Uncategorized

#59

 

以下の形式で問題1を整理し、正解とその理由を解説します。

■ 問題文

企業は Amazon ECS を使用して、機密データを処理するアプリケーションをデプロイしています。この企業は、最近のセキュリティ評価において、Amazon RDS の認証情報が、企業のソースコードリポジトリ内のアプリケーションコードと一緒に置かれているというセキュリティリスクを発見しました。

セキュリティエンジニアは、データベースの認証情報を安全に保管し、ローテーションする方法を考案する必要があります。アプリケーションだけが認証情報にアクセスできるようにする必要があります。さらに、データベース管理者が暗号化されていないデータベース認証情報を他のチームと共有できないように制限する必要があります。さらに、このソリューションは管理コストを削減しなければなりません。

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

■ 選択肢

A.
AWS Systems Manager Parameter Store を使用して、データベース認証情報を生成します。ECS タスクに IAM プロファイルを使用して、データベース認証情報へのアクセスを特定のコンテナのみに制限します。

B.
AWS Secrets Manager を使用して、データベースの認証情報を保存します。ECS タスクに IAM インラインポリシーを使用して、データベース認証情報へのアクセスを特定のコンテナのみに制限します。

C.
AWS Secrets Manager を使用して、データベース認証情報を保存します。ECS タスクに IAM ロールを使用して、データベース認証情報へのアクセスを特定のコンテナのみに制限します。

D.
AWS Systems Manager Parameter Store を使用して、データベース認証情報を保存します。ECS タスクに IAM ロールを使用して、データベース認証情報へのアクセスを特定のコンテナのみに制限します。

■ 正解の選択肢と解説

正解：C

C. Secrets Manager + IAM ロール

→ 正解

  • Secrets Manager はデータベース認証情報の安全な保存・ローテーションをネイティブにサポートしており、管理コストの削減にも有効。
  • ECS タスクに IAM ロールを割り当てれば、特定のコンテナのみにアクセスを制限可能。
  • 管理者による平文共有のリスクも、アクセスコントロールによって防止可能。

■ 不正解の選択肢の理由

A. Systems Manager + IAM プロファイル

→ 誤り

  • Parameter Store はローテーション機能が弱い／非自動であり、Secrets Managerに比べてセキュリティ面や管理面で劣る。
  • 「IAMプロファイル」という表現もEC2用であり、ECSでは タスク IAMロール を使用すべき。

B. Secrets Manager + IAM インラインポリシー

→ 誤り

  • ECSタスクに適切なのはタスク IAMロール。インラインポリシーはIAMユーザーやロールに添付するもので、誤解を招く表現。

D. Parameter Store + IAM ロール

→ 誤り

  • IAM ロールの使用は適切だが、Parameter Store は Secrets Managerのような認証情報のローテーション機能が不足しており、要件未達。

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

  • Secrets Manager は RDS 認証情報の保存・暗号化・ローテーションに最適。
  • ECS タスクの AWS API へのアクセス制御は IAM ロール（タスクロール） を使う。
  • Secrets Manager はアクセス権を IAM ポリシーで制御でき、最小権限原則を満たす。
  • 認証情報はコードやリポジトリにハードコーディングしないのがベストプラクティス。

他の問題もあれば、引き続き分析・解説いたします。

以下は、問題2の整理および解説です。

■ 問題文（編集せずにそのまま）

コンプライアンス上の理由から、セキュリティエンジニアは、承認された最新のパッチが適用されていないインスタンスをリストした週次レポートを作成する必要があります。また、最新のパッチが適用されていないシステムが 30 日以上存在しないことも確認しなければなりません。承認された更新が適用されています。

これらの目標を達成するための最も効率的な方法を選択してください。

■ 選択肢（編集せずにそのまま）

A.
AMI を最新の承認済みパッチで更新し、定義されたメンテナンスウィンドウ中に各インスタンスを再デプロイします。

B.
Amazon Inspector を使用して、最新のパッチが適用されていないシステムを特定し、30 日後にそれらのインスタンスを最新の AMI バージョンで再デプロイします。

