Uncategorized

#39

 

以下は、提供いただいたHTML形式の問題に基づき、指定の形式で整理した内容です。

■ 問題文（原文）

ある企業は、カスタマイズされた通知ソリューションを導入して、踏み台ホストに対する不正な認証試行が繰り返されたことを検知しようとしています。この企業のセキュリティエンジニアは、5 分間に 5 回の認証試行が失敗した場合に通知を行うソリューションを実装する必要があります。このソリューションは、AWS ネイティブサービスを使用し、特定の踏み台ホストに割り当てられている指定のシステム管理者のみに通知する必要があります。

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

■ 選択肢（原文）

A.
AWS Systems Manager エージェントを使用して、オペレーティングシステムのログを収集します。Systems Manager Run Command AWS-ConfigureCloudWatch ドキュメントを使用して、失敗したログイン試行のメトリクスフィルターに基づいて Amazon CloudWatch アラームを設定します。アラームの定義されたしきい値を超えたら、Amazon Simple Notification Service (Amazon SNS) にアラートを送信します。EC2 インスタンスタグを使用して、通知を受け取る SNS トピックを決定します。

B.
AWS Systems Manager エージェントを使用して、オペレーティングシステムのログを収集します。Systems Manager Run Command AWS-ConfigureCloudWatch ドキュメントを使用して、失敗したログイン試行のメトリクスフィルターに基づいて Amazon EventBridge イベントを設定します。アラームの定義されたしきい値を超えたら、Amazon Simple Notification Service (Amazon SNS) にアラートを送信します。SNS メッセージングフィルターを使用して、通知の受信者を制御します。

C.
Amazon CloudWatch エージェントを使用して、オペレーティングシステムのログを収集します。失敗したログイン試行のメトリクスフィルターに基づいて CloudWatch アラームを作成します。アラームの定義されたしきい値を超えたら、Amazon Simple Notification Service (Amazon SNS) にアラートを送信します。SNS メッセージングフィルターを使用して、通知の受信者を制御します。

D.
Amazon CloudWatch エージェントを使用して、オペレーティングシステムのログを収集します。Amazon EventBridge を使用して、失敗したログイン試行のメトリクスフィルターに基づいてアラームを設定します。アラームの定義されたしきい値を超えたら、Amazon Simple Notification Service (Amazon SNS) にアラートを送信します。Amazon EC2 インスタンスタグを使用して、通知を受け取る SNS トピックを決定します。

■ 問題文の要件の概要

  • 条件検知：5分間に5回の認証失敗を検出する必要がある
  • 対象限定：特定の踏み台ホストに割り当てられている指定のシステム管理者のみに通知する必要がある
  • AWSネイティブサービスで構成すること

■ 正解の選択肢と解説

正解：C

理由：

  • CloudWatch エージェントでOSログを収集し
  • メトリクスフィルターで認証失敗を検出し
  • CloudWatch アラームでしきい値（5分間に5回）を設定し
  • SNSメッセージングフィルターで通知対象を指定されたシステム管理者のみに限定できるため、すべての要件を満たしている。

■ 不正解の選択肢の理由

A：

  • SNS通知の対象をEC2インスタンスタグで決定しているが、これは個別の管理者に動的に絞り込む手段として不適切。

B：

  • EventBridge を使用して通知をトリガーしているが、メトリクスしきい値監視には CloudWatch アラームがより適切。
  • なお SNS フィルターは使っているため通知の制御は可能だが、EventBridge の使用は過剰で不適切。

D：

  • SNS通知の制御に「EC2インスタンスタグ」を用いており、特定のシステム管理者への通知を柔軟に制御できない。
  • また、EventBridgeでアラームを設定する構成も不適切。

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

  • CloudWatch メトリクスフィルター + アラームでログベースのイベントをしきい値付きで監視できる
  • SNS メッセージングフィルターを使うことで、通知対象を属性ベースで動的に振り分けることが可能
  • EventBridgeはルールベースのイベント検知には向くが、しきい値監視はCloudWatchの役割
  • Systems Managerをログ収集に使うこともできるが、最も軽量かつ単純なのは CloudWatch エージェント構成

他の問題も同様に整理しますので、引き続きお送りください。

以下は、問題2の内容を指定の形式で整理したものです。

■ 問題文（原文）

