NTT Security Japan

お問い合わせ

クラウドを守る「CWPP」とは?導入後に直面する壁とアラート対応の解決策

セキュリティマガジン

クラウドを守る「CWPP」とは?導入後に直面する壁とアラート対応の解決策
クラウドの活用が進む中、サイバー攻撃の手口もクラウド環境に特化したものへと進化しています。ファイアウォールなどの境界防御をすり抜け、クラウド内部に侵入された場合にシステムを守り抜くことができるかどうかが、企業のセキュリティ対策における大きな焦点となっています。
本記事では、クラウド上で稼働するシステム本体(ワークロード)をサイバー攻撃から守るためのソリューション「CWPP(Cloud Workload Protection Platform)」について、従来型セキュリティやCSPMとの違い、そして開発スピードを落とさずに運用するDevSecOpsの仕組みまでをわかりやすく解説します。



CWPPとは?CSPMや従来型セキュリティとの決定的な違い

CWPPは、クラウド上で稼働する仮想サーバー、コンテナ、サーバーレスといったワークロードを保護するためのセキュリティプラットフォームです。

従来のセキュリティが最新のクラウド環境で通用しない理由

従来のアンチウイルスソフトやファイアウォールは、「IPアドレスが固定された長期間稼働するサーバー」を守ることを前提に設計されています。しかし、数分から数時間で自動的に生成・消滅を繰り返すクラウド環境においては、従来の重いスキャン機能や固定的なネットワーク監視では動的なクラウド環境に追いつかず、機能不全に陥ってしまいます。

CSPMとの決定的な違い

クラウドセキュリティの領域には「CSPM(Cloud Security Posture Management)」というツールも存在しますが、両者は「守る対象」が明確に異なります。

  • CSPM【インフラの外側】: ネットワークの公開設定やアクセス権限など、「設定ミス」を監視するツール
  • CWPP【インフラの内側】: クラウド内で稼働しているシステムやアプリケーション本体を攻撃から守るツール

つまり、CSPMが環境の不備を塞ぐ役割であるのに対し、CWPPは環境内で動いているシステムを守る役割を担っています。

「ワークロード保護」が必須とされる背景

クラウドの利用形態がIaaS(仮想サーバー)だけでなく、コンテナやサーバーレスアーキテクチャへと進化するにつれ、ユーザーが直接OSを管理できない環境が増加しています。このようなインフラを持たない環境に対しては、エージェント型セキュリティが使えない、OS前提の防御が成立しないという課題が発生するため、ワークロード全体を保護できるCWPPが必須となっています。

CWPPは“設定ミス対策”ではなく、“侵入後の検知・防御”を担う

万が一クラウド内部へ侵入された場合、最後にシステムを守る砦となるのがCWPPです。設定の不備を指摘するだけでなく、稼働中のマルウェアの実行を阻止するなど、「侵入された後の脅威」に対して直接的な検知・防御を行います。

クラウド内部を可視化・防御する3つの主要機能

クラウド内部の多様な環境を保護するため、CWPPは主に3つの強力な機能を備えています。

①マルチクラウド・ハイブリッド環境の「統合的な可視化」

AWS、Azure、Google Cloudといった複数のパブリッククラウドに加え、自社のオンプレミス環境を含めて一つのダッシュボードに統合します。どこで、どのようなワークロードが稼働しているのかを正確に把握することで、セキュリティの死角となる「管理外のサーバーやコンテナ」を無くし、一元的な保護体制を構築します。

②OSからコンテナ・サーバーレスまでの「脆弱性・構成管理」

可視化されたすべてのワークロードに対して、OS、ミドルウェア、アプリケーションのライブラリに潜む脆弱性を継続的にスキャンします。コンテナイメージやサーバーレスの関数コードまで幅広く解析し、システムの穴を塞ぐための構成管理を行います。

③稼働中のマルウェア検知や異常な振る舞いの「実行制御・保護」

