CSPM(Cloud Security Posture Management:クラウドセキュリティ態勢管理)は、AWS・Microsoft Azure・Google Cloud Platform(GCP)といったパブリッククラウド環境の設定状況を継続的にスキャンし、設定ミスやコンプライアンス違反を検知・是正するためのソリューションカテゴリーです。Capital Oneの大規模情報漏えい事件をはじめ、クラウド由来のインシデントの大多数は「攻撃」よりも「設定ミス」に起因します。本記事では、CSPMの定義・主要機能・関連カテゴリ(CWPP/CIEM/CNAPP)との違い、そして導入のポイントを解説します。
CSPMとは:クラウドインフラの設定ミスを継続的に検知・是正する
CSPMの定義
CSPMは、IaaS・PaaS環境の構成情報をAPI経由で収集し、ベストプラクティスやコンプライアンス基準と照合して逸脱を検出するソリューションです。Gartnerが2010年代半ばに提唱したカテゴリーで、現在ではCNAPP(Cloud-Native Application Protection Platform)の中核機能として位置付けられています。
CSPMが評価する典型的な対象は次の通りです。
- ストレージサービス(S3 / Blob Storage / Cloud Storage)の公開設定
- IAMポリシーの過剰権限・未使用権限
- セキュリティグループ・ファイアウォール規則の過剰開放
- 暗号化(保存時・転送時)の有効化状況
- ロギング・監査証跡(CloudTrail / Activity Log / Cloud Audit Logs)の有効化
- マネージドサービス(RDS、Cloud SQL、AKS等)のセキュリティ設定
- マルチアカウント・マルチサブスクリプション全体のガバナンス
シェアド・レスポンシビリティモデルにおける位置づけ
パブリッククラウドでは「クラウドプロバイダがインフラを保護し、利用者がクラウド上の構成・データを保護する」というシェアド・レスポンシビリティモデルが採用されています。利用者責任の範囲で起きる設定ミスは、プロバイダ側のセキュリティ機能だけでは検知できません。CSPMはまさにこの「利用者責任側」の設定健全性を見張る仕組みです。
フィッシング訓練選定ガイド
フィッシング訓練サービスの選び方を解説。訓練テンプレート、レポーティング、AI活用など、効果的な訓練に必要な機能を比較できます。
CSPMが解決する課題:クラウド設定ミスの実態
設定ミスは「攻撃」より頻度が高い
クラウド由来のセキュリティインシデントの多くは、ゼロデイ攻撃ではなく「公開すべきでないバケットを公開していた」「過剰権限のIAMロールが横展開に使われた」といった設定ミスに起因します。Gartnerは「2025年までにクラウドセキュリティ障害の99%は顧客側に責任がある」と早くから予測しており、その主因として設定ミスが繰り返し挙げられています。
代表的なクラウド設定ミスのパターン
- 公開ストレージ:S3バケットを「Public」に設定したまま個人情報を保管
- 過剰なIAM権限:開発者アカウントに本番環境への管理者権限を付与し続ける
- オープンなセキュリティグループ:管理用ポート(22/3389)を 0.0.0.0/0 に開放
- 暗号化の無効化:本番DBスナップショットが平文で保存されている
- ロギング未設定:監査証跡が記録されておらず、事後調査が不可能
- デフォルト認証情報:マネージドサービスの初期設定のまま運用
- MFA未強制:ルートアカウントや特権アカウントでMFAが無効
人間の目視チェックでは、数百〜数千のリソースが日々増減するクラウド環境を網羅し続けることは不可能です。
CSPMの主要機能
1. 構成情報の継続的なスキャン
クラウドプロバイダの管理API(AWS Config、Azure Resource Graph、Google Cloud Asset Inventoryなど)を介して、リソースの構成情報を定期取得します。新規リソース作成時のリアルタイム評価に対応する製品も多く存在します。
2. ポリシー評価とベンチマーク照合
スキャン結果を以下のような基準と照合します。
- CIS Benchmarks(AWS、Azure、GCP、Kubernetes等の各ベンチマーク)
- NIST Cybersecurity Framework / NIST SP 800-53
- PCI DSS(カード業界)
- HIPAA(医療業界)
- ISO/IEC 27001 / 27017
- 組織独自のカスタムポリシー
各ルール違反にリスクスコアを付与し、優先順位を可視化します。
3. 自動修復(Auto-Remediation)
検出した違反に対して、修正アクションを自動実行する機能です。例として「Public化されたS3バケットを自動でPrivateに戻す」「過剰開放されたセキュリティグループを既定値に戻す」など。重要な操作は管理者承認フロー付きで実行します。
4. コンプライアンスレポーティング
監査対応用に、各種フレームワークへの準拠状況をダッシュボード化・PDF出力します。手作業での監査証跡収集を大幅に削減できます。
5. ドリフト検知(IaC連携)
Terraform・CloudFormation等のIaC(Infrastructure as Code)で定義された「あるべき構成」と、実際のクラウド構成の差分を検知します。本番環境で誰かが手作業で変更した「ドリフト」を可視化し、修正を促します。
6. 脅威検知連携
CSPM単体では「設定の静的評価」が中心ですが、CloudTrailなどのアクティビティログを取り込み、不審な行動(深夜の大量データダウンロード、未使用リージョンでの突然のリソース作成など)を検知する機能を備える製品も増えています。
CSPM・CWPP・CIEM・CNAPPの違い
クラウドセキュリティ領域には類似カテゴリーが複数存在します。整理すると次のようになります。
| カテゴリ | 対象 | 主な役割 |
|---|---|---|
| CSPM | クラウドインフラ構成(コントロールプレーン) | 設定ミス検知・コンプライアンス評価 |
| CWPP | ワークロード(VM・コンテナ・サーバーレス) | ランタイム保護・脆弱性スキャン |
| CIEM | クラウドのアイデンティティ・権限 | 過剰権限の検知・最小権限化 |
| DSPM | クラウド上のデータ | データの所在・分類・アクセス可視化 |
| CNAPP | 上記の統合プラットフォーム | CSPM+CWPP+CIEM等を1製品で提供 |
近年は単体カテゴリーよりも、これらを統合したCNAPP(Cloud-Native Application Protection Platform)として提供されるケースが主流になっています。
CSPMとSSPMの違い
| 項目 | CSPM | SSPM |
|---|---|---|
| 管理対象 | クラウドインフラ(IaaS/PaaS) | SaaSアプリ(M365、Salesforce等) |
| API連携先 | AWS / Azure / GCPの管理API | 各SaaSの管理API |
| 典型的なリスク | 公開バケット・過剰IAM権限・暗号化漏れ | 設定ミス・休眠アカウント・外部共有 |
| 主な利用者 | クラウドエンジニア・SRE | IT管理者・SaaS担当 |
CSPMは「インフラ層」、SSPMは「アプリ層」を扱う補完関係にあります。両方を組み合わせることで、クラウド利用全体の態勢管理が成立します。
CSPM導入のステップ
ステップ1:対象アカウント・サブスクリプションの棚卸し
組織が利用しているクラウドアカウント・サブスクリプション・プロジェクトを一覧化します。シャドークラウド(部門が独自契約したアカウント)も含めて把握することが重要です。
ステップ2:読み取り権限の付与とAPI連携
CSPMツールに対して、各クラウドアカウントへの読み取り権限を付与します。AWSではクロスアカウントロール、Azureではサービスプリンシパル、GCPではService Accountを使用するのが一般的です。
ステップ3:ベースラインの選定
評価ルールセットの初期値として、CIS Benchmarksなど業界標準を選定します。組織独自の制約(特定のリージョンを禁止する、特定のサービスを許可しない等)はカスタムルールとして追加します。
ステップ4:優先度付けと対応計画
初回スキャンでは数百〜数千件の違反が検出されるのが普通です。すべてを一度に直そうとせず、影響度(公開バケット、ルートアカウント関連など)から優先的に対応します。
ステップ5:CI/CDとIaCへの組み込み
新規リソース作成時のチェックを「事後検知」だけでなく「事前防止」に寄せるため、IaCコードのレビュー段階でポリシー評価を行うshift-leftの仕組み(OPA / Conftest / Checkov / tfsec など)を併用します。
ステップ6:継続的な運用サイクル
CSPMは「導入して終わり」ではなく、新ルール追加・新サービス対応・組織変更を反映し続ける運用が必要です。週次または月次のレビュー会で、検出傾向と対応状況を可視化することが望ましい運用です。
CSPMだけでは解決しない領域
CSPMは強力ですが、以下の領域は別カテゴリーとの組み合わせが必要です。
- アプリケーション内部の脆弱性 → SAST/DAST/SCA
- コンテナ・VM内のランタイム挙動 → CWPP
- 過剰権限の最小化提案 → CIEM
- SaaSアプリ側の設定ミス → SSPM
- データそのもののリスク評価 → DSPM
- アイデンティティの認証強度 → IdP・MFA・SSO(LOCKED MSO等)
CSPMは「クラウドインフラ設定の健全性」という重要な1ピースを担いますが、クラウドセキュリティ全体としては多層防御が前提になります。
LOCKEDサービスとの関係
CSPMはクラウドインフラ層のソリューションですが、その運用基盤となる「クラウド管理コンソールへのアクセス制御」は、LOCKED MSOによるSSO・MFA統合が担う領域です。クラウド管理者アカウントが乗っ取られれば、CSPMの自動修復機能を逆手に取られる可能性すらあります。クラウド管理者を狙った標的型フィッシングへの組織耐性は、LOCKED ATPの訓練機能で底上げできます。
LOCKEDの詳細を見る クラウドセキュリティの土台となるアクセス管理・標的型攻撃対策はLOCKEDにご相談ください。 資料請求・デモ依頼はこちら →
まとめ:CSPMはクラウド利用が広がるすべての組織で必須
| ポイント | 内容 |
|---|---|
| CSPMとは | パブリッククラウドの設定ミス・コンプライアンス違反を継続的に検知・是正 |
| 対象 | AWS / Azure / GCPなどIaaS/PaaSのコントロールプレーン |
| 主な機能 | 構成スキャン/ベンチマーク照合/自動修復/コンプライアンスレポート/ドリフト検知 |
| 関連カテゴリ | CWPP(ワークロード)/CIEM(権限)/DSPM(データ)/CNAPP(統合) |
| SSPMとの関係 | インフラ層(CSPM)とアプリ層(SSPM)の補完関係 |
クラウド利用が「一部のチーム」から「全社の前提」へ移行した今、設定ミスを人手で追い切ることはもはや不可能です。CSPMは、クラウド利用の規模と速度に追従するための前提インフラとして検討すべき領域です。
参考資料・関連機関
- 総務省:クラウドサービス利用・提供における適切な設定のためのガイドライン
- IPA:中小企業の情報セキュリティ対策ガイドライン
- ISMAP(政府情報システムのためのセキュリティ評価制度)公式ポータル
- NIST SP 800-210:General Access Control Guidance for Cloud Systems
- Center for Internet Security:CIS Benchmarks