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

正解：B

A. 既存の ECR リポジトリで KMS 暗号化を有効化 する。

ECS コンテナインスタンスの ユーザーデータ（User Data） から Amazon Inspector エージェント をインストールし、CVE ルールを用いた評価を実行 する。

不正解 既存の ECR リポジトリに対して KMS 暗号化を有効化することはできません。KMS 暗号化は ECR リポジトリの作成時にのみ設定可能 であり、既存のリポジトリには適用できません。

B. KMS 暗号化を有効化した新しい ECR リポジトリ を作成し、ECR スキャン（ECR Image Scanning）を有効化 する。

次回のイメージプッシュ後に スキャンレポートを分析 する。

正解 ECR リポジトリの KMS 暗号化は新規作成時にのみ適用可能 なため、新しいリポジトリを作成する必要があります。

また、Amazon ECR のスキャン機能（ECR Image Scanning） を有効化することで、ECR にプッシュされたコンテナイメージの CVE スキャンを自動で実施 できます。

この方法により、KMS 暗号化と CVE スキャンの両方の要件を満たすことができます。

C. KMS 暗号化を有効化した新しい ECR リポジトリ を作成し、ECR スキャンを有効化 する。

さらに、ECS コンテナインスタンスに AWS Systems Manager Agent をインストールし、インベントリレポートを取得 する。

不正解 ECR のスキャン機能を有効にするのは正しいですが、AWS Systems Manager Agent はコンテナイメージの脆弱性スキャンには不要 です。

Systems Manager は EC2 インスタンスのインベントリ収集には使えますが、ECR イメージの脆弱性分析には関与しません。

D. 既存の ECR リポジトリで KMS 暗号化を有効化 する。

AWS Trusted Advisor を使用して ECS コンテナインスタンスのチェック を行い、既知の CVE と比較して検証 する。

不正解 既存の ECR リポジトリに対して KMS 暗号化を適用することはできません。

また、AWS Trusted Advisor は脆弱性（CVE）のスキャン機能を持っていません。Trusted Advisor は コスト最適化、セキュリティの基本チェック、ベストプラクティスの推奨 などを行いますが、コンテナイメージの脆弱性スキャンには適用できません。

全体的な説明

問われている要件

この問題では、ECR リポジトリの暗号化と、コンテナイメージの脆弱性スキャンの方法 が問われています。 解決策を選ぶ際のポイントは以下の通りです。

1. ECR の KMS 暗号化を有効にする方法を理解する

• 既存の ECR リポジトリには KMS 暗号化を適用できない ため、新しいリポジトリを作成する必要がある。

2. コンテナイメージの CVE スキャンを実施する方法を理解する

• Amazon ECR のスキャン機能を有効化 すれば、コンテナイメージをスキャンし、CVE（Common Vulnerabilities and Exposures）のチェックが可能。

3. AWS Trusted Advisor は適切な選択肢ではない

• AWS Trusted Advisor は脆弱性スキャンの機能を提供していない。

前提知識

• Amazon ECR の KMS 暗号化ECR リポジトリの作成時 に AWS Key Management Service（KMS） を使用した暗号化を有効にできる。
• 既存のリポジトリには適用できない ため、KMS 暗号化を有効化するには 新しいリポジトリを作成 する必要がある。

Amazon ECR Image Scanning

• ECR は、プッシュされたコンテナイメージを 自動的にスキャンし、CVE を検出する機能 を提供する。
• スキャン結果は ECR コンソールや AWS CLI で確認可能。

AWS Trusted Advisor との違い

• Trusted Advisor は コスト最適化やセキュリティベストプラクティスのチェックを行うサービス であり、CVE のスキャン機能は持っていない。

解くための考え方

1. ECR の KMS 暗号化は新しいリポジトリでのみ有効にできる ため、既存リポジトリを暗号化する方法は除外する。
2. CVE スキャンが可能なサービスは Amazon ECR Image Scanning のみ であるため、それを活用する解決策を選ぶ。
3. 適切なソリューションを選ぶ

• ECR スキャンを活用し、次回のイメージプッシュ時に脆弱性を分析する方法が最適。

参考資料

• Amazon ECR の暗号化
• Amazon ECR イメージスキャン
• AWS Key Management Service (AWS KMS) の概要

正解：B

A. インライン IAM ユーザーポリシー を作成し、フリーランス編集者の IAM ユーザーに Amazon EC2 へのアクセスを許可 する。

不正解 IAM インラインポリシー を作成すれば、フリーランス編集者の IAM ユーザーに EC2 へのアクセスを許可できますが、IAM グループに追加された場合に追加のアクセス権を持つ可能性がある ため、要件を満たしません。

B. IAM パーミッションバウンダリー（Permissions Boundary） を作成し、Amazon EC2 へのアクセスのみ許可 する。

フリーランス編集者の IAM アカウントに このパーミッションバウンダリーを適用 し、他の AWS サービスへのアクセスを制限する。

正解 IAM パーミッションバウンダリー（Permissions Boundary） を使用すると、IAM ユーザーが どのようなポリシーを追加されても、それ以上の権限を持つことができないように制限 できます。

この方法を使用すれば、IAM ユーザーが 他の AWS サービスへのアクセス権を付与されても、パーミッションバウンダリーの制約により適用されない ため、要件を満たします。

