CNAPPとは？CSPM・CWPP・CIEMとの関係と選定のポイント

CNAPPとは？意味・定義から導入メリット・選び方まで徹底解説

クラウドネイティブ開発が標準となった今、多くの企業が直面している課題があります。

CSPM、CWPP、CIEM、DAST、SBOM——セキュリティツールが乱立し、アラートは増え続け、本当に危険なリスクが埋もれてしまう。DevOpsチームとセキュリティチームの間には溝が生まれ、設定ミスや脆弱性への対応は後手に回る。

こうした課題へのアプローチとして注目されているのが CNAPP（Cloud Native Application Protection Platform） です。

本記事では、CNAPPの定義から構成要素、導入メリット、そして自社に合ったプラットフォームの選び方まで、実務に役立つ情報を体系的に解説します。

CNAPPとは？定義と基本概念

CNAPP（Cloud Native Application Protection Platform） は、Gartnerが2021年のInnovation Insightレポートで定義したセキュリティカテゴリです。日本語では「クラウドネイティブアプリケーション保護プラットフォーム」と訳されます。

CNAPPの本質は、クラウドネイティブアプリケーションのライフサイクル全体——コードの記述からCI/CDパイプライン、本番環境のランタイムまで——を統合的かつ継続的に保護することにあります。

従来のセキュリティツールは「クラウド設定の監視（CSPM）」「ワークロードの保護（CWPP）」など、特定のレイヤーに特化していました。CNAPPはこれらを統合し、コンテキストを共有しながらリスクを一元的に可視化・優先順位付けします。

CNAPPの核心は「ツールの統合」ではなく「リスク理解の統合」です。

設定ミス、過剰な権限、アプリケーション脆弱性——これらが単独で存在する場合と、同一リソースに集中している場合では、リスクの深刻度はまったく異なります。CNAPPはこの攻撃チェーンを横断的に把握し、実際に悪用される可能性の高いリスクを見つけやすくします。

ただし、CNAPPという名称だけで全製品の対応範囲が揃うわけではありません。たとえば、設定を点検できることと、稼働中の不審な動作を検知・遮断できることは別の機能です。MicrosoftによるCNAPPの解説でも、複数のセキュリティ機能を組み合わせる構成が示されています。

CNAPPを構成する4つのコア機能

CNAPPは単一のツールではなく、複数のセキュリティ機能を統合したプラットフォームです。主要な構成要素を理解することで、自社に必要な機能を見極められます。なお、各機能の対応範囲は製品によって異なり、IaCの検査やKubernetesの設定点検などを含む製品もあります。エージェントの有無、収集できる情報、実行時の防御範囲は製品ごとに確認が必要です。

CSPM（Cloud Security Posture Management）

クラウドインフラストラクチャの設定ミスやベストプラクティス違反を検出する機能です。ストレージの公開設定やログ設定など、クラウド構成の不備を確認します。

CSPMは本番環境の設定監視を中心とした機能ですが、CNAPP製品の中には、IaC（Infrastructure as Code）スキャンと組み合わせて開発段階から設定リスクを確認できるものもあります。その場合、Terraform、CloudFormation、Kubernetesマニフェストなどのコードレベルで問題を検出し、本番環境へのデプロイ前に修正を促せます。

CWPP（Cloud Workload Protection Platform）

コンテナ、仮想マシン、サーバーレス環境など、クラウドワークロードを保護する機能です。

CWPPの役割は、ビルド時のコンテナイメージスキャンから本番環境のランタイム保護まで多岐にわたります。CNAPPでは、CWPPで検出された脆弱性情報をCSPMやCIEMのデータと関連付けることで、実際の影響範囲を把握しやすくなります。

CIEM（Cloud Infrastructure Entitlement Management）

クラウド環境における過剰なIAM権限や特権アクセスを可視化し、最小権限の原則を実現する機能です。

権限の情報だけを見ても、その権限が悪用された場合の影響は判断しにくいことがあります。CNAPP製品の中には、過剰権限を持つリソースに設定ミスや脆弱性が存在するかどうかを組み合わせて評価し、攻撃者に悪用された場合の実際のリスクをスコアリングするものもあります。

