Uncategorized

#44

 

以下に 問題1 を指定フォーマットで整理します。

■問題文（そのまま）

企業は、VPC 内の Amazon EC2 インスタンスでビジネスに不可欠なアプリケーションをホストしています。VPC は、デフォルトの DHCP オプションセットを使用しています。セキュリティエンジニアは、内部リソースが VPC で行うすべての DNS クエリをログに記録する必要があります。セキュリティエンジニアはまた、時間の経過とともに最も一般的な DNS クエリのリストを作成する必要があります。

これらの要件を満たすソリューションを選択してください。

■選択肢（そのまま）

A
VPC 内のすべてのサブネットの VPC フローログを作成します。フローログを Amazon CloudWatch Logs ロググループにストリーミングします。CloudWatch Logs Insights を使用して、ロググループの最も一般的な DNS クエリをカスタムダッシュボードに一覧表示します。

B
VPC に BIND DNS サーバーをインストールします。BIND ログから一般的な DNS クエリの DNS リクエスト数を一覧表示する bash スクリプトを作成します。

✅ C
Amazon Route 53 Resolver のクエリログを設定します。Amazon CloudWatch Logs ロググループを送信先として追加します。Amazon CloudWatch Contributor Insights を使用して、データを分析し、最も一般的な DNS クエリを表示する時系列を作成します。

D
VPC 内の各 EC2 インスタンスに Amazon CloudWatch エージェントをインストールします。CloudWatch エージェントを使用して、DNS クエリログを Amazon CloudWatch Logs ロググループにストリーミングします。CloudWatch メトリクスフィルターを使用して、最も一般的な DNS クエリを一覧表示するメトリクスを自動的に生成します。

■問題文の要件の概要

  • VPC 内のすべての DNS クエリを 記録すること。
  • 時間の経過とともに最も頻出のクエリを可視化する必要あり。
  • デフォルトの DHCP オプションセット（＝AmazonProvidedDNS）を使用している前提。

■正解の選択肢と解説

✅ C. Amazon Route 53 Resolver クエリログ + CloudWatch Contributor Insights

  • Route 53 Resolver のクエリログ機能を使うことで、VPC 内で行われた全 DNS クエリをログに記録可能。
  • CloudWatch Logs に出力し、Contributor Insights を使えば「最も多いクエリ」などの統計を時系列で可視化可能。
  • 唯一、AWS 標準機能で要件をフルカバーできる構成。

■不正解の選択肢の理由

❌ A. VPC フローログ + CloudWatch Logs Insights

  • フローログは TCP/UDP/IP のヘッダ情報のみ取得、DNS クエリ内容（例：example.com）は含まれない。
  • クエリの内容が取れないため、要件を満たさない。

❌ B. BIND DNS サーバーを自前で立てる

  • 手動で DNS サーバー構築・運用・ログ収集・bash 解析は保守性・拡張性・可観測性に欠ける。
  • AWSネイティブな方法で対応すべき設問であり、試験では選ばれない。

❌ D. CloudWatch エージェントをインスタンスにインストール

  • OS ログレベルで DNS クエリを取得しようとしているが、すべてのクエリ取得は難しい。
  • 全インスタンスにエージェント導入も運用負荷が高く、AWS標準機能に劣る。
  • AmazonProvidedDNS に対するクエリは CloudWatch エージェントでは取得できない。

■SCS試験で押さえておくべきポイント

項目内容
✅ Route 53 Resolver クエリログVPC から発信される DNS クエリをキャプチャする正式手段。CloudWatch Logs に記録可能。
✅ CloudWatch Contributor InsightsDNS クエリの**集計分析（Top-N集計など）**に使える強力な分析ツール。
❌ VPC Flow LogsではDNSクエリの中身は取れないIP/ポートレベルまで。名前解決内容は記録されない。
❌ エージェントや自前 DNS サーバーの導入は運用負荷が高く非推奨セキュリティと効率の観点から避ける。試験では AWS マネージドソリューションを優先。

この問題は、「VPC内部のDNS解決の観測方法」に関する代表的な問題で、Route 53 Resolver クエリログとCloudWatch 統合の理解が試されます。

次の問題もあれば、続けて解説可能です。

以下に 問題2 を指定フォーマットで整理します。

■問題文（そのまま）

最近、企業のパブリックな Application Load Balancer (ALB) が DDoS 攻撃を受けました。この問題を軽減するために、同社は ALB の前に Amazon CloudFront をデプロイし、ユーザーが ALB の背後にある Amazon EC2 インスタンスに直接アクセスしないようにしました。

