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

本稿は、CNAPP導入前に揃えるべき条件を、前後編にて整理する後編です。前編では、CNAPP製品選定の前に現状把握が必須な理由と、誰が見て、誰が判断し、誰が責任を持つのかについて説明しました。

後編では、失敗事例と成功事例、ツールとルールを適合させるための盲点を洗い出す重要性、CNAPP相談や問い合わせ前のチェックリストをご紹介します。

仕様書通りの動作、仕様書通りの重大事故

失敗事例と成功事例

明確なゴールを定めないまま導入した結果として、最も分かりやすい帰結がこれです。

システムの状況は可視化され、リスクは一覧化される。いわゆる「見える化」が達成され、一安心。見えなかったものが見えるようになったこと自体は前進です。ただし、本当に目的は「見ること」だったのでしょうか。

最初は驚き、次に感心する。そして満足し、いつしか「また出ている」という慣れに変わる。これは改善ではありません。実態としては状況の悪化です。リスクに対する不感症は、重大インシデントの主要な原因になり得ます。

検知されたリスクは、どれも正しい。しかし、それをどうするかのゴールがない。ゴールがないから、誰が何をすべきかが分からない。結果として、対応は属人的、ただし「誰かが処理している」という事実だけは残る。そして、その事実をもって「なんとなく」満足してしまう。これは意志の問題ではなく、構造の問題です。

失敗事例：名前も間違え、居場所も知らず
── 意図せぬ公開ストレージ

外部公開されているクラウドストレージがありました。ネーミング上は「意図して公開した」ように見える名称だったため、担当者は深く考えず、結果として放置していました。アラート検知後の調査や運用フローが整備されていなかったからです。

その結果、当該ストレージは2つのリスクを内包していたことが判明し、インシデントとなりました。1つは言うまでもなく、外部に公開されていたこと。もう1つは、ネーミングルールを誤り、「外部公開対象であるかのように」命名されていたことです。

該当アラートを開けば問題点は明確でした。そもそも、外部開放されるべきではないリージョンに作成された資源だったのです。これでは、「導入した」とは言えても、「活用している」とは到底言えません。

次の事例は、肌感覚でイメージがつくかもしれません。IAMでの権限管理の問題です。

失敗事例：永続的な一時権限
── 作業ロールの無効化漏れ

あるユーザでは、アカウントを横断して同一作業を実施する必要が生じました。そのため、一時的に作業用ユーザへ高権限を付与しています。問題は、作業完了後です。

権限を付与したことの確認は容易です。付与されていなければ、そもそも作業が完了しないからです。一方で、後片付け──すなわち権限の除去確認には、どうしても属人性が入り込みます。確認が形式的になり、やがて精度が落ちていく。

システム構築に例えるなら、単体テストの結果確認に近いでしょう。実行したかどうかではなく、「本当に評価としてOKか」。

この種の作業で、私自身も一度、痛い目を見たことがあります。詳細は控えますが、残業代で手取りが20万円ほど増えた、と言えば伝わる方には伝わるかもしれません。タクシー帰り、気分はお大尽というより護送される囚人でした。

この事例でも、作業が完了したにも関わらず、一時権限が残存したユーザが複数いることが後日検知されました。高権限が付与され、アラートとして発報される。そこまではいい、作業中だからと静観できます。しかし、作業完了後にアラートが解消されているかの確認が行われなかった。「一時的」の終わりは、自然には訪れません。これも、アラートに対する対応フロー未整備の問題です。

ツールが組織に完全に定着する。誰も否定しない。誰の手も煩わせない。ただし、「誰にも負荷をかけない」が「誰も気にしていない」に近づくと、少々問題です。

ゴールは定義されず、あるいは定義されていても更新されない。リスク許容度も見直されないまま、「去年と同じ」という惰性で運用が続いていく。見落としは人的ミスとして処理され、原因は個人に帰属され、PDCAサイクルは回されなくなります。それでも、「自分たちはセキュリティに気を使っている」という満足感だけは強く残ります。

こうした組織では、いっそ生成AIを活用して顛末書の作成を自動化したほうが、業務としては効率的かもしれません。幸い、最近の生成AIは、この種のドキュメント生成を非常に得意としています。一方で、対照的な成功例もあります。次は、外部漏洩を予防・抑止するという目的だけに注力した例です。

成功事例：身を捨ててこそ浮かぶ瀬もあれ
── セキュリティ統制を人の手に取り戻した例

あるユーザは、指摘されるすべてのリスクに対応することを「放棄」しました。その代わり、システムを4種類に分割（外部開放するか／重要情報を持つか）し、属性ごとに重視する監視項目を定義。外部からのアクセス経路の有無と、データ暗号化の有無。それ以外は切り捨てです。

結果として、出力数は約1/100まで削減。対応対象が常に"手で扱える範囲"に収まり、優先度の高い設定ミスが"人の目に届く"ようになりました。

CNAPPを入れただけで終わる根本的な原因は、それを使って何をしたかったのかが、いつの間にか問われなくなっていることです。そして問題が顕在化したときに残るのは、「ツールは入れた、自分たちの責任は果たしたはずだ」という綺麗な言葉だけ。形骸化した構築プロジェクトでは、決して珍しい光景ではありません。

