Uncategorized

81~90

 

以下に、SCS-81の問題に対する解説と学習ポイントを示します。

■ 問題文

ある企業は Amazon GuardDuty を使用して、AWS アカウントの脅威と悪意のあるアクティビティを検出しています。
同社は、Amazon S3 バケットにアップロードされたサードパーティの脅威インテリジェンスリストを取得しています。
セキュリティエンジニアは、会社のすべての AWS アカウントで脅威リストを効率的に使用するにはどうすればよいですか?

■ 選択肢

A. S3 バケットポリシーで、すべての会社の AWS アカウントが脅威リストにアクセスできるようにします。AWS Lambda 関数を使用して、脅威リストをすべての企業 AWS アカウントに自動的に追加します。
B. GuardDuty がマスターメンバー構成になっていることを確認します。脅威リストを含む S3 オブジェクトを参照するマスターアカウントに脅威リストを追加します。
C. すべてのアカウントが AWS Organizations の同じ組織の一部であることを確認します。AWS Organizations 内の企業アカウントに脅威リストを追加します。
D. S3 バケットの脅威リストが公開されていることを確認します。GuardDuty の結果で Amazon CloudWatch Events イベントを使用して、IP を脅威リストと照合します。

✅ 正解：

B. GuardDuty がマスターメンバー構成になっていることを確認します。脅威リストを含む S3 オブジェクトを参照するマスターアカウントに脅威リストを追加します。

🔍 解説：

Amazon GuardDuty はマスターメンバー構成（現：管理アカウントとメンバーアカウント構成）に対応しており、カスタム脅威インテリジェンスリストは管理アカウントからのみ追加・管理されます。
一度管理アカウントで設定すれば、すべてのメンバーアカウントにもそのリストが自動的に適用されるため、効率的に利用できます。

❌ 不正解の選択肢の理由：

  • A. 各アカウントに個別でLambdaなどを使って追加するのはスケーラビリティに欠け、GuardDutyの構成と合致しません。GuardDutyの脅威リストはメンバーアカウントからは設定できません。
  • C. Organizationsの所属だけではGuardDutyのカスタム脅威リスト共有は実現しません。GuardDutyの管理/メンバーアカウント構成が前提です。
  • D. S3の公開設定やCloudWatch EventsでのIP照合はGuardDutyの脅威検知とは無関係であり、誤った手法です。そもそもS3を公開するのはセキュリティ上好ましくありません。

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

  • GuardDutyの管理アカウントが設定するカスタム脅威インテリジェンスリストは、メンバーアカウントにも自動的に適用される。
  • S3バケットにアップロードしたCSVフォーマットのリスト（IPアドレス、ドメインなど）を指定可能。
  • 組織レベルのセキュリティサービス統合（Security Hub、GuardDutyなど）は基本的に管理アカウントで設定→メンバーに適用されるモデル。
  • CloudWatch Eventsはアラートのトリガーに用いるが、脅威リストの設定や照合そのものには使われない。

承知しました。
今後は、問題文と選択肢の箇所ではマーク（✅や❌など）を付けず、正解が分からないように表記し、
その下で「正解と解説」を提示いたします。

以下、前回の問題【SCS-82】をその形式で再構成します。

■ 問題文

ある会社には、Amazon RDSのPostgreSQLデータベースを使用するアプリケーションがあります。
この会社は、データベースに個人の機密データを格納できる機能を開発しています。
この環境のセキュリティレビューを実施する中で、RDS DBインスタンスが静止状態でデータを暗号化していないことが判明しました。
会社は、停止時でもすべての既存のデータと個人情報など新しいデータを暗号化するソリューションを求めています。

会社がこれらの要件を満たすために使用できるオプションの組み合わせはどれですか？（2つ選択）

