AWS Security Hub CSPMによる集約のシナリオ判断

集約画面に所見が来ない、標準のチェックが揃わない、表示上は解決でも資源が未修復といった事例を判断します。Security Hub表記の集約教材として、現行のSecurity Hub CSPMの範囲を扱います。

この単元で学ぶこと

1. 空の画面から始めない集約画面に所見がない場合、まず対象アカウントと地域、検出元の有効化、連携を調べます。問題がない可能性もありますが、入力が来ていない可能性もあります。「ゼロ件」だけを全資源の安全証明として報告しないよう、見ている範囲を記録します。

2. 集約先と生成元ホームリージョンに地域Bをリンクしても、地域BでSecurity Hub CSPMが無効なら期待するデータは集まりません。所見を作る地域の有効化と、集めて見る地域の設定を別に確認します。中央から設定を管理する仕組みを使う場合も、適用範囲を検証します。

3. 検出サービスの役割を追う GuardDutyの不審活動、Inspectorの脆弱性、Macieの機密データ等の所見は元サービスの結果です。集約を始めたことだけで各サービスの対象が全部有効になるとは判断しません。どの検出元の結果が必要かを決め、有効化・権限・地域等を確認します。

4. チェックの入力を確認する Configを利用するコントロールの対象資源が記録されていなければ、意図したチェックを行えません。標準を選んだことと、入力情報が揃って評価されたことは別です。Configの記録範囲とコントロールの対象条件を確認します。

5. スコアを事業へ説明するスコアは評価対象のコントロールの状態を整理する指標です。無効な確認項目や対象外の業務要件を含めて、自社が全規制に適合していると結論付けるものではありません。監査では対象範囲と自社統制の証跡を合わせ、どこまで確認できたか説明します。

6. 表示上の解決と実際の解決所見を抑制したりワークフロー状態を変更したりしても、脆弱なソフトウェアや広い通信許可が変更されるわけではありません。検出元の状況、実際の設定変更、再確認の結果を記録します。整理のための自動ルールと実修復の連携を分けて設計します。

7. 自動対応の証拠 EventBridgeで対応関数を呼び出せても、関数の権限不足や処理失敗があり得ます。イベントの到達、処理の実行結果、対象資源への反映を分けて確かめます。担当者へ通知できたことだけで自動修復完了とは報告しません。

8. 過去と現在を分ける有効化前の所見が自動的にすべて遡って集約されるわけではありません。監査で過去期間を求められたら、検出元や保存済みログ・所見の履歴を確認します。CSPMの現在の一覧と、過去全体の監査証跡の範囲を明確に区別します。

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。