CSPMとは？クラウド設定を点検する仕組みと導入時の確認点

はじめに

クラウドの利便性がビジネスを加速させる一方で、その影に潜むリスクをご存知でしょうか？クラウド環境では、ストレージの公開設定やアクセス権限など「たった一つの設定ミス」が、情報漏洩につながることがあります。設定ミスによる情報漏洩インシデントは、さまざまな業種で報告されています。自社のクラウド環境は本当に安全でしょうか？「うちは大丈夫」という思い込みが、設定の見直しを遅らせる原因になります。この課題に対応する鍵となるのが「CSPM (Cloud Security Posture Management)」です。この記事では、CSPMの基本から選び方、そして単体では守れない領域とその対策まで徹底解説します。

CSPM（Cloud Security Posture Management）とは何か

CSPM（Cloud Security Posture Management）とは、クラウドサービスの設定を継続的に確認し、設定ミスやセキュリティ上の不備を見つけるための仕組みです。公開範囲、アクセス権限、暗号化、ログの取得などの設定を、点検項目や基準と照合し、設定ミスやコンプライアンス上の違反を検出します。参考：MicrosoftのCSPM解説

まさに、クラウド環境の健康状態を定期的にチェックする「健康診断」のようなものです。「Posture Management（ポスチャー管理）」とは、「あるべき正しい姿勢（Posture）を保つための管理」を意味します。CSPMは、この「正しい姿勢」、つまり安全な設定状態が常に維持されているかを監視・管理する役割を担います。

主に監視対象となるのは、AWS、Microsoft Azure、Google Cloudといったクラウドプラットフォーム上のIaaSやPaaS環境の設定です。API連携により、クラウド側の設定状態を自動的に確認します。なお、CSPMが確認するのはクラウドの設定であり、アプリケーションやOSに含まれる脆弱性は別の手段で確認します（後述の「CSPMの限界と、その先へ」で解説します）。

なぜ今、CSPMが不可欠なのか？3つの深刻な背景

背景1：ヒューマンエラーによる設定ミスの頻発

クラウド環境は日々複雑化・巨大化しており、手動での設定管理には限界があります。前述の通り、設定ミスに起因する情報漏洩事例は後を絶ちません。過剰に公開されたストレージや、適切に制御されていない権限など、たった一つの些細なミスが重大なセキュリティホールとなり、直ちに情報漏洩につながる事案になりかねません。
IaC（Infrastructure as Code）などのアプローチを通じて、できる限りコード化・自動化を行う方法もありますが、それだけで設定ミスを完全に管理するのは困難でしょう。

背景2：責任共有モデルの罠

クラウドを利用する際、セキュリティに関する責任はクラウド事業者と利用者（貴社）で分担されます。これが「責任共有モデル」です。クラウド事業者は「クラウドのセキュリティ」（物理インフラなど）を担いますが、「クラウド上のセキュリティ」（設定やデータなど）は利用者の責任です。そのため、「クラウドを使っているから安全」ではなく、その設定や実装したアプリケーションなどは当然ながらユーザーの責任として適切に担保していく必要があります。

※ 利用するサービスによって責任領域は異なるが、当然ながらクラウド設定についてはユーザーの責任となる
出典： AWSにおける責任共有モデル

背景3：多様化するコンプライアンス要件

GDPR、CCPA、ISO/IEC 27001、PCI DSSなど、企業が対応を求められる規制や基準は多様化しています。CSPMは、CISベンチマークなどの基準に沿った設定が維持されているかを継続的に確認し、製品によってはその結果をレポートとして出力できます。これにより、監査に向けた設定状況の確認作業を効率化できます。

ただし、基準に沿った設定チェックが通ることと、認証取得や監査合格が保証されることは別です。CSPMの結果は、規制や認証への対応状況を確認するための材料の一つとして扱います。

クラウド設定ミスにおける情報漏洩の事例

自動車会社：長期間にわたる顧客データの露出

2023年5月、ある自動車会社は、クラウド環境の設定ミスにより、顧客の車両に関するデータが長期間にわたって外部からアクセス可能な状態だったことを公表しました。車両の位置情報や車両識別番号などが対象となり、その後の調査では、別の顧客データについても同様の状態が見つかっています。

この事例のように、設定ミスは利用者が気づかないまま長く残ることがあります。設定時の確認だけでなく、稼働中の環境を継続的に点検する仕組みが求められます。

CSPMの主要機能と導入メリット

主要機能

一般的なCSPMが備える主な機能は次のとおりです。具体的な対応範囲は製品によって異なります。

• 可視化：連携したクラウドアカウント内のリソース（サーバー、DB、ストレージ等）とその設定状態を一覧表示します。
• 継続的な監視と設定違反の検出：CISベンチマークなどの業界標準や自社ポリシーに基づき、設定の違反を自動検知します。
• コンプライアンス準拠状況の可視化：基準ごとの準拠状況をダッシュボードで可視化し、監査に使えるレポートを出力します。
• インシデント対応の迅速化と修復：違反を検知した際にはアラートを通知し、製品や構成によってはLambda関数などを用いた自動修復を実行します。