会社のセキュリティエンジニアは、すべての AWS アカウントのルートユーザーのアクティビティを監視し、報告するように依頼されました。次のうち、セキュリティエンジニアがすべてのルートユーザーのアクティビティを監視および報告できるようにする最適な方法を選択してください。 (2 つ選択)

■ 選択肢（原文）

A.
ルートユーザーのアクティビティを AWS アカウントでスキャンするように Amazon Inspector を設定します。

B.
管理アカウントでルートユーザーの API 呼び出しを監視するように AWS Organizations を設定します。

C.
ルートユーザーがコンソールにログインしたときに、セキュリティチームにメールを送信するように AWS Trusted Advisor を設定します。

D.
Amazon SNS を使用してターゲットグループに通知します。

E.
ルートユーザーからの API 呼び出しが報告されたときにトリガーされる Amazon EventBridge (Amazon CloudWatch Events) ルールを作成します。

■ 問題文の要件の概要

  • 目的：すべての AWS アカウントで「ルートユーザーのアクティビティ」を監視し、報告する
  • 手段：AWSネイティブの仕組みで、検出と通知の仕組みを組み立てる必要がある
  • 対象：ルートユーザーのAPI呼び出しおよびログイン行動

■ 正解の選択肢と解説

正解：D, E

✅ E. ルートユーザーからの API 呼び出しが報告されたときにトリガーされる Amazon EventBridge ルールを作成します。

  • 理由：CloudTrail で記録されたルートユーザーのアクティビティ（API呼び出し）に対して、EventBridge ルールをトリガーできます。
  • CloudTrail → EventBridge → Lambda などの構成で、ルートユーザーの利用を即座に検知して通知する構成が実現可能です。
  • AWS 公式ブログでも紹介されているベストプラクティスです。

✅ D. Amazon SNS を使用してターゲットグループに通知します。

  • 理由：EventBridge ルールからの通知や、Lambda 処理の結果を SNS に転送して、セキュリティチームなどの適切な受信者にメール通知を届けることができます。
  • SNS は通知送信先（メール、SMS、HTTPなど）として広く利用されており、通知の受け手を柔軟に設定できるのが強みです。

■ 不正解の選択肢の理由

❌ A. Amazon Inspector を使用する

  • 理由：Amazon Inspector は EC2 やコンテナに対する脆弱性スキャンサービスであり、ルートユーザーのアクティビティは検出対象外。

❌ B. AWS Organizations を使用する

  • 理由：Organizations はアカウント管理機能（統制、SCPの適用など）を提供するが、ルートユーザーの操作ログの取得や通知には対応していない。

❌ C. AWS Trusted Advisor を使用する

  • 理由：Trusted Advisor は設定のベストプラクティスチェックを行うものであり、リアルタイムのログインイベントの通知機能はない。

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

  • CloudTrail でルートユーザーの API 呼び出し・ログインなどのアクティビティを記録できる
  • EventBridge で CloudTrail イベントをフィルタリングしてルールベースでトリガー処理を実行できる（ルートユーザー識別は userIdentity.type = "Root"）
  • SNS を使って、セキュリティチームなどに通知（Eメールなど）を送信できる
  • Inspector / Trusted Advisor / Organizations ではルートユーザーの操作自体を直接監視・通知する機能は持たない

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

以下は問題3の内容を指定フォーマットで整理したものです。

■ 問題文（原文）

企業は、Application Load Balancer (ALB) の背後で動作するウェブベースのアプリケーションがあります。このアプリケーションは、クレデンシャルスタッフィング攻撃を受けており、多数のログイン試行が失敗しています。攻撃は多数の IP アドレスから行われています。ログイン試行では、既知のモバイルデバイスエミュレーターの User-Agent 文字列が使用されています。

セキュリティエンジニアは、クレデンシャルスタッフィング攻撃を軽減するためのソリューションを実装する必要があります。このソリューションでは、アプリケーションへの正当なログインを許可する必要があります。

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

■ 選択肢（原文）

A.
攻撃に関与している IP アドレスからのトラフィックを拒否するように、ALB のインバウンドセキュリティグループを変更します。

B.
ALB 用の AWS WAF を使用して、ウェブ ACL を作成します。デバイスエミュレーターの User-Agent 文字列を含むリクエストをブロックするカスタムルールを作成します。

C.
指定された User-Agent 文字列を含むログイン試行に反応する Amazon CloudWatch アラームを作成します。Amazon Simple Notification Service (Amazon SNS) トピックをアラームに追加します。

