Amazon SCS-C02: コンテナとサーバーレスセキュリティ — 学習ガイド

By Laurynas Brazys · 25 July 2026 · #amazon #scs-c02 #certification #exam-prep #study-guide

こちらの一部です： AWS Security Specialty SCS-C02 — 学習ガイド. 検証済みの解答で練習： Amazon試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.

SSHを使わないECS Execとランタイム調査

ECS Execは、SSH、踏み台ホスト、パブリックIPを公開することなく、実行中のコンテナ（Fargateタスクを含む）へのインタラクティブなシェルを提供します。これは、AWSがタスクのサイドカー実行環境にインジェクトするSSMエージェント上で動作することで機能します。SSHデーモンがなく、キーマテリアルもなく、保護すべきインバウンドネットワークパスもないため、運用オーバーヘッドは最小限に抑えられ、すべてのセッションはCloudTrailを通じて監査可能であり、（オプションで）S3やCloudWatch Logsにログを記録できます。

ECS Execが機能するためには、以下の3つの要件をすべて満たす必要があります。

タスクロールの権限: 実行ロールではなくタスクロールに、ssmmessages:CreateControlChannel、ssmmessages:CreateDataChannel、ssmmessages:OpenControlChannel、ssmmessages:OpenDataChannelの権限が必要です。実行ロールはイメージのプルとログの書き込みのみを行います。ランタイムのSSMトラフィックはタスクロールを経由します。なぜなら、コンテナプロセスが引き受けるアイデンティティがタスクロールだからです。
サービスまたはタスクの設定: サービスは--enable-execute-command付きで作成または更新される必要があります。このフラグは新しいタスクでenableExecuteCommandを有効にします。既存のタスクは置き換える必要があります。
コンテナイメージのサポート: コンテナイメージ内にシェル（/bin/shまたは/bin/bash）が存在する必要があります。

一般的な調査フローは次のようになります。

aws ecs update-service --cluster prod --service api \
  --enable-execute-command --force-new-deployment

aws ecs execute-command --cluster prod \
  --task 5f8c...c2 --container api \
  --interactive --command "/bin/sh"

そのシェルから、エンジニアはS3にログをコピーしたり、ヒープダンプをトリガーしたり、フォレンジックのために/procを読み取ったりすることができます。代替案である、SSH経由でコンテナにアクセスしようとしたり、デバッグエージェントを有効にするためにタスクを再起動したりする方法は、Fargateでは失敗するか、収集しようとしていた証拠を破壊してしまいます。

EC2上のコンテナからのIMDSアクセスをブロックする

よくある誤解として、EC2インスタンスのIMDSv2ホップリミット設定がそのインスタンス上のコンテナを保護するというものがあります。しかし、少なくともデフォルトのブリッジまたはホストネットワークモードでは、そうはなりません。コンテナはホストのネットワーク名前空間またはNATブリッジを共有し、169.254.169.254に到達してインスタンスプロファイルの認証情報を取得できてしまいます。これは通常、タスクロールよりもはるかに高い権限を持っています。これにより、最小権限の原則が完全に損なわれます。

Fargateへの移行が不可能な場合の修正策は、2つの部分からなります。

タスクにawsvpcネットワークモードを使用する。 各タスクは独自のENIとネットワーク名前空間を持つようになります。IMDSトラフィックはホストのリンクローカルエンドポイントに透過的に到達しなくなります。
コンテナインスタンスの/etc/ecs/ecs.configでECS_AWSVPC_BLOCK_IMDS=trueを設定する。 これにより、ECSエージェントは、awsvpcタスクから169.254.169.254宛のパケットをドロップするiptablesルールをインストールするよう指示されます。

echo 'ECS_AWSVPC_BLOCK_IMDS=true' >> /etc/ecs/ecs.config
systemctl restart ecs

これを、最小限のインスタンスプロファイル（基本的にECSエージェントが必要とするものだけ、つまりAmazonEC2ContainerServiceforEC2Role）と、アプリケーション権限のためのタスクごとのIAMロールと組み合わせます。インスタンスのIMDSホップリミットを1に設定し、IMDSv2を必須にすることは、有用な多層防御策ではありますが、代替にはなりません。ブリッジモードのコンテナは、リクエストがホストから発信されるため、ホップ1でIMDSに到達できてしまうからです。

