CSPMからCNAPPへ: クラウド全体のポスチャ管理

なぜポスチャ管理が必要なのか

AWS・Azure・GCPを横断して数百〜数千のリソースを運用していると、IAMポリシー・ネットワーク設定・ストレージの公開設定・暗号化設定など、手動で追い切れないほどの設定項目が発生します。CSPMは、これらの設定をCIS Benchmarksのようなベースラインと突き合わせて継続的にスキャンし、逸脱を「ファインディング」として検出するツール群です。

CSPM/CNAPPの典型的なアーキテクチャ

CSPMはAPI経由の読み取り専用アクセスで各クラウドアカウントをスキャンし、結果をファインディングデータベースに蓄積します。CNAPPでは、これにCWPP(ワークロードの脆弱性・不審なプロセス検知)やCIEM(過剰なIAM権限の可視化)の結果を統合し、単一のリスクスコアとして評価した上でチケット化・自動修復ワークフローへ渡します。

「Risk Prioritization」の段階がSecurity Gateです。ここでリスクの高い組み合わせを見逃すと、後段のチケットには重要度の低い項目ばかりが積み上がり、本当に危険なファインディングが埋もれてしまいます。

CSPM・CWPP・CIEM・CNAPPの違い

よくある設定ミス・運用の落とし穴

• ファインディングをフラットなチェックリストとして扱う High Risk

  数百件のファインディングを重大度ラベルだけで上から消化し、悪用可能性や外部露出を考慮したリスクベースの優先順位付けをしていない。

• Toxic Combinationの見落とし High Risk

  「パブリック公開されたリソース」「過剰なIAM権限」「ログ未取得」はそれぞれ単体ではMedium/Low評価でも、組み合わさると重大な侵害経路になる。単一ファインディングの重大度だけでは見えない。

• 本番アカウントのみのスキャン Medium Risk

  検証・開発用のAWSアカウントやAzureサブスクリプション、GCPプロジェクトがCSPMのスキャン対象から漏れ、そこから本番への横展開の起点になる。

• 是正SLAが追跡されていない Medium Risk

  ファインディングを検出しても、重大度ごとの是正期限(SLA)が設定・追跡されておらず、Criticalな項目が数か月放置される。

攻撃シナリオ: Medium評価のファインディングを連鎖させる

個別にはCSPMがMedium severityとしか評価しない3つのファインディングが、組み合わさることで完全な侵害経路になる例です。

1. 攻撃者がインターネットからスキャンし、パブリックIPを持つEC2インスタンスを発見する(単体ではMedium: 「意図的な公開設定」の可能性もあるため)。
2. そのインスタンスに付与されたインスタンスロールが、実際にはs3:*やsecretsmanager:GetSecretValueなど広範な権限を持っていることを、メタデータサービス経由で確認する(単体ではMedium: 「過剰権限」自体はよくある)。
3. VPC Flow Logsが有効化されておらず、この後の内部トラフィックが記録されないことを確認する(単体ではLow〜Medium: 「ログ未取得」単独では実害が出にくい)。
4. 3つを組み合わせ、公開インスタンスを侵害 → ロールの権限でS3やSecrets Managerにアクセス → 痕跡がログに残らない、という一連の攻撃パスが完成する。CNAPPの攻撃パス分析はこの連鎖を「Critical」として検出するが、フラットなファインディングリストではMediumが3件としか見えない。

検知

CSPMは一度のスキャンで終わらず、継続的に(多くは数時間〜1日おきに)全リソースを再スキャンし、以前は準拠していたリソースが非準拠に変化した「ドリフト」を検知します。ドリフトはIaCの変更漏れ、手動での緊急変更、あるいは攻撃者による設定変更のいずれかを示唆するため、単発のスキャン結果より重要なシグナルになります。

• コンプライアンス状態が「準拠」から「非準拠」に変化したリソースをリアルタイムでアラート。
• 手動変更(IaC管理外の変更)によって生じたドリフトを、Terraformのstateやgit履歴と突き合わせて検証する。
• ドリフト検知の結果は、Detection & Responseページで扱う監査ログ監視・アラーティングのパイプラインに統合し、CSPMのアラートを他の検知シグナルと同じSOCワークフローで処理する。

是正

CSPMのファインディング出力をもとに、該当するリソースへ具体的な是正コマンドを適用する例です。

{
  "resource": "arn:aws:s3:::app-uploads-prod",
  "rule": "S3_BUCKET_PUBLIC_ACCESS_BLOCK_DISABLED",
  "severity": "HIGH",
  "exposure": "internet-facing",
  "exploitability": "high",
  "first_seen": "2026-09-01T03:12:00Z",
  "status": "OPEN"
}

このファインディングに対する是正コマンドです。

# Block Public Accessを有効化して公開設定を遮断
$ aws s3api put-public-access-block \
    --bucket app-uploads-prod \
    --public-access-block-configuration \
    BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

# 是正後、CSPMの再スキャンでステータスがCLOSEDになったことを確認
$ aws s3api get-public-access-block --bucket app-uploads-prod

実際に手を動かす

このページで扱った「CSPMファインディングのリスクベース優先順位付けと是正」を、実際のシナリオ形式で体験できます。複数のMediumファインディングがどのように組み合わさってCriticalな攻撃パスになるかを、実際のCLIコマンドで確認します。

実装チェックリスト

• CSPMがすべてのAWSアカウント/Azureサブスクリプション/GCPプロジェクトに対して有効化されている(本番以外も含む)
• ファインディングが重大度の羅列ではなく、悪用可能性・外部露出を含むリスクベースで優先順位付けされている
• Toxic Combination(公開リソース+過剰権限+ログ未取得など)が個別ファインディングとは別に定期レビューされている
• 重大度ごとの是正SLAが定義され、SLA超過のファインディングが可視化されている
• スキャンが点検時点(point-in-time)ではなく継続的に実行され、ドリフトが検知できる
• CIEM(IAM権限の可視化)がCSPMの結果と統合され、権限起因のリスクが単独で見落とされない
• CSPMのアラートがチケットシステムに自動連携され、検出から是正までのトラッキングができている
• ドリフト検知のアラートが、監査ログベースの検知パイプラインと同じインシデント対応フローに統合されている