C.
インスタンスのパッチコンプライアンスについてレポートするように Amazon EC2 Systems Manager を設定し、定義されたメンテナンスウィンドウ中に更新を適用します。

D.
AWS CloudTrail のログを調査し、過去 30 日間に再起動しなかったインスタンスがあるかどうかを判断し、それらのインスタンスを再デプロイします。

■ 正解の選択肢と解説

正解：C

インスタンスのパッチコンプライアンスについてレポートするように Amazon EC2 Systems Manager を設定し、定義されたメンテナンスウィンドウ中に更新を適用します。

  • Systems Manager Patch Manager は、パッチ適用・スキャン・コンプライアンスレポート作成を自動化できる機能。
  • 「定義されたメンテナンスウィンドウ」を使うことで、業務時間外などのスケジュールで適用可能。
  • 30日間以上パッチが適用されていないシステムも可視化できるため、コンプライアンスチェックに最適。

■ 不正解の選択肢の理由

A. AMI を最新パッチで更新し再デプロイ
→ レポートやスキャン機能がなく、コンプライアンス状態の可視化が不十分。

B. Amazon Inspector で検出・30日後に再デプロイ
→ Inspector は脆弱性スキャンツールであり、パッチ適用状況の可視化やスケジュール更新には不向き。

D. CloudTrail ログを調査し再起動判定
→ CloudTrail はアクティビティログであり、パッチの有無は判断できない。

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

  • AWS Systems Manager Patch Manager を使えば、パッチ適用の自動化・可視化・スケジュール適用が可能。
  • パッチコンプライアンスレポートが必要なときは、Patch Manager一択。
  • Amazon Inspector は脆弱性検出ツールで、パッチ状態そのもののコンプライアンスチェックには適していない。
  • CloudTrail や AMI 更新は補助的で、今回のような定期レポートと更新の組み合わせ要件には不十分。

他の問題の解説も必要であれば、どうぞお知らせください。

以下は、問題3の整理と詳細解説です。

■ 問題文（編集せずにそのまま）

ある会社は、11 日前にアクセスキーの 1 つがコード共有のウェブサイトに公開されていることに気づきました。セキュリティエンジニアは、公開されたキーのすべての使用を確認して、公開の範囲を判断する必要があります。同社は、アカウント開設時にすべてのリージョンで AWS CloudTrail を有効にしました。

タスクを完了することを可能にする最適な方法を選択してください。

■ 選択肢（編集せずにそのまま）

A.
CloudTrail コンソールで公開されたアクセスキーでイベント履歴をフィルタリングします。過去 11 日間のデータを調べます。

B.
IAM コンソールの [ アクセスアドバイザー ] タブを使用して、過去 11 日間のすべてのアクセスキーのアクティビティを表示します。

C.
Amazon Athena を使用して、Amazon S3 から CloudTrail ログをクエリします。過去 11 日間に公開されたアクセスキーの行を取得します。

D.
AWS CLI を使用して、IAM 認証情報レポートを生成します。過去 11 日間のすべてのデータを抽出します。

■ 正解の選択肢と解説

正解：A

CloudTrail コンソールで公開されたアクセスキーでイベント履歴をフィルタリングします。過去 11 日間のデータを調べます。

  • CloudTrail は AWS アカウント内のアクティビティを記録し、直近90日分のイベント履歴をコンソールで確認可能。
  • 公開されたアクセスキーの AccessKeyId を指定して、該当キーが使用された全イベントを確認できる。
  • 今回はキーが公開されてから11日しか経っていないため、AthenaやS3を使うほどではない。

■ 不正解の選択肢の理由

B. IAM アクセスアドバイザー
→ IAM エンティティがどのサービスを使用したか（最終アクセス日）を見る機能。個別イベントや詳細操作ログは見られない。

C. Amazon Athena + S3
→ CloudTrail が S3に保存されていればAthenaで分析可能だが、コンソールから直接検索できる場合は不要な工数。