GuardDuty Runtime Monitoring、EKS Protection、およびコントロールプレーンログ

GuardDutyは、階層化されたコンテナ検出機能を提供します。

EKS Protectionは、EKSの監査ログを分析し、不審なKubernetes APIアクティビティ（匿名アクセス、特権Podの作成、システムPodへのexecなど）を検出します。
Runtime Monitoringは、eBPFベースのセンサーをデプロイし（EKSのマネージドアドオンとして、またはECS/FargateのSSM管理エージェントとして）、コンテナ内部のプロセス、ファイル、ネットワークアクティビティを監視します。これにより、Podやタスク内からのリバースシェル、暗号通貨マイニングバイナリ、認証情報漏洩などの検出結果を表面化させます。

EKS Protectionは、EKSコントロールプレーンの監査ログが実際にCloudWatch Logsに出力されていない限り、価値がありません。クラスターで少なくともauditとauthenticatorのログタイプを有効にしてください。

aws eks update-cluster-config --name prod \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'

これがないと、GuardDutyはEKS Protectionの検出結果を検査するためのデータプレーンを持たないことになります。これは、オペレーターがGuardDutyの機能を有効にしながらクラスターのロギング設定をオフのままにし、なぜKubernetesの検出結果が表示されないのか不思議に思う、というよくある落とし穴です。

ECR拡張スキャンによるイメージスキャン

ECR拡張スキャンはAmazon Inspectorを搭載しており、コンテナイメージのOSおよび言語パッケージ（Python、Node、Java、Go、Ruby）のCVEを継続的にスキャンします。基本スキャンはプッシュ時に一度だけ実行され、OSパッケージのみを対象とします。一方、拡張スキャンは継続的で、アプリケーションの依存関係も含まれます。現代の脆弱性のほとんどはここに存在します。

両方のサービスが有効になっている場合、検出結果は自動的にSecurity Hubに流れ、コンプライアンスのための一元的な可視性を提供し、CI/CDビルドを失敗させるEventBridgeルールを記述できるようになります。一般的な強制パターンは次のとおりです。

実践的な問題：ユースケースシナリオ

シナリオ： NovaTech社は、顧客向けのマイクロサービスを混合コンピューティング環境で実行しています。これには、EC2上の複数のECSクラスター、データ処理用のEKSクラスター、イベント処理用のサーバーレスLambdaが含まれます。イメージはECRに保存され、運用ではホストアクセスにSSMを使用し、GuardDutyとCloudWatchは有効化されていますが、コンテナとコントロールプレーンコンポーネント全体での可視性は一様ではありません。

課題： 本番環境のコンテナが不審なアウトバウンド接続を示し、あるエンジニアがPodからEC2インスタンスメタデータサービスに到達できることを発見しました。これにより、認証情報が漏洩するリスクがありました。イメージの脆弱性とコントロールプレーンのロギング不足が、根本原因を隠している可能性があります。

推奨アプローチ：

タスクに対してECS Execを有効化し、ホストとコンテナランタイムの調査のためにAWS Systems Manager Session Managerを必須とします（ECS Exec + SSM）。これにより、SSHの必要性をなくし、セッションアクティビティがCloudTrailとCloudWatch Logsに記録されることを保証します。
EC2インスタンスでIMDSv2を強制し（Instance Metadata ServiceでHttpTokens=required, hop limit=1）、ホストレベルのネットワークルールを適用してコンテナのネットワーク名前空間から169.254.169.254へのアクセスをブロックし、コンテナがインスタンスメタデータをクエリできないようにします。
コンテナとLambdaに対してAmazon GuardDutyのランタイムモニタリングとマルウェア保護を有効にし、検出結果をSecurity HubとEventBridgeに転送して、自動化された封じ込めプレイブックを実行します。
コントロールプレーンログ（audit, authenticator, controllerManager, scheduler）をCloudWatch Logsに送ることでEKSを強化し、IAM Roles for Service Accounts (IRSA) を採用し、アドミッションコントロール（Pod SecurityまたはOPA Gatekeeper）を強制してリスクの高いケーパビリティを制限します。
Amazon ECRの拡張イメージスキャン（Inspector/ECRスキャン）を有効化し、プッシュ時のスキャンを設定します。検出結果をCIに統合し、EventBridge + Lambdaを介してイメージをブロック/隔離する強制措置を講じます。
テレメトリを一元化します。CloudTrail、GuardDutyの検出結果、EKSコントロールプレーンログ、ECRスキャン結果を、一元化されたS3/Lambda/Security Hubパイプラインに送信し、継続的なコンプライアンスのためにAWS Configルールにフィードします。