C. IAM グループ を作成し、Amazon EC2 へのアクセスを許可するポリシーをアタッチ する。

フリーランス編集者の IAM アカウントをこのグループに追加する。

不正解 IAM グループにポリシーをアタッチしても、フリーランス編集者の IAM アカウントが 後から別のグループに追加され、そのグループに追加の権限が与えられた場合、他の AWS サービスへのアクセスが可能になってしまいます。

したがって、この方法では IAM グループ経由の追加権限を制限することができない ため、要件を満たしません。

D. Amazon EC2 へのアクセスを許可し、他のすべての AWS サービスを明示的に拒否する IAM ロール を作成する。

フリーランス編集者に このロールを常に引き受ける（assume）ように指示 する。

不正解 IAM ロールを作成して、フリーランス編集者に そのロールを AssumeRole するよう指示する方法 は、ロールを引き受けるためのIAMユーザを作成する必要があり、無用な複雑さを発生させます。

全体的な説明

問われている要件

この問題では、フリーランス編集者の IAM ユーザーが Amazon EC2 以外の AWS サービスにアクセスできないようにする方法 が問われています。 特に、IAM グループに追加されても追加の権限を持たせないこと が重要な要件になっています。

前提知識

• IAM ポリシーとはIAM ポリシーは、AWS リソースに対するアクセス権を制御するための JSON 形式のルール です。
• IAM ポリシーには以下の種類があります：アタッチポリシー（Permissions Policy）: IAM ユーザー、グループ、またはロールに適用されるポリシー。
• インラインポリシー: 特定の IAM エンティティに埋め込まれるポリシー。
• パーミッションバウンダリー（Permissions Boundary）: IAM ユーザーまたはロールが持つ最大の権限を制限するポリシー。

IAM パーミッションバウンダリーとは

• IAM パーミッションバウンダリーは、IAM ユーザーまたはロールが付与される最大の権限を制限する機能 です。
• ユーザーに IAM グループを通じて追加のポリシーが適用されても、パーミッションバウンダリーで許可されていない操作は実行できません。
• 例えば、以下のようなパーミッションバウンダリーを設定すると、IAM ユーザーは Amazon EC2 以外の AWS サービスにアクセスできなくなります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "ec2:StartInstances",
        "ec2:StopInstances",
        "ec2:RebootInstances"
      ],
      "Resource": "*"
    }
  ]
}

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

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

解くための考え方

1. IAM ユーザーが Amazon EC2 以外の AWS サービスにアクセスできないようにする方法を考える

• 単純な IAM ポリシーや IAM グループの制限では、IAM ユーザーがグループを通じて追加のアクセス権を得る可能性があるため不十分。

2. IAM パーミッションバウンダリーを活用する

• IAM パーミッションバウンダリーを適用すれば、IAM ユーザーが 他のポリシーで追加の権限を持つことができない ように制限できる。

3. 最適な方法を選ぶ

• IAM パーミッションバウンダリーを設定し、EC2 以外のアクセスを制限する方法が最も適切である。

参考資料

• AWS IAM パーミッションバウンダリーの概要
• IAM ポリシーのベストプラクティス
• AWS IAM のポリシーの種類

正解：C

A. 新しい CloudTrail を作成 し、Amazon S3 にログを送信するように設定する。

また、Amazon EventBridge を使用して、CloudTrail が削除または停止された場合に通知を送信する。

不正解 CloudTrail を新しく作成しても、既存のメンバーアカウントに適用される保証はない ため、この方法では要件を満たしません。

また、CloudTrail の削除や停止の監視 は重要ですが、それだけでは CloudTrail を全てのアカウントで強制的に有効化する仕組みにはならない ため、適切ではありません。

B. 各メンバーアカウントに AWS Lambda 関数をデプロイ し、既存の CloudTrail があるかをチェックする。

CloudTrail がない場合は 自動的に新しいトレイルを作成する。

不正解 Lambda 関数を各アカウントにデプロイして CloudTrail の有無をチェックし、新規作成する方法 は技術的に可能ですが、運用負荷が高い ため、組織全体での管理には適していません。

また、新しいアカウントが追加された際に Lambda 関数が確実にデプロイされる保証がない ため、要件を満たしません。

C. Organizations の管理アカウントで既存の CloudTrail を編集し、組織全体に適用する。

正解 AWS Organizations では、管理アカウントで CloudTrail を設定し、組織全体に適用することが可能 です。

この方法を使えば、すべてのメンバーアカウントに自動的に CloudTrail が適用され、新しいアカウントが追加された際も自動で適用される ため、最も適切な解決策です。

D. サービスコントロールポリシー（SCP）を作成 し、cloudtrail:Delete* および cloudtrail:Stop* のアクションを拒否する。

この SCP を すべてのメンバーアカウントに適用 する。

不正解 SCP を適用して cloudtrail:Delete* や cloudtrail:Stop* を拒否することは、CloudTrail の無効化を防ぐのには有効ですが、CloudTrail を自動的に有効化することはできない ため、要件を満たしません。

全体的な説明

問われている要件

この問題では、以下の 2 つの要件を満たす方法を選ぶ必要があります：

1. 既存の AWS アカウントに CloudTrail を強制的に適用する
2. 新しく作成される AWS アカウントにも自動で適用されるようにする

前提知識

