#43｜SalmonLog

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

■問題文（そのまま）

会社は AWS でアプリケーションを実行します。AWS Lambda 関数は、Amazon RDS for MySQL DB インスタンスへの認証情報を使用しています。セキュリティリスク評価により、これらの認証情報は頻繁にローテーションされないことが確認されました。また、保存時の暗号化は DB インスタンスに対して有効になっていません。セキュリティチームは、これらの問題の両方を解決する必要があります。

これらのセキュリティリスクを修正するために推奨される戦略を選択してください。

■選択肢（そのまま）

A
Lambda 関数を構成して、データベースの認証情報を暗号化された AWS Systems Manager Parameter Store のパラメーターとして保存および取得します。別の Lambda 関数を作成して、認証情報を自動的にローテーションします。DB インスタンスの暗号化されたリードレプリカを作成します。暗号化されたリードレプリカを新しいプライマリノードに昇格させます。

B
DB インスタンスで IAM DB 認証を有効にします。Lambda 実行ロールに DB インスタンスへのアクセスを許可します。DB インスタンスの暗号化されたリードレプリカを作成します。暗号化されたリードレプリカを新しいプライマリノードに昇格させます。

✅ C
AWS Secrets Manager でデータベース認証情報を保存および取得し、認証情報のローテーションを有効にするように Lambda 関数を設定します。DB インスタンスのスナップショットを作成し、そのスナップショットのコピーを暗号化します。DB インスタンスを、暗号化されたスナップショットに基づく新しい DB インスタンスに置き換えます。

D
DB インスタンスで IAM DB 認証を有効にします。Lambda 実行ロールに DB インスタンスへのアクセスを許可します。DB インスタンスを変更し、暗号化を有効にします。

■問題文の要件の概要

認証情報がローテーションされていない → 自動ローテーションの導入が必要
DBインスタンスが暗号化されていない → 保存時暗号化の有効化が必要
対象は Amazon RDS for MySQL

■正解の選択肢と解説

✅ C. Secrets Manager + 暗号化スナップショットからの再作成

Secrets Manager を使えば、認証情報の保存・取得・自動ローテーションが可能。
RDS は既存インスタンスの暗号化を「そのまま」有効にできない。そのため、スナップショットを暗号化して新規インスタンスを復元するのが正しい方法。
これにより、認証情報の安全な管理と保存時暗号化の両方に対応。

■不正解の選択肢の理由

❌ A. Systems Manager Parameter Store + 暗号化されたリードレプリカを昇格

Parameter Store でもシークレット保存は可能だが、Secrets Manager のような自動ローテーション機能が標準ではない。
さらに、暗号化されていない DB から暗号化されたリードレプリカは作成できないという制約がある（RDSの仕様）。

❌ B. IAM DB 認証 + リードレプリカ

IAM DB 認証は確かに認証情報の代替になるが、MySQLでのサポートが限定的で、Lambdaとの直接連携には限界がある。
さらに リードレプリカからの昇格で暗号化状態を変更できないため、目的の保存時暗号化には不適切。

❌ D. IAM DB 認証 + インスタンスの暗号化を有効にする

既存インスタンスの暗号化を「直接有効」にすることはできない（RDSでは不可）。
暗号化したい場合は、「スナップショットを作成 → 暗号化 → 新インスタンスを復元」が唯一の手段。

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

観点	内容
🔑 Secrets Manager	DB認証情報の保存・取得・自動ローテーションに対応。セキュリティ最適。
❌ Parameter Store	暗号化保存可能だが、Secrets Managerのようなローテーション自動化は要実装。
❌ RDS暗号化制限	既存のインスタンスの暗号化は直接できない。スナップショットコピー→新規作成が必要。
⚠ IAM DB認証	有効だが、MySQL との組み合わせや Lambda との実用性に制限あり。
✅ 暗号化スナップショット復元	保存時暗号化が必要な場合のベストプラクティス。

