クラウドセキュリティ態勢管理（CSPM）を解説

CSPMが重要な理由

多くの企業はクラウドに移行する際、Amazon Web Services（AWS）、Google Cloud、Microsoft Azureなど、どのクラウドプロバイダーを利用する場合でも、クラウドのセキュリティはすべてプロバイダーの責任だと考えがちです。しかし、これまでに把握されているクラウド侵害はすべて、クラウドプロバイダーではなく顧客側に原因があるクラウドの設定ミスによって発生しています。

CSPMを活用すると、自動チェックによってセキュリティやコンプライアンス上のリスクを特定し、軽減できます。クラウドを利用する企業は、データ侵害につながりかねない設定ミスを検出できます。クラウドネイティブアプリケーションセキュリティの現状に関する調査では、回答者の半数以上が設定ミス、または既知の脆弱性に関するインシデントを経験しており、包括的なクラウドセキュリティにCSPMソリューションが不可欠であることが明らかになりました。

クラウドセキュリティの設定ミスはなぜ起こるのか？

クラウドの設定ミスとは、アプリケーション、コンテナ、インフラストラクチャ、その他のソフトウェアコンポーネントに適切な制御を実装できていない状態です。こうした問題は、多くの場合、インフラストラクチャ全体や、コンテナ、Kubernetes、クラウドサービスが相互にどう連携しているかを十分に把握できていない場合に発生します。また、セキュリティの観点で十分とは限らないデフォルトのセキュリティ設定や認証情報を、そのまま使用しているケースもあります。

責任共有モデル

前述のとおり、セキュリティの責任はクラウドプロバイダーだけにあるわけではありません。パブリッククラウドサービスを利用する組織とクラウドプロバイダーが、責任を共有します。

この責任共有モデルは、組織が利用するインフラストラクチャの種類によって異なります。オンプレミスのインフラストラクチャのセキュリティは組織が全面的に担いますが、クラウドインフラストラクチャではその責任が軽減されます。

• Infrastructure as a Service（IaaS）：クラウドプロバイダーが、物理ハードウェア、インフラストラクチャ、ネットワーク、ストレージを管理します。

• Platform as a Service（PaaS）：クラウドプロバイダーはインフラストラクチャに加え、オペレーティングシステムや環境など、アプリケーションの実行に必要なものを管理します。

• Software as a Service（SaaS）：クラウドプロバイダーが、インフラストラクチャ、プラットフォーム、ソフトウェア自体を管理します。

IaaSからSaaSへと移行するにつれてクラウドプロバイダーの責任範囲は広がりますが、適切な設定を行い、ユーザーがクラウドを利用する方法を保護する責任は、引き続き組織にあります。

CSPMのユースケース

CSPMは、脅威検出、インシデント対応、コンプライアンス、インフラストラクチャの保護など、さまざまな用途に対応するサイバーセキュリティツールです。

脅威の検出

CSPMは、複数のクラウド環境にわたって脅威を事前に検出できます。脅威を継続的に検出することで、設定ミスや不審なアクティビティを一元的に可視化し、リスクへの露出を評価して最小限に抑えられます。

インシデント対応

CSPMソリューションのもう一つの重要な機能は、攻撃者によるIAMの引き受けロールの変更や暗号化の無効化など、侵害の兆候を検出するとともに、設定ミスによる脆弱性を組織に通知することです。インシデント対応機能を利用すれば、検出した脅威を一元的に把握し、迅速かつ効率的に軽減できます。

コンプライアンス

CSPMは、HIPAA、SOC 2などの規制に関する継続的なコンプライアンス監視とレポート作成にも対応します。これにより、パブリッククラウドサービスの利用時にコンプライアンス違反を回避し、社内のセキュリティポリシーを徹底できます。

インフラストラクチャの保護

インフラストラクチャの保護において、CSPMは設定ファイル内の設定ミスを検出できます。これにより、さまざまなクラウドサービスの連携を把握し、安全でないクラウド環境へのアプリケーションのデプロイを防止できます。

CSPMとDevSecOps

クラウドインフラストラクチャの構築と管理にInfrastructure as Code（IaC）が広く使われるようになるにつれ、開発者がクラウド環境に対して担う責任も大きくなっています。そのため、開発、DevOps、セキュリティの各チームが、クラウドとインフラストラクチャのセキュリティに共同で責任を持つ必要があります。

このDevSecOpsのアプローチでは、自動化されたIaCのデプロイも含め、ソフトウェア開発ライフサイクル（SDLC）全体にセキュリティを組み込みます。クラウドインフラストラクチャは設定ファイルを使ってプロビジョニング、管理されるため、IaCのデプロイでは設定ミスが起こる可能性があります。CSPMでIaCのデプロイを監視すれば、脆弱な設定を検出し、開発チームによるセキュリティ問題の修正を支援できます。

Policy as Code（PaC）も、DevSecOpsのアプローチの一環としてCSPMソリューションと併用できるツールです。PaCは、他のコードや実行環境をチェックし、望ましくない状態や安全でない設定がないか確認するために設計されています。PaCを活用することでセキュリティを自動化し、ソフトウェア開発ライフサイクル（SDLC）のあらゆる段階で、ルールの内容や適用方法に曖昧さや意見の相違が生じないようにしながら、クラウドに関わるすべての担当者が安全に業務を進められます。

CSPMソリューションをクラウドネイティブアプリケーションセキュリティプラットフォームと併用すれば、アプリケーションそのものと、それらが稼働するクラウドファースト環境のセキュリティを強化できます。SnykによるFugueの買収により、組織はクラウドの設定ミスがもたらす影響をより詳しく把握できるようになり、開発チームは問題を修正しやすくなります。Fugueの多くの機能はSnyk IaC製品に統合されており、今後も機能を追加していく予定です。

よくある質問

CSPMが必要なのはなぜですか？

多くの組織では、外部の攻撃者や内部関係者による意図的な侵害を検出するためのクラウドセキュリティプロセスを整備していますが、意図しないセキュリティリスクも存在します。デフォルト設定の使用や不適切なアクセス制御といったクラウドの設定ミスによって、組織が脆弱な状態に置かれることがあります。クラウドセキュリティ態勢管理（CSPM）は、コンテナやKubernetesからマルチクラウド環境まで、クラウドインフラストラクチャ全体の設定ミスを自動的に検出します。

CSPMとCASBの違いは何ですか？

クラウドアクセスセキュリティブローカー（CASB）は、組織がクラウドリソースを利用する際にセキュリティポリシーを適用します。CASBソリューションはファイアウォールとして機能し、ユーザーが会社のポリシーに準拠した方法でクラウドを利用できるようにします。一方、クラウドセキュリティ態勢管理（CSPM）ソリューションは、設定ミスの可能性を自動検出し、クラウドリソースが安全に設定されていることを確認します。

CSPMとCWPPの違いは何ですか？

クラウドワークロード保護プラットフォーム（CWPP）は、従来型のデータセンター、プライベートクラウド、パブリッククラウド環境にあるワークロードを保護するセキュリティソリューションです。クラウドセキュリティ態勢管理（CSPM）はクラウド環境を対象とし、CWPPはデプロイ先を問わずワークロードを保護します。ただし、どちらのサイバーセキュリティツールも、クラウド上の機密データの保護を目的としています。