AWS SCS サンプル問題

正解：C

A　GuardDutyにはS3 Protectionがあり、S3のデータイベントを解析して異常なアクセスパターンを検出できる。S3が対象外という前提が誤り

B　GuardDutyのS3 Protectionが解析するのはCloudTrailのS3データイベントであり、S3サーバーアクセスログではない。サーバーアクセスログを有効にしても検出結果は増えない

C（正解）　正解。S3 Protectionは個別に有効・無効を切り替えられる保護プランで、これが無効だとS3のデータイベントは解析対象にならない

D　Object Lockは書き込み保護の機能で、脅威検出の可否とは無関係。GuardDutyの解析対象や検出能力には影響しない

正解：A

A（正解）　正解。対象インスタンスのEBSボリュームからレプリカを作成してGuardDuty側でスキャンするため、インスタンス上にエージェントを常駐させる必要がなく本番ワークロードへの影響も小さい

B　実現はできるがエージェントの配布・更新・スキャン中の負荷という運用コストが発生し、インスタンス性能に影響を与えたくないという制約にも反する

C　Inspectorが検出するのはソフトウェアの脆弱性やネットワーク到達性、コード上の問題であり、マルウェアそのもののシグネチャ検査は行わない

D　Macieが対象とするのはS3上の機密データの検出であり、EBSボリュームもマルウェアも対象外である

正解：B・C

A　証拠となるファイルやタイムスタンプが失われ、攻撃の経路や範囲が追えなくなる

B（正解）　正解。外部との通信を止めつつ、メモリ上の揮発性の情報を失わずに調査を進められる

C（正解）　正解。本番環境に手を加えずに解析でき、解析作業による証拠の汚染も避けられる。暗号化キーの共有許可も併せて必要になる

D　メモリ上の情報が失われ、攻撃者の痕跡も消える。侵害の原因が残っていれば再び悪用される

E　証拠が完全に失われる。復旧を優先する場合でも証拠保全の後に行うべきである

正解：A・C

A（正解）　正解。侵害の判明後に設計から始めると封じ込めが遅れるため、隔離の手段と解析の場は平時に用意して手順を確認しておく

B　有効化した時点より前の記録は残らないため、最も知りたい侵害前後の挙動が失われる。ログは平時から取得しておく必要がある

C（正解）　正解。平時は使わない強い権限を用途と主体を限って用意し、利用そのものを検知できるようにしておくことで、緊急時の初動と事後の説明責任を両立できる

D　判断のばらつきと対応の遅れを招く。想定される事案ごとに手順を用意し、訓練で検証しておくのが基本になる

E　メモリやインスタンスストア上の証拠が失われ、原因究明が不可能になる。証拠保全を経てから復旧するのが原則である

正解：B

A　集約自体はできるが、各アカウントの管理者が自分の証跡を停止・削除できてしまい、改ざん耐性の要件を満たさない。新規アカウントへの適用も自動化されない

B（正解）　正解。組織の証跡はメンバーアカウント側から変更・削除できず、組織に追加されたアカウントも自動的に記録対象となるため、両方の要件を同時に満たす

C　削除は防げても停止や設定変更を個別に禁止する必要があり、証跡の作成漏れも起きる。新規アカウントの自動適用も別途仕組みが必要になる

D　イベントデータストアを作るだけでは他アカウントのイベントは入らない。組織単位で収集する設定が別途必要になる

正解：D

A　管理イベントの読み取りに含まれるのは設定参照系のAPIで、オブジェクトの取得は記録されない

B　サーバーアクセスログでもオブジェクトアクセスは追えるが、配信がベストエフォートで遅延があり、IAM主体の情報も限定的なため監査用途としては弱い

C　抽出は可能だが、全バケットのデータイベントを記録するためログ量とコストの制約に反する

D（正解）　正解。高度なイベントセレクタはリソースARNやイベント名で記録対象を絞り込めるため、必要なバケットだけを記録してログ量とコストを抑えられる

正解：A

A（正解）　正解。ログファイル検証を有効にすると各ログのハッシュを含む署名付きダイジェストファイルが定期的に出力され、ファイルの変更・削除の有無を後から検証できる