検出される設定の例と結果の読み方

代表的な検出例は、想定外に公開されたストレージ、広すぎるネットワーク許可、監査に必要なログの不足などです。

検出結果は、設定値と判断理由、影響する資産、推奨する変更を合わせて確認します。インターネット公開がサービスの要件である場合もあるため、検知をすべて一律に修正すればよいわけではありません。

導入メリット

• セキュリティリスクの低減：設定ミスを早期に発見・修正することで、情報漏洩などのインシデントにつながるリスクを減らせます。
• 運用工数の削減：手動での監視・チェックの負担を減らし、セキュリティ担当者が検出結果の判断と修正に集中しやすくなります。
• 監査対応の効率化：出力されたレポートを活用することで、設定状況の確認や監査資料の準備にかかる時間とコストを抑えられます。
• 安全な基盤構築：クラウド基盤の設定状態を継続的に把握することで、新たなサービス開発やビジネス拡大といった「攻めのIT投資」を安心して推進できます。

【徹底比較】CSPMとCWPP、CIEMとの違いは？

CSPMは非常に重要ですが、クラウドセキュリティには他にも重要なソリューションがあります。特に混同されやすいのがCWPP (Cloud Workload Protection Platform) です。

• CWPP：CSPMはクラウドインフラストラクチャの設定（例：ファイアウォールルール、アクセス権限）を点検します。一方、CWPPはそのインフラ上で動作するワークロード（例：VM、コンテナ内のOSやアプリケーション）を保護します。簡単に言えば、CSPMが「建物の鍵やドアの施錠状態」をチェックするのに対し、CWPPは「建物の中の住人の安全」を守るようなものです。
• CIEM：CIEM (Cloud Infrastructure Entitlement Management) は、クラウドリソースへの権限（特に過剰な権限）を管理・最適化することに特化したソリューションです。

また、これらを統合的に行うものとしてCNAPP(Cloud Native Application Protection Platform)というアプローチがあります。

失敗しないCSPMツールの選び方5つのチェックポイント

1. 対応クラウドとサービスの範囲　自社で利用しているAWS、Microsoft Azure、Google Cloudなどのクラウドだけでなく、今後利用を検討しているサービスにも対応しているかを確認しましょう。同じクラウドに対応していても、利用中のすべてのリソースが検査されるとは限らないため、対象サービスと点検項目まで確認します。
2. 検出ルールの柔軟性とカスタマイズ性　CISベンチマークなどの標準ルールに加え、自社の独自ポリシーをルールとして設定・適用できるかが重要です。
3. 修復機能のレベル　単なるアラート通知だけでなく、Lambda関数などを用いた自動修復や、管理者の承認を経て実行する半自動修復（ワンクリック修復）をサポートしているかを確認しましょう。
4. API連携と他ツールとの拡張性　SIEM、SOAR、チケット管理システムなど、既存のセキュリティ・運用ツールとAPIで連携できるかを確認します。あわせて、クラウドとの連携に必要な権限の範囲が、自社の権限管理の方針に合うかも確認します。
5. レポートとダッシュボードの分かりやすさ　技術者だけでなく、経営層や監査担当者も状況を一目で理解できる、直感的なダッシュボードとレポート機能を備えているかが重要です。

評価中に一つの設定を変更し、次の検査で結果が更新されるか確かめると、収集頻度や修正確認の流れを把握できます。通知を送れるかだけでなく、同じ問題が再発した際に気づけるかも確認します。

検知後に対応できる運用をつくる

CSPMを導入しても、検出結果を確認して修正する体制がなければ、リスクは減りません。導入時には、クラウドアカウントごとの担当部署をそろえ、検出結果を誰が確認するか決めます。

修正できる設定は変更の影響を調べて対応し、必要な公開設定などは理由と見直し日を記録して管理します。例外として残した設定も、見直し日に改めて要否を確認します。

CSPMの限界と、その先へ

CSPMは強力なツールですが、万能ではありません。その限界を理解し、補完するソリューションを導入することが、クラウドも含めたセキュリティ対策にとって非常に重要となります。

課題1：把握できていない資産（シャドーIT）の存在

CSPMがその能力を最大限に発揮するための大前提は、「監視すべきクラウドアカウントが全て連携されている」ことです。しかし、現実はどうでしょうか？

• 開発チームがテスト目的で、管理部門に無断で作成したクラウドアカウント
• 退職した従業員が個人で契約し、誰も管理しなくなった野良インスタンス
• M&Aによって引き継いだが、存在を忘れ去られているドメイン

これら企業が把握できていない資産（シャドーIT）は、当然ながらCSPMの監視対象外です。そして、攻撃者はまさにこのような管理の隙間を狙って侵入を試みます。

解決策：ASM (Attack Surface Management)/OSINTによる資産探索