■ 選択肢

  1. DBインスタンスのスナップショットを作成します。スナップショットを新しいスナップショットにコピーし、コピーするプロセスで暗号化を有効にします。新しいスナップショットを使用して、DBインスタンスを復元します。
  2. DBインスタンスの構成を変更し、暗号化を有効にします。DBインスタンスのスナップショットを作成します。スナップショットを使用してDBインスタンスを復元します。
  3. AWS Key Management Service (AWS KMS)を使用して、新しいデフォルトのAWSマネージドaws/rdsキーを作成します。このキーをAmazon RDSでの操作のための暗号化キーとして選択します。
  4. AWS Key Management Service (AWS KMS)を使用して、新しいCMKを作成します。この鍵をAmazon RDSで運用する際の暗号化キーとして選択します。
  5. DBインスタンスのスナップショットを作成します。スナップショットで暗号化を有効にします。スナップショットを使用して、DBインスタンスを復元します。

✅ 正解と解説

正解：1 と 4

■ 解説：

  • 選択肢1：スナップショットを暗号化付きでコピーして復元
    → RDSは既存インスタンスの暗号化を後付けできないため、この手法が標準的な対応です。
  • 選択肢4：KMSのカスタマーマネージドキー（CMK）を使用する
    → 暗号化されたスナップショット作成やDB復元時に、CMKを指定することで鍵管理やアクセス制御を細かく制御できます。

❌ 不正解の選択肢の理由

  • 選択肢2：構成変更で暗号化を有効にする
    → RDSでは既存インスタンスに対し暗号化を直接オンにすることはできません。誤り。
  • 選択肢3：aws/rdsのマネージドキー作成
    → aws/rdsキーはAWSが自動作成するもので、ユーザーが新規作成できません。CMKの利用が推奨されます。
  • 選択肢5：スナップショットで暗号化を有効にする
    → 「スナップショットの作成」時点では暗号化指定はできません。スナップショットの「コピー」時に暗号化を指定します。

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

  • RDSの暗号化はインスタンス作成時のみ設定可能。既存の非暗号化インスタンスに対しては、スナップショット→コピー（暗号化）→復元が必要。
  • 暗号化のためのKMSキーは**CMK（カスタマーマネージドキー）**が柔軟性と制御性に優れる。
  • AWSマネージドキー（aws/rdsなど）は自動作成されるため、直接指定やカスタマイズには不向き。
  • 暗号化を扱う設問では「どのタイミングで暗号化を設定できるか」に注目すること。

今後もこの形式で続けますので、次の問題があれば送ってください。

以下に【SCS-83】の問題に対する詳細な解説を示します。

■ 問題文

ある会社は、Application Load Balancer (ALB) を使用して動的 Web サイトを運営しています。
セキュリティエンジニアは、さまざまな IP アドレスからのボットがブルートフォース攻撃を使用してサービスエンドポイントを頻繁に呼び出していることに気付きました。

この問題を軽減する最も適切な方法は何ですか？

■ 選択肢

  1. ALB ログを処理する AWS Lambda 関数を作成します。 ALB のセキュリティグループでボットの IP アドレスをブロックします。
  2. ALB の AWS WAF ウェブ ACL を作成するレートベースのルールをウェブ ACL に追加して、ボットをブロックします。
  3. ALB リスナールールを作成します。ボットを照合する条件として、source-ip と path-pattern を組み合わせます。HTTP 403 ステータスを返す固定応答アクションを指定します。
  4. ALB の AWS WAF ウェブ ACL を作成します。Bot Controlルールグループを追加して、ボットをブロックします。ルールをウェブ ACL にアタッチします。

✅ 正解と解説

正解：4

■ 解説：

AWS WAF の Bot Control ルールグループは、既知のボットや悪意あるリクエストを自動的に識別・制御できるマネージドルールです。
ブルートフォース攻撃のようなボットによるアクセス制限に対して、最も自動化かつ包括的な対策が可能です。

Bot Control では、次のようなカテゴリに基づいてボットを分類・制御できます：

  • 一般的なスクレイピングボット
  • クローラー
  • 自動化ツール
  • 不審なリクエスト元

Web ACL にアタッチすれば、ALBに流れるリクエストに対しリアルタイムに適用可能です。