システムが実際に稼働している状態において、不審なプロセスの起動や未知のマルウェアの実行などの「異常な振る舞い」をリアルタイムで検知します。脅威を検知した際は、単にアラートを上げるだけでなく、該当するプロセスを即座に強制終了させるなど、被害の拡大を自律的に防ぎます。

進化する「3つのワークロード」と特有の脅威

ワークロードが直面する「根本的なリスク」

クラウドの実行環境がどのように進化しようとも、サイバー攻撃者が狙う根本的な弱点は変わりません。IPAの「情報セキュリティ10大脅威」が示す通り、「ランサム攻撃(1位)」と「脆弱性を突いた攻撃(4位)」は長年企業を脅かし続けています。これらの脅威に対して、CWPPは効果的に無力化します。

順位

「組織」向け脅威

初選出年

10大脅威での取り扱い(2016年以降)

1

ランサム攻撃による被害

2016年

11年連続11回目

2

サプライチェーンや委託先を狙った攻撃

2019年

8年連続8回目

3

AIの利用をめぐるサイバーリスク

2026年

初選出

4

システムの脆弱性を突いた攻撃

2016年

6年連続9回目

5

機密情報等を狙った標的型攻撃

2016年

11年連続11回目

6

地政学的リスクに起因するサイバー攻撃(情報戦を含む)

2025年

2年連続2回目

7

内部不正による情報漏えい等

2016年

11年連続11回目

8

リモートワーク等の環境や仕組みを狙った攻撃

2021年

6年連続6回目

9

DDoS攻撃(分散型サービス妨害攻撃)

2016年

2年連続7回目

10

ビジネスメール詐欺

2018年

9年連続9回目

出典:IPA「情報セキュリティ10大脅威 2026 [組織]」を基に作成
https://www.ipa.go.jp/security/10threats/10threats2026.html

IaaS:ランサムウェア脅威からの保護と一元管理

IaaS環境は従来のオンプレミスサーバーと構造が似ているため、ランサムウェア攻撃の標的になりやすい領域です。CWPPは、稼働中の仮想サーバーに対するランサムウェアの侵入や不審な暗号化プロセスをリアルタイムで検知し、即座に遮断することができます。

コンテナ:デプロイ前のイメージに潜む脆弱性の検知

コンテナ環境において最も警戒すべきは、脆弱性を突いた攻撃です。開発者が利用するオープンソースのコンテナイメージには、あらかじめ脆弱性が含まれていることが少なくありません。CWPPは、このイメージが本番環境にデプロイされる前にスキャンを行い、脆弱性を持ったまま稼働し始めるのを未然に防ぎます。

サーバーレス:インフラレス環境での過剰権限や不正コード実行の防御

OSの管理が不要なサーバーレス環境では、インフラへの直接攻撃が難しいため、アプリケーションのコードや付与された権限が狙われます。CWPPは、サーバーレス関数に対する過剰な権限付与のリスクを評価し、不正なコード挿入や意図しない外部通信を監視・ブロックすることで、インフラレス特有の脅威から保護します。

なぜ従来のEDRではダメなのか?CWPPが解決する3つの課題

PCやサーバーの挙動を監視するEDR(Endpoint Detection and Response)も優秀なツールですが、クラウドネイティブな環境にそのまま適用しようとすると、3つの課題に直面します。

課題①:起動後のスキャンでは、数分で消滅するコンテナに間に合わない

数分単位で生成と消滅を繰り返すコンテナに対し、起動してからスキャンを開始する従来のEDRでは、脅威を発見した頃にはすでにコンテナが消滅し、攻撃が完了しています。一方、CWPPは稼働後ではなく、コンテナの元となる「起動前のイメージ」の段階でスキャンを完了させるため、この時間的な制約を構造的に克服します。

課題②:エージェントがリソースを消費し、処理速度が低下する

全サーバーに監視用ソフトウェアをインストールする従来手法は、システム全体のリソースを消費し、クラウド本来の処理速度やスケーラビリティを損ないます。一方、CWPPはクラウド事業者のAPIやスナップショット技術を活用したスキャンに対応しており、システムに負荷をかけずに広範囲な監視を実現します。