D. IAM 認証情報レポート
→ パスワード設定、MFA状態、アクセスキーの有効・無効などの静的な情報一覧を出すもので、過去の使用履歴は見られない。

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

  • CloudTrail イベント履歴は90日保持。短期間の調査であれば、コンソールでの直接確認がベスト。
  • アクセスキー流出時は、そのキーの AccessKeyId でフィルタし、**「何に使われたか」**を特定する。
  • IAM アクセスアドバイザーや認証情報レポートは、イベントログの分析には使えない。
  • Athena クエリは、CloudTrail ログがS3に配信されており、かつ長期調査や高度な分析が必要な場合に有効。

他の設問の解説も必要であれば、引き続きご提供できますので、お知らせください。

以下は、問題4 の整理と詳細解説です。

■ 問題文（そのまま）

規制要件を満たすために、セキュリティエンジニアは、AWS サービスの使用を us-east-1 リージョンに制限する IAM ポリシーを実装する必要があります。

エンジニアはどのようなポリシーを実装する必要がありますか？

■ 選択肢（そのまま）

A

{
 "Version": "2012-10-17",
 "Statement": [{
   "Effect": "deny",
   "NotAction": "*",
   "Resource": "*",
   "Condition": {
     "StringEquals": {
       "aws:RequestRegion": "us-east-1"
     }
   }
 }]
}

B

{
 "Version": "2012-10-17",
 "Statement": [{
   "Effect": "Allow",
   "Action": "*",
   "Resource": "*",
   "Condition": {
     "StringEquals": {
       "aws:RequestRegion": "us-east-1"
     }
   }
 }]
}

C（正解）

{
 "Version": "2012-10-17",
 "Statement": [{
   "Effect": "Deny",
   "Action": "*",
   "Resource": "*",
   "Condition": {
     "StringNotEquals": {
       "aws:RequestRegion": "us-east-1"
     }
   }
 }]
}

D

{
 "Version": "2012-10-17",
 "Statement": [{
   "Effect": "Allow",
   "Action": "*", "Resource": "*",
   "Condition": {
     "StringEquals": {
       "ec2:region": "us-east-1"
     }
   }
 }]
}

■ 正解の選択肢と解説

正解：C

この IAM ポリシーは、us-east-1 以外のリージョンでのすべてのアクションを明示的に拒否するものです：

  • StringNotEquals: us-east-1 以外のリクエストが対象
  • Effect: Deny: 明示的に拒否（最優先される）
{
 "Effect": "Deny",
 "Action": "*",
 "Resource": "*",
 "Condition": {
   "StringNotEquals": {
     "aws:RequestRegion": "us-east-1"
   }
 }
}

リージョン制限を厳格に行うには、明示的なDenyがベストプラクティスです。

■ 不正解の選択肢の理由

A

  • Effect: "deny" と NotAction: "*" の組み合わせは矛盾しており、意味が通らない。
  • 通常、Denyには Action: "*" を使い、除外条件には Condition を使うべき。

B

  • us-east-1 のみを許可する Allow ポリシーだが、他のポリシーで us-east-1 以外を許可してしまうリスクが残る。
  • 明示的に他のリージョンを拒否していない。

D

  • ec2:region という条件キーは存在しない（正しくは aws:RequestRegion）。
  • IAMポリシーで存在しない条件キーを指定すると、無効扱いになり効果がない。

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

  • リージョン制限は aws:RequestRegion 条件キーを使う。
  • 明示的な Deny は、すべての Allow に優先される。
  • 許可ポリシーだけで制限を構成しようとせず、Denyによる明示的ブロックで安全性を担保する。
  • IAMポリシーで利用可能な条件キーは 公式ドキュメント に準拠。

必要であれば、似たパターンのポリシー例も提供できますので、お申し付けください。

以下の形式で出力します：

■ 問題文（文字列を編集せずに出力）

AWS Lambda 関数がデータを変更するために悪用されました。セキュリティエンジニアは、誰が関数を呼び出したか、どのような出力が生成されたかを特定する必要があります。エンジニアは、Amazon CloudWatch Logs で Lambda 関数によって作成されたログを見つけることができません。

ログが取得できない理由を説明しているものを選択してください。

■ 選択肢（文字列を編集せずに出力）