• AWS CloudTrail とはCloudTrail は AWS アカウント内の API アクティビティを記録する監査サービス。
• Amazon S3 にログを保存し、AWS Security Hub、Amazon EventBridge などと統合可能。

Organizations における CloudTrail の管理

• 管理アカウントで CloudTrail を作成し、組織全体に適用することが可能。
• この設定を行うことで、既存のアカウントと今後作成されるアカウントすべてに CloudTrail を自動的に適用できる。
• これにより、メンバーアカウント側で個別に CloudTrail を設定する必要がなくなる。

サービスコントロールポリシー（SCP）とは

• SCP は AWS Organizations の機能で、メンバーアカウントの IAM 権限の上限を設定する。
• 例えば CloudTrail の削除を拒否する SCP を適用すれば、メンバーアカウントのユーザーが CloudTrail を削除できないようにすることは可能 。
• ただし、SCP は 既存のアカウントに CloudTrail を強制的に適用する機能はない。

解くための考え方

1. CloudTrail を確実に有効化する方法を探す

• 各アカウントで個別に設定するのではなく、管理アカウントから一元管理できる方法が望ましい。

2. 新しいアカウントにも自動適用できる方法を探す

• Organizations の管理アカウントで CloudTrail を設定すれば、新しいアカウントにも自動適用される。

3. 不要な選択肢を排除する

• CloudTrail の削除を防ぐ SCPは有用だが、CloudTrail を有効化する機能ではないため、除外。
• Lambda を使う方法は実装の手間と運用負荷が高いため、除外。

4. 最適な選択肢を選ぶ

• Organizations の管理アカウントで CloudTrail を編集し、組織全体に適用する方法が最も適切。

参考資料

• AWS Organizations における CloudTrail の設定
• AWS CloudTrail の概要
• AWS Organizations の SCP（サービスコントロールポリシー）

正解：C

A. AWS CloudTrail ログ、VPC フローログ、および DNS ログを有効化 し、Amazon CloudWatch Logs を使用してログを管理する。

不正解 CloudTrail ログ、VPC フローログ、DNS ログを収集し、CloudWatch Logs に保存することで、セキュリティデータの可視性は向上します。

しかし、CloudWatch Logs は 自動的に脅威を検出する機能を持たない ため、企業の要件である リアルタイムの脅威検出には適していません。

B. AWS CloudTrail ログ、VPC フローログ、および DNS ログを有効化 し、Amazon Macie を使用してログを管理する。

不正解 Amazon Macie は、機械学習を活用して Amazon S3 に保存されているデータの機密性や異常なアクセスを検出するサービス です。

この問題では EC2 インスタンスの異常なトラフィックやネットワークの異常な振る舞いも監視する必要がある ため、Macie だけでは要件を満たしません。

C. Amazon GuardDuty を有効化 し、AWS CloudTrail ログ、VPC フローログ、および DNS ログを分析する。

正解 Amazon GuardDuty は、AWS CloudTrail ログ、VPC フローログ、DNS ログを分析し、異常なアクティビティをリアルタイムで検出する AWS のマネージド型セキュリティ監視サービスです。

GuardDuty は DNS アクセスの異常な増加、異常なインスタンストラフィック、異常なネットワークアクティビティ、S3 API の異常な操作 などを自動的に検出し、セキュリティインシデントのリスクを軽減します。

このため、企業の要件を最も適切に満たす選択肢です。

D. Amazon Inspector を有効化 し、AWS CloudTrail ログ、VPC フローログ、および DNS ログを分析する。

不正解 Amazon Inspector は、EC2 インスタンスやコンテナイメージの脆弱性スキャンを実行するサービス です。

この問題では、リアルタイムのネットワークトラフィックの監視や、異常な振る舞いの検出が必要 なため、Amazon Inspector は適していません。

全体的な説明

問われている要件

この問題では、以下の2つの要件を満たす方法を選ぶ必要があります：

1. AWS 環境全体を継続的に監視し、異常なアクティビティをリアルタイムで検出すること
2. DNS トラフィック、EC2 インスタンスの挙動、ネットワークインターフェースのトラフィック、S3 API コールを分析すること

前提知識

• Amazon GuardDuty とはGuardDuty は AWS の 脅威検出サービス で、以下のデータを分析し、異常な振る舞いを検出する：AWS CloudTrail の管理イベント（API アクセスの異常な試行など）
• VPC フローログ（異常なネットワークアクティビティの検出）
• DNS クエリログ（悪意のあるドメインへのアクセスを検出）
• S3 データイベントログ（異常な S3 API コールを検出）

GuardDuty は マネージド型の脅威インテリジェンス機能を持ち、リアルタイムで分析を行う。

CloudWatch Logs との違い

• CloudWatch Logs は、ログを保存・検索するサービス であり、脅威を検出する機能は持たない。
• そのため、リアルタイムの脅威検出には適さない。

Amazon Macie との違い

• Amazon Macie は、S3 に保存されたデータの 機密情報（PII、クレジットカード番号など） を特定し、異常なアクセスを検出するサービス。
• ネットワークトラフィックや DNS クエリの異常を検出する機能はないため、要件を満たさない。

Amazon Inspector との違い

• Amazon Inspector は、EC2 インスタンスやコンテナの脆弱性スキャンを実施するサービス。
• ネットワークアクティビティや異常な API アクセスを監視する機能はない ため、要件を満たさない。