この問題は、Secrets Manager の自動ローテーションと、RDS 暗号化制限という2つの重要トピックを同時に問う良問です。特に「RDSインスタンスは後から暗号化できない」という仕様は頻出ですので要暗記です。

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

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

■問題文（そのまま）

ウェブアプリケーションは、Application Load Balancer (ALB) の背後にある Amazon EC2 インスタンスの VPC で実行されます。アプリケーションは、Amazon RDS for MySQL DB インスタンスにデータを保存します。Linux の踏み台ホストは、データベースにスキーマの更新を適用します。管理者は、会社のワークステーションから SSH を使用して踏み台ホストに接続します。インフラストラクチャには、以下のセキュリティグループが適用されています。

sgLB: ALB に関連付けられています
sgWeb: EC2 インスタンスに関連付けられています
sgDB: データベースに関連付けられています
sgBastion: 踏み台ホストに関連付けられています

アプリケーションを安全に機能させる最適なセキュリティグループを選択してください。

■選択肢（そのまま）

sgLB: 0.0.0.0/0 からのポート 80 と 443 のトラフィックを許可します。
sgWeb: sgLB からのポート 80 と 443 のトラフィックを許可します。
sgDB：sgWeb と sgBastion からのポート 3306 のトラフィックを許可します。
sgBastion: ポート 22 および VPC IP アドレス範囲からのトラフィックを許可します。

sgLB: 0.0.0.0/0 からのポート 80 と 443 のトラフィックを許可します。
sgWeb: 0.0.0.0/0 からのポート 80 と 443 のトラフィックを許可します。
sgDB: sgWeb と sgBastion からのポート 3306 のトラフィックを許可します。
sgBastion: 企業 IP アドレス範囲からのポート 22 トラフィックを許可します。

sgLB: 0.0.0.0/0 からのポート 80 と 443 のトラフィックを許可します。
sgWeb: sgLB からのポート 80 と 443 のトラフィックを許可します。
sgDB: sgWeb と sgLB からのポート 3306 のトラフィックを許可します。
sgBastion: VPC IP アドレス範囲からのポート 22 トラフィックを許可します。

✅ D

sgLB: 0.0.0.0/0 からのポート 80 と 443 のトラフィックを許可します。
sgWeb: sgLB からのポート 80 と 443 のトラフィックを許可します。
sgDB：sgWeb と sgBastion からのポート 3306 のトラフィックを許可します。
sgBastion: 企業 IP アドレス範囲からのポート 22 トラフィックを許可します。

■問題文の要件の概要

ALB 経由で Web アプリにアクセス → ALB から EC2 への通信を許可する必要あり。
Web アプリ → RDS にアクセス → EC2（sgWeb）から RDS（sgDB）への3306許可
管理者 → 踏み台ホスト（sgBastion）→ DB に接続 → SSH許可 + sgBastion から sgDB:3306 許可
セキュリティ強化のため、パブリックからの広範な許可は避ける

■正解の選択肢と解説

✅ D が正解：

sgLB: ALB に外部からアクセスできるよう、0.0.0.0/0 からの 80, 443 を許可。
sgWeb: ALB（sgLB）からのアクセスだけを許可 → 最小権限原則に沿う。
sgDB: アプリ（sgWeb）と管理用（sgBastion）からの DB ポート 3306 を許可。
sgBastion: 管理者の会社 IP アドレスからの SSH 接続のみを許可 → セキュア。

■不正解の選択肢の理由

❌ A

sgBastion が「VPC IP アドレス範囲からのポート 22 を許可」しており、踏み台ホストに過剰に広いアクセス許可が与えられてしまう。会社の IP に限定すべき。

❌ B

sgWeb が 0.0.0.0/0 からの HTTP/S を許可しており、ALB 経由のアクセス制御が無効化されている。ALBを使う意味が薄れるため非推奨。

❌ C

sgDB が sgLB からの 3306 を許可しており、ALB からDBへのアクセスが可能になってしまう。ALBはDBに直接アクセスしないためセキュリティ上問題。

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