論理的根拠： この一連の対策は、SSHベースのアクセスを排除し、メタデータによる認証情報の盗難を防ぎ、ランタイムでの検出と自動応答を提供し、イメージの衛生状態を徹底させ、コントロールプレーンの可視性を確保します。これは、最小権限、多層防御、および一元化された可観測性というAWSのベストプラクティスに沿ったものです。

# CodeBuild buildspec fragment
post_build:
  commands:
    - aws ecr describe-image-scan-findings \
        --repository-name api --image-id imageTag=$TAG \
        --query 'imageScanFindings.findingSeverityCounts' > findings.json
      CRIT=$(jq '.CRITICAL // 0' findings.json)
      if [ "$CRIT" -gt 0 ]; then echo "Critical CVEs present"; exit 1; fi

パイプラインへの統合こそが、スキャンを単なるダッシュボード上の作業から、実効性のある統制へと変えるのです。

Lambda：オーソライザー、シークレット、実行ロール

Lambda関数レベルのセキュリティには、混同されがちな3つの側面があります。

リソースポリシー（関数ポリシー）： どのプリンシパル（API Gateway、EventBridge、他のアカウントなど）が関数を呼び出せるかを制御します。API GatewayのLambdaオーソライザーは、HTTP呼び出し元に対するIDゲートです。これはIAMポリシーを返し、API Gatewayはそのポリシーをキャッシュして、バックエンド関数を呼び出す前に強制適用します。
実行ロール： 関数コードがランタイムで引き受けるIDです。その信頼ポリシーにはlambda.amazonaws.comを含める必要があり、CloudWatch Logsが機能するためにはlogs:CreateLogGroup、logs:CreateLogStream、logs:PutLogEventsの権限を付与する必要があります。ログが見つからない場合、修正すべきはほとんどの場合、実行ロールです。LambdaコンソールはCloudWatchが受信したログをレンダリングするだけなので、コンソールが原因ではありません。「コンソールのログだけ」に頼るのは診断の罠です。実行ロールに権限がなければログストリームは作成されず、コンソールには何も表示されません。
シークレットの取得： 認証情報を平文で環境変数に埋め込まないでください。Secrets ManagerまたはSSM Parameter StoreのSecureStringに保存し、コールドスタート時に取得します。

import boto3, os, json
_ssm = boto3.client("ssm")
_cached = None

def get_db_password():
    global _cached
    if _cached is None:
        r = _ssm.get_parameter(Name=os.environ["DB_PWD_PARAM"], WithDecryption=True)
        _cached = r["Parameter"]["Value"]
    return _cached

実行ロールには、CMKに対するssm:GetParameterとkms:Decryptの権限が必要です。ウォーム呼び出し時にAPIコールを避けるため、モジュールスコープでキャッシュします。スループットが高い関数では、Secrets Manager Lambda拡張機能を使用して、ローテーションを意識した自動キャッシュを利用します。

ECRの暗号化とリポジトリ保護

Amazon ECRは、デフォルトでAWSマネージドキーを使用してAES-256ですべてのイメージを保管時に暗号化しますが、規制対象のワークロードでは通常、カスタマーマネージドKMSキーが必要です。これにより、キーのローテーション、キーポリシー、CloudTrailでの監査可能性が顧客の管理下に置かれます。KMS暗号化はリポジトリ作成時にのみ設定可能です。既存のECRリポジトリを後からAES-256からKMSに変更することはできません。したがって、移行には、新しいKMS暗号化リポジトリを作成し、イメージを複製または再プッシュし、下流のコンシューマーを更新し、古いリポジトリを削除する必要があります。KMS暗号化リポジトリからプルするクロスアカウントのコンシューマーには、ECRの読み取り権限に加えて、CMKに対するkms:Decrypt権限を付与する必要があります。さもなければ、リポジトリポリシーがプリンシパルを許可していても、KMSアクセスエラーでプルは失敗します。

