IT用語集 2024/05/21

CNAPPとは？わかりやすく10分で解説

コラム

クラウド活用が当たり前になった一方で、設定ミスや権限の過剰付与、コンテナ／Kubernetesの運用複雑化などにより、「どこで何が危ないのか」を把握しづらくなっています。この記事では、クラウドネイティブ環境をライフサイクル全体で守る考え方として注目されるCNAPPを、構成要素・できること／できないこと・導入の勘所まで整理します。

CNAPPとは

CNAPP（Cloud-Native Application Protection Platform）は、クラウド上で動くアプリケーションや基盤を、開発から運用まで一貫して守るための統合的なセキュリティプラットフォームです。もともとはCSPMやCWPPなど個別領域の製品を組み合わせて対処していた課題を、より連携の強い形で扱う概念として広まりました。

CNAPPの定義

CNAPPは、クラウドネイティブアプリケーションのライフサイクル全体（設計・開発・デプロイ・運用）にわたり、設定・脆弱性・権限・ランタイムの脅威などを横断的に管理し、リスク低減につなげる枠組みです。従来は「設定の監視」「ワークロード保護」「権限管理」などが別々に運用されがちでしたが、CNAPPはそれらを関連付けて扱うことを重視します。

クラウドネイティブのセキュリティが難しい理由

変化が速い：オートスケール、短命なリソース、CI/CDにより構成が頻繁に変わる
責任分界が複雑：クラウド事業者が守る範囲と利用者が守る範囲が混在し、認識ズレが起きやすい
対象が多い：VM、コンテナ、Kubernetes、サーバーレス、マネージドDBなど多様な実行基盤が同時に存在する
設定と権限が事故になりやすい：公開設定、暗号化、ログ、IAM権限など“ミスがそのまま露出”につながりやすい

CNAPPがカバーする範囲

CNAPPは「クラウドアカウントの設定」だけでなく、「ワークロード（VM／コンテナ等）の脆弱性や挙動」「Kubernetesの設定」「CI/CDやIaC」「権限（IAM）」「データ保護」など、複数の観点を束ねて扱う方向に進化しています。実装や製品によって守備範囲に差はあるため、導入時は“どこまで含むか”を要件化することが重要です。

CNAPPの主要なコンポーネント

CNAPPは単一機能ではなく、複数の機能群の組み合わせとして語られます。ここでは代表的な要素を「何を見て」「何が分かり」「何に効くか」の順で整理します。

CSPM

CSPM（Cloud Security Posture Management）は、クラウド環境の設定状態を継続的に点検し、ベストプラクティスやガイドラインに照らしてリスクを見つける仕組みです。代表例としては、ストレージの公開設定、暗号化、ログ有効化、ネットワークルール、セキュリティグループの穴などが対象になります。

注意点は、「設定が正しい＝安全」とは限らないことです。例えば設定は適切でも、ワークロードに脆弱性があれば侵害されます。CSPMは“土台の衛生状態”を整える役割と捉えると分かりやすいでしょう。

CWPP

CWPP（Cloud Workload Protection Platform）は、VM・コンテナ・サーバーレスなどのワークロードを保護します。典型的には、脆弱性スキャン、マルウェア検知、ランタイム監視、プロセス挙動の異常検知、コンテナイメージの安全性確認などが含まれます。

CWPPは「実行中のものを守る」視点が強いため、侵害兆候の検知や封じ込めに寄与します。一方で、根本原因が設定や権限にある場合は、CSPMや権限管理とつなげて是正する必要があります。

CIEM

CIEM（Cloud Infrastructure Entitlement Management）は、クラウドの権限（IAM）を可視化し、過剰権限や危険な権限の組み合わせを見つけ、最小権限に近づける取り組みです。現実の事故では「意図せず強い権限が付いていた」「使っていない権限が残っていた」「横展開できる権限があった」などが頻出します。

CNAPP文脈では、検出だけでなく「なぜその権限が必要なのか」「どのリソースに影響するのか」「代替手段はあるか」を判断できる材料を提供できるかが価値になります。

IaCスキャン

