問題文（そのまま）
あるセキュリティエンジニアが管理者権限で AWS Lambda コンソールにログインしています。セキュリティエンジニアが、my Function という名前の Lambda 関数のログを Amazon CloudWatch で表示しようとしています。セキュリティエンジニアが Lambda コンソールで CloudWatch でログを表示するオプションを選択すると、「ログストリームの読み込み中にエラーが発生しました」というメッセージが表示されます。IAM Lambda 関数の実行ロールのポリシーには、次の内容が含まれています。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "logs:CreateLogGroup",
"Resource": "arn:aws:logs:us-east-1:111111111111:*"
},
{
"Effect": "Allow",
"Action": ["logs:PutLogEvents"],
"Resource": ["arn:aws:logs:us-east-1:111111111111:log-group:/aws/Lambda/myFunction:*"]
}
]
}
セキュリティエンジニアはどのようにエラーを修正する必要がありますか?
選択肢（そのまま）
① logs:CreateLogGroup アクションを 2 番目の Allow ステートメントに移動します。
② logs:PutDestination アクションを 2 番目の Allow ステートメントに追加します。
③ logs:GetLogEvents アクションを 2 番目の Allow ステートメントに追加します。
④ logs:CreateLogStream アクションを 2 番目の Allow ステートメントに追加します。
正解の選択肢と解説
✅ ④ logs:CreateLogStream アクションを 2 番目の Allow ステートメントに追加します。
- Lambda 関数は 最初にログストリームを作成 (logs:CreateLogStream) → そのストリームに対して logs:PutLogEvents を実行してログを書き込みます。
- 現在の実行ロールには CreateLogStream 権限がないため、Lambda はログストリームを作成できず、結果として CloudWatch Logs コンソールには何も表示されず「ログストリームの読み込み中にエラー」になる。
- CreateLogStream を追加すると、関数起動時にストリームが自動生成され、PutLogEvents でログが書き込まれ、コンソールから閲覧可能になる。
不正解の選択肢の理由
| 選択肢 | 誤りの理由 |
|---|---|
| ① | CreateLogGroup は既に別のステートメントで許可されており、問題はストリームの作成。移動しても解決しない。 |
| ② | PutDestination は CloudWatch Logs サブスクリプションフィルタ用。ログストリーム作成・書き込みには関係しない。 |
| ③ | GetLogEvents はログ「閲覧」用の API。ログを書き込めない現状では追加してもエラーは続く。 |
SCS 試験で押さえておくべきポイント
- Lambda 実行ロールに必要な CloudWatch Logs 権限
logs:CreateLogGroup（初回のみ）logs:CreateLogStream（各インスタンス起動時）logs:PutLogEvents（ログ書き込み）
- エラーの見分け方
- ログストリームが「存在しない」エラーは CreateLogStream 欠如が典型。
- 「アクセス拒否」エラーは IAM ポリシーのリソース ARN かキーポリシーの不足を疑う。
- 実行ロールと閲覧ロールの違い
- 実行ロール: Lambda が自身のログを書き込むための権限。
- 閲覧者ロール/ユーザー: CloudWatch で
logs:GetLogEvents,logs:DescribeLogStreamsが必要。
- デバッグ手順
- CloudWatch Logs のメトリクスフィルタやコンソールで「ロググループはあるがストリームが無い」→ CreateLogStream をチェック。
この流れを理解しておくと、Lambda と CloudWatch Logs に関する権限エラーを迅速に解決できます。
問題文
【SCS-143】ある組織の開発者は、アプリケーションをコンテナにデプロイしました。
セキュリティエンジニアは、コンテナの安全性を確保したいと考えています。
次の選択肢のうち攻撃を減らし、コンテナのセキュリティを強化するのはどれですか？(2つ選択)
選択肢
- コンテナを使用して、デプロイを自動化します。
- リソースの消費（CPU、メモリ）、ネットワーク接続、ポート、不要なコンテナ・ライブラリの制限を行います。
- ホスト、機能、データ分類でコンテナを分離します。
- Docker Notaryを使用して、タスク定義に署名します。
- ホストカーネルでコンテナブレークアウトを有効にする。
Docker Notary はイメージ（OCI/Docker イメージ）の署名には使えますが、ECS や EKS の「タスク定義」自体を署名する仕組みはありません。試験の文脈では 4 は該当しないため、正解は 2 と 3 になります。以下に修正文をまとめます。
| 正解 | 攻撃面削減・セキュリティ強化の理由 |
|---|---|
| 2. リソースの消費（CPU、メモリ）、ネットワーク接続、ポート、不要なコンテナ・ライブラリの制限を行う | 最小権限・サンドボックス化：cgroups で CPU/メモリ制限、--cap-drop や seccomp/AppArmor/SELinux で権限・システムコールを絞り、不要パッケージを削除。DoS や権限昇格のリスクを低減。 |
| 3. ホスト、機能、データ分類でコンテナを分離する | ワークロード分離：機密度や機能ごとにホスト／名前空間／ネットワークを分けることで水平移動やデータ混在のリスクを抑える。Kubernetes の Namespaces、ECS のタスクレベル ENI などで実装可。 |
不正解の選択肢 (再評価)
| 選択肢 | 理由 |
|---|---|
| 1 | デプロイ自動化は運用効率化であって直接的な攻撃面削減策ではない。 |
| 4 | Notary はイメージ署名のツールであり「タスク定義」を署名することはできない。したがって設問の意図に合わない。 |
| 5 | 「コンテナブレークアウトを有効にする」はセキュリティを弱める行為。 |
②→制限を行うことにより侵入されたとしてもコンテナ外への影響を軽減できる。
③→コンテナを分離することで、コンテナ内で動くプロセスの動作がホストに影響しにくくなるためセキュリティリスクが低くなる。
問題文（原文）
【SCS-144】ある会社は、顧客管理の CMK の削除を監視したいと考えています。
セキュリティエンジニアは、CMK が削除される前に会社に通知するアラームを作成する必要があります。
セキュリティエンジニアは、AWS CloudTrail と Amazon CloudWatch を統合しました。
セキュリティエンジニアは、この要件を満たすために次に何をする必要がありますか?
選択肢（そのまま）
- AWS Key Management Service (AWS KMS) 内で、CMK の作成中にキー マテリアルの削除時間を指定します。AWS KMS は CloudWatch アラームを自動的に作成します。
- DeleteAlias の API 呼び出しを探すための Amazon EventBridge (Amazon CloudWatch Events) ルールを作成します。Amazon SNS メッセージを会社に送信する AWS Lambda 関数を作成します。EventBridge ルールのターゲットとして Lambda 関数を追加します。
- DisableKey と ScheduleKeyDeletion の API 呼び出しを探す Amazon EventBridge (Amazon CloudWatch Events) ルールを作成します。Amazon SNS メッセージを会社に送信する AWS Lambda 関数を作成します。EventBridge ルールのターゲットとして Lambda 関数を追加します。
- Amazon SNS ポリシーを作成して、RevokeGrant と ScheduleKeyDeletion の AWS KMS API コールを探します。アラームを生成し、会社に通知を送信する AWS Lambda 関数を作成します。SNS ポリシーのターゲットとして Lambda 関数を追加します。
正解の選択肢と解説
✅ 3. DisableKey と ScheduleKeyDeletion の API 呼び出しを探す EventBridge ルールを作成し、SNS で通知する
| 理由 | 詳細 |
|---|---|
| CMK 削除の手順 | KMS では CMK を削除する前に DisableKey（キー無効化）→ ScheduleKeyDeletion（削除予約）を必ず実行する。両 API コールは CloudTrail に記録される。 |
| リアルタイム検知 | EventBridge ルールで detail.eventName が DisableKey または ScheduleKeyDeletion のイベントをマッチさせ、即時にターゲット (Lambda / SNS) を起動できる。 |
| 通知ワークフロー | ルールのターゲットとして Lambda を指定し、その Lambda から SNS へパブリッシュすればメール・Slack などへ即座にアラート送信可能。 |
不正解の選択肢のポイント
| 選択肢 | 誤りの理由 |
|---|---|
| 1 | キーマテリアル削除時刻を指定しても CloudWatch アラームは自動作成されない。監視要件を満たさない。 |
| 2 | DeleteAlias は CMK の削除プロセスとは無関係（エイリアスを消すだけ）。監視対象 API が誤り。 |
| 4 | SNS ポリシーで API 呼び出しを直接フィルタする機能はない。RevokeGrant も削除予約とは無関係。設計が不適切。 |
SCS 試験で押さえておくべきポイント
- CMK 削除フロー
DisableKey→ScheduleKeyDeletion(7–30 日後に物理削除)
- 監視方法
- CloudTrail で管理 API を記録し、EventBridge ルールでフィルタ。
- 早期警告が必要なら
ScheduleKeyDeletionをフックするのが最も確実。
- 通知実装
- ルール → SNS 直接、あるいは Lambda で整形して SNS/PagerDuty/ChatOps へ送信。
- KMS と CloudWatch の連携
- KMS は自動アラームを作らない。監査・通知は EventBridge／SNS／Lambda を組み合わせるのが定石。
この手順を覚えておくと、KMS キーライフサイクルの監視とアラートを問う SCS 問題で確実に対応できます。
問題文（原文そのまま）
【SCS-145】ある会社は複数の本番AWSアカウントを持っています。
各アカウントは、中央のアカウントで単一のAmazon S3バケットにロギングするように構成されたAWS CloudTrailを持っています。
本番アカウントの2つは、S3バケットに何もログを記録していない状態となっています。
トラブル解消のため以下のどのステップを踏む必要がありますか(3つを選んでください)。
選択肢（原文そのまま）
1. ログファイルのプレフィックスが、ログが入るべきS3バケットの名前に設定されていることを確認します。
2. S3バケットポリシーで、本番用AWSアカウントIDのCloudTrailからのアクセスを許可していることを確認します。
3. アカウントに新しいCloudTrail構成を作成し、アカウントのS3バケットにログを記録するように構成します。
4. CloudTrailコンソールで、各トレイルがアクティブで問題ないことを確認します。
5. マスターアカウントでグローバルCloudTrailの設定を開き、ストレージの場所が正しいS3バケットに設定されていることを確認します。
6. CloudTrailコンソールで、S3バケット名が正しく設定されていることを確認します。
正解の選択肢と解説
| 正解 | 解説 |
|---|---|
| 2 | クロスアカウント書き込み許可がないと CloudTrail は中央バケットへ PutObject できず、ログは保存されない。バケットポリシーで Principal を各本番アカウントの ID（または cloudtrail.amazonaws.com）にし、s3:PutObject を許可する必要がある。 |
| 4 | まず Trail が有効 (Status: Logging = ON) であることを確認。誤って停止・削除・リージョン無効になっていればログは生成されない。 |
| 6 | 2 つのアカウントだけ 送信先バケット名／フォルダ が間違っている可能性があるため、CloudTrail 設定で中央バケット名と正しいパスが入力されているかをチェックする。 |
不正解の選択肢の理由
| 選択肢 | 理由 |
|---|---|
| 1 | オブジェクトキーの プレフィクスは自由。バケット名と一致している必要はなく、ログ未着の主因にはなりにくい。 |
| 3 | 既存 Trail を修正・調査せずに新規 Trail を作るのは根本原因の解決にならない。 |
| 5 | 設問では「各アカウントに個別 CloudTrail があり中央バケットへ出力」なので、Organizations 一括 Trail（マスターアカウントで設定）とは前提が異なる。 |
SCS試験で押さえておくべきポイント
- クロスアカウント CloudTrail
- バケットポリシーに
s3:PutObjectとs3:GetBucketAclを許可。 aws:SourceArnやaws:SourceAccount条件で限定するとより安全。
- バケットポリシーに
- Trail ステータス確認
- CloudTrail コンソールまたは CLI
describe-trails→get-trail-statusでIsLoggingを確認。
- CloudTrail コンソールまたは CLI
- 送信先設定ミス
- バケット名・リージョン・キー prefix のタイプミスが典型的な原因。
- 最小修正アプローチ
- まず設定と権限を点検 → それでも駄目なら再作成。
この流れを覚えておけば、CloudTrail ログが集約バケットに届かないトラブルの原因特定と解決手順を迅速に提示できます。
問題文（そのまま）
【SCS-146】ある組織は、すべてのAWSアカウント内で発生したAWS APIコールを記録したいと考えており、これらのログを一元的に分析する必要があります。
最も安全な方法でこれらの要件を満たすために、どのような組み合わせで手順を実行する必要がありますか？（2つ選択）
選択肢（そのまま）
1. 各AWSアカウントでAWS CloudTrailを有効にします。
2. ログを保存するアカウントのみCloudTrailをONにします。
3. ログを保存するアカウントにて、バケットのACLを更新し、他のアカウントからログを取得できるようにします。
4. CloudTrailのサービスベースのロールを作成し、各アカウントでCloudTrailと関連付けます。
5. ログを保存するアカウントにて、バケットポリシーを更新し、他のアカウントからログを取得できるようにします。
正解の選択肢と解説
| ✔ | 手順 | なぜ必要か |
|---|---|---|
| 1 | 各 AWS アカウントで AWS CloudTrail を有効にする。 | すべての API コールを確実に取得する最も公式な方法。組織 Trail を使う場合でも、管理アカウント側で “すべてのアカウントを含む” トレイルを作成すれば内部的にメンバーアカウントでも CloudTrail が有効化される。 |
| 5 | 中央ログ保存用アカウントで S3 バケットポリシーを更新し、他アカウントの CloudTrail からの PutObject を許可する。 | クロスアカウント書き込みは ACL ではなくバケットポリシー が推奨。Principal に各アカウント ID もしくは cloudtrail.amazonaws.com を指定し、s3:PutObject と s3:GetBucketAcl を許可することで、安全かつ最小権限でログを受け取れる。 |
不正解の選択肢の理由
| ✖ | 誤りのポイント |
|---|---|
| 2 | 中央アカウントだけで CloudTrail を有効にしても、他アカウントで発生した API コールは記録されない。組織 Trail を設定しない限り非対応。 |
| 3 | ACL は細かな制御が難しく、推奨されない。バケットポリシー (選択肢 5) での許可がベストプラクティス。 |
| 4 | CloudTrail はサービスロール不要。各アカウントに IAM ロールを関連付ける設定は存在しないため無意味。 |
SCS 試験で押さえておくべきポイント
- 組織レベルの CloudTrail
- Organizations を使用すると、管理アカウントの単一トレイルで全メンバーアカウントの API コールを取得可能。
- 中央集約バケットの権限設定
- バケットポリシー で
s3:PutObjectを許可し、aws:SourceArn/aws:SourceAccount条件で絞るとより安全。
- バケットポリシー で
- ACL よりポリシー
- ACL はレガシー。クロスアカウントアクセスにはバケットポリシーを使うのが推奨。
- サービスロール不要
- CloudTrail はフルマネージドで、別途 IAM ロールを作る必要はない。
この組み合わせで、全アカウントの API コールを安全に集約し、中央で一元分析できる構成が完成します。
問題文
【SCS-148】ある開発者は会社の開発アカウントで AWS Lambda 関数を作成しました。
この関数は、会社のセキュリティアカウントにある AWS KMS のカスタマー管理キー (CMK) を使って暗号化／復号化する必要があります。
以前に同じキーを利用していた旧 Lambda 関数は正常に動作していますが、新しい関数をテストすると「KMS キーへのアクセスが拒否されました」というエラーになります。
開発アカウントの新しい Lambda 関数でも、そのセキュリティアカウントの CMK を使用できるようにするには、次のうち どの手順を組み合わせる必要がありますか？（2 つ選択）
選択肢（そのまま）
- セキュリティアカウントで、新しい Lambda 関数の IAM ロールを設定します。セキュリティアカウントで KMS キーへのアクセスを許可する IAM ポリシーをアタッチします。
- 開発アカウントで、新しい Lambda 関数の IAM ロールを設定します。セキュリティアカウントで KMS キーへのアクセスを許可するキーポリシーをアタッチします。
- 開発アカウントで、新しい Lambda 関数の IAM ロールを設定します。セキュリティアカウントの KMS キーへのアクセスを許可する IAM ポリシーをアタッチします。
- セキュリティアカウントで KMS キーのキーポリシーを設定して、セキュリティアカウントで新しい Lambda 関数の IAM ロールへのアクセスを許可します。
- セキュリティアカウントの KMS キーにキーポリシーを設定し、開発アカウントの新しい Lambda 関数の IAM ロールにアクセスできるようにします。
正解
- 3. 開発アカウントで新しい Lambda 関数の IAM ロールを設定し、セキュリティアカウントの KMS キーへのアクセスを許可する IAM ポリシー をロールに付与する。
- 5. セキュリティアカウント側で KMS キーのキーポリシー を更新し、開発アカウントの新しい Lambda ロールを Principal として許可する。
解説
| 手順 | 目的 |
|---|---|
| ③ IAM ポリシーをロールに付与 | Lambda 実行ロールが kms:Encrypt / kms:Decrypt などのアクションを そのキー ARN に対して許可されている必要がある。ロール側にポリシーが無いと、たとえキーがロールを信頼していてもアクセスは拒否される。 |
| ⑤ キーポリシーにロールを追加 | クロスアカウントで CMK を使わせるには、キー自身のポリシーに相手アカウントのロール ARN を Principal として明示する必要がある（またはアカウントレベルで許可してもよい）。これが無いと KMS がアクセスを拒否する。 |
旧 Lambda 関数が動いていたのは、その関数の実行ロール ARN がすでにキーポリシーに登録されており、かつロールに KMS 権限があったため。新しい関数は別ロールを使っているので、同じ 2 か所（IAM ポリシー & キーポリシー）の調整が必要になります。
不正解の選択肢
| 選択肢 | なぜ誤りか |
|---|---|
| 1 | Lambda 実行ロールは開発アカウント側に存在するはず。セキュリティアカウントでロールを作成しても関数は使用しない。 |
| 2 | キーポリシーは必要だが、IAM ポリシー側の権限が不足していると依然 AccessDenied になる。 |
| 4 | キーポリシーで許可すべき Principal は「開発アカウントのロール」。セキュリティアカウントのロールを許可しても無関係。 |
ポイント
- KMS クロスアカウント利用は「キーのキーポリシー」と「呼び出し側 IAM ポリシー」の両方で許可が揃って初めて成功する。
- Lambda 新規関数を作ると 新しい実行ロールが割り当てられることが多いので、ロール ARN をキーポリシーに追加し直すのを忘れがち。
問題文（そのまま）
【SCS-149】ある組織は、Amazon EC2インスタンス上で実行される3層のWebアプリケーションを構築することを望んでいます。
これらのEC2インスタンスは、Amazon RDS DBインスタンスへのSQL接続を認証するために使用される資格情報へのアクセスを必要とします。
また、AWS Lambda関数は、同じデータベース認証情報を使用してRDSデータベースにクエリを発行する必要があります。
認証情報は、EC2インスタンスとLambda関数がアクセスできるように保存する必要があります。
それ以外のアクセスは許可されません。
アクセスログは、資格情報がいつ、誰によってアクセスされたかを記録する必要があります。
セキュリティエンジニアは、これらの要件を満たすために何をすべきですか？
（2つ選んでください。)
選択肢（そのまま）
- AWS Key Management Service (AWS KMS)にデータベース認証情報を格納する。ロールの信頼ポリシーでEC2およびLambdaサービスのプリンシパルを使用して、AWS KMSにアクセスできるIAMロールを作成する。EC2インスタンスのプロファイルにロールを追加する。インスタンスプロファイルをEC2インスタンスにアタッチする。Lambdaが新しいロールを使用して実行できるように設定する。
- データベースの認証情報をAWS KMSに格納する。EC2とLambdaサービスのプリンシパルを使用して信頼ポリシーでKMSにアクセスできるIAMロールを作成する。EC2インスタンスプロファイルにロールを追加する。インスタンスプロファイルをEC2インスタンスとLambda関数にアタッチする。
- AWS Secrets Managerにデータベースの認証情報を格納する。EC2とLambdaサービスのプリンシパルを使用して信頼ポリシーでSecrets ManagerにアクセスできるIAMロールを作成する。EC2インスタンスプロファイルにロールを追加する。インスタンスプロファイルをEC2インスタンスとLambda関数にアタッチする。
- AWS Secrets Managerにデータベースの認証情報を格納する。EC2とLambdaサービスのプリンシパルを使用して信頼ポリシーでSecrets ManagerにアクセスできるIAMロールを作成する。EC2インスタンスプロファイルにロールを追加する。新しいロールを実行に使用するようにLambdaを設定する。
正解 🎯
- 3
- 4
解説
| 選択肢 | どう要件を満たすか |
|---|---|
| 3 & 4 共通のポイント | AWS Secrets Manager は・RDS 資格情報を安全に保存し、IAM ポリシーで EC2/Lambda の実行ロールだけに取得 (secretsmanager:GetSecretValue) を許可・アクセスは CloudTrail に記録されるため「いつ誰が取得したか」を監査できるIAM ロール を EC2 インスタンスプロファイルに追加し、Lambda の実行ロールにも設定すれば “EC2 と Lambda だけが取得” という境界を実現できる。 |
| 3 | 同じロールを両方のワークロードで使う構成を示唆。単一ロールで権限管理を簡素化したい場合に合致。 |
| 4 | EC2 用ロールをインスタンスプロファイルに、Lambda はそのロールを明示的に実行ロールとして設定する構成。AWS 推奨の付与手順を踏んでいる。 |
なぜ 1 と 2 は不適切か？
| 選択肢 | 理由 |
|---|---|
| 1・2 | KMS は暗号鍵を管理するサービスであって “認証情報そのものを保管する場所” ではない。 秘密値の保存と自動ローテーション、取得ログの可視化といった要件には Secrets Manager が適切。 |
Secrets Manager + IAM ロールの組み合わせにより、最小権限アクセス・中央管理・取得ログ監査という 3 点をすべて満たせます。
ご指摘どおり 3 は誤りです。
Lambda にはインスタンスプロファイル（EC2 のみで使う入れ物）をアタッチできないため、手順 3 の記述は実装不可能です。
現状の選択肢を整理すると
| 番号 | サービス | 主な問題点 | 可否 |
|---|---|---|---|
| 1 | KMS に直接パスワードを保管 | KMS は鍵管理サービスであってシークレット保管庫ではない | ❌ |
| 2 | KMS + 同一ロールを EC2/Lambda に付与 | そもそも KMS に直接保管できないうえ、Lambda にインスタンスプロファイルは不可 | ❌ |
| 3 | Secrets Manager + インスタンスプロファイルを EC2/Lambda に付与 | Lambda にインスタンスプロファイルを付与は不可 | ❌ |
| 4 | Secrets Manager + EC2 インスタンスプロファイル + Lambda 実行ロールに同じ IAM ロールを割り当てる | 要件をすべて満たす | ✅ |
傍注
- Secrets Manager はデフォルトで KMS 暗号化されます。
- 取得操作は CloudTrail に記録されるため「いつ／誰が」も監査可能です。
- ロールの信頼ポリシーを
{ "Service": ["ec2.amazonaws.com","lambda.amazonaws.com"] }のように 2 つのサービスプリンシパルを並べれば、同じロールを EC2 と Lambda の両方から引き受けできます。
- あるいは 別々のロール（EC2 用、Lambda 用）にして、それぞれに
secretsmanager:GetSecretValueを許可しても構いません。
結論
- 正解は “手順 4 のみ” です。
- 「2 つ選択せよ」とありますが、提示されている 4 つの選択肢のうち実装可能なのは 4 だけです。おそらく設問の記述ミス、または選択肢が 1 つ欠落している可能性があります。
もし本番試験で同様の矛盾に遭遇した場合:
- 最も AWS ベストプラクティスに沿うもの（＝ Secrets Manager を使い、適切なロールを割り当て、CloudTrail で監査できるもの）を選ぶ。
- 選択肢数の指示と合わなくても、技術的に唯一正しいものを優先する。
それでも疑問が残る場合は、試験後の コメント欄 に「選択肢の数が矛盾していた」旨を報告しておくと採点時に考慮されることがあります。
問題文（そのまま）
【SCS-150】ある会社が、Webサイト用の画像をAmazon S3バケットに保存しています。
同社は、エンドユーザーに画像を提供するためにAmazon CloudFrontを使用しています。
最近、同社が配布ライセンスを持っていない国から画像がアクセスされていることを発見しました。
画像の配布を制限するために、どの措置を取るべきですか？(2つ選んでください)
選択肢（そのまま）
- S3バケットのポリシーを更新し、CloudFrontのオリジンアクセスID（OAI）へのアクセスを制限します。
- ウェブサイトのDNSレコードを更新して、Amazon Route 53のジオロケーションレコードを使用するようにし、ライセンスを持っていない国のリストを拒否する。
- 会社がライセンスを欠いている国のCloudFrontジオブロックの拒否リストを追加します。
- ライセンスを欠いている国の拒否リストでS3バケットポリシーを更新します。
- CloudFrontのRestrict Viewer Accessオプションを有効にして、ライセンスを持たない国の拒否リストを作成します。
正解の選択肢と解説
| ✔ | 措置 | 目的と効果 |
|---|---|---|
| 1 | S3 バケットポリシーを更新し、CloudFront OAI だけを許可 | 直接 S3 へアクセスされる抜け道を遮断し、配信経路を CloudFront に強制することで国別ブロックが確実に適用される。 |
| 3 | CloudFront のジオブロック（Geo restriction）でライセンス対象外の国を拒否リストに追加 | CloudFront エッジでリクエストを遮断し、指定国からの画像配布を停止。ログにも拒否情報が記録される。 |
なぜ他の選択肢は不適切か
| ✖ | 理由 |
|---|---|
| 2 | Route 53 ジオロケーションは DNS レコードの返答先を変える機能。ユーザが既に CloudFront のドメインを知っている場合や IP を直打ちした場合には回避可能で、完全な制御にならない。 |
| 4 | S3 バケットはリクエスト元 IP だけでは国を判定しないため、国ごとに拒否リストを組むことはできない。バケットポリシーで国制限は実装不可。 |
| 5 | Restrict Viewer Access は 署名付き URL/クッキー を強制する機能であり、国によるブロックは行えない。 |
SCS 試験で押さえておくポイント
- S3 + CloudFront ベストプラクティス
- 公開オブジェクトを CloudFront 経由のみにするには OAI/OAC とバケットポリシーで「
aws:Refererではなく OAI/OAC ARN」を許可。
- 公開オブジェクトを CloudFront 経由のみにするには OAI/OAC とバケットポリシーで「
- Geo restriction
- CloudFront のジオブロックは国コード（ISO 3166-1 alpha-2）単位で Allow list か Deny list を設定。国別ライセンス制御の王道。
- なぜ Route 53 では不十分か
- DNS で名前解決を拒否しても、既にキャッシュ済みのエンドポイントや直 IP で回避可能。真のアクセス制御は配信レイヤで行う必要がある。
- 署名付き URL/クッキー
- ユーザ属性（課金ユーザ等）で配信を制限したいケース向け。国別ブロックとは別のユースケース。
この 2 つの措置を組み合わせることで、ライセンスを持たない国からのアクセスを CloudFront でブロックし、S3 直アクセスも排除できる最も安全な構成になります。