{
  "encryptionConfiguration": {
    "encryptionType": "KMS",
    "kmsKey": "arn:aws:kms:us-east-1:111122223333:key/abcd-...-ef01"
  },
  "imageScanningConfiguration": { "scanOnPush": true },
  "imageTagMutability": "IMMUTABLE"
}

イミュータブルタグ（変更不能タグ）は、検証済みのv1.2.3タグがスキャン後に悪意のあるイメージによって密かに上書きされるといった、タグハイジャック攻撃を防ぎます。

イメージスキャン: 基本、拡張、Inspector

ECRは2つのスキャンモードを提供します。基本スキャンは、オープンソースのClair CVEデータベースを使用し、プッシュ時（または手動実行時）にのみ実行され、ECRコンソールで検出結果を返します。これは無料ですが、継続的な再スキャンは行わず、OSとプログラミング言語パッケージをまとめてカバーすることはなく、Security Hubとのネイティブな統合もありません。拡張スキャンはAmazon Inspectorを搭載しており、オペレーティングシステムパッケージとアプリケーション言語パッケージ（Python、Java、Node.js、Go、Ruby、.NET）の両方をカバーします。Inspectorは、更新された脆弱性インテリジェンスに対してプッシュされたイメージを継続的に監視するため、イメージがプッシュされた1週間後に公開されたCVEであっても、再ビルドすることなく検出結果が生成されます。

