"CSPMを探しています。"や"CSPMのデモを見せてもられませんか?"といった言葉は、ここ数ヶ月、私が最も多くお客様からお伺いするものかもしれません。この記事では、CSPMとは何なのか?と本当に必要なものなのか?を掘り下げてみたいと思います。
CSPMとは?
Gartner社のGlossaryではCSPMとは以下のように表現されています。
Cloud security posture management (CSPM) consists of offerings that continuously manage IaaS and PaaS security posture through prevention, detection and response to cloud infrastructure risks. The core of CSPM applies common frameworks, regulatory requirements and enterprise policies to proactively and reactively discover and assess risk/trust of cloud services configuration and security settings.
要約すると、IaaSやPaaSの設定状態をグローバル標準のフレームワークやポリシーを元にチェック、設定の不備を検出して対処を促す、になるかと思います。CSPMがフォーカスしているのはクラウド環境の設定不備ですね。
なぜ設定不備にフォーカスするのか?
改めてなぜ設定不備にフォーカスするのか考えてみたいと思います。私は、クラウド環境の設定不備にフォーカスする理由は、クラウドが持つ特性の1つにあるのではと考えています。以下のNIST SP800-145 Definition of Cloud Computingで定義されているクラウドの特性抜粋です。
On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service provider.
クラウドは、APIやGUIを介して様々な人が常にVMやContainerのようなワークロードを配備したり消したりして、状態が変化しているかと思います。これはワークロードの配備だけでは無く、VPCやSecurity GroupやIAM等の設定についても同様です。人は誰しも間違いをおかすため、設定状態は必ずしこ臨んだものにはならないかと。私は、クラウドが持つOn-demand self-serviceの特性が、設定不備にフォーカスすべきと唱えられている最も大きな理由かと考えています。
なぜクラウドは状態が常に変化するのか?
では、なぜクラウドは状態が常に変化するのか?について掘り下げてみたいと思います。私は、ソフトウェア開発に対する考え方とソフトウェアそのもののアーキテクチャの変化が大きいと考えています。
開発に対する考え方の変化
先ずソフトウェア開発に対する考え方の変化ですが、20数年前までソフトウェア開発は、ウォーターフローのような統制と管理が根底にあるアプローチで行われていて、開発されたソフトウェアが実行環境(当時はオンプレ)に配備されるのは年に数回程度で、1度配備されたら実行環境に変更を加えることは稀でそのまま維持されるケースがほとんどでした。マイクロソフトやレッドハット等、OSベンダから提供された修正パッチを適用することはあっても、実行環境の構成変更は頻繁には行われないため、おのずと設定不備もおきなかったかと思われます。
ソフトウェアそのもののアーキテクチャの変化
直近の10数年で、ソフトウェアのアーキテクチャはこれまでのモノリシックからマイクロサービスが主流になってきたかと思います。全ての機能を1つのソフトウェアに実装するモノリシックに対して、マイクロサービスは機能毎にソフトウェアを細かく分割して実装します。分割実装された各々のソフトウェアは独立していて他のソフトウェアに依存していないため、個々のソフトウェアは各々がCICDプラットフォームを通じてクラウド環境に継続的に配備されます。VMやContainer等のワークロードや、VPCやSecurity Groupのようなネットワークやセキュリティの設定は常に変更が加えられ、設定不備は日常茶飯事で起きるようになってきたかと思います。
本当に設定不備だけ注視していれば充分なのか?
マイクロサービスで分割実装されたソフトウェアは継続的にCICDプラットフォームを通じてクラウド環境に配備されるようになり、同時にクラウド環境は常に変更されるようになりました。クラウド環境の設定不備は頭の痛い問題ですね。今一度、クラウド環境の設定不備と、その他のリスクの関連性を俯瞰してみたいと思います。下記のイメージは、Gartner社のMarket Guide for Cloud-Native Application Protection Platformsからの抜粋です。
このイメージが表現しているCloud Configurationが、この記事で述べている設定不備にあたります。他にもArtifact ScanniningとRuntime Protectionがあります。設定不備は3つの要素のうちの1つに過ぎません。記事の趣旨からそれるため、Artifact ScanningとRuntime Protectionの深掘りは割愛しますが、各々は、開発段階でソフトウェアが持っているリスク(例/Gitリポにシークレットをベタ書きしたファイルがある)を検出することと、クラウド環境に配備されたワークロードが持っているリスク(例/Malwareが混入している)を検出することです。
CNAPPとは?
前述したGartner社のドキュメントでは、CNAPPとは以下のように表現されています。
CNAPPs address the full life cycle protection requirements of cloud-native applications from development to production.
要約すると、Cloud Native Applicationを、開発から運用までの全てのライフサイクルにて守るになるかと思います。CNAPPが注視しているのはソフトウェアライフサイクル全般ですね。クラウド環境の設定不備だけではありません。
なぜライフサイクル全般を注視しなければならないのか?
前述したNISTのドキュメントに以下の一節があります。
*Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. *
クラウドとは、ダイナミックに変化するIT環境と言えるかと思います。では、何がダイナミックに変化させているのでしょうか? 私は、ソフトウェア(ここではソフトウェアとはビジネスアプリケーションとします)がそのようにさせていると思っています。ソフトウェアを配備するためには、それらの実行環境であるワークロードやネットワークやセキュリティが必要です。ソフトウェアはマイクロサービスで分割実装されていて、個々のソフトウェアは日に何度もクラウド環境に配備されます。環境はダイナミックに変化し続けますね。ソフトウェアは開発された時点で何らかのリスク(例/Gitリポにシークレットをベタ書きしたファイルがある)を持っています。クラウド環境の設定不備云々の問題ではありません。クラウド環境に配備されたワークロードにも、いつのまにかリスク(例/Malwareが混入している)が存在しているかと思います。これもクラウド環境の設定不備とは無関係です。ライフサイクル全般を注視しなければ、クラウド特有のリスクを最小化することは不可能と言えます。
なぜなぜ質問に最後までお付き合い頂きありがとうございました。いかなる言葉も、それが何を意味していてなぜそんな言葉が生まれたのか、背景まで遡ることで、言葉が持つ本当の意味が見えてくるかと思います。