D.
ALB 用の AWS WAF を使用して、ウェブ ACL を作成します。正当な User-Agent 文字列からのリクエストを許可するカスタムルールを作成します。

■ 問題文の要件の概要

  • クレデンシャルスタッフィング攻撃（多くの失敗ログイン）を軽減する必要がある
  • 攻撃は複数のIPから、**特定のUser-Agent（モバイルエミュレーター）**を利用
  • 正当なログインは許可する必要がある
  • ALB配下のアプリケーションに対する対策であることが前提

■ 正解の選択肢と解説

正解：B

✅ B. AWS WAF のウェブ ACL で、User-Agent 文字列に基づきリクエストをブロックする

  • 理由：User-Agent にモバイルエミュレータの文字列が含まれているという明確な条件があるため、WAF のカスタムルールで User-Agent に基づく制御が可能。
  • WAF の カスタムルールで「User-Agent ヘッダに特定文字列を含む場合はブロック」と設定することで、該当攻撃のみブロックし、正当ユーザーを許可することができる。

■ 不正解の選択肢の理由

❌ A. セキュリティグループでIPブロック

  • 理由：セキュリティグループは L3/L4 レベルで動作し、IPアドレスやポート番号のみで制御する。
  • User-Agent は HTTP ヘッダ（L7）であり、セキュリティグループでは制御不可。
  • また攻撃が「多数の IP アドレス」から行われており、IP アドレス単位の制御は実用的でない。

❌ C. CloudWatch アラーム + SNS

  • 理由：CloudWatch は監視と通知に使うものであり、リクエストそのものをブロックすることはできない。
  • SNS を使って通知は送れるが、攻撃をリアルタイムで遮断する機能はない。

❌ D. 正当な User-Agent 文字列を許可するルールを作成

  • 理由：すべての正当な User-Agent を網羅するのは困難であり、誤検知による正規ユーザーのブロックのリスクがある。
  • 攻撃者は User-Agent を容易に偽装できるため、ホワイトリスト方式は実用性に欠ける。

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

  • AWS WAF を使うと、L7（アプリケーション層）レベルでリクエストを制御できる
    • User-Agent, IP, URI, Header, Country などで制御可能
  • セキュリティグループやNACLはL3/L4層の制御に特化しており、HTTPヘッダの制御は不可
  • CloudWatch/SNSは通知用途であり、リクエストの遮断には利用できない
  • ブラックリスト方式（悪意ある User-Agent のみをブロック）の方が柔軟で安全

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

以下は問題4の内容を、指定フォーマットに従って整理・解説したものです。

■ 問題文（原文）

ある企業では、AWS Organizations の既存の組織の中に、DevOps チームごとに個別の子アカウントを作成する予定です。AWS CloudTrail はすべてのアカウントで有効化されており、一元化された AWS アカウントの Amazon S3 バケットに監査ログを書き込むように構成されています。セキュリティエンジニアは、DevOps チームのメンバーがこの構成を変更または無効にできないようにする必要があります。

これらの要件を満たす最適な方法を選択してください。

■ 選択肢（原文）

A.
特定の CloudTrail の証跡への変更を禁止する SCP を作成し、組織内の適切な組織単位またはアカウントに SCP を適用します。

B.
特定の CloudTrail の証跡への変更を禁止する IAM ポリシーを作成し、そのポリシーを AWS アカウントのルートユーザーに適用します。

C.
特定の CloudTrail の証跡への変更を禁止する IAM ポリシーを作成し、新しい IAM グループに適用します。チームメンバーには、新しい IAM グループのメンバーである個々の IAM アカウントを使用させます。

D.
CloudTrail の証跡の指定された宛先アカウントに、ソースアカウントの AWS アカウントのルートユーザーからの設定変更を禁止する S3 バケットポリシーを作成します。

■ 問題文の要件の概要

  • CloudTrail の設定が DevOps メンバーによって変更・無効化されないようにする。
  • CloudTrail は組織の複数アカウントに適用され、ログは一元的な S3 バケットに格納されている。
  • 管理を組織単位で一元的に制御する必要がある。

■ 正解の選択肢と解説

✅ 正解：A