拡張スキャンはレジストリレベル（リージョンごと）で有効になり、リポジトリごとにprod-*やteam-a/*のようなワイルドカードパターンを使用した包含フィルターを設定します。これは、「ほとんどのリポジトリをスキャンするが、サンドボックス/実験用のリポジトリは除外する」という一般的な要件に対する正しい制御方法です。個々のリポジトリに対してネガティブな除外設定を行うのではなく、スキャン対象をリストアップするポジティブフィルターを定義します。

aws ecr put-registry-scanning-configuration \
  --scan-type ENHANCED \
  --rules '[{
    "scanFrequency": "CONTINUOUS_SCAN",
    "repositoryFilters":[{"filter":"prod-*","filterType":"WILDCARD"}]
  },{
    "scanFrequency": "SCAN_ON_PUSH",
    "repositoryFilters":[{"filter":"dev-*","filterType":"WILDCARD"}]
  }]'

Inspectorとの統合とSecurity Hubでの集約

スキャンが必要な各アカウントとリージョンでAmazon Inspectorを有効にする必要があります。AWS Organizationsのセットアップでは、セキュリティツールアカウントがInspectorの委任管理者として指定されます。これにより、スキャンの有効化、新しいメンバーアカウントの自動登録設定、集約された検出結果の表示が可能になります。委任を忘れたり、自動登録の切り替えを忘れたりすると、検知しにくい障害モードに陥ります。組織に参加した新しいアカウントが、スキャンされることのないコンテナをECRにサイレントにプッシュしてしまい、エラーとして表面化することなくカバレッジの保証が破られてしまいます。

両方のサービスが有効で、Security HubのInspector統合がオンになっている場合、Inspectorの検出結果は自動的にAWS Security Hubに送られます。Security Hubは、検出結果をAWSセキュリティ検出フォーマット（ASFF）に正規化し、GuardDuty、Macie、Configの検出結果と関連付けます。そして、Security Hubの委任管理者とクロスリージョン集約を組み合わせることで、単一の画面で表示します。Security Hubの検出結果に対するEventBridgeルールにより、重大なCVEをLambdaにルーティングしてチケットを自動作成したり、問題のあるイメージにquarantine=trueラベルを付けたり、パイプラインゲートを介してデプロイをブロックしたりできます。

一元化されたスキャンとクロスアカウントCI/CD

マルチアカウントのコンテナワークロードで推奨されるパターンは、強化された中央レジストリアカウントを中核に置くことです。

中央アカウント: KMSで暗号化されたECRリポジトリをホストし、拡張スキャン、イミュータブルタグ、イメージ署名（AWS Signerと統合されたNotation/Sigstore経由）を設定します。
ビルドアカウント: CodeBuild/CodePipelineジョブを実行し、ビルド、中央ECRへのプッシュ、Inspectorの検出結果の待機、および重要度しきい値に基づくゲート処理を行います。
ワークロードアカウント（dev/stage/prod）: クロスアカウント権限を介して中央レジストリからイメージをプルします。

クロスアカウントの読み取りアクセスには2つのレイヤーが必要です。コンシューマーアカウント側でecr:GetDownloadUrlForLayer、ecr:BatchGetImage、ecr:GetAuthorizationTokenを許可するIAMポリシーと、中央アカウントのECRリポジトリ側で特定のコンシューマーアカウントまたはロールを許可するリポジトリポリシーです。

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowProdPull",
    "Effect": "Allow",
    "Principal": {"AWS":"arn:aws:iam::444455556666:role/EcsTaskExecutionRole"},
    "Action": ["ecr:BatchGetImage","ecr:GetDownloadUrlForLayer"]
  }]
}

ECRリポジトリポリシーはリソースベースであるため、アイデンティティポリシーとリソースポリシーの組み合わせによってアクセスが決定されます。どちらかのレイヤーが欠けているとAccessDeniedExceptionが発生します。KMSが関与する場合、KMSキーポリシーもクロスアカウントのプリンシパルにkms:Decryptを許可する必要があります。

EKSコントロールプレーンのロギングと可観測性

EKSでは、マネージドコントロールプレーンに直接アクセスできないため、セキュリティ関連のKubernetesイベントは、コントロールプレーンログを明示的に有効にした場合にのみ公開されます。利用可能なログタイプはapi、audit、authenticator、controllerManager、schedulerの5つです。auditログは最も価値の高いセキュリティアーティファクトです。IAMオーセンティケーターを介して解決された呼び出し元アイデンティティとともに、クラスターへのすべてのAPIコールを記録します。また、authenticatorログはIAMからKubernetes RBACへのマッピング決定を記録します。すべてのタイプは、/aws/eks/<cluster>/clusterロググループ内のCloudWatch Logsにストリーミングされ、そこからKinesis Data Firehoseにサブスクライブしたり、S3に転送したり、SIEMに送信したりできます。

aws eks update-cluster-config --name prod-cluster \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator",
  "controllerManager","scheduler"],"enabled":true}]}'

コントロールプレーンログをGuardDuty EKS Protection（ノードでのランタイム脅威検出）で補完し、ノードインスタンスプロファイルではなくIRSA (IAM Roles for Service Accounts) を使用することで、監査ログがAWS APIアクティビティを特定のポッドに帰属させることができます。

よくある落とし穴

プッシュ時のスキャンのみに依存する: 基本的なプッシュ時のスキャンは、プッシュ時に既知の脆弱性を検出しますが、レジストリに既にあるイメージに対して後から公開されるCVEには何も対処しません。PCI DSSやFedRAMPなどの監査フレームワークでは、継続的な脆弱性評価が求められており、そのためにはCONTINUOUS_SCAN頻度での拡張スキャンとSecurity Hubでの集約が必須です。プッシュごとのスナップショットでは、この統制要件を満たせません。

保管時の暗号化が必須な場合にECRでKMSを省略する: デフォルトのAES-256暗号化は本物の暗号化ですが、カスタマー管理型のキー、キーローテーションの記録、プリンシパルごとのkms:Decrypt監査証跡を要求するコンプライアンス体制は、AWS所有のキーでは満たせません。暗号化タイプはリポジトリごとに不変であるため、これは作成時に対応する必要があります。「後で有効にする」ことは、リポジトリを再作成しない限り不可能です。

Inspectorの委任管理者や自動登録を忘れる: Inspectorの委任管理者を設定しないと、各アカウントの所有者が個別にスキャンを有効化し、検出結果を転送する必要があり、これは運用上非現実的でカバレッジにギャップが生じます。新しいメンバーアカウントに対する自動有効化を行わないと、Control TowerやOrganizations経由で作成された新しいアカウントはすべてInspectorが無効な状態で開始されるため、中央アカウントのSecurity Hubに検出結果が表示されなくても、そのECRイメージはスキャンされません。これは明らかなエラーではなく、サイレントな偽陰性（見逃し）となります。

実践的な問題：ユースケースシナリオ

シナリオ: Meridian Financialは、本番環境のEKSクラスター、ECSサービス、そして本番、開発、専用のセキュリティアカウントにまたがる複数のECRレジストリを持つ、マルチアカウントのAWS環境を運用しています。エンジニアリングチームはCI/CDパイプライン経由でコンテナイメージをECRにプッシュしてEKS/ECSにデプロイし、セキュリティチームはモニタリングとコンプライアンスのための中央集権的なアカウントを維持しています。

課題: 最近のデプロイで、重大度の高い脆弱性を持つコンテナが本番投入前に検出されずにリリースされてしまいました。調査担当者は、EKSコントロールプレーンのログが限定的で、スキャン結果がアカウント間で断片化していることを発見し、修正が遅れました。

推奨アプローチ:

ECRリポジトリレベルの保護を有効化する: イメージタグの不変性（Immutability）を強制し、特定のIAMロールによるプッシュ/プルを制限するリポジトリポリシーを適用し、専用のAWS KMSカスタマー管理キー（CMK）でリポジトリを保管時に暗号化します。
プッシュ時のイメージスキャン（基本）をオンにし、ECRに対してAmazon Inspectorの拡張イメージスキャンを有効にして脆弱性の検出結果を生成します。アカウント全体の重大度を中央で集約するために、InspectorをAWS Security Hubと統合します。
中央集権的なクロスアカウントスキャンを実装する: ECRレプリケーションを設定するか、セキュリティアカウントのCodeBuild/CodePipelineロールにクロスアカウントのプル権限を付与し、セキュリティアカウントがすべてのイメージをInspectorおよび追加のSCA/DASTツールでスキャンできるようにします。アーティファクトはセキュリティアカウントのCMKで暗号化された中央のS3バケットに保存します。
CI/CDでのゲーティングを強制する: Inspector/Security Hubの検出結果をクエリするパイプラインスキャンステージ（STSのassume-roleを使用するCodeBuild/CodePipelineまたはGitHub Actions）を追加し、重大/クリティカルな検出結果があるイメージを自動的にブロックするか、承認を要求するようにします。
EKSの可観測性を向上させる: EKSコントロールプレーンのログ（API, Audit, Authenticator, ControllerManager, Scheduler）を有効にし、中央のロギングアカウントのCloudWatch Logsに送信します。EKS APIイベントに対してCloudTrailを有効にし、ランタイムモニタリングにはContainer InsightsとGuardDutyを使用します。

論理的根拠: このアプローチは多層防御を適用します。レジストリの暗号化と保護、Inspectorによる拡張スキャンの自動化、一貫したポリシー適用のためのSecurity Hubでの検出結果の中央集約、CI/CDでのデプロイのゲーティング、そして迅速な検知とフォレンジックのためのEKSコントロールプレーンログの有効化は、AWSの最小権限および中央集権モニタリングのベストプラクティスに沿ったものです。

← 脆弱性、パッチ、ホストセキュリティ · すべてのドメイン · インシデント対応とフォレンジック →

これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →

Pass the whole exam — not just this question

You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.

試験に合格する →

Amazonを閲覧 →

Amazon SCS-C02: コンテナとサーバーレスセキュリティ — 学習ガイド

SSHを使わないECS Execとランタイム調査

EC2上のコンテナからのIMDSアクセスをブロックする

GuardDuty Runtime Monitoring、EKS Protection、およびコントロールプレーンログ

ECR拡張スキャンによるイメージスキャン

実践的な問題：ユースケースシナリオ

Lambda：オーソライザー、シークレット、実行ロール

ECRの暗号化とリポジトリ保護

イメージスキャン: 基本、拡張、Inspector

Inspectorとの統合とSecurity Hubでの集約

一元化されたスキャンとクロスアカウントCI/CD

EKSコントロールプレーンのロギングと可観測性

よくある落とし穴

実践的な問題：ユースケースシナリオ

Pass the whole exam — not just this question

Related guides

1つのサブスクリプション。すべての試験。