同社は、一部のトラフィックが依然として ALB に直接流入し、EC2 インスタンスによって処理されていることを発見しました。

EC2 インスタンスが CloudFront からのみトラフィックを受信するようにする最適な手順を組み合わせを選択してください。(2 つ選択)

■選択肢（そのまま）

A
CloudFront が ALB に送信するカスタム HTTP ヘッダを許可するために、キャッシュキーポリシーを追加するように CloudFront を設定します。

✅ B
CloudFront が ALB に送信するリクエストにカスタム HTTP ヘッダーを追加するように CloudFront を設定します。

✅ C
カスタム HTTP ヘッダーを含むリクエストのみを転送するように ALB を設定します。

D
ALB と CloudFront が X-Forwarded-For ヘッダーを使用してクライアントの IP アドレスを確認するように設定します。

E
AWS Certificate Manager (ACM) によって生成された同じ X.509 証明書を使用するように ALB と CloudFront を設定します。

■問題文の要件の概要

  • ALB および背後の EC2 インスタンスへの直接アクセスを防止したい
  • CloudFront 経由のみでアクセス許可を制限することが目的
  • DDoS 攻撃への対策強化を狙っている

■正解の選択肢と解説

✅ B. CloudFront が ALB に送信するリクエストにカスタム HTTP ヘッダーを追加

  • CloudFront 側で X-Custom-Header などの 専用ヘッダーを付与。
  • このヘッダーがCloudFront経由のリクエストである証明になる。
  • ALB 側でこのヘッダーを条件にアクセス制御が可能になる。

✅ C. ALB を設定して、特定のカスタムヘッダーを持つリクエストのみ転送

  • ALB のリスナールールやターゲットグループ設定で、特定ヘッダーの有無を検査可能。
  • これにより、CloudFront を通過したリクエストだけが EC2 に届くように制限できる。

■不正解の選択肢の理由

❌ A. キャッシュキーポリシーの追加

  • キャッシュキーポリシーは CloudFront のキャッシュのキー決定に使うもの。
  • セキュリティヘッダーの検査や追加には直接関係がない。

❌ D. X-Forwarded-For ヘッダーの使用

  • X-Forwarded-For はクライアントのIPトラッキング用途であり、アクセス制限には不十分。
  • ヘッダーは偽装可能であり、CloudFront 経由かどうかの判定に使用するのは適さない。

❌ E. ACM の証明書を共通で使用

  • HTTPS 通信の暗号化のために使うが、直接アクセスを防ぐ手段ではない。
  • 証明書の共通利用は通信経路の暗号の一貫性確保にしか寄与しない。

■SCS試験で押さえておくべきポイント

項目内容
✅ CloudFront + ALB でアクセス制限する方法CloudFront にカスタム HTTP ヘッダーを追加し、ALB 側でこのヘッダーの存在を検査してCloudFront経由かどうか判別。
✅ ALBリスナールールでヘッダー条件を指定可能特定の HTTP ヘッダーを含まないリクエストは拒否・リダイレクト可能。
❌ X-Forwarded-For や共通証明書では制限できないクライアント追跡や暗号化用途であり、アクセス経路の保証には使えない。
❌ キャッシュキーポリシー ≠ セキュリティ制御これはあくまでキャッシュ戦略のための設定。

この問題は、CloudFront を用いたWebアクセス経路の制限と DDoS対策強化に関する重要な内容です。実務でもよく使われる手法なので、設定手順・目的の切り分けを理解しておくことが重要です。

次の問題もどうぞ。

以下に 問題3 を指定形式でまとめます。

■問題文（そのまま）

セキュリティエンジニアは、会社の主要なウェブサイトをホストする Amazon EC2 インスタンスに関連する調査結果を示す Amazon GuardDuty アラートを受け取りました。

受信した GuardDuty の結果は次のとおりです。

UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration

セキュリティエンジニアは、悪意のある行為者が、同社が営業していない国の EC2 インスタンスに意図した API アクセスキーを使用したことを確認しました。セキュリティエンジニアは、悪意のある行為者のアクセスを拒否する必要があります。

セキュリティエンジニアが最初に取るべき方法を選択してください。

■選択肢（そのまま）

A
AWS Systems Manager エージェントを EC2 インスタンスにインストールし、インベントリレポートを実行します。

