クラウド戦線異状あり：用心棒としてのCNAPP～前提事項編（前編）

インターネットという荒野に佇むクラウド基盤、治安の悪化が身に沁みます。CNAPP製品は、いわば自衛のための用心棒。なにを基準に雇えばいいのか。

クラウドの利便性を享受するのは一般ユーザーだけではない

「リスクと利便性はトレードオフ」。手あかのついた言い回しですが、内容自体は今も有効です。違いがあるとすれば、適用範囲が広がりすぎたこと。いまや対象はシステムだけでなく生活全般で、利便性を享受するのは一般ユーザーだけではありません。攻撃者も、極めて合理的に活用しています。

例えば、JPCERT/CCが注意喚起として公開した脆弱性情報^※1があります。とあるOSSに脆弱性が発見されました。CVEスコアは10点満点です。この時点で「相当まずい」という共通認識は、特に合意形成を必要とせず成立します。

※1 React Server Componentsの脆弱性（CVE-2025-55182）について

興味深いのは、その後です。JPCERT/CCの関連情報として挙げられているAWSレポートでは、公開直後からの悪用観測が報告されています（詳細は※1を参照）。もはや「公開＝対策開始」ではなく、「公開＝攻撃開始の合図」に近い。生成AIの進化で攻撃者側の準備コストが劇的に下がった結果、脆弱性情報は"注意喚起"であると同時に、"即実行可能な仕様書"として機能し始めています。読む側がエンジニアか攻撃者かで、CIが回る方向が変わるだけの話です。

さらに、IPAが発表した2025年の情報セキュリティ10大脅威では、地政学的要因^※2も挙げられています。AWSの脅威レポートでは、国家的背景が疑われるアクターによる悪用も示唆されています。AWS側の詳細は関連情報^※1から辿れるほか、「React2Shell CVE-2025-55182 AWS exploitation」等で検索すると確認できます。

※2 情報セキュリティ10大脅威 2025 | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構

つまり、これはランダムフォールトではない。再現性があり、悪意ある攻撃者が手ぐすねを引いて待っている。そのうえ、テストケースがご丁寧にも公開されているという環境です。

クラウドはインターネット上のデータセンターですが、現在はその周囲の治安が急激に悪化しています。これまでのような牧歌的な防犯意識では、とてもじゃないが生き抜けない。閑静な住宅街、でも不特定多数が懐に凶器を隠し持っている......かもしれない。

これまでは、インシデントの多くが内部要因──設定ミスや権限過多、確認漏れといった人間由来の問題でした。しかし現在は、外部からの入力値があまりにも想定どおりに悪意を持っている。もはや「想定外」を減らす努力よりも、「想定が甘い前提」を受け入れる方が、コスト効率に優れているのかもしれません。

そう考えると、CNAPPをCSPM、CWP、CIEMといった機能単位で細かく分解して理解するよりも、「インシデントを起こさないための前提条件」として一式まとめて捉える方が、状況に合っているようにも思えます。分解すれば理解は進みますが、分解している間に事態が進む。分解は後からでもできますが、復旧対応は待ってくれません。

本稿では、この前提のもとCNAPP導入前に揃えるべき条件を、前後編にて整理します。前編では、CNAPP製品選定の前に現状把握が必須な理由と、誰が見て、誰が判断し、誰が責任を持つのかについて。後編では、失敗事例と成功事例、ツールとルールを適合させるための盲点を洗い出す重要性、CNAPP相談や問い合わせ前のチェックリストについて解説します。

手順書風に言えば、導入が「実作業」、本稿は「前提事項」です。読み終えるころには、「自社は何を決めれば前に進めるか」が分かる状態を目指します。

なお、本稿は特定製品の推奨ではなく、CNAPP導入前の「前提条件（準備）」に焦点を当てます。

靴を選ぶ前に地図を開こう～

CNAPP製品選定の前に"現状把握"が必須な理由

結論から述べてしまうと、セキュリティの観点に限れば、モダンなCNAPP製品で「できること」自体に大きな差はありません。各製品とも、検知・可視化・是正といった基本機能はすでに出揃っています。

例えば、次のようなケースです。これはOrca Securityで検知された問題ですが──

ラックの社内検証環境で検出された1台のサーバ。ログインパスワードはマスクされていますが、P@******の8文字構成です。

素晴らしいですね。英数大文字小文字に記号まで完璧に取り入れています。マスクされた文字長から逆算しても、約6,900億通りの組み合わせが考えられます。それにもかかわらず、少し目端の利く人間であれば、ほぼノータイムで正解に辿り着ける。柔軟な発想の賜物ですが、システムの基盤としては、少々柔軟すぎると言わざるを得ません。

もっとも、これが直ちにインシデントへ直結するかといえば、答えは否です。

そもそも内部ネットワークからしか接続できないのであれば（それでも鍵認証を使え、という話はさておき）、リスクは一段下がります。また、そのサーバ自体が機微情報へのアクセス権を持っていなければ、同様に深刻度は下がります。

実際、このサーバも閉じたネットワーク上に置かれた単体リソースでした。

最近のCNAPP製品は、このような事象を単体の設定不備ではなく「リスク」として捉えます。

• 脆弱なパスワードを検出
• 対象マシンのネットワーク経路を特定
• 権限とアクセス可能なストレージを評価
• ストレージ内データの重要度を評価

単純な設定不備を機械的に検出するのではなく、攻撃された場合に引き起こされる事象の重大度や攻撃容易性を踏まえ、対応が必要か否かを判断するのが現在の主流です。