B　上書きからの復元には有効だが、ファイルが改ざんされていないことをAWSの署名で証明する手段にはならない

C　アクセスの記録は残るが、個々のログファイルの内容が元のままであることの証明にはならない

D　暗号化は機密性を守る仕組みで、完全性の検証手段ではない。復号できる権限があれば書き換えたうえで再暗号化もできてしまう

正解：C

A　Insightsは通常と異なる呼び出し量を検出する機能で、任意条件での履歴検索の代替にはならない

B　検索性は高まるが、5年分のインデックス維持のコストとクラスターの運用が新たに発生し、手間を減らす方向とは言い難い

C（正解）　正解。CloudTrail Lakeはイベントを構造化して保持し、テーブル定義やパーティション管理なしにSQLで長期の履歴を検索できる

D　検索はできるが、ロード処理の実装とクラスターの運用が増えるため、管理負担を減らしたいという目的に逆行する

正解：B

A　対象を事前に決められないという前提と矛盾する。網羅的な列挙は現実的でなく、維持も困難である

B（正解）　正解。Insightsは通常の呼び出しパターンをベースラインとして学習し、書き込みAPIの呼び出し量やエラー率が逸脱したときにイベントを生成するため、対象APIを事前に指定する必要がない

C　コストの変化は遅れて現れ、API呼び出し量と直結もしない。セキュリティ検知の手段としては不適切である

D　Configが記録するのは対応リソースの構成変更に限られ、読み取り系や非対応サービスのAPIの急増は捉えられない

正解：B

A　台数変動には耐えるが、同じサブネットに別の用途のリソースが配置されると意図しない通信まで許可される。層の境界を正確に表現できない

B（正解）　正解。セキュリティグループを送信元に指定すれば、そのグループに属するインスタンスが増減してもルールの変更が不要で、層の境界を論理的に表現できる

C　ネットワークACLはステートレスで戻り方向のエフェメラルポートの管理が必要になるうえ、セキュリティグループを全許可にすると多層防御が失われる

D　台数が変わるたびにルールの追加・削除が必要で運用負荷が高く、ルール数の上限にも当たりやすい

正解：C

A　拒否ルールがない点は正しいが、ネットワークACLはステートレスであるという基本を取り違えている

B　外部からの攻撃を止めるなら受信ルールでの拒否が中心になる。送信ルールだけでは受信を止められない

C（正解）　正解。ネットワークACLはルール番号の小さい順に評価され、拒否ルールを書ける唯一のレイヤーとしてサブネット単位の遮断に使える。番号順の設計が要点になる

D　WAFはHTTP/HTTPSを扱うレイヤーで、対象がWeb以外の通信を含む場合には適用できない。ネットワークACLで遮断できるという前提も誤っている

正解：D

A　セキュリティグループのルールで指定できるのはIPアドレス範囲やセキュリティグループなどで、ドメイン名は指定できない

B　IPアドレスが頻繁に変わる前提では維持できない。ルール数の上限にも当たりやすい

C　通信の制限にならないどころか、インスタンスをインターネットへ露出させる危険な変更である

D（正解）　正解。Network Firewallはドメイン名によるフィルタリングに対応しており、IPアドレスの変動に影響されずに許可対象を表現できる。出口を1か所に集約する設計とも相性が良い

正解：C

A　セキュリティグループを送信元に指定できるのは、そのグループに属するENIからの通信を許可する用途である。グループに属さない社外拠点のCIDRを間接的に参照する使い方はできない

B　ネットワークACLはステートレスで戻り方向の管理が必要になるうえ、セキュリティグループを全許可にすると多層防御が失われる

C（正解）　正解。参照先のプレフィックスリストを1か所更新すれば、それを参照するすべてのセキュリティグループへ反映されるため、拠点の増減に個別の修正が不要になる。ほかのアカウントへ共有して使わせることもできる

D　セキュリティグループのルールに書かれたCIDRの値を判定できる条件キーは用意されていないため、ルールの中身を根拠にした予防的な拒否は表現できない