A. Lambda 関数の実行ロールは、CloudWatch Logs がログを保存する Amazon S3 バケットに書き込むためのアクセス許可を付与していません。
B. 実行された Lambda 関数のバージョンが最新ではありません。
C. Lambda 関数の実行ロールは、CloudWatch Logs にログデータを書き込むためのアクセス許可を付与していません。
D. Lambda 関数は、Amazon API Gateway を使用して実行されたため、ログは CloudWatch Logs に保存されません。

■ 正解の選択肢と解説

正解：C. Lambda 関数の実行ロールは、CloudWatch Logs にログデータを書き込むためのアクセス許可を付与していません。

Lambda がログを CloudWatch Logs に書き込むには、実行ロールに logs:CreateLogGroup, logs:CreateLogStream, logs:PutLogEvents 権限が必要です。これらの権限がなければ、関数自体は正常に実行されてもログは出力されません。

■ 不正解の選択肢の理由

  • A. 誤り。CloudWatch Logs はログを内部的に保持するサービスであり、Amazon S3 は関係ありません。S3 バケットへのアクセス許可は不要です。
  • B. 誤り。Lambda のバージョンが最新かどうかは、ログ出力とは無関係です。旧バージョンでも適切なロールがあればログは出力されます。
  • D. 誤り。API Gateway を使って Lambda を呼び出しても、Lambda 側が CloudWatch Logs にログを出力できるようになっていれば記録されます。呼び出し元は無関係です。

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

  • Lambda のログが CloudWatch Logs に出力されるには、Lambda の実行ロールに CloudWatch Logs への書き込み権限が必要。
  • 実行ロールの IAM ポリシーには、以下のようなアクションが含まれている必要がある：
{
  "Effect": "Allow",
  "Action": [
    "logs:CreateLogGroup",
    "logs:CreateLogStream",
    "logs:PutLogEvents"
  ],
  "Resource": "*"
}
  • CloudWatch Logs は S3 バケットではなく独自にログを管理するため、S3 との関係はない。
  • 呼び出し元（例：API Gateway、EventBridgeなど）にかかわらず、ログ出力は Lambda 側のロール設定次第。

このパターンは Lambda セキュリティとロギングに関する頻出トピックなので、IAM 実行ロールの必要なポリシー構成を頭に入れておくと得点しやすいです。

以下の形式で出力します：

■ 問題文

あるセキュリティエンジニアは、数千台の Amazon EC2 インスタンスを本番環境と開発環境に分けて保有しています。各インスタンスには、その環境のタグが付けられています。エンジニアは、すべての開発用 EC2 インスタンスを分析してパッチを適用し、それらが現在一般的な脆弱性または共通脆弱性識別子 (CVE) にさらされていないことを確認する必要があります。

これらの要件を満たすための最も効率的な方法を選択してください。(2 つ選択)

■ 選択肢

A. すべての開発用インスタンスに Amazon Inspector エージェントをインストールします。カスタムルールパッケージを作成し、開発環境としてタグ付けされたすべてのインスタンスでこのカスタムルールを使用してスキャンを実行するように Inspector を構成します。
B. すべての開発用インスタンスに Amazon EC2 System Manager エージェントをインストールします。EC2 で Systems Manager Run Command を発行し、すべてのインスタンスを更新します。
C. 各 EC2 インスタンスにログオンし、インストールされているさまざまなソフトウェアバージョンを確認してエクスポートし、現在の CVE のリストと照合して確認します。
D. すべての開発用インスタンスに Amazon Inspector エージェントをインストールします。開発環境としてタグ付けされたすべてのインスタンスでこの CVE ルールパッケージを使用してスキャンを実行するように Inspector を構成します。
E. AWS Trusted Advisor を使用して、すべての EC2 インスタンスがオペレーティングシステムとインストールされたソフトウェアの最新バージョンにパッチされていることを確認します。

■ 正解の選択肢と解説