用心棒（ツール）に誰がルールを示す？

ツールとルールを適合させるための盲点を洗い出す

第一歩として考えたいのは、「相談すること」です。三人寄れば文殊の知恵。ひとつの問題を三人で抱えれば、数学的にはダメージも三分の一。致命傷だけは避けられるかもしれません。

冗談はさておき、この視点は重要です。直近でも、それを痛感させられる出来事がありました。

弊社では複数のCNAPPソリューションを検証できる環境を用意しています。その中で、自分としては「コストと機能のバランスから見て、これは良い」と判断した製品がありました。一方、インフラエンジニアに近い立場の複数メンバーは、別の製品を支持していた。見事な正面衝突です。

では、なぜ食い違ったのか。ヒアリングを重ねる中で浮かび上がってきたのは、「暗黙知の差異」でした。

• どの情報が分かっていれば十分なのか
• どこまでが"前提知識"として共有されているのか
• どの粒度のガイドが現場に必要なのか

自分は、「このリスクなら、この手順で対応するのが当然だろう」という前提で考えていました。その前提に立つと、対応精度やカスタマイズ性に優れた製品が魅力的に映る。

一方、インフラエンジニアが重視していたのは、「このアラートは誰の主管なのか」「どの順番で対応すべきか」が即座に分かることでした。つまり、現場で手が止まらない情報が最短距離で出てくるかどうかです。その観点では、別製品の方が実務に直結するという評価でした。

結局のところ、無意識のうちに常識と思い込んでいた前提知識にズレがあったのです。自分にとっての当たり前は、必ずしも他人の当たり前ではありません。このケースは、そのことを強く実感させられ、とても勉強になった出来事でした。

だからこそ、まずは雑談がてら相談してみる。そんな始め方でも良いのではないでしょうか。もちろん、相談相手はラックでなくても構いません。ですが、私たちはPrisma Cloudを活用したクラウドセキュリティ統制支援を、CSPM黎明期から提供してきました。要件整理から運用設計、実装後の定着まで、一通り"痛い目"を見てきた経験があります。現在はその知見を引き継ぎ、モダンCNAPPの選定・運用設計支援として提供しています。

私たちができること：現在地の確認と、暗黙知の言語化

私たちができることは、実はとても地味です。「現在地の確認」。いま何が起きているのか。どこまで準備できているのか。何に詰まっているのか。まずは雑談ベースで棚卸しします。

話しているうちに、違和感が出る箇所が必ずあります。だいたいそこに"暗黙の了解"が埋まっています。その暗黙知を白日の下に晒しつつ、いまの状況に合う運用モデルと、相性の良いCNAPPを一緒に見立てる。必要なら導入後の運用もフォローする。やることはそれだけです。

CNAPPは「雇うこと」が目的ではありません。雇ったあと、どうPDCAを回すか。この部分で、私たちは血と汗と涙を流してきました。ここ数年、CNAPPの概念は成長期で、拡大の一途を辿っています。裏を返せば、CSPM、CWP、CIEM、DSPM──それぞれの概念が現場に降りてくるたびに、順番に痛い目を見てきた、ということでもあります。

私たちができないこと：決断と責任

逆説的に、下記のようなお手伝いはできません。

1. 全社的なセキュリティ憲章の制定

目指すべきゴールは、お客様の意思決定そのものです。外部である私たちが代行することはできません。ただし、憲章が曖昧な場合に「どの方向に破綻しやすいか」を経験則としてお伝えすることは可能です。

2. 検知されたリスクへの直接対応（運用代行としての恒常対応）

いわゆる運用代行には、クラウド環境への強い編集権限が必要になります。これは外部に管理権限を渡すのとほぼ同義で、統制上の新しいリスクになります。

3. クラウドインフラに対する唯一絶対のベストプラクティス提示

セキュリティ上のあるべき姿は示せますが、利便性と統制の配分は、お客様自身が決めるべき領域です。ここを外部が決めてしまうと、責任の所在が曖昧になり、統制設計そのものが崩れやすくなります。

荒野に一歩、踏み出す前に

CNAPP相談・問い合わせ前のチェックリスト

来年、汗をかかないために。今から一緒に、少しだけ汗をかきませんか。

相談の成果物は「正解」ではありません。いまの状況を整理し、どこに力を入れるべきか、どこを割り切れるか。その輪郭をはっきりさせることです。

規模や構成によっては、新規導入をせずともAWS Security HubやMicrosoft Defender for Cloudなど、各クラウドのネイティブ機能（例：設定監査、推奨事項、脅威検知）で十分な場合もあります。だからこそ、最初に「前提」を固める必要があります。

相談前に、次の問いに向き合っていただければ十分です（「今は答えられない」も歓迎です）。

CNAPPは、雇った瞬間に街を守ってくれる用心棒ではありません。どんな掟に従わせ、どこまでを任せ、どこから人が判断するのか。そこが定まって、はじめて"戦力"になります。

だからこそ、まずは雑談でも構いません。地図を広げて、「いま自分たちはどこに立っているのか」を、一緒に確認するところから始められればと思います。