こんにちは。AWS事業本部トクヤマシュンです。
本日より、Amazon GuardDuty ECS Runtime Monitoringが利用できるようになりました！！
当機能はECS on Fargate、ECS on EC2のどちらにも対応しています！！
(2023/11/29追記：ECS on EC2は現在プレビュー機能のようです。)
立ち位置としては、これまでAmazon GuardDuty EKS Runtime MonitoringとしてEKSのみに提供されてきた機能が、
Runtime Monitoringとして独立してECS、EC2にも対応できるようになった、ということのようです。
(EC2は現在プレビュー)
Amazon EKSではできるようになったのにECSはまだか...
とずっとやきもきしていたため、このアップデートはまさに待ち望んでいたものでした！！
ECSを利用しているユーザーは全員利用を検討すべき機能だと思います！！
興奮さめやりません！！
ここからは本機能の内容についてみていきます。
はじめにサマリ
はじめに、今回のアップデート内容をサマリします。
- 機能概要
- ECSのランタイムセキュリティに関する問題をGuardDutyで検出できるようになった
- これまではEKS on EC2のみだったが、ECS on Fargate、ECS on EC2でも使えるように
- ECSのランタイムセキュリティに関する問題をGuardDutyで検出できるようになった
- 検出の仕組み
- サイドカー形式でデプロイされたGuardDutyセキュリティエージェントによって、ランタイムセキュリティに関するイベントを記録
- 専用のVPCエンドポイントが作成される
- エージェントが記録したイベントはVPCエンドポイント経由でGuardDutyに送信
- このVPCエンドポイントは無料
- 有効化方法
- 下記の2ステップ
- ①Runtime Monitoringを有効化
- ②GuardDutyセキュリティエージェントをデプロイ
- インストールされたエージェントの状態はCoverageからまとめて確認可能
- 下記の2ステップ
- マルチアカウント管理
- AWS Organizationsと連携し、マルチアカウントで有効/無効や結果の集約が可能
- 要件
- データプレーン
- Fargateの場合
- platformバージョンは1.4.0もしくはLATESTであること
- EC2の場合
- 2023/09/29以降のECS-optimized AMIもしくはECSエージェントのバージョンv1.77.0以上であること
- ホストOSはAmazon Linux 2もしくはAmazon Linux 2023であること（2023年12月1日：Amazon Linux 2023も対象である旨追記）
- CPUアーキテクチャはx64/Gravitonのどちらにも対応
- Fargateの場合
- タスク
- 利用可能なvCPUとメモリの組み合わせあり
- GuardDutyセキュリティエージェント用のメモリ確保が必要
- 詳細はこちらの表参照
- Amazon ECRからエージェントイメージをダウンロードする必要あり
- タスク実行ロールにECRへのアクセス権限が必要
- ECRへのアクセス経路が必要
- 利用可能なvCPUとメモリの組み合わせあり
- データプレーン
- 料金
- 30日間は無料
- 試用期間終了後はエージェントが保護するタスクのvCPU量に応じて課金
- 最初の500vCPU：1vCPUあたり$1.5/月
- 次の4,500vCPU：1vCPUあたり$0.75/月
- 以降：1vCPUあたり$0.25/月
- 利用可能なリージョン
- US East (N. Virginia)
- US West (Oregon)
- US East (Ohio)
- Europe (Ireland)
- Europe (Frankfurt)
- Europe (Stockholm)
- Asia Pacific (Sydney)
- Asia Pacific (Tokyo)
- Asia Pacific (Singapore)
長くなってしまいましたが、サマリは以上です。
ここからは、
- 何ができるようになったのか？
- 何が嬉しいのか？
- どのように有効化するのか？
についてみていきます。
何ができるようになったのか？
ECSクラスター上で動作しているコンテナに対して、潜在的なランタイムセキュリティに関する問題を検出することができるようになりました。
コンテナの権限昇格や不正なプロセスの実行、ネットワーク接続などの発生を検知することで、早期に脅威に気づいて対応することができます。
何が嬉しいのか？
コンテナのセキュリティガイドラインとしてデファクトスタンダードとなっているNIST SP800-190（IPAによる和訳もあります）によると、
コンテナのセキュリティリスクは下記に分類されています。
- ①イメージのリスク
- ②レジストリのリスク
- ③オーケストレータのリスク
- ④ホストのリスク
- ⑤コンテナのリスク
⑤コンテナのリスク対策についてはこれまでAmazon GuardDuty Malware ProtectionやAmazon Guard Duty EKS Runtime Monitoringといったサービスがありましたが、
データプレーンにFargateを使っていた場合は利用可能なAWSサービスがありませんでした。
今回のアップデートによってECS on Fargateを用いている場合でもコンテナのリスクへの対応が可能となりました！
ECS on Fargateを利用していた場合のコンテナのリスク対策が非常に悩ましかったのですが、これからはAmazon GuardDuty ECS Runtime Protectionを利用することが第一の選択肢となるかと思います。
なお、⑤コンテナのリスク対策となりうるAWSサービスの対応状況は下記の通りとなりましたので、ご参考ください。
（コンテナのリスク対策がとれないのはあとEKS on Fargateだけ...！！）
どのように有効化するのか？
では、AWSマネージメントコンソールから有効化してみましょう。
Amazon GuardDutyのサービス画面の左ペインからRuntime Monitoringをクリックします。
上部でRuntime Monitoring自体の有効有無が設定できますので、「有効にする」をクリックします。
ポップアップが出てきたら、「確認」をクリックします。
Runtime Monitoring自体は有効化できました。 次に、ECS Runtime Monitoringを有効化するため、AWS Fargate(ECS only)の欄にある「有効にする」をクリックします。
またポップアップが出てくるので、「確認」をクリックします。
ECS Runtime Montoringを有効化できました。
基本的な設定はたったこれだけです。
画面内のRuntime coverageタブ→ECS clusters runtime coverageをクリックしてみます。
存在する全てのクラスターが「Auto-maneged」として自動で登録され、表示されます。
（表示されるまでにはしばらくラグがあるかもしれません）
この手順で有効化すると、すべてのECSクラスターがECS Runtime Monitoringの対象となるようです。
一部のクラスターを対象外としたい、という場合にはクラスターにタグ付けが必要です。
詳細は公式ドキュメント Managing the security agent for Fargate (Amazon ECS only)をご確認ください。
さて、次にECSクラスター内でECSサービスを起動してみます。
test-nginxというクラスター内に、次のタスク定義を持つサービスを開始します。
（サービスではタスクをパブリックサブネットで起動するよう設定しました。ECRへの接続が必要なので）
test-nginxタスク定義(クリックで展開)
{
"taskDefinitionArn": "arn:aws:ecs:ap-northeast-1:xxxxxxxxxxxx:task-definition/test-nginx:3",
"containerDefinitions": [
{
"name": "nginx",
"image": "public.ecr.aws/nginx/nginx:stable",
"cpu": 0,
"portMappings": [
{
"name": "nginx-80-tcp",
"containerPort": 80,
"hostPort": 80,
"protocol": "tcp",
"appProtocol": "http"
}
],
"essential": true,
"environment": [],
"environmentFiles": [],
"mountPoints": [],
"volumesFrom": [],
"ulimits": [],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-create-group": "true",
"awslogs-group": "/ecs/test-nginx",
"awslogs-region": "ap-northeast-1",
"awslogs-stream-prefix": "ecs"
},
"secretOptions": []
}
}
],
"family": "test-nginx",
"taskRoleArn": "arn:aws:iam::xxxxxxxxxxxx:role/testEcsTaskRole",
"executionRoleArn": "arn:aws:iam::xxxxxxxxxxxx:role/ecsTaskExecutionRole",
"networkMode": "awsvpc",
"revision": 3,
"volumes": [],
"status": "ACTIVE",
"requiresAttributes": [
{
"name": "com.amazonaws.ecs.capability.logging-driver.awslogs"
},
{
"name": "ecs.capability.execution-role-awslogs"
},
{
"name": "com.amazonaws.ecs.capability.docker-remote-api.1.19"
},
{
"name": "com.amazonaws.ecs.capability.task-iam-role"
},
{
"name": "ecs.capability.extensible-ephemeral-storage"
},
{
"name": "com.amazonaws.ecs.capability.docker-remote-api.1.18"
},
{
"name": "ecs.capability.task-eni"
},
{
"name": "com.amazonaws.ecs.capability.docker-remote-api.1.29"
}
],
"placementConstraints": [],
"compatibilities": [
"EC2",
"FARGATE"
],
"requiresCompatibilities": [
"FARGATE"
],
"cpu": "256",
"memory": "512",
"ephemeralStorage": {
"sizeInGiB": 21
},
"runtimePlatform": {
"cpuArchitecture": "X86_64",
"operatingSystemFamily": "LINUX"
},
"registeredAt": "2023-11-27T12:55:00.334Z",
"registeredBy": "arn:aws:sts::xxxxxxxxxxxx:assumed-role/cm-tokuyama.shun/cm-tokuyama.shun",
"tags": []
}タスクが起動してくると、aws-guardduty-agent-から始まるコンテナ名を持つ、タスク定義にはないコンテナを確認できました。
これが、GuardDutyセキュリティエージェントのサイドカーコンテナです。
今回タスクはvCPU：0.25、メモリ0.5GBで起動したので、エージェント用のメモリは0.125GB確保されてます。
しばらく待つと、コンテナがRunning状態となります。
この状態でも、GuardDutyエージェントのコンテナ詳細はブラックボックスになっていて分かりません。
ともあれ、ECS Runtime Monitoringを有効化することができました。
この状態でtest-nginxコンテナで何らかの脅威と思われるイベントが起こると、GuardDutyで検出されることになります。
ECS側では特に設定は不要（GuardDutyエージェントの使うメモリを考慮するくらい）なので、とても楽に有効化することができました！
まとめ
今回のエントリではAmazon GuardDuty ECS Runtime Monitoringの発表についてまとめました。
これまでECS on Fargateを使ってきた方にとっては特に必見のアップデートです！
まずはぜひご利用してみてください！
0