正解：C

A　インスタンスをインターネットへ露出させることになり、セキュリティ上の後退である。接続内容の記録も残らない

B　経路の保護にはなるが、鍵の管理は残り、OS内での操作記録も別途仕組みが必要になる。踏み台の課題の一部しか解消しない

C（正解）　正解。受信ポートも鍵も不要で、IAMで接続権限を制御でき、セッションの操作内容をログとして残せる。踏み台の維持コストもなくなる

D　シリアルコンソールは障害復旧向けの手段で、日常の運用アクセスの代替としては機能や記録の面で不適切である

正解：B

A　ピアリングはCIDRが重複していると確立できず、また経路とセキュリティグループの設定次第で他リソースへの到達余地が残る

B（正解）　正解。PrivateLinkによる接続はCIDRの重複に影響されず、公開したサービスにのみ到達できるため、他リソースへのアクセスを構造的に遮断できる

C　CIDR重複の問題が残り、顧客同士や自社ネットワークとの経路設計も複雑になる。外部顧客との接続には過剰である

D　通信がインターネットを経由し、顧客のIP変更のたびに設定が必要になる。プライベート接続を求める要件にも合わない

正解：C

A　許可の広さが拒否を上書きすることはない。評価の基本原則を取り違えている

B　識別ベースのポリシーがリソースベースのポリシーの明示的な拒否を上書きすることはない

C（正解）　正解。どのポリシー種別であっても明示的な拒否が1つでもあれば最終結果は拒否になる。明示的拒否は評価の最初に判定され、他の許可では覆せない

D　ポリシーの更新時刻が評価に影響することはない。そのような優先規則は存在しない

正解：B

A　事後の是正であり、検知までの間は過大な権限が有効なままになる。予防的な統制になっていない

B（正解）　正解。許可境界は作られるロールが行使できる権限の上限を定め、境界の付与を条件にすることで境界なしのロール作成そのものを防げる

C　特定のポリシー名を拒否しても、同等の権限を持つ独自ポリシーを作られると回避される

D　ロールを自由に作らせたいという前提が成立しなくなる

正解：D

A　1つのロールに集約する方針に反し、長期認証情報の管理という重い課題を抱え込む

B　同時に複数の利用者が存在する環境では競合し、書き換えの遅延で誤った権限が付与される危険がある

C　アプリの実装に不備があれば他利用者のデータへ到達できる。権限の境界がAWS側で担保されない

D（正解）　正解。セッションポリシーはロールの権限とセッションポリシーの重なりだけを有効にするため、共通ロールを保ちながらセッション単位の最小権限が実現できる

正解：A

A（正解）　正解。NotActionを許可と組み合わせると列挙外のすべてが許可対象になる。禁止を表現したいのであれば明示的な拒否で書くべきである

B　NotActionは識別ベースのポリシーでも使用でき、無効になるわけではない

C　サイズ上限とNotActionの使用に直接の関係はない

D　NotActionは対象の指定方法であって、効果を拒否に変える働きはない

正解：C

A　プロジェクトの増加に比例してポリシーが増え、リソース追加のたびに更新が必要になる。避けたい運用そのものである

B　分離の観点では強力だが、同一アカウントを共有するという前提を変える大きな移行を伴い、要件への回答としては過剰である

C（正解）　正解。プロジェクトが増えてもタグを付けるだけで済み、ポリシーの追加や書き換えが不要になる。タグ付けの統制を併せて設計する必要がある

D　管理対象が最も増える方式で、要望と正反対の運用になる

正解：B

A　管理者は自らのIAMポリシーを変更できるため、識別ベースの制限だけでは限定が保証されない

B（正解）　正解。KMSではキーポリシーが権限の基点であり、そこで許可されていない主体はIAMポリシーの記述だけでは操作できない。委任を許す記述を絞ることで利用主体を限定できる

C　利用主体の限定にならず、有効化している間は誰でも権限があれば使える。運用も現実的でない

D　属性による制御は補助的な手段で、キーポリシーが権限の基点であるという原則は変わらない

