Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
近年、クラウド環境を前提としたアプリケーション開発が広がり、マイクロサービス、コンテナ、Kubernetes、CI/CDといったモダンな開発・運用手法の導入が加速しています。
この変化により、セキュリティ対策の対象は、従来の「クラウドインフラを守る」だけでは不十分になりました。アプリケーション、コンテナイメージ、IaC、CI/CDパイプライン、クラウド設定、IAM権限、ランタイム環境、インシデント対応までを含めて、ライフサイクル全体でリスクを管理する必要があります。
こうした背景から登場した概念が、CNAPP（Cloud-Native Application Protection Platform、読み方：シーナップ）です。
CNAPPは、クラウドネイティブ環境に必要な複数のセキュリティ機能を1つのプラットフォームに統合し、開発から運用、検知・対応までを一貫して支えるための考え方です。本記事では、CNAPPとは何かを「ライフサイクル全体を統合するプラットフォーム」という視点から整理し、主要機能、導入メリット、製品選定のポイント、Sysdig Secureの活用例について解説します。
CNAPPとは — ライフサイクル全体を統合するセキュリティプラットフォーム
CNAPP（Cloud-Native Application Protection Platform）とは、クラウドネイティブ環境におけるインフラ、アプリケーション、ワークロード、ID、設定、ランタイムのリスクを統合的に可視化・制御するためのセキュリティプラットフォームです。
その本質は、コード作成からビルド、本番運用、インシデント対応まで、本来は別々のツールで管理されがちなセキュリティ機能を1つの基盤に束ねる点にあります。
CNAPPでは、たとえば次のような機能を統合します。
- IaCスキャン
- アーティファクト／コンテナイメージスキャン
- SBOM生成
- CSPM（クラウド構成管理）
- CIEM（クラウド権限管理）
- CWPP（ワークロード保護）
- CDR（クラウド検知・対応）
- ランタイム脅威検知
- コンプライアンス監査
- リスクの優先順位付け
- インシデント調査・対応
これらを個別に導入するだけでは、各ツールの検出結果が分断され、リスクの全体像を把握しにくくなります。CNAPPは、設計・開発・運用・対応の各段階のデータをつなぎ、クラウドネイティブ環境全体のリスクを一貫して管理するための基盤です。
CNAPPソリューションは、主要クラウドプラットフォームとのAPI連携、CI/CDパイプラインとの統合、エージェント方式・エージェントレス方式の組み合わせにより、開発段階と実行段階の双方をカバーします。
Gartnerの定義と背景
Gartnerは、2021年のレポート「Innovation Insight for Cloud-Native Application Protection Platforms」で、CNAPPを新しい製品カテゴリーとして定義しました。
CNAPPは、単なるポイントソリューションの集合ではありません。クラウドネイティブアプリケーションを保護するために必要な複数の機能を統合し、顧客とベンダーが共通の基準で製品価値を理解できるようにするための概念です。
同様の動きは、約10年前のアプリケーションパフォーマンス管理（APM）領域でも見られました。市場が成熟するにつれて、共通の期待値や最低限の機能要件が明確化されていったのです。
CNAPPもまた、「クラウドネイティブ環境を守るには、複数のセキュリティ機能を統合したプラットフォームが必要である」という業界共通の認識を言語化した概念だといえます。
CNAPPの機能はライフサイクルのどこに対応するか
CNAPPは、WAFやEDRのような単一機能のセキュリティ対策とは異なり、クラウドネイティブアプリケーションのライフサイクル全体を保護します。
ここでは、CNAPPを構成する代表的なセキュリティ機能が、Plan / Build / Run / Respond の各段階にどのように対応するかを整理します。
ライフサイクルの複数段階にまたがって機能する代表例が、CSPMとCIEMです。
CSPM（Cloud Security Posture Management）は、設計段階では設定ミスの早期検出に役立ち、運用段階ではクラウド環境の継続的な監視に使われます。
CIEM（Cloud Infrastructure Entitlement Management）は、設計段階では最小権限設計を支援し、運用段階では実際に使われている権限と過剰権限を可視化します。
つまりCNAPPとは、これらの機能を1つのプラットフォーム上で連携させ、ライフサイクルをまたいでリスク情報を引き継ぐ仕組みそのものです。
なお、AIワークロードやAIエージェントの防御は、従来のCNAPP定義における標準機能というよりも、クラウドネイティブ環境に新たに広がる攻撃面として、今後CNAPPが拡張して対応していく領域と位置づけられます。
CNAPPを構成する主要機能
CNAPPは、複数のセキュリティ機能を統合することで、クラウドネイティブ環境全体を保護します。以下は、代表的な機能と役割の概要です。
CNAPPは、これらの機能をPlan / Build / Run / Respondのライフサイクル全体で連携させ、フィードバックループを形成する統合基盤です。GartnerもCNAPPにおいて統合性を重視しており、クラウド構成管理や権限管理に加えて、実行中のワークロードを保護するCWPPは重要な構成要素のひとつになります。
なぜ「統合プラットフォーム」でなければならないのか
CNAPPを導入する最大のメリットは、クラウドネイティブアプリケーションスタック全体に対する可視性と制御性を、統合的に高められる点にあります。
現在、多くの組織では、Plan / Build / Run / Respond の各段階をカバーするために、複数のポイントソリューションを組み合わせています。たとえば、IaCスキャン、SCA、イメージスキャン、CSPM、IAM監査、ランタイム検知、インシデント対応ツールを個別に導入しているケースです。
しかし、この運用では次のような課題が生まれます。
- ツールごとに検出結果が分断される
- 同じリスクが複数のツールから重複して通知される
- 実際に悪用可能なリスクかどうか判断しづらい
- 開発チームと運用チームで見ている情報が異なる
- レポート作成や優先順位付けに多くの手作業が発生する
- 結果として、重大リスクを見落とす可能性がある
特に問題となるのは、リスクの文脈が失われることです。
たとえば、あるコンテナイメージにCritical脆弱性が含まれていたとしても、そのイメージが本番環境で稼働していないのであれば、緊急度は下がります。一方で、同じ脆弱性を含むイメージがインターネットに公開されたワークロードで稼働している場合、優先度は大きく上がります。
この判断には、イメージスキャン、ランタイム情報、クラウド設定、ネットワーク露出、権限情報を横断的に結びつける必要があります。個別ツールだけでは、この判断が難しくなります。
CNAPPは、こうしたデータの断片化を解消し、統一されたポリシーと共通のリスクコンテキストに基づいて、ライフサイクル全体のセキュリティを管理できるようにします。
例1：ビルド段階の脆弱性を、実行中の状況をふまえて判断する
ビルドチームがSCA（ソフトウェア構成分析）ツールでコンテナイメージをスキャンし、CVEデータベースを参照して既知の脆弱性を特定していたとします。
ここで、Log4Shellのような深刻な脆弱性が検出された場合、従来のスキャン結果だけでは「すぐに修正すべきか」を判断しきれません。重要なのは、その脆弱性を含むコンテナが実際に本番環境で稼働しているか、外部に公開されているか、攻撃経路上にあるかという文脈です。
CNAPPでは、ビルド段階のスキャン結果をランタイム情報と結びつけることで、次のような判断が可能になります。
- その脆弱性を含むイメージが本番環境で稼働しているか
- 対象ワークロードがインターネットに公開されているか
- 実際に使われているパッケージか
- 攻撃者が到達可能な経路上にあるか
- 過剰権限や設定ミスと組み合わさっているか
これにより、単なるCVE一覧ではなく、実際の攻撃可能性に基づく優先順位付けができます。
脆弱性管理において重要なのは、検出数を増やすことではありません。限られた開発・運用リソースの中で、本当に修正すべきリスクを特定することです。CNAPPは、ビルド段階とランタイム段階の情報をつなぐことで、リスクベースの脆弱性管理を実現します。
実行中のワークロードに基づいて脆弱性アラートを削減する仕組みについては、「コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み」で詳しく解説しています。
例2：設計段階の設定ミスを、運用段階で継続的に検証する
クラウドエンジニアがサンドボックス環境でサブネットのポートを誤って開放し、そのままTerraformにコミットしてしまったとします。
この場合、CNAPPは複数の段階で問題を検出できます。
まず、IaCスキャンにより、デプロイ前のTerraformやCloudFormationの設定を解析し、不適切な構成を検出します。これにより、設定ミスが本番環境に反映される前に修正できます。
次に、CSPMにより、本番環境に展開されたクラウドリソースを継続的に監視します。もし設定変更や手動操作によってポリシー違反が発生した場合でも、運用段階で検出できます。
さらに、CNAPP製品によっては、検出した問題に対して修正候補を提示したり、設定をコンプライアンス状態へ戻す自動修復機能を備えていたりします。
これにより、「コード上の設定」と「実際に動いているクラウド環境」の乖離を継続的に検出・是正できます。
このようにCNAPPは、従来の分散的なツール運用に伴うデータの断片化とリスクの過小評価を解消し、ライフサイクル全体で一貫したセキュリティ運用を実現します。
CNAPPが守るべきリスク — 共通課題は「可視性の欠如」
Gartnerは2019年10月の解説記事「Is the Cloud Secure?」で、「2025年までに、クラウドのセキュリティ侵害の99%が顧客の過失によるものになる」と述べています。
クラウド環境では、クラウドサービス事業者が基盤の安全性を担保する一方で、利用者側には設定、権限、アプリケーション、データ、ワークロードの管理責任があります。これが責任共有モデルです。
さらに、クラウドネイティブ環境では、この責任範囲がより複雑になります。コンテナのプロビジョニング、Kubernetesの設定、コンテナイメージの作成、CI/CDパイプライン、ランタイム環境、アプリケーション開発まで、利用者が管理すべき対象が広がるためです。
CNAPPが対処すべき代表的なリスクは、ライフサイクルのどの段階に現れるかという視点で整理できます。
設定ミス
設定ミスは、設計段階と運用段階の両方で発生します。S3バケットの公開設定、Kubernetesの過剰権限、ネットワーク設定の不備、暗号化設定の漏れなどは、クラウド侵害の代表的な原因です。
IaCテンプレートの段階で設定ミスが入り込むと、そのまま複数環境へ展開される可能性があります。CNAPPでは、IaCスキャンとCSPMを組み合わせることで、デプロイ前後の両方で設定ミスを検出できます。
過剰権限とアイデンティティ管理の不備
クラウド環境では、IAMユーザー、ロール、サービスアカウント、マシンIDなど、多数の権限が複雑に絡み合います。
「とりあえず管理者権限を付与する」という運用は、攻撃者にとって大きな侵入口になります。特にマイクロサービスや自動化されたCI/CD環境では、権限の棚卸しが難しく、過剰権限が放置されやすくなります。
CIEMは、実際に使われている権限と付与されている権限の差分を可視化し、最小権限の実現を支援します。
シャドーITと管理対象の増加
クラウドネイティブ環境では、CI/CDパイプラインから新しいリソースやコンテナ実行環境が自動的に立ち上がります。その結果、管理者が把握していないクラウドリソースやワークロードが増えることがあります。
このようなシャドーITは、設定ミスや未管理の脆弱性を生む原因になります。CNAPPは、クラウドアカウント、Kubernetesクラスタ、ワークロード、コンテナイメージを横断的に可視化し、管理対象の抜け漏れを減らします。
脅威の侵入と拡散スピード
クラウド環境では、誤って公開された資産が短時間でスキャンされ、攻撃対象になる可能性があります。公開されたストレージ、脆弱なサービス、過剰権限を持つワークロードは、攻撃者にとって格好の標的です。
特にコンテナやKubernetes環境では、ワークロードのライフサイクルが短く、数分単位で起動・停止することも珍しくありません。そのため、事後的なログ確認だけでは不十分であり、実行中の挙動をリアルタイムに検知することが重要です。
これらのリスクに共通する本質的な課題は、可視性の欠如です。
誰が、どこで、何を立ち上げたのか。どの設定に問題があるのか。どの権限が過剰なのか。どのワークロードが攻撃経路上にあるのか。実行中にどのような異常が起きているのか。
これらをリアルタイムに把握できない状態こそが、クラウドネイティブ環境における最大のリスクです。CNAPPは、ライフサイクル全体にわたって可視性を統合することで、この課題に応えます。
CNAPPとDevSecOps — プラットフォームが文化を支える
CNAPPは、DevSecOpsを技術面から支えるプラットフォームでもあります。
DevSecOpsとは、セキュリティを開発の最後にまとめて確認するのではなく、設計・開発・テスト・デプロイ・運用の各段階に最初から組み込む考え方です。
これは、CNAPPが目指す「ライフサイクル全体でセキュリティを統合する」という発想と重なります。
DevSecOpsの実践には、次のような要素が求められます。
- シフトレフトによる早期検出
- CI/CDパイプラインでの継続的なセキュリティチェック
- 開発者が理解しやすいリスク提示
- 脆弱性と設定ミスの優先順位付け
- 運用時のリアルタイム監視
- インシデント対応への連携
- セキュリティチームと開発・運用チームの情報共有
これらを単体ツールと手作業で実現するのは困難です。CNAPPは、セキュリティを開発・運用プロセスに自然に組み込むための仕組みとして機能します。
重要なのは、CNAPPが開発者の生産性を妨げるためのものではないという点です。むしろ、開発者にとって不要なアラートを減らし、修正すべきリスクを明確にすることで、セキュリティと開発スピードの両立を支援します。
DevSecOpsの役割分担、パイプライン設計、SLA設計といった運用プロセスの詳細は、「DevSecOpsとコンテナセキュリティ｜SREが知っておくべき運用設計の考え方」で詳しく解説しています。
CNAPP対応製品の選定ポイントとSysdigの対応
CNAPP対応製品を選定する際は、単に機能一覧を比較するのではなく、ライフサイクル全体を実際にカバーできるかを評価することが重要です。
以下に、主な評価項目とSysdig Secureの対応を整理します。
Sysdig Secureは、CSPM、CWPP、CIEMに加え、ランタイム検知やCDRの機能を連携させ、コンテキストに基づくリスク可視化と優先順位付けを支援します。
特に、コンテナやKubernetesのように変化の速い環境では、ランタイムの情報を使ってリスクを判断できるかどうかが重要です。クラウド攻撃はオンプレミス環境のように数週間かけて進行するものではなく、数分から十数分で完結し得るため、設定情報の定期スキャンだけでなく、実行時に何が起きているかをリアルタイムに捉える仕組みが欠かせません。Sysdig Secureは、実行中のワークロード、クラウド設定、権限、脆弱性情報を結びつけることで、運用現場が対応すべきリスクを絞り込めるようにします。
日本国内でも採用実績を重ねており、「導入して終わり」ではなく、「運用し続けられるCNAPP」を求める組織にとって、有力な選択肢のひとつです。
CNAPP導入を成功させる5つのステップ
CNAPPの導入は、最初からすべての機能を一気に展開するよりも、段階的に進めることが重要です。
1. 環境の調査とプロファイリング
まずは、クラウドアカウント、Kubernetesクラスタ、コンテナイメージ、ワークロード、IAM権限、CI/CDパイプラインなど、現在の環境全体を把握します。
どのリソースが存在し、誰が管理し、どのような設定・権限・脆弱性があるのかを可視化することが出発点です。
2. ポリシーと推奨事項の確認
CNAPPが検出したポリシー違反や推奨事項を確認し、改善余地を洗い出します。
この段階では、検出されたすべての項目を一度に修正しようとするのではなく、影響度や攻撃可能性に基づいて優先順位を付けることが重要です。
3. 適用ポリシーの選定と実施
最初から強い制御を一気に適用すると、開発・運用に影響が出る可能性があります。まずは、影響範囲の小さいポリシーから適用し、チームがアラートや修正フローに慣れる時間を確保します。
開発者にとって理解しやすい形でフィードバックを返すことも重要です。
4. アラートの監視と対応
ポリシー適用後は、発生するアラートを継続的に監視し、実際の運用に合わせてチューニングします。
誤検知や重要度の低いアラートが多いと、セキュリティチームやSREの負荷が高まり、重要なリスクを見落とす原因になります。リスクベースで優先順位を付け、対応すべきアラートを絞り込むことが重要です。
5. 継続的な改善
CNAPP導入は、一度設定して終わるものではありません。クラウド環境、開発プロセス、ワークロード、攻撃手法は常に変化します。
そのため、「適用 → 検証 → 改善」のサイクルを継続的に回し、ポリシー、検知ルール、対応フローを更新していく必要があります。
最初から完璧を目指すのではなく、小さく始めて改善を重ねることが、CNAPP導入を成功させるポイントです。
CNAPPにつながるクラウドネイティブセキュリティ事例 — Sysdig Secure事例
Sysdig Secureを活用し、CNAPPにつながるクラウドネイティブセキュリティの強化を進めた日本のお客様事例をご紹介します。
これらの事例は、単一の検知機能だけではなく、クラウド環境の可視化、ランタイム保護、脆弱性の優先順位付け、運用統合といった複数の観点を組み合わせている点で、CNAPP的なアプローチの参考になります。
みんなの銀行：クラウドネイティブセキュリティで運用を統合
みんなの銀行は、Sysdigのクラウドネイティブセキュリティを活用し、個別のセキュリティ運用からの脱却を進めました。
クラウド環境全体の可視化とリスクの優先順位付けにより、セキュリティ運用の効率化と体制強化につなげています。
事例：みんなの銀行の守りを固めるSysdig のクラウドネイティブセキュリティ
NTTドコモ：クラウドネイティブ基盤のセキュリティと可視化を強化
NTTドコモは、クラウドネイティブ基盤「RAFTEL」のセキュリティ対策と運用監視の強化にSysdigを活用しています。
クラウド環境全体の可視化、リアルタイム脅威検知、脆弱性の優先順位付けを通じて、セキュリティ運用の効率化と体制強化を実現しています。
事例：8000万ユーザーへのAPIサービス基盤RAFTELをSysdigで支える
まとめ：CNAPPはライフサイクル全体を束ねるプラットフォーム
クラウドネイティブ技術の進展により、アプリケーション開発のスピードと柔軟性は大きく向上しました。一方で、セキュリティリスクの管理対象は、クラウド設定、IAM権限、コンテナイメージ、CI/CD、Kubernetes、ランタイム、インシデント対応へと広がり、従来の単体ツールだけでは全体像を把握しにくくなっています。
この環境で求められるのは、設計、シフトレフト、ランタイム検知、インシデント対応を分断せず、1つのプラットフォームでライフサイクル全体を統合することです。
CNAPPは、まさにこの統合を担う概念です。
今後は、AIワークロードやAIエージェント、MCPサーバーといった新しい攻撃面への対応も重要になります。これらは従来のCNAPP定義を拡張する領域ですが、クラウドネイティブ環境を守るうえで避けて通れないテーマです。
製品選定にあたっては、単機能ツールの寄せ集めではなく、ライフサイクル全体を横断して可視化・優先順位付け・運用対応までを支援できるかを確認する必要があります。
Sysdig SecureのようなCNAPP対応製品は、クラウドネイティブ環境におけるセキュリティ体制の整備と、運用効率化の両立を支援する有力な選択肢です。
各段階の具体的な実装・運用については、本記事の全体像を起点に、関連記事へと読み進めてください。
関連記事
- コンテナセキュリティとは？クラウドネイティブ時代に必要な対策の全体像
- プラン・設計：クラウドセキュリティの設計とPolicy as Code
- シフトレフトとは？コンテナセキュリティをCI/CDに組み込む実践ガイド
- コンテナランタイムセキュリティとは？Falcoによるリアルタイム検知の仕組み
- DevSecOpsとコンテナセキュリティ｜SREが知っておくべき運用設計の考え方
- MCP時代のAIエージェントをどう守るか——SRE / DevSecOpsのための設計・脅威モデル・実装指針