【無料】AWS SCS-C03練習問題10問｜図解解説付き｜Udemy講師作成

正解：D

A. 既存の ECR リポジトリの設定を編集して KMS 暗号化を有効化 する。 さらに、Amazon GuardDuty の Runtime Monitoring を有効化 し、ノード上のエージェントでコンテナの実行時の挙動を監視 する。

不正解 ECR リポジトリの暗号化設定はリポジトリの作成時に決まり、作成後に変更することはできないため、この時点で1つ目の要件を満たせません。また GuardDuty の Runtime Monitoring は、稼働中のコンテナやノードのプロセス・ネットワークの挙動から不審な活動を検出する機能であり、イメージに含まれるパッケージを CVE と照合する脆弱性スキャンではありません。どちらの要件も満たせない選択肢です。

B. 既存の ECR リポジトリの設定を編集して KMS 暗号化を有効化 する。 さらに、AWS Config のマネージドルール でコンテナイメージを 既知の CVE と照合して評価 する。

不正解 既存リポジトリの暗号化設定は変更できないため、前提の時点で1つ目の要件を満たせません。また AWS Config は AWS リソースの設定項目を記録し、ルールで望ましい設定かどうかを評価するサービスです。リポジトリでスキャンが有効になっているかといった設定の評価はできますが、イメージ内のパッケージを CVE と照合して脆弱性そのものを検出する機能は提供していません。

C. KMS 暗号化を有効化した新しい ECR リポジトリ を作成する。 さらに、AWS Systems Manager Patch Manager でノードグループのインスタンスに パッチベースラインを適用 する。

不正解 カスタマー管理の KMS キーを指定した新規リポジトリを作成する点は適切ですが、Patch Manager が対象とするのはマネージドノードのオペレーティングシステムやアプリケーションのパッチ適用であり、レジストリに格納されたコンテナイメージの中身を検査するものではありません。イメージに含まれる CVE を把握する手段が用意されていないため、2つ目の要件を満たせません。

D. KMS 暗号化を有効化した新しい ECR リポジトリ を作成し、既存のイメージをそこへ移行 する。 新しいリポジトリでは プッシュ時の自動スキャン（ベーシックスキャン）を有効化 する。

正解 ECR の暗号化設定は作成時にのみ指定できるため、カスタマー管理の KMS キーを指定した新しいリポジトリを作成し、そこへイメージを移行するのが正しい手順です。あわせて ECR のイメージスキャンを有効化しておけば、リポジトリにプッシュされたイメージが自動的にスキャンされ、CVE の検出結果をコンソールや API から確認できます。追加のエージェントや独自の仕組みを用意することなく、暗号化と CVE の把握という2つの要件を満たせます。

全体的な説明

問われている要件

• ECR のプライベートリポジトリをカスタマー管理の KMS キーで暗号化すること
• コンテナイメージに含まれる既知の CVE を把握できるようにすること
• ECR の暗号化設定がリポジトリ作成時にのみ決まるという制約を理解していること
• 脆弱性の検出をどのサービス・機能が担うのかを正しく区別できること

前提知識

Amazon ECR の保管時暗号化について

• ECR は既定でも Amazon S3 のサーバー側暗号化によりイメージを暗号化しますが、リポジトリ単位で AWS KMS キーを使用した暗号化（SSE-KMS）を選択することもできます。KMS キーはリポジトリと同じリージョンに存在する必要があります。
• 暗号化設定はリポジトリの作成時に決まり、作成後に変更することはできません。既存リポジトリを KMS 暗号化に切り替えるには、新しいリポジトリを作成してイメージを移行します。

ECR のイメージスキャンについて

• ベーシックスキャンは AWS ネイティブ技術により 50 を超えるデータフィードから情報を取り込み、幅広い OS のパッケージについて CVE の検出結果を生成する機能です。プッシュ時の自動スキャンまたは手動スキャンを設定でき、結果はコンソールや AWS CLI から参照できます。
• 拡張スキャンは Amazon Inspector との統合機能で、OS パッケージに加えてプログラミング言語パッケージの脆弱性も継続的に検出します。

GuardDuty Runtime Monitoring について

• EKS のノードや ECS タスク、EC2 インスタンスにエージェントを配置し、プロセスの起動やネットワーク接続といった実行時の挙動から不審な活動を検出する機能です。イメージに含まれる脆弱性を洗い出す用途のものではありません。

AWS Systems Manager Patch Manager / AWS Config について

• Patch Manager はマネージドノードの OS・アプリケーションへのパッチ適用を自動化する機能で、対象はインスタンスであってレジストリ内のイメージではありません。
• AWS Config はリソースの設定を記録して望ましい状態かを評価するサービスで、脆弱性スキャンそのものは行いません。

図による解説

アーキテクチャ図

保管時の暗号化と CVE の把握を、1つのリポジトリに対して別々の経路で同時に成立させています。カスタマー管理キーを持つ AWS KMS は②で新規プライベートリポジトリの暗号化を担い、CI パイプラインが①でプッシュしたイメージはそのキーで保管されます。同じプッシュを契機に③の自動スキャンが走り、ECR ベーシックスキャンが⑤でスキャン結果を生成して、コンソールから CVE を確認できる状態になります。Amazon EKS のマネージドノードグループは④でイメージを取得する側にすぎません。ここを取り違えて EKS のノードにエージェントやパッチ適用の仕組みを足しても、それは④より先の実行環境を見る対策であり、③の位置にある静的なイメージ検査の代わりにはならないため、CVE を把握する要件は満たせません。

解くための考え方

まず1つ目の要件である KMS 暗号化から検討します。ECR リポジトリの暗号化設定は作成時に決まり後から変更できないという制約があるため、「既存のリポジトリの設定を編集して KMS 暗号化を有効化する」と述べている選択肢は、その時点で実現不可能と判断して除外できます。この制約を知っているかどうかが最初の分岐点です。 残った選択肢はいずれも KMS 暗号化を指定した新しいリポジトリを作成しており、1つ目の要件を満たします。 次に2つ目の要件である CVE の把握を検討します。ECR にはイメージスキャン機能が組み込まれており、プッシュ時の自動スキャンを有効化すればイメージが自動的に検査され、検出結果をコンソールや API で確認できます。追加のインフラやエージェントは不要です。 一方、Patch Manager が扱うのはノードの OS に適用するパッチであり、レジストリに置かれたイメージの中身は検査対象外です。GuardDuty の Runtime Monitoring は稼働中のコンテナの挙動を見る機能で、静的なイメージの脆弱性を洗い出すものではありません。AWS Config も設定の評価にとどまり、CVE の照合は行いません。いずれも検出の対象そのものが要件とずれています。 したがって、KMS 暗号化を指定した新規リポジトリを作成し、プッシュ時の自動スキャンを有効化して以降のスキャン結果を確認するという組み合わせだけが、両方の要件を過不足なく満たします。

参考資料

• Amazon ECR の保管時の暗号化
• Amazon ECR のイメージスキャン
• Amazon ECR のベーシックスキャン
• GuardDuty Runtime Monitoring

正解：A

A. Amazon S3 の操作だけを許可範囲とする IAM パーミッションバウンダリー（Permissions Boundary） を用意 する。 委託先の IAM ユーザーに、権限の上限としてこのバウンダリーを設定 する。

正解 パーミッションバウンダリー（アクセス許可の境界）は、IAM ユーザーまたはロールが持ち得る最大権限を定義する仕組みです。実際に許可される操作は、アイデンティティベースポリシーとバウンダリーの両方で許可された範囲（論理積）に限定されます。すでにアタッチされている S3 許可のポリシーが実際の権限を与え、バウンダリーはその範囲を S3 に閉じ込める役割を担います。そのため、IAM グループへの追加によって他の AWS サービスへの許可が付与されても、それ以外の操作は実行できません。要件を正確に満たす解決策です。

B. 対象のバケットに S3 バケットポリシー を設定し、委託先の IAM ユーザーの ARN だけにアクセスを許可 する。 同じポリシーで それ以外のプリンシパルからのアクセスを明示的に拒否 する。

不正解 バケットポリシーは特定の S3 バケットに付けるリソースベースポリシーで、そのバケットに誰がアクセスできるかを制御します。制御が及ぶ範囲は対象のバケットに閉じており、委託先の IAM ユーザーが AWS Lambda や Amazon DynamoDB などに対して持つ権限には一切影響しません。ユーザーが別の IAM グループに追加されれば、そのグループのポリシーで許可された他サービスの操作はそのまま実行できるため、要件を満たしません。