❌ 不正解の選択肢の理由：

  • 1.
    セキュリティグループはIPレベルのアクセス制御のみで、ALBには適用されません（ALBはセキュリティグループを使用するが、リクエスト内容で制御は不可）。
    さらにLambda関数でログを解析して手動ブロックするのはリアルタイム性とスケーラビリティに欠ける対応です。
  • 2.
    レートベースルールは同一IPアドレスからの過剰なリクエストに対して効果がありますが、IPを分散するボットには不十分です。Bot Controlはこれを補完する高度な手法です。
  • 3.
    ALBリスナールールではsource-ipのような条件で細かなアクセス制御はできません。WAFのようなレイヤー7の高度な制御は提供されません。

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

  • AWS WAFのBot Controlルールグループは、ボット対策における推奨ソリューション。既知のボットや疑わしいパターンをリアルタイムにブロック。
  • セキュリティグループではリクエストパターンに基づく制御はできない。ALBレイヤーのアプリケーション攻撃に対してはWAFを使う。
  • レートベースルールは単一IPの大量リクエスト対策に有効。分散型の攻撃（IPを変えるボットなど）には効果が薄い。
  • ブルートフォース対策には、WAF + Bot Control + レート制限の組み合わせが現実的。

次の問題もどうぞお送りください。分析・整理しながら対策していきましょう。

以下に【SCS-84】の問題に対する解説を示します（選択肢の部分は正解が分からない形式で記載しています）。

■ 問題文

ある会社は、インターネットに接続されないプライベートVPCにアプリケーションを配備したいと考えています。
この会社のセキュリティチームは、bastionホストやSSHでのEC2ログインを禁止しています。
一方でアプリケーションチームは、AWS Systems Manager Session Managerを使用してEC2に接続・管理する予定です。

セキュリティチームが取るべき手順の組み合わせはどれですか？（3つ選択）

■ 選択肢

  1. VPC内のすべてのEC2インスタンスにSystems Manager Agentがインストールされ、実行されていることを確認する。
  2. VPC内のEC2インスタンスに付属するIAMロールがSystems Managerへのアクセスを許可していることを確認する。
  3. SSHキーペアの作成を防止するSCPを作成する。
  4. VPCでNATゲートウェイを起動する。このNATゲートウェイにトラフィックを転送するようにルーティングポリシーを更新する。
  5. Systems ManagerとAmazon EC2に対して、適切なVPCエンドポイントが設置されていることを確認する。
  6. VPCにトランジットゲートウェイアタッチメントがあることを確認します。このトランジットゲートウェイにトラフィックを転送するようにルーティングポリシーを更新します。

✅ 正解と解説

正解：1、2、5

■ 解説：

プライベートVPC環境において、インターネットを介さずにSession Manager経由でEC2インスタンスにアクセスするためには、以下の構成が必須です。

選択肢1：Systems Manager Agentが稼働していること

→ Session ManagerはSSM Agentを通じてEC2に接続するため、Agentがインストールかつ起動状態である必要があります。

選択肢2：IAMロールがSSMアクセスを許可していること

→ EC2に付与されたIAMロールに、少なくとも以下のようなポリシー（例：AmazonSSMManagedInstanceCore）が必要です。これによりEC2がSSMと通信できます。

選択肢5：VPCエンドポイントの作成

→ VPCがインターネットに接続していない場合、**SSM用のインターフェース型VPCエンドポイント（ssm, ec2messages, ssmmessages）**が必要です。これがないとエージェントはAWS Systems Managerに到達できません。