観点	内容
✅ セキュリティグループの参照	セキュリティグループ間で参照（例: `sgWeb から sgDB:3306`）するのが最小権限に有効。
✅ ALB + EC2構成	EC2 は ALB からの通信のみを許可するべき（Web に直接公開しない）。
✅ 踏み台ホスト制限	SSH は会社のIPアドレスなどに制限する。`0.0.0.0/0`やVPC全体は広すぎる。
✅ RDS 暗号化とセキュリティ	RDS は原則として、必要な通信元だけを許可。ALBなど不要な経路からは遮断する。

この問題は、セキュリティグループ設計の実践力が問われる典型的な構成問題です。全体の構成を頭に描いた上で、通信元と通信先の正当性を確認する視点が重要です。

次の問題もあれば、引き続きどうぞ。

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

■問題文（そのまま）

Amazon GuardDuty は、ある企業の Amazon EC2 インスタンスから、既知のコマンドおよびコントロールエンドポイントへの通信を検出しました。このインスタンスは、一般的なウェブフレームワークの脆弱なバージョンを実行していることが判明しました。同社のセキュリティ運用チームは、そのフレームワークの特定のバージョンがインストールされている他のコンピューティングリソースをすばやく特定したいと考えています。

このタスクを達成する最適な方法を選択してください。

■選択肢（そのまま）

A
AWS Resource Access Manager を使用してすべての EC2 インスタンスをスキャンし、ウェブフレームワークの脆弱なバージョンを特定します。

B
AWS Config に準拠していないかどうか、すべての EC2 インスタンスをスキャンします。Amazon Athena を使用して、フレームワークのインストールに関する AWS CloudTrail ログをクエリします。

✅ C
AWS Systems Manager を使用してすべての EC2 インスタンスをスキャンし、ウェブフレームワークの脆弱なバージョンを特定します。

D
Amazon Inspector Network Reachability ルールパッケージを使用してすべての EC2 インスタンスをスキャンし、RecognizedPortWithListener の結果でウェブサーバーを実行しているインスタンスを特定します。

■問題文の要件の概要

GuardDuty が C2 通信を検出。
脆弱なウェブフレームワークのバージョンを実行していることが判明。
他のインスタンスにも同じ脆弱なソフトウェアが存在するか調べたい。
最速かつ正確に対象バージョンを可視化したい。

■正解の選択肢と解説

✅ C. AWS Systems Manager を使用してすべての EC2 インスタンスをスキャンし、ウェブフレームワークの脆弱なバージョンを特定します。

AWS Systems Manager の インベントリ機能を使えば、EC2 インスタンス上のソフトウェア情報（パッケージ名、バージョン、インストール日など）を一元収集可能。
SSM Agent がインストール・有効なインスタンスであれば、インベントリ情報を S3 や Athena などと連携して可視化・分析もできる。
多数のインスタンスの中から、特定のソフトウェアバージョンを持つ対象を素早く特定可能。

■不正解の選択肢の理由

❌ A. AWS Resource Access Manager を使用して…
→ AWS RAM はリソース共有のためのサービスであり、ソフトウェアスキャンやインベントリ機能は一切持たない。

❌ B. AWS Config + Athena + CloudTrail ログ
→ AWS Config はリソース構成の変更監視。CloudTrail はAPI 呼び出しのログなので、ウェブフレームワークのインストールログが出ない可能性が高い。
→ 時間もかかる上に不確実であり、バージョンの特定は難しい。

❌ D. Amazon Inspector Network Reachability
→ Network Reachability パッケージはオープンポートや通信可否を評価するもので、ソフトウェアバージョンの特定は不可能。

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

観点	内容
✅ GuardDuty 検出後の対応	GuardDuty はインシデント検出まで。その後の調査・対処は他のサービスで行う。
✅ Systems Manager の活用	SSM インベントリでソフトウェア一覧とバージョン管理が可能。セキュリティ分析に非常に有効。
✅ Amazon Inspector の用途	ソフトウェアの脆弱性検出（Inspector V2）、またはネットワーク到達性評価（旧Inspector）であり、バージョン特定目的ではない。
✅ RAM, Config の役割理解	RAM はリソース共有、Config は構成管理であり、ソフトウェアスキャンには直接使えない。