脆弱性管理（SCA / SBOM）

アプリケーション層の脆弱性とソフトウェアサプライチェーンリスクを管理する機能です。

SCA（Software Composition Analysis）はオープンソースライブラリの既知の脆弱性を検出し、SBOM（Software Bill of Materials）はソフトウェアの構成要素を一覧化します。CNAPPでは、これらの情報をCI/CDパイプラインに組み込むことで、本番環境にデプロイされる前に脆弱性を検出・修正しやすくなります。

CNAPPと従来ツールの違い：比較表

上記は一般的な傾向です。連携できるデータや分析の範囲は製品ごとに異なるため、すべてのCNAPPで同じことができるわけではありません。

CNAPPがもたらす4つの導入メリット

1. リスクの可視化と優先順位付けの精度向上

CNAPPの最大の価値は、個別のアラートを「攻撃経路」として関連付けて評価できる点です。

たとえば、あるサーバーで既知の脆弱性が見つかったとします。同じサーバーがインターネットから到達可能か、重要なデータへアクセスできる権限を持つかを合わせて見られれば、単独のリスクではなく「攻撃につながりやすい経路」として評価でき、担当者は修正の順番を決めやすくなります。S3バケットの公開設定（CSPMで検出）と過剰なIAM権限（CIEMで検出）が同じアプリケーションに関係する場合も同様です。これは判断の例であり、すべてのCNAPPで同じ分析ができるという意味ではありません。

インターネットへの露出度、データの機密性に加え、実際の悪用が確認されているか（CISAのKEVカタログへの掲載など）や、今後30日間に悪用される可能性の推定（FIRSTのEPSS）なども考慮して総合的に評価することで、修復すべき対象が明確になります。

2. SOCとDevOpsの連携強化

アラートが統合され、コンテキストが付与されることで、DevOpsチームが自らセキュリティ対応を進めやすくなります。

IaCの修正、コンテナイメージの更新、権限の縮小——これらの対応をDevOpsチームが直接行うことで、SOCは緊急性の高いインシデント対応に集中しやすくなります。修正案を確認し、変更の影響を検証してから反映する手順も合わせて決めておくと、セキュリティが「ブロッカー」ではなく「イネーブラー」として機能する体制に近づきます。

3. TCO（総所有コスト）の最適化

複数ツールのライセンス費用、個別の運用工数、ツール間連携の開発コストを抑えられる場合があります。ただし、課金対象がアカウント数、資産数、実行時間のどれなのかや、既存のEDR・監視ツールとの役割の重複によって、費用の見え方は変わります。

また、アラートの優先順位付けにより、対応工数そのものを減らせます。「すべてのアラートに対応する」から「本当に危険なリスクに集中する」へのシフトは、限られたセキュリティリソースの有効活用につながります。

4. DevSecOpsの実現

開発者がCI/CDパイプライン内でセキュリティ結果を確認できる環境が整います。

プルリクエスト時点で脆弱性や設定ミスがフィードバックされれば、本番環境にリスクが持ち込まれる前に修正しやすくなります。「セキュリティは後工程」から「セキュリティは開発の一部」への転換を後押しします。

CNAPPだけでは解決できない3つの課題

CNAPPは強力なプラットフォームですが、すべてのクラウドセキュリティ課題を解決するわけではありません。導入前に理解しておくべき限界があります。

課題1：管理外資産（シャドーIT）の把握

CNAPPはクラウドアカウントに接続して資産を監視しますが、管理外のクラウドリソース——未承認のテスト環境、放置されたサブドメイン、開発者が個人アカウントで作成したリソース——は監視対象外です。

これらの管理外資産は攻撃の入口になり得ます。外部からの視点で攻撃対象領域を把握する ASM（Attack Surface Management） との併用が有効です。

課題2：実行中アプリケーションの動的脆弱性