解くための考え方

1. リアルタイムで異常を検出できるサービスを選ぶ

• CloudWatch Logs は ログの保存と検索が主な機能 なので不適切。
• Amazon Macie は S3 のデータ保護に特化 しているため不適切。
• Amazon Inspector は 脆弱性スキャンツール なので不適切。

2. 複数の脅威（DNS、ネットワーク、EC2、S3）を総合的に監視できるサービスを選ぶ

• GuardDuty は、VPC フローログ、CloudTrail ログ、DNS クエリを分析し、異常な挙動をリアルタイムで検出できる ため、最適な選択肢。

3. 最適な選択肢を選ぶ

• Amazon GuardDutyを有効化し、AWS 環境全体の脅威をリアルタイムで検出する方法が最も適切。

参考資料

• Amazon GuardDuty の概要
• Amazon GuardDuty の脅威検出機能
• AWS CloudTrail の概要
• Amazon Macie の概要
• Amazon Inspector の概要

正解：A

A. パーミッションセットを割り当てる各アカウントに、同じ名前と権限を持つカスタマーマネージドポリシーを作成する。

正解 IAM Identity Center でカスタマーマネージドポリシーを使用する場合、ポリシーが適用される各アカウントに、そのポリシーが存在している必要がある ため、同じカスタマーマネージドポリシーを 各 AWS アカウントに作成する必要があります。

AWS マネージドポリシーは AWS によって管理され、すべてのアカウントで利用可能 ですが、カスタマーマネージドポリシーはアカウントごとに作成しなければならない ため、この手順が必要になります。

B. AWS マネージドポリシーまたはカスタマーマネージドポリシーのどちらかを削除 し、新しいパーミッションセットを作成する。 その後、佐藤さんに別々のパーミッションセットを適用する。

不正解 AWS マネージドポリシーとカスタマーマネージドポリシーを別々のパーミッションセットに分けても、カスタマーマネージドポリシーが各アカウントに存在しない限り、適用エラーは解決しない ため、この方法では問題を解決できません。

C. AWS マネージドポリシーとカスタマーマネージドポリシーのロジックを再評価し、競合を解決してからデプロイする。

不正解 ポリシーのロジックの競合を解決することは一般的に重要ですが、この問題の根本的な原因は カスタマーマネージドポリシーがメンバーアカウントに存在しないこと です。

したがって、ポリシーの内容を修正するだけでは問題は解決しません。

D. 新しいパーミッションセットを適用せず、既存の「MediaOpsAccess」パーミッションセットを編集して AWS マネージドポリシーとカスタマーマネージドポリシーを含める。

不正解 既存のパーミッションセットを編集しても、カスタマーマネージドポリシーが各アカウントに存在しない問題は解決しない ため、エラーは解決されません。

全体的な説明

問われている要件

この問題では、以下の点が重要です：

1. IAM Identity Center でカスタマーマネージドポリシーを使用する際の要件を理解すること
2. パーミッションセットを適用するために必要な設定を行うこと

前提知識

• IAM Identity Center のパーミッションセットとはIAM Identity Center では「パーミッションセット」を定義し、各 AWS アカウントの IAM ロールに適用することでアクセスを制御する。
• パーミッションセットに AWS マネージドポリシーやカスタマーマネージドポリシーをアタッチ可能。

カスタマーマネージドポリシーの適用方法

• AWS マネージドポリシーはすべての AWS アカウントで利用可能 だが、カスタマーマネージドポリシーは作成されたアカウント内にのみ存在する。
• そのため、IAM Identity Center で カスタマーマネージドポリシーを含むパーミッションセットを適用する場合、すべての対象アカウントに同じポリシーが存在する必要がある。

IAM Identity Center のポリシー適用プロセス

1. パーミッションセットを作成し、必要な IAM ポリシーを追加する。
2. IAM Identity Center がメンバーアカウントに IAM ロールを作成し、パーミッションセットのポリシーをそのロールにアタッチする。
3. AWS マネージドポリシーは AWS により管理されているため、すべてのアカウントで適用可能。
4. カスタマーマネージドポリシーは、そのアカウント内で作成されている必要があるため、存在しないとエラーが発生する。

解くための考え方

1. エラーの原因を特定する

• AWS マネージドポリシーはすべてのアカウントで使用可能。
• カスタマーマネージドポリシーは そのポリシーが適用されるアカウントごとに作成されていなければならない。
• ポリシーが存在しないため、割り当てに失敗している可能性が高い。

2. 解決策を選ぶ

• すべてのアカウントに 同じ名前と権限を持つカスタマーマネージドポリシーを作成する。
• 他の選択肢はこの問題を解決できないため除外する。

参考資料

• AWS IAM Identity Center (SSO) のパーミッションセットの管理
• AWS IAM ポリシーの種類
• カスタマーマネージドポリシーの作成

正解：D

A. IAM ポリシーを設定して、Lambda コンソールから環境変数へのアクセスを制限する。

不正解 IAM ポリシーを設定すれば、Lambda コンソール上で環境変数を隠すことはできますが、環境変数そのものが暗号化されずに保存されている ため、Lambda 関数のログを通じて情報漏洩のリスクが残りる可能性があります。

また、IAM ポリシーでは、環境変数の内容そのものを暗号化することはできません。

