以下は、提供いただいたSCS試験問題の形式に従った解析結果です。
■ 問題文（そのまま）
ある教育会社では、世界中の大学生が利用するウェブアプリケーションを運用しています。このアプリケーションは、Amazon Elastic Container Service (Amazon ECS) クラスターで、Application Load Balancer (ALB) の背後にある Auto Scaling グループで実行されています。システム管理者は、ログイン失敗の試行回数が毎週急増し、アプリケーションの認証サービスに負荷がかかっていることを検知しました。失敗したログイン試行はすべて、毎週変更される約 500 の異なる IP アドレスから発信されています。ソリューションアーキテクトは、失敗したログイン試行が認証サービスを圧倒するのを防ぐ必要があります。
これらの要件を最も高い運用効率で満たすソリューションを選択してください。
■ 選択肢（そのまま）
A: AWS Firewall Manager を使用して、セキュリティグループとセキュリティグループポリシーを作成し、IP アドレスからのアクセスを拒否します。
B: AWS WAF の ウェブ ACL に IP セット一致ルールを作成し、ルールアクションをブロックに設定します。ウェブ ACL を ALB に接続します。
C: AWS Firewall Manager を使用して、特定の CIDR 範囲にのみアクセスを許可するセキュリティグループとセキュリティグループポリシーを作成します。
D: レートベースのルールで AWS WAF の ウェブ ACL を作成し、ルールアクションをブロックに設定します。ウェブ ACL を ALB に接続します。
■ 正解の選択肢と解説
正解：D
解説：
攻撃元のIPアドレスが毎週約500件も変化するため、静的なIPブロック（IPセット一致ルール）では追従できません。
AWS WAFのレートベースルールは、短時間に多数のリクエストを送るIPを自動的に検出して一時的にブロックできるため、認証サービスの保護に非常に適しています。
この方法は継続的なIPリストの更新が不要で、高い運用効率を発揮します。
■ 不正解の選択肢の理由
- A（Firewall Manager + セキュリティグループ）
→ Firewall Manager はセキュリティグループを集中管理できますが、頻繁に変わるIPを毎週更新する必要があり、運用効率が低く不適です。 - B（IPセット一致ルール）
→ 静的IPセットでは毎週変化するIPに対応できません。レートベースルールのような動的検出が必要です。 - C（Firewall ManagerでCIDR制限）
→ CIDR制限は想定される全世界の学生アクセスを大幅に制限することになり、正当なユーザーまで排除するリスクがあるため不適切です。
■ SCS試験で押さえておくべきポイント
| 観点 | 内容 |
|---|---|
| WAFレートベースルール | 送信元IPごとに1分間のリクエスト数をカウントし、しきい値を超えたIPをブロック。自動的に緩和。 |
| IPセット一致ルール | 静的なIPブロックには有効だが、頻繁に変わる攻撃元には不向き。 |
| Firewall Managerの用途 | 組織内のWAF/SG/NW Firewallポリシー管理に適すが、迅速な攻撃緩和には向かない。 |
| ALBとWAFの統合 | AWS WAFはALBと統合可能で、HTTPリクエスト単位で詳細制御が可能。 |
| 運用効率の観点 | 「IPが変化し続ける」「ルールを自動化したい」状況ではレートベースルールが最適。 |
必要に応じて、図解やサービス間の関連も補足可能です。次の問題もあればお送りください。
以下は、提供いただいたSCS試験問題の形式に従った解析結果です。
■ 問題文（そのまま）
会社のセキュリティエンジニアは、他の AWS サービスへのアクセスを提供せずに、請負業者の IAM アカウントによる会社の Amazon EC2 コンソールへのアクセスを制限する任務を負っています。請負業者の IAM アカウントは、IAM グループメンバーシップに基づいて IAM アカウントに追加のアクセス許可が割り当てられている場合でも、他の AWS サービスにアクセスできないようにする必要があります。
これらの要件を満たすための最適な方法を選択してください。
■ 選択肢（そのまま）
A: Amazon EC2 アクセスを許可する IAM アクセス許可の境界ポリシーを作成します。請負業者の IAM アカウントを IAM アクセス許可の境界ポリシーに関連付けます。
B: Amazon EC2 アクセスを許可するポリシーが添付された IAM グループを作成します。請負業者の IAM アカウントを IAM グループに関連付けます。
C: 請負業者の IAM ユーザーに Amazon EC2 アクセスを許可するインライン IAM ユーザーポリシーを作成します。
D: EC2 を許可し、他のすべてのサービスを明示的に拒否する IAM ロールを作成します。請負業者に常にこのロールを引き受けるように指示します。
■ 正解の選択肢と解説
正解：A
解説：
IAM アクセス許可の境界（Permissions Boundary）は、IAM ユーザーやロールに対して「許可できる操作の最大範囲（上限）」を制限する仕組みです。
この問題では、「グループなど他の経路で不要な許可が与えられる可能性がある」ことが前提になっているため、その上限を定義するアクセス許可の境界を設定することが最も確実な制御手段です。
アクセス許可の境界では、「このユーザーがどのようなポリシーを持っていても、ここで定めた範囲内でしか許可されない」ため、EC2以外のアクセスを防げます。
■ 不正解の選択肢の理由
- B：IAM グループにポリシーを付けるだけでは、他のグループから付与された権限を制限する手段がありません。アクセスが分散している環境では不適。
- C：インラインポリシーを使っても、他に付与されたマネージドポリシーやグループポリシーの影響を排除できません。
- D：IAM ロールによる制御は有効ですが、「常にこのロールを引き受けるように強制」する仕組みは IAM には存在しません。ユーザー自身の権限が強ければ、他の方法で操作できてしまいます。
■ SCS試験で押さえておくべきポイント
| 観点 | 内容 |
|---|---|
| アクセス許可の境界 | IAM ユーザーやロールが持てるアクセス許可の上限を制御する高度なセキュリティ機能。 |
| グループ・マネージドポリシーの影響 | 他のポリシー経路（例：グループ経由）で意図せぬアクセスが付与される可能性がある。 |
| ポリシー構造の優先順位 | アクセス許可の境界が存在する場合、ユーザーの全ポリシーは「境界」以内でしか効力を持たない。 |
| 明示的拒否と制限の違い | 境界は「上限の許可」を設定するもので、「明示的拒否」は行わない。 |
| 強制的な AssumeRole はできない | IAM ロールを使って制限しても、ユーザー自体に強い権限があれば回避可能。 |
他にも類似問題があれば、引き続き送ってください。対策を一緒に深めましょう。
以下は、問題3の解析結果を所定の形式でまとめた内容です。
■ 問題文（そのまま）
ある企業には、複数の本番用 AWS アカウントと、中央のセキュリティ用 AWS アカウントがあります。セキュリティアカウントは、集中監視のために使用され、すべての企業アカウントのすべてのリソースに対する IAM 特権を持っています。会社のすべての Amazon S3 バケットは、そのコンテンツのデータ分類を示す値でタグ付けされています。セキュリティエンジニアは、バケットポリシーへの準拠を強制する監視ソリューションをセキュリティアカウントに展開しています。システムは、すべての本番アカウントの S3 バケットを監視し、ポリシーの変更がバケットのデータ分類に従っていることを確認する必要があります。コンプライアンスに反する変更があった場合、セキュリティチームに迅速に通知されなければなりません。
必要なソリューションを構築するアクションの組み合わせを選択してください。(3 つ選択)
■ 選択肢（そのまま）
A: セキュリティアカウントで Amazon GuardDuty を有効にし、本番アカウントにメンバーとして参加します。
B: セキュリティアカウントで Amazon EventBridge (Amazon CloudWatch Events) ルールを設定して、S3 バケットの作成または変更イベントを検出します。
C: セキュリティアカウントで AWS Lambda 関数を呼び出し、S3 イベントに応答して S3 バケット設定を分析し、セキュリティチームにコンプライアンス違反の通知を送信します。
D: AWS Trusted Advisor を有効にし、セキュリティ連絡先に割り当てられたメールアドレスのメール通知を有効にします。
E: すべての S3 イベントをセキュリティアカウントのイベントバスに送信するように、本番アカウントで Amazon EventBridge (Amazon CloudWatch Events) を設定します。
F: PUT、POST、および DELETE イベントに対して、S3 バケットにイベント通知を設定します。
■ 正解の選択肢と解説
正解：B、C、E
B：EventBridge ルールでS3のバケット作成や変更イベントを検出
セキュリティアカウント側で EventBridge ルールを作成することで、S3 バケットに対する重要な変更をリアルタイムで検知できます。
C：Lambda によるバケット設定の分析と通知
検知されたイベントに対して Lambda 関数で自動チェックを行い、S3 バケットのタグやポリシーがデータ分類と一致しているかを検証し、違反時は通知することで監視体制を自動化できます。
E：本番アカウントから EventBridge イベントをセキュリティアカウントのバスへ転送
複数アカウント構成において、監視の一元化には EventBridge のクロスアカウントイベント転送が効果的です。これにより、すべての監視ロジックをセキュリティアカウントで集中管理できます。
■ 不正解の選択肢の理由
- A（GuardDuty）：これは脅威検出ツールであり、S3 ポリシー変更やデータ分類違反の検知には適していません。
- D（Trusted Advisor）：Trusted Advisor はベストプラクティスに基づいたアドバイスを提供するツールであり、カスタムなコンプライアンス違反の検知は行えません。
- F（S3イベント通知）：S3 イベント通知はオブジェクトレベル（PUT、POST、DELETE）であり、バケットの設定やポリシー変更といったメタレベルのイベントを検出できません。
■ SCS試験で押さえておくべきポイント
| 観点 | 内容 |
|---|---|
| EventBridge のクロスアカウント転送 | 本番アカウント → セキュリティアカウントのイベントバスへイベントを送信可能。 |
| S3 設定変更の監視方法 | CloudTrail や EventBridge で「CreateBucket」や「PutBucketPolicy」などを検出可能。 |
| Lambda による自動検証 | バケットのタグ・ポリシーをチェックし、SNSなどで通知可能。 |
| GuardDuty と Trusted Advisor の違い | GuardDuty は脅威検知、Trusted Advisor はベストプラクティス確認用であり、設定変更検出には不向き。 |
| S3 イベント通知の限界 | S3 バケットレベルの構成変更は通知できないため、EventBridgeやCloudTrailの活用が必要。 |
他のクロスアカウント監視や自動修復系の問題もあれば、ぜひお送りください。SCS試験合格に向けて、重点分野を押さえましょう。
以下の形式で問題と解説を整理しました。
■ 問題文（そのまま）
ある企業は、セキュリティ監視戦略の一環として、すべてのリージョンで Amazon GuardDuty を有効にしています。VPC の 1 つで、会社は FTP サーバーとして機能する Amazon EC2 インスタンスをホストしており、複数の拠点から多数のクライアントがアクセスしています。GuardDuty は、毎時多くの接続が発生することから、これをブルートフォース攻撃として識別されます。
検出結果は誤検知としてフラグが立てられています。しかし、GuardDuty はこの問題を攻撃だと識別し続けています。セキュリティエンジニアは、脅威の識別能力の感度を改善するように依頼されました。エンジニアは、変更によって潜在的な異常な動作の可視性が損なわれないようにする必要があります。
この問題に対処する最適な方法を選択してください。
■ 選択肢（そのまま）
A: FTP サーバーがデプロイされているリージョンの GuardDuty で FTP ルールを無効にします。
B: 信頼できる FTP サーバーの IP アドレスを IP リストに追加し、GuardDuty にデプロイして、通知の受信を停止します。
C: 新しい発生が報告されるたびに検出結果を閉じる AWS Lambda 関数を作成します。
D: 自動アーカイブを有効にした GuardDuty フィルターを使用して、検出結果を終了します。
■ 正解の選択肢と解説
正解：D
理由：GuardDuty にはフィルター機能があり、特定の条件に一致する検出結果に対して「自動アーカイブ」を設定できます。これにより検出は維持しつつ、毎回アラートに対処しなくても済むようになり、誤検知のノイズを減らしつつ異常検出機能は維持できます。
■ 不正解の選択肢の理由
- A: ルールそのものを無効にすると、本物の攻撃の検知まで無効化される可能性があり、可視性が損なわれます。
- B: GuardDuty の IP リストは「信頼された送信元 IP（例：VPCフローのソースIPなど）」に対して使用されるもので、EC2（受信側）のIPを信頼リストに入れても意味がないため無効です。
- C: Lambda による自動クローズは可能ですが、管理と実装が煩雑で運用効率が悪いです。GuardDuty 本来の機能を活用すべきです。
■ SCS試験で押さえておくべきポイント
- GuardDuty の誤検知対応には「自動アーカイブ付きフィルター」が推奨される。
- IPリストの用途は送信元（攻撃元）の信頼設定であり、対象リソース（自社EC2）のIPには使えない。
- 脅威検知の可視性を損なわないようにしつつノイズを減らす対応が求められる。
必要であれば、自動アーカイブフィルターの設定例やCloudFormationテンプレートも提供できます。
以下の形式で問題を整理しました。
■ 問題文（文字列を編集せずに出力）
ある企業は最近、AWS 環境の年次セキュリティ評価を実施しました。その結果、監査ログが 90 日を超えて利用できないこと、IAM ポリシーの不正な変更が検知されずに行われていることが判明しました。
これらの問題を解決する最適な方法を選択してください。
■ 選択肢（文字列を編集せずに出力）
A.
Amazon S3 にロググループをエクスポートするように Amazon CloudWatch を設定します。リソースにポリシーが変更されたときに通知を提供するように AWS CloudTrail を設定します。
B.
AWS CloudTrail の証跡ログを 90 日後に Amazon S3 Glacier にアーカイブする Amazon S3 ライフサイクルポリシーを作成します。リソースにポリシーが変更されたときに通知を提供するように Amazon Inspector を設定します。
C.（正解）
Amazon S3 に監査ログを保存する AWS CloudTrail の証跡を作成します。リソースにポリシーが変更されたときに通知を提供するように AWS Config ルールを設定します。
D.
AWS CloudTrail ログをアーカイブするように AWS Artifact を設定します。リソースにポリシーが変更されたときに通知を提供するように AWS Trusted Advisor を設定します。
■ 正解の選択肢と解説
正解：C
- AWS CloudTrail の証跡により、S3 バケットにログを保存することで 90 日を超えた保持が可能です（CloudTrail コンソール上は直近90日分までしか閲覧不可）。
- AWS Config ルールを使用すれば、IAM ポリシーの変更など特定の構成変更が発生したときに 検知して通知できます。
■ 不正解の選択肢の理由
- A：CloudTrail は通知機能を持たない。 CloudWatch でロググループを S3 に出力しても、IAM ポリシーの変更通知には直結しません。
- B：Amazon Inspector はポリシー変更の検知はできない。 また、Glacier へのアーカイブだけでは閲覧性や即時性に欠け、通知にはつながりません。
- D：AWS Artifact は監査用レポート提供サービス。 CloudTrail ログのアーカイブには使用しませんし、Trusted Advisor は IAM ポリシーの具体的な変更は検知できません。
■ SCS試験で押さえておくべきポイント
- CloudTrail はデフォルトで90日間のイベント履歴提供。永続保存には S3 への証跡設定が必要。
- AWS Config はリソース変更検知、履歴追跡、通知機能を持つ。構成違反の検知には不可欠。
- CloudTrail は通知機能がないため、ConfigやEventBridgeなどと組み合わせる必要がある。
- Amazon InspectorやArtifactは役割が異なるため、設定変更監視には不適。
他の問題も続けてご提供いただければ、同じ形式で整理していきます。
以下の形式で問題を整理しました。
■ 問題文（文字列を編集せずに出力）
セキュリティエンジニアは、新しく設計された製品のログ記録ソリューションを開発中です。AWS CloudTrail をサポートしデバッグするために、システム管理者と開発者は、イベントログファイルに適切にアクセスする必要があります。
ログファイルを改ざんや不正アクセスから保護するための最適な対策の組み合わせを選択してください。(2 つ選択)
■ 選択肢（文字列を編集せずに出力）
A.
ログファイルの整合性の検証のメカニズムが有効であることを確認します。
B.
すべてのログファイルが、社内ネットワークからの SSH アクセスのみを許可する Amazon EC2 インスタンスに保存されていることを確認します。
C.
業務上知る必要のあるシステム管理者と開発者だけが、ログファイルを閲覧することはできるが、変更することはできないようにします。
D.
すべてのログファイルが同じアカウントの少なくとも 2 つの別々の Amazon S3 バケットに書き込まれていることを確認します。
E.
システム管理者と開発者がログファイルを編集できるようにし、それ以外のアクセスはできないようにします。
■ 正解の選択肢と解説
正解：A, C
A. ログファイルの整合性の検証のメカニズムが有効であることを確認します。
- CloudTrail の整合性検証機能を有効にすることで、ログファイルが改ざんされていないことを後から検証可能になります。
- SHA-256とRSA署名によって、検証可能なイミュータブルログを実現します。
C. 閲覧は可能だが変更は不可にする
- 最小特権の原則（PoLP）に基づき、必要なメンバーにのみ読み取り専用アクセスを与えるのがベストプラクティス。
- 改ざんリスクを防ぐ観点でも「読み取り専用」が重要。
■ 不正解の選択肢の理由
B. EC2インスタンスに保存
- CloudTrailログはS3への保存が基本設計。EC2で保存管理すると、耐久性や監査性が下がり、操作ミスやインスタンス障害の影響も大きくなります。
D. 別S3バケットに書き込む
- バケットを分けても改ざん・不正アクセスを防ぐ直接的効果はありません。整合性検証や適切なポリシーが必要です。
E. 編集を許可
- ログ改ざんリスクが高まり、セキュリティの原則に反します。ログは基本的に誰にも変更させてはいけません。
■ SCS試験で押さえておくべきポイント
- CloudTrailログはS3に保存、整合性検証を有効化して改ざん検出可能にする。
- IAMで読み取り専用アクセスを適切に制御し、最小権限の原則を遵守。
- EC2など可変性のあるリソースへのログ保存は避け、イミュータブルなS3保管＋検証を基本とする。
次の問題も続けてどうぞ。必要に応じて個別補足も可能です。
以下の形式で問題7を整理し、選択肢の正誤と理由を解説します。
■ 問題文
ある企業では、図のようにアカウントに複数の VPC があり、ピアリングされています。セキュリティエンジニアは、3 つの VPC すべてで Amazon EC2 インスタンスの侵入テストを実行したいと考えています。
これを達成させる最適な方法を選択してください。(2 つ選択)
■ 選択肢
A.
データセンターから VPC A への VPN 接続を作成します。オンプレミスのスキャンエンジンを使用して、3 つの VPC すべてのインスタンスをスキャンします。3 つの VPC すべてについて、ペネトレーションテスト (侵入テスト) のリクエストフォームに記入します。
B.
データセンターから 3 つの VPC のそれぞれに VPN 接続を作成します。オンプレミスのスキャンエンジンを使用して、各 VPC のインスタンスをスキャンします。ペネトレーションテスト (侵入テスト) のリクエストフォームへの記入は必要ありません。
C.
事前承認されたスキャンエンジンを AWS Marketplace から VPC B にデプロイし、それを使用して 3 つの VPC すべてのインスタンスをスキャンします。ペネトレーションテスト (侵入テスト) のリクエストフォームへの記入は必要ありません。
D.
事前承認されたスキャンエンジンを AWS Marketplace から各 VPC にデプロイし、その VPC 内のスキャンエンジンから各 VPC のインスタンスをスキャンします。ペネトレーションテスト (侵入テスト) のリクエストフォームへの記入は必要ありません。
E.
データセンターから 3 つの VPC のそれぞれに VPN 接続を作成します。オンプレミスのスキャンエンジンを使用して、各 VPC のインスタンスをスキャンします。3 つの VPC すべてについて、ペネトレーションテスト (侵入テスト) のリクエストフォームに記入します。
■ 正解の選択肢と解説
正解：B, D
B. データセンターから各VPCにVPN接続し、オンプレミスからスキャン
→ 正解
- 各VPCにVPN接続することで、VPCピアリングの非推移性の制限を回避できます。
- Amazon EC2の侵入テストは 事前承認不要なサービス のため、フォーム記入は不要。
D. 各VPCにスキャンエンジンをデプロイしてローカルスキャン
→ 正解
- 各VPCにローカルでスキャンエンジンを設置することで、VPCピアリングを経由せず安全かつ確実にスキャン可能。
- AWS Marketplaceの事前承認済みスキャンエンジンはフォーム不要。
■ 不正解の選択肢の理由
A. VPC A にのみ VPN接続して他VPCもスキャン
→ 誤り
- VPCピアリングは推移性がないため、VPC A 経由で VPC B/C に接続できません。
C. VPC B にスキャンエンジン1つだけ設置
→ 誤り
- 同様に、VPC B からピア接続を通じて VPC A/C をスキャンすることはできません（非推移）。
E. 正しい構成だが「リクエストフォームが必要」としている
→ 誤り
- Amazon EC2 に対する侵入テストは フォーム記入不要（公式ガイドで明記）。
■ SCS試験で押さえておくべきポイント
- VPCピアリングは非推移的（transitiveではない）
→ 直接の接続が必要（VPN, ENI, TGW など） - Amazon EC2 は事前申請なしで侵入テストが可能
- オンプレミス/Marketplace問わず、スキャンのネットワーク的到達性が重要
次の問題もお送りいただければ、同様に解説いたします。