B
Amazon Inspector エージェントをホストにインストールし、CVE ルールパッケージで評価を実行します。

✅ C
IAM コンソールを開き、インスタンスプロファイルに関連付けられているすべての IAM セッションを取り消します。

D
EC2 コンソールを開き、0.0.0.0/0 からのインバウンドトラフィックを許可するセキュリティグループをすべて削除します。

■問題文の要件の概要

  • GuardDuty により UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration のアラートが発生
  • インスタンスプロファイルの資格情報が営業していない国で不正利用された
  • 不正アクセスの即時遮断が必要

■正解の選択肢と解説

✅ C. IAM コンソールを開き、インスタンスプロファイルに関連付けられているすべての IAM セッションを取り消す

  • 該当のGuardDutyアラートは「インスタンスの IAM ロール（InstanceProfile）の資格情報が漏洩し、外部で使用された」ことを意味する。
  • STSによる一時的認証情報（セッション）を即座に失効させることで、不正アクセスを即遮断できる。
  • AWS Console または aws sts revoke-session などで対応可能。

■不正解の選択肢の理由

❌ A. Systems Manager のインベントリレポート

  • これはインスタンスの構成情報収集ツールであり、不正アクセスを遮断するものではない。
  • 緊急遮断としては効果がない。

❌ B. Amazon Inspector による脆弱性スキャン

  • CVE検査により脆弱性の有無を判断する目的。
  • 不正アクセスの遮断には即効性がない。

❌ D. セキュリティグループから 0.0.0.0/0 を削除

  • これは外部アクセスを遮断するが、IAM 認証情報の悪用とは無関係。
  • セキュリティグループはネットワーク層であり、APIアクセスのブロックには無力。

■SCS試験で押さえておくべきポイント

項目内容
✅ GuardDuty アラートの識別InstanceCredentialExfiltration はインスタンスプロファイルの漏洩を意味する深刻な侵害。
✅ STS 一時セッションの取り消しIAMロールの認証情報を盗まれた場合、まず既存のセッションを無効化する。
✅ 即応措置の優先度調査よりもアクセス遮断が先。レポートやスキャンは次のフェーズ。
✅ IAM コンソールまたは AWS CLI でセッションを取り消し可能revoke-session 相当の操作で緊急対応できる。

この問題は、インスタンスプロファイルの漏洩という SCS 試験でも出やすいインシデントレスポンスの基本です。GuardDutyの検出名からどういう脅威か即判断できるようにしておきましょう。

次の問題があれば続けてどうぞ。

以下に 問題4 を指定形式でまとめます。

■問題文（そのまま）

ある会社には、単一の Amazon EC2 インスタンスで実行されるレガシーアプリケーションがあります。セキュリティ監査は、アプリケーションが同じ AWS アカウントで DOC-EXAMPLE-BUCKET1 という名前の Amazon S3 バケットにアクセスするために、そのコード内の IAM アクセスキーを使用していたことを示します。このアクセスキーのペアは、この S3 バケットのみにおけるすべてのオブジェクトに対する s3:GetObject 権限を持っています。このアプリケーションは、Amazon EC2 から他の AWS リソースにアクセスするための会社のセキュリティポリシーに準拠していないため、会社はアプリケーションをオフラインにします。

セキュリティエンジニアは、AWS CloudTrail がすべての AWS リージョンで有効になっていることを検証します。CloudTrail は、DOCEXAMPLE-BUCKET2 という名前の S3 バケットにログを送信しています。この S3 バケットは、DOC-EXAMPLE-BUCKET1 と同じ AWS アカウントにあります。ただし、CloudTrail はログを Amazon CloudWatch Logs に送信するように設定されていません。

同社は、過去 60 日間に DOC-EXAMPLE-BUCKET1 内のオブジェクトが IAM アクセスキーでアクセスされたかどうかを知りたいと考えています。アクセスされたオブジェクトがある場合、会社はテキストファイル (.txt) であるオブジェクトのいずれかが個人を特定できる情報 (PII) を含んでいるかどうかを知りたいと考えています。

この情報を収集する最適な手順を組み合わせてを選択してください。(2 つ選択)

■選択肢（そのまま）

✅ A
Amazon Athena を使用して、DOC-EXAMPLE-BUCKET2 の CloudTrail ログをクエリし、アクセスキーを使用して PII を含むオブジェクトにアクセスした API 呼び出しを確認します。

✅ B
Amazon Macie を設定して、DOC-EXAMPLE-BUCKET1 内のオブジェクトのうち、PII を含み、アクセスキーで利用可能なオブジェクトを特定します。