正解：C

A　都度の書き換えが必要で、複数の委譲が並行すると衝突しやすい。書き換えの取り消し漏れも起きる

B　エイリアスは参照用の別名で、権限を分離する仕組みではない

C（正解）　正解。グラントはキーポリシーを変更せずに一時的で限定的な権限を委譲でき、取り消しによって即座に権限を失わせられる。多数の一時的な委譲を扱う用途に適している

D　長期の認証情報が増え、期間を限定した委譲という要件にも合わない

正解：D

A　既存の単一リージョンキーを後からマルチリージョンキーへ変換することはできない。作成時に選択する属性である

B　権限の付与はできるが、復号のたびに元リージョンのKMSへ依存する構成が残り、要望に反する

C　KMSで生成したキーマテリアルをエクスポートすることはできない

D（正解）　正解。マルチリージョンキーは同じキーマテリアルを持つため、一方で暗号化したデータを他方で復号でき、リージョン間の依存を持たずに処理を継続できる

正解：A

A（正解）　正解。インポートしたキーマテリアルであれば原本を自社で保持でき、有効期限の設定や必要時の削除による無効化も自社の判断で行える。自動ローテーションが使えない点は運用設計で補う

B　KMSが生成したキーマテリアルはエクスポートできないため、この運用は成立しない

C　AWS管理キーはキーポリシーを編集できず、鍵の生成を自社管理下で行うという要件も満たさない

D　鍵を平文でストレージへ置くことになり、保護の観点で大きく後退する

正解：B

A　S3やEBSの標準的な暗号化統合はCloudHSMのAPIを直接利用する構成に対応しておらず、アプリケーション側の作り込みが大量に発生する

B（正解）　正解。鍵はCloudHSMのクラスターに保管されつつ、利用側はKMSのキーとして扱えるため、サービス統合をそのまま活かして規制要件に対応できる

C　AWS管理キーのキーマテリアルを別の場所へ保管する仕組みはなく、要件も満たさない

D　マルチリージョンキーはリージョン間での利用のための機能で、単一テナントのハードウェアという要件とは無関係である

正解：C

A　分離の助けにはなるが、サービスによってはタグでの制御に限界があり、課金や上限も共有されたままで、事故の波及を構造的には防げない

B　ネットワークの分離は進むが、IAMや上限、課金は共有されたままで、権限分離という中心的な課題が残る

C（正解）　正解。アカウントは権限・課金・サービス上限の境界であり、分割によって事故の波及範囲を構造的に限定できる。組織単位ごとの統制もSCPで表現できる

D　リージョンは権限の境界ではないため、同じ認証情報で操作できてしまい分離にならない

正解：B

A　管理アカウントを日常運用に使わない方針に反し、影響範囲の大きい権限を広く配ることにもなる

B（正解）　正解。委任管理者の仕組みはサービスごとに登録でき、管理アカウントを使わずに組織全体の有効化・設定・集約を実施できる

C　アカウント数に比例して手間が増え、検出結果の集約も実現しない。一元管理という目的に合わない

D　参照はできるが、組織全体の有効化や設定の一元管理はできず、対応状況の管理機能も失われる

正解：D

A　検知には有効だが、タグなしでの作成そのものは防げず、キー名の表記ゆれの統制にもならない

B　作成の拒否はできるが、キー名の正しい表記を組織として定義する仕組みは別に必要である

C　人手の運用に依存するため徹底できず、規模が大きくなるほど守られなくなる

D（正解）　正解。タグポリシーが表記ゆれを含む定義の統制を担い、SCPが作成時の必須化を担う。役割の異なる2つの仕組みを組み合わせることで要件を満たせる

正解：A

A（正解）　正解。組織単位を対象にした展開では、新しく追加されたアカウントにもスタックが自動的に作成されるため、個別の作業が不要になる

B　手作業が残り、新規アカウントへの適用漏れが避けられない

C　SCPは操作の許可・拒否を表現する仕組みで、リソースを作成する働きはない

D　IAMロールやConfigの設定は各アカウントに存在する必要があり、参照で代替できるものではない