この問題は、GuardDutyを起点としたインシデント対応における調査スキルが問われています。SSM Inventory の即時性と正確性を把握しておくことがカギです。

次の問題もお送りください。続けて対応いたします。

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

■問題文（そのまま）

ある企業は、Amazon Elastic Kubernetes Service (Amazon EKS) と Amazon Aurora を使用して、AWS 上でマイクロサービスアーキテクチャを Kubernetes コンテナで運用しています。企業は AWS Organizations 内に組織を持ち、数百の AWS アカウントで異なるマイクロサービスをホストしています。
企業は、すべての AWS アカウントにわたる AWS リソースのログを監視するソリューションを実装する必要があります。このソリューションには、セキュリティ関連の問題を自動検出する機能を含める必要があります。

最も少ない運用労力でこれらの要件を満たすソリューションを選択してください。

■選択肢（そのまま）

A
監視専用のアカウントを指定します。すべてのアカウントの Amazon CloudWatch Logs を監視アカウントと共有します。Amazon Kinesis Data Streams を CloudWatch Logs にサブスクライブします。AWS Lambda 関数を作成し、データストリーム内のログレコードを処理してセキュリティ問題を検出します。

B
監視専用のアカウントを指定します。すべてのアカウントの Amazon CloudWatch Logs を監視アカウントと共有します。すべてのログを CloudWatch に公開するように Aurora を設定します。監視アカウントで Amazon Inspector を使用して、CloudWatch Logs を評価します。

✅ C
組織の管理アカウントで Amazon GuardDuty の管理者アカウントを指定します。すべてのアカウントで GuardDuty を有効にします。GuardDuty の管理者アカウントで EKS Protection と RDS Protection を有効にします。

D
組織の管理アカウントに中央の Amazon S3 バケットを作成します。すべての AWS アカウントで AWS CloudTrail を設定して、CloudTrail ログを S3 バケットに配信します。すべてのログを CloudTrail に公開するように Aurora を設定します。Amazon Athena を使用して S3 バケット内の CloudTrail ログをクエリし、セキュリティ問題を特定します。

■問題文の要件の概要

複数アカウント（数百）を対象とした監視。
Amazon EKS と Aurora を使用。
セキュリティ関連の自動検出機能が必要。
最小限の運用労力で構成可能なソリューションを選ぶ。

■正解の選択肢と解説

✅ C. 組織の管理アカウントで Amazon GuardDuty の管理者アカウントを指定し、EKS Protection と RDS Protection を有効化する。

GuardDuty は AWS 組織全体に対して集中管理が可能で、運用負荷を最小限に抑えてセキュリティ脅威の検出が可能。
EKS Protection：EKS クラスタの監査ログから不審なアクティビティ（認証されていないアクセス、シークレットの漏洩など）を検出。
RDS Protection：Aurora や RDS のログインアクティビティを監視し、異常なアクセスパターンを検出。
GuardDuty の利点は、設定さえすれば自動で脅威を検出してくれる点。ログ分析の手間や Lambda 実装が不要。

■不正解の選択肢の理由

❌ A. CloudWatch Logs + Kinesis Data Streams + Lambda による自作検出処理

この構成では ログ収集から脅威検出まで手動実装が必要。
スケーラビリティや保守性に課題あり。
セキュリティ検出ロジックも Lambda で全て管理する必要があり、「運用負荷が高すぎる」ため不適。

❌ B. CloudWatch Logs + Amazon Inspector

Amazon Inspector は EC2 やコンテナイメージの脆弱性スキャンツールであり、CloudWatch Logs には対応していない。
Logs を使った脅威検出に利用できないため、「誤った用途のサービス選定」。

❌ D. CloudTrail + S3 + Athena

CloudTrail ログを集約し、Athena でクエリする方式は分析に時間がかかり、定期的な監視が手動依存になる。
セキュリティイベントのリアルタイム検出が困難。分析スキルも必要。
GuardDuty のように 自動で検知・通知が行われる設計ではないため、非効率。

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