課題③:ファイアウォールでは、コンテナ間の通信が見えない

クラウド内部で稼働するコンテナ同士の通信は、従来のファイアウォールでは監視できません。一方、CWPPはクラウド内部の構造をマッピングし、コンテナ間の通信を可視化・制御することで、侵入したマルウェアが内部で横展開(ラテラルムーブメント)していくのを確実に食い止めます。

結論:EDRは“人が使う端末”、CWPPは“自動で生まれる計算資源”向け

EDRは社員が操作するPCや固定的なサーバーといった「人が使う端末」を守るのに適しています。一方でCWPPは、システムによって秒単位で動的に生成・破棄される「自動で生まれる計算資源」を守るために最適化された、全く異なるアプローチのセキュリティソリューションと言えます。

CWPPが実現する「DevSecOps」3つの保護サイクル

セキュリティチェックのせいで開発スピードが落ちることは致命的です。CWPPは開発パイプライン(CI/CD)とシームレスに連携し、開発・配備・稼働の3つのサイクルでセキュリティを自動化する「DevSecOps」を実現します。

サイクル

フェーズ

CWPPの主な役割・対策

Build(開発時)

コード記述・ビルド直後

脆弱性スキャンの自動実行(シフトレフトの実現)

Deploy(配備時)

本番環境へのリリース直前

基準違反や脆弱性が残るイメージのリリース自動ブロック

Run(稼働時)

本番環境での稼働中

未知の脅威や異常な振る舞いの検知と即時遮断

Build:コード記述直後の脆弱性スキャン

開発者がコードを書き、リポジトリにプッシュしてビルドを行った直後のタイミングで、CWPPが自動的に脆弱性スキャンを実行します。セキュリティテストの工程を開発の初期段階へと前倒しする「シフトレフト」のアプローチにより、手戻りのコストを最小限に抑えながら安全なコード開発を支援します。

Deploy:脆弱性が残るコンテナイメージのリリースを自動ブロック

開発環境でのテストを終え、本番環境へデプロイされる直前の関所として機能します。自社が定めたセキュリティ基準を満たしていないコンテナイメージや、脆弱性が残存しているワークロードがリリースされようとした場合、CI/CDパイプライン上で自動的にブロックし、安全性が担保されたものだけを本番環境へ送り出します。

Run:稼働中ワークロードの異常検知と即時遮断

どれだけ事前のチェックを厳重に行っても、稼働後に未知のゼロデイ脆弱性が発見されるリスクはゼロにはなりません。そのため、本番環境で実際に稼働しているワークロードに対しても継続的なモニタリングを行い、不審なプロセスの立ち上がりやマルウェアの活動を検知した瞬間にネットワークからの隔離や即時遮断を行い、被害を最小限に抑えます。

まとめ:クラウドの恩恵を損なわずに、内側からの脅威を防ぐ

CWPPは、クラウド環境の柔軟性とスピードを一切損なうことなく、システム内部の実行環境をサイバー攻撃から守り抜くクラウド時代の「内部防御エンジン」です。設定ミスを防ぐCSPMだけではカバーしきれない「侵入された後の脅威」に対して、強力な可視化と実行制御を提供します。これからのクラウドセキュリティにおいては、外側を守るCSPMと内側を守るCWPPを個別に運用するのではなく、両者を統合し、包括的にクラウド全体を保護する「CNAPP(Cloud Native Application Protection Platform)」の形を目指すことが理想的なアプローチとなります。

関連記事:【CNAPPとは】クラウドセキュリティの課題を解決する統合プラットフォーム

【ホワイトペーパー】
人材不足・複雑化する脅威にどう立ち向かう?
MDRアウトソーシングで乗り越えるセキュリティ運用の壁

ホワイトペーパー
ダウンロード

関連記事 / おすすめ記事

Inquiry

お問い合わせ

お客様の業務課題に応じて、さまざまなソリューションの中から最適な組み合わせで、ご提案します。
お困りのことがございましたらお気軽にお問い合わせください。