CWPPとは？ワークロード保護の役割とCSPMとの違い

CWPP（Cloud Workload Protection Platform）とは何か？

CWPP（Cloud Workload Protection Platform）とは、クラウド環境で動作しているサーバーやコンテナなど、アプリケーションが動く「中身」を守るためのセキュリティ製品群です。簡単に言えば、クラウド上のワークロードを悪意ある攻撃から保護するためのプラットフォームです。構成や既知の脆弱性の検査、稼働中の動作の監視などを扱い、製品によっては仮想マシンからコンテナ、サーバーレスまで、さまざまな形態のワークロードを対象とします。ただし、提供する機能や対象は製品によって異なります。参考：MicrosoftのCWPP解説
（ワークロード‥ 処理や作業の単位。クラウド上で動いているプログラムやアプリケーション、それらが動くサーバー環境全体を指します。）

では、具体的に何を守るのでしょうか？CWPPが守る主なワークロードには次のようなものがあります。

仮想マシン（VM）：Amazon EC2やAzure Virtual Machinesなど、クラウド上の仮想サーバーです。従来のサーバーに近い形で、基幹システムをこうした環境へ移行する企業も増えています。

コンテナ：仮想サーバーよりも軽量で、素早く起動できるプログラムの実行環境です。マイクロサービス化の流れとともに広く使われるようになりました。起動が速く効率的な一方で、短い寿命と動的な特性がセキュリティ管理を難しくしています。

サーバーレス関数：AWS LambdaやAzure Functionsのような、必要な時だけ動く関数です。インフラ管理が不要なメリットがある反面、実行環境の中が見えづらく、サーバーにエージェントを入れる従来型のセキュリティ対策をそのまま適用できません。

これらはそれぞれ特徴が異なり、直面する脅威も違います。CWPPはこの多様なワークロードを統一的な方法で守ることを目指しています。

なぜ今、CWPPが必要なのか？2つの背景

1. ワークロードが多様化し、短命になっている

クラウドネイティブ技術が広く使われるようになり、ワークロードの性質が大きく変わりました。特にコンテナやサーバーレス環境では、ワークロードが短時間で作成・破棄される「短命」な特徴を持っています。

たとえば、ECサイトの大規模セール時には、アクセス増加に合わせて自動的にコンテナが増え、ピークが過ぎると自動的に減ります。こういった環境では、エージェントの導入を前提とした従来型のセキュリティツールが、導入の完了前にワークロードが消えてしまうといった問題に直面することがあります。また、コンテナイメージの開発から本番環境への展開までが高速化しており、リリースごとにセキュリティチェックの時間を確保しにくくなっています。

2. クラウド利用企業が負う責任の範囲

AWS、Azure、Google Cloudなどのクラウドプロバイダーは「責任共有モデル」という考え方を採用しています。たとえばIaaSの仮想マシンであれば、物理インフラやハイパーバイザーの安全性はクラウド事業者が担保する一方、その上で動くOS、ミドルウェア、アプリケーション、データの保護はユーザー側の責任です。どこまでが利用者の責任になるかは、利用するサービスの種類によって変わります。

しかし、この境界線があいまいなまま、「クラウドだから安全」と考えてワークロードレベルの対策が手薄になっているケースもあります。利用者側の責任範囲で起きる設定ミスや管理不備は、クラウド事業者の対策ではカバーされません。このうち、ワークロードの中身に関わる部分を補うのが、CWPPの役割です。

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

主要機能

CWPPは、ワークロードを多層的に保護するため、主に以下のような機能を提供します。どの機能を備えているか、検知だけか遮断まで行えるかは製品によって異なります。

脆弱性管理：OSやミドルウェア、アプリケーションフレームワークに存在する既知の脆弱性を継続的にスキャンし、CVE（共通脆弱性識別子）で識別される脆弱性情報と照合します。リスクレベルに応じた優先順位付けを行い、パッチ適用の計画を支援します。

マルウェア対策：シグネチャベースの検知に加え、振る舞い検知などを組み合わせて、既知のパターンに当てはまらない不審なプログラムの検出を図る製品もあります。設定によっては、不正なプログラムの実行をブロックします。