IaC（Infrastructure as Code）は、TerraformやCloudFormationなどでインフラ構成をコード化する考え方です。IaCスキャンは、デプロイ前に設定ミスや危険な構成を検出し、修正できる点がメリットです。運用中に見つけるより、早い段階で直した方が手戻りが小さいため、シフトレフトと相性が良い領域です。

Kubernetesのセキュリティ

クラウドネイティブではKubernetesが中核になることが多く、CNAPPでもKubernetesの設定評価（API公開、RBAC、ネットワークポリシー、イメージ署名、Podの権限など）を扱う製品が増えています。Kubernetesは自由度が高い反面、設定項目が多く、誤設定が見逃されやすいのが特徴です。

CNAPPの実装と利点

シフトレフト

シフトレフトは、セキュリティを「運用の最後で検査するもの」ではなく、「開発・設計段階から織り込むもの」として扱う考え方です。CNAPPでIaCスキャンやコンテナイメージ検査、CI/CD連携が強い場合、開発の流れの中でリスクを早期に潰しやすくなります。

ただし、シフトレフトは“検査を増やす”ことが目的ではありません。開発のスピードを落とさずに、危険な変更が本番に入りにくい状態を作ることが狙いです。そのため、アラートのノイズを減らす設計（優先度付け、例外管理、所有者の割り当て）が不可欠です。

マルチクラウド環境での一貫性

複数クラウドを併用すると、サービスの名称も設定の粒度も異なり、統制が難しくなります。CNAPPは「同じ観点での点検」「横断的な可視化」「共通の優先順位付け」によって、ばらつきを減らす方向で価値を出します。

一方で、各クラウド固有の機能を深く使うほど“共通化”だけでは足りなくなります。マルチクラウド対応をうたう場合でも、実運用で必要な深さ（どのサービスまで見るか、どこまで自動修復できるか）を確認する必要があります。

CNAPPの実用例

DevOpsと連携した運用

DevOpsの流れにCNAPPを組み込む場合、典型的には次のような分担になります。

開発時：IaCスキャン、依存ライブラリの脆弱性チェック、コンテナイメージ検査
デプロイ前：ポリシー違反のブロック、例外の申請フロー、変更差分のレビュー
運用時：CSPMで設定監視、CWPPでランタイム監視、権限の棚卸しと是正

ポイントは、検出したリスクを「誰が」「いつまでに」「どの手順で」直すかを明確にすることです。CNAPPがダッシュボードで見えるだけでは、現場は動きません。運用ルール（担当、期限、例外、承認）まで含めて初めて“対策”になります。

脅威の検出と対応

クラウド侵害では、設定ミス→侵入→権限悪用→横展開→データアクセス、のように複数要因が連鎖しがちです。CNAPPが有効なのは、CSPM（設定）・CIEM（権限）・CWPP（挙動）を関連付けて、原因と影響範囲を素早く絞り込める場合です。

ただし、インシデント対応を本格的に回すには、ログ基盤、アラート運用、チケット連携、封じ込め手順（権限剥奪、公開停止、ネットワーク遮断など）が別途必要です。CNAPP単体でSOC運用が完結するかどうかは、製品と体制次第です。

CNAPPの選び方

必要な機能を要件に落とす

CNAPPは守備範囲が広い分、製品ごとの差が出やすい領域です。次の観点で要件を具体化すると、比較がしやすくなります。

対象範囲：AWS/Azure/GCP、Kubernetes、サーバーレス、SaaS連携の有無
検出の深さ：設定（CSPM）だけか、権限（CIEM）や実行時（CWPP）まで一体か
優先順位付け：重要度の根拠が明確か（露出・権限・到達可能性・資産重要度など）
自動化：自動修復の範囲、誤修復のリスク、例外運用のしやすさ
運用連携：チケット、SIEM/SOAR、CI/CD、通知、所有者割り当て

市場の主要プロダクトは「方向性」で把握する

市場には多数の製品がありますが、ここで重要なのは製品名そのものより、「どこに強いか」です。例えば、Kubernetesやコンテナに強いもの、マルチクラウドの可視化を強く打ち出すもの、開発工程への組み込みを重視するものなど方向性が分かれます。比較では、デモやPoCで「自社のクラウド構成で、どれだけ具体的にリスクが見えるか」「修正までの導線が現場に合うか」を確認してください。