以下に、問題の解説をSCS対策用にまとめました。
・問題文
【SCS-122】ある企業が、アプリケーション用にAWS WAFとAmazon CloudFrontを導入しました。
アプリケーションは、AutoScalingグループの一部であるAmazon EC2インスタンス上で実行されます。
Auto Scaling グループは Application Load Balancer (ALB) の背後にあります。
AWS WAF ウェブ ACL は AWS Managed Rules ルール グループを使用し、CloudFront ディストリビューションに関連付けられています。
CloudFront は AWS WAF からリクエストを受け取り、ALB をディストリビューションのオリジンとして使用します。
セキュリティレビュー中に、セキュリティエンジニアは、インフラストラクチャが大規模なレイヤ7 DDoS攻撃の影響を受けやすいことを発見しました。
セキュリティエンジニアは、このタイプの攻撃を防御するために、ソリューションのエッジでどのようにセキュリティを向上させることができますか？
・選択肢
A. Lambda@Edge機能を使用するようにCloudFrontディストリビューションを設定します。CloudFrontのビューワーリクエストにレート制限をかけるAWS Lambda関数を作成します。レート制限を超えた場合、リクエストをブロックします。
B. AWS WAFのWeb ACLは、すべてのAWS WAFルールをより速く処理するために、より多くのキャパシティユニットを持つように構成します。
C. レート制限を超えた場合に自動的にリクエストをブロックするレートベースのルールをAWS WAFに設定します。
D. ALB ではなくAWS WAF をオリジンとして使用するように CloudFront ディストリビューションを設定します。
・正解の選択肢と解説
正解：C
解説：
AWS WAFには「レートベースルール」があり、特定のIPアドレスからのリクエストが一定のしきい値を超えた場合に自動的にブロックできます。
この機能はCloudFrontと組み合わせてL7（アプリケーション層）のDDoS攻撃に対する第一の防御手段として有効です。
「エッジでのセキュリティ向上」かつ「大規模アクセス制御」には、AWS WAFのレートベースルールが推奨されます。
・不正解の選択肢の理由
A（Lambda@Edgeでレート制限）：
Lambda@Edgeで自作のレート制限ロジックを実装するのは技術的には可能ですが、スケーラビリティや管理面で非効率で、WAFのレートベースルールのような専用機能の方が圧倒的に適しています。
B（キャパシティユニットの増加）：
AWS WAFには「Web ACL capacity unit（WCU）」がありますが、WCUはルールの処理能力のリソース目安であり、レート制限やDDoS対策機能ではありません。この選択肢は目的に合いません。
D（AWS WAFをオリジンに設定）：
AWS WAFはオリジン（＝CloudFrontからのリクエスト先）にはなりません。ALBやS3などがオリジンであり、この記述はAWSの設計上不正確です。
・SCS試験で押さえておくべきポイント
- AWS WAFのレートベースルールは、L7 DDoSの緩和策として有効。IPごとのしきい値設定が可能。
- CloudFrontとWAFの組み合わせはDDoS防御のエッジ戦略の基本。
- Lambda@Edgeは柔軟性が高いがDDoS対策には不向き（正確なレート追跡が困難でコスト高）。
- WAFのWCUは処理能力指標であり、DDoS防御とは直接関係しない。
- CloudFrontのオリジン設定はALBやS3などが対象であり、WAFをオリジンにすることはできない。
次の問題もどうぞお送りください。引き続き対応いたします。
以下に、SCS試験対策の形式で詳細解説を行います。
・問題文
【SCS-123】最近、セキュリティエンジニアが me-south-1 リージョンを有効にしました。
セキュリティエンジニアは現在、IAM ロールを設定しており、me-south-1 のエンドポイントに API 呼び出しを行っています。
API 呼び出しは、次のエラーを返します:
「AuthFailure: AWS was not able to validate the provided access credentials（AWS は、提供されたアクセス資格情報を検証できませんでした）」
どのソリューションを使用すれば、このエラーは解決しますか?（2つ選んでください。）
・選択肢
A. iam:SetSecurityTokenServicePreferences アクションをセキュリティエンジニアの IAM ロールに追加します。
B. me-south-1 の AWS Security Token Service (AWS STS) エンドポイントを使用して、STS トークンを取得します。
C. us-east-1 リージョンの AWS Security Token Service (AWS STS) エンドポイントを使用して、STS トークンを取得します。
D. me-south-1 で AWS Security Token Service (AWS STS) エンドポイントを手動で有効化します。
E. AWS STS のグローバルエンドポイントを、リージョン互換のセッショントークンを発行するように変更します。
・正解の選択肢と解説
正解：B, E
✅ B. me-south-1 の STS エンドポイントを使用して、STS トークンを取得する
理由：me-south-1 のような一部のリージョンでは、デフォルトで STS リージョンエンドポイントが無効になっており、そのリージョンの STS を使ってトークンを取得する必要があります。
グローバルSTSで取得したトークンは**リージョン非対応トークン（legacy token）**であるため、me-south-1 では認証されず、AuthFailureが発生します。
✅ E. グローバルSTSを、リージョン互換のセッショントークンを発行するよう変更する
理由：
AWSでは SetSecurityTokenServicePreferences API を使用して、グローバルSTSがリージョン互換のトークンを発行するように設定できます。
この設定をすると、us-east-1 などのグローバルエンドポイントから取得したトークンでも me-south-1 を含むリージョンで認証可能になります。
・不正解の選択肢の理由
A.
このアクション（SetSecurityTokenServicePreferences）をロールに許可するだけでは設定は変わらず、実際にAPIを呼び出す操作が必要。選択肢A単独では解決になりません。
C.us-east-1 のグローバルSTSで取得したデフォルトの非リージョン互換トークンは、me-south-1 では認証されません。設定変更（選択肢E）なしではエラーの原因となります。
D.
STSエンドポイントの有効化は手動ではできません。me-south-1 のSTSはすでに管理された形で提供されており、利用者が「有効化」する操作は不要です。
・SCS試験で押さえておくべきポイント
✅ リージョン互換トークンの必要性：
- 特定リージョン（例：
me-south-1,ap-east-1）ではリージョン互換トークンが必須。 - グローバルSTS（
us-east-1）は、デフォルトでは非互換トークンを返す。
✅ トークンの互換設定方法：
SetSecurityTokenServicePreferencesを使って、リージョン互換のトークンを発行するように変更可能。
✅ STSはリージョンごとにエンドポイントがある：
me-south-1などのリージョンに合わせて、正しいSTSエンドポイントを使うことが重要。
次の問題もお待ちしています！
以下に、SCS-124の問題についてSCS試験対策の形式で解説します。
・問題文
【SCS-124】ある大企業のセキュリティエンジニアは、1500社の子会社が使用するデータ処理アプリケーションを管理しています。
この大企業では、親会社と子会社がすべてAWSを使用しています。
データ処理アプリケーションはTCPポート443を使用し、ネットワークロードバランサー（NLB）の背後にあるAmazon EC2上で実行されています。
コンプライアンス上の理由から、アプリケーションは子会社のみがアクセスでき、公共のインターネット上では通信できないようにする必要があります。
この要件を満たすために、エンジニアは各子会社のパブリックとプライベートのCIDRブロック範囲を受け取りました。
エンジニアはアプリケーションに適切なアクセス制限を実装するためにどのようなソリューションを使用すべきですか？
・選択肢
A. 1500社の子会社のCIDRブロック範囲からTCPポート443でのアクセスを許可するNACLを作成します。NACLをNLBとEC2インスタンスの両方に関連付けます。
B. 1500社の子会社のCIDRブロック範囲からのTCPポート443でのアクセスを許可するために、セキュリティグループを作成します。そのセキュリティグループをNLBに関連付けます。NLBセキュリティグループからTCPポート443でアクセスするEC2インスタンス用の2つ目のセキュリティグループを作成してEC2に関連付けます。
C. NLBがある親会社のアカウントにAWS PrivateLinkのエンドポイントサービスを作成します。セキュリティグループを作成し、AWS PrivateLinkエンドポイントからTCPポート443でアクセスできるようにしてEC2に関連付けます。データ処理アプリケーションに接続するために、1500の子会社のAWSアカウントでAWS PrivateLinkインターフェースエンドポイントを使用します。
D. セキュリティグループを作成し、1500社の子会社CIDRブロック範囲からのTCPポート443でのアクセスを許可します。セキュリティグループをEC2インスタンスに関連付けます。
・正解の選択肢と解説
正解：C
✅ 解説：
この問題の要件は以下の通りです：
- 通信は インターネットを経由せずに行うこと（＝PrivateLinkが必要）
- 親会社側のアプリケーションに、子会社のみアクセスできる
- 子会社はすべて AWS アカウントを持っている
- 接続数が 大規模（1500社）
これらの条件を効率的かつセキュアに満たすには、PrivateLink（VPCエンドポイントサービス＋インターフェースエンドポイント）を利用するのがベストです。
PrivateLinkは、親アカウントが提供するサービスに対して、他のアカウントがプライベートIP経由でアクセスできる仕組みです。
・不正解の選択肢の理由
❌ A. NACL を使用してアクセスを制限
- NACLはステートレスで、CIDR単位の許可しかできず、1500社分のCIDR管理は現実的ではありません。
- また、NACLはVPC単位でしか適用できないため、アカウントをまたいだアクセス制御ができません。
❌ B. セキュリティグループをNLBとEC2に関連付けて制限
- NLB（Network Load Balancer）はセキュリティグループを持ちません。
- セキュリティグループでの制限はALBで可能ですが、NLBでは無効です。
- アカウント間通信を制御する手段としても不適切です。
❌ D. セキュリティグループにCIDRを許可
- セキュリティグループは有効ですが、1500社分のCIDR範囲を一つずつ手動で設定するのは管理的に非効率ですし、セキュリティグループのルール数にも上限があります（ルールごとに50程度）。
- インターネット経由でのアクセス制限にはならないため、要件を満たしません。
・SCS試験で押さえておくべきポイント
✅ AWS PrivateLink（エンドポイントサービス + インターフェースエンドポイント）：
- 他アカウントからのプライベートアクセスを可能にするベストプラクティス。
- インターネットを経由せずに、セキュアな通信が可能。
- サービスプロバイダー（親会社）は NLB を介してサービスを提供。
- サービスコンシューマー（子会社）は Interface Endpoint をVPC内に作成。
✅ セキュリティグループ vs NACL の適用範囲と用途：
- SG：ステートフル・インスタンス単位
- NACL：ステートレス・サブネット単位
✅ NLBはセキュリティグループを持たない
ご希望があれば、この内容を暗記カード形式やポイント表形式でまとめることも可能です。次の問題もどうぞお送りください！
以下に【SCS-125】の問題に関する詳細解説をお届けします。
・問題文
【SCS-125】ある企業は、EC2上のDocker上で実行されている数百のアプリケーションが中央の場所にログを送信する必要があるフォレンジックロギングのシステムを保有しています。
セキュリティエンジニアは、ログファイルのリアルタイム分析を実行することができ、イベントを検証することができ、データを永続に保存するロギングソリューションを作成する必要があります。
どのサービスを組み合わせるのが適切でしょうか。
（2つを選択します。）
・選択肢
A. Amazon Elasticsearch（OpenSearch）
B. Amazon Kinesis
C. Amazon SQS
D. Amazon CloudWatch
E. Amazon Athena
・正解の選択肢と解説
正解：A（OpenSearch）, B（Kinesis）
✅ A. Amazon OpenSearch（旧Elasticsearch）
理由：
- OpenSearchはログデータをリアルタイムで検索・可視化・分析できるエンジンです。
- Kibana/OpenSearch Dashboardsを使ってフォレンジック分析や可視化も可能です。
- 長期保存にも使える（ただし保存コストには注意）。
✅ B. Amazon Kinesis（Data Streams / Firehose）
理由：
- EC2上のDockerアプリからのログをストリーミングでリアルタイムに処理できる。
- Kinesis Firehoseを使えば、OpenSearchやS3、CloudWatch Logsなどに自動的に配信可能。
- 高スループット・リアルタイム処理に最適。
・不正解の選択肢の理由
❌ C. Amazon SQS
- SQSはメッセージキューであり、リアルタイムログ処理や検索には不向き。
- フォレンジックロギングの要件である「リアルタイム分析」「可視化」はサポートしません。
❌ D. Amazon CloudWatch
- CloudWatch Logsにログを送信するのは一般的ですが、検索や可視化には制限が多く、複雑な分析には不向き。
- また、DockerコンテナからCloudWatch Logsに直接送るにはエージェント設定が必要で柔軟性に欠ける。
- 分析よりはモニタリング/アラート用途に強み。
❌ E. Amazon Athena
- AthenaはS3上にあるログをバッチ的にクエリするには便利だが、リアルタイム性がない。
- また、Kinesisのような即時配信や継続的監視はできません。
・SCS試験で押さえておくべきポイント
✅ ログのリアルタイム処理＋保存＋検索という3要素に対応するためには：
- Kinesis（Data Streams or Firehose）でログを集約・配信
- OpenSearchでリアルタイム分析・検索・可視化
✅ フォレンジック対応の設計では：
- ログの改ざん防止・中央集約・長期保存が重要。
- CloudWatchは補助的に使う（モニタリング・アラート）。
- Athenaは過去ログのクエリ用、リアルタイム分析には不向き。
次の問題もお送りください。引き続き、SCS対策フォーマットで解説いたします！
以下に【SCS-127】の問題について、SCS試験対策形式で解説します。
・問題文
【SCS-127】ある企業は、Amazon Elastic Container Service (Amazon ECS) でコンテナを使用するバッチワークロードを実行しています。
同社は、外部サービスとの統合に必要な API キーを格納するための安全なソリューションを必要としています。
同社のセキュリティポリシーでは、API キーをプレーンテキストで保存または送信してはならないと規定されています。
同社の IT チームは現在、API キーを手動でローテーションしています。
セキュリティエンジニアは、セキュリティ要件を満たし、API キーのローテーションを自動化するソリューションを推奨する必要があります。
セキュリティエンジニアはどのソリューションを推奨する必要がありますか?
・選択肢
A. AWS Systems Manager パラメータ ストアでセキュアな文字列パラメータを使用します。自動回転機能を有効にします。
B. API キーの保存には Amazon EC2 ユーザーデータを使用します。スケジュールされた AWS Lambda 関数をセットアップして、API キーを自動的にローテーションします。
C. AWS Fargate を使用して API キーを保存します。スケジュールされた AWS Lambda 関数をセットアップして、API キーを自動的にローテーションします。
D. AWS Secrets Manager を使用して API キーを保存します。コンテナー定義で API キーを参照します。
・正解の選択肢と解説
正解：D
✅ D. AWS Secrets Manager を使用して API キーを保存します。コンテナー定義で API キーを参照します。
理由：
- AWS Secrets Managerは、APIキーや認証情報を安全に保存・取得・自動ローテーションできるマネージドサービスです。
- ECS（特にFargate/ECS on EC2）のタスク定義で Secrets Manager の値を参照することが可能です。
- セキュリティポリシーにある「プレーンテキスト禁止」にも対応可能（暗号化保存、アクセス制御、監査ログあり）。
- Secrets ManagerはLambdaを使った自動ローテーション機能もネイティブにサポート。
・不正解の選択肢の理由
❌ A. Systems Manager パラメータストア + セキュア文字列
- セキュアな保存は可能ですが、自動ローテーションはネイティブには非対応。
- Secrets Managerの方がこの用途には適しています。
- セキュアストリングにLambdaを組み合わせれば可能だが、Secrets Managerの方がはるかに簡便で推奨されている。
❌ B. EC2ユーザーデータ + Lambda
- ユーザーデータはEC2起動時に1回だけ実行される設定であり、セキュアな保存用途ではない。
- セキュリティ的にも脆弱（base64でエンコードされているだけで平文扱い）。
- ECS/Fargateでの実行にも適していない。
❌ C. Fargateに保存 + Lambdaでローテーション
- FargateはAPIキーなどの秘密情報を保存する場所ではない。アプリ実行環境であって保管場所ではない。
- スケーラブルでセキュアな設計としては不適切。
・SCS試験で押さえておくべきポイント
✅ AWS Secrets Manager：
- 機密情報（APIキー、DB認証情報、OAuthトークンなど）の暗号化保管と自動ローテーションが可能。
- IAMでアクセス制御、CloudTrailで監査、Lambdaベースのローテーションスクリプトもサポート。
✅ ECS連携：
- ECS/Fargateでは、タスク定義内でSecrets Managerの値を環境変数として参照可能。
- セキュアにアプリケーションへ情報を提供できる。
✅ 誤った保存場所の例（試験で頻出）：
- EC2ユーザーデータ：セキュアでない。
- コンテナ内やEFS：改ざん・盗難のリスクが高く、ポリシー違反。
次の問題もあれば続けてどうぞ。SCSの重要ポイントを押さえて、丁寧に解説します！
ありがとうございます。以下に、SCS-128の問題に対する正答と詳細解説をSCS試験対策として提供します。
✅ 問題文
【SCS-128】ある組織は、Amazon S3 に移行している数ペタバイトのワークロードを持っていますが、システム管理者は鍵が漏洩した場合の鍵の悪用と影響を懸念しています。
AWS KMS と S3 をどのような設定にするのが適切でしょうか。
（2つ選択してください。）
✅ 選択肢
- 暗号化されたS3オブジェクトを取得するAPI操作がないこと。
- S3オブジェクトの暗号化は、KMSサービスのセキュアなバウンダリ内で行われます。
- S3はKMSを使用して、個々のオブジェクトに一意のデータキーを生成します。
- 単一のマスターキーを使用し、監査と使用状況の検証を行う場所を含めたすべてのデータを暗号化します。
- KMS暗号化エンベロープにて、暗号化時にマスターキーにデジタル署名を行い、暗号の磨耗を防止します。
✅ 正解の選択肢と解説
✅ 1. 暗号化されたS3オブジェクトを取得するAPI操作がないこと。
✅ 3. S3はKMSを使用して、個々のオブジェクトに一意のデータキーを生成します。
✅ 選択肢1（A）：暗号化されたS3オブジェクトを取得するAPI操作がないこと
- この記述は一見誤解を招きますが、文意としては「SSE-C（顧客提供キー）を使ったオブジェクトは、キーが提供されないと取得できない」ことを意味しています。
- 実際には
GetObjectAPI は存在しますが、SSE-C を使用して保存されたオブジェクトの取得には、同一の暗号化キーの提供が必須です。 - 鍵が漏洩しない限り第三者がオブジェクトを取得できないという意味で、漏洩時の影響を最小限に抑えるという要件を満たしています。
📌 参考：SSE-Cの特徴 – AWS公式
✅ 選択肢3（C）：S3はKMSを使用して、個々のオブジェクトに一意のデータキーを生成します
- AWSのSSE-KMS（サーバーサイド暗号化 with KMS）は、オブジェクトごとに一意のデータキー（DEK）を生成し、それをKMSのカスタマーマスターキー（CMK）で暗号化して保存するエンベロープ暗号化方式です。
- これにより、万が一キーが漏洩しても、すべてのオブジェクトが一括で復号されるリスクを防ぐことができます。
- 高セキュリティ・大規模データ保護に最適な設計です。
❌ 不正解の選択肢の理由
❌ 選択肢2（B）：S3オブジェクトの暗号化は、KMSのセキュアバウンダリ内で行われます
- 実際の暗号化処理はS3が実施し、KMSはデータキーの生成と管理のみを行います。
- 「KMS内で暗号化される」という表現は誤解であり不正確です。
❌ 選択肢4（D）：単一のマスターキーを使用して全データを暗号化
- 1つのマスターキーで大量データを暗号化するのはスコープの分離がなく、リスク集中が高くなるため、セキュリティ上不適切です。
- また、KMSではCMKを直接使ってオブジェクトを暗号化することはなく、必ず一時的なデータキー（DEK）を通して処理します。
❌ 選択肢5（E）：マスターキーにデジタル署名して暗号の磨耗を防止
- KMSやエンベロープ暗号化において、マスターキーに署名するという設計は存在しません。
- 「暗号の磨耗（cryptographic wear）」もAWSの暗号化設計では使われない概念であり、技術的根拠がないため不正解です。
✅ SCS試験で押さえておくべきポイント
| 観点 | 内容 |
|---|---|
| SSE-KMS | KMSと連携し、各オブジェクトに一意のデータキーを生成、CMKでそのキーを暗号化（エンベロープ暗号） |
| SSE-C | クライアントが提供するキーを使用。リクエストでキーが一致しないとオブジェクト取得不可。鍵漏洩対策に有効 |
| KMSの役割 | データの暗号化処理は行わず、鍵の生成と保護、復号の制御、CloudTrailによる操作記録を担当 |
| キーのスコープと分離 | 単一CMKによる一括暗号化は避け、用途や機密度に応じたキー分離が推奨される |
引き続き他の問題も対応可能ですので、どうぞお送りください！
以下に、【SCS-129】の問題を指定の形式で整理・解説いたします。
・問題文（文字列を編集せずに出力）
【SCS-129】ある会社は、AWS 環境で Amazon GuardDuty を使用しています。
会社は、セキュリティエンジニアに すべてのアカウントのGuardDuty を一時停止するよう依頼しました。また、セキュリティエンジニアはGuardDutyの料金が発生しないようにする必要があります。
この要件を満たすためにセキュリティエンジニアが実行する必要がある手順はどれですか?（2つ選んでください。）
・選択肢（文字列を編集せずに出力）
- すべてのリージョンのすべてのDetectorから、すべてのオプションのデータソースを無効にします。
- 管理アカウントで各メンバーアカウントのGuardDutyを一時停止します。
- 各メンバーアカウントでGuardDutyを一時停止します。
- 既存の検出結果をすべて削除します。
- すべてのメンバーアカウントの関連付けを解除または削除します。
・正解の選択肢と解説
✅ 正解：1 と 2
✅ 1. すべてのリージョンのすべてのDetectorから、すべてのオプションのデータソースを無効にします。
- GuardDuty の一部機能（例：Malware Protection、S3 Protection、EKS Audit Logs）は、GuardDuty が「停止中」でも個別に課金が発生する場合があります。
- これらを無効化することで、完全に料金の発生を防げます。
- 各リージョンのすべての検出器（Detector）に対して操作が必要です。
✅ 2. 管理アカウントで各メンバーアカウントのGuardDutyを一時停止します。
- 組織で GuardDuty を利用している場合、GuardDuty は管理アカウントから一元的に制御されます。
- メンバーアカウント自身では一時停止できず、管理アカウントから検出器を無効化または停止する必要があります。
📚 参考：GuardDuty の無効化と一時停止（公式ドキュメント）
・不正解の選択肢の理由
❌ 3. 各メンバーアカウントでGuardDutyを一時停止します。
- 組織ガードデューティーが有効な場合、メンバーアカウントでは自分で無効化・一時停止できません。
- この操作は管理アカウントの責任です。
❌ 4. 既存の検出結果をすべて削除します。
- GuardDutyの課金は検出処理に対して発生するため、結果を削除しても料金には影響なしです。
❌ 5. すべてのメンバーアカウントの関連付けを解除または削除します。
- メンバーアカウントの解除は、将来の分析・運用復帰を難しくするだけで、一時停止とは別の手段です。
- GuardDuty を一時的に停止し、課金を防ぐ目的には不要かつ過剰な対応です。
・SCS試験で押さえておくべきポイント
- GuardDutyの課金は、検出器が有効な状態 + データソースの使用によって発生する。
- 停止してもオプション機能（S3、Malware、EKSログなど）は別途課金対象。
- 管理アカウントが一元管理可能であり、メンバーアカウント単独では停止操作はできない。
- 停止≠無効化≠削除：操作の違いと影響範囲を明確にする。
引き続き、他のSCS問題も分析・解説可能ですので、どうぞお送りください。
以下は、【SCS-130】の問題について、指定された形式での出力です。
・問題文（文字列を編集せずに出力）
【SCS-130】ある会社のセキュリティエンジニアは、IAM ロールの異常なアクティビティに関する Amazon GuardDuty の結果を調査しています。
AWS アカウントには、会社のオンプレミスの Active Directory ドメインコントローラーとのフェデレーションで構成された AWS シングルサインオンがあります。
セキュリティエンジニアは、調査の結果、根本的な原因がオンプレミスの Active Directory ID の侵害であると判断しました。
複数の本番ワークロードが AWS で IAM ロールを使用しています。
セキュリティエンジニアは、AWS での本番ワークロードのダウンタイムを最小限に抑えながら、IAM ロールの不正使用を軽減する必要があります。
セキュリティエンジニアは、これらの要件を満たすためにどのアクションを組み合わせて実行する必要がありますか? （2つ選んでください。）
・選択肢（文字列を編集せずに出力）
- IAM ロールのアクセスキーを無効にします。新しい IAM アクセスキーを発行します。
- オンプレミスの Active Directory に登録されている ID のアクセス権を剥奪します。
- IAM ポリシーを IAM ロールにアタッチして、現在より前に発行された AWS Security Token Service (AWS STS) トークンへのすべてのアクセスを拒否します。
- IAM ポリシーを IAM ロールにアタッチして、フェデレーション Active Directory ID の ARN へのアクセスを拒否します。
・正解の選択肢と解説
✅ 2. オンプレミスの Active Directory に登録されている ID のアクセス権を剥奪します。
→ 根本原因がオンプレミスAD IDの侵害であるため、ID自体の使用を即座に停止することが最優先です。これにより、新たな認証フェデレーションの試みを遮断できます。
✅ 3. IAM ポリシーを IAM ロールにアタッチして、現在より前に発行された AWS Security Token Service (AWS STS) トークンへのすべてのアクセスを拒否します。
→ 一時的なSTSトークンは、発行後一定期間使用可能です。すでに発行されたトークンを無効にするためには、Condition要素で “aws:TokenIssueTime” を用いたポリシーを使用し、特定時刻以前のトークンを拒否するのが有効です。
・不正解の選択肢の理由
❌ 1. IAM ロールのアクセスキーを無効にします。新しい IAM アクセスキーを発行します。
→ IAMロールにはアクセスキーは存在しません。アクセスキーはIAMユーザーに関連付けられるもので、フェデレーション認証とは関係ありません。
❌ 4. IAM ポリシーを IAM ロールにアタッチして、フェデレーション Active Directory ID の ARN へのアクセスを拒否します。
→ IAMポリシーでフェデレーションIDのARNをブロックすることは通常困難で、また実際の動作にも誤りが出やすい方法です。加えて、具体的なIDが複数ある場合、管理負荷が高く推奨されません。
・SCS試験で押さえておくべきポイント
- 侵害されたIDの遮断が最優先。オンプレミスAD連携時もIDの使用を即停止する。
- STSトークンの無効化は、「TokenIssueTime」での条件付き拒否が唯一の手段。
- IAMロールはアクセスキーを持たず、信頼ポリシーとSTS AssumeRoleを通じて利用される。
- 一時的なセキュリティ対策としてポリシーの条件付き制御はよく出題される。
続けて他の問題もお送りいただければ、同様に整理して解説いたします。
