AWSで最初に有効化すべきCSPM基準はこれだけ ― CIS AWS Foundations入門
CSPM を触り始めたとき、
真っ先に有効化すべき基準はどれか。
結論はシンプルです。
CIS AWS Foundations Benchmark だけでよい。
本執筆は
AWS Security Hub CSPM 有効化設計の教科書 CIS / NIST / PCI をどう選ぶか
の補足資料です。
1. なぜCISだけは必ず有効化すべきなのか
CIS は「理想論」ではありません。
- CloudTrail が有効か
- Root に MFA が付いているか
- S3 がパブリックになっていないか
といった、
実際に事故が起きる「現場の設定ミス」だけを集めた基準です。
2. CISがカバーしている“現場で一番事故る設定”
CIS が扱っている項目は、単なる「設定のベストプラクティス」ではありません。
多くは 実際にインシデントにつながった事例をベースに作られたものです。
例えば以下のような設定は、
「分かっている人にとっては当たり前」ですが、
新規構築・移行直後の環境では非常に高い確率で抜け落ちます。
| 項目例 | 起きやすい事故 |
|---|---|
| CloudTrail が一部リージョンで無効 | 侵入経路を追えず原因究明不能 |
| Root アカウントに MFA 未設定 | 認証情報漏えいで即全アカウント侵害 |
| S3 がパブリック | 個人情報や設定ファイルの流出 |
| Security Group が 0.0.0.0/0 | 管理ポートが世界公開状態 |
| IAM ロールの過剰権限 | 侵入後に被害が一気に横展開 |
これらはすべて、
「攻撃者が最初に狙うポイント」でもあります。
3. CSPMが実際に見ている具体チェック項目
多くの CSPM 製品は、内部的には
CIS の文章をそのままルール化していると考えて差し支えありません。
例えば
CloudTrail is enabled in all regionsEnsure MFA is enabled for the root accountS3 buckets are not publicly accessible
といった CIS の項目は、
CSPM 側では
- API を叩いて設定値を取得
- 設定が基準に合致しているかを判定
- NG ならアラート発報
という形で完全に機械判定されています。
つまり CIS は、
「人がレビューしなくても安全かどうかを判断できるレベルまで落とし込まれた基準」
なのです。
4. よくある誤解：「CIS＝セキュリティのすべて」ではない
CIS は非常に優秀ですが、
これを有効化した瞬間にセキュリティが完成するわけではありません。
CIS が見ているのは、あくまで
- AWS の設定が
- 事故を起こしやすい状態になっていないか
という 「入口の安全確認」 です。
- アプリケーションの脆弱性
- データの持ち出し(アウトバウンド通信制御)
- 内部不正
といった領域は、CIS の守備範囲外です。
だからこそ、
CISは「土台」であって「完成形」ではない
この認識を持たずに導入すると、
「CISは入っているのに事故が起きた」という
最もつらい状態に陥ります。