正解：B, D

  • B. Systems Manager (SSM) を使用すると、EC2 インスタンスにリモートでパッチを適用できます。Run Command を使ってタグ（例：”Environment”:”Dev”）付きインスタンスに一括操作できるため、効率的です。
  • D. Amazon Inspector は、脆弱性スキャンを自動で実行し、CVE に基づく評価結果を提供します。タグベースでスキャン対象を絞り込むことができるため、大規模環境でも効果的です。

■ 不正解の選択肢の理由

  • A. カスタムルールパッケージを作成する必要はありません。Inspector は AWS が提供する既定の CVE ベースのルールセットを使う設計になっており、カスタムルールはサポートされていません。
  • C. インスタンスに都度ログインしてバージョン確認し手動で照合するのは非効率でスケーラビリティがありません。
  • E. Trusted Advisor はパッチ状態を直接評価しません。セキュリティベストプラクティスに関する助言をするツールであり、脆弱性スキャンは対象外です。

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

  • 脆弱性評価には Amazon Inspector、パッチ適用には Systems Manager（SSM Run Command） を使用するのがベストプラクティス。
  • タグベースの運用により、対象リソースのグループ管理が可能。
  • Inspector v2 はエージェントレスで動作（ただしエージェントが必要な場合もあるので注意）。
  • Trusted Advisor は脆弱性スキャンをしないことを明確に区別する。

以下の形式で出力します：

■ 問題文

セキュリティエンジニアが、既存の証跡の AWS CloudTrail ログファイルのプレフィックスを更新するよう依頼されました。CloudTrail コンソールで変更を保存しようとすると、セキュリティエンジニアは次のエラーメッセージを受け取ります。

「There is a problem with the bucket policy (バケットポリシーに問題があります。) 」

変更を保存できるようにするにはどうすればよいですか。

■ 選択肢

A. Amazon S3 コンソールの既存のバケットポリシーを更新して、セキュリティエンジニアのプリンシパルが GetBucketPolicy を実行できるようにしてから、CloudTrail コンソールのログファイルのプレフィックスを更新します。
B. Amazon S3 コンソールの既存のバケットポリシーを更新して、セキュリティエンジニアのプリンシパルが PutBucketPolicy を実行できるようにしてから、CloudTrail コンソールのログファイルのプレフィックスを更新します。
C. 更新されたログファイルのプレフィックスを使用して新しい証跡を作成してから、元の証跡を削除します。Amazon S3 コンソールの既存のバケットポリシーを新しいログファイルのプレフィックスで更新してから、CloudTrail コンソールのログファイルのプレフィックスを更新します。
D. Amazon S3 コンソールの既存のバケットポリシーを新しいログファイルのプレフィックスで更新してから、CloudTrail コンソールのログファイルのプレフィックスを更新します。

■ 正解の選択肢と解説

正解：D

CloudTrail が S3 バケットにログを配信できるようにするには、バケットポリシーが正しいプレフィックスに対して PutObject を許可している必要があります。ログファイルのプレフィックスを変更した際に「バケットポリシーに問題があります」と表示される場合は、新しいプレフィックスに対する書き込み権限がバケットポリシーに設定されていないことが原因です。

■ 不正解の選択肢の理由

  • A. GetBucketPolicy はポリシーの読み取り権限であり、CloudTrail がログを出力できるようになるためのものではありません。
  • B. PutBucketPolicy はバケットポリシーの更新に必要な権限ですが、この問題の解決には関係ありません。セキュリティエンジニア個人の権限ではなく、CloudTrail がログを書き込めるようにバケットポリシー自体を修正すべきです。
  • C. 新しい証跡を作成・削除する必要はなく、既存の証跡でプレフィックスを更新できます。操作が過剰で非効率です。

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

  • CloudTrail がログを出力するには、S3 バケットのバケットポリシーに s3:PutObject の許可が必要。
  • ログファイルのプレフィックスを変更した場合、バケットポリシーの Resource に新しいプレフィックスを反映する必要がある。
  • 「There is a problem with the bucket policy」というエラーは、CloudTrail 側の設定ではなく、S3 バケットポリシーが原因であることが多い。
  • IAM ユーザーやロールの権限ではなく、CloudTrail が書き込む先のリソース側の許可が重要である点に注意。

RELATED POST