❌ 不正解の選択肢の理由

  • 選択肢3：SCPでSSHキーペア作成をブロック
    → キーペアの作成を制限することはセキュリティ強化にはなりますが、Session Managerの利用に必須ではありません。また、インスタンスにログインする手段は鍵だけではないため、部分的な対応にすぎません。
  • 選択肢4：NATゲートウェイの設置
    → NAT Gatewayはインターネットアクセスを提供する手段であり、「インターネットに接続しないVPC」という要件に反します。
  • 選択肢6：トランジットゲートウェイの使用
    → トランジットゲートウェイは複数VPC間やオンプレとの接続用途であり、Systems Managerの通信とは無関係です。

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

  • Session ManagerはEC2への安全なアクセス手段として、SSH禁止環境でよく利用される。
  • 必要な構成：
    • Systems Manager Agent（SSM Agent）のインストールと稼働
    • IAMロールによる適切なポリシー付与（例：AmazonSSMManagedInstanceCore）
    • インターネット非接続環境では VPCエンドポイント（Interface型） の設置が必須
  • セキュリティ強化のためにポート22の開放を避け、CloudTrailなどで操作ログを記録するのもベストプラクティス。

次の問題があれば、引き続きお送りください。SCS合格に向けてしっかりサポートします。

以下に【SCS-85】の問題に対する詳細な解説を示します。

■ 問題文

セキュリティエンジニアは、VPC内で通信するコンテナ間で相互認証されたTLS接続を実装する必要があります。
どのソリューションが最も安全で保守が容易ですか？

■ 選択肢

  1. AWS Certificate Managerで公開認証局から証明書を生成し、全コンテナに配備する。
  2. 1つのコンテナで自己署名証明書を作成し、AWS Secrets Managerを使用して証明書を他のコンテナに配布し、信頼を確立する。
  3. AWS Certificate Manager Private Certificate Authority (ACM PCA) を使って下位の認証局を作成し、コンテナで秘密鍵を作成し、ACM PCA APIを使って署名する。
  4. AWS Certificate Manager Private Certificate Authority (ACM PCA)を使って下位の認証局を作成し、AWS Certificate Managerを使ってプライベート証明書を生成し、すべてのコンテナに配備する。

✅ 正解と解説

正解：3

■ 解説：

TLSの**双方向認証（mTLS）**では、クライアントとサーバの双方が証明書を提示し、相互に信頼できるCAによって署名されていることを確認する必要があります。

選択肢3の構成は以下の理由で最も安全かつ保守が容易です：

  • ACM Private CAを使用して信頼されたプライベート認証局を構築できる。
  • 各コンテナが自分自身で秘密鍵を生成し、ACM PCAのAPIで証明書署名要求（CSR）を提出して証明書を取得できる。
  • これにより秘密鍵の漏洩リスクを減らし、ゼロトラスト設計に適合する。
  • APIベースで証明書ライフサイクル（更新・再発行）の自動化が可能。

❌ 不正解の選択肢の理由

  • 選択肢1：ACMパブリック証明書を使う
    → パブリック証明書はインターネット公開用のFQDNに対してのみ発行され、VPC内プライベート通信では使えない。また、全コンテナに配布するのは管理負担が大きい。
  • 選択肢2：自己署名＋Secrets Manager配布
    → 自己署名は信頼性が低く、Secrets Managerで証明書を配布する方式は秘密鍵の集中管理になり、セキュリティリスクが高い。
  • 選択肢4：ACMを使って証明書生成→全コンテナ配布
    → ACMの証明書発行は基本的に**マネージドサービス向け（ELB、CloudFrontなど）**であり、証明書のエクスポートができない。手動配布もスケーラビリティに欠ける。

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

  • mTLS（相互TLS）は、双方の証明書確認が必要なセキュアな通信方式。
  • ACM PCAはプライベートCAの構築と証明書の自動発行に最適。
  • ACMでは証明書の秘密鍵をエクスポートできないため、コンテナやEC2などのマネージド外サービスで利用するにはAPI署名方式が必要。
  • コンテナごとに秘密鍵を生成し、CSRをACM PCAへ送信→署名済み証明書を取得というフローがセキュア。

次の問題もあれば、引き続きお送りください。SCSに合格するために重要なポイントを丁寧に整理していきましょう。

了解しました。
今後は 問題文と選択肢を一切編集せず、文字列のままそのまま出力いたします（HTMLタグは除去）。
以下に、【SCS-86】の内容を指示通りの形式で再掲します。

■ 問題文