A. 特定の CloudTrail の証跡への変更を禁止する SCP を作成し、組織内の適切な組織単位またはアカウントに SCP を適用します。

  • 理由：SCP（Service Control Policy）は AWS Organizations を用いて、組織レベルでアクセスの最大範囲を制御するガードレールです。
  • IAM ポリシーとは異なり、ルートユーザーを含めた全てのエンティティに強制的に適用されるため、CloudTrail の証跡に対する変更操作を一括で制限できます。
  • CloudTrail の証跡設定の保護には SCPの使用がベストプラクティスです。

■ 不正解の選択肢の理由

❌ B. IAM ポリシーをルートユーザーに適用

  • 理由：ルートユーザーには IAM ポリシーを直接アタッチできません。また、ルートユーザーは最小限の使用に制限すべきであり、ポリシー管理の対象にするべきではありません。

❌ C. IAM ポリシーを IAM グループに適用し、チームで使用

  • 理由：IAM ポリシーはアカウント単位での制御に過ぎず、意図的に別の権限を持つ IAM ユーザーを作成された場合に対応できない。
  • 組織全体に共通の制限を適用したい場合、IAM ポリシーではなく SCP を使うべき。

❌ D. S3 バケットポリシーでルートユーザーからの変更をブロック

  • 理由：S3 バケットポリシーは、S3 バケットへのアクセス制御にのみ効果があり、CloudTrail 自体の証跡設定や有効/無効の操作を制御することはできない。

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

  • SCP（Service Control Policy） は AWS Organizations 環境において、組織全体の最大許可範囲を制御するための機能。
    • IAM ポリシーはユーザーやロールごとのアクセス制御だが、SCP はアカウント単位に強制的に適用される。
    • ルートユーザーにも影響する点が最大の特徴。
  • CloudTrail の証跡を改ざんや削除から守るには、SCPで CloudTrail の変更 API を明示的にDenyする。
  • SCSでは、「一元的な監査」「ルートユーザー制限」「組織全体での統制」などが頻出トピック。

続けて他の問題もご希望であればお送りください。

以下は問題5の内容を指定フォーマットで整理・解説したものです。

■ 問題文（原文）

セキュリティエンジニアは、AWS CloudTrail が無効になった場合に備えて、複数の AWS リージョンで AWS CloudTrail を有効に戻すソリューションを構築する必要があります。
このソリューションを実装するための最も効率的な方法を選択してください。

■ 選択肢（原文）

A.
cloudtrail.amazonaws.com イベントソースと StopLogging イベント名を使用して Amazon CloudWatch アラームを作成し、AWS Lambda 関数をトリガーして StartLogging API を呼び出します。

B.
AWS Config マネージドルールを使用して、AWS-EnableCloudTrail の修復をトリガーします。

C.
AWS Trusted Advisor を監視して、CloudTrail のログ記録が有効になっていることを確認します。

D.
cloudtrail.amazonaws.com イベントソースと StartLogging イベント名を使用して Amazon EventBridge (CloudWatch Events) イベントを作成し、AWS Lambda 関数をトリガーして StartLogging API を呼び出します。

■ 問題文の要件の概要

  • CloudTrail が 意図せず無効化された場合 に、自動的に 再有効化する仕組み を構築したい。
  • マルチリージョン対応。
  • 最も効率的な方法を選ぶ必要がある。

■ 正解の選択肢と解説

✅ 正解：B

B. AWS Config マネージドルールを使用して、AWS-EnableCloudTrail の修復をトリガーします。

  • AWS Config のマネージドルール AWS-EnableCloudTrail は、CloudTrail が有効かどうかを評価し、**準拠していない場合に自動で修復（再有効化）**できます。
  • CloudTrail の停止検知 → 修復の自動実行という一連の流れを シンプルにかつ少ない構成で実現できる。
  • AWS Config は マルチリージョン対応であり、統合的に CloudTrail 状態を管理・強制できます。

■ 不正解の選択肢の理由

❌ A. CloudWatch アラーム + Lambda で StartLogging 呼び出し

  • StopLogging イベントを検知 → Lambda で StartLogging 実行 という流れは 実装可能だが複雑。
  • CloudWatch Logs や EventBridge の構成・Lambda 実装・権限設定などが必要で、効率面では不利。

❌ C. AWS Trusted Advisor を監視する

  • Trusted Advisor は 可視化と通知はできるが修復機能がない。
  • 手動での確認・対応を前提としており、自動復旧には不向き。