C. IAM Access Analyzer のポリシー生成機能 を使用し、Amazon S3 の操作だけを許可するポリシーを作成 する。 生成したポリシーを 委託先の IAM ユーザーに直接アタッチ する。

不正解 IAM Access Analyzer のポリシー生成は、CloudTrail に記録された実際の操作履歴から必要最小限のアイデンティティベースポリシーを作り出す機能で、S3 の操作だけを許可するポリシーを用意すること自体は可能です。しかしこのポリシーは権限を「追加」するものであり、ユーザーが後から IAM グループに追加されると、そのグループにアタッチされたポリシーの権限も合わさって有効になります。グループ経由の権限拡大を止める仕組みがないため、要件を満たしません。

D. AWS CloudTrail と Amazon EventBridge で iam:AddUserToGroup の実行を検知 する。 検知をトリガーに AWS Lambda 関数を実行し、委託先の IAM ユーザーをグループから除外 する。

不正解 グループへの追加を検知して自動的に除外する構成は、逸脱が起きた後に元の状態へ戻す事後的な是正であり、権限の上限を定める仕組みではありません。イベントの記録から Lambda 関数の実行までには時間差があり、その間はグループ経由で付与された他サービスの権限が有効な状態になります。付与そのものを無効化できないため、要件を満たしません。

全体的な説明

問われている要件

• 委託先の IAM ユーザーに Amazon S3 コンソールへのアクセスのみを許可すること
• S3 以外の AWS サービスへのアクセスを一切禁止すること
• IAM グループに追加されても、グループ経由で付与された追加の権限が有効にならないこと
• 権限を「付与」する仕組みではなく、権限の「上限」を設定できる仕組みを選ぶこと

前提知識

IAM ポリシーの種類について

• アイデンティティベースポリシーは、IAM ユーザー・グループ・ロールにアタッチして権限を付与する JSON 形式のポリシーで、複数のエンティティで再利用できるマネージドポリシーと、特定のエンティティに直接埋め込むインラインポリシーがあります。
• IAM Access Analyzer のポリシー生成機能は、CloudTrail の操作履歴から必要な権限だけを含むポリシーを作成する機能です。生成されるのはアイデンティティベースポリシーであり、いずれも権限を「追加」するもので、他のポリシーによる権限の拡大を防ぐ効果はありません。
• リソースベースポリシー（S3 のバケットポリシーなど）は、対象のリソースに付けて誰からのアクセスを許可するかを定めるものです。効果はそのリソースに閉じており、プリンシパルが他のサービスに対して持つ権限は制御できません。

パーミッションバウンダリー（アクセス許可の境界）について

• IAM ユーザーまたはロールに設定でき、そのエンティティが持ち得る最大権限を定義する機能です。実際の有効な権限は、アイデンティティベースポリシーとバウンダリーの両方で許可された操作（論理積）に限定されます。
• グループを通じて追加のポリシーが適用されても、バウンダリーで許可されていない操作は実行できません。なお、バウンダリー自体は権限を付与しない点に注意が必要です。

例えば、以下のようなパーミッションバウンダリーを設定すると、IAM ユーザーは Amazon S3 以外の AWS サービスにアクセスできなくなります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "*"
    }
  ]
}

この設定では、Amazon S3 の操作のみが明示的に Allow されています。Permissions Boundary においては、明示的に Allow されていないアクションは暗黙的に Deny されるため、S3 以外の AWS サービスへのアクセスは自動的にブロックされます。

そのため、委託先の IAM ユーザーが IAM グループに追加され、グループポリシーで Lambda や DynamoDB などの追加権限が付与されたとしても、Permissions Boundary との論理積評価により、実際に実行できる操作は S3 のみに留まります。

図による解説

アーキテクチャ図

委託先ユーザーへ権限が届く経路が直接の適用とグループ経由に分かれても、両方が Permissions Boundary という同じ関門を必ず通る構成になっています。IAM User には Boundary 適用としてバウンダリーが直接効き、グループに追加された場合は IAM Group の追加ポリシーが他サービスへの許可を試行しますが、いずれも S3 アクセスのみ許可のバウンダリーで評価され、S3 のみ通過の経路だけが Amazon S3 のコンソール操作へ届き、Lambda・DynamoDB・RDS へ向かう経路は他はブロックとして断たれます。バウンダリーは上限を定めるだけで、権限そのものは与えません。アタッチ済みの S3 許可ポリシーを外すと、上限だけが残って何も実行できなくなります。

アーキテクチャ図

有効な権限は付与側の足し合わせではなく、付与されたポリシーと Permissions Boundary の論理積で決まります。付与されたポリシーの枠には、ユーザーにアタッチ済みの直接アタッチと、Lambda・DynamoDB・RDS 等への追加権限を含むグループポリシーが並び、権限付与と付与を試行として IAM 権限評価エンジンへ入ります。そこへ上限で制約として S3 アクセスのみ許可のバウンダリーが加わり、両方で許可された操作だけが論理積の結果として有効な権限に残るため、出力は S3 アクセスのみになります。付与側をどれだけ広げても出力が変わらない点が要件と一致します。逆にバウンダリーだけを設定して付与側に S3 の許可がなければ、論理積は空になり S3 すら操作できません。

解くための考え方

S3 の操作を許可するポリシーはすでにアタッチされているため、残る論点は「IAM グループに追加されても」他の AWS サービスにアクセスできないようにする方法です。ここでは、通常のポリシーによる権限の付与と、権限の上限を設定する仕組みの違いを理解しているかが問われています。 Access Analyzer で生成したポリシーを直接アタッチする方法は、必要な権限を絞り込む点では有効ですが、権限を追加する仕組みにすぎません。ユーザーが後から別のグループに追加されれば、そのグループのポリシーで許可された操作がそのまま有効になります。 バケットポリシーで委託先のユーザーだけを許可する方法は、効果が対象のバケットに閉じており、他の AWS サービスに対する権限にはまったく作用しません。グループへの追加を検知して自動的に除外する方法も、逸脱が起きた後に元へ戻す是正であって、検知から是正までの間は追加された権限が有効なままです。どちらも上限を定める仕組みにはなりません。 これに対してパーミッションバウンダリーは、IAM ユーザーが持ち得る権限の上限を定義する機能です。有効な権限はアイデンティティベースポリシーとバウンダリーの論理積で決まるため、バウンダリーで S3 のみを許可しておけば、グループ経由で Lambda や DynamoDB への許可が追加されても、実際に実行できるのは S3 の操作だけに留まります。 「どのようなポリシーが追加されても超えられない上限」という性質が要件と正確に一致するため、S3 のみを許可するバウンダリーを委託先の IAM ユーザーに設定する方法が正解となります。

参考資料

• AWS IAM パーミッションバウンダリーの概要
• IAM ポリシーの評価論理
• IAM Access Analyzer のポリシー生成
• アイデンティティベースポリシーとリソースベースポリシー

正解：B

A. AWS CloudFormation テンプレートを用意 し、各メンバーアカウントで実行して証跡を個別に作成 する。 作成した証跡は 中央の S3 バケットにログを配信 するように設定する。

不正解 テンプレートを各アカウントで実行して証跡を作成すれば、既存アカウントについては要件を満たせます。しかし新しいアカウントが組織に追加されるたびに同じ作業を実施しなければならず、設定漏れや配信先の指定ミスが発生します。メンバーアカウント側のユーザーが作成された証跡を停止・削除できてしまう点も含め、今後追加されるアカウントを自動的に記録対象にするという要件を満たせません。

B. Organizations の管理アカウントで既存の証跡を編集し、組織内のすべてのアカウントに適用 する。 この証跡の配信先として 中央の S3 バケットを指定 し、管理アカウントから設定を反映 する。

正解 AWS Organizations の管理アカウント（または委任された管理者アカウント）で既存の証跡を組織の証跡として設定すると、組織内の全メンバーアカウントのイベントが指定した中央の S3 バケットに記録されます。組織に新しいアカウントが追加されると自動的に記録対象となり、メンバーアカウント側のユーザーは組織の証跡を停止・削除できません。既存アカウントへの適用と新規アカウントへの自動適用の両方を最小の運用負荷で満たせる、最も適切な解決策です。

