![【Security Hub修復手順】[ECS.21] ECS タスク定義では、Windowsコンテナ定義で管理者以外のユーザーを設定する必要があります](https://images.ctfassets.net/ct0aopd36mqt/wp-refcat-img-cea52bc8a6ec5cad9021b38df4a08b9e/24c76ee7c1ae7aa7f9676a59c77f8702/aws-security-hub?w=3840&fm=webp)
【Security Hub修復手順】[ECS.21] ECS タスク定義では、Windowsコンテナ定義で管理者以外のユーザーを設定する必要があります
こんにちは！クラウド事業本部コンサルティング部の浅野です。
皆さん、お使いのAWS環境のセキュリティチェックはしていますか？
本記事では、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修復手順をご紹介します。
本記事の対象コントロール
[ECS.21] ECS タスク定義では、Windows コンテナ定義で管理者以外のユーザーを設定する必要があります
[ECS.21] ECS Task Definitions should configure non-administrator users in Windows container definitions
本記事は Windowsコンテナ を対象としたコントロールを扱います。Linuxコンテナ版（[ECS.20]）の修復手順については以下の記事で取り上げています。
前提条件
本記事はAWS Security Hubで「AWS基礎セキュリティのベストプラクティススタンダード」を利用されている方向けの内容となります。
AWS Security Hubの詳細についてはこちらのブログをご覧ください。
対象コントロールの説明
このコントロールは、ECSタスク定義の最新のアクティブなリビジョンで、Windowsコンテナが管理者以外のユーザーとして実行されるよう設定されているかチェックします。
コンテナ定義の user パラメータに管理者以外のユーザー（containeradministrator 以外）が設定されていると、このコントロールは成功します。
Windowsコンテナのデフォルトユーザーとは
Windowsコンテナを何も指定せずに起動すると、デフォルトで ContainerAdministrator という管理者アカウントで動作します。これはLinuxコンテナの root に相当する強い権限を持つアカウントです。
Microsoftは、Windowsコンテナイメージに ContainerUser という制限付きアカウントを標準で用意しており、マルチテナント環境では ContainerUser の利用を推奨しています。
| アカウント | 役割 | Linux相当 |
|---|---|---|
ContainerAdministrator |
管理者権限 | root |
ContainerUser |
制限付きユーザー | 一般ユーザー（UID 1000等） |
評価ロジック
本コントロールはWindowsコンテナを対象とします。タスク定義の operatingSystemFamily が WINDOWS_SERVER_* のものが評価対象であり、Linuxコンテナや operatingSystemFamily 未設定のタスク定義は評価対象外です。
評価対象のタスク定義で、コンテナ定義の user パラメータが以下のいずれかの状態だと FAILED と検知されます。
userが未設定（デフォルトのContainerAdministratorで動作する扱い）userにcontaineradministratorまたは0が明示指定されている
対応しないとどうなるか
コンテナが管理者権限で動作する場合、コンテナ内の脆弱性を起点とした攻撃が成立した際に、ホスト側への影響範囲が広がります。特権コンテナの利用やコンテナエスケープと組み合わさると、ホストOSへの侵害につながる懸念もあります。
AWS公式のAmazon ECSのタスクとコンテナのセキュリティに関するベストプラクティスでも、コンテナを管理者以外のユーザーで実行することが推奨されています。
最小権限の原則に従い、コンテナを管理者以外で動かすことは本番環境では必須の対応です。
修復手順
コントロールの確認方法
- AWSマネジメントコンソールからSecurity Hub CSPMを開く
- 左メニューから「検出結果」を選択
- フィルターで
コンプライアンスセキュリティコントロールIDにECS.21を指定し、コンプライアンスのステータスがFAILEDの検出結果を確認する
- 該当の検出結果を選択し、詳細パネルから対象リソース（タスク定義）のARNを確認する
ARNの形式例: arn:aws:ecs:<region>:<account-id>:task-definition/<family-name>:<revision>
ステークホルダーに確認
修復を行う前に、以下の点をステークホルダーに確認してください。
- 対象タスク定義を利用しているECSサービス・ECSタスクの稼働状況
- コンテナアプリケーションが管理者以外のユーザーで動作するか（管理者権限が必要なシステム操作・サービス起動を含んでいないか）
- 新しいタスク定義リビジョンへの切り替えタイミング（メンテナンスウィンドウ）
現状の確認
ECSコンソールから対象のタスク定義リビジョンを開き、「コンテナ: <コンテナ名>」セクションの「ランタイムの設定」を確認すると、「ユーザー」が空欄（未設定）になっていることが確認できます。
この状態のタスク定義は、起動時にデフォルトの ContainerAdministrator（管理者）で動作するため、本コントロールは FAILED となります。
修復値として containeruser を指定する背景
本コントロールへの対応は、タスク定義の user パラメータに管理者以外のユーザーを指定することです。
具体的に何を指定すべきかは、公式情報と実機検証の両面から決めていきます。
Microsoft公式が推奨する非管理者アカウント
Microsoft公式の Secure Windows containers では、Windowsコンテナの標準アカウントとして以下を案内しています。
Windows Server containers offer two default user accounts, ContainerUser and ContainerAdministrator, each with their own specific purpose. ... We strongly recommended that when deploying a Windows server container to any multi-tenant environment that your application runs via the ContainerUser account.
→ つまり、推奨される指定値は ContainerUser です。
AWS公式 API Reference の記述には注意
一方、AWS の ContainerDefinition API Reference を確認すると、user パラメータの説明欄に次の記述があります。
The user to use inside the container. ... This parameter is not supported for Windows containers.
つまり、AWS公式ドキュメント上は「Windowsコンテナでは user パラメータはサポートされていない」と明記されています。
Configルールは値の内容を厳密には見ない
本コントロールの実体である AWS Config ルール ECS_TASK_DEFINITION_WINDOWS_USER_NON_ADMIN は、タスク定義の user の値が「containeradministrator または 0、もしくは未設定」のいずれかでなければ COMPLIANT と判定します。
逆にいうと、この条件さえ外せば、設定した値が実在するユーザーか・実行時に効くかは問わず PASSED 扱いになります。
では「PASSED = 安全に動作している」と言えるか
そうとは限りません。AWS公式が「Windowsでは非サポート」と書いている以上、たとえ user="containeruser" と指定しても、実行時に値が無視されて ContainerAdministrator のまま動いてしまう可能性も否定できません。
形式的に PASSED にできることと、実態として管理者以外のユーザーで動いていることは別の問題です。本記事ではここを実機で確認します。
実機検証：実際に ContainerUser として動作しているか
タスク定義に "user": "containeruser" を設定したコンテナを Fargate で実際に起動し、コンテナ内で whoami /all を実行して、現在のユーザー名・所属グループ・特権を確認しました。
whoami /all は Windows 標準のコマンドで、コマンドを実行したプロセスが「どのユーザー」「どのグループに所属」「どんな特権を持つか」を一括出力します。これにより、表面的なユーザー名だけでなく、Microsoft が用意した制限付きアカウントの権限プリセットを満たしているかまで確認できます。
検証結果の CloudWatch Logs：
出力から確認できる重要な3点は次のとおりです。
| 観点 | 出力 | 意味 |
|---|---|---|
| Mandatory Label | Medium Mandatory Level (S-1-16-8192) |
Windows OSが「管理者プロセスではない」と判定している。管理者なら High Mandatory Level (S-1-16-12288) になる |
| 所属グループ | BUILTIN\Users は含まれるが BUILTIN\Administrators は含まれない |
一般ユーザーグループにのみ所属し、管理者グループには属していない |
| 特権リスト | SeChangeNotifyPrivilege（全ユーザー標準）と SeIncreaseWorkingSetPrivilege のみ |
SeBackupPrivilege / SeDebugPrivilege / SeRestorePrivilege 等の管理者特権を一つも持っていない |
これらは Windows OS レベルで「管理者ではない」ことを示す確実な証拠です。
つまり、AWS公式 API Reference の「Windowsでは非サポート」記述に反して、実装上はタスク定義の user がコンテナの実行ユーザーコンテキストに反映されており、ContainerUser として正しく機能していることが確認できました。
結論
以上から、本コントロールの修復値として "user": "containeruser" を採用します。
ECS.21 を PASSED にできるだけでなく、コンテナが実際に ContainerUser（Microsoft 標準の制限付きアカウント）として動作することを実機で確認済みのため、安心して指定できます。
なお、Windowsのユーザー名は大文字小文字を区別しないため、containeruser と ContainerUser は同一のユーザーを指します。本記事では後述するコンソールGUIのバリデーション制約の都合により containeruser 表記で進めます。
JSONエディタで新しいリビジョンを作成し、user パラメータを設定
ECSコンソールでは、コンテナ定義の user パラメータの入力欄が標準のGUIフォーム上に確認できません。修正にはJSONエディタを使用します。
コンソールGUIの注意点: コンテナ詳細フォームに
user用の入力欄を見つけて値を入れても、ContainerUser（先頭大文字）はバリデーションエラーで弾かれます。コンソールGUIのバリデーションは小文字英数字とアンダースコア・ハイフンしか受け付けないためです。前述のとおりWindowsのユーザー名は大文字小文字を区別しないため、containeruser（全て小文字） で指定すれば問題ありません。
タスク定義ファミリーのリビジョン一覧で最新リビジョンにチェックを入れ、「新しいリビジョンを作成」を選択します。
新リビジョンの編集画面の下部「コンテナ: <コンテナ名>」セクションで「JSON」タブに切り替え、コンテナ定義のJSON内に "user": "containeruser" を追加します。
画面下部の「作成」を選択し、新しいリビジョンを作成します。
作成後、新リビジョン詳細の「コンテナ: <コンテナ名>」セクションを展開し、「ランタイムの設定」で「ユーザー」が containeruser になっていることを確認します。
ECSサービスでタスク定義を利用している場合は、新しいリビジョンを利用するようサービスを更新してください。スタンドアロンタスクとして実行している場合は、新しいリビジョンでタスクを再実行してください。
修復確認
本コントロールは タスク定義の登録時点で評価される ため、新しいリビジョンを作成した時点でPASSEDに切り替わります。サービスの更新は実際の稼働タスクを新リビジョンに切り替えるためのものであり、Security Hubの判定自体はサービス更新を待たずに反映されます。
数分後、Security Hubで検出結果が「PASSED」になることを確認します。
詳細を見ると、コンプライアンスが「PASSED」になっていることが確認できます。
検出結果のリソース情報で、参照されているタスク定義のリビジョン番号が新しいリビジョンに切り替わっていることもあわせて確認します。
注意: Security Hubの検出結果は更新までに時間がかかる場合があります（最大12時間程度）。
最後に
今回は、AWS Security HubによるAWS環境のセキュリティ状況スコアリングに該当する項目についての修正手順をご紹介しました。
コントロールを修正して、お使いのAWS環境のセキュリティをパワーアップさせましょう！
最後までお読みいただきありがとうございました！どなたかのお役に立てれば幸いです。
今回は以上です。