観点	内容
✅ GuardDuty	セキュリティ脅威を自動で検出し、組織レベルで一元管理できる。
✅ EKS / RDS Protection	Kubernetes クラスタや RDS への不審なアクセスを自動で可視化できる。
✅ 少ない運用労力	Lambda や手動クエリより、マネージドサービスを活用した自動検出が推奨。
❌ CloudWatch Logs / Inspector の誤用	Logs 分析は Inspector の用途外。運用を考慮せずに選ばないよう注意。
❌ Kinesis + Lambda の手作り構成	SCS 試験では、セキュリティ検出は自動・統合されたサービスで実現するのがベストプラクティス。

この問題では、スケーラビリティと運用の最適化がキーワードです。SCS 試験では、「自動化・統合・最小構成でセキュリティを担保」できるサービス設計を選びましょう。

次の問題も引き続き対応します。

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

■問題文（そのまま）

会社は、キー枯渇に関連する規制要件を満たしながら、ローカルでデータを暗号化したいと考えています。暗号化キーは、10 日以上古いものであってはならず、また 65,536 オブジェクト以上を暗号化してはなりません。暗号化キーは、FIPS 140-2 レベル 2 で検証されたハードウェアセキュリティモジュール (HSM) で生成する必要があります。同社は、5 つのデータプロダクションで継続的に運用するために、毎秒平均 100 個のオブジェクトを Amazon S3 にアップロードすることを計画しており、コストに配慮しています。

会社のニーズを最も効率的に満たす方法を選択してください。

■選択肢（そのまま）

A
AWS Key Management Service (AWS KMS) を使用して、AWS マネージドキーを生成します。次に、すべてのオブジェクトで自動的にローテーションするように設定された Amazon S3 クライアント側の暗号化を使用します。

✅ B
AWS 暗号化 SDK を使用し、最大経過時間を 10 日に設定し、暗号化されたメッセージの最大数を 65,536 に設定します。AWS Key Management Service (AWS KMS) を使用して、マスターキーとデータキーを生成します。暗号化処理中に Encryption SDK でデータキーキャッシュを使用します。

C
Amazon S3 マネージドキーを用いたサーバー側の暗号化 (SSE-S3) を使用し、マスターキーを自動的にローテーションするように設定します。

D
AWS CloudHSM を使用してマスターキーとデータキーを生成します。次に、オブジェクトをアップロードする前に、Boto 3 と Python を使用してローカルでデータを暗号化します。10 日ごと、または 65,536 個のオブジェクトが Amazon S3 にアップロードされた後、データキーをローテーションします。

■問題文の要件の概要

暗号化キーの有効期間は「最大10日間」。
1つのキーで「最大65,536オブジェクトまでの暗号化」。
キーは「FIPS 140-2 レベル2」検証済の HSM で生成。
処理は「クライアントサイド暗号化」。
アップロード数は「毎秒100オブジェクト × 複数プロダクション」。
「コスト効率」が求められる。

■正解の選択肢と解説

✅ B. AWS 暗号化 SDK + AWS KMS + データキーキャッシュの活用

AWS 暗号化 SDK には「データキーキャッシュ」と「セキュリティしきい値」設定機能があり、キーの再利用条件（時間・回数）を厳格に制御可能。
「最大10日」「最大65,536オブジェクト」のしきい値設定が可能。
KMS は FIPS 140-2 レベル2 準拠の HSM を使用。
データキーキャッシュを使うことで KMS 呼び出し数を最小化し、コスト効率にも優れる。

■不正解の選択肢の理由

❌ A. AWS KMS + S3 クライアント暗号化（自動ローテーション）

AWS KMS のマネージドキーでは自動ローテーションは年1回で、10日ごとの制御が不可能。
暗号化ごとのしきい値制限（65,536回など）を制御できない。
要件の「明示的なキー再利用制限」を満たせない。

❌ C. SSE-S3（Amazon S3 マネージドキー）