C. 管理アカウントで 新しい証跡を作成 し、中央の S3 バケットにログを配信するように設定する。 また、AWS Config のマネージドルール で各アカウントの CloudTrail の有効化状況を評価し、非準拠を検出したら通知 する。

不正解 管理アカウントで作成しただけの証跡は、そのアカウントで発生したイベントしか記録せず、他のメンバーアカウントには適用されません。また AWS Config のマネージドルールによる評価は、証跡が有効になっていないアカウントを可視化する検出的統制であり、非準拠を通知するだけで CloudTrail を有効化するわけではありません。2つの要件のいずれも満たせません。

D. サービスコントロールポリシー（SCP）を作成 し、cloudtrail:StopLogging および cloudtrail:DeleteTrail のアクションを拒否する。 この SCP を 組織内のすべての OU に適用 する。

不正解 証跡の停止や削除を拒否する SCP は、すでに有効になっている CloudTrail をメンバーアカウントのユーザーが無効化することを防ぐ予防的統制として有効です。しかし SCP はメンバーアカウント内で行使できる権限の上限を定めるガードレールであり、CloudTrail を新たに有効化する機能はありません。証跡が存在しないアカウントには何の効果もないため、要件を満たしません。

全体的な説明

問われている要件

• 既存の全メンバーアカウントの API イベントを中央の S3 バケットに集約すること
• 今後追加されるアカウントにも個別作業なしで適用されること
• 各アカウントでの個別設定や独自の配布の仕組みに頼らず、確実で運用負荷の低い方法であること
• 「無効化を防ぐ」統制と「有効化を強制する」仕組みの違いを区別できること

前提知識

AWS CloudTrail について

• AWS アカウント内の API コールをイベントとして記録する監査サービスです。証跡を作成するとイベントを S3 バケットに継続的に配信でき、Amazon EventBridge や CloudWatch Logs とも統合できます。

組織の証跡（Organization Trail）について

• AWS Organizations の管理アカウントまたは委任された管理者が証跡を「組織内の全アカウントに適用」として設定すると、全メンバーアカウントのイベントが単一の S3 バケットに集約されます。
• 組織に新規アカウントが追加されると自動的に記録対象となり、メンバーアカウントのユーザーは組織の証跡を停止・削除できません。既存の証跡を編集して組織の証跡に変更することもできます。
• メンバーアカウントのユーザーは、自アカウントの CloudTrail コンソールで組織の証跡を表示し、自アカウントで発生したイベントを参照できます。表示はできても設定の変更・停止・削除ができない点が、各アカウントで個別に作成した証跡との違いです。

サービスコントロールポリシー（SCP）について

• AWS Organizations のポリシーで、メンバーアカウント内の IAM ユーザー・ロールが行使できる権限の上限を定義します。管理アカウントには適用されません。
• 特定のアクションを拒否する予防的統制には有効ですが、何かを「実行させる」「有効化する」機能はありません。

AWS Config について

• リソースの設定を記録し、ルールに照らして準拠状況を評価するサービスです。証跡が有効かどうかを評価して非準拠を可視化できますが、評価そのものが設定を作り出すわけではありません。

図による解説

アーキテクチャ図

設定の起点が管理アカウントの 1 か所だけで、適用先が既存のアカウントと将来のアカウントの両方へ自動的に広がることが分かれ目です。管理アカウントから伸びる操作は「組織の証跡を設定」の 1 本だけで、その先の AWS CloudTrail から既存メンバーアカウント 1 と 2 へ「既存に自動適用」「追加設定は不要」の経路が、新規メンバーアカウントへ「新規に自動適用」の経路が分かれ、記録されたイベントは「ログを集約送信」で Amazon S3 の中央ログバケットへ集まります。新規側は参加した時点で CloudTrail が即時有効になり、メンバー側の作業は発生しません。ここを取り違えて管理アカウントに通常の証跡を作っただけだと、この分岐そのものが生まれず、集まるのは管理アカウント自身のイベントだけになります。

アーキテクチャ図

同じメンバーアカウントに働きかけていても、CloudTrail を有効化できるのは組織の証跡だけで、SCP が担えるのは停止・削除の禁止だけです。組織の証跡からは「証跡を有効化」の実線がメンバーアカウントへ届き、その結果としてメンバーアカウントは CloudTrail が有効な状態になり、停止・削除も制限されます。一方 SCP からメンバーアカウントへ届く線は「停止操作を拒否」だけで、もう一方は「有効化は不可」という赤い破線となって SCP の限界へ抜けます。SCP は権限の上限を定めるガードレールであり、記録を始めさせる力はありません。ここを混同して SCP だけを配ると、証跡がまだ作られていないアカウントには何の効果もなく、ログの欠落は残ったままになります。

解くための考え方

「既存アカウントへの適用」と「新規アカウントへの自動適用」という2つの要件を、1つの仕組みで満たす必要があります。 まず、管理アカウントで新しい証跡を作成する方法は、そのアカウントのイベントしか記録できず、他のメンバーアカウントには効果がありません。AWS Config のルールで有効化状況を評価して通知する構成も、設定されていないアカウントを見つけるための検出的統制であり、有効化を保証する仕組みではありません。 次に、CloudFormation テンプレートを各アカウントで実行して証跡を作る方法は、既存アカウントについては要件を満たしますが、新しいアカウントが追加されるたびに同じ作業が必要になり、実施漏れが起こります。メンバーアカウント側で証跡を停止・削除できてしまう点も残ります。 SCP で cloudtrail:StopLogging や cloudtrail:DeleteTrail を拒否する方法は、有効になっている CloudTrail を守る補完的な統制としては優れていますが、SCP は権限のガードレールであって、存在しない証跡を作成・有効化する力はありません。 これに対して、管理アカウントで既存の証跡を編集して組織の証跡に変更すれば、組織内の全メンバーアカウントのイベントが中央の S3 バケットに自動的に集約され、新規アカウントも組織に参加した時点で自動的に記録対象になります。さらにメンバーアカウント側では組織の証跡を停止・削除できないため、無効化への耐性も同時に得られます。両方の要件を一度に満たせるのは組織の証跡だけです。

参考資料

• AWS CloudTrail とは
• AWS Organizations の組織の証跡を作成する
• AWS Config ルール cloudtrail-enabled
• AWS Organizations の SCP（サービスコントロールポリシー）

正解：C

A. AWS Config の設定レコーダーを構成 し、CloudTrail、VPC フローログ、DNS ログ を評価対象に加えて分析する。

不正解 AWS Config は AWS リソースの設定項目を記録し、設定変更の履歴を残して、あらかじめ定義したルールに照らして準拠状況を評価するサービスです。セキュリティグループが過度に開放されているといった設定上の問題は把握できますが、フローログや DNS ログを取り込んで通信の内容から脅威を判定する機能は持ちません。検出の対象が設定に限られるため、要件を満たせません。

B. Amazon Detective を有効化 し、CloudTrail、VPC フローログ、DNS ログ を取り込んでアカウントとリソースの挙動を分析する。

不正解 Amazon Detective は CloudTrail や VPC フローログ、GuardDuty の検出結果を取り込み、リソースやアカウントの関係をグラフとして可視化するサービスです。役割はあくまで既存の検出結果や不審なアクティビティの根本原因を調査することにあり、継続的な脅威検出（検出結果の生成）は担いません。検出の起点となる仕組みが別途必要になるため、要件を満たせません。

C. 環境全体で Amazon GuardDuty を有効化 し、以降は CloudTrail イベント、VPC フローログ、DNS ログ の継続的な分析をサービス側に任せる。

正解 Amazon GuardDuty は、CloudTrail のイベント、VPC フローログ、DNS ログを基盤データソースとして継続的に取り込み、機械学習と脅威インテリジェンスによって異常なアクティビティをほぼリアルタイムで検出するマネージド型の脅威検出サービスです。悪意のあるドメインへの名前解決、インスタンスやネットワークインターフェースの異常な通信を自動的に検出でき、S3 保護を有効化すれば S3 に対する不審な API コールも検出できます。報告された兆候をすべてカバーし、有効化するだけで監視が始まります。

D. 収集した CloudTrail、VPC フローログ、Route 53 Resolver クエリログ を Amazon S3 に集約 し、Amazon Athena から SQL クエリを実行して兆候を洗い出す。