❌ C
Amazon CloudWatch Logs Insights を使用して、DOC-EXAMPLE-BUCKET1 内の、PII を含み、アクセスキーで利用可能なオブジェクトを特定します。

❌ D
AWS Identity and Access Management Access Analyzer を使用して、DOC-EXAMPLE-BUCKET1 に PII を含むオブジェクトにアクセスするためにアクセスキーを使用した API 呼び出しを特定します。

❌ E
Amazon OpenSearch Service (Amazon Elasticsearch Service) を使用して、DOC-EXAMPLE-BUCKET2 の CloudTrail ログをクエリし、アクセスキーを使用して PII を含むオブジェクトにアクセスした API 呼び出しを確認します。

■問題文の要件の概要

  • IAM アクセスキーによって .txt ファイルがアクセスされたかを特定したい
  • さらに、それらのファイルが PII を含んでいるかを判定したい
  • CloudTrail は S3 バケット（DOC-EXAMPLE-BUCKET2）には送信されているが、CloudWatch Logs には連携されていない

■正解の選択肢と解説

✅ A. Amazon Athena を使用して CloudTrail ログをクエリする

  • CloudTrail ログは S3（DOC-EXAMPLE-BUCKET2）に保存されているため、Athena を使えば API イベント（GetObject など）に関するログを SQL 形式でクエリできる。
  • これにより、どのオブジェクトがアクセスされたかを確認可能。

✅ B. Amazon Macie を使用して PII を含むオブジェクトを特定する

  • Macie は S3 オブジェクト内の PII（個人情報）を自動検出するサービス。
  • .txt などのプレーンテキストもスキャン可能。
  • アクセスキーで読み取り可能なオブジェクト群の中で、PII を含むファイルを識別できる。

■不正解の選択肢の理由

❌ C. CloudWatch Logs Insights を使う

  • CloudTrail ログは CloudWatch Logs に送信されていないと問題文に記載あり。
  • したがって、Logs Insights は使えない。

❌ D. IAM Access Analyzer を使う

  • Access Analyzer は IAM ポリシーを元に外部アクセスの検出やリソースの共有状態を分析するものであり、実際のアクセスログや PII の検出は行わない。

❌ E. Amazon OpenSearch Service を使う

  • OpenSearch を使うには CloudTrail ログを事前に インデックス化しておく必要がある。
  • 現在の構成ではそのようなインデックスが存在せず、Athena のほうが手軽で即時性がある。

■SCS試験で押さえておくべきポイント

項目内容
✅ CloudTrail ログの分析S3 に保存された CloudTrail ログは、Athena で直接クエリ可能。
✅ PII 検出Macie は S3 内の機密情報（PIIなど）検出専用サービス。
✅ Logs Insights の前提条件CloudWatch Logs にログがあることが前提。連携されていなければ利用不可。
✅ Access Analyzer の機能リソースが外部に公開されていないか確認する静的解析用。ログ分析はできない。
✅ OpenSearch は前処理が必要検索にはデータの取り込みとインデックス作成が必要。即時性には欠ける。

この設問は **CloudTrail ログの活用（Athena）＋S3オブジェクトの内容確認（Macie）**という、よくあるセキュリティ調査フローの基本です。
CloudTrailの出力先、Macieの検出対象など、各サービスの特性を押さえておくと応用も効きます。

次の問題があれば、どうぞお送りください。

以下に 問題5 を指定フォーマットでまとめます。

■問題文（そのまま）

企業には、アカウント A とアカウント B の 2 つの AWS アカウントがあります。アカウント A には、アカウント B の IAM ユーザーがアカウント A の Amazon S3 バケットに機密文書をアップロードする必要があるときに想定される IAM ロールがあります。

新しい要件は、ユーザーが多要素認証 (MFA) で認証されている場合にのみ、そのロールを引き受けることを義務付けています。セキュリティエンジニアは、最小限のリスクと労力でこの要件を満たすソリューションを推奨する必要があります。

推奨する最適なソリューションを選択してください。

■選択肢（そのまま）

❌ A
aws:MultiFactorAuthPresent 条件をセッションポリシーに追加します。

❌ B
aws:MultiFactorAuthPresent 条件をロールのアクセス許可ポリシーに追加します。

❌ C
aws:MultiFactorAuthPresent 条件を S3 バケットポリシーに追加します。