ASMは、攻撃者の視点に立ち、インターネット上に公開されている自社の資産（ドメイン、IP、クラウドインスタンス、SaaSアプリなど）を探索・発見します。把握できていなかった資産が見つかれば、管理対象への追加や不要な公開の停止を検討できます。また、脆弱性診断を通じてアプリケーション層の脆弱性を検知することによって、設定以外のセキュリティリスクもあぶり出すことができます。

課題2：アプリケーションとソフトウェアサプライチェーンの脆弱性

クラウドの設定が適切でも、安心はできません。攻撃の侵入口はインフラ層だけではなく、その上で動作するアプリケーションや、利用しているオープンソースソフトウェア（OSS）に脆弱性があれば、そこが侵入口になります。

• Webアプリケーションに潜む脆弱性（例：SQLインジェクション、クロスサイトスクリプティング）
• アプリケーションを構成するために利用しているオープンソースソフトウェア（OSS）に含まれる既知の脆弱性

これらは、CSPMの守備範囲外です。OSやコンテナの脆弱性、実行時の不審な動作も、設定点検とは異なる観点です。クラウドの設定がどれだけ堅牢でも、アプリケーションの「ドア」に鍵がかかっていなければ、そこから侵入されてしまいます。

解決策：SBOMや脆弱性診断などのアプリケーションに対してのセキュリティ対策

• SBOM (Software Bill of Materials)　ソフトウェアの構成要素（使用しているライブラリ、フレームワークなど）を部品表として可視化します。これにより、使用しているOSSに脆弱性が発見された場合、どのアプリケーションに影響があるかを迅速に特定・対応できます。
• 脆弱性診断ツール（DAST）　稼働中のWebアプリケーションに対して外部から攻撃を模倣した検査を行い、SQLインジェクションやクロスサイトスクリプティング（XSS）などの実行時脆弱性を検出します。

結論

これからのクラウドセキュリティは、CSPMを中核としつつ、ASMによる攻撃対象領域の把握、SBOMによるソフトウェアサプライチェーンの可視化、脆弱性診断によるアプリケーションレイヤーの検査を組み合わせた、統合的なアプローチが重要です。それぞれが異なる層のリスクを扱うため、組み合わせることで、インフラからアプリケーションまでの確認漏れを減らせます。

まとめ

CSPMは、クラウド時代のセキュリティにおいて欠かせない第一歩です。設定ミスという身近で影響の大きいリスクを継続的に点検し、基準に沿った設定状態の確認を効率化することで、安全なクラウド基盤を築く助けになります。しかし、CSPM単体では防げない脅威が存在します。安全を確保するためには、CSPMを中核としつつ、ASM、SBOM、脆弱性診断といったソリューションを組み合わせた、多層的かつ統合的なセキュリティアプローチが必要です。

Securify CSPMの対象クラウド

弊社が提供するSecurify CSPMは、AWS・Google Cloud・Microsoft Azure・さくらのクラウド・Oracle Cloud・Cloudflareの6つのクラウドを対象に、公開設定や権限を継続監視します。設定ミスの内容と修正手順を確認できます。対象サービスやチェック項目はクラウドごとに異なります。

Securifyでは、CSPMのほか、外部公開資産を発見するSecurify ASM、WebサイトやAPIの脆弱性を検出する脆弱性診断、ソフトウェアの成分から脆弱性を見つけるSecurify SBOMも提供しています。

料金は連携するアセットソース数に応じた個別見積もりです。アカウント・プロジェクトなどの集計単位と対象範囲は、CSPMの料金ページをご確認ください。ぜひお気軽にお問い合わせください。

SecurifyのCSPM機能についてはこちらでご紹介しております。併せてご覧ください。

参考文献（References）

• Microsoft Security 101: What is CSPM? https://www.microsoft.com/en-us/security/business/security-101/what-is-cspm
• Gartner IT Glossary: Cloud Security Posture Management (CSPM) https://www.gartner.com/en/information-technology/glossary/cloud-security-posture-management-cspm
• Cloudflare Learning: What is CSPM? https://www.cloudflare.com/learning/cloud/what-is-cspm/
• Orca Security: What is CSPM? と CNAPP との関係整理 https://orca.security/resources/blog/what-is-cspm/
• Netskope: Cloud Security Posture Management 解説 https://www.netskope.com/jp/security-defined/cspm-cloud-security-posture-management
• AWS 公式: Shared Responsibility Model https://aws.amazon.com/compliance/shared-responsibility-model/
• Microsoft Azure 公式: Shared Responsibility in the cloud https://learn.microsoft.com/azure/security/fundamentals/shared-responsibility
• Google Cloud: Shared fate model https://cloud.google.com/security/shared-fate
• CIS Benchmarks 総合ポータル https://www.cisecurity.org/cis-benchmarks/
  • CIS Benchmarks 概要 https://www.cisecurity.org/cis-benchmarks-overview
  • CIS Google Cloud Platform https://www.cisecurity.org/benchmark/google_cloud_computing_platform/
  • CIS AWS Foundations ほか https://www.cisecurity.org/benchmark/amazon_web_services/
  • CIS Oracle Cloud Infrastructure https://www.cisecurity.org/benchmark/oracle_cloud