不正解 各種ログを S3 に集約して Athena でクエリする構成は、過去のログを横断的に調べる分析基盤としては有効で、監査や事後調査に向いています。しかし Athena は実行したクエリに対して結果を返すサービスであり、何を異常とみなすかの判断と、その判断を継続的に走らせる仕組みは利用者が用意することになります。ほぼリアルタイムでの継続的な検出という要件を満たせません。

全体的な説明

問われている要件

• 名前解決、インスタンスの通信、ネットワークインターフェースの通信量、S3 の API コールという複数種類の兆候を検出すること
• 環境全体を継続的に監視し、ほぼリアルタイムで検出すること
• さまざまなリソースで任意のタイミングに現れる兆候へ自動的に対応できること
• ログの「保存・照会」や設定の「評価」ではなく、ログの分析による脅威検出ができるサービスを選ぶこと

前提知識

Amazon GuardDuty について

• CloudTrail の管理イベント、VPC フローログ、DNS ログを基盤データソースとして自動的に分析するマネージド型脅威検出サービスです。これらのログを利用者側で有効化・保存していなくても、GuardDuty は独立したストリームから直接データを取得します。
• 機械学習、異常検出、脅威インテリジェンスにより、API アクセスの異常な試行、異常なネットワークアクティビティ、悪意のあるドメインへのアクセスなどをほぼリアルタイムで検出します。
• S3 保護を有効化すると CloudTrail の S3 データイベントを分析し、S3 に対する不審な API コールも検出できます。

Amazon Athena について

• S3 上のデータに対して標準 SQL でクエリを実行するサービスです。クエリを投げた時点の分析結果が得られるもので、常時稼働して異常を判定する仕組みではありません。

Amazon Detective について

• CloudTrail、VPC フローログ、GuardDuty の検出結果などを取り込み、関連するエンティティをグラフ化して調査を支援するサービスです。検出結果を自ら生成するのではなく、既に得られている検出結果の根本原因を追跡するために使います。

AWS Config について

• リソースの設定を記録し、ルールに照らして準拠状況を評価するサービスです。設定の逸脱は検出できますが、通信内容や API の振る舞いから脅威を判定するものではありません。

図による解説

アーキテクチャ図

報告された兆候の一つひとつが、どのデータに現れ、誰がそれを判定するのかが分かれます。API 操作の異常は AWS CloudTrail に（①）、インスタンスやネットワークインターフェイスの想定外の通信は VPC フローログに（②）、通常は使われないドメインへの名前解決は DNS ログに（③）、S3 への不審な API コールは S3 データイベントに（④）現れ、これらを Amazon GuardDuty が横断して取り込み、ほぼリアルタイムで検出結果を出力します。GuardDuty が読む DNS ログは独立したストリームで、Route 53 Resolver のクエリログ記録を有効化していなくても分析されます。同じログを扱えるという理由で分析基盤や調査支援のサービスを選ぶと、何を異常とみなす基準とそれを走らせる契機を自前で用意することになり、継続的な検出になりません。

解くための考え方

まず、報告された4種類の兆候がどのデータに現れるかを整理します。名前解決の異常は DNS のクエリ記録に、インスタンスやネットワークインターフェースの通信の異常は VPC フローログに、S3 への不審な API コールは CloudTrail のデータイベントに、それぞれ現れます。つまり、複数のデータを横断して継続的に分析し、異常かどうかを自動で判定できるサービスが必要です。 ログを S3 に集約して Athena でクエリする方法は、蓄積したログを調べる基盤としては優れていますが、判定の基準と実行のタイミングを利用者が用意する必要があり、継続的な検出にはなりません。 Amazon Detective は同じ種類のログを取り込みますが、目的は検出済みの事象を掘り下げる調査であり、脅威の検出そのものは担いません。AWS Config は設定の記録と評価が対象で、通信や API の振る舞いは扱いません。この2つは役割そのものが要件とずれています。 Amazon GuardDuty は、CloudTrail のイベント、VPC フローログ、DNS ログを基盤データソースとして自動的に取り込み、機械学習と脅威インテリジェンスで分析して、報告された兆候をすべて検出できます。利用者がログ基盤を構築・運用する必要がなく、有効化するだけで環境全体の継続的な監視が始まる点も「継続的に監視しほぼリアルタイムで検出する」という要件に合致します。したがって GuardDuty を有効化します。

参考資料

• Amazon GuardDuty とは
• GuardDuty の基盤データソース
• Amazon Detective とは
• Amazon Athena とは
• AWS Config とは

正解：D

A. 割り当て先アカウントの既存 IAM ポリシーとの 権限の競合を洗い出す。 競合を解消したうえで パーミッションセットを再プロビジョニング する。

不正解 権限の重複や競合を整理することは運用上は有用ですが、IAM の評価では複数のポリシーがアタッチされていてもそれらは統合して評価されるため、権限内容の競合がプロビジョニングのエラーを引き起こすわけではありません。この事象の原因は参照先のカスタマーマネージドポリシーがメンバーアカウントに存在しないことであり、権限内容を調整しても解消しません。

B. 管理アカウントで作成した カスタマーマネージドポリシーの ARN を確認 する。 その ARN をパーミッションセットに直接指定して 割り当て直す。

不正解 パーミッションセットが AWS マネージドポリシーを ARN で指定できるのに対し、カスタマーマネージドポリシーは名前とパスによる参照しか受け付けません。管理アカウントのポリシー ARN を指定して他アカウントのロールにアタッチさせる方法は用意されておらず、そもそも IAM のポリシーはアカウントをまたいでアタッチできません。参照先のポリシーを各アカウントに用意するという根本原因の解消にもなりません。

C. AWS マネージドポリシーとカスタマーマネージドポリシーを 別々のパーミッションセットに分割 する。 ユーザーには2つのパーミッションセットをそれぞれ割り当てる。

不正解 2つのポリシーを別々のパーミッションセットに分けても、カスタマーマネージドポリシーを参照するパーミッションセットである以上、割り当て先の各アカウントに同じ名前のポリシーが存在しなければプロビジョニングは失敗します。エラーの原因はポリシーの組み合わせ方ではなく、参照先のポリシーがメンバーアカウントに存在しないことであるため、この方法では解決しません。

D. パーミッションセットを割り当てる各アカウントに、同じ名前とパスのカスタマーマネージドポリシーを作成する。 その後、パーミッションセットを再プロビジョニングする。

正解 IAM Identity Center のパーミッションセットがカスタマーマネージドポリシーを参照する場合、ポリシー本体ではなく名前とパスだけが記録されます。そのため、割り当て先の各 AWS アカウントに同じ名前とパスのポリシーが事前に作成されている必要があります。AWS マネージドポリシーは AWS が全アカウントに提供するため参照できますが、カスタマーマネージドポリシーは作成したアカウント内にしか存在しません。各アカウントに同名のポリシーを用意することでエラーが解消されます。

全体的な説明

問われている要件

• IAM Identity Center のパーミッションセットにカスタマーマネージドポリシーを使う際の前提条件を理解していること
• プロビジョニング失敗の根本原因（参照先ポリシーの不存在）を特定できること
• AWS マネージドポリシーとカスタマーマネージドポリシーの管理単位・参照方法の違いを区別できること
• マルチアカウント環境で同一のポリシーを各アカウントへ行き渡らせる方法を理解していること

前提知識

IAM Identity Center とパーミッションセットについて

• IAM Identity Center は、AWS Organizations 配下の複数アカウントへのシングルサインオンとアクセス権限を一元管理するサービスです。
• パーミッションセットはアクセス権限のテンプレートで、ユーザーやグループにアカウント単位で割り当てると、IAM Identity Center が各アカウント内に IAM ロールを自動作成（プロビジョニング）し、指定されたポリシーをそのロールにアタッチします。

AWS マネージドポリシーとカスタマーマネージドポリシーについて

• AWS マネージドポリシーは AWS が作成・管理する共通ポリシーで、すべてのアカウントから同じ ARN で参照できます。パーミッションセットには ARN を指定してアタッチします。
• カスタマーマネージドポリシーは利用者が各アカウント内に作成する独自ポリシーで、作成したアカウントの中にしか存在しません。パーミッションセットへは名前とパスによる参照として登録します。
• 1 つのパーミッションセットにアタッチできる AWS マネージドポリシーとカスタマーマネージドポリシーは合計 251 個です。実務上の制約になるのはこの値ではなく、割り当て先の各アカウントで自動作成される IAM ロールにアタッチできる管理ポリシー数で、既定は 10 個、Service Quotas から最大 25 個まで引き上げを申請できます。