✅ D
aws:MultiFactorAuthPresent 条件をロールの信頼ポリシーに追加します。

■問題文の要件の概要

  • クロスアカウントアクセスで、アカウントBのユーザーがアカウントAのS3バケットにファイルをアップロード
  • MFAで認証された場合にのみロール引受を許可したい
  • リスク・労力を最小限に抑えたい

■正解の選択肢と解説

✅ D. aws:MultiFactorAuthPresent 条件をロールの信頼ポリシーに追加する

  • ロールの信頼ポリシーは、どのエンティティがどの条件でロールをAssumeRoleできるかを制御。
  • aws:MultiFactorAuthPresent を使えば「MFAが有効なセッションからのみAssumeRoleを許可」と制限可能。
  • MFA強制のベストプラクティスであり、最小の労力で確実に制御できる方法。
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::アカウントB:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

■不正解の選択肢の理由

❌ A. セッションポリシーに追加

  • セッションポリシーは「ロールでできることを一時的に制限する」ものであり、ロールを引き受ける前の条件は制御できない。

❌ B. アクセス許可ポリシーに追加

  • アクセス許可ポリシー（IAMポリシー）は、ロールが引き受けられた後のアクション制御。引受条件には関与できない。

❌ C. S3バケットポリシーに追加

  • S3ポリシーはS3へのアクセス制御。ロールの引受条件（sts:AssumeRole）を制御するには不適切。

■SCS試験で押さえておくべきポイント

観点ポイント
✅ MFA制御MFA必須にするには aws:MultiFactorAuthPresent を信頼ポリシーに入れる
✅ クロスアカウントPrincipal に相手アカウントIDやIAMユーザー/ロールを指定し、信頼関係を構成
❌ セッション/アクセス許可ポリシーでは制御できないロール引受の条件は信頼ポリシーでしか制御できない
✅ 最小の労力追加のサービス不要で信頼ポリシー修正のみで実現可能

この問題は IAM信頼ポリシーとMFA制御の基本構文を理解しているかを問う定番問題です。
aws:MultiFactorAuthPresent の使い所は信頼ポリシーのみ、という点を明確に覚えておきましょう。

次の問題があれば、続けてどうぞ。

以下に 問題6 を指定フォーマットで整理します。

■問題文（そのまま）

企業は AWS CloudTrail を使用して、すべてのアカウントのすべての AWS リージョンのすべての AWS API アクティビティをログに記録しています。同社は、中央の場所にあるログファイルの整合性を保護したいと考えています。
ログファイルを改ざんから保護する手順の組み合わせを選択してください。 (2 つ選択)

■選択肢（そのまま）

✅ A
すべての AWS アカウントに対して AWS Organizations を有効にします。組織の証跡を作成する際に、ログファイルの整合性の検証で CloudTrail を有効にします。この証跡から中央の Amazon S3 バケットにログを送信します。

✅ B
専用のログアカウントで中央の Amazon S3 バケットを作成します。メンバーアカウントで、このバケットにログを書き込むための CloudTrail のアクセス権を付与します。

❌ C
Amazon S3 バケットでサーバーアクセスログを有効にします。

❌ D
すべての AWS アカウントに対して AWS Organizations を有効にします。各メンバーアカウントで CloudTrail を有効にするための SCP を作成し、ログを中央の Amazon S3 バケットに送信します。

❌ E
AWS Systems Manager Compliance を使用して、CloudTrail のログを含む Amazon S3 バケットのアクセスポリシーを継続的に監視します。

■問題文の要件の概要

  • すべてのアカウント・すべてのリージョンの AWS API アクティビティを対象に CloudTrail を使用している。
  • ログファイルの整合性（改ざんされていないこと）を保護したい。
  • ログの保存先は中央の場所（S3）。

■正解の選択肢と解説

✅ A. 組織の証跡 + ログファイルの整合性検証

  • AWS Organizations を利用して 組織の証跡 (Organization Trail) を有効化すると、すべてのアカウント・リージョンの CloudTrail イベントを集中管理できる。
  • CloudTrail で「ログファイルの整合性検証」を有効にすることで、ログ改ざんの検出が可能（署名ファイルで検証）。

✅ B. ログアカウントで S3 を集中管理

  • CloudTrail ログを一か所で管理するには、専用ログアカウントで S3 バケットを作成。
  • 各アカウントの CloudTrail からこの S3 バケットへの書き込み権限を付与する構成がセキュリティ的にもベストプラクティス。