CNAPPは、CSPMによるネットワーク経路、CWPによる脆弱な実行環境の検知、CIEMによる権限評価、さらにはDSPMによるデータの重要度評価まで。個々の概念を横断的に組み合わせ、リスク評価する方向へと進化しています。

では、各製品で何が違うのか。少なくとも「何が検出できるか」という観点だけを見れば、差は限定的です。違いが現れるのは、組織全体として何をゴールに置くのか、その設計思想の部分でしょう。

微小な差異は無限ですが、大雑把に分ければ方向性は2つに分類されます。ただ、どちらが正解という話ではなく、目指すゴールが異なるだけです。

1. 中央統制型

これまで通り、セキュリティエンジニアがリスクを集約・評価し、対応方針を決定するモデル。

メリット	専門家による統制が可能。人的リソースが十分であれば、分散型よりも高い安全性を維持できる。
デメリット	システムが肥大化するほど、要求される人的コストも比例して増大する。

2. 責任分散型

リスクの認識と初動対応をインフラエンジニアに移譲し、セキュリティエンジニアは結果の統制に専念するモデル。

メリット	セキュリティエンジニアの負荷が低く、インフラ側もリスクを「自分事」として捉えやすい。
デメリット	拠り所となるセキュリティ憲章が存在しない場合、統制は急速に形骸化し、事実上の無政府状態に陥る可能性がある。

ツールとゴールは一文字違う

誰が見て、誰が判断し、誰が責任を持つのか

では、選ぶべき基準は何か。少し逆説的に考えたほうが、かえって分かりやすいかもしれません。まず決めるべきは、ゴールです。

「セキュリティを強化したい」「リスクを下げたい」と掲げることは簡単ですが、何が不足しており、何を実現すべきかを具体化しなければ意味がありません。掲げるだけで実現するのであれば、私もとっくにFIREしています。

この部分が曖昧なままだと、評価軸は「機能の多さ」や「検知項目の数」に寄りがちです。機能が多いこと自体は、決して悪ではありません。ただし、要件に合致しない機能はデッドウェイトであり、運用上は飾り以上の意味を持たないことも多い。

次に決めるべきは、運用の主語です。

一体誰がアラートを見るのか。どこが対応するのか。

何を判断基準に、対応の要否を決めるのか。全体としての状況を俯瞰するのは誰か。例外の許可は誰が出すのか。リスクの責任を誰がとるのか。このあたりが「状況次第」「ケースバイケース」と曖昧にされたままだと、製品は正しく動作しますが、組織は正しく動作しません。

実際、こうした点を決めないまま導入し、検知されたアラートを手当たり次第に処理し始めた組織がありました。結果、1年ほどで累積した未処理アラートは100万件。製品は正常、データも正確。ただし、誰も処理しきれずに積み重なるだけ、という状態です。

3つ目は、現在地の把握です。遠大なビジョンを持つこと自体は悪くありません。ただし、現時点で前提条件が揃っているかどうかは別の話です。一段飛ばしで階段を駆け上ろうとしても、足を踏み外すだけです。

ここまで整理できて、はじめて「どの製品を選ぶか」という話に進めます。必ずしもベストフィットである必要はありません。ゴールが明確で、それを必要十分に満たせるのであれば、目的は達成できます。これは特別な話ではなく、通常のシステム開発と同じです。いわゆる要件定義、あるいはプロジェクト憲章を策定する段階の話になります。

例えば、責任分散型を選ぶ場合。アラートはできるだけインフラエンジニアに近い場所へ落とされ、修正のガイドも「誰の責任か」「どう直すべきか」「放置すると何が起きるか」といった粒度で提示されます。

このモデルは成熟度が高い場合には非常によく回ります。一方で、組織内にセキュリティに関する共通言語が存在しない場合、「検知はされているが、誰も責任を取らない」という静かな事故が発生しがちです。

では、中央統制型の場合はどうか。修正のガイドは「直し方」と「リスク」に集約される傾向があります。ただし、集約されているからこそ、専門家が「何を優先して直すべきか」を継続的にフォローできます。セキュリティ専門人材が十分に確保されている場合には、非常に強力なモデルです。

逆に言えば、人が足りない状態で導入すると、「見えているが手が出ない」という、精神衛生上あまり好ましくない状況が生まれやすい。内製を増やすのか、運用の一部を外部に委託するのか。判断によってギャップを埋めることは可能です。

ただし、忘れてはいけない点もあります。セキュリティは本番業務です。開発フェーズのように、トライアルアンドエラーを前提とした改善は容易ではありません。製品によってカスタマイズ性には大きな差があり、導入後になって「作り込めない製品だった」と気づくのは致命的です。

CNAPPは安い買い物ではありません。すぐに乗り換える、という選択肢は現実的ではなく、費用だけでなく、導入までに投じたコミュニケーションコストも無視できません。さらに、費用構造そのものも重要です。製品ごとにライセンスの数え方は異なり、一見リーズナブルに見えるソリューションでも、構成次第では二倍、五倍といった価格差が生じることも珍しくありません。

ここまで読んで、「当然だろう」「うちは大丈夫だ」と思った方は、おそらくこの記事の想定読者ではありません。むしろ、こちらが教えを乞う側です。

後編では、ゴール不在のまま導入した組織がどう破綻するか（そしてどう立て直したか）、さらに「相談・問い合わせ前に揃えるべき情報」をチェックリストに落としていきます。