カスタマーマネージドポリシー利用時の前提条件について

• パーミッションセットはポリシー本文も ARN も保持せず名前とパスで参照するため、割り当て先の各アカウントに同じ名前・同じパスのポリシーが事前に存在している必要があります。存在しないアカウントへの割り当てはプロビジョニングエラーになります。
• 多数のアカウントへ同一ポリシーを配布する場合は、AWS CloudFormation StackSets などで一括作成すると名前や内容のずれを防げます。

図による解説

アーキテクチャ図

パーミッションセットがポリシーをどう参照するかによって、割り当て先アカウントに必要な準備が変わります。IAM Identity Center が割り当てを実行すると、メンバーアカウント 1 と 2 のそれぞれに、パーミッションセットを反映した IAM ロールが自動作成されます。AWS マネージドポリシーは ARN 参照なのでどのアカウントからも解決できますが、カスタマーマネージドポリシーは名前とパスによる参照であり、各アカウント内に同名・同パスのポリシーが事前に存在していなければロールへアタッチできません。この事前作成を省くと、参照先が見つからないアカウントでプロビジョニングが失敗します。ポリシーを分けても管理アカウントの ARN を指定しても、参照先が無いという事実は変わりません。

解くための考え方

プロビジョニングが失敗しています。パーミッションセットには AWS マネージドポリシーとカスタマーマネージドポリシーの両方がアタッチされています。AWS マネージドポリシーは AWS が全アカウント共通で提供しており、ARN を指定すればどのアカウントでも参照できるため、ここで失敗することはありません。一方、カスタマーマネージドポリシーはアカウント内に閉じたリソースであり、パーミッションセットは名前とパスだけを保持しています。IAM Identity Center は割り当て時に対象アカウント内で同じ名前とパスのポリシーを探し、自動作成した IAM ロールにアタッチしようとするため、そのポリシーが存在しなければプロビジョニングは失敗します。 この理解に基づくと、割り当て先の各アカウントに同じ名前とパスのポリシーを作成する対応だけが、原因を直接解消します。ポリシーを別々のパーミッションセットに分割する対応は、参照先が存在しないという事実に手を付けていないためエラーは続きます。権限の競合を解消する対応も、複数のポリシーは統合して評価されるためプロビジョニングの成否には影響しません。管理アカウントのポリシー ARN を指定する対応は、カスタマーマネージドポリシーが名前とパスでしか参照できないことに加え、IAM のポリシーがアカウントをまたいでアタッチできないという点でも成立しません。 なお、実務で多数のアカウントに同一ポリシーを配布する際は、CloudFormation StackSets を利用して一括作成・一括更新する構成にすると、アカウント間でポリシーの名前や内容がずれることを防げます。

参考資料

• 権限セットに IAM ポリシーを使用する
• AWS IAM Identity Center の権限セット
• AttachCustomerManagedPolicyReferenceToPermissionSet API
• IAM Identity Center のクォータと制限

正解：D

A. 値ごとに AWS Secrets Manager のシークレットを作成し、関数から取得 API で読み出す方式へ移行する。 実行ロールには、対象シークレットの取得だけを認めるポリシーを付与する。

不正解 AWS Secrets Manager は機密情報の保管に適したサービスで、暗号化保存ときめ細かなアクセス制御に加え、データベース認証情報などの自動ローテーションやクロスアカウント共有にも対応します。ただし有料サービスであり、シークレット 1 件につき月額 0.40USD、API リクエスト 10,000 回ごとに 0.05USD の料金が発生します。今回のようにローテーションを必要としない短い値を関数の数だけ登録すると、シークレットの件数と取得回数の両方で費用が積み上がります。暗号化とアクセス制御という要件そのものは満たすものの、同じ要件を追加料金なしで満たせる方式がある以上、最もコスト効率が良い方法とは言えません。

B. AWS CloudTrail で関数の設定を参照する操作を記録し、Amazon EventBridge のルールで想定外の参照を検知して通知する。

不正解 CloudTrail と EventBridge の組み合わせは、関数設定の参照操作を記録して通知する検知の仕組みにとどまります。機密情報が環境変数に平文で置かれている状態は変わらず、参照権限を持つ利用者は通知が届く前に値をそのまま読み取れます。値を暗号化されたストアへ移すという要件を満たしておらず、事後的な監視を追加するだけで根本対策にはなりません。

C. 機密情報を含む設定ファイルを AWS Lambda のレイヤーとして発行し、対象の関数にアタッチして実行時にファイルから読み込む方式へ移行する。 レイヤーの利用許可と IAM 権限を設定し、必要な Lambda 関数の実行ロールだけが該当するレイヤーバージョンを参照できるようにする。

不正解 Lambda のレイヤーは ZIP アーカイブを関数へ配布する仕組みであり、シークレットストアではありません。GetLayerVersion API はレイヤーアーカイブのダウンロード用リンクを返すため、レイヤーを参照できる利用者は中身をそのまま取得でき、暗号化された状態で保管して実行時にだけ復号するという制御はできません。値を変更するたびにレイヤーの再発行と各関数の設定更新が必要になる点でも、この規模の環境には適しません。

D. 値ごとに AWS Systems Manager Parameter Store の標準パラメータを SecureString 型で作成し、復号付きの取得 API で読み出す。 実行ロールには、対象パラメータの取得と復号だけを認めるポリシーを付与する。

正解 SecureString 型のパラメータは値を AWS KMS のキーで暗号化して保管し、WithDecryption を指定した取得 API に対して復号済みの値を返します。標準パラメータは 1 つのアカウント・リージョンあたり 10,000 件まで、値のサイズは 4KB まで扱え、保存も標準スループットでの取得も追加料金がかかりません。数十バイトの値を多数の関数から参照する今回の条件では、暗号化とアクセス制御を満たしたうえで費用が発生しない点が決め手になります。読み取りを許可する範囲はパラメータの ARN 単位で指定できるため、必要な関数の実行ロールだけに限定できます。

全体的な説明

問われている要件

• 環境変数に平文で置かれた API トークンや署名キーを、暗号化された仕組みで安全に管理し直すこと
• 3,000 を超える Lambda 関数という規模でも最もコスト効率の良い方法を選ぶこと
• 機密情報へのアクセスを必要な Lambda 関数だけに制限できること
• 保存する値が数十バイト程度の短い文字列であり、ローテーションは求められていないこと

前提知識

Lambda 環境変数のリスクについて

• Lambda の環境変数は保存時に AWS KMS で暗号化されますが、参照権限（lambda:GetFunctionConfiguration など）を持つユーザーにはコンソールや API で復号された平文の値が表示されます。
• API トークンや署名キーを環境変数に直接保存すると、権限を持つ全員に値が見えるうえ、多数の関数に散在した値の更新も困難になります。

AWS Systems Manager Parameter Store について

• 設定値や機密情報を階層構造の名前で一元管理できるストアです。標準パラメータは 1 つのアカウント・リージョンあたり 10,000 件、値のサイズ 4KB までを追加料金なしで利用でき、8KB まで扱えるアドバンストパラメータは有料です。
• セキュアストリング型のパラメータは KMS のキーで暗号化され、取得時に復号オプション（WithDecryption）を指定すると復号済みの値を受け取れます。

AWS Secrets Manager について

• パスワードやデータベース認証情報などのシークレット管理に特化したサービスで、Lambda と連携したシークレットの自動ローテーションやクロスアカウント共有をサポートします。
• シークレット単位・API リクエスト単位で課金される有料サービスであり、ローテーションが不要な小さい値を大量に管理する用途ではコスト面で不利になります。

Lambda レイヤーの位置付けについて

• レイヤーはライブラリや共通コードを ZIP アーカイブとして複数の関数へ配布する仕組みで、GetLayerVersion API はアーカイブのダウンロード用リンクを返します。暗号化した状態で保管して実行時に復号するといったシークレット管理の機能は持ちません。

IAM によるアクセス制御について

• ssm:GetParameter アクションをパラメータの ARN 単位で許可することで、必要な Lambda 関数の実行ロールだけに特定パラメータの読み取りを絞り込めます。セキュアストリングの復号には kms:Decrypt 権限も必要です。
• AWS Parameters and Secrets Lambda Extension を使うと、取得した値を関数内にキャッシュして API 呼び出し回数を削減できます。