CSPMはインフラ設定、SCA/SBOMは既知の脆弱性を検出しますが、アプリケーション固有の欠陥——認証バイパス、ビジネスロジックの脆弱性、APIの不適切な実装——は検出できません。

実行中のアプリケーションに対して疑似攻撃を実施する DAST（Dynamic Application Security Testing） により、OWASP Top 10に代表されるWebアプリケーション脆弱性を実環境で検証する必要があります。ただし、ビジネスロジックの欠陥のように、自動化された検査だけでは見つけにくいものもあるため、対象に応じて確認方法を組み合わせます。

課題3：サプライチェーン全体のリスク

SBOM機能は自社アプリケーションの依存関係を可視化しますが、サードパーティベンダーのセキュリティ状況——利用しているSaaSの脆弱性、委託先のセキュリティ体制——は対象外です。

サプライチェーン全体のリスクを管理するには、TPRM（Third-Party Risk Management） の観点も必要になります。

CNAPPプラットフォームの選び方：5つの評価軸

市場には多くのCNAPPソリューションが存在します。自社に合ったプラットフォームを選定するための評価軸を解説します。

評価軸1：エージェントレス vs エージェントベース

エージェントレス方式は、クラウドAPIなどを通じて情報を取得するため、導入が容易で運用負荷が低いのが特徴です。一方、ランタイムの詳細な監視には限界があります。

エージェントベース方式は、ワークロードにエージェントをインストールすることで、リアルタイムの脅威検出やプロセスレベルの可視化が可能です。ただし、導入・運用の工数が増加し、対応OSや性能への影響も確認が必要です。

エージェントレスをベースに、重要なワークロードにのみエージェントを導入するハイブリッドアプローチも、現実的な選択肢の一つです。いずれの方式でも、検知、通知、遮断のどこまでできるかを分けて確認します。

評価軸2：マルチクラウド対応

AWS、Azure、GCPなど複数のクラウドを利用している場合、統一されたポリシー管理と可視化が重要です。各クラウドの機能差異を吸収し、一貫したセキュリティ基準を適用できるか、利用中のクラウドとサービスが必要な深さまで検査対象になっているかを確認してください。

評価軸3：CI/CDパイプラインとの統合

GitHub Actions、GitLab CI、Jenkins、CircleCIなど、自社で利用しているCI/CDツールとの統合が容易かどうかを確認します。開発者の既存ワークフローを大きく変更せずにセキュリティを組み込めることが、DevSecOps成功の鍵です。

評価軸4：リスクスコアリングのロジック

単純な重大度（Critical/High/Medium/Low）だけでなく、攻撃経路、露出度、悪用の状況（KEVへの掲載や、EPSSによる悪用可能性の推定）、資産の重要度などを組み合わせたコンテキストベースのスコアリングが可能かを確認します。EPSSのスコアは悪用される確率の推定値で、パーセンタイルは他のCVEと比べた順位を示す別の値です。製品がどちらを使っているかも確認しておくと、結果を読み違えにくくなります。

たとえば「Critical脆弱性が1,000件」というアラートと「実際に攻撃可能な経路が3件」というアラートでは、対応の優先順位がまったく異なります。

評価軸5：日本語サポートと国内実績

海外製品を選定する場合、日本語ドキュメント、日本語サポート、国内での導入実績を確認することをお勧めします。とくにインシデント発生時の迅速なコミュニケーションは、言語の壁が大きな障壁となりえます。

導入前に確認したいこと

5つの評価軸に加え、運用面では次の点も確認しておきます。

• 検知に必要な権限、ネットワーク接続、エージェント設置の条件は何か。
• 修正案を確認し、変更の影響を検証してから反映できるか。
• 既存のEDRや監視、チケット管理と役割が重複しないか。
• 課金対象がアカウント数、資産数、実行時間のどれなのか。

評価環境では、実際の設定不備を1件選び、検知から担当者への連絡、修正後の確認まで試すと、運用上の不足を見つけやすくなります。

Securifyで確認できる領域と役割分担