B. AWS Step Functions に環境変数を保存し、実行時にアクセスする。

IAM 権限を設定し、必要な Lambda 関数のみに環境変数のアクセスを許可する。

不正解 AWS Step Functions はワークフロー管理ツールであり、環境変数の管理には適していません。

また、Step Functions にデータを保存する場合、コストがかかる上に、運用が複雑になるため、コスト効率の良い解決策ではありません。

C. AWS Secrets Manager に環境変数を保存し、実行時にアクセスする。

IAM 権限を設定し、必要な Lambda 関数のみにシークレットへのアクセスを許可する。

不正解 AWS Secrets Manager は機密情報を保存するのに適したサービスですが、主にパスワードや API キー、データベース認証情報などの大きなデータを管理するために設計されています。

また、Secrets Manager は 有料サービスであり、100,000 回の API リクエストごとに $0.40 の課金が発生する ため、数千の Lambda 関数が頻繁にシークレットにアクセスする環境ではコストが高くなる可能性があります。

D. AWS Systems Manager Parameter Store に環境変数を「セキュアストリング」として保存し、実行時にアクセスする。

IAM 権限を設定し、必要な Lambda 関数のみにパラメータへのアクセスを許可する。

正解 AWS Systems Manager Parameter Store の「セキュアストリング（SecureString）」を使用すれば、機密情報を自動的に KMS で暗号化して保存でき、Lambda 実行時にセキュアに取得可能 です。

さらに、基本的な使用では追加料金が発生しないため、コスト効率が良い というメリットがあります。

全体的な説明

問われている要件

この問題では、以下の 2 つの要件を満たす方法を選ぶ必要があります：

1. Lambda 環境変数のプレーンテキスト保存を回避し、機密情報をセキュアに管理する
2. コスト効率の良い方法で実装する

前提知識

• AWS Lambda 環境変数のリスクAWS Lambda では、環境変数に保存されたデータはデフォルトでプレーンテキストとして保存される。
• Lambda の 実行ロールを持つユーザーは、Lambda コンソールから環境変数を閲覧できる。
• 機密情報（API キー、データベース認証情報など）をプレーンテキストで環境変数に保存すると、情報漏洩のリスクが高まる。

AWS Systems Manager Parameter Store

• セキュアストリング（SecureString）を使用すれば、KMS で暗号化された状態で機密情報を保存できる。
• Lambda 関数は SSM API を使用して、環境変数としての値を安全に取得可能。
• 基本的な利用は無料（ただし、頻繁なアクセスが必要な場合は Secrets Manager の方が適している可能性がある）。
• 例：Python の boto3 を使用した取得方法

import boto3

ssm = boto3.client('ssm')

response = ssm.get_parameter(
    Name='/my/secure/parameter',
    WithDecryption=True
)

secret_value = response['Parameter']['Value']

AWS Secrets Manager

• 主にパスワードや API キーなどの重要なシークレットを管理するためのサービス。
• シークレットのローテーション機能を提供。
• 有料サービス（100,000 API リクエストごとに 課金）。

IAM ポリシーでの制御

• IAM ポリシーで Lambda 関数に対して Parameter Store へのアクセスを制限可能。
• 例：Lambda に対する IAM ポリシー（SSM Parameter Store の SecureString へのアクセス許可）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ssm:GetParameter",
      "Resource": "arn:aws:ssm:us-east-1:123456789012:parameter/my-secure-parameter"
    }
  ]
}

解くための考え方

1. Lambda 環境変数のセキュリティリスクを排除する方法を選ぶ

• IAM ポリシーだけでは プレーンテキストの問題は解決しない。
• Step Functions は環境変数の管理には不適切。

2. 機密情報を適切に管理できるサービスを選ぶ

• Secrets Manager は適切な管理方法だが、コストが高い。
• Systems Manager Parameter Store は 基本無料で、セキュアストリングを使用すれば暗号化可能。

3. 最適な選択肢を選ぶ

• AWS Systems Manager Parameter Store を使用して機密情報を暗号化し、IAM で適切に制限する方法が最も適切。

参考資料

• AWS Systems Manager Parameter Store
• AWS Secrets Manager
• Lambda 環境変数

正解：A

A. AWS IAM Access Analyzer を使用してポリシーを分析し、ポリシーの検証チェック結果を確認する。

正解 AWS IAM Access Analyzer には ポリシー検証機能 があり、IAM ポリシーや SCP の文法的な誤り、非推奨のルール、不適切な設定 を検出できます。

SCP の最適化に関しては IAM Access Analyzer が AWS のベストプラクティスを考慮したポリシーの評価を行うため、最も適したツール です。

B. AWS Trusted Advisor のチェックを確認し、組織内のすべてのアカウントのセキュリティ状態をレビューする。

不正解 AWS Trusted Advisor は、AWS アカウントの コスト最適化、パフォーマンス、セキュリティ、フォールトトレランス、サービスの制限 に関する推奨事項を提供します。

しかし、Trusted Advisor は SCP の最適化を直接チェックする機能を持っていないため、問題の解決策としては適切ではありません。

C. AWS Audit Manager をセットアップし、すべての AWS リージョンおよびアカウントで監査を実行する。

不正解 AWS Audit Manager は、コンプライアンスと監査のためのサービス であり、SCP の最適化とは関係がない ため、適切な解決策ではありません。

