以下に 問題1 を指定フォーマットで整理・解説します。
■ 問題文（文字列を編集せずに出力）
ある企業は、AWS アカウント全体にリソースとワークロードを安全にデプロイする必要があります。これらのアカウントは、AWS Organizations 内の組織に属しています。
企業は、承認されたアーキテクチャパターンの Infrastructure as Code (IaC) 管理に AWS CloudFormation を使用する必要があります。また、リソースとワークロードの構成と作成に関するタグ付け要件と特定のガイドラインを適用する必要があります。
これらの要件を満たすソリューションを選択してください。
■ 選択肢（文字列を編集せずに出力）
A.
AWS CodePipeline パイプラインを使用して、IaC で定義されたワークロードをテストし、CloudFormation を介してアカウントにデプロイします。AWS Config ルールを使用してタグ付け要件を強制します。SCP を適用して、すべての OU で誤って構成されたリソースが作成されないようにします。
B.
CloudFormation スタックポリシーを使用して、タグ付けまたは構成要件を満たさないリソースが作成されないようにします。Amazon EventBridge ルールを使用して、CloudFormation 外部でリソースを作成しようとする API コールを検出します。
C.
AWS Service Catalog を CloudFormation とともに使用して、承認されたアーキテクチャ構成へのアクセスを管理します。組織全体のアカウントに Service Catalog ポートフォリオをプロビジョニングします。AWS Config ルールを使用して、アカウント全体にタグ付け要件やその他のリソース構成ポリシーを適用します。
D.
IAM アクセス許可の境界を作成して、CloudFormation を介して誤って構成されたリソースが作成されないようにし、タグ付け要件を適用します。すべてのアカウントロールにアクセス許可の境界 (パーミッションバウンダリー) を適用します。AWS Config ルールを使用して、誤って構成された状態にある既存のリソースを識別します。
■ 問題文の要件の概要
- 組織内の複数アカウントで 安全にリソース・ワークロードをデプロイ
- 承認された アーキテクチャパターン に基づくデプロイを CloudFormation + IaC で管理
- タグ付け要件や構成ガイドラインを 強制的に適用
■ 正解の選択肢と解説
✅ C. AWS Service Catalog を CloudFormation とともに使用して、承認されたアーキテクチャ構成へのアクセスを管理します。組織全体のアカウントに Service Catalog ポートフォリオをプロビジョニングします。AWS Config ルールを使用して、アカウント全体にタグ付け要件やその他のリソース構成ポリシーを適用します。
解説：
- Service Catalog によって、企業が承認した CloudFormation テンプレート（プロダクト）を集めたポートフォリオを各アカウントに提供できる。
- この仕組みにより、利用者は 承認済みテンプレートのみから インフラを構築でき、アーキテクチャ統制が実現される。
- AWS Config により、タグ付けやその他のポリシーをアカウント横断で継続的にチェックできる。
■ 不正解の選択肢の理由
| 選択肢 | 誤っている理由 |
|---|---|
| A | CodePipeline は IaC デプロイ手段の一つであり、統制された構成管理機能は持たない。SCP は IAM アクションの制限には有効だが、リソースの構成内容を検査・強制する用途には向かない。 |
| B | CloudFormation スタックポリシーはリソースの 削除・変更 の保護用途。タグ付けや構成チェックには使えない。また EventBridge によるイベント検出は 受動的であり、予防策ではない。 |
| D | アクセス許可の境界（パーミッションバウンダリー）は IAM アクションの最大許容値を制限するだけで、構成の正当性（タグやガイドライン）までは管理できない。制御対象が違う。 |
■ SCS試験で押さえておくべきポイント
- ✅ AWS Service Catalog：
- CloudFormation ベースの承認済みテンプレートをカタログ化し、ユーザーに制御されたデプロイ手段を提供。
- 組織全体に統一された IaC 実装を強制できる。
- ✅ AWS Config マネージドルールは、タグや構成ポリシーの自動評価に最適。
- ✅ スタックポリシー・パーミッションバウンダリー・SCP などは役割が異なるため、選択肢の機能と制限を正確に把握する。
この問題は、CloudFormation による IaC ガバナンスをどう確立するかというセキュリティ/ガバナンスの本質を問う内容です。
Service Catalog + AWS Config の組み合わせは、統制された IaC とガバナンスの模範的な構成として押さえておきましょう。
以下に 問題2 を指定フォーマットで整理・解説します。
■ 問題文（文字列を編集せずに出力）
会社のポリシーに従って、すべての API キーを暗号化し、一元化されたセキュリティアカウントのソースコードとは別に保持する必要があります。このセキュリティアカウントは、会社のセキュリティ担当者が管理しています。ただし、監査により、API キーが AWS Lambda 関数のソースコードとともに DevOps アカウントの AWS CodeCommit リポジトリに保存されていることがわかりました。セキュリティチームは API キーをどのように安全に保持する必要がありますか？
■ 選択肢（文字列を編集せずに出力）
A. キーを暗号化するために Amazon S3 が管理する暗号化キーを使用したサーバー側の暗号化 (SSE-S3) を使用して、セキュリティアカウント内の Amazon S3 バケットに API キーを保存します。S3 キーの署名付き URL を作成し、AWS CloudFormation テンプレートの Lambda 環境変数で URL を指定します。Lambda 関数のコードを更新して、URL を使用してキーを取得し、API を呼び出します。
B. 暗号化のために AWS Key Management Service (AWS KMS) を使用して、セキュリティアカウントに CodeCommit リポジトリを作成します。開発チームに Lambda のソースコードをこのリポジトリに移行するように要求します。
C. セキュリティアカウントの AWS Secrets Manager でシークレットを作成し、暗号化に AWS Key Management Service (AWS KMS) を使用して API キーを保存します。Lambda 関数が使用する IAM ロールへのアクセスを許可して、関数が Secrets Manager からキーを取得して API を呼び出すことができるようにします。
D. Lambda 関数の暗号化された環境変数を作成し、暗号化に AWS Key Management Service (AWS KMS) を使用して API キーを保存します。Lambda 関数が使用する IAM ロールへのアクセスを許可して、関数が実行時にキーを復号化できるようにします。
■ 問題文の要件の概要
- APIキーは暗号化されている必要がある。
- APIキーはソースコードとは分離して管理する必要がある。
- 一元化されたセキュリティアカウントが管理すべき。
- DevOpsアカウントのCodeCommitにキーが含まれていたのは問題である。
■ 正解の選択肢と解説
✅ C. セキュリティアカウントの AWS Secrets Manager を使用し、KMS で暗号化して API キーを保存する
解説：
- Secrets Manager は、APIキーやパスワードなどのシークレット情報の保存・暗号化・取得・ローテーションに最適なサービス。
- KMS と統合して、保存時に自動暗号化される。
- Lambda関数には IAMロールでアクセス権限を付与すれば、実行時に安全に取得可能。
- ソースコードと物理的に分離され、かつ アクセス制御が厳格に管理できるため、要件をすべて満たす。
■ 不正解の選択肢の理由
| 選択肢 | 理由 |
|---|---|
| A | S3に保存し署名付きURLでアクセスするのは、キー管理が煩雑かつセキュリティリスクが高い。Secrets Manager のようにローテーション・監査などができないため不適切。 |
| B | CodeCommit はソースコード管理用のサービスであり、シークレットの保存には不適切。APIキーをリポジトリに保存してはならない。 |
| D | Lambda の環境変数に保存するのは、ある程度安全だが、Secrets Manager に比べて柔軟性・管理性が劣る。環境変数に直接キーを置くことは、セキュリティポリシー違反となりうる。 |
■ SCS試験で押さえておくべきポイント
- ✅ Secrets Manager はシークレット管理のベストプラクティス（暗号化、ローテーション、アクセス制御、監査ログに対応）
- ✅ APIキーなどの機密情報はソースコードや環境変数に直接含めず、外部管理し、実行時に取得する
- ✅ KMSと組み合わせた暗号化管理が重要
- ✅ IAM ロールでアクセス制御を細かく設定することが推奨される
- ❌ CodeCommitやS3はシークレット保存用ではない
この問題は、セキュリティのベストプラクティスと AWS サービスの適切な選定を問う典型的なシナリオであり、SCS試験では高頻度で出題されるテーマです。特に「Secrets Manager or not」はよく問われます。
以下に 問題3 を指定フォーマットで整理・解説します。
■ 問題文（文字列を編集せずに出力）
ある企業は、AWS Organizations 内の組織を使用して、Amazon EC2 インスタンスと VPC を分離しています。この企業は、開発ワークロードと本番ワークロードを分けるために、別々の OU を設定しています。
セキュリティエンジニアは、本番 OU 内の AWS アカウントのみが Amazon S3 バケットに VPC フローログを書き込めるようにする必要があります。セキュリティエンジニアは、S3 バケットポリシーの Condition 要素を設定し、VPC フローログの s3:PutObject アクションを許可するように構成しています。
この要件を満たすために、セキュリティエンジニアは Condition 要素をどのように設定しますか?
■ 選択肢（文字列を編集せずに出力）
A. aws:ResourceOrgPaths 条件キーの値を、本番 OU の Organizations エンティティパスに設定します。
B. aws:SourceOrgPaths 条件キーの値を、本番 OU の Organizations エンティティパスに設定します。
C. aws:ResourceOrgID 条件キーの値を組織 ID に設定します。
D. aws:SourceOrgID 条件キーの値を組織 ID に設定します。
■ 問題文の要件の概要
- 本番OU内のアカウントだけが
- S3バケットにVPCフローログをPutObjectできるように
- S3バケットポリシーのCondition要素で制御したい
■ 正解の選択肢と解説
✅ B. aws:SourceOrgPaths 条件キーの値を、本番 OU の Organizations エンティティパスに設定します。
解説：
aws:SourceOrgPathsは、リクエスト元のAWSアカウントが属するOUパスを評価する条件キーです。- バケットポリシーの
Conditionにこのキーを指定することで、特定のOU内のアカウント（本番OU）だけにs3:PutObjectを許可できます。 - エンティティパスは
"o-xxxxxx/r-ou-yyyyy"のような形式。
■ 不正解の選択肢の理由
| 選択肢 | 理由 |
|---|---|
| A. aws:ResourceOrgPaths | リソース（ここではS3バケット）が属するOUを指定する条件キー。アクセス元ではなく、対象リソース側に使用するため本件では不適切。 |
| C. aws:ResourceOrgID | 同様に、リソース側（S3）が属する組織IDを制御する条件キー。リクエスト元のアカウントを制限できない。 |
| D. aws:SourceOrgID | 組織ID全体を対象とするため、OU単位での制限ができない。今回のように「本番OUのみ許可」という条件には粒度が粗すぎる。 |
■ SCS試験で押さえておくべきポイント
- ✅ Organizations OU単位でアクセスを制御するには
aws:SourceOrgPathsを使う。 - ✅
aws:SourceOrgIDは「組織全体のID」、OU単位の制御には不向き。 - ✅
aws:ResourceOrgPaths/aws:ResourceOrgIDはリクエスト元ではなくリソース側の評価に使う。 - ✅ S3バケットポリシーの
ConditionでOUベース制御が可能になったのは比較的新しい（2023年）。 - ✅ 本番環境と開発環境の明確な分離管理はセキュリティの基本方針。
この問題は、AWS Organizations + S3バケットポリシーの組み合わせによる組織ベースの制御を問う問題で、実務上でも非常に重要な設定パターンです。条件キーの違いを確実に押さえておきましょう。
以下に 問題4 を指定フォーマットで整理・解説します。
■ 問題文（文字列を編集せずに出力）
ある企業が、Application Load Balancer (ALB) の背後にある Amazon EC2 インスタンスでパブリックウェブサイトをホストしています。このウェブサイトは、固有の User-Agent を持つ特定の IoT デバイスブランドによるグローバル DDoS 攻撃を受けています。
セキュリティエンジニアが AWS WAF を使用して、ウェブ ACL を作成し、ウェブ ACL を ALB に関連付けます。セキュリティエンジニアは、リクエストをブロックするために、ウェブ ACL の一部としてルールステートメントを実装する必要があります。このルールステートメントは、現在の攻撃および将来のこれらの IoT デバイスからの攻撃を軽減しつつ、正規のお客様のリクエストをブロックしないようにする必要があります。
これらの要件を満たすルールステートメントを選択してください。
■ 選択肢（文字列を編集せずに出力）
A. User-Agent からの IoT デバイスの IP アドレスを含む IP セット一致ルールステートメントを使用します。
B. 地理的一致ルールステートメントを使用します。IoT デバイスが配置されている国をブロックするようにステートメントを構成します。
C. レートベースのルールステートメントを使用します。IoT デバイスからのリクエスト数に等しいレート制限を設定します。
D. User-Agent からの IoT デバイスブランドの詳細を含む文字列一致ルールステートメントを使用します。
■ 問題文の要件の概要
- User-Agent が固有な特定のIoTデバイスによるDDoS攻撃が発生
- 正規のユーザーをブロックせずに防御したい
- 現在と将来の攻撃の両方に対応可能なルールをAWS WAFに設定する必要がある
■ 正解の選択肢と解説
✅ D. User-Agent からの IoT デバイスブランドの詳細を含む文字列一致ルールステートメントを使用します。
解説：
- AWS WAFでは、User-Agentヘッダーに含まれる固有の文字列にマッチさせることで、特定のIoTデバイスからのリクエストを識別可能。
- 「文字列一致ルールステートメント（String Match Statement）」を使えば、特定のブランドのUser-Agent文字列を検出してブロックできます。
- IPアドレスや国単位の制御と比べて、誤検知が少なく、正規ユーザーへの影響を避けられる精度の高い制御が可能です。
■ 不正解の選択肢の理由
| 選択肢 | 理由 |
|---|---|
| A. IPセット一致ルール | IoTデバイスのIPは頻繁に変わる動的IPが多く、IPリストの維持が困難で効果的でない。 |
| B. 地理的一致ルール | 攻撃元の国全体をブロックすると、その国の正規ユーザーまで排除してしまうリスクがある。 |
| C. レートベースルール | リクエスト数に基づく制限では、正規ユーザーと攻撃者の挙動が似ている場合に誤ブロックが発生する可能性がある。 |
■ SCS試験で押さえておくべきポイント
- ✅ User-Agent 文字列に基づくフィルタリングは、特定ブランドやデバイスを識別しやすく、セグメントされたブロックに向いている。
- ✅ AWS WAFの文字列一致ルールは、ヘッダー、URI、クエリ文字列などから検索可能。
- ✅ IPや国単位でのブロックは粗い制御となり、誤検知のリスクが高いため、精度が求められる場面では避ける。
- ✅ DDoS対策にはAWS Shieldもあるが、本問はアプリケーションレイヤのWAF対策に焦点を当てている。
この問題は、WAFのフィルタリング精度とブロック戦略に関する実践的な理解を問うものです。User-Agentヘッダーを活用したルール構成は、軽量で持続可能なDDoS対策の第一歩として非常に有効です。
以下に 問題5 を指定フォーマットで整理・解説します。
■ 問題文（文字列を編集せずに出力）
ある企業は、外部コンサルタントを雇用しました。コンサルタントは、企業の VPC にアクセスするためにノートパソコンを使用する必要があります。具体的には、同じ AWS リージョン内でピアリングされた 2 つの VPC へのアクセスが必要です。企業は、これらの VPC へのアクセスを提供しつつ、他のネットワークリソースへの不要なアクセスは許可しないようにしたいと考えています。
これらの要件を満たすソリューションを選択してください。
■ 選択肢（文字列を編集せずに出力）
A. VPC と同じリージョンに AWS Site-to-Site VPN エンドポイントを作成します。適切なサブネットと承認ルールを使用してアクセスを設定します。
B. AWS アカウントを作成します。AWS Resource Access Manager の VPC 共有機能を使用して、コンサルタントが VPC にアクセスできるようにします。
C. VPC と同じリージョンに AWS Client VPN エンドポイントを作成します。適切なサブネットと承認ルールを使用してアクセスを設定します。
D. VPC と同じリージョンにゲートウェイ VPC エンドポイントを作成します。適切なサブネットと承認ルールを使用してアクセスを設定します。
■ 問題文の要件の概要
- 外部コンサルタントが ノートパソコンから企業のAWS環境にアクセスする必要がある
- アクセス対象は 2つのピアリングされたVPC
- 他のリソースにはアクセス させたくない（アクセス制御が必要）
- セキュアなリモートアクセス手段が求められる
■ 正解の選択肢と解説
✅ C. VPC と同じリージョンに AWS Client VPN エンドポイントを作成します。適切なサブネットと承認ルールを使用してアクセスを設定します。
解説：
- AWS Client VPN は、ユーザーのノートパソコンなどのクライアント端末から OpenVPN を使って AWS VPC に安全に接続できるサービス。
- アクセス対象を 認証ルールやセキュリティグループで制御できるため、「2つのVPCにのみアクセス可」といったニーズに合致。
- ピアリングされていれば、Client VPN を1つのVPCに関連付ければ、もう1つのVPCにもルート設定でアクセス可能。
■ 不正解の選択肢の理由
| 選択肢 | 理由 |
|---|---|
| A. Site-to-Site VPN | これは オンプレミスのネットワーク（例:企業拠点）とVPCをつなぐためのVPN。ノートパソコンのようなクライアント端末からの直接接続には適していない。 |
| B. AWS RAM (VPC共有) | AWS RAMのVPC共有は他のAWSアカウントとのVPCリソース共有機能であり、外部からのネットワーク接続を提供する仕組みではない。 |
| D. ゲートウェイ VPC エンドポイント | これはS3やDynamoDBなどの特定のAWSサービスにプライベートアクセスを提供するもの。VPNのようなリモートアクセス手段にはならない。 |
■ SCS試験で押さえておくべきポイント
- ✅ AWS Client VPN は、外部ユーザーやコンサルタントが AWS 内のVPCにセキュアにアクセスする標準的な方法。
- ✅ アクセス制御は承認ルールとセキュリティグループを組み合わせて行う。
- ✅ ピアリングされたVPCへのアクセスも、ルートとセキュリティ設定により有効にできる。
- ✅ Site-to-Site VPN や VPCエンドポイントは、それぞれ用途が限定されている（オンプレ用、特定AWSサービス用など）。
- ✅ AWS RAMはIAMやネットワークアクセスを直接制御するものではない。
この問題は、セキュアなリモートアクセス設計とAWSネットワーク構成の理解が問われています。Client VPNの特性と他のネットワーク手段との違いを明確に理解しておきましょう。
以下に 問題6 を指定フォーマットで整理・解説します。
■ 問題文（文字列を編集せずに出力）
ある企業が、Application Load Balancer (ALB) の背後にある Amazon EC2 インスタンスのフリートでアプリケーションを実行しています。セキュリティエンジニアは、VPN を使用せずにアプリケーションへの安全なアクセスを提供する必要があります。ユーザーは、定義されたデバイスポスチャー (端末のセキュリティ状態や構成情報を評価する指標) などの特定のセキュリティ条件を満たしている場合にのみ、アプリケーションにアクセスできる必要があります。
これらの要件を満たすソリューションを選択してください。
■ 選択肢（文字列を編集せずに出力）
A. Amazon Verified Permissions を構成します。ポリシーベースのアクセス制御 (PBAC) ポリシーを使用して、承認を実行します。
B. AWS Verified Access を構成します。ALB のエンドポイントを作成して、アプリケーションを追加します。
C. AWS WAF を使用して、ウェブ ACL を作成します。定義されたデバイスポスチャと一致しないトラフィックをブロックするようにカスタム応答を構成します。
D. Amazon Verified Permissions を構成します。ALB のエンドポイントを作成して、アプリケーションを追加します。
■ 問題文の要件の概要
- VPNなしで安全にアクセスさせたい
- ALBの背後にあるEC2のWebアプリケーションが対象
- デバイスポスチャ（セキュリティ状態）に基づくアクセス制御が必要
■ 正解の選択肢と解説
✅ B. AWS Verified Access を構成します。ALB のエンドポイントを作成して、アプリケーションを追加します。
解説：
- AWS Verified Access は、ゼロトラストモデルに基づいて、VPNを使わずにアプリケーションへの安全なアクセスを提供するサービスです。
- デバイスポスチャ（例えば、ウイルス対策の有無やOSバージョンなど）とユーザーのID情報などのコンテキストに基づいたアクセス許可の制御が可能です。
- Application Load Balancer（ALB）とも統合できるため、ALBの背後にあるアプリケーションに対してアクセスルールを適用可能です。
■ 不正解の選択肢の理由
| 選択肢 | 誤っている理由 |
|---|---|
| A. Verified Permissions + PBAC | Verified Permissions は**アプリケーション内のアクセス制御（認可）**に使うサービスで、ALB やデバイスポスチャとは無関係。 |
| C. AWS WAF | WAF はリクエストのIP、User-Agent、パラメータ等による制御は可能だが、デバイスポスチャ（セキュリティ状態）を評価する機能はない。 |
| D. Verified Permissions + ALB | Verified Permissions はALBに関連付ける仕組みがないため、ALBの背後のアクセス制御には使えない。デバイスポスチャの評価も不可。 |
■ SCS試験で押さえておくべきポイント
- ✅ AWS Verified Access は、VPN不要でゼロトラスト型アクセスを提供するAWSサービス。
- ✅ デバイスポスチャやIDベースの認可を使って細かなアクセス制御が可能。
- ✅ Verified AccessはALBやNetwork Load Balancerと統合可能で、ロードバランサーエンドポイント経由でアクセス制御が行える。
- ❌ Amazon Verified Permissions は、アプリケーション内部の認可ロジックの管理用であり、ネットワークアクセス制御には使えない。
- ❌ AWS WAF では、デバイスポスチャなどの端末状態を評価することはできない。
この問題は、AWSのアクセス制御系サービスの違いを問う代表的なゼロトラスト系設問です。Verified Access の特徴をしっかり押さえましょう。
以下に 問題7 を指定フォーマットで整理・解説します。
■ 問題文（文字列を編集せずに出力）
あるセキュリティエンジニアが、Amazon EC2 インスタンス全体に広がっているマルウェア感染を調査しています。侵害の主要な指標は、インターネット上のコマンド & コントロール (C2) ホストへの TCP ポート 2905 を使用した外向きのトラフィックです。
セキュリティエンジニアは、特定されたアウトバウンドトラフィックを拒否するネットワーク ACL ルールを作成し、このルールを EC2 インスタンスが存在するサブネットに適用しました。セキュリティエンジニアは、TCP ポート 2905 で通信を試みている EC2 インスタンスを特定する必要があります。
影響を受ける EC2 インスタンスを、最も少ない運用工数で特定できるソリューションを選択してください。
■ 選択肢（文字列を編集せずに出力）
A. Amazon GuardDuty を有効にします。カスタム GuardDuty IP リストを作成し、EC2 インスタンスがコマンド & コントロール (C2) ホストの 1 つと通信しようとしたときに検出結果を作成します。Amazon Detective を使用して、通信を開始する EC2 インスタンスを特定します。
B. Amazon VPC Network Access Analyzer でネットワークアクセススコープを作成します。ネットワークアクセススコープを使用して、TCP ポート 2905 にトラフィックを送信しようとする EC2 インスタンスを特定します。
C. 影響を受ける EC2 インスタンスが配置されている VPC の VPC フローログを有効にします。拒否されたトラフィックをキャプチャするようにフローログを設定します。フローログで、宛先 TCP ポートが 2905 である REJECT レコードを検索します。
D. AWS Network Firewall でファイアウォールを作成し、EC2 インスタンスのサブネットにアタッチします。TCP ポート 2905 のファイアウォールからのトラフィックを識別してログに記録するカスタムルールを作成します。TCP ポート 2905 のトラフィックを参照するファイアウォールログを識別する Amazon CloudWatch Logs メトリクスフィルターを作成します。
■ 正解の選択肢と解説
✅ C. VPC フローログで、宛先 TCP ポートが 2905 である REJECT レコードを検索する
解説：
- VPC フローログ（VPC Flow Logs） は、VPC 内のネットワークトラフィック（許可・拒否両方）を記録する仕組みです。
- 今回、セキュリティエンジニアは ネットワークACLでTCP 2905を拒否しているため、このトラフィックは
REJECTとしてフローログに記録されます。 - 宛先ポート2905で
REJECTされたログを検索すれば、マルウェアによって外部通信を試みているEC2インスタンスのIPアドレスを特定可能です。 - 導入・設定が簡易かつ既存の構成に影響を与えず、ログベースで調査可能なため「最も少ない運用工数で特定できる」条件に合致します。
■ 不正解の選択肢の理由
| 選択肢 | 誤りの理由 |
|---|---|
| A. GuardDuty + Detective | GuardDutyは マルウェアの兆候は検出できても、特定ポートの拒否トラフィックのログを取る機能はない。DetectiveはGuardDutyの調査支援ツールであり、VPC ACLのREJECT状況は扱えない。 |
| B. VPC Network Access Analyzer | これはネットワークの構成ミス検出や意図しない経路を可視化するためのツールであり、実トラフィックのログを取得することはできない。リアルタイムな調査には使えない。 |
| D. AWS Network Firewall | 正しく使えば検出可能だが、新たなファイアウォールの設計・設定・サブネットアタッチが必要で、「運用工数が最も少ない」という条件に反する。また、CloudWatch Logsやメトリクスフィルターの設定も追加工数になる。 |
■ SCS試験で押さえておくべきポイント
- ✅ VPCフローログは、VPC内の通信（許可/拒否）の詳細をキャプチャ可能で、セキュリティ調査に不可欠なログソース。
- ✅ REJECTログをフィルタリングすることで、ACLやセキュリティグループで拒否された通信も特定できる。
- ❌ GuardDuty は異常な振る舞いを検出するが、特定ポート拒否通信の調査には使えない。
- ❌ Network Access Analyzer は構成チェックツールで、トラフィックログは扱わない。
- ❌ AWS Network Firewall は効果的だが、設定・構築の運用負荷が高いため、今回は不適。
この問題は、「どのサービスがトラフィックログを最も手軽に記録・分析できるか」という点にフォーカスした出題です。VPCフローログの使いどころを押さえておきましょう。