SSE-S3 のキーは AWS が管理するもので、FIPS 140-2 レベル2の要件は未保証。
キーの使用回数・期間の制御ができない。
クライアント側での暗号化制御が求められているため、サーバー側暗号化では要件不適合。

❌ D. CloudHSM + Boto3 + 手動ローテーション

CloudHSM は FIPS レベル2 を満たすが、ローテーション条件（10日 or 65,536回）を手動で管理する必要がある。
毎秒100オブジェクト × 複数ストリームでは高頻度ローテーション管理が困難。
CloudHSM は KMS より高コストかつ複雑なオペレーションが必要 → 「コスト効率が悪い」。

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

ポイント	内容
✅ AWS 暗号化 SDK	クライアント側暗号化処理において、キー使用回数と時間を制限可能。
✅ データキーキャッシュ	AWS KMS への呼び出し回数を抑制しつつ、セキュリティ要件を遵守できる。
✅ KMS は FIPS レベル2	暗号化SDKと併用することで、ハードウェアベースで安全なキー管理が可能。
❌ 自動ローテーション誤解	KMS キーの自動ローテーションは年1回。短期間でのローテーションは手動設計が必要。
❌ CloudHSM の誤用	FIPS要件は満たすが、管理負荷・コストが高いためスケーラブルな構成には不適。

この問題では「セキュリティしきい値をコードで制御可能な AWS 暗号化 SDK + KMS の組み合わせ」が最も重要です。
特に、「キー枯渇対策」や「再利用制限」が求められる場合には SDK のキャッシュ管理機能が鍵です。

次の問題もお待ちしております。

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

■問題文（そのまま）

セキュリティエンジニアは、Amazon S3 バケットポリシーを設定して、DOCEXAMPLE-BUCKET という名前の S3 バケットへのアクセスを制限する必要があります。このポリシーでは、エンドポイント vpce-1a2b3c4d からのみ DOC-EXAMPLE-BUCKET へのアクセスを許可する必要があります。指定されたエンドポイントが使用されていない場合、ポリシーは DOC-EXAMPLE-BUCKET へのすべてのアクセスを拒否する必要があります。

これらの要件を満たすバケットポリシーのステートメントを選択してください。

■選択肢（そのまま）

"Statement": [
  {
    "Sid": "Access-to-specific-VPCE-only",
    "Principal": "*",
    "Action": "s3:*",
    "Effect": "Allow",
    "Resource": [
      "arn:aws:s3:::DOC-EXAMPLE-BUCKET",
      "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
    ],
    "Condition": {
      "StringEquals": {
        "aws:sourceVpce": "vpce-1a2b3c4d"
      }
    }
  }
]

"Statement": [
  {
    "Sid": "Access-to-specific-VPCE-only",
    "Principal": "*",
    "Action": "s3:*",
    "Effect": "Deny",
    "Resource": [
      "arn:aws:s3:::DOC-EXAMPLE-BUCKET",
      "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
    ],
    "Condition": {
      "StringEquals": {
        "aws:sourceVpce": "vpce-1a2b3c4d"
      }
    }
  }
]

✅ C

"Statement": [
  {
    "Sid": "Access-to-specific-VPCE-only",
    "Principal": "*",
    "Action": "s3:*",
    "Effect": "Deny",
    "Resource": [
      "arn:aws:s3:::DOC-EXAMPLE-BUCKET",
      "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
    ],
    "Condition": {
      "StringNotEquals": {
        "aws:sourceVpce": "vpce-1a2b3c4d"
      }
    }
  }
]

"Statement": [
  {
    "Sid": "Access-to-specific-VPCE-only",
    "Principal": "*",
    "Action": "s3:*",
    "Effect": "Allow",
    "Resource": [
      "arn:aws:s3:::DOC-EXAMPLE-BUCKET",
      "arn:aws:s3:::DOC-EXAMPLE-BUCKET/*"
    ],
    "Condition": {
      "StringNotEquals": {
        "aws:sourceVpce": "vpce-1a2b3c4d"
      }
    }
  }
]