Audit Manager は、SOC 2 や ISO 27001 などのフレームワークに基づいたコンプライアンス評価を行う ためのツールです。

D. すべてのアカウントの EC2 インスタンスに Amazon Inspector エージェントをインストールする。

不正解 Amazon Inspector は、EC2 インスタンスやコンテナの脆弱性スキャンを行うツール であり、SCP の管理には関係ありません。 SCP の最適化やベストプラクティスの適用を確認するツールとしては適切ではありません。

全体的な説明

問われている要件

この問題では、以下の 2 つの要件を満たす方法を選ぶ必要があります：

1. AWS Organizations の SCP を最適化すること
2. SCP が AWS のベストプラクティスに準拠していることを確認すること

前提知識

• AWS Organizations と SCP（サービスコントロールポリシー）SCP は、組織内のアカウントに適用されるポリシーで、IAM ポリシーとは異なり、権限の「最大範囲」を制限する。
• SCP によって、メンバーアカウント内で 許可されるアクションを制限 できる。
• SCP の設定ミスがあると、組織内の AWS リソースに影響を与える可能性があるため、適切なポリシー管理が必要。

IAM Access Analyzer とは

• IAM Access Analyzer は IAM ポリシー、SCP、およびリソースポリシーを分析し、問題点やベストプラクティス違反を検出するサービス。
• SCP に関して、ポリシーの文法的な誤りや非推奨のルールを検出できるため、最適化に最も適したツール。

AWS Trusted Advisor との違い

• Trusted Advisor は セキュリティ設定やコスト最適化のチェックはできるが、SCP の最適化には特化していない。
• そのため、SCP の設定を最適化するためには IAM Access Analyzer の方が適している。

AWS Audit Manager との違い

• Audit Manager は、監査レポート作成のためのサービス であり、SCP の最適化を行うツールではない。

Amazon Inspector との違い

• Amazon Inspector は、EC2 やコンテナの脆弱性スキャンを行うサービス であり、IAM ポリシーや SCP には関係ない。

解くための考え方

1. SCP の設定ミスを特定し、最適化できるサービスを選ぶ

• Trusted Advisor、Audit Manager、Amazon Inspector は SCP の最適化に関与しないため除外。

2. SCP の文法エラーや非推奨ルールを検出できるツールを選ぶ

• IAM Access Analyzer は ポリシーの解析や問題点の指摘が可能 であり、AWS の推奨する方法。

3. 最適な選択肢を選ぶ

• IAM Access Analyzer を使ってポリシーを分析し、最適化を行う方法が最適。

参考資料

• AWS IAM Access Analyzer の概要
• AWS Organizations の SCP ベストプラクティス
• AWS Trusted Advisor の機能
• AWS Audit Manager の概要

正解：A、C、F

A. AWS Config のカスタムルールを作成し、AWS リソースの設定変更を検出する。コンプライアンス違反イベントを EventBridge に送信し、Security Hub と連携して findings として集約する。

正解 AWS Config のカスタムルールを利用すると、特定のリソース設定の変更をトリガーとして検出でき、本アーキテクチャにおける検出レイヤーを担います。

この方法により、リアルタイムのリソース設定変更の検出と後続レイヤーへの連携を実現できます。

B. AWS Systems Manager Change Manager を使用して、AWS リソースの設定変更を追跡する。リメディエーション用の Systems Manager ドキュメント（SSM ドキュメント）を作成し、委任管理者アカウントでリソースを修正する。

不正解 AWS Systems Manager Change Manager は運用変更の管理に適しているが、即時修正を目的としたツールではないため、本要件には不適切です。

したがって、この選択肢は適切ではありません。

C. Amazon EventBridge のイベントルールを作成し、委任管理者アカウントの AWS Lambda 関数をトリガーして非準拠リソースを修正する。

正解 EventBridge は本アーキテクチャの実行レイヤーを担い、AWS Config（検出レイヤー）および Security Hub（集約レイヤー）から送信されるイベントを受け取り、委任管理者アカウントの Lambda 関数をトリガーします。

この方法により、検出された違反に対するリアルタイムな自動修正が実現します。

D. 特定の API リクエストを評価して AWS リソースの設定を確認し、非準拠リソースに対する Security Hub の finding を作成する。

不正解 この選択肢の手法（API リクエストを評価してリソースの設定をチェックする方法）は、リアルタイムな変更追跡には適しているが、リメディエーション（修正）のアクションが含まれていないため不十分です。

E. Amazon EventBridge のイベントルールを作成し、特定の AWS Config ルールを定期的に評価する Lambda を実行する。

不正解 EventBridge をスケジュール実行して AWS Config ルールを定期的に評価する方法は、リアルタイム性に欠けるため適切ではないです。

このため、この方法は要件を満たしません。

F. AWS Security Hub の findings を Amazon EventBridge に集約し、委任管理者アカウントで Organizations 全体のセキュリティイベントを一元管理する。

正解 Security Hub は本アーキテクチャの集約レイヤーを担い、複数のセキュリティサービスからの findings を一元管理して EventBridge に送信します。

この構成により、Organizations 全体のセキュリティ違反を一元的に集約し、EventBridge 経由で修正アクションへ連携します。

全体的な説明

問われている要件