図による解説

アーキテクチャ図

機密情報を関数の設定から切り離し、実行時に取りに行く形へ置き換えています。3,000 を超える Lambda Function は環境変数に機密情報を持たず、API トークンや署名キーは SSM Parameter Store へ SecureString タイプで格納され、AWS KMS のキーで暗号化されたまま保管されます。関数は実行時に GetParameter 要求を出し、Parameter Store から KMS へ復号要求が渡って復号済みの値が返ります。値を取り出せるのは ssm:GetParameter を最小権限で与えられた実行ロールだけで、関数設定の参照権限しか持たない利用者からは見えません。環境変数のまま守ろうとすると、保存時に暗号化されていてもコンソールには平文が表示されてしまいます。

解くための考え方

方向性としては、環境変数に平文で置かれた機密情報を暗号化された専用のストアへ移し、実行時に取得する構成へ変えます。CloudTrail と EventBridge で参照操作を検知する案は、平文の値が関数の設定に残ったままで、読み取り自体を防げないため根本対策になりません。レイヤーに設定ファイルを同梱する案も、レイヤーは配布の仕組みであって暗号化保管とアクセス時の復号を担うものではないため、要件を満たしません。残るのは Secrets Manager と Parameter Store の比較で、どちらも KMS による暗号化と IAM によるアクセス制御という要件は満たせます。ここで決め手になるのが「3,000 を超える関数」「数十バイトの短い値」「ローテーションは不要」「最もコスト効率の良い方法」という条件です。Secrets Manager は自動ローテーションなどの高機能を備える分、シークレット数と API リクエスト数に応じた料金が発生し、この規模ではコストが積み上がります。一方、Parameter Store の標準パラメータは追加料金なしで利用でき、セキュアストリングを使えば KMS 暗号化の要件も満たせるため、コスト面で明確に優位です。この条件では、機密情報をセキュアストリングとして Parameter Store に保存し、IAM ポリシーで必要な Lambda 関数だけにパラメータへのアクセスを許可します。データベース認証情報の定期的な自動ローテーションが求められる場合など、要件が変われば Secrets Manager が適切な選択になります。

参考資料

• AWS Systems Manager Parameter Store
• AWS Secrets Manager
• Lambda 環境変数
• レイヤーによる Lambda 依存関係の管理

正解：C

A. AWS Well-Architected Tool でセキュリティの柱のレビューを行い、提示された改善計画から対策を確認する。

不正解 AWS Well-Architected Tool は、ワークロードについての設問に回答していく形式でリスクを洗い出し、改善計画として提示する自己評価のためのツールです。得られる結果はアーキテクチャ全体の設計判断に対する定性的な指摘であり、個々のポリシードキュメントを読み込んで記述の妥当性を機械的に判定する仕組みは備えていません。レビューの過程で権限設計の考え方を見直すことはできますが、どの SCP のどの記述が誤っているかを特定して修正案を得るという要件には応えられないため、この用途には使えません。

B. AWS Security Hub の基礎セキュリティのベストプラクティス標準を有効化し、コントロールごとの評価結果を確認する。

不正解 AWS Security Hub のセキュリティ標準は、アカウント内のリソース設定が各コントロールの条件を満たしているかを自動判定し、検出結果とスコアの形で提示する仕組みです。判定の材料になるのは暗号化の有無やログの設定状況といったリソース側の状態で、複数アカウントの結果を集約して優先度を付ける用途に向いています。組織に適用されている SCP の JSON を読み取り、記述の誤りや広すぎる許可を指摘する検証は含まれないため、今回の洗い出しには使えません。

C. IAM Access Analyzer のポリシー検証を対象の SCP に対して実行し、返された指摘に沿って記述を直す。

正解 ポリシー検証はポリシータイプにサービスコントロールポリシーを指定でき、SCP のドキュメントそのものを解析対象にできます。結果はエラー、セキュリティ警告、警告、提案の 4 種類に分かれ、機能しない記述、広すぎる許可、推奨から外れた書き方が修正の手掛かりとともに返されます。判定の基準が AWS のポリシーベストプラクティスに置かれているため、返された指摘を順に反映していけば、記述の誤りの解消と基準への適合確認を同じ作業で進められます。

D. AWS Audit Manager で対象アカウントの評価を開始し、自動収集された証跡から準拠状況を確認する。

不正解 AWS Audit Manager は、SOC 2 や ISO 27001 などのコンプライアンスフレームワークに沿って AWS 利用状況の証跡を継続的に自動収集し、監査に提出するレポートを組み立てるサービスです。評価の単位はフレームワークが定めるコントロールであり、集めるのは設定やアクティビティの記録です。ポリシードキュメントの中身を読み取って記述の誤りや必要以上に広い許可を指摘する機能は持たないため、監査準備には役立っても、既存の SCP を洗い出して直すという今回の目的には結び付きません。

全体的な説明

問われている要件

• AWS Organizations の SCP を最適化できるツールを選ぶこと
• SCP が AWS のベストプラクティスに準拠していることを確認できること
• ポリシードキュメント自体を解析できるサービスと、リソースや環境をチェックするサービスを区別すること
• 各セキュリティ関連サービスの守備範囲を正しく理解していること

前提知識

AWS Organizations と SCP（サービスコントロールポリシー）について

• SCP は AWS Organizations の認可ポリシーの一種で、メンバーアカウント内の IAM ユーザー・ロールが利用できる権限の最大範囲（ガードレール）を定めます。SCP 自体は権限を付与せず、実際のアクセスには IAM ポリシー側の許可も必要です。
• SCP は組織の管理アカウントには適用されません。設定ミスは組織内の広範囲な操作に影響するため、適切な検証とポリシー管理が重要です。

IAM Access Analyzer のポリシー検証について

• ポリシー検証機能は 100 種類を超えるチェックに基づき、エラー、セキュリティ警告、警告、提案の 4 種類の検証結果と修正の推奨事項を返します。
• ValidatePolicy API では検証対象のポリシータイプとして、アイデンティティポリシーやリソースポリシーに加えてサービスコントロールポリシーとリソースコントロールポリシーを指定でき、SCP 固有の観点で検証できます。

他の選択肢のサービスの守備範囲について

• AWS Well-Architected Tool は設問への回答をもとにワークロードのリスクと改善計画を提示する自己評価ツールで、ポリシードキュメントの解析は行いません。
• AWS Audit Manager は SOC 2 や ISO 27001 などのフレームワークに沿った証跡収集と監査レポート作成を自動化するサービスです。
• AWS Security Hub はセキュリティ標準のコントロールでリソース設定を自動判定し、検出結果を集約するサービスで、ポリシーの文法検証は対象外です。

図による解説

アーキテクチャ図

1 つの Service Control Policy が、メンバーアカウントへの適用と IAM Access Analyzer への検証入力という 2 つの使われ方に分かれた構成になっています。管理アカウントで作成した SCP は開発系と分析系のメンバーアカウントへ適用され、許可アクションを限定して権限の最大範囲を制限します。同じポリシードキュメントを IAM Access Analyzer のポリシー検証へ分析対象として渡すとチェックが実行され、文法エラー・過剰な許可・ベストプラクティス違反が検証結果レポートとして返ります。つまり検証は SCP の JSON そのものを読む作業であり、適用先のアカウントで何が起きたかを観測する作業ではありません。ここを混同して、リソース設定の状態を判定する仕組みや証跡を集める仕組みに SCP の良し悪しを尋ねても、記述のどこが誤っているかは返ってきません。

解くための考え方

「SCP の最適化」と「AWS のベストプラクティスへの準拠確認」の 2 点を満たすには、ポリシードキュメントそのものを解析・検証できるツールが必要です。選択肢に登場するサービスを役割で整理すると、まず AWS Security Hub はセキュリティ標準のコントロールに照らしてリソース設定の状態を判定するサービスであり、評価しているのは暗号化やログ設定といった環境側の状態です。AWS Audit Manager はコンプライアンスフレームワークに沿った証跡収集と監査レポート作成のためのサービスで、SCP の記述内容を改善する指摘は行いません。AWS Well-Architected Tool はセキュリティを含む柱ごとの設問に回答して改善計画を得る自己評価ツールで、ポリシーの文法を機械的に確認する用途には使えません。残る IAM Access Analyzer のポリシー検証機能は、AWS のベストプラクティスに基づく多数のチェックでポリシーを解析し、エラー、セキュリティ警告、警告、提案という 4 種類の検証結果を返します。検証対象のポリシータイプとして SCP を明示的にサポートしている点が決め手で、既存の SCP をこの機能にかけ、指摘された問題を修正していくことで、最適化とベストプラクティス準拠の確認という両方の要件を満たせます。ポリシーを検証するのは IAM Access Analyzer、環境やリソースの状態をチェックするのは Security Hub、証跡をまとめるのは Audit Manager です。