ランタイム保護（不正侵入検知・防御）：稼働中のワークロードの挙動を監視し、異常なプロセスの起動、不審なネットワーク通信、ファイルシステムの改ざんなどを検知します。製品や設定によっては、検知したワークロードの隔離や通信の遮断まで行います。

コンプライアンス対応の支援：OSやコンテナの設定を、セキュリティ基準やベンチマークに照らして継続的に点検し、PCI DSS、HIPAA、ISO/IEC 27001、SOC 2などへの対応状況を確認する材料としてレポートを出力できる製品もあります。ただし、ツールの点検結果だけで、これらの基準への準拠や認証取得が保証されるわけではありません。

コンテナ/サーバーレスセキュリティ：Dockerイメージの脆弱性スキャン、Kubernetes上での異常な権限昇格の検知、Lambda関数の過剰な権限の特定など、クラウドネイティブ技術特有のセキュリティ課題に対応する製品もあります。

エージェント方式とエージェントレス方式

CWPPの情報収集には、大きく分けてエージェント方式とエージェントレス方式があります。エージェント方式では、対象にソフトウェアを配置して情報を取得します。導入・更新の手間、対応OS、性能への影響を確認します。エージェントレス方式では、クラウドAPIやスナップショットなどを使う場合がありますが、取得頻度や観測できる情報は実装によります。

「エージェントレスだから実行時の攻撃をすべて防げる」「エージェントがあれば全対象を監視できる」とは限りません。検知、通知、遮断のどこまでできるかを分けて確認することが必要です。

【徹底比較】CSPM、CIEMとの違いは？クラウドセキュリティの全体像

クラウドセキュリティの世界では、CWPP以外にもCSPM、CIEMといった重要なソリューションが存在します。これらは互いに補完関係にありながら、それぞれ異なる領域をカバーしています。以下の比較表で、各ソリューションの役割を整理しましょう。

CSPMは、クラウドの管理設定に不備がないかを点検します。たとえば、ストレージの公開範囲や監査ログの設定です。CWPPでは、その環境で動くOSやコンテナ、プロセスなどが主な確認対象になります。公開設定が適切でも、サーバーに脆弱なソフトウェアが残る場合はあります。逆にOSを更新しても、クラウドのアクセス設定が広すぎる問題は残り得ます。どちらか一方の結果だけで、環境全体の安全性を判断することはできません。

これらの個別ソリューションを組み合わせた考え方として、CNAPP（Cloud Native Application Protection Platform）が注目を集めています。CNAPPは、CWPP、CSPM、CIEMなどの機能を一つの製品群としてまとめ、クラウドセキュリティの状況を横断的に把握・管理することを目指すものです。ただし、CNAPPという名称だけで全製品の対応範囲が揃うわけではなく、含まれる機能は製品によって異なります。

CWPPの限界と次世代アプローチ

CWPPはワークロードを守るうえで重要なツールですが、単体では対応しきれない課題があります。クラウド環境を守るには、複合的な対策が必要です。

課題1：クラウド設定の不備

どんなに高性能なCWPPを導入していても、クラウドの設定自体に問題があれば、攻撃の入口が残ります。例えば、管理用SSHポートが公開されていれば、攻撃者に侵入口を与えてしまいます。CWPPは侵入後の不審な活動を検知できますが、入口となるクラウド設定そのものを直すことは主な役割ではありません。

この問題に対応するのがCSPMです。CSPMはクラウド設定を継続的に監視し、業界標準などに照らして不適切な設定を検出します。修正の方法は、手順の提示から自動修正まで製品によって異なります。CWPPとCSPMは互いに補完し合い、多層的な防御を構築します。

課題2：アプリケーションの脆弱性

CWPPは主にOSやミドルウェアの脆弱性を対象とします。製品によってはコンテナイメージに含まれるライブラリも検査しますが、自社開発コードの脆弱性や、開発段階の依存関係まで確認できるとは限りません。多くのアプリケーションはオープンソースのライブラリを組み合わせて作られており、ライブラリの脆弱性はアプリケーション側の更新で対処する必要があります。