この問題では、リアルタイムでのセキュリティ違反検出と完全自動リメディエーションを行い、変更履歴を監査ログとして記録することが求められています。重要なのは、人的介入を必要としない完全自動化の実現です。

前提知識

1. AWS Security Hub の役割

• AWS リソースのセキュリティコンプライアンスチェックと異常検出を一元管理
• 複数のセキュリティサービス（Config、GuardDuty、Inspector など）からの findings を集約
• findings を EventBridge に送信し、自動アクションを実行可能
• findings の重要度やリソースタイプでフィルタリングして、優先度の高い違反に即座に対応

2. AWS Config の役割

• リソースの設定変更を継続的に監視し、ポリシー違反を即座に検出
• カスタムルールを設定すれば、組織固有のセキュリティ基準を満たさないリソースを特定可能
• Config ルールの評価結果を EventBridge に送信し、Security Hub に findings として集約することで後続の対応フローへ連携
• すべての設定変更履歴が記録され、監査証跡として利用可能

3. Amazon EventBridge の役割

• 本アーキテクチャの実行レイヤーとして、AWS Config の違反イベントと Security Hub の findings をリアルタイムで受信
• イベントの内容（リソースタイプ、違反の種類、重要度など）に基づいて委任管理者アカウントの Lambda 関数を起動
• 複数のターゲット（Lambda、SNS、Step Functions など）を組み合わせた高度なワークフローも構築可能
• すべてのイベント処理履歴が CloudTrail に記録され、監査要件を満たす

解くための考え方

本問題の要件を満たす完全自動化アーキテクチャは以下の通りです：

リアルタイムにリソースのセキュリティ違反を検出する（検出レイヤー） → AWS Config カスタムルールがコンプライアンス違反をリアルタイムに検出し、EventBridge と Security Hub へ送信

複数サービスの findings を一元集約し、EventBridge へ連携する（集約レイヤー） → Security Hub が Config・GuardDuty・Inspector などの findings を集約し、EventBridge へ送信

検出・集約されたイベントをもとに自動修正を実行する（実行レイヤー） → EventBridge が委任管理者アカウントの Lambda をトリガーし、違反リソースを修正

すべての変更を中央で記録する → 委任管理者アカウントでの集中管理 + CloudTrail/Security Hub による監査ログ

なお、「ほぼリアルタイム」とは、Config 評価・EventBridge 配信・Lambda 実行による数秒〜数分程度の技術的遅延を指し、手動介入の必要性を示すものではありません。

参考資料（AWS公式ドキュメント）

• AWS Security Hub のカスタムアクション
• AWS Config ルールの作成
• Amazon EventBridge ルールの設定

正解：A

A.

正解 まず、KMSコンソールでキーの用途を指定し、マルチリージョンキーオプションを有効にします。これはキー作成の最初のステップであり、通常のキーとマルチリージョンキーの違いを決定する重要な選択です。次に、プライマリリージョンでマルチリージョンキーを作成し、エイリアスと説明を設定します。その後、プライマリキーからレプリカキーを作成することで、他のリージョンに同じキーマテリアルを持つキーを展開します。レプリカキー作成時、AWS KMSが自動的に同じキーマテリアルを他リージョンに複製します。各リージョンでレプリカキーが作成された後、アプリケーションやサービスを設定し、最後に動作確認を行います。この順序は、各ステップが前のステップの完了を前提としているため、入れ替えることはできません。

B.

不正解 キーの用途とマルチリージョンオプションを指定する前にキーを作成することはできません。キー作成プロセスは、まずKMSコンソールでキータイプ(マルチリージョンキーか通常のキーか)と用途を指定することから始まります。この設定により、作成されるキーの特性が決定され、キー作成プロセスが開始されます。順序を逆にすると、キー作成の初期設定ができません。

C.

不正解 レプリカキーを作成する前に、プライマリリージョンでマルチリージョンキーを作成する必要があります。プライマリキーが存在しない状態では、レプリカキーの作成元となるキーがないため、レプリカキーを作成することはできません。また、プライマリキーの詳細画面にアクセスすることもできません。キー作成の基本的な流れとして、まずプライマリキーを完成させてから、そのキーを基にレプリカを作成します。

D.

不正解 各リージョンでアプリケーションやサービスを設定する前に、各リージョンにレプリカキーを作成する必要があります。レプリカキーが作成されていない状態では、他のリージョンにはキーが存在せず、アプリケーションやサービスがキーを参照することができません。プライマリリージョン以外のリージョンでキーを使用するには、まずそのリージョンにレプリカキーが存在している必要があります。レプリカキーの作成は、アプリケーション設定の前提条件です。

E.

不正解 この順序では、キーの用途とマルチリージョンオプションを指定する前にキーを作成し、さらにレプリカキーを作成する前にアプリケーションやサービスを設定しようとしています。キー作成プロセスは、まず設定から始まる必要があります。また、各リージョンでレプリカキーが作成されていなければ、そのリージョンのアプリケーションやサービスがキーを使用することができません。各ステップの前提条件が満たされていないため、この順序では正常に動作しません。

F.

不正解 アプリケーションやサービスを設定する前に検証を行うことは論理的に矛盾しています。動作検証では、実際にアプリケーションやサービスがキーを使用してデータを暗号化・復号化できることを確認する必要があります。アプリケーションやサービスが設定されていない状態では、実際の使用状況を検証することができません。検証は、すべての設定が完了した後の最終ステップとして実行する必要があります。