参考資料

• AWS IAM Access Analyzer のポリシー検証
• ValidatePolicy API リファレンス
• AWS Organizations のサービスコントロールポリシー
• AWS Well-Architected Tool とは
• AWS Audit Manager の概要

正解：C

A. 監査用の別アカウントに EBS スナップショットを共有し、そのアカウントに KMS キーの使用を許可する。

不正解 スナップショットを別アカウントへ共有しても、実体は所有元のアカウントに残ったままで、共有先には参照する権限が与えられるだけです。所有元のアカウントが侵害されてスナップショットが削除されたり共有設定が解除されたりすれば、共有先からも利用できなくなります。AWS も、共有されたスナップショットは自分のアカウントへコピーして自分の KMS キーで再暗号化することを推奨しています。復旧手段として確実にするには、共有を受けた側でコピーを作成し、自分のアカウントの所有物にしておく必要があるため、共有の設定だけでは要件を満たせません。

B. 新しい Amazon S3 バケットを用意 し、EBS のライフサイクルポリシーでスナップショットをそのバケットへ退避 する。 バケット側の ライフサイクル設定で S3 Glacier Flexible Retrieval へ移し 、S3 Object Lock によって削除できない状態にする。

不正解 EBS スナップショットは Amazon S3 に保存されていますが、AWS が管理する内部のバケットに格納されており、ユーザーが S3 コンソールや S3 API から直接アクセスすることはできません。そのため、スナップショットをユーザーのバケットへ移動することも、S3 ライフサイクル設定で Glacier Flexible Retrieval へ移行することもできません。S3 Object Lock はユーザーが管理するバケット内のオブジェクトに適用する機能であり、スナップショットの削除保護には使えないため、この構成自体が実現不可能です。スナップショットに対して取れる手段は、EC2 の API を通じたコピーや共有、リサイクルビンによる保持といった EBS 側の機能に限られます。

C. 保管専用の AWS アカウントを別途開設し、スナップショットの受け入れに必要な権限だけを与える。 そのアカウントで EBS スナップショットのコピーを定期的に作成し、暗号化に使っている KMS キーの利用も認めておく。

正解 コピーを作った側がそのスナップショットの所有者になるため、保管専用アカウントに定期的にコピーしておけば、運用中のアカウントの管理権限を奪われてもコピーは攻撃者の手の届かない場所に残り、そこから EC2 インスタンスを復元できます。共有はコピーを作るための前段に過ぎず、実体を自分のものとして持つところまで進めている点が決め手です。暗号化にカスタマーマネージドキーを使っている以上、キーポリシーでコピー先へ復号と再暗号化の利用を認めておく手順も欠かせません。保管先を別アカウントへ分離する形はランサムウェア対策としても推奨されています。

D. スナップショットに削除保護用のタグを付与し、IAM ポリシーでそのタグを持つスナップショットの削除を拒否する。

不正解 タグ条件を使った IAM ポリシーでの削除拒否は、誤操作による削除を防ぐうえでは有効ですが、保護の効力は同じアカウント内で完結します。アカウントの管理権限を奪った攻撃者は、そのポリシー自体を変更・削除したり、対象のタグを外したりできるため、本問が前提とする侵害シナリオでは保護になりません。バックアップを侵害の影響範囲の外へ置くという要件を満たさないため、適切ではありません。

全体的な説明

問われている要件

• アカウントの管理権限を奪われた場合でも EBS スナップショットが失われないようにすること
• スナップショットから EC2 インスタンスを確実に復旧できる状態を維持すること
• KMS カスタマーマネージドキーで暗号化されたスナップショットを復元時に復号できること
• EBS スナップショットの保存場所と操作可能な API の制約を理解していること

前提知識

EBS スナップショットの仕組みについて

• EBS スナップショットはボリュームのブロックレベルの増分バックアップで、Amazon S3（AWS が管理する内部バケット）に保存されます。ユーザーは S3 コンソールや S3 API から直接アクセスできず、コピー・共有・削除などの操作は EC2 の API を通じて行います。
• そのため、S3 ライフサイクル設定や S3 Object Lock といったユーザー管理バケット向けの機能をスナップショットに適用することはできません。

スナップショットの共有とコピーの違いについて

• 共有はスナップショットの所有権を移さず、指定したアカウントに参照を許可する設定です。共有先が長期的に使い続けるには、自分のアカウントへコピーして所有者になる必要があります。
• カスタマーマネージドキーで暗号化されたスナップショットの場合、KMS キーポリシーでコピー先アカウントにキーの使用権限（kms:Decrypt、kms:ReEncrypt、kms:DescribeKey など）を許可します。AWS が管理するデフォルトキー（aws/ebs）で暗号化されたスナップショットは共有できないため、クロスアカウント運用ではカスタマーマネージドキーの利用が前提になります。
• Amazon Data Lifecycle Manager（DLM）を使うと、スナップショットの定期作成と別アカウントへのコピーを自動化できます。

アカウント分離によるバックアップ保護について

• 本番とは別のバックアップ専用アカウントに最小限の権限だけを付与してスナップショットのコピーを保管すると、認証情報の漏洩やランサムウェア攻撃で本番アカウントが侵害されても、バックアップの削除や改ざんを防げます。この構成は AWS の災害復旧ベストプラクティスとして推奨されています。
• 同じアカウント内で完結する IAM ポリシーやタグによる削除制限は、そのアカウントの管理権限を持つ者であれば変更できるため、侵害を前提とした保護策にはなりません。

図による解説

アーキテクチャ図

バックアップは削除の禁止ではなく、所有者を分けることで守ります。本番アカウントでは EC2 インスタンスが使う EBS ボリュームから定期的にスナップショットを作成し、Customer Managed Key で暗号化します。そのスナップショットを保管アカウントへコピーすると、コピーは保管アカウントが所有する別のリソースになるため、本番アカウントの管理権限を奪われても消されません。キー本体は本番側が所有したままなので、KMS キーポリシーで保管アカウントへ復号と使用を許可しておく手順が同時に必要です。ここを共有の設定で止めると実体は本番側に残り、所有元で削除された時点で保管アカウントからも復元に使えなくなります。

解くための考え方

アカウントの管理権限を奪われた場合、そのアカウント内のリソースはすべて削除され得ます。バックアップは侵害の影響範囲の外に置く必要があります。同じアカウント内でタグと IAM ポリシーによる削除拒否を組んでも、攻撃者はポリシーやタグ自体を操作できるため保護になりません。次に、各選択肢の技術的な実現可能性を確認します。EBS スナップショットは AWS が管理する内部の S3 に保存され、ユーザーが S3 の機能で直接操作できないという制約を知っていれば、S3 バケットへ移動して Glacier Flexible Retrieval へ移行し Object Lock を適用する案は、構成自体が成立しません。別アカウントへ共有する案は一見すると影響範囲の外に置いたように見えますが、共有は参照を許可するだけで実体は所有元に残るため、所有元でスナップショットが削除されれば共有先も復旧に使えません。残る、新しいアカウントを作成して最小限の権限を付与し、スナップショットを定期的にコピーして KMS キーへのアクセスを許可する方法だけが要件を満たします。コピーによって保管アカウントがスナップショットの所有者になるため、本番アカウント側で何が起きても復旧手段が残ります。加えて、スナップショットがカスタマーマネージドキーで暗号化されている以上、コピー先アカウントにキーポリシーで使用権限を許可しなければ復号もコピーもできないため、「KMS キーへのアクセスを許可する」という手順まで含んだこの選択肢が正解となります。

参考資料

• EBS スナップショットのコピー
• EBS スナップショットの共有設定
• AWS の災害復旧（DR）ベストプラクティス
• 他のアカウントのユーザーに KMS キーの使用を許可する

正解：D

