【Security Hub修復手順】[ECS.4] ECS コンテナは、非特権として実行する必要があります

こんにちは。AWS事業本部コンサルティング部に所属している今泉（@bun76235104）です。

皆さん、お使いのAWS環境のセキュリティチェックはしていますか？

当エントリでは、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修正手順をご紹介します。

本記事の対象コントロール

[ECS.4] ECS コンテナは、非特権として実行する必要があります

[ECS.4] ECS containers should run as non-privileged

前提条件

本記事はAWS Security Hubで「AWS基礎セキュリティのベストプラクティススタンダード」を利用されている方向けの内容となります。 AWS Security Hubの詳細についてはこちらのブログをご覧ください。

対象コントロールの説明

今回のコントロールは「ECS コンテナは、非特権として実行する必要があります」です。

このコントロールではAmazon ECSのタスク定義内でコンテナのprivilegedパラメータがtrueに設定されているかどうかをチェックします。（移行「特権モード」と表記する際は、このprivilegedがtrueである状態を指します）

privileged= 優遇された という意味合いで、コンテナを優遇するをパラメータということで何となく危険そうなのは分かりますが、どのように危険なのでしょうか？

特権モードのコンテナ？何が危ないの？

短く言うと「ホストコンピュータに対しても非常に強い権限を備えてしまうコンテナ」です。ホストに対してもと聞くと非常に危険そうな感じがしますね。

私も以前勘違いしていたのですが「コンテナのプロセスをroot権限で動かすこと」ではありません。

Linuxカーネルにおけるケーパビリティ（capability）が関連しています。

「ケーパビリティって何？」と短い言葉で説明できない場合はぜひ以下の記事をご参照ください。非常に分かりやすかったです。

私はrootユーザーが万能なのではなく、全ケーパビリティを備えたrootユーザーが万能ということだと理解しています。

privileged=falseなコンテナであれば、このケーパビリティが制限されていますが、特権モード（privileged=true）で起動している場合、すべてのケーパビリティを持つことになります。

特権コンテナのケーパビリティがあれば、それを利用してホスト環境へのルートアクセスを取得することが可能になるそうです。

このあたりの危険性などについて、こちらの記事をご参照ください。詳細に書かれていて、危機感を感じました。

ということでコンテナを特権モードにおいて起動しないように修正手順を見ていきます。

修正手順

1 対象のリソース（タスク定義）を特定

まずAWS Security HubのコンソールからECS.4のチェック結果を確認します。是正対象のタスク定義を確認できます。

2 ステークホルダーに確認

ステークホルダー（タスク定義の作成者やアプリケーションを管理している部署など）に以下を確認しましょう。

• 特権モードではなく privileged=false にしても問題ないか？
  • 完全なケーパビリティを持つ万能なアクセス権限を与える必要は本当にあるのか？

また、特権モードが有効である場合タスク定義のネットワークモードがhostという設定になっています。

こちらについてもセキュリティ上のリスクや制約がありますので合わせて変更を検討したいところです。

別のコントロールの範疇になるため今回詳細は割愛しますが、こちらの記事を参照して合わせて確認してください。

※設定変更後、稼働しているアプリケーションに影響が出る可能性があるため社内で注意深く確認・対応してください。

3 ECSのタスク定義を修正

ここからAWSのマネジメントコンソールにログインして実際の画面イメージを見ながら説明いたします。

なお、ここからの説明では、ECSのコンソールで左上に表示されている「新しいECSエクスペリエンス」を有効にした新しいダッシュボードを利用した画面となっています。

Amazon ECSのコンソールにアクセスして、「タスク定義」をクリックします。

次に特権モードでコンテナを起動させる設定になっているタスク定義を選択（クリック）します。

現在利用しているリビジョンを選択して、「新しいリビジョンの作成」をクリックして「JSONを使用した新しいリビジョンの作成」をクリックします。

タスク定義のJSON内 containerDefinitions配下のprivilegedの値がtrueとなっていることを確認します。

確認後値をfalseに変更します。

falseに変更後、「作成」をクリックします。

これでタスク定義の新しいリビジョンでは特権モードを無効にできました。

タスクをサービスで稼働させている場合、以下の手順で対象のサービスを選択して「更新」をクリックします。

「デプロイ設定」ブロックの「リビジョン」を上で作成したタスク定義のリビジョンに設定して画面下部の「更新」をクリックしましょう。

これにてサービスで稼働しているタスクも新しいものに更新できました。

なお、CI/CDで新しいタスク定義のリビジョンのリリースを自動化している場合、そちらでリリースするタスク定義の設定を決めている可能性があります。

「無事に是正できたと思ったら次のリリースでまた特権モードのコンテナになっていた」ということがないように、ECSアプリケーションのデプロイ手順をよく確認しておきましょう。

最後に

今回は、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修正手順をご紹介しました。

コントロールを修正して、お使いのAWS環境のセキュリティをパワーアップさせましょう！

最後までお読みいただきありがとうございました！どなたかのお役に立てれば幸いです。

以上、今泉でした！