❌ D. EventBridge + Lambda で StartLogging 実行

  • EventBridge で StartLogging イベントをトリガーしても 既に有効化されているログ記録を再度呼び出すだけになる。
  • StopLogging 検出時に復旧させたい意図と合致しない。

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

  • AWS Config マネージドルールは、ベストプラクティス準拠チェックと**自動修復（リメディエーション）**が可能。
    • AWS-EnableCloudTrail ルールで CloudTrail の有効状態を継続的に監視・復旧。
  • CloudTrail 無効化の防止・検出・復旧はセキュリティ試験において重要論点。
  • Lambda や EventBridge によるイベントトリガー型の修復は実現可能だが、効率重視の設問では適さない。
  • AWS SCS試験では、「ベストプラクティスで簡潔に達成できる構成」を選択する視点が重要。

次の問題もあれば続けて送ってください。引き続きこの形式で解説いたします。

以下は、問題6に対する指定形式での解説です。

■ 問題文（原文）

ある企業では、AWS アカウントにサードパーティの ID プロバイダーと SAML ベースの SSO を使用しています。サードパーティの ID プロバイダーが期限切れの署名証明書を再発行した後、ユーザーがログインしようとすると、次のような通知が表示されました。

Error: Response Signature Invalid (Service: AWSSecurityTokenService;
Status Code: 400; Error Code: InvalidIdentityToken)

セキュリティエンジニアは、運用上のオーバーヘッドを最小限に抑えつつ、問題を解消するソリューションを提供する必要があります。
これらの条件を満たすソリューションを選択してください。

■ 選択肢（原文）

A.
ID サービスプロバイダーから更新された SAML メタデータファイルをダウンロードします。AWS CLI を使用して、AWS Identity and Access Management (IAM) で定義された AWS ID プロバイダーエンティティでファイルを更新します。

B.
新しい公開鍵を使用して ID プロバイダーのメタデータファイルに署名します。AWS CLI を使用して、AWS Identity and Access Management (IAM) で定義された AWS ID プロバイダーエンティティに署名をアップロードします。

C.
AWS Identity and Access Management (IAM) で定義された AWS ID プロバイダーエンティティが、AWS マネジメントコンソールを使用して新しい公開鍵を同期して取得するように設定します。

D.
AWS マネジメントコンソールを使用して、サードパーティの署名証明書の新しい秘密鍵を AWS Identity and Access Management (IAM) で定義された AWS ID プロバイダーエンティティにアップロードします。

■ 問題文の要件の概要

  • SAMLベースのSSO認証エラー（署名無効）発生。
  • サードパーティIdPの証明書が再発行されている。
  • AWS側のIAM IDプロバイダー設定を更新して整合性を取り戻す必要がある。
  • 運用負荷を最小限にするソリューションが求められている。

■ 正解の選択肢と解説

✅ 正解：A

A. IDサービスプロバイダーから更新されたSAMLメタデータファイルをダウンロードし、AWS CLIを使ってIAMのIDプロバイダーを更新する。

  • SAML認証では、AWSとIdPの間で証明書ベースの署名整合性が必要です。
  • IdP側の署名証明書が変更された場合、AWS側に登録されている証明書と一致しなくなり、「Response Signature Invalid」エラーが発生します。
  • これを解消するためには、新しい証明書を含んだSAMLメタデータファイルを再取得し、AWSにアップロードする必要があります。
  • aws iam update-saml-provider コマンドで簡潔に更新でき、運用上のオーバーヘッドも小さいため最適解です。

■ 不正解の選択肢の理由

❌ B. 公開鍵で署名してアップロードする

  • メタデータファイルはIdP側が生成すべきものであり、AWS側で署名や改変を行うものではありません。
  • AWS IAMは署名済みメタデータの検証はしますが、ユーザー側で署名を付加してアップロードする運用ではありません。

❌ C. 公開鍵の同期設定

  • IAMに登録されたIdPエンティティは自動的に公開鍵を取得・同期する機能はありません。
  • 常に手動またはCLI経由で更新が必要です。

❌ D. 秘密鍵のアップロード

  • AWSに秘密鍵をアップロードすることはセキュリティ的にNGですし、必要でもありません。
  • AWSが必要とするのは**公開鍵（含むメタデータ）**です。

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

  • SAML連携トラブルの定番エラーとして「Response Signature Invalid」は頻出。
  • 原因の多くは IdP側で証明書更新が行われたのに、AWS側が未更新な状態。
  • この問題を解決するには、SAMLメタデータを再取得し、IAMのSAMLプロバイダーエンティティを更新する。
  • AWS CLIの update-saml-provider コマンドを使うと手早く対応可能。
  • IAM IDプロバイダーの設定は手動管理が基本で、自動同期は非対応である点も押さえる。