■問題文の要件の概要

アクセスは 特定の VPC エンドポイント（vpce-1a2b3c4d） からのみに制限。
それ以外のアクセスは明示的に拒否することが必要。
つまり「条件に一致しないものはすべて拒否する」明示的制御が求められる。

■正解の選択肢と解説

✅ C. Effect: Deny + StringNotEquals による拒否ポリシー

"Effect": "Deny",
"Condition": {
  "StringNotEquals": {
    "aws:sourceVpce": "vpce-1a2b3c4d"
  }
}

StringNotEquals を使って、指定された VPC エンドポイント以外からのすべてのアクセスを拒否。
AWS の IAM ポリシー評価では、明示的な Deny が常に優先されるため、他の許可ポリシーを無効にできる。
ポリシーが複数ある場合でもこの Deny により、他経路からのアクセスは完全に遮断できる。
最もセキュアかつ要件に忠実な実装。

■不正解の選択肢の理由

❌ A. Allow + StringEquals

Effect: Allow に StringEquals を使って 条件付き許可しているが…
「それ以外を拒否する」ポリシーがないため、他のポリシーで許可されていればアクセスできてしまう。
「明示的拒否」がないと SCPやIAMの許可をブロックできない。
よって「他のエンドポイントからのアクセス拒否」という要件を満たせない。

❌ B. Deny + StringEquals

これは vpce-1a2b3c4d からのアクセスを 拒否する設定。完全に逆。
正しくは「vpce-1a2b3c4d以外を拒否」する必要がある。
条件の評価対象を逆に指定しているので、要件を誤解している実装。

❌ D. Allow + StringNotEquals

Effect: Allow に StringNotEquals を使うと、vpce-1a2b3c4d以外からのアクセスを許可する意味になってしまう。
これはまったくの逆効果。
指定エンドポイントからのみ許可するどころか、それ以外を許してしまう。

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

ポイント	内容
✅ 明示的拒否は常に最優先で適用される	他の許可ポリシーより優先されるため、アクセス制御の最後の砦。
✅ aws:sourceVpce は VPCエンドポイント制御に使う	特定の PrivateLink 経由に通信を限定したいときに有効。
❌ Allow + 条件付きだけでは不十分	IAMやSCPなど別の経路の許可をブロックできない。拒否ポリシーが必要。
✅ “Deny” + “StringNotEquals” パターンは鉄板	条件外のアクセスはすべて拒否できる。セキュリティ試験でよく問われる構文。

この問題は IAMポリシー評価ロジック（明示的Deny優先）と 条件付きアクセス制御の正しい適用を理解しているかどうかが問われています。

引き続き、次の問題も対応可能です。必要であればお送りください。

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

■問題文（そのまま）

企業は、Amazon EC2 セキュリティグループが、SSH アクセスを CIDR ブロック 0.0.0.0/0 から許可しないようにする必要があります。同社は、この要件への準拠を常に監視し、準拠していないセキュリティグループがあれば、ほぼリアルタイムで通知を受け取りたいと考えています。

セキュリティエンジニアは、AWS Config を設定し、セキュリティグループを監視するために restricted-ssh マネージドルールを使用する予定です。

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

■選択肢（そのまま）

A
AWS Config を設定して、その設定スナップショットを Amazon S3 バケットに送信します。S3 バケットへの PutEvent で実行する AWS Lambda 関数を作成します。Lambda 関数を設定して、restricted-ssh マネージドルールへのコンプライアンス変更のスナップショットを解析します。変更が発見された場合、Amazon Simple Notification Service (Amazon SNS) トピックに通知を送信するために Lambda 関数を設定します。

B
restricted-ssh マネージドルールの CloudWatch メトリクスで Amazon CloudWatch アラームを設定します。アラームが ALARM 状態の場合に、Amazon Simple Notification Service (Amazon SNS) トピックに通知を送信するように CloudWatch アラームを設定します。