Securifyは、公開資産のASM、内部資産のIASM、Webアプリケーション・APIの脆弱性診断、クラウド設定のCSPM、ソフトウェア構成のSBOMなどを提供しています。CNAPPを構成する領域のうちクラウド設定とソフトウェア構成を扱い、あわせて前述の課題1・2で挙げた管理外資産の把握やアプリケーションの動的な診断を補う役割を担います。

ASM：外部公開資産を把握

Securify ASMは、ドメイン・IP・クラウドを起点に、インターネットに公開された自社の資産を発見します。クラウドアカウントと連携すると外部に公開されたリソースを一覧で確認でき、ポートスキャンで外部からアクセスできるポートも検出します。管理漏れや不要な公開を確認し、脆弱性診断につなげられます。

攻撃者と同じく外部からの視点で自社の露出状況を把握することで、クラウドアカウント内の設定を点検するCSPMだけでは見えにくい資産にも気づけます。

脆弱性診断：実行中のWebアプリケーション・APIを診断

Securifyの脆弱性診断は、WebサイトやAPIに疑似攻撃を実行し、SQLインジェクションやクロスサイトスクリプティング（XSS）、認証・アクセス制御の不備などを調べる動的な診断（DAST）です。認証が必要な画面、REST・GraphQL API、SPAにも対応し、検出した脆弱性の根拠と修正例を日本語で示します。

診断スケジュールによる定期診断や、APIからの診断の起動にも対応しているため、既存の開発・運用の仕組みに診断の実行を組み込めます。

CSPM：複数クラウドの設定ミスを継続監視

Securify CSPMは、AWS・Google Cloud・Microsoft Azure・さくらのクラウド・Oracle Cloud・Cloudflareの6つのクラウドに対応し、ストレージの公開設定や権限の不備、暗号化の不備などの設定ミスを継続監視します。違反したポリシーと修正手順を確認でき、CISベンチマークなどの基準への準拠状況も把握できます。適用するチェック項目は、クラウドサービスやリソースの種類によって異なります。

製品間の連携：公開状態と重要度を踏まえた優先順位付け

Securify CSPMは、本番・検証・開発など環境の性質に合わせて設定した重要度や、資産の公開状態を関連付けて設定ミスを評価し、対応の優先順位を示します。Securify SBOMは、リポジトリ・コンテナ・クラウドから構成情報を収集して脆弱性情報と照合し、ASM・CSPMとの連携で脆弱な部品を使う稼働資産を把握します。外部に公開されたサービスで使われているかを踏まえて、対応の優先順位を付けられます。

一方、稼働中のワークロードの監視や攻撃の遮断（CWPP）、権限の利用状況の分析や最小権限ポリシーの自動生成（CIEM）、権限の自動修正などを求める場合は、必要な機能と対応範囲を個別にご確認ください。既存のEDRや監視ツールを含め、何を検知し、誰が調べ、どの手段で対処するかを整理すると、製品間の重複や不足が分かりやすくなります。

まとめ

クラウドネイティブ時代のセキュリティは、ツールの数を増やすことではなく、リスクの理解を統合することで強化されます。

CNAPPは、サイロ化したセキュリティツールを統合し、攻撃経路を考慮したリスク評価を実現するプラットフォームです。ただし、管理外資産の把握やアプリケーション層の動的テストなど、CNAPPだけでは対応できない領域も存在します。また、CNAPPと呼ばれる製品でも対応範囲は異なるため、必要な機能を個別に確認することが欠かせません。

自社のクラウド環境とセキュリティ要件を踏まえ、CNAPPをベースに必要な機能を拡張していくアプローチが、現実的かつ効果的な選択肢です。

次のステップ

クラウドセキュリティの現状を把握することが、改善への第一歩です。

Securifyでは、利用中のクラウドやアカウント数に合わせて、CSPMの連携方法と料金をご案内しています。ASM・脆弱性診断・SBOMとの組み合わせについてもご相談いただけます。自社の環境で実際の画面を操作できるトライアル（PoC）も受け付けています。

ご興味のある方はぜひお問い合わせください。

→ Securifyの詳細はこちら