この課題に対しては、SBOMでコンポーネントの依存関係を可視化し、DASTで実際のアプリケーション動作環境を検査することが効果的です。前者は構成要素を明確にし、後者は実環境での脆弱性を発見します。

課題3：管理外のIT資産

「シャドーIT」と呼ばれる管理外の資産が攻撃の入口になることがあります。開発者が一時的に立ち上げたサーバーや、退職者が残したクラウドリソースなど、把握していない資産には当然ながらセキュリティ対策も行き届いていません。

ASM（Attack Surface Management）は外部から自社の公開資産を探索し、潜在的なリスクを発見します。定期的なスキャンで新たに公開された資産や、証明書切れ、古いソフトウェアなどの問題を早期に特定しやすくなります。

CWPPを選ぶときに確認したいこと

CWPPは製品によって対象や機能の範囲が大きく異なります。評価環境では、次のような点を実際に試して確認するとよいでしょう。

• 実際に使うOS、コンテナ実行基盤、サーバーレス環境が対象になるか
• 短時間で作成・破棄される資産を、どのタイミングで収集するか
• 脆弱性のあるイメージを見つけた後、稼働先と担当チームをたどれるか
• 誤検知の確認や例外登録を、既存の監視運用と合わせられるか
• 遮断を有効にする場合、業務影響の検証と解除手順があるか

既存の監視やEDRを含め、何を検知し、誰が調べ、どの手段で対処するかを整理すると、製品間の重複や不足が分かりやすくなります。

結論：CWPPの重要性と統合アプローチの必要性

これまで説明してきたように、CWPPはクラウドワークロードを保護するうえで重要なソリューションです。脆弱性管理、マルウェア対策、ランタイム保護などの機能によって、ワークロード内部の脅威からシステムを守ることができます。

ただし、クラウドセキュリティには様々な課題があります。インフラの設定ミス（CSPM）、過剰な権限付与（CIEM）、管理外の公開資産（ASM）、ソフトウェアサプライチェーンのリスク（SBOM）、アプリケーションの脆弱性（DAST）など、多角的な対応が求められます。これらに別々のツールで対応すると、運用が複雑になり、コストも増えがちです。さらに、ツール間でアラートを関連付けにくいため、重要な脅威を見逃してしまう恐れもあります。

今後のクラウドセキュリティでは、これらの機能をまとめて管理するCNAPP（Cloud Native Application Protection Platform）のような考え方も選択肢になります。単一のツールにまとめるか、複数のツールを組み合わせるかにかかわらず、どの領域を何で守り、結果をどう関連付けて優先度を判断するかを決めておくことが、日々複雑化するクラウド環境に対応するための鍵といえるのではないでしょうか。

クラウドセキュリティの対策範囲を見直しませんか？

弊社が提供する「Securify」は、外部公開資産を管理するASM、クラウド設定を監視するCSPM、ソフトウェアの構成と脆弱性を管理するSBOM、WebサイトやAPIを診断する脆弱性診断などを提供しています。Securify SBOMではソフトウェア構成と関連するOSSのリスク、Securify CSPMではクラウド設定のリスクを確認できます。稼働中のプロセスの監視や攻撃の遮断を含むCWPPの機能とは対象範囲が異なるため、既存のCWPPやEDRと役割を分けて比較してください。

「自社のセキュリティにどこか穴があるか不安」「複数のツール管理に疲弊している」「クラウド移行は進んだが、セキュリティが追いついていない」――このような課題をお持ちでしたら、ぜひお気軽にご相談ください。

対象となるクラウドや資産に合わせて、利用できる機能と料金をご案内します。

クラウドセキュリティは、もはや「オプション」ではありません。ビジネスの成長と継続性を支える「基盤」です。ワークロード、クラウド設定、公開資産、ソフトウェア構成のそれぞれに目を配り、安心してクラウドの恩恵を活用できる環境を、共に構築していきましょう。

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