■不正解の選択肢の理由

❌ C. Amazon S3 バケットでサーバーアクセスログを有効にします。

  • サーバーアクセスログは S3 へのアクセスの記録であり、CloudTrail ログそのものの整合性保護には関係しない。

❌ D. SCP で CloudTrail 有効化を強制

  • SCP は **操作の制限（拒否）**が主用途。
  • CloudTrail の有効化を強制する方法ではないため不適。

❌ E. AWS Systems Manager Compliance を使ってバケットポリシー監視

  • Compliance は主に インスタンス設定やパッチ適用の管理。
  • S3 バケットのアクセスポリシー監視やログ整合性の検証には使わない。

■SCS試験で押さえておくべきポイント

観点ポイント
✅ CloudTrail整合性保護ログファイルの整合性検証 (Log File Validation) を有効化する
✅ 組織証跡AWS Organizations を使って すべてのアカウントのCloudTrailを一元管理
✅ ログ集約専用のログアカウント＋中央S3バケットがベストプラクティス
❌ S3アクセスログやSCPログ整合性やCloudTrail有効化には直接寄与しない点に注意

この問題では、CloudTrailの 整合性検証オプションと ログの集約構成について理解しているかが問われています。
次の問題があれば、続けてどうぞ。

以下に 問題7 を指定フォーマットで整理します。

■問題文（そのまま）

ある企業が、Amazon S3 バケットをベンダーに提供し、ベンダーが S3 バケット内のログファイルを分析できるようにしたいと考えています。同社は、S3 バケットへのアクセスを許可する IAM ロールを作成しました。同社はまた、ベンダーアカウントを指定する信頼ポリシーを設定する必要があります。

S3 バケットにアクセスするための API 呼び出しの引数として必要な情報を選択してください。 (2 つ選択)

■選択肢（そのまま）

✅ A
ベンダーから企業に提供された外部 ID

❌ B
企業のアカウントの信頼ポリシーの Amazon リソースネーム (ARN)

❌ C
会社のアカウントの S3 バケットのバケットポリシーの名前

❌ D
企業のアカウントの IAM ロールからの一時的なアクセスキー

✅ E
企業のアカウントの IAM ロールの Amazon リソースネーム (ARN)

■問題文の要件の概要

  • ベンダーに S3 バケットへのアクセスを許可したい。
  • IAM ロールを企業側で作成し、信頼ポリシーを設定。
  • ベンダーは API でロールを引き受けて S3 にアクセスする必要がある。

■正解の選択肢と解説

✅ A. 外部 ID

  • AssumeRole API を使用する場合、外部 ID（external ID） を指定するのが推奨されるセキュリティ対策。
  • 外部 ID は「混乱した代理（confused deputy）」問題を防ぐ。
  • ベンダーがこの外部 ID を提供し、API 呼び出し時に指定する必要がある。

✅ E. IAM ロールの ARN

  • ベンダーが引き受けるべき IAM ロールは、企業アカウント内にあるロール。
  • ベンダーは sts:AssumeRole API を呼び出す際に、そのロールの ARN を明示的に指定する必要がある。

■不正解の選択肢の理由

❌ B. 信頼ポリシーの ARN

  • 信頼ポリシーは IAM ロールに添付される JSON 定義であり、API 呼び出しでは指定不要。
  • API 側から信頼ポリシーを指定することはない。

❌ C. バケットポリシーの名前

  • バケットポリシーに名前は存在せず、単にバケットリソースにアタッチされている JSON ポリシー。
  • API 呼び出しにおいて、バケットポリシーを指定することはない。

❌ D. 一時的なアクセスキー

  • 一時的なアクセスキーは、AssumeRole を呼び出した「結果として」生成されるもの。
  • 呼び出しの「引数」には含めない。

■SCS試験で押さえておくべきポイント

項目説明
✅ クロスアカウントアクセス別アカウントの IAM ロールを AssumeRole することで可能
✅ AssumeRole API 引数ロールの ARN と 外部 ID（信頼ポリシーで検証）
✅ 外部 ID の目的サードパーティとのやり取り時にセキュリティ向上、confused deputy 回避
❌ 信頼ポリシーの ARNAPI で明示的に指定するものではない
❌ 一時キーAssumeRole 後に得られるものであり、指定は不要

この問題は、**クロスアカウント IAM ロールの利用とセキュリティ対策（外部 ID）**についての深い理解が求められます。
次の問題があれば、引き続きお送りください。

RELATED POST