次の問題も準備できましたら、ぜひお送りください。引き続きこの形式でサポートいたします。

以下は、問題7の解説を指定された形式で整理した内容です。

■ 問題文（原文）

セキュリティエンジニアが IAM ユーザーとして AWS マネジメントコンソールにサインインし、セキュリティロールの IAM ロールに切り替えました。メンテナンス操作を実行するには、セキュリティエンジニアは、セキュリティロールを信頼できるエンティティとして一覧表示するメンテナロールの IAM ロールに切り替える必要があります。セキュリティエンジニアは、メンテナロールに切り替えようとしますが、失敗します。

失敗の可能性の高い原因を選択してください。

■ 選択肢（原文）

A.
セキュリティロールのポリシーには、sts:AssumeRole アクションを許可するステートメントが含まれていません。

B.
セキュリティエンジニアがアカウントにサインインするために使用した IAM ユーザーに、セキュリティロールとメンテナロールが割り当てられていません。

C.
セキュリティエンジニアは、AWS アカウントのルートユーザーとしてログインしている必要があります。これにより、任意のロールを直接引き受けることができます。

D.
メンテナロールは、信頼できるエンティティとして IAM ユーザーが含まれていません。

■ 問題文の要件の概要

  • IAMユーザーがAWSマネジメントコンソールからセキュリティロールに切り替え済。
  • 次に別のメンテナロールに切り替えようとして失敗。
  • 原因は「切り替え先ロールの信頼関係」または「ロールチェーンの制約」が疑われる。
  • 最も可能性の高い原因を特定する必要がある。

■ 正解の選択肢と解説

✅ 正解：D

D. メンテナロールは、信頼できるエンティティとして IAM ユーザーが含まれていません。

  • AWSマネジメントコンソールはロールの連鎖（ロール→ロール）をサポートしていません。
    • そのため、「セキュリティロール」から「メンテナロール」に直接切り替えることはできません。
  • ロールを引き受けるには、そのロールの**信頼ポリシー（Trust Policy）**に自分が信頼されたエンティティ（プリンシパル）として含まれている必要があります。
  • 今回の状況では、IAMユーザーはセキュリティロール経由でメンテナロールに切り替えようとしていますが、セキュリティロールからの連鎖が許されないため、IAMユーザー自身がメンテナロールの信頼されたエンティティでなければならない。

■ 不正解の選択肢の理由

❌ A. sts:AssumeRole アクションがセキュリティロールにない

  • この設定はCLIやSDKでロールの連鎖を行うときに必要。
  • しかし、マネジメントコンソールではロールの連鎖自体がサポートされていないため、そもそもセキュリティロール経由で AssumeRole はできない。
  • よって、セキュリティロールに sts:AssumeRole があっても問題は解決しない。

❌ B. IAMユーザーにセキュリティロールとメンテナロールが割り当てられていない

  • IAMロールはユーザーに「割り当てる」ものではなく、AssumeRoleできる設定（信頼ポリシー＋権限ポリシー）が重要。
  • IAMユーザーは最初にセキュリティロールに切り替えているので、セキュリティロールの AssumeRole は成功している。
  • 問題は次のロールへの切り替え（連鎖）であり、この選択肢は本質から外れている。

❌ C. ルートユーザーとしてログインする必要がある

  • AWSベストプラクティスにおいてルートユーザーでのログイン・操作は推奨されていない。
  • このような設定を必要とする運用は誤り。
  • ロールの切り替えには、IAMユーザーと適切な信頼関係で十分。

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

  • マネジメントコンソールはロールの連鎖をサポートしない（CLIやAPIは可能）。
  • 複数ロールに切り替えが必要な場合、IAMユーザーがすべての対象ロールに対して直接AssumeRoleできるように信頼ポリシーを設定する必要がある。
  • 信頼ポリシーとアクセス許可ポリシーは別物。信頼されていないエンティティはAssumeRoleできない。
  • ルートユーザーでの作業は避けるのが原則。セキュリティの観点からもNG。

次の問題もお送りいただければ、引き続きこの形式でご対応します。

RELATED POST