全体的な説明

問われている要件

• 複数のAWSリージョンにわたって配送データを暗号化する必要があります
• AWS KMSカスタマーマネージドキーを作成し、マルチリージョンで使用できるようにする必要があります
• キーの可用性と災害復旧の観点から、複数のリージョンで同じキーマテリアルを使用できるようにする必要があります
• KMSキーの設定手順を正しい順序で実行する必要があります

前提知識

AWS KMSマルチリージョンキーについて

AWS KMSマルチリージョンキーは、複数のAWSリージョンで同じキーマテリアルを使用できる特殊なタイプのカスタマーマネージドキーです。マルチリージョンキーを使用することで、あるリージョンで暗号化したデータを、別のリージョンで復号化できます。これは災害復旧やマルチリージョンアプリケーションのユースケースに最適です。マルチリージョンキーは、プライマリキーと1つ以上のレプリカキーで構成され、すべてのキーが同じキーマテリアルを共有しますが、各リージョンで独立して管理されます。

マルチリージョンキーの作成プロセス

マルチリージョンキーの作成は、キー作成時に「マルチリージョンキー」オプションを有効にすることから始まります。このオプションを選択すると、作成されるキーは通常の単一リージョンキーとは異なる特性を持ちます。プライマリキーを作成した後、そのキーの詳細画面から「レプリカキーの作成」機能を使用して、他のリージョンにレプリカキーを作成できます。レプリカキーの作成時、AWS KMSは自動的にプライマリキーと同じキーマテリアルを使用するため、ユーザーがキーマテリアルをエクスポート・インポートする必要はありません。

レプリカキーの特性

レプリカキーは、プライマリキーと同じキーマテリアルを使用しますが、各リージョンで独立したKMSキーとして機能します。各レプリカキーには独自のキーIDがあり、独立したキーポリシーとアクセス制御を持つことができます。レプリカキーは、そのリージョン内でローカルに暗号化・復号化操作を実行できるため、クロスリージョン呼び出しによるレイテンシーを回避できます。また、あるリージョンが利用不可能になった場合でも、他のリージョンのレプリカキーを使用して継続的にデータにアクセスできます。

マルチリージョンキーのメリット

マルチリージョンキーを使用することで、グローバルに分散したアプリケーションでのキー管理が簡素化されます。あるリージョンで暗号化したデータを、別のリージョンで復号化できるため、災害復旧シナリオやクロスリージョンデータレプリケーションが容易になります。各リージョンでローカルのKMS操作が可能となるため、クロスリージョン呼び出しによるレイテンシーとコストを削減できます。また、すべてのリージョンで同じキーマテリアルを使用するため、キー管理の複雑性が軽減されます。

解くための考え方

この問題では、AWS KMSマルチリージョンキーを作成し、複数のリージョンに展開するための正しい手順を理解する必要があります。各ステップには明確な前提条件があり、順序を間違えると設定が正常に完了しません。

まず、KMSコンソールでキーの用途を指定し、マルチリージョンキーオプションを有効にする必要があります。これはキー作成プロセスの最初のステップであり、通常のキーとマルチリージョンキーの違いを決定する重要な選択です。マルチリージョンキーオプションを有効にしないと、後からレプリカキーを作成することはできません。

次に、プライマリリージョンでマルチリージョンキーを作成し、キーのエイリアスと説明を設定します。プライマリキーは、すべてのレプリカキーの基となるキーであり、最初に作成する必要があります。キーのエイリアスを設定することで、キーIDの代わりにわかりやすい名前でキーを参照できるようになります。

その後、プライマリキーの詳細画面から「レプリカキーの作成」を選択し、他のリージョンにレプリカキーを作成します。このステップにより、複数のリージョンで同じキーマテリアルを使用するキーが展開されます。レプリカキー作成時、AWS KMSが自動的に同じキーマテリアルを他リージョンに複製するため、ユーザーがキーマテリアルを手動でエクスポート・インポートする必要はありません。

各リージョンでレプリカキーが作成された後、各リージョンでキーを使用するアプリケーションやサービス(Amazon S3、Amazon EBS、Amazon RDSなど)を設定し、キーIDまたはエイリアスを使用してキーを参照します。各リージョンにキーが存在していることが、アプリケーション設定の前提条件です。

最後に、各リージョンでキーが正常に機能していることを確認し、暗号化と復号化の操作が正しく実行されることを検証します。各リージョンでキーが正しく設定されていること、アプリケーションやサービスがキーを使用してデータを暗号化できること、暗号化されたデータを正しく復号化できることを確認することで、マルチリージョンでのキー管理が完了したことを確認できます。

この手順の順序は、各ステップが前のステップの完了を前提としているため、入れ替えることはできません。マルチリージョンオプションを指定しなければマルチリージョンキーを作成できず、プライマリキーが作成されていなければレプリカキーを作成できません。また、各リージョンでレプリカキーが作成されていなければ、アプリケーションやサービスがそのリージョンでキーを使用することができません。 参考資料

• AWS KMS カスタマーマネージドキーの作成
• KMS キーのエクスポートとインポート
• マルチリージョンでの KMS キーの使用
• AWS KMS とは
• KMS キーのエイリアスの設定
• AWS KMS キーマテリアルのインポート