CNAPP（Cloud-Native Application Protection Platform）は、クラウドの設定管理やワークロード保護など、複数のセキュリティ機能を統合するプラットフォームです。CSAは、CSPMやCWPPに加え、権限管理などの機能を組み合わせる製品カテゴリとして説明しています。出典：CSA
導入時は、自社のどの資産を、構築から稼働までのどの段階で保護し、誰が修正するかを比較しましょう。この記事では、製品の順位ではなく、自社で必要な範囲と既存製品との重複を判断するための確認表を示します。
CNAPPとCSPM・CWPP・CIEMの違い
CSPMはクラウド設定、CWPPはワークロード、CIEMはアクセス権限を主な対象にします。CNAPPはそれらを組み合わせて評価する枠組みです。
| 用語 | 主な対象 | 選定時に確認したいこと |
|---|---|---|
| CSPM | クラウドリソースの設定や基準への適合 | 公開設定などの問題を対象環境で検出できるか |
| CWPP | VM、コンテナなどのワークロード | 脆弱性の把握と稼働中の保護をどこまで行えるか |
| CIEM | IDに付与された権限 | 過剰な権限を把握し、見直しにつなげられるか |
| CNAPP | 上記を含む複数の保護領域 | 問題を関連付け、対応の優先順位を判断できるか |
各機能の整理はCSAの構成要素解説とIBMのCNAPP解説に基づきます。IBMは製品によって機能が異なるとも説明しています。「CNAPP対応」という名称だけで、必要な保護がすべて含まれるとは判断しないようにします。
構築時から稼働時まで、必要な保護を分ける
CNAPPを評価するときは、開発工程と運用工程を分けて要件を書き出します。IBMは、コード作成から実行時までの保護とCI/CDへの統合を説明しています。以下は、その考え方を企業の選定作業に落とし込んだ確認手順です。出典：IBM
構築・リリース前：問題をどの時点で止めるか
コードでインフラを定義するIaC、コンテナイメージ、利用ライブラリなどについて、自社で検査したい対象を列挙します。そのうえで、利用中のリポジトリやCI/CDに接続できるか、検査結果を開発者が確認できるかを質問します。
検査機能の有無と、リリースを止める運用は別々に決めます。たとえば、重大な問題を検出した場合に承認を必要とするのか、警告だけにするのか、例外の有効期限を誰が管理するのかまで整理します。
稼働後：設定・脆弱性・挙動を区別する
稼働後は「設定が適切か」「既知の脆弱性があるか」「不審な挙動が起きているか」を別の確認項目にします。特に、定期的なスキャンと継続的な監視を同じものとして扱わないことが大切です。
具体例として、Microsoft Defender for Cloudのエージェントレス・マルウェアスキャンは、継続的・リアルタイムの保護ではなく、定期的な時点観測だと公式資料に記載されています。エージェントレススキャンの周期は24時間に1回で、変更できません。また、圧縮ファイルが1GB超、内部ファイル数が10,000超、入れ子が5階層超のいずれかに該当すると、VMの一部だけを検査して完了する場合があります。これは同機能の説明であり、エージェントレス製品全般の制約を意味しません。出典：Microsoft Learn「Malware scanning coverage and limitations」
比較時は、検知したい事象ごとに、収集方式、実行間隔、通知までの時間、遮断の可否を回答してもらいましょう。
CNAPPの比較表：機能の有無から運用まで記入する
以下は選定用の記入ひな型です。製品仕様の断定ではなく、自社要件と候補製品の回答を並べるために使います。候補ごとに複製し、「対応」とだけ書かず、対象外と契約条件も残してください。
| 比較項目 | 確認する内容 | 自社要件・候補の回答記入欄 |
|---|---|---|
| 対象資産 | クラウド、アカウント、リージョン、VM、コンテナ、サーバーレスの対応範囲 | 必須：＿＿／対応・対象外：＿＿ |
| 構築時の検査 | IaC・イメージ等の対象、リポジトリ連携、リリース停止条件 | 対象：＿＿／実行箇所：＿＿ |
| 稼働時の保護 | 設定・脆弱性・挙動の検査方式と頻度、通知・遮断の範囲 | 方式：＿＿／間隔：＿＿／対応：＿＿ |
| 権限とデータ | 接続に必要な権限、取得データ、処理・保管場所、削除条件 | 権限：＿＿／データ条件：＿＿ |
| 優先順位 | 複数の検知結果をどう関連付け、判断理由を表示するか | 判断材料：＿＿／説明可否：＿＿ |
| 対応業務 | 通知先、チケット連携、修正担当、例外管理、再検査 | 担当：＿＿／完了条件：＿＿ |
| 既存製品との重複 | 残す機能、置き換える機能、併用時の通知整理 | 継続：＿＿／廃止候補：＿＿ |
| 費用と契約 | 課金単位、必要プラン、追加機能、試験・移行・運用の費用 | 見積条件：＿＿／費用：＿＿ |
接続権限は、導入前に確認したい項目です。たとえばMicrosoftのエージェントレススキャンはVMディスクのスナップショットを分析し、クラウドごとに必要な権限が定義されています。Azureでは、有効化時に必要な権限がサブスクリプションへ自動追加されます。AWSでは、削除権限の不備でDefenderタグ付きスナップショットが250個以上蓄積すると、影響するAWSのスキャン範囲で新規スキャンが停止します。停止中もDefender for Cloudの課金は続くため、削除権限と停止時の運用・費用も確認しましょう。「エージェント不要」という説明だけで、接続に必要な権限やデータの扱いまで判断しないようにします。出典：Microsoft Learn「Agentless scanning architecture」「Permissions used by agentless scanning」
PoCでは検知から修正完了までを確かめる
PoC（導入前の検証）では、同じ対象と条件で候補を比較します。以下は本稿の評価手順案です。合格値は、自社の重要度と対応体制に合わせて検証前に決めてください。
- 対象と除外を確定する。資産台帳と検査対象を照合し、対象資産数に対して検査できた数を記録します。検査できない資産は理由も残します。検査済みのVMについても、圧縮ファイルなどの条件で部分検査になっていないか、実際の検査範囲を確認します。
- 検知から通知までを測る。承認済みの隔離された検証環境で確認用の設定不備などを使い、検知結果と通知時間を記録します。本番環境に危険な設定を作る必要はありません。
- 優先順位の説明を確認する。担当者が「なぜ先に直すのか」を画面や出力から説明できるかを確認します。単にアラート件数が少ないことを高評価にしません。
- 修正して再検査する。チケットの起票、担当への引き渡し、修正、再検査、完了までを一巡させます。所要時間と手作業を記録します。
- 例外と接続解除を試す。修正を保留する場合の承認・期限管理、接続解除後の権限とデータの扱いを確認します。
検知結果を確認する部門と、実際にクラウド設定やアプリケーションを変更する部門が異なる場合は、双方が参加します。外部に運用を委託する場合も、自社の承認者と委託先の実行範囲を表に追記すると、依頼内容を整理できます。
導入判断は「補える不足」と「残す対策」で決める
採否は、比較表で必須とした条件を満たすかから判断します。必須資産が対象外なら、別の対策を組み合わせるのか、その候補を外すのかを決めます。要件を満たしていても、通知を受けた後の担当が決まらない場合は、運用分担の確定を導入条件にします。
既存製品を廃止する判断は、機能名の重複だけで行わず、PoCの結果と対応業務の比較を基に進めましょう。最後に「CNAPPへ移す範囲」「既存製品で続ける範囲」「未解決の範囲」を1枚にまとめると、導入費用と移行作業を含めた判断がしやすくなります。