--- title: "CNAPとは？CNAPPとの違い・5つの構成要素とTrivy・Security Hubで試す手順、採用判断" url: "https://www.issoh.co.jp/tech/details/13257/" published: 2026-07-07 updated: 2026-09-27 categories: ["セキュリティ"] publisher: "株式会社一創" --- # CNAPとは？CNAPPとの違い・5つの構成要素とTrivy・Security Hubで試す手順、採用判断 CNAPは、コンテナやマイクロサービスで作られたクラウドネイティブなシステムを守るために、これまで別々の製品だったセキュリティ機能を1つの基盤へ束ねる考え方です。正式にはCNAPP（Cloud-Native Application Protection Platform）と呼ばれ、CSPM・CWPP・CIEMといった略語の機能を統合します。この記事では、CNAPとCNAPPの関係、5つの主要コンポーネント、CSPM単体との違い、TrivyやAWS Security Hub CSPMで今日から試せる点検コマンド、そして自社が導入すべきかどうかの判断基準までを、システムを作る側の視点で整理します。読み終えたとき、どの機能から着手すべきかを自分で線引きできるはずです。 ## まとめ：CNAPはCSPM・CWPP・CIEMを統合するクラウド保護基盤 CNAP（CNAPP）は、クラウド構成の点検を担うCSPM、稼働中ワークロードを守るCWPP、権限を管理するCIEMなど、個別に発展してきた機能を1つのプラットフォームへ集約したものです。単体ツールを並べると、それぞれが大量のアラートを出し、どれが本当に危険かを人が判断しきれなくなります。CNAPは検出結果を攻撃経路の文脈でつなぎ、優先すべきリスクを絞り込みます。 ただし全社に一律で必要なわけではありません。マルチクラウドでコンテナを本番運用し、単体ツールの運用が破綻している企業には効きますが、単一クラウドで小規模なら各クラウド標準機能で足ります。製品を契約する前に、無償のTrivyでIaCを点検し、AWSならSecurity Hub CSPMの30日間無料トライアルで検出の量を測る。この2つで自社の穴の大きさは見えます。 ## CNAPとCNAPPの定義とクラウドセキュリティでの位置づけ CNAPという略語は、クラウドセキュリティの新しいカテゴリを指すときに使われます。多くの場面でCNAPPと同じ対象を意味しており、両者を区別せず読んでも実務上は困りません。まずは言葉の関係と、従来型の守り方が通じない理由から押さえます。 ### CNAPとCNAPPの関係と、なぜ名称のゆれが生じたのかの整理 CNAPPは「Cloud-Native Application Protection Platform（クラウドネイティブ・アプリケーション保護プラットフォーム）」の頭文字です。ここから末尾のP（Platform）を省いた略記がCNAPで、概念そのものを指すときや口頭・検索で短く書くときに現れます。日本語の検索では両方が同じ領域を指し、ベンダーの解説記事もCNAPPで統一している例が中心です。Microsoftも公式ドキュメントで[Defender for CloudをCNAPPと位置づけ、CSPM・DevSecOps・CWPPの3つを中核に挙げています](https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-cloud-introduction)（2026年8月更新の版）。この記事でも、機能の集合体を指すときはCNAPPと表記し、考え方を指すときにCNAPを用います。名称のゆれ自体に技術的な差はありません。 ### クラウドネイティブ環境で従来型のセキュリティが通用しない理由 オンプレミス時代の防御は、社内と社外の境界にファイアウォールを置く発想が中心でした。コンテナは数秒で起動して消え、サーバーレスは実行のたびに環境が変わり、権限はクラウドのAPIキーやロールで細かく分かれます。守る対象が固定的な「サーバー」から、絶えず生成・破棄される「構成と権限」へ移りました。境界を固める従来型では、この動きの速さと分散に追いつけません。構成・ワークロード・権限を横断して継続的に点検する仕組みが必要になったのは、この変化のためです。 ### GartnerがCNAPPを定義した2021年前後の市場の経緯 調査会社のGartnerは2021年、乱立していたクラウドセキュリティ製品を1つの枠組みで捉える「CNAPP」というカテゴリを提唱しました。それ以前は、構成管理のCSPM、ワークロード保護のCWPP、権限管理のCIEMがそれぞれ別カテゴリとして発展していました。その後はクラウド事業者自身が統合側へ動いています。AWSは2025年12月に[GuardDuty・Inspector・CSPMの信号を相関させる新しいSecurity Hubを一般提供](https://aws.amazon.com/about-aws/whats-new/2025/12/security-hub-near-real-time-risk-analytics/)し、Googleは2026年3月11日に[CNAPP大手のWizの買収を完了](https://www.googlecloudpresscorner.com/2026-03-11-Google-Completes-Acquisition-of-Wiz)しました。単体製品からプラットフォームへの集約は、市場の既定路線になっています。 ## CNAPが登場した背景と単体セキュリティツール乱立の運用課題 CNAPPが生まれた直接の理由は、クラウド普及とともにセキュリティ製品が増えすぎ、運用側が管理しきれなくなったことにあります。歴史をたどると、機能が別々に生まれた必然と、その分断が生む具体的な痛みが見えてきます。 ### CSPM・CWPP・CIEMが別々の製品として生まれてきた経緯 クラウドの設定ミスが情報漏えいの主因になったことから、2010年代半ばに構成を点検するCSPMが製品カテゴリとして立ち上がりました。その後、コンテナやVMなど稼働中のワークロードを守るCWPPが加わります。さらにクラウドではアカウントやロールの権限設計が複雑になり、過剰な権限の付与を検出するCIEMが必要になりました。それぞれが別の課題に応じて別々の製品として立ち上がったため、企業は3種類以上のツールを個別に契約し、別々の画面で運用する状態に陥りました。 ### 単体ツールの分断が招くアラート洪水と危険な見落としが起きる構図 ツールが分かれていると、CSPMは設定不備を、CWPPは脆弱性を、CIEMは権限逸脱を、それぞれ独立してアラート化します。1つのシステムに問題が重なっても、担当者は複数の画面を突き合わせて危険度を推測するしかありません。結果として、日々数百件の警告に埋もれ、本当に攻撃につながる経路を見落とします。単体ツールの弱点は、検知能力ではなく「文脈の欠如」にあります。誰がどのデータへ到達できるかという因果を、ツールをまたいで追えないのです。 ## CNAPを構成する5つの主要コンポーネントと防御範囲の全体像 CNAPPは複数の機能領域を1つに束ねた集合体です。中核となる5つのコンポーネントを、守る対象と防ぐリスクで整理します。自社に不足している領域を見極める材料になります。 ### CSPMとCWPPが分担する構成点検とワークロード実行時保護 CSPM（Cloud Security Posture Management）は、クラウドの設定が安全な状態から逸脱していないかを継続的に点検します。公開設定のままのストレージや、暗号化されていないデータベースを検出する役割です。CWPP（Cloud Workload Protection Platform）は、稼働中のコンテナ・VM・サーバーレス関数そのものを守り、脆弱性や不正なプロセスの実行を監視します。CSPMが「箱の置き方」を、CWPPが「箱の中身」を見る関係と捉えると分かりやすいでしょう。ワークロード側の収集方式や製品ごとの実装差は[CWPPの仕組みとCSPMとの違い](https://www.issoh.co.jp/tech/details/16212/)で整理しています。稼働中のコンテナそのものをカーネルレベルで隔離する手段としては、ユーザー空間カーネルで守る[gVisorとは](https://www.issoh.co.jp/tech/details/15689/)のようなサンドボックス型ランタイムも選択肢の1つです。Microsoftの製品でCSPMがどう実装されるかは、[Microsoft Defender CSPMの解説記事](https://www.issoh.co.jp/tech/details/8045/)で具体的に確認できます。 ### CIEM・KSPM・DSPMが埋める権限管理とデータ保護の死角 CIEM（Cloud Infrastructure Entitlement Management）は、クラウドの権限を棚卸しし、使われていない過剰な権限を最小権限へ寄せる仕組みです。KSPM（Kubernetes Security Posture Management）はKubernetesクラスタ固有の設定不備を、DSPM（Data Security Posture Management）は機密データの所在と露出を可視化します。構成やワークロードだけを見ていると、「誰がどのデータへ到達できるか」という攻撃者目線の経路が抜け落ちます。この3つは、その死角を埋めるために後から重ねられた層です。 ### IaCスキャンとコードセキュリティで固める開発段階からの防御 CNAPPの特徴は、本番稼働後だけでなく開発段階にも守りを広げる点にあります。TerraformなどのIaC（Infrastructure as Code）を本番反映前にスキャンし、設定ミスをコードの時点で止めます。コンテナイメージの脆弱性検査や、ソースコードの静的解析も同じ流れです。問題を早い段階で潰すこの考え方は「シフトレフト」と呼ばれ、実行時の監視（シフトライト）と組み合わせて開発から運用までを一続きで守ります。開発工程へ検査を組み込む進め方の全体像は、[DevSecOpsのライフサイクルと導入判断](https://www.issoh.co.jp/tech/details/3959/)で扱っています。 ### CNAPを構成する5コンポーネントと守る対象・防ぐリスク一覧 各コンポーネントの担当範囲を一覧にすると、自社に欠けている層が浮かびます。次の表は代表的な5領域の対応関係です。 | コンポーネント | 守る対象 | 主に防ぐリスク | | ------- | ------------ | --------- | | CSPM | クラウド構成・設定 | 設定ミス・基準逸脱 | | CWPP | 稼働中ワークロード | 脆弱性・不正実行 | | CIEM | 権限・アカウント | 過剰権限の悪用 | | KSPM | Kubernetes構成 | クラスタ設定不備 | | DSPM | 保管データ | 機密データの露出 | すべてを一度に揃える必要はありません。自社の運用で穴になっている層から埋めるのが現実的な順序です。 ## CSPM単体とCNAPの違い、統合で変わるリスク優先度の考え方 CNAPPを検討する企業の多くは、すでにCSPMを使っています。では単体のCSPMと、それを含むCNAPPは何が違うのか。差は機能の数ではなく、検出をどう優先度に変換するかにあります。 ### CSPM単体で見える範囲とCNAP統合で新たに広がる可視化範囲 CSPM単体は、クラウドの設定不備を網羅的に洗い出します。ただし見えるのは「構成」の層だけで、その設定ミスが実際に悪用可能かどうかまでは判断しません。CNAPPはCSPMの構成情報に、CWPPの脆弱性、CIEMの権限、DSPMのデータ配置を重ね合わせます。「公開設定のサーバーに未修正の脆弱性があり、そこから機密データへ強い権限で到達できる」という一連の経路を1つのリスクとして提示できるのが、統合の価値です。CSPM側の検出の仕組みと単体で運用する場合の判断は、[CSPMの設定ミス検出の仕組みとCNAPPとの違い](https://www.issoh.co.jp/tech/details/16228/)で掘り下げています。 ### 攻撃経路の相関分析で膨大なアラートから優先リスクを絞る仕組み 単体ツールは各領域で危険度を採点しますが、他領域の状況を知らないため、実際には到達できない問題も高リスクと表示しがちです。CNAPPは複数層の情報をグラフとして相関させ、外部から機密資産まで一直線につながる「攻撃パス」を優先します。数百件の警告のうち、対処すべき十数件へ絞る発想です。アラートを減らすこと自体が目的ではなく、限られた人員をどこへ向けるかを決めるための道具だと考えてください。 ## CNAPの守りを手元で試す：TrivyのIaC点検とAWS標準機能の有効化手順 CNAPPの価値は、製品を買う前にある程度まで確かめられます。IaCの点検はOSSで、構成点検はクラウド標準機能で始められるからです。ここでは、コピーしてそのまま動かせる2つの手順と、各クラウドの標準機能の対応関係を示します。 ### trivy configでTerraformの設定ミスを本番反映前に止める手順 Aqua Securityが公開する[OSSのスキャナTrivy](https://github.com/aquasecurity/trivy)は、コンテナイメージの脆弱性検査に加え、`trivy config`でTerraform・CloudFormation・Kubernetesマニフェストの設定不備を検出できます。2026年9月時点の版は0.7x系です。公式の[Terraformスキャンの手順](https://trivy.dev/docs/latest/tutorials/misconfiguration/terraform/)に沿うと、次の形になります。 ``` # HIGH以上の設定不備があれば終了コード1で止める（CIのゲートにそのまま使える） trivy config --severity HIGH,CRITICAL --exit-code 1 ./infra # 変数ファイルを反映した状態で点検する trivy config --tf-vars terraform.tfvars ./infra # terraform plan の結果（実際に作られるリソース）を点検する terraform plan -out tfplan terraform show -json tfplan > tfplan.json trivy config tfplan.json ``` `--exit-code 1`を付けると、検出があった時点でパイプラインが失敗します。プルリクエストの必須チェックに組み込めば、公開設定のS3バケットや暗号化なしのRDSがコードレビューの段階で止まります。インストール方法や読み方を含む基本は[Trivyの使い方入門](https://www.issoh.co.jp/tech/details/10398/)にまとめました。 ### AWS CLIでSecurity Hub CSPMを有効化し重大な検出を絞り込む手順 AWSでは、従来のSecurity Hubが[Security Hub CSPMという名称](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)になりました。AWS基礎セキュリティのベストプラクティスやCIS・PCI DSSの基準で構成を点検し、GuardDutyやInspectorの検出も集約します。初回有効化から30日間は無料トライアルです。ただしリージョン単位で動き、多くのコントロールはAWS Configの記録が前提になる点に注意してください。 ``` # 東京リージョンで有効化し、既定のセキュリティ標準も同時に有効にする aws securityhub enable-security-hub --enable-default-standards --region ap-northeast-1 # 重大度CRITICALで未対応の検出だけを表で出す aws securityhub get-findings --region ap-northeast-1 \ --filters '{"SeverityLabel":[{"Value":"CRITICAL","Comparison":"EQUALS"}],"WorkflowStatus":[{"Value":"NEW","Comparison":"EQUALS"}]}' \ --query 'Findings[].{Title:Title,Resource:Resources[0].Id}' --output table ``` トライアル期間中にCRITICALの件数を数えれば、単体のCSPMで回るか、攻撃経路の相関まで必要かの判断材料がそろいます。CSPMとの違いや料金の考え方は[AWS Security Hubの有効化手順と料金の解説](https://www.issoh.co.jp/tech/details/15890/)で扱っています。 ### AWS・Azure・Google Cloud標準機能とCNAPP要素の対応比較 各クラウドの標準機能が、CNAPPのどの層までを受け持つかを並べました。2026年9月時点の公式ドキュメントに基づきます。表中の「新Hub」は新Security Hubの略記です。 | クラウド | 標準機能 | 主に受け持つ層 | | ------------ | ----------------------- | ------------------- | | AWS | Security Hub CSPM・新Hub | 構成点検と検出の相関 | | Azure | Defender for Cloud | CSPM・DevSecOps・CWPP | | Google Cloud | Security Command Center | 構成点検と脅威検出 | Defender for CloudはMicrosoft自身がCNAPPと称しており、無料のFoundational CSPMから始められます。[Security Command Center](https://docs.cloud.google.com/security-command-center/docs/security-command-center-overview)はStandard・Premium・Enterpriseの3階層で、AWSやAzureへの接続はEnterpriseの機能です。単一クラウドなら、まずこの表の標準機能を使い切るのが先になります。 ## CNAPを採用すべき企業と、過剰投資になりやすい企業の見極め ここからは判断を言い切ります。CNAPPは強力ですが、すべての組織に見合うわけではありません。導入が投資に見合う前提条件と、逆に過剰になる典型例を、条件付きで整理します。 ### CNAPへの統合投資が費用対効果に見合う企業の3つの前提条件 CNAPPが効くのは、次の3条件のいずれかに当てはまる組織です。第一に、AWS・Azure・Google Cloudなど複数のクラウドをまたいで運用し、各社の標準機能を横断で見たい場合。第二に、コンテナやKubernetesを本番で運用し、イメージから権限まで一気通貫で追いたい場合。第三に、すでにCSPMやCWPPを個別契約していて、アラートの突き合わせに人手が割かれている場合です。とりわけPCI DSSなどのコンプライアンス要件があると、証跡を1基盤へ集約する効果が大きくなります。 ### 小規模・単一クラウド構成ではCNAPが過剰投資になりやすい理由 単一のクラウドしか使わず、アカウント数も少なく、コンテナを本番で運用していない組織に、フル機能のCNAPPは過剰です。AWSならSecurity Hub CSPM、AzureならDefender for Cloud、Google CloudならSecurity Command Centerといった各社標準機能が、基本的な構成点検と権限可視化をすでに提供します。CNAPPはリソース数やワークロード数に応じて費用が増える製品が多く、小さな環境ほど割高になりがちです。標準機能で設定ミスを潰し、弱い層だけを単体ツールで補う方が費用対効果は高くなります。ここは「まず標準機能」で線引きしてよい場面です。 ### 失敗パターン：全機能を一括導入してアラートで運用が回らない例 よくある失敗は、CNAPPを契約した初日に全機能を有効化し、数千件の警告に埋もれて誰も見なくなるパターンです。ツールが優先度を付けても、対応する体制がなければアラートは放置されます。現実的な進め方は、最も痛い1〜2領域から始めることです。設定ミスが不安ならCSPM、権限が不安ならCIEMというように、自社のインシデント履歴が示す弱点から段階的に広げます。導入の成否を分けるのは製品の網羅性ではなく、運用に載る範囲へ絞れるかどうかです。 ## 主要なCNAP製品の選定軸と受託開発プロジェクトへの組み込み 最後に、製品を比べるときの観点と、これから作るシステムへ守りを組み込む進め方を示します。導入済みでも、これから設計する場合でも、判断の軸は共通です。 ### 主要なCNAP製品を比べるときに見るべき4つの実践的な選定観点 2026年9月時点で代表的なCNAPP製品には、Wiz（2026年3月にGoogleが買収を完了し、ブランドは維持）、Palo Alto NetworksのPrisma Cloud、Microsoft Defender for Cloud、CrowdStrike Falcon Cloud Security、Trend Micro、Sysdig、Aqua Securityなどがあります。比べる軸は4つに絞れます。第一に、自社が使うクラウドとKubernetesへのカバレッジをどこまでもつか。第二に、エージェント常駐型か、権限を渡すだけのエージェントレス型か。第三に、開発段階のIaC・コードスキャンにどこまで踏み込むか。第四に、既存のSIEMやチケット基盤と連携できるか。名前や知名度ではなく、この4観点を自社環境に当てて評価します。 ### 受託開発でセキュリティを設計の段階から組み込む現実的な進め方 クラウドネイティブなシステムを新規に構築する、あるいは既存システムを移行する段階では、CNAPが前提とするコンテナ・権限・IaCの守りをアーキテクチャ設計へ織り込めます。運用後にツールで穴を探すより、設計時に最小権限やイメージ検査の方針を決め、先に示した`trivy config`のゲートをCIへ入れておく方が、後戻りのコストを抑えられるためです。AWS・Google Cloud・Azureの基盤をセキュリティ設計込みで組みたい場合は、[クラウドのインフラ構築支援](https://www.issoh.co.jp/service/system/aws/)で要件から検討できます。CNAPの前提となるクラウドネイティブそのものの全体像は、[クラウドネイティブとはを解説した記事](https://www.issoh.co.jp/column/details/12999/)が参考になるはずです。 ## よくある質問 CNAPとCNAPP、周辺の略語について、検索で多い疑問に短く答えます。 ### CNAPとCNAPPに違いはありますか？ 技術的な意味の違いはほとんどありません。CNAPPは「Cloud-Native Application Protection Platform」の略で、末尾のPlatformを省いた表記がCNAPです。概念や検索語として短く書くときにCNAPが使われ、製品カテゴリを正式に指すときはCNAPPと書かれます。日本語のベンダー解説ではCNAPP表記が中心です。どちらも同じクラウドセキュリティの枠組みを指すと考えて差し支えありません。 ### CNAPPとCSPMは何が違うのですか？ CSPMはクラウドの設定不備を点検する単機能で、CNAPPはそのCSPMを含む統合基盤です。CSPMが「構成の層」だけを見るのに対し、CNAPPは構成・ワークロード・権限・データを重ね合わせ、外部から機密資産へつながる攻撃経路として優先度を付けます。すでにCSPM単体で設定管理が回っているなら、次に権限やワークロードの層をどう統合するかが検討点になります。 ### CNAPは具体的に何を守るのですか？ クラウド上で動くアプリケーションを、開発から運用まで一続きで守ります。守る対象は、クラウドの構成、稼働中のコンテナやVM、アカウントの権限、Kubernetesの設定、保管データなどです。加えてTerraformなどのIaCやコンテナイメージを本番反映前に検査し、設定ミスを早い段階で止めます。単一の資産ではなく、それらをつなぐ経路全体を守るのが特徴です。 ### 主要なCNAPP製品にはどんなものがありますか？ 2026年9月時点では、Wiz、Palo Alto NetworksのPrisma Cloud、Microsoft Defender for Cloud、CrowdStrike Falcon Cloud Security、Trend Micro、Sysdig、Aqua Securityなどが代表的です。WizはGoogleの傘下に入りましたが、AWSやAzureも引き続き対象にしています。エージェントレスで素早く可視化するもの、実行時監視に強いもの、開発段階のスキャンに踏み込むものと個性が分かれます。自社が使うクラウドとKubernetesへのカバレッジ、既存基盤との連携を軸に比べてください。 ### CNAPPを無料で試す方法や、自社に必要かの判断基準はありますか？ 製品の前に、OSSのTrivyでIaCとイメージを点検し、AWSならSecurity Hub CSPMの30日間無料トライアル、AzureならDefender for Cloudの無料のFoundational CSPMで検出の量を測る方法があります。そのうえで、マルチクラウドか、コンテナを本番運用しているか、単体ツールのアラート運用が破綻していないか、の3点が確認する項目です。いずれかに当てはまれば統合の効果が見込め、当てはまらなければ標準機能を固めて弱い層だけを補う方が費用対効果に優れます。 ## 関連記事 - [クラウドネイティブとは](https://www.issoh.co.jp/column/details/12999/)：CNAPが守る対象であるコンテナ・マイクロサービスの全体像を理解できます。 - [CSPMとは](https://www.issoh.co.jp/tech/details/16228/)：CNAPの一構成要素であるCSPMの検出の仕組みと、単体で運用する場合の判断を整理しています。 - [Microsoft Defender CSPMとは何か](https://www.issoh.co.jp/tech/details/8045/)：CNAPの一構成要素であるCSPMを、Microsoft製品で具体的に確認できます。 - [クラウドセキュリティとは](https://www.issoh.co.jp/column/details/13266/)：CNAPPが束ねるクラウドセキュリティ全体を、概念と責任共有モデルから整理できます。 - [インフラ構築（AWS・Google Cloud・Azure）](https://www.issoh.co.jp/service/system/aws/)：クラウド基盤を設計段階からセキュアに構築する相談窓口です。 --- 出典: [CNAPとは？CNAPPとの違い・5つの構成要素とTrivy・Security Hubで試す手順、採用判断]()（株式会社一創）