A. 対象のインスタンスが置かれているサブネットに対して、新しいネットワーク ACL（NACL）を作成して関連付ける。 若い番号のルールとして、インバウンドとアウトバウンドの双方に 0.0.0.0/0 を対象とする拒否ルールを置き、対象への通信をすべて止める。

不正解 ネットワーク ACL はステートレスで接続状態を追跡しないため、すべてのトラフィックを拒否すれば既存の SSH セッションの通信も即座に遮断できます。しかし NACL はサブネット単位に関連付けられるため、この方法では同じサブネットで稼働している他の無関係なインスタンスの通信まで遮断してしまい、業務影響が大きすぎます。NACL を新しく関連付ける操作自体も、同じサブネットを共有している他のワークロードの通信要件を洗い直す前提になり、緊急時の判断としては重くなります。特定の 1 台だけを対象に隔離するという要件には、インスタンス単位で適用できるセキュリティグループと Session Manager の組み合わせの方が適しています。

B. 対象のインスタンスを停止して EBS スナップショットを取得し、そこから作成したボリュームを調査用のインスタンスにアタッチする。

不正解 インスタンスを停止すればすべての通信は止まりますが、実行中のプロセスや確立中の接続といった揮発性の情報は失われ、稼働状態のまま調査するという目的が果たせません。ボリュームの複製を調査用インスタンスに渡す手順は証拠保全としては有効なものの、対象インスタンスへフォレンジックチームがアクセスできる経路を残したまま隔離するという要件は満たさないため、隔離手順の答えにはなりません。

C. インバウンドルールとアウトバウンドルールを 1 つも持たない新しいセキュリティグループを作成してインスタンスに付け替え、元のセキュリティグループを削除する。

不正解 セキュリティグループを入れ替えても、追跡されている接続は許可の根拠だったルールがなくなった後もタイムアウトまでパケットが通り続けるため、維持されている SSH セッションはこの操作では切断されません。さらに、ルールを持たないセキュリティグループではフォレンジックチームがネットワーク経由で入る手段も失われ、調査のためのアクセス経路を確保するという要件も満たせないため、隔離手順として成立しません。既存の接続を断つ効果と調査経路の確保のどちらも得られない点で、対応としては後退になります。

D. ポート 22 を許可するインバウンドルールを取り除き、SSH を受け付けない状態にする。 インスタンスロールに AWS Systems Manager Session Manager 用のポリシーを付与し、調査のための接続手段をそちらへ切り替える。

正解 インバウンドから SSH の入口をなくしたうえで、調査担当の到達手段を Session Manager に移す構成です。Session Manager は SSM エージェントが Systems Manager のエンドポイントへ向けて張るアウトバウンドの HTTPS（443）で成立するため、アウトバウンドの経路か VPC エンドポイントを確保しておけば、インバウンドを一切開けずに IAM 認証で接続できます。セッション開始を許可する対象を IAM で絞れば到達できるのは調査担当だけになり、接続後にインスタンス内から残っている SSH のプロセスを落とせるため、対象 1 台の遮断と調査経路の確保を同時に満たせます。

全体的な説明

問われている要件

• インシデント対応の一環として、対象の EC2 インスタンス 1 台だけを完全に隔離すること
• フォレンジックチームだけが調査のためにアクセスできる経路を確保すること
• 維持されたままになっている既存の SSH セッションを遮断すること
• 同じサブネット内の他のインスタンスに影響を与えないこと

前提知識

セキュリティグループの接続追跡について

• セキュリティグループはステートフルで、許可した接続の状態を接続追跡（コネクショントラッキング）で記録します。追跡されている接続は、その接続を許可していたルールを削除・変更しても即座には中断されず、通信が終了またはタイムアウトするまでパケットが許可され続けます。
• このため、問題文の状況のように SSH ルールを差し替えても既存の SSH セッションが残り続けます。なお、追跡されていない接続はルールの削除で即座に中断されます。

ネットワーク ACL（NACL）について

• NACL はステートレスで接続状態を追跡せず、すべてのパケットをルールで評価するため、拒否ルールは既存の接続にも即座に適用されます。
• ただし NACL はサブネット単位に関連付けられるため、拒否ルールは同じサブネット内のすべてのインスタンスに影響します。

AWS Systems Manager Session Manager について

• インバウンドポートを一切開けず、SSH キーや踏み台サーバーも使わずに EC2 インスタンスへシェルアクセスできる機能です。インスタンス側の SSM エージェントが Systems Manager のエンドポイントへアウトバウンドの HTTPS（ポート 443）接続を行う仕組みで、VPC エンドポイントを使えばインターネットへの経路がない環境でも利用できます。
• 利用にはインスタンスロールへの権限付与（AmazonSSMManagedInstanceCore など）が必要で、IAM ポリシーによりフォレンジックチームなど特定のユーザーだけにセッション開始を許可できます。セッションの操作履歴を CloudWatch Logs や S3 に記録でき、調査作業の証跡も残せます。

図による解説

アーキテクチャ図

調査担当の到達経路を、インバウンドからアウトバウンドへ付け替えています。Security Group はポート 22 のインバウンドルールを削除済みで、Internet からの SSH は VPC 内部へ入る手前で遮断されます。代わりに IAM Role が SSM ポリシーを EC2 Instance へ与え、インスタンス上の SSM エージェント自身が Systems Manager Session Manager のエンドポイントへ HTTPS で接続します。Forensic Team はインスタンスへ直接届くのではなく Session Manager 側でセッションを開始するため、インバウンドを一切開けずに IAM 認証だけで到達できます。この経路がアウトバウンドの 443 に依存している点は見落としやすく、隔離を徹底しようとアウトバウンドまで塞ぎ、VPC エンドポイントも用意しなければ、遮断と同時に調査経路まで失われます。

アーキテクチャ図

同じ遮断でも、ステートフルかステートレスかで既存の接続への効き方が変わります。Security Group はステートフル動作のため、ルール変更前から確立していた既存 SSH 接続を追跡したまま維持します。ポート 22 のルールを削除しても拒否されるのは新規接続試行だけで、既存の通信は隔離対象の EC2 Instance へ通り抜けます。一方 Network ACL はステートレス動作で拒否ルールを既存接続にも即座に適用しますが、その効果はサブネット単位に及ぶため、同居サブネットの他インスタンスまで巻き添えで遮断されます。既存セッションが残る事象への対処に NACL を選ぶと、無関係なワークロードを止めてしまいます。残存セッションは調査経路からインスタンス内へ入り、当該プロセスを終了させて断つのが筋です。

解くための考え方

既存の SSH セッションが維持されたままという事象の原因を特定します。セキュリティグループはステートフルで接続追跡を行うため、ルールを削除しても追跡済みの既存接続はタイムアウトまで維持されるという仕様が原因であり、セキュリティグループのルール操作だけでは既存セッションを即座に遮断できないと分かります。続いて、各選択肢を要件と照らし合わせます。ルールのないセキュリティグループへ付け替える方法は、接続追跡の仕様は変わらないので既存セッションは残り、しかもフォレンジックチームの経路まで塞いでしまいます。NACL で全トラフィックを拒否する方法は、ステートレスな NACL なら既存接続も即座に遮断できるものの、サブネット全体に適用されるため、複数のインスタンスが稼働している本問の環境では無関係なインスタンスまで通信不能にしてしまいます。インスタンスを停止してスナップショットから調査用ボリュームを作る方法は、証拠保全の手順としては妥当でも、稼働中のインスタンスへ調査担当がアクセスできる状態を保つという要件を外しています。残る構成は、ポート 22 のインバウンドルールを削除して SSH の入口を閉じ、代わりにインスタンスロールに Session Manager 用のポリシーを追加すれば、インバウンドを開けずに IAM 認証でアクセス経路を確保できます。Session Manager は SSM エージェントからのアウトバウンドの HTTPS（443）で成立するため、アウトバウンドの経路か VPC エンドポイントを残しておく必要があります。フォレンジックチームだけに IAM でセッション開始を許可し、Session Manager 経由でログインして残っている SSH セッションのプロセスを終了させれば、対象インスタンスのみを完全に隔離しつつ調査を進められます。

参考資料

• AWS Systems Manager Session Manager の概要
• Amazon EC2 のセキュリティグループの動作
• Amazon VPC ネットワーク ACL の仕組み
• Amazon EC2 セキュリティグループの接続の追跡