✅ C
restricted-ssh マネージドルールの AWS Config からのコンプライアンス変更イベントによって呼び出される Amazon EventBridge (Amazon CloudWatch Events) イベントルールを設定します。通知を提供する Amazon Simple Notification Service (Amazon SNS) トピックをターゲットとするイベントルールを設定します。

D
すべてのコンプライアンス通知を Amazon CloudWatch Logs にプッシュするように AWS Config を設定します。AWS Config のロググループに CloudWatch Logs のメトリクスフィルターを設定し、restricted-ssh マネージドルールのコンプライアンス通知の変更を探します。メトリクスフィルターで Amazon CloudWatch アラームを作成し、アラームが ALARM 状態の場合に Amazon Simple Notification Service (Amazon SNS) トピックに通知を送信します。

■問題文の要件の概要

EC2 のセキュリティグループが 0.0.0.0/0 からの SSH アクセスを許可していないことを監視。
restricted-ssh マネージドルールで AWS Config による準拠評価。
**準拠違反があれば「ほぼリアルタイムで通知」**が必要。

■正解の選択肢と解説

✅ C. AWS Config で EventBridge 経由で準拠違反を通知

AWS Config のマネージドルール（ここでは restricted-ssh）は、コンプライアンス状態が変化すると EventBridge にイベントを発行。
EventBridge ルールを設定すれば、コンプライアンス違反のたびに SNS へ通知が即時送信可能。
最もシンプルかつリアルタイムな構成。AWS が推奨するベストプラクティス。

■不正解の選択肢の理由

❌ A. スナップショット + Lambda で監視

AWS Config の「設定スナップショット」は 定期的な全体構成の記録であり、リアルタイム検出には向かない。
Lambda 関数でスナップショットをパースする構成は 複雑・非効率・通知遅延が発生。

❌ B. CloudWatch アラームで通知

AWS Config のルールには CloudWatch メトリクスが生成されるが、メトリクス反映までに遅延あり。
アラームが変化して SNS 通知される仕組みは、EventBridge より即時性に欠ける。

❌ D. CloudWatch Logs + メトリクスフィルター

AWS Config のログを CloudWatch Logs に出力 → メトリクスフィルター → アラーム → SNS通知。
検出から通知までの処理ステップが多く、即時性が低い。
構成も煩雑。

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

ポイント	内容
✅ AWS Config + EventBridge + SNS	AWSリソースのコンプライアンス変化をリアルタイムで通知する最適な構成。
✅ restricted-ssh ルール	`0.0.0.0/0` からの SSH 許可をチェックするセキュリティベースラインルール。
❌ スナップショット依存構成	遅延・非効率。監視用途には不適。
❌ CloudWatch Logs + メトリクス構成	検出に時間がかかる。試験ではリアルタイム性を問われたら EventBridge を選択。

この問題は「準拠違反の即時通知手段として EventBridge を使えるか？」という、AWS Config と EventBridge の連携理解を問う基本問題です。

次の問題もあれば続けて解説します。

■問題文（そのまま）

■選択肢（そのまま）

■問題文の要件の概要

■正解の選択肢と解説

■不正解の選択肢の理由

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

■問題文（そのまま）

■選択肢（そのまま）

■問題文の要件の概要

■正解の選択肢と解説

■不正解の選択肢の理由

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

■問題文（そのまま）

■選択肢（そのまま）

■問題文の要件の概要

■正解の選択肢と解説

■不正解の選択肢の理由

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

■問題文（そのまま）

■選択肢（そのまま）

■問題文の要件の概要

■正解の選択肢と解説

■不正解の選択肢の理由

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

■問題文（そのまま）

■選択肢（そのまま）

■問題文の要件の概要

■正解の選択肢と解説

■不正解の選択肢の理由

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

■問題文（そのまま）

■選択肢（そのまま）

■問題文の要件の概要

■正解の選択肢と解説

■不正解の選択肢の理由

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

■問題文（そのまま）

■選択肢（そのまま）

■問題文の要件の概要

■正解の選択肢と解説

■不正解の選択肢の理由

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

#38

#36

151-160

Recent Posts

Recent Comments

Archives

Categories