【SCS-86】ある企業は、企業の各チームに AWS アカウントを提供しています。
各チームのメンバーは、自分のチームのアカウントのユーザーアカウントを使用して AWS で認証を行います。
同社は、3 つ以上のチームによる共同作業のために、プロジェクト固有の AWS アカウントを作成しました。
また、この新しいアカウント内に新しい Amazon S3 バケットも作成しました。
S3 バケットポリシーまたは S3 ACL はありません。
セキュリティエンジニアは、すべてのチームが S3 バケットに保存されているオブジェクトを読み書きできるように、安全なソリューションを実装する必要があります。
セキュリティエンジニアはこれらの要件を満たすために何をすべきですか?

■ 選択肢

  1. S3 バケットが存在する同じ AWS アカウントで、バケットの ACL を更新して、チームの AWS アカウントの正規ユーザー ID を含めます。チームは、オブジェクトを読み取り、バケット内のオブジェクトに書き込むときに、バケットが配置されている AWS アカウントのアカウント番号を指定します。
  2. S3 バケットが存在する同じ AWS アカウントで、バケットに対する適切なアクセス許可を持つ IAM ロールを作成します。チームの AWS アカウントをプリンシパルとして指定する信頼ポリシーを含めます。チームは、オブジェクトを読み取り、バケット内のオブジェクトに書き込むときに、このロールを使用します。
  3. S3 バケットが存在する同じ AWS アカウントで、バケットポリシーを追加して、すべてのチームがオブジェクトの読み取りとバケット内のオブジェクトへの書き込みを許可します。チームは、オブジェクトを読み取り、バケット内のオブジェクトに書き込むときに、バケットが配置されている AWS アカウントのアカウント番号を指定します。
  4. S3 バケットが存在する同じ AWS アカウントで、IAM ユーザー、IAM グループ、および各チームのアクセスキーを作成します。各チームは、バケット内のオブジェクトの読み取りと書き込みを行うときに、アクセスキーを共有します。

✅ 正解：2

🔍 解説：

このシナリオでは、複数のAWSアカウント（各チーム）からプロジェクト用S3バケットへの安全なクロスアカウントアクセスを実現する必要があります。
選択肢2は、次のような構成で実現されます：

  • プロジェクトアカウントにIAMロールを作成し、S3へのアクセス権限を付与する
  • 信頼ポリシーで各チームのアカウントIDをプリンシパルとして許可
  • 各チームは自身のアカウントからそのIAMロールをAssumeRoleしてS3へアクセスする

この方式は、**セキュア・管理性良好・監査容易（CloudTrailで記録）**と三拍子揃ったベストプラクティスです。

❌ 不正解の選択肢の理由：

  • 選択肢1：ACL利用
    　→ ACLは非推奨の旧式手法で、運用管理が煩雑。正規ユーザーIDの扱いも難しく、セキュリティ制御が弱い。
  • 選択肢3：バケットポリシーの直接許可
    　→ 一見有効に見えるが、オブジェクトの所有権問題（バケット所有者と書き込み側が異なる）が発生しやすく、bucket-owner-full-controlの明示や設定管理が複雑。
  • 選択肢4：アクセスキー共有
    　→ 最悪の選択肢。アクセスキーの共有はセキュリティ違反であり、誰が操作したか追跡できず、鍵漏洩リスクも極めて高い。

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

  • クロスアカウントアクセスには「IAMロール＋AssumeRole＋信頼ポリシー」が王道
  • S3のACLは非推奨。バケットポリシーよりもIAMベースのアクセス制御の方が柔軟で安全
  • アクセスキーの共有は禁止事項。クレデンシャルはユーザーごと・役割ごとに発行すべき
  • ロールを使うことでCloudTrailにより誰が何をしたかを追跡できるため監査にも強い

次の問題もそのまま貼り付けてください。同様の形式で対応いたします。

以下に【SCS-87】の問題に対する解説を、問題文と選択肢の文字列を一切編集せず、指示通りの形式でご提示します。

■ 問題文

【SCS-87】ある会社は、キーマテリアルをインポートしたカスタマーマスターキー（CMK）があります。
会社の方針として、すべての暗号鍵を1年ごとにローテーションすることが求められています。
上記の方針を実現するために、どのようなことができますか。

■ 選択肢

  1. CMKの自動キーローテーションを毎年有効にする。
  2. AWSコマンドラインインターフェイスを使用して、既存のCMKを毎年ローテーションするためのAWS Lambda関数を作成する。
  3. 既存のCMKに新しいキーマテリアルをインポートし、CMKを手動でローテーションさせる。
  4. 新しいCMKを作成し、そこに新しいキーマテリアルをインポートし、キーエイリアスを新しいCMKに向ける。

✅ 正解：4

🔍 解説：

インポートされたキーマテリアルを持つCMK（Customer Managed Key）は、自動キーローテーションがサポートされていません。
そのため、毎年のローテーションを実現するには、以下のように手動のローテーションプロセスを行う必要があります：

  • 新しいキーマテリアルを使って新しいCMKを作成する
  • 現在のCMKに関連付けられたエイリアスを新しいCMKに切り替える
  • これにより、アプリケーションやサービスは同じエイリアス名を使用し続けることで、新しいキーを透過的に使用できるようになります

これはAWSのKMS設計に基づく唯一の正しい方法です。

❌ 不正解の選択肢の理由：

  • 1. CMKの自動キーローテーションを毎年有効にする。
    　→ 自動キーローテーションはインポートされたキーマテリアルでは使用できません。AWS管理のキーマテリアルか、AWSが生成したキーのみが対象です。
  • 2. CLIとLambdaを使ってCMKを毎年ローテーションする。
    　→ Lambda関数で既存CMKのキーマテリアルを置き換えるAPIは存在せず、既存CMKに対してキーマテリアルの再インポートはサポートされていません。
  • 3. 既存のCMKに新しいキーマテリアルをインポートし、CMKを手動でローテーションさせる。
    　→ KMSでは一度インポートされたCMKのキーマテリアルは上書きできません。CMKごとに新たに作成する必要があります。

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

  • インポートされたキーマテリアルのCMKは、自動ローテーション不可
  • ローテーションには「新しいCMKを作成してエイリアスを更新」という手順が必要
  • エイリアスを使うことでアプリケーションコードを変更せずにキーの切り替えが可能
  • KMSのCMKは「削除不可」であり、古いキーも復号用途で残す必要がある場合がある

引き続き、他の問題もお送りください。同じ形式で対応いたします。

以下に【SCS-88】の問題に対する解説を、問題文と選択肢を一切編集せず、指示通りの形式でご提示します。

■ 問題文

【SCS-88】あるセキュリティエンジニアは、攻撃者が悪用していると報告されているEC2インスタンスIDをリスト化したAWS Abuse Noticeを受け取りました。
この状況に基づいて、エンジニアはどのアクションを取るべきですか？(3つ選択)

■ 選択肢

  1. AWS Artifactを使用して、各インスタンスの状態の正確なイメージを取得する。
  2. 漏洩したインスタンスに接続されている各ボリュームのEBSスナップショットを作成します。
  3. メモリダンプをキャプチャします。
  4. 管理者資格で各インスタンスにログインし、インスタンスを再起動します。
  5. フォレンジック・ワークステーションとの出入りを除く、すべてのネットワーク出入りを禁止する。
  6. Amazon EC2のAuto Recoveryを実行します。

✅ 正解：2、3、5

🔍 解説：

AWS Abuse Noticeを受け取ったということは、インスタンスが**侵害されている（またはその可能性がある）**ことを意味します。
このような場合、インシデントレスポンスとフォレンジック対応が求められ、下記のような行動が適切です：

2. EBSスナップショットを作成

→ ボリュームの**変更されない証拠（イメージ）**を取得することで、後の解析に利用できます。証拠保全の基本。

3. メモリダンプをキャプチャ

→ インスタンスが動作しているうちに、プロセス・ネットワーク接続・暗号鍵などの揮発性データを収集することが可能です。これもフォレンジックの基本。

5. フォレンジック・ワークステーションとの出入りを除く、すべてのネットワーク出入りを禁止

→ 被害の拡大を防ぎつつ、外部との通信を遮断して証拠を保護します。NACLやセキュリティグループで制限可能です。

❌ 不正解の選択肢の理由：

  • 1. AWS Artifactを使用して、各インスタンスの状態の正確なイメージを取得する。
    　→ AWS Artifactはコンプライアンス文書提供サービスであり、インスタンスの状態取得には使いません。
  • 4. 管理者資格で各インスタンスにログインし、インスタンスを再起動します。
    　→ 再起動は証拠の破壊・揮発性情報の喪失を引き起こすため、インシデント対応中には避けるべき行為です。
  • 6. Amazon EC2のAuto Recoveryを実行します。
    　→ Auto Recoveryは障害からの復旧処理であり、セキュリティインシデント対応としては不適切。むしろ状態の変化を加えるのはNG。

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

  • インシデント発生時は「隔離→証拠保全→調査」の順に行動する
  • スナップショット取得・メモリダンプ・ネットワーク隔離は基本対応
  • インスタンスの再起動や復旧操作は証拠を失わせるため、事前にフォレンジック作業が完了していることが前提
  • AWS Artifactは監査用の資料提供サービスであり、技術的トラブルシュートには使用しない

次の問題もそのまま貼り付けてください。同じフォーマットで対応いたします。

以下に【SCS-89】の問題に対する解説を、問題文と選択肢を一切編集せず、ご提示します。

■ 問題文

【SCS-89】ある企業のAmazon CloudWatch Logs エージェントは、CloudWatch Logsサービスへ正常にログを配信しています。
しかし、関連するログストリームが特定の時間アクティブになった後、ログは配信されなくなります。
この現象の原因を特定するには、どのような手順が必要ですか？(2つ選択)

■ 選択肢

  1. CloudWatch Logsエージェントがファイルを読み取ることを許可する監視ファイルのファイルパーミッションが変更されていないことを確認します。
  2. OS Logのローテーションルールが、エージェントストリーミングの構成要件に適合していることを確認します。
  3. Amazon Kinesisプロデューサーを構成して、まずログをAmazon Kinesis Streamsに入れるようにします。
  4. CloudWatch Logsのメトリックを作成し、ロギングが停止するまでの期間に少なくとも1回は変化する値を切り分けます。
  5. AWS CloudFormationを使用して、CloudWatch Logsエージェントの設定ファイルを動的に作成し、維持します。

✅ 正解：1、2

🔍 解説：

CloudWatch Logsエージェントが突然ログを送信しなくなった場合、最もよくある原因は以下の通りです：

1. ファイルパーミッションの問題

→ ログファイルのパーミッションが変更され、CloudWatch Logsエージェント（特にcwagentやssm-userなどの実行ユーザー）がファイルを読み取れなくなると、ログはCloudWatchに送信されなくなります。

2. ログローテーションの非互換

→ 多くのOSではlogrotateなどの仕組みでログファイルが定期的にローテートされます。
新しいログファイルが生成されても、CloudWatchエージェントが新しいファイルに追従する設定（file_fingerprint_linesやmulti_line_start_patternなど）が正しくないと、ログ送信が止まっているように見えることがあります。

❌ 不正解の選択肢の理由：

  • 3. Amazon Kinesisプロデューサーを構成して…
    　→ 問題の範囲はCloudWatch Logsへのエージェント送信であり、Kinesisは無関係です。CloudWatch Logsとは直接関係がありません。
  • 4. CloudWatch Logsのメトリックを作成し…
    　→ メトリクスの変化でログの停止を「検出する」ことは可能ですが、「原因の特定」にはつながりません。
  • 5. CloudFormationで設定ファイルを管理する
    　→ 設定ファイルの動的作成・管理は構成の自動化手段であり、問題の原因特定とは無関係です。

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

  • CloudWatch Logs エージェントのトラブルシュートでは、読み取り対象ログファイルのパーミッション・存在・ローテーションを確認する
  • ログローテーションが発生した場合に備え、**正しい設定（例：ファイルパターンや追跡方法）**が必要
  • CloudWatch Logsでログが途切れた場合は、ローカルログファイル・エージェントログ・パーミッション・タイムスタンプの順に確認

次の問題も続けてお送りください。すべて同じフォーマットで対応します。

以下に【SCS-90】の問題に対する解説を、問題文と選択肢を一切編集せず、ご提示します。

■ 問題文

【SCS-90】あるセキュリティエンジニアは、Amazon S3バケットに機密の在庫データを格納するサプライチェーンアプリケーションを設計するために、開発チームと協力して作業しています。
このアプリケーションは、Amazon S3上のデータを暗号化するためにAWS KMSカスタマーマスターキー（CMK）を使用する予定です。
Amazon S3上の在庫データはベンダーと共有されます。
すべてのベンダーは、各自のAWSアカウントからAWSプリンシパルを使用して、Amazon S3上のデータにアクセスします。
対象ベンダーは毎週変更される可能性があり、このソリューションはクロスアカウントアクセスをサポートする必要があります。
KMS CMKのアクセス制御を管理するための最も効率的な方法はどれでしょうか?

■ 選択肢

  1. キーアクセスを管理するためにKMSグラントを使用する。ベンダーアクセスを管理するために、プログラムによるグラントの作成と失効を行います。
  2. IAMロールを使用して鍵のアクセスを管理する。IAMロールポリシーをプログラム的に更新し、ベンダーアクセスを管理します。
  3. KMSキーポリシーを使用して、キーアクセスを管理する。ベンダーアクセスを管理するために、KMSキーポリシーをプログラム的に更新します。
  4. キーアクセスを管理するためにIAMロールを使用して、AWSアカウント間で委任されたアクセスを使用します。IAM信頼ポリシーをプログラム的に更新し、アカウント間のベンダーアクセスを管理します。

✅ 正解：1

🔍 解説：

このシナリオでは「KMSを使用して暗号化されたS3データに対するクロスアカウントアクセス」を、「頻繁に変化するベンダーに対して効率よく制御する方法」が問われています。

1. KMSグラントの使用（正解）

KMSでは、他アカウントのプリンシパル（例：ベンダー）に対して一時的かつ限定的なアクセス権限を付与するには「グラント」が最適です。

  • グラントはKMS API経由でプログラム的に付与・取り消しできる
  • キーポリシーやIAMポリシーを更新するより軽量で安全
  • 毎週ベンダーが変わるような動的な状況にも向いている

❌ 不正解の選択肢の理由：

2. IAMロールで鍵のアクセス管理

→ KMSキーへのアクセスはロールだけでは完結しない。KMSのキーポリシーやグラントの許可が必要。さらにクロスアカウントを直接ロールで管理するのは煩雑かつリスクが高い。

3. キーポリシーを直接更新

→ キーポリシーの更新は管理が重く・エラーを起こしやすい。頻繁な変更を自動化するには適していない。ポリシー文字列の制限や複雑な記述の問題もある。

4. IAMロールと信頼ポリシーで委任

→ これはリソースの操作権限を委任する方法であり、KMSキー自体へのアクセス制御には適していない。信頼ポリシーの変更は非推奨で煩雑かつスケーラビリティに乏しい。

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

  • KMSのクロスアカウントアクセス制御には「グラント」を使うことで、きめ細かく・一時的な許可を安全に付与できる
  • KMSグラントは「APIベースで発行・失効できる」ため、自動化や動的なアクセス管理に最適
  • IAMポリシーやキーポリシーの変更は静的・手動更新が必要で非効率
  • グラントは「S3やEBSなどサービスが自動的に作成する」ケースもあり、仕組みを理解しておくことが重要

次の問題もお待ちしております。引き続き、同形式で丁寧に対応します。

RELATED POST