Uncategorized

131-140

 

問題文
【SCS-131】あるグローバル企業は、レイヤー3、4、7でDDoS攻撃を緩和し、対応する必要があります。
この会社のすべてのAWSアプリケーションは、Amazon CloudFrontとAmazon Route 53を使用してAmazon S3にホストされた静的コンテンツを持つサーバーレス構成です。
どのソリューションがこれらの要件を満たすでしょうか？

選択肢

  1. AWS WAFをAWS Businessサポートプランにアップグレードして使用します。
  2. オリジンアクセスIDで構成されたアプリケーションロードバランサーでAWS Certificate Managerを使用する。
  3. AWS Shield Advancedを使用します。
  4. AWS WAFを使用して、AWS KMSで暗号化されたAWS Lambda関数を保護し、すべてのイングレストラフィックを制限するNACLを使用します。

正解の選択肢と解説

✅ 3. AWS Shield Advancedを使用します。

理由

  • L3/L4 DDoS 保護: Shield Advanced は AWS グローバルネットワークのエッジ (CloudFront、Route 53、Global Accelerator など) で大規模なボリューム型攻撃を自動検知・緩和。
  • L7 (アプリケーション層) 保護: Shield Advanced の料金に AWS WAF の追加料金が含まれるため、カスタムルールを使って HTTP/HTTPS レイヤーの攻撃も同一ダッシュボードで可視化・対処できる。
  • CloudFront / Route 53 との統合: 本シナリオで利用している CloudFront 配信元 (S3) と Route 53 DNS はいずれも Shield Advanced の自動保護対象。
  • 付帯機能: 攻撃インシデント時の DDoS Response Team (DRT) 24/7 サポートやコスト保護 (DDoS コスト保証) も得られ、エンタープライズ規模の可用性要件に合致。

不正解の選択肢の理由

選択肢誤りのポイント
1AWS WAF は主に L7 (HTTP/HTTPS) 専用。Business サポートプランへアップグレードしても L3/L4 の大規模 DDoS 緩和機構は得られない。
2ALB は CloudFront 配信の静的 S3 オリジンには不要。ALB と ACM は TLS 終端に関する話題であり、DDoS 緩和 (特に DNS やネットワーク層) をカバーしない。
4WAF + NACL + KMS はコンピュート／暗号化／ネットワーク制御の個別機能を組み合わせたものだが、CloudFront・Route 53 経由の大規模 L3/L4 攻撃には非対応。NACL は VPC 内サブネット境界でのステートレス制御であり、エッジサービスを保護しない。

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

  1. AWS Shield Standard vs. Advanced
    • Standard は全 AWS 顧客に無料提供。主に L3/L4 の一般的 DDoS 緩和。
    • Advanced は L3/L4 の拡張保護 + WAF Advanced rules + DRT サポート + コスト保護。CloudFront、Route 53、Global Accelerator などグローバルエッジサービスを対象。
  2. AWS WAF の役割
    • レイヤー7 (HTTP/HTTPS) フィルタリング専用。Shield Advanced の一部として使うか、単独で Web 攻撃対策に利用。
    • DDoS というより “悪意のある Web リクエスト” に焦点。
  3. CloudFront ＋ S3 オリジンのセキュリティ設計
    • CloudFront オリジンアクセスコントロール (OAC)／OAI で S3 バケットを非公開にし、エッジ配信のみ許可。
    • DDoS 緩和は CloudFront エッジ → Shield (Standard/Advanced) で行う。
  4. Route 53 への DDoS 攻撃
    • DNS はインフラ層の最前線。Shield Advanced で保護すると過剰クエリや DNS 反射攻撃の影響を最小化できる。
  5. コストとサポート
    • Shield Advanced には使用量連動と月額固定 (エンドポイントあたり & 区域外データ転送料) が発生。
    • Advanced 加入で DRT への直接連絡が可能。試験では「ビジネス上クリティカルなワークロード」＝ Shield Advanced がよく問われる。

これらを整理して覚えておくと、DDoS/エッジセキュリティ分野の設問で的確に選択肢を絞り込めます。

問題文
【SCS-132】ある会社の開発チームは最近、Java アプリケーションをデフォルトの AWS Elastic Beanstalk 環境にデプロイしました。
アプリケーションは、同じアカウントのデフォルト設定を持つ Amazon S3 バケットに接続できません。
この問題をトラブルシューティングするには、セキュリティエンジニアは何をすべきですか?

選択肢

  1. Elastic Beanstalk のサービス ロールが Amazon S3 にアクセスできることを確認します。
  2. Elastic Beanstalk インスタンスプロファイルが Amazon S3 にアクセスできることを確認します。
  3. AWSElasticBeanstalkFullAccess 管理ポリシーが Elastic Beanstalk 環境にアタッチされていることを確認します。
  4. S3 バケットポリシーが Elastic Beanstalk アプリケーション ARN からのアクセスを許可していることを確認します。

正解の選択肢と解説

✅ 2. Elastic Beanstalk インスタンスプロファイルが Amazon S3 にアクセスできることを確認します。

  • インスタンスプロファイル (EC2 ロール) は、Elastic Beanstalk 環境内で実行される EC2 インスタンスが AWS リソースにアクセスするときに使用される IAM ロール。
  • アプリケーションコードが AWS SDK を介して S3 にアクセスする場合、インスタンスが引き受けるこのロールに s3:GetObject などの適切な権限が必要。
  • デフォルト環境を作成するときに生成される aws-elasticbeanstalk-ec2-role には S3 へのフルアクセスは含まれていないため、バケットへの接続失敗は典型的な症状。
  • まず インスタンスプロファイルに S3 アクセス権限を追加 (またはカスタム IAM ポリシーをアタッチ) して問題を切り分けるのが正攻法。

不正解の選択肢の理由

選択肢誤りのポイント
1サービスロール は Elastic Beanstalk がスタック操作 (Auto Scaling 変更、ログローテーションなど) を行う用途。アプリケーションの S3 API 呼び出しには使用されない。
3AWSElasticBeanstalkFullAccess はコンソールユーザや CloudFormation が EB 環境を操作するための権限セットで、インスタンスの実行権限とは無関係。加えて過剰権限でセキュリティベストプラクティスに反する。
4同一アカウント内の S3 バケットは バケットポリシーが空でも IAM 許可があればアクセス可能。今回の症状は IAM 側が原因であり、バケットポリシー追加は不要。

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

  1. Elastic Beanstalk の 2 種類の IAM ロール
    • サービスロール (aws-elasticbeanstalk-service-role) ➜ 環境の作成・管理用。
    • インスタンスプロファイル (aws-elasticbeanstalk-ec2-role) ➜ アプリが実行される EC2 のアクセス権。リソースアクセス問題はまずこちらを確認。
  2. 同一アカウントの S3 アクセス許可モデル
    • デフォルトのバケットポリシーは空 (許可も拒否もなし)。
    • IAM ポリシーが許可されていればアクセス可能。拒否系ポリシーや SCP が無い限り、バケットポリシーの追加は不要。
  3. 最小権限原則 (PoLP)
    • トラブルシューティングでもフルアクセスや管理ポリシー付与は最後の手段。必要最小限 (s3:GetObject, s3:PutObject など) で解決できるか確認。
  4. ロール／ポリシーのどこを調べるか
    • 信頼ポリシー: EC2 が AssumeRole できるか。
    • 権限ポリシー: 必要なアクションとリソースが許可されているか。
    • 明示的 Deny が無いか。
  5. Beanstalk 標準ロールの不足権限は試験頻出
    • “アプリが S3/SES/SNS へアクセスできない”→ “インスタンスプロファイルの IAM 設定を確認” が定石として問われやすい。

これらの観点を押さえておくと、Elastic Beanstalk と IAM 権限絡みの設問を素早く判断できます。

問題文
【SCS-133】ある企業が us-east-1 リージョンに Amazon GuardDuty をデプロイしました。
会社の Amazon EC2 インスタンスに関連するすべての DNS ログを検査したいと考えています。
EC2 インスタンスが確実にログに記録されるようにするには、セキュリティエンジニアは何をすべきですか?

選択肢

  1. ホスト名用に構成された IPv6 アドレスを使用します。
  2. 外部 DNS リゾルバーを、AWS にのみ表示される内部リゾルバーとして構成します。
  3. すべての EC2 インスタンスに AWS DNS リゾルバーを使用します。
  4. すべての EC2 インスタンスのロギングを使用して、サードパーティの DNS リゾルバーを構成します。

正解の選択肢と解説

✅ 3. すべての EC2 インスタンスに AWS DNS リゾルバーを使用します。

  • GuardDuty の DNS ログ取り込みは Route 53 Resolver 依存
    GuardDuty は VPC 内の “Amazon-provided DNS” (デフォルトで VPC CIDR + 2 のアドレス) や Route 53 Resolver エンドポイントを経由したクエリのみをデータソースとして取得します。
  • EC2 側で Amazon DNS を利用していれば自動的に検査対象
    OS の /etc/resolv.conf などでデフォルトの AWS DNS を指すようにすれば、追加設定なしで GuardDuty が DNS クエリを分析できます。
  • 外部／独自リゾルバー経由のクエリは GuardDuty では見えない
    その場合は別途 Route 53 Resolver Query Logging を有効にしてログを集め、別の分析基盤で処理する必要がありますが、問題文は GuardDuty のみでの検査を求めているため該当しません。

不正解の選択肢の理由

選択肢誤りのポイント
1IPv6 を使うかどうかは GuardDuty の DNS 取り込みに無関係。DNS リゾルバーが Amazon DNS であることが条件。
2“外部リゾルバー” を内部に隠蔽しても Amazon DNS ではないため GuardDuty の DNS データソースにならない。
4サードパーティリゾルバーのロギングは GuardDuty では解析されない。別途ログを集約して自前で分析する必要がある。

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

  1. GuardDuty のデータソース
    • VPC Flow Logs、CloudTrail イベント、DNS クエリログ (Route 53 Resolver)。DNS については Amazon-provided DNS を利用している VPC に限られる。
  2. Amazon-provided DNS のアドレス
    • VPC CIDR base + 2 (例: 10.0.0.2) がデフォルト。EC2 の DHCP オプションセットで上書きしない限り自動設定される。
  3. カスタム DNS と GuardDuty
    • カスタムリゾルバーを使う場合、GuardDuty では DNS 検査が行えない。Route 53 Resolver Query Logging + Athena/SIEM などの別手法が必要。
  4. リージョン展開
    • GuardDuty はアクティベートしたリージョンでのみ DNS ログを検査する。マルチリージョン環境ではすべてのリージョンで有効化するか、組織管理アカウント経由で一括有効化する。
  5. 最小構成で効果を得る手順
    • “EC2 からの DNS ログを GuardDuty で検査したい” ➜ “まず EC2 が Amazon-provided DNS を利用しているか確認” が定石。DNS ログ収集専用の設定変更や追加コストなしで脅威検知が始まる。

これらを理解しておくと、GuardDuty と DNS ログに関する設問で正しい判断がしやすくなります。

問題文
【SCS-134】ある企業では、IDプロバイダ（IdP）に所属する数千人の開発者に対し、AWSリソースへの安全なアクセスを提供しています。
同社の開発者は、IAM資格情報を使用して、企業敷地の（ネットワーク）内から一連のAWSサービスにアクセスしています。
新しいIAMユーザーのプロビジョニングの要求が大量にあるため、アクセス許可の付与に長い時間がかかっています。
セキュリティエンジニアは、開発者がプロビジョニングの遅延を避けるために、自分のIAMクレデンシャルを他人と共有しているという報告を受けました。
このため、セキュリティエンジニアは全体的なセキュリティについて懸念を抱いています。
どのアクションが、セキュリティに対処する要件を満たすでしょうか？

選択肢

  1. AWS CloudTrailイベント用のAmazon CloudWatchアラームを作成する。同じIAM認証情報のセットが複数の開発者によって使用されたときに通知を送信するためにメトリックフィルタを作成する。
  2. AWSと既存の企業IdPの間にフェデレーションを作成する。IAMロールを活用し、AWSリソースへのフェデレーションアクセスを提供する。
  3. 企業敷地内とVPCの間にVPNトンネルを作成する。企業構内から発信された場合のみ、すべてのAWSサービスへの許可を許可する。
  4. 各IAMユーザーに対して複数のIAMロールを作成する。同じIAM資格情報を使用するユーザーが、同時に同じIAMロールを引き受けることができないようにする。

正解の選択肢と解説

✅ 2. AWSと既存の企業IdPの間にフェデレーションを作成する。IAMロールを活用し、AWSリソースへのフェデレーションアクセスを提供する。

  • 根本原因の解消: 静的 IAM ユーザーを大量に発行する必要をなくし、IdP 側の認証情報をそのまま使って一時的な AWS 資格情報 (STS トークン) を払い出すことでクレデンシャル共有の動機を排除。
  • セキュリティ強化: 資格情報は短時間で失効し、ロールに最小権限を割当て可能。個人ごとの IdP 認証が必須になるため、なりすまし・共有は困難。
  • 運用効率: 新規開発者は IdP でプロビジョニングされるだけで即日 AWS へアクセス可能。IAM 側の個別ユーザー作成待ちが発生しない。

不正解の選択肢の理由

選択肢なぜ要件を満たさないか
1CloudTrail + メトリックで共有を検知できても 根本の共有行為を阻止できない。運用負荷が高く、資格情報発行の遅延問題も解決しない。
3VPN でネットワーク経路を限定しても、同じ IAM 資格情報の共有は依然可能。またクラウド作業を社内 NW に限定すると開発効率も低下。
4ロール増殖は管理が煩雑で、本質的に 静的クレデンシャルを使い続ける問題 を残す。共有防止にもならない。

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

  1. フェデレーション & SSO ベストプラクティス
    • IdP と AWS を SAML/OIDC で連携し、IAM ロールを AssumeRole させる。新規ユーザーは IdP 側でのみ管理。
    • 一時的な STS 資格情報 (最長 12h) により漏えいリスクを大幅低減。
  2. IAM ユーザー vs. フェデレーティッドユーザー
    • 静的アクセスキーは長期・共有・ローテーション忘れのリスク。
    • フェデレーションは Just-in-Time アクセスと最小権限ロールで運用スケールに強い。
  3. 資格情報共有への対策
    • 未然防止が第一 (SSO、MFA、短期トークン)。
    • 監視（CloudTrail＋Athena/GuardDuty）は補助的手段として重要だが、共有を許容する構成では本末転倒。
  4. IdP 統合の典型フロー
    1. ユーザーが IdP にサインイン（企業認証）。
    2. IdP が SAML アサーションで IAM ロールを指示。
    3. AWS STS が一時的なアクセスキー/セッショントークンを発行。
    4. 開発者は SDK/CLI/Console でロールセッションを利用。
  5. 試験での判断基準
    • 「資格情報共有／大量ユーザー管理が負担」→「IdP フェデレーション／SSO」 が定番パターン。
    • ネットワーク制限や監視は補完策であり、根本解決と問われたらフェデレーションを選ぶ。

これらの観点を理解していれば、ユーザー＆アクセス管理に関する SCS の設問で正答を導きやすくなります。

問題文
【SCS-135】ある会社は最近、Amazon Route 53 を DNS プロバイダーとして使用し始めました。
会社は、Route 53 が受け取るパブリック DNS クエリをログに記録する必要があります。
同社は、Route 53 のパブリック DNS クエリロギングを有効にしました。
クエリは、1 年以上経過したログを削除する耐久性の高いストレージソリューションに保存する必要があります。
これらの要件を最も費用対効果の高い方法で満たすソリューションはどれですか?

選択肢

  1. ログデータを Amazon S3 にエクスポートするように Route 53 を設定します。 1 年以上経過したターゲット S3 バケット内のオブジェクトを削除する S3 ライフサイクルポリシーを構成します。
  2. ログデータを Amazon S3 にエクスポートするように Route 53 を設定します。1 年以上経過したログファイルを削除するために、AWS Lambda 関数を 1 時間ごとに実行するように設定します。
  3. ログデータを Amazon CloudWatch Logs にエクスポートするように Route 53 を設定します。対象の CloudWatch Logs ロググループに対して、保持期間を 1 年に設定します。
  4. ログデータを Amazon CloudWatch Logs にエクスポートするように Route 53 を設定します。 CloudWatch Logs Insights を使用して、1 年以上経過したログ エントリを特定して削除します。

正解の選択肢と解説

✅ 1. ログデータを Amazon S3 にエクスポートするように Route 53 を設定し、1 年以上経過したオブジェクトを削除する S3 ライフサイクルポリシーを構成する。

  • 耐久性: S3 は 99.999999999 %（11 ナイン）の耐久性を提供し、ログ保管に十分。
  • 費用対効果: S3 は CloudWatch Logs より GB あたりの保管コストが低く、ライフサイクルルールで古いデータを自動削除すれば追加料金なし。必要に応じて Glacier／IA 層への移行も同一ルールで設定可能。
  • 運用の容易さ: Route 53 パブリック DNS クエリログはバケットを指定するだけで自動出力。ライフサイクルポリシーは数クリックで設定でき、Lambda や追加サービスは不要。

不正解の選択肢の理由

選択肢誤り・不足のポイント
2Lambda を 1 時間ごとに実行すると実行回数課金が積み上がり、不要な運用負荷とコスト。ライフサイクルポリシー一本で済む。
3CloudWatch Logs の長期保管は S3 より高コスト。大量 DNS ログを 1 年以上保存すると料金が割高になる。
4Insights クエリを使った削除は手動 or 定期バッチが必要で非自動化。さらに CloudWatch Logs 自体の保管コストが高い。

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

  1. Route 53 パブリック DNS クエリログの保存先
    • S3 または CloudWatch Logs を選択可能。大量データの長期保管は S3 が定番。
  2. S3 ライフサイクルポリシー
    • ルールで日時条件に応じて Transition （IA/Glacier へ移行）や Expiration （削除）を自動実行。追加コード不要。
  3. コスト最適化の基本
    • 長期アーカイブ＝Glacier → 削除 が最安。問われているのは「削除」であり、ライフサイクル Expiration が最もシンプル。
  4. CloudWatch Logs の保持設定
    • 日次 GB あたり料金がかかり続ける。短期モニタリング要件向きで、長期保管には非効率。
  5. 運用負荷 vs. 自動化
    • Lambda で削除は柔軟だがメンテナンス／バグのリスク。S3 ライフサイクルは完全マネージドで“セット＆忘れる”運用が推奨。

これらを覚えておくと、ログ保管コスト最適化やライフサイクル管理を問う SCS 問題で素早く正解を選べます。

問題文
【SCS-136】ある企業が、既存の Microsoft Active Directory で定義されている ID とグループを使用して、AWS リソースへのアクセスを制御したいと考えています。
AWS サービスの許可を Active Directory のユーザー属性にマッピングするために、AWS アカウントで何を作成しなければなりませんか？

選択肢

  1. AWS IAMグループ
  2. AWS IAMユーザー
  3. AWS IAMロール
  4. AWS IAMアクセスキー

正解の選択肢と解説

✅ 3. AWS IAMロール

  • SAML フェデレーションの受け皿
    Active Directory (AD) と AWS を SAML 連携すると、AD IdP から渡された RoleArn と RoleSessionName 属性に基づいて IAM ロール を引き受けます。
  • 属性ベースアクセス制御 (ABAC)
    ロールのポリシー内で AWS リソースアクセス許可を aws:PrincipalTag などのキーにマッピングすれば、AD 側のユーザー属性（部門・職位等）を直接許可条件に利用可能。
  • ユーザー／グループを AWS 側で管理しない
    IAM ユーザーやグループを大量に作成せずに済み、ID 管理を AD へ一元化できるためセキュリティと運用効率を両立。

不正解の選択肢の理由

選択肢なぜ誤りか
1. IAM グループグループを作成しても AD 属性と自動連携できず、結局ユーザー追加作業が発生。ABAC も実装不可。
2. IAM ユーザー固定クレデンシャルが増え管理負担と漏えいリスクが高まる。フェデレーション利用の利点を失う。
4. IAM アクセスキー単なる認証情報。属性マッピングやポリシー制御には寄与せず、長期キー管理の問題を抱える。

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

  1. AD ⇔ AWS フェデレーション手順
    • AD FS など IdP で SAML アサーションに RoleArn / PrincipalArn を付与。
    • ユーザーは STS AssumeRoleWithSAML で一時クレデンシャルを取得。
  2. ABAC（属性ベースアクセス制御）
    • IdP から渡された属性を IAM ロールのセッションタグに自動付与。
    • ポリシー側で Condition に StringEquals 等でタグ値を比較してアクセス許可。
  3. IAM ロールの利点
    • 最小権限ロールを一元管理、短期トークンで漏えいリスクを低減。
    • 同一ロールを複数ユーザーが動的に引き受けられ、スケールに強い。
  4. IAM ユーザー／グループは極力避ける
    • 大規模組織では SSO／フェデレーション＋ロールがセキュリティ・運用のベストプラクティス。
  5. 試験での定石
    • “オンプレ AD の属性で AWS 権限を制御”→“SAML フェデレーション + IAM ロール + ABAC” が正解パターン。

これらを理解しておけば、フェデレーションとアクセス制御を扱う SCS 問題で確実に得点できます。

問題文
【SCS-137】ある会社は、複数の本番用AWSアカウントと中央のセキュリティAWSアカウントを保有しています。
同社のセキュリティアカウントは集中監視のために使用され、すべての企業アカウントのすべてのリソースに対するIAM特権を持っています。
会社のすべてのAmazon S3バケットは、コンテンツをデータ分類する為に値でタグ付けされています。
セキュリティエンジニアは、セキュリティアカウントにバケットポリシーの遵守を強制する監視ソリューションを導入しています。
このシステムは、すべての本番アカウントのS3バケットを監視し、あらゆるポリシーの変更がバケットのデータ分類に従っていることを確認する必要があります。
何らかの変更がコンプライアンスから外れている場合、セキュリティチームに迅速に通知されなければなりません。
どのアクションの組み合わせが必要なソリューションとなりますか?(3つ選んでください)

選択肢

  1. 本番アカウントのAmazon CloudWatch Eventsを構成して、すべてのS3イベントをセキュリティアカウントのイベントバスに送信します。
  2. セキュリティアカウントでAmazon GuardDutyを有効化し、本番アカウントをメンバーとして参加させます。
  3. S3バケットの作成または変更イベントを検出するために、セキュリティアカウントでAmazon CloudWatch Eventsルールを構成します。
  4. AWS Trusted Advisorを有効化し、セキュリティ担当者に割り当てられたメールアドレスに対するメール通知を有効にします。
  5. セキュリティアカウントでAWS Lambda関数を呼び出し、S3イベントに応答してS3バケットの設定を分析し、セキュリティチームにコンプライアンス違反の通知を送信します。
  6. S3バケットにPUT、POST、DELETEイベントのイベント通知を設定します。

正解の選択肢と解説

正解解説
1各本番アカウントで EventBridge (旧 CloudWatch Events) ルールを作成し、CloudTrail が発行する PutBucketPolicy／PutBucketAcl／CreateBucket などの API コール をセキュリティアカウントの クロスアカウントイベントバスへ転送する。これでリアルタイムにポリシー変更イベントを集中収集できる。
3セキュリティアカウント側で、受信したイベントバスを対象に CreateBucket／PutBucketPolicy／DeleteBucketPolicy などを検出するルールを作成し、後段アクション（Lambda など）を起動する。
5ルールが発火したら Lambda を呼び出し、対象バケットの タグ (データ分類) を取得し、変更されたバケットポリシーが基準に合致するかプログラムで評価。違反があれば SNS／ChatOps／メール でセキュリティチームへ即時通知する。

全体フロー
本番アカウント → EventBridge クロスアカウント送信 (①) →
セキュリティアカウント EventBridge ルールで検出 (③) →
Lambda で評価＆通知 (⑤)

不正解の選択肢の理由

選択肢なぜ要件を満たさないか
2GuardDuty は脅威検出サービスであり、S3 バケットポリシーのコンプライアンス監視やタグ判定は行わない。
4Trusted Advisor は S3 パブリックアクセスやバージョニングなどの静的チェックのみ。リアルタイムのポリシー変更検知・タグ別評価には不向き。
6S3 イベント通知は オブジェクトレベル（PUT/POST/DELETE）であり、バケットポリシー変更やタグ付けイベントを通知できない。

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

  1. EventBridge × CloudTrail
    • CloudTrail で記録される管理 API コールは EventBridge ルールでフィルタできる。クロスアカウント転送により集中監視が可能。
  2. クロスアカウントイベントバス設計
    • 送信側アカウントで PutEvents を許可し、受信側（セキュリティアカウント）のイベントバスで EventBusPolicy を設定。
  3. タグ＋Lambda＝動的コンプライアンス評価
    • バケットやリソースに付与した分類タグを Lambda で読み取り、GetBucketPolicy の内容と照合すれば ABAC 的なガバナンスを実装できる。
  4. リアルタイム通知
    • 監視要件が「迅速な通知」の場合、SNS／ChatOps 連携を Lambda で発火させる設計が頻出。
  5. GuardDuty／Trusted Advisor の守備範囲
    • GuardDuty ＝ 脅威検知、Trusted Advisor ＝ ベストプラクティス診断。構成変更コンプライアンス監視は EventBridge＋Lambda が王道。

これらの知識を押さえておくと、マルチアカウント監視・リアルタイムコンプライアンスを扱う SCS 問題で確実にポイントを獲得できます。

問題文
【SCS-138】ある会社は、Amazon S3 バケット内のすべてのリージョンからの AWS CloudTrail ログの集中ロギングとモニタリングを実装しました。
ログファイルは、AWS KMS を使用して暗号化されます。
セキュリティエンジニアは、Amazon EC2 インスタンスでホストされているサードパーティツールを使用してログファイルを確認しようとしています。
セキュリティエンジニアは S3 バケットのログにアクセスできず、アクセス拒否エラーメッセージを受け取ります。
セキュリティエンジニアはこの問題を解決するために何をすべきですか?

選択肢

  1. セキュリティエンジニアが使用するロールが、KMS CMK を使用してオブジェクトを復号化するアクセス許可を付与していることを確認します。
  2. セキュリティエンジニアが使用するロールが、KMS CMK を使用してオブジェクトを復号化するアクセス許可を付与し、S3 バケットとオブジェクトへのアクセスを許可することを確認します。
  3. EC2 インスタンスプロファイルが使用するロールが、KMS CMK を使用してオブジェクトを復号化するアクセス許可を付与し、S3 バケットとオブジェクトへのアクセスを許可することを確認します。
  4. EC2 インスタンスプロファイルが使用するロールが、KMS CMK を使用してオブジェクトを復号化するアクセス許可を付与していることを確認します。

正解の選択肢と解説

✅ 3. EC2 インスタンスプロファイルが使用するロールが、KMS CMK を使用してオブジェクトを復号化するアクセス許可を付与し、S3 バケットとオブジェクトへのアクセスを許可することを確認します。

  • 実際に S3 へアクセスしているのは EC2 インスタンス ⇒ インスタンスプロファイル（EC2 ロール）の権限が評価される。
  • KMS 暗号化オブジェクト をダウンロードして読むには
    • kms:Decrypt（CMK）
    • s3:GetObject、s3:ListBucket など（バケット／オブジェクト）
      両方の許可が必要。
  • これらをロールのポリシー（または CMK キーポリシーの Principal）に追加すればアクセス拒否は解消される。

不正解の選択肢の理由

選択肢誤りのポイント
1KMS の復号権限のみ。s3:GetObject が無いので依然としてアクセス拒否。さらに対象は EC2 ロールではなく「エンジニアのロール」。
2KMS と S3 権限はそろっているが、アクセス主体が誤り。ツールは EC2 から実行されるため、このロールは使われない。
4依然として s3:GetObject 権限が欠落。暗号復号だけではオブジェクトを取得できない。

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

  1. KMS で暗号化された S3 オブジェクトのアクセス要件
    • IAM またはバケットポリシーで S3 権限 (s3:GetObject, s3:ListBucket)
    • キーポリシーまたは IAM で KMS 権限 (kms:Decrypt, kms:GenerateDataKey)
      どちらかが欠けると AccessDenied。
  2. インスタンスプロファイル (EC2 ロール)
    • EC2 上のプロセスは自動的にインスタンスプロファイルを引き受ける。CLI/API アクセス権はこのロールで決まる。
  3. CMK キーポリシー vs. IAM ポリシー
    • CMK キーポリシーで IAM ロールを Principal に含めるか、kms:Decrypt を含む IAM インライン／マネージドポリシーをアタッチ。
  4. CloudTrail ログ集中ストレージのベストプラクティス
    • 監査／ツール用に読み取り専用ロールを作成し、必要最小権限＋KMS 権限を付与。
    • バケットポリシーで組織単位 or セキュリティアカウントからのアクセスをホワイトリスト化するとより安全。
  5. トラブルシューティングの順序
    1. S3 アクセス権 (AccessDenied → 403) を確認。
    2. KMS 権限 (AccessDeniedException → 400) を確認。
    3. CMK キーポリシーと IAM ポリシーの両方を見比べて不足を補う。

このパターンは SCS で頻出なので、**「暗号化オブジェクトを読む＝S3 権限＋KMS 権限＋正しいロール」**とセットで覚えておくとよいでしょう。

問題文
【SCS-139】あるセキュリティチームは、承認されたAmazon Machine Images (AMI)のみを使用することを義務付けました。
セキュリティチームは、どのようにしてこの義務付けに対するコンプライアンスを厳守できますか?

選択肢

  1. すべてのAmazon EC2インスタンスを終了させ、承認されたAMIで再起動させる。
  2. AWS Systems Managerを使用して、稼働中のすべてのインスタンスにパッチを適用する。
  3. AWS Configルールを導入し、稼働中の全インスタンスが準拠しているかチェックする。
  4. Amazon CloudWatch Logsでメトリックフィルタを定義し、コンプライアンスを検証する。

正解の選択肢と解説

✅ 3. AWS Configルールを導入し、稼働中の全インスタンスが準拠しているかチェックする。

  • AWS Config の Managed Rule
    • approved-amis-by-id または approved-amis-by-tag を使えば、インスタンスの起動時および定期評価で使用 AMI を自動判定。
  • コンプライアンス違反の自動検知とアラーム
    • ルール違反が発生すると Config コンソールや EventBridge にイベントを発行でき、リアルタイム通知・自動リメディエーション (Lambda, SSM Automation) も設定可能。
  • 継続的モニタリング
    • 既存インスタンスだけでなく新規に起動されるインスタンスも継続的に評価し、組織規模で強制力を担保。

不正解の選択肢の理由

選択肢なぜ誤りか
1既存インスタンスを一括終了するのは業務停止リスクが高すぎる。再発防止の継続的監視も行えない。
2Systems Manager のパッチ適用は OS 更新の話であり、AMI そのものの承認制御とは無関係。
4CloudWatch Logs のメトリックフィルタはログ解析用途。AMI ID 準拠の評価を継続的かつ網羅的に行う仕組みではない。

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

  1. AWS Config Managed Rules
    • approved-amis-by-id: 許可された AMI ID リストを直接指定。
    • approved-amis-by-tag: 承認 AMI に共通タグを付与し、タグ一致で判定。
  2. EventBridge + Lambda で自動修復
    • ルール違反イベントで TerminateInstance, StopInstance、通知 (SNS/Slack) を自動化できる。
  3. タグ or ID 管理の選択
    • ゴールデン AMI を継続的にローテーションする場合は タグ方式 が柔軟。
  4. Config Recorder と Delivery Channel
    • Config 評価を有効にするには Recorder と S3 配信先を設定しておく。
  5. 試験パターン
    • “承認済みリソースのみ許可”→“AWS Config で継続的コンプライアンス評価” が鉄板シナリオ。

これを押さえておけば、AMI コンプライアンスやガバナンスを問う SCS 問題に確実に対応できます。

問題文
【SCS-140】ある企業では、Amazon Linux EC2インスタンスからのシステムログをレビュー中に、セキュリティエンジニアがAmazon CloudWatch Logsエージェントで適切に警告または報告されなかったsudoコマンドがあることに気づきました。
なぜsudoコマンドの警告が報告されなかったのでしょうか。

選択肢

  1. セキュリティグループがアウトバウンドポート80のトラフィックをブロックしており、エージェントがログを送信するのを妨げています。
  2. EC2インスタンスのIAMインスタンスプロファイルが、CloudWatch LogsエージェントがログをCloudWatchにプッシュできるように適切に構成されていません。
  3. CloudWatch Logsのデータ保護のステータスが有効に設定されており、OSのセキュリティイベントログを取り込むことができないようになっています。
  4. VPCは、すべてのトラフィックがプロキシを経由する必要があり、CloudWatch Logsエージェントはプロキシ構成をサポートしていません。

正解の選択肢と解説

✅ 2. EC2インスタンスのIAMインスタンスプロファイルが、CloudWatch LogsエージェントがログをCloudWatchにプッシュできるように適切に構成されていません。

CloudWatch Logs エージェント（または Unified CloudWatch Agent）は、logs:CreateLogStream と logs:PutLogEvents などの API を呼び出してログを CloudWatch に送信します。
EC2 インスタンスにアタッチされた インスタンスプロファイル（IAM ロール） にこれらの権限が含まれていない場合、ログはローカルには生成されても CloudWatch へは転送されません。したがって sudo 実行が /var/log/secure などに記録されていても、CloudWatch Logs 側のメトリックフィルタやアラームが反応しないため警告が出ません。

不正解の選択肢の理由

選択肢誤りのポイント
1CloudWatch Logs は HTTPS (TCP 443) を使用するため、ポート 80 のブロックは影響しない。
3データ保護機能は機密データをマスキングするためのもので、ログの取り込み自体を拒否しない。
4CloudWatch Logs エージェントは HTTP/HTTPS プロキシ設定をサポートしている。VPC のプロキシ要件だけでは送信失敗の直接原因にならない。

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

  1. CloudWatch Logs 送信権限
    • インスタンスプロファイルに logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents が必要。
  2. ログ欠落時の切り分け
    • まず IAM 権限を確認し、次にエージェント設定ファイルで対象ログパスが含まれているかを確認する。
  3. ネットワーク要件
    • CloudWatch Logs エンドポイントは 443/TCP。アウトバウンド HTTPS とプロキシ設定の可否を押さえる。
  4. メトリックフィルタ／アラームの前提
    • CloudWatch Logs にログが到達して初めてフィルタ・アラームが機能する。権限不足でアップロードできないと検知も不能。
  5. 試験の定石
    • 「CloudWatch Logs に送れない／アラームが動かない」→「インスタンスプロファイルの権限不足」をまず疑う。

RELATED POST