作成者別アーカイブ: 諸角昌宏

セキュリティを脅威で語るかぎり、対策は終わらない

コメントをどうぞ

2026年6月13日
ゼロトラストWGリーダー　諸角昌宏

本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のないご意見をいただければ幸いである。

はじめに：ツールは増えたのに、不安は減らない

セキュリティ対策の一覧表を開くとそこに並んでいるのは、EDR、SASE、WAF、SIEM、メールセキュリティ……。気がつけば、対策の一覧が「導入済み製品の一覧」になってはいないだろうか。

毎年新しい脅威レポートを読み、新しい製品を検討し、予算を確保し、導入する。それでも不安は消えない。次の脅威が報じられれば、また次の製品の検討が始まる。多くの組織で、セキュリティはこのサイクルの中にあると思える。

本ブログでは、このサイクルの原因が担当者の問題ではなく、「セキュリティを脅威への対抗として捉える」という捉え方そのものにあることを示し、意思決定の起点に置く問いを入れ替えることで、やるべきことの順番と、それを組織に通す力がどう変わるかを提案してみたい。

第1章. 脅威を主語にすると、対応は「脅威ごとの足し算」になる

セキュリティの議論は、多くの場合「脅威」から始まる。新型ランサムウェア、サプライチェーン攻撃、AIを悪用した攻撃。脅威を主語に置くと、問いは自動的に「この脅威をどう防ぐか」になる。

ここに見落とされがちな構造がある。脅威はマルウェア、エクスプロイト、DDoSといった、個別の技術的な現象として記述される。個別の脅威の粒度で立てられた問いは、その脅威に対応する個別の対策——検知ルールの追加、設定の強化、訓練、そして最も典型的には対策製品の導入——を引き寄せることになる。しかし、いずれの形を取るにせよ、対応は脅威ごとの足し算になる。フィッシングにはメール対策と訓練を、ランサムウェアにはEDRとバックアップを、という具合に、脅威と対策の対応表を埋めていく発想である。

もちろん、脅威の認識から組織の足腰に関わる対応に至る場合もある。ランサムウェアの被害事例を見て、バックアップと復旧体制の見直しに取り組んだ組織は実際にある。しかし注意深く見ると、そこでは問いがいつの間にか「この脅威をどう防ぐか」から「攻撃されても戻ることができるか」に翻訳されている。この翻訳が起きなければ、対応は最短距離にある個別対策の追加——多くの場合は製品の導入——に着地してしまう。問いの立て方は答えを決定するわけではないが、答えの探索範囲を強く方向づける。そして現状、この翻訳は仕組みではなく、担当者個人の力量か偶然に任されてしまっている。

この「脅威ごとの足し算」は、以下の3つの帰結を生むと考える：

  1. 第一に、対策の全体像が「脅威と対策の対応表」になり、表の行を埋めた時点で完了した気になってしまう。個々の対策が製品か設定か訓練かに関わらず、対策同士の整合性や、それらを支える土台（資産管理、復旧力など）の有無は問われない。
  2. 第二に、責任が脅威に最も近いセキュリティ部門とベンダーに局所化され、経営・業務部門・一般の従業員にとってセキュリティは「自分の問題ではない」ものになる。
  3. 第三に、脅威は無限に更新され続けるため、足し算も無限に続く。新しい脅威が報じられるたびに対応表に行が増え、予算と人の疲弊を生む。冒頭の「対策一覧がツール一覧になる」現象は、この足し算の力学に、製品の形で答えを供給する市場の力学が重なった、最も目に見える症状である。

実例：「VPNは危険だ」という言説

身近な例がVPNを巡る言説である。ランサムウェア被害の報道でVPNが侵入経路として言及されることが増え、「VPNは危険だ。脱VPN・ゼロトラスト移行を」という言説が広まった。脅威（VPN経由の侵入）を主語にした瞬間、答えは「VPNを捨ててZTNA/SASE製品を買う」という製品の置き換えになってしまう。

しかし、以前のブログ（「VPN利用の現状と脱VPNの現実性について」）において、「SaaSセキュリティリーグ」での実務者による議論が示す現実は、もっと複雑である。VPNの利用は、従業員のリモートアクセス・サードベンダー用アクセス・拠点間アクセスという用途ごとに事情が異なる。SIPの制約でVPNを残さざるを得ない領域があり、SASEのコストの問題があり、パートナーからVPN接続を求められれば運用での統制で対応するしかない場面もある。

つまり実務の答えは「製品の総入れ替え」ではない。自組織のアクセス経路を棚卸しして把握し、リスクの高い経路から優先的に手を打ち、技術で解決できない部分は運用で統制することである。さらに言えば、VPNが侵入経路となった事故の多くで実際に効いてくるのは、VPNという技術の存在そのものではなく、パッチ未適用の機器や多要素認証の不在、棚卸しされていないアカウント、つまり基本対策の穴である。

「VPNは危険だ」という脅威の語りは、この現実をすべて覆い隠し、「どの製品に乗り換えるか」という問いだけを残してしまうことになる。

注意：　断っておきたいこと

誤解のないように、これは現場のセキュリティ担当者への批判ではない。脅威ごとの足し算を続けさせてきたのは、脅威の深刻さでしか動かない予算プロセスであり、恐怖を喚起することが最も効率的な営業手段になっているセキュリティ市場の構造であり、さらに遡れば「情報セキュリティとはCIAを維持すること」という定義の構造である。この定義が歴史的にどう成立したかはともかく、CIAは結果として、攻撃者が情報に対してできること（見る・変える・使えなくする）に対応している。そのため、この定義のもとでは、関心が自然と「侵害が有るか無いか」に向かいやすい（この対応関係と、CIAを目的ではなく評価軸として捉え直す考察は、以前のブログ「ゼロトラストとCIA（前編）」「同（後編）」を参照）。

現場は、この構造の中で最善を尽くしてきた。問題は人ではなく、語りの構造にある。だからこそ、語りの構造を変えることに意味があると考える。

第2章. 捉え直し：セキュリティとは「コントロール可能にすること」

では、脅威の代わりに何を主語に置くべきか。

以前のブログ「ゼロトラストとCIA（後編）」は、情報セキュリティの目的を「コントロール可能にすること」、すなわち何が起きても、把握し・対処し・戻れる状態を保ち続けることと再定義することを提案した。CIAは目的ではなく、その状態を評価するための軸である。

この捉え直しの実践的な意味は、問いが変わることにある。「この脅威をどう防ぐか」ではなく、「何が起きても、我々は把握し、対処し、戻れるか」である。前者の答えは脅威ごとに積み上がる個別対策となるが、後者の答えは脅威を横断して効く組織の能力となる。資産を把握しているか。侵害の影響を限定できる設計になっているか。何日で事業を戻せるかを自分たちで決められているか。何が起きたかを後から説明できるか。これらは特定の脅威のための対策ではなく、どんな脅威に対しても効く土台であり、その大半は技術製品ではなく組織の営みである。脅威は無限に増えるが、保つべき能力は有限である。足し算が無限に続く世界から、有限の土台を育てる世界への転換と言うこともできる。

実例：Mythosレディの正しい読み方

この捉え直しが机上の空論でないことを示すのが、いま最も「脅威論」を煽りやすい題材、すなわちAIによる攻撃能力の問題であると考える。

2026年4月のClaude Mythos Previewの登場は、AIが脆弱性発見からexploit生成までを機械速度で実行しうることを示し、大きな衝撃を与えた。恐怖で語ろうと思えば、いくらでも語れる題材である。そして脅威論で受け取った組織は、「Mythosにどう対抗するか」「Mythos対策製品はどれか」という問いを立てるであろう。

しかし、「AI脆弱性の嵐」を解説したブログ「Mythosレディとは何か」は、まさにこの読み方を明確に退けている。Mythosレディとは「すごいハッキングツールに対抗する体制」のことではない。すなわち、脅威論として捉えるべきではない、と言っている。実際、各社モデルの能力は急速に収束しており、「Mythosだけを管理すればよい」という特定脅威への対応は、すでに現実から離れつつある。特定の脅威に紐づけた対策は、脅威が一般化した瞬間に意味を失う。脅威を主語にしたアプローチの賞味期限は、それほど短いと考えられる。

注目すべきは、この最先端の脅威に対して同文書が示した処方箋である。それは新しいAI防御製品の導入ではなく、まず取り組むべきは、資産管理、ネットワークセグメンテーション、パッチ管理の継続化、IAM、多層防御の再設計という基本対策の強化であり、その目的は「コントロール可能な状態の実現」である。高度な攻撃への対策より、基本の穴を塞ぐことが先決である。攻撃者は最も弱い点を狙う。

ただし、ここで言う基本対策は「一度整備すれば終わり」のものではない。ブログ「Mythosレディとは何か」の続編-2「VulnOpsとCTEM：継続的脆弱性管理の具体的な実装」が示すように、脆弱性の発見から武器化までの猶予が数時間レベルに縮むと言われている環境では、「スキャンしてパッチを当て、次のスキャンを待つ」という定期イベント型の運用は、その前提から崩れてしまう。だからこそこのブログでは、脆弱性の発見・優先順位付け・修復を常時回し続けるVulnOpsとCTEM、すなわち基本対策の継続的な運用化をMythosレディの中核に据えている。

機械速度のAI攻撃という、史上最も恐ろしげな脅威ですら、行き着く答えは新奇な対抗製品ではない。基本対策を、環境の変化速度に合わせて回し続け、コントロール可能な状態を「保ち続ける」ことなのである。

第3章. 基本対策は「地味な義務」ではなく「コントロール能力の部品」である

脅威を主語にした世界では、基本対策は分が悪い。脅威は常に「新しいもの」として報じられるが、資産管理もパッチ適用もバックアップも何十年も変わらず、ニュース性がなく、ベンダーが売り込む目玉にもならない。結果、最新製品が積み上がる横で、足元の基本が穴だらけになる。そして実際のインシデントの多くは、高度な攻撃ではなく、その基本の穴から起きている。

しかし「コントロール可能にすること」を目的に置くことで、基本対策の位置づけが一変する。基本対策とは、組織のコントロール能力を構成する部品そのものである。

  • 資産管理・ログ収集は「把握する」能力の実体である。何を持っているか知らずにコントロールはできない
  • アクセス制御・最小権限・MFAは「対処する」能力の実体である。侵害が起きたとき、攻撃者が動ける範囲を最初から狭めておく営みである
  • バックアップと復旧訓練は「戻れる」能力の実体である
  • 監査ログの保全・記録は「説明できる」能力の実体である
  • パッチ適用と脆弱性管理の継続運用は「適応し続ける」能力の実体である。VulnOps/CTEMは、この能力を機械速度の環境に対応させた実装形態にほかならない

高度な製品は、この基本の上に載る追加部品にすぎない。たとえば、資産台帳のない組織にEDRを入れても、アラートが指す先が分からなければ対処できないということが起こりうる。

第4章. 実践：問いを入れ替える

実践の核心は、新しい施策の追加ではない。意思決定の起点に置く問いを、入れ替えることである。第1章で見たように、脅威の問いから組織的な答えに至るには問いの「翻訳」が必要であり、それは現状、個人の力量か偶然に任されている。ならば、翻訳を偶然に任せず、最初から翻訳後の問いを置くようにしたい。つまり、「この脅威をどう防ぐか」をやめ、「何が起きても、我々は把握し、対処し、戻れるか」と問うことである。これは、抽象論ではない。セキュリティ担当者が日常的に立てる問い（あるいは経営や他部門から投げかけられる問い）に、そのまま当てはめることができるものである。以下に、そのいくつかの例をあげる：

場面よくある問い新たに入れ替えた問い
重大な脆弱性が公表されたCVSSスコアが高い。対応すべきか。この脆弱性は自社のどこに存在するか、それにすぐに答えられるか。実際の悪用は始まっているか。塞ぐまでの間、悪用に気づく手段はあるか。
他社の大きな被害が報道されたうちの会社は同じ攻撃を防げるか。同じことがうちの会社で起きたら、何時間で気づき、何日で事業を戻せるか。
ベンダーから製品提案を受けたこの製品はどの脅威を防げるか。この製品は我々のどの能力を高めるか。それを活かす土台（資産管理など）は整っているか。
インシデントの振り返りなぜ防げなかったのか。誰のミスか。検知・対処・復旧のどこで時間を失ったか。次は、もっと早く気づき、早く戻れるか。
新システムの導入審査セキュリティ要件のチェックリストを満たしているか。このシステムで事故が起きたとき、気づけるか（ログ）、影響を限定できるか（権限）、戻せるか（バックアップ）。
経営への報告・予算要求今月の脅威動向はこの通り。この脅威への対策費がほしい。検知から対処までの時間は縮んだか。元の状態に戻すのに、いくら投資するか。
従業員への注意喚起怪しいメールを開かせないために、どう注意喚起するか。異変に気づいた従業員が、責められずに、すぐ報告できるようになっているか。

以上のように、入れ替えの規則は単純である。よくある問いの主語は「脅威」や「製品」であるが、入れ替えた問いの主語はすべて「我々」であり、問うている中身は、第3章で挙げた能力——把握する、対処する、戻れる、説明できる、適応し続ける——のいずれかである。会議において問いが脅威や製品を主語にし始めたと気づいたら、「それは、我々のどの能力の話か」と置き直すことが重要である。それだけで、議論は製品の比較から、自組織の足りない土台の話に戻ってくると考えられる。

この問いの入れ替えは、特に経営との対話で効いてくると考えられる。脅威ベースの予算要求では、経営は投資の効果を確かめようがない。それは、攻撃が起きなかった場合、それが投資のおかげなのか、単に運が良かっただけなのかを、区別できないからである。効果が測れない以上、出すか出さないかの判断のよりどころは「どれだけ怖いか」しかなくなってしまう。したがって、恐怖が薄れれば予算は削られ、「昨年対策したのに、なぜ今年もまた要るのか」という問いに答えられなくなる。

これに対し、能力を問う形の予算要求では、投資の前後で数値化が可能になる。検知から対処までの時間がどれだけ縮んだか。復旧訓練で目標時間内に事業を戻せたか。資産の把握率がどれだけ上がったか。効果が測れれば、経営は他の事業投資と同じ物差しでセキュリティを評価し、判断できる。また、能力は放置すれば劣化するものだから、継続的に投資が必要な理由も自然に説明がつく。基本対策の地味な工数に予算と権限がつかないことに悩んでいる現場にとって、これは武器になるはずである。

なお、基本対策が進まない理由の多くは、現場の問題ではなく組織的な障壁である。パッチを当てたくても、古い基幹システムは業務への影響が大きくて止められず、停止する日程について関係部門の合意が取れない。資産の管理責任者が誰なのか分からない。業務部門の協力が得られない。これらは技術では解決できず、経営層の関与によってしか解決できない。NIST CSF 2.0がGovern機能を独立した柱に据えたのは、この認識の表れであると考える。だからこそ、経営に通じる問いへの入れ替えは、現場の自助努力の話ではなく、構造を動かすための要件なのである。

おわりに：脅威とは、天気予報のように付き合えばよい

最後に、誤解のないように以下の2つの点を補足しておきたい。

第一に、本ブログは「脅威を無視してよい」と言っているのではない。台風が近づいていると知れば、私たちは怖がって騒ぐのではなく、雨戸を閉め、ベランダの物を固定し、停電に備える。台風の情報は、人を怖がらせるためのものではなく、備えるためのものである。脅威の情報も同じように扱うべきであると考える。実際、現場では既にそうしている。脅威インテリジェンスを検知に活かすことや、実際に悪用されている脆弱性（KEV）から優先的にパッチを当てる判断は、まさに「備えるための情報利用」であり、「把握する」能力の一部である。本ブログが見直したいとしているのは、人を怖がらせて動かすための脅威の使い方であって、こうした実務まで否定するものではない。

第二に、「コントロール可能にすること」は、新しいバズワードでも、新しい製品カテゴリでもない。NIST CSF、Assume Breach（侵害を前提とする）、レジリエンスといった、現場がすでに知っている考え方を、一つの目的としてまとめ直したものである。この捉え直しのために、新しく製品を買うというようなものではない。

現場のセキュリティ担当者であれば、本ブログの内容の多くは、すでに肌で感じていることだと思う。防御製品を並べても侵害は起き、勝負を分けるのは把握と復旧であることを、インシデントを経験した人ほど知っている。足りていなかったのは知識ではなく、それを組織に通すための問いの立て方だったのではないだろうか。「この脅威をどう防ぐか」ではなく、「何が起きても、把握し、対処し、戻れるか」。この問いから始めることが重要と考える。

以上

社内セキュリティ教育のリアルと、これからの変え方

コメントをどうぞ

第6回SaaSセキュリティリーグ会議

「SaaSセキュリティリーグ」は、SaaSユーザー企業の実務者同士で情報交換を行う取り組みである。SaaS管理者やセキュリティ担当者を横串でつなぎ、知見交換を行うことで、セキュリティレベル向上に貢献していくことを目的としている。ここでは、「SaaSセキュリティリーグ」が行った第6回会議の内容をまとめて公開する。

問題点の概要

サイバー攻撃の巧妙化・多様化が急速に進む中、企業のセキュリティ対策において「人」の要素がかつてなく重要になっている。

ディスカッション内容

各社が実際にやっていること

実施中の施策を共有したところ、以下のように各社の「リアルな現場感」が浮き彫りになった。

  • グループ会社からEラーニングと迷惑メール訓練が降ってきて、それを実施している。
  • 新入社員研修に2時間ほどのセキュリティ講義を盛り込んでいる。基本的な教育として、社用のPCの使い方とか、勝手にクラウド/AIのサービスを使わない、迷惑メール訓練等を行っている。
  • 月1回でセキュリティ啓蒙資料を公開し、週次でコンテンツを提供している。
  • セキュリティ・ワークショップを希望者向けに企画中である。タッチポイントを増やすことを意識している。
  • 年1回のEラーニングとフィッシングメール訓練に加え、情報セキュリティポータルから時事ネタを発信している。社内インシデントの再発防止策を3か月に一度、事案ベースで共有している。
  • グローバル企業であるので多言語対応が必須である。また、経営層向けのサイバーセキュリティ教育を外部機関と組んで実施し、部門長レベルにも個別に教育を展開している。
  • セキュリティだけでなく、世の中で起こっている問題の研修を行っている。

「本当に身についている」か、正直なところ

  • フィッシング訓練を繰り返しても、クリックしてしまう人は一定数存在する。抜けてしまうスパム等については問い合わせが増えているが、ウイルス検知については問い合わせが来ていなくて、うまく駆除できていない可能性がある。問題は、「報告する＝恥ずかしい」という空気が漂い、報告が滞ることである。
  • メールテストの内容：差出人とURLのチェック、内容確認として緊急を煽るものを入れている。教育として見逃せないことは、Eラーニングでどのようなトピックを挟むかである。

従業員の「気づく力」と「報告する文化」が重要

  • クリックした社員を非難する文化があると報告文化が育たない。目指すべきは「完璧な社員」ではなく、「気づいたら躊躇なく報告できる組織」である。
  • 「空振りはかまわないよ！」を周知する。疑わしきは報告する文化の形成が重要である。
  • Slackに報告用ワークフローを設けた企業では「わりと効果が出ている」という声がある。報告のハードルを下げる設計が、報告文化の醸成につながっている。

ルールを守らせるのか、リスクを理解させるのか

この問いに対して、参加者の意見はわかれた。 「ルールは出すが、背景を伝えることで理解につなげている。なぜそのサービスを使ってはいけないのか、セキュリティ的な理由を説明する」——という声がある一方で、「現場は余裕がないので教育時間を増やせない。基本を教えることがルールになるのかもしれない」という意見がある。

理解させたいのは山々だが、現場に余裕がない。基本を教えることがそのままルールになってしまうというのが現実のようである。したがって、重要なのは、ルールの背景にある「なぜ」を伝えることで、完全な理解は難しくても「疑わしきは報告」という行動原則を染み込ませることはできるのではないかと考える。

変えていくための4つのアプローチ

  1. 継続的なタッチポイント
    年一回の研修だけでなく、週次・月次の小さな接触の積み重ねが必要である。ワークショップ、ニュースレター、Slack等を組み合わせるのが望ましい。
  2. セキュリティチャンピオン
    万人向けの深い教育は難しい。まず各部門に「わかっている人」を育て、周囲を巻き込む構造を作る。
  3. 経営層・部門長の巻き込み
    セキュリティを現場だけの問題にしない。経営課題として位置づけ、部門長が旗を振ることで優先度が上がる。
  4. 効果測定と改善サイクル
    KnownBE4のような動画による教育も有効である。ツールを使うことで集計・測定が可能になるのが良い。「感覚」ではなくデータで効果を見える化し、改善につなげる。

どのアプローチも共通するのは「地道に続けること」である。セキュリティ教育に即効薬はない。以下のような日々の小さな改革の積み重ねが、組織のリテラシーを底上げする。

  • 報告のハードルを下げる——Slackワークフロー、専用フォームなど「気軽に言える場」を作る
  • 「空振りはかまわない」を明言する——報告した社員を絶対に責めない文化を経営層が宣言する
  • インシデント事例を定期共有する——他社・自社の事例を定期的に共有し、「対岸の火事」にしない
  • 効果を測定する——クリック率・報告率・アンケート結果を追い、改善サイクルを回す

おわりに

セキュリティ教育の難しさは、「やった」と「身についた」の間にある大きな溝である。年一回のEラーニングを全社員が受けても、翌日にフィッシングメールをクリックする人は出てくる。

大切なのは「完璧な社員を育てること」ではなく、「何か起きたとき、すぐ報告できる組織を作ること」である。そのための文化づくりは、ルール設計よりずっと時間がかかる。しかし、地道に続けることでしか変わらない。

以上

Mythosレディとは何か（続編-2）　～　VulnOpsとCTEM：継続的脆弱性管理の具体的な実装

1件のフィードバック

2026年6月5日
AIWGメンバー　諸角昌宏

本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のないご意見をいただければ幸いである。

はじめに：前回のおさらい

前回のブログ「Mythosレディとは何か（続編）　～　Mythosレディにゼロトラストが有効な理由」では、ゼロトラストがMythosクラスの能力を持つAIによる攻撃に対して有効な5つの代表的な理由を説明した。マイクロセグメンテーションによる横展開の阻止、最小権限による攻撃チェーンの分断、継続的検証による早期発見、egressフィルタリングとの相乗効果、フィッシング耐性MFAによる認証情報窃取の無効化である。そして、3層（第1層（基本対策）、第2層（ゼロトラスト）、第3層（VulnOps・CTEM））を順番に完成させるのではなく、同時に育てることがMythosレディへの現実的な道筋であることを示した。

今回のブログはその第3層、「VulnOpsとCTEM」の具体的な実装について検討する。ゼロトラストが「攻撃者の難易度を上げる」戦略だとすれば、VulnOpsとCTEMは「攻撃者に悪用される前に脆弱性を発見し、修復する」戦略となる。これがMythosレディの中核をなすと考えている。「MythosクラスのAIが脆弱性発見から武器化までの時間をさらに圧縮し、組織が利用できる修復猶予を数日から数時間レベルへ縮小させる可能性がある時代に、従来の脆弱性管理はなぜ機能しないのか。そして何に変わるべきか」について考えていく。

１．なぜ今、脆弱性管理が変わらなければならないのか

従来の脆弱性管理は、基本的に「スキャン→リスクベーストリアージ→パッチ適用→次のスキャンを待つ」というサイクルで運用されている。このサイクルは、根本的な前提として「攻撃者が脆弱性を発見・武器化するまでには時間がある」という前提に基づいている。

Mythos時代に崩壊した前提

「AI脆弱性の嵐」が指摘するように、すでに開示から悪用までの時間は高影響度の脆弱性で数日単位に圧縮されており、数時間以内の武器化事例も報告されている。MythosクラスのAIはこの時間をさらに圧縮し、組織が利用できる修復猶予を数日から数時間レベルへ縮小させる可能性がある。従来のパッチサイクルが「数週間から数カ月」である組織では、このギャップが致命的になる。

加えてCVE件数の爆発的増加が追い打ちをかける。CSAの「VulnOps: Vulnerability Management in the Age of AI」（2026年5月）によると、CVE件数は2020年比で約3倍に増加しており2026年も増加が続いている。さらにNISTのNVDは2026年4月15日、リスクベーストリアージポリシーを発表し、CISAのKEVカタログ掲載のCVEや連邦政府使用ソフトウェアなどに限定してフル分析を提供するようになった（CSA Labsの解説記事）。多くのCVEはCVSSスコアやCPE識別子なしで届くことになり、既存の脆弱性管理ツールが依存してきたパブリックインフラが構造的に変化したと言える。

以上のような状況を踏まえ、従来の脆弱性管理が機能しない理由として以下の3点が考えられる：

  1. スキャンは「瞬間のスナップショット」であり、次のスキャンまでに生まれた脆弱性は見えない。
  2. リスクベーストリアージの基本はCVSS、EPSS、資産価値、攻撃経路、ビジネス影響度を組み合わせてリスクを評価することであるが、CVSSスコアだけで判断している組織が多い。
  3. パッチ適用は人間の作業速度に縛られており、発見から修復までの時間的ギャップ（Exposure Window）が、攻撃者が脆弱性を悪用できる機会を生んでいる。

加えて、CVEの公開件数は年々増加しており、すべてに対応することはリソースの面で不可能に近い。「何を先に直すか」という優先順位付けの精度が、生存を左右する時代になってきていると言える。

「管理する」から「継続的に運営する（Ops化）」へ

この状況への１つの答えが「VulnOps（Vulnerability Operations）」という考え方である。脆弱性対応をプロジェクトではなくオペレーションとして継続的に回していく。発見・トリアージ・優先順位付け・修復・検証・監視というループである。

２．VulnOpsとは何か

VulnOpsとはセキュリティオペレーション（SecOps）の文脈で、脆弱性管理を継続的なオペレーションとして組み込む概念である。「脆弱性スキャンを年2回実施する」とかではなく「脆弱性の発見から修復までのループを常時回す」ことを組織の能力として確立する。

VulnOps（Vulnerability Operations）という用語は、2025年9月にHeather Adkins（Google CISO）とGadi Evronが警告を発し、同年10月にBruce Schneierも加わって「Vulnerability Operations（VulnOps）」という概念を提唱した。その後「AI脆弱性の嵐」でVulnOpsを「恒久的な組織能力」として位置づけ、CSA Labsが2026年5月に「VulnOps: Vulnerability Management in the Age of AI」として定義している。

VulnOpsのループ

VulnOpsは以下のループで構成される。このループは継続的に行われる。

ステップフェーズ内容ゼロトラスト、AIエージェントとの接続
①発見継続的スキャン、SBOM、外部インテリジェンスによる脆弱性の検出など。「いつスキャンしたか」ではなく「常に見えている状態」を目指す。ゼロトラストのプロテクトサーフェスと連動。DAASで定義する資産が対象。
②トリアージリスクベーストリアージの基本はCVSS,
EPSS,資産価値,攻撃経路,ビジネス影響度を組み合わせてリスクを評価する。		プロテクトサーフェスが「どの資産の脆弱性を優先するか」を決める。
③優先順位付け「攻撃者が実際に悪用できるか」という観点で修復順を決める意思決定プロセス。CTEM（後述）のValidationフェーズと連動。実際の経路を検証する。
④修復・軽減パッチ適用を最優先とする。パッチがない場合は回避策（ゼロトラストポリシーの一時強化、セグメンテーション追加など）で影響を軽減する。ゼロトラストポリシーへの即時反映。
⑤検証・監視修復が有効であることを確認し、継続的に監視する。修復後も同一クラスの脆弱性が再発していないかを追跡する。第3層で発見した情報が第1層（パッチ）と第2層（ZTポリシー）に戻る。

ゼロトラストとの連動

VulnOpsとゼロトラストは独立した取り組みではない。ゼロトラストのプロテクトサーフェスがVulnOpsの対象を決め、VulnOpsで発見された脆弱性がゼロトラストのポリシー更新を促していく。この双方向の循環が3層（第1層（基本対策）、第2層（ゼロトラスト）、第3層（VulnOps・CTEM））を「同時に育てる」ことになる。

３．CTEMとは何か、VulnOpsとどう違うのか

CTEM（Continuous Threat Exposure Management）はGartnerが2022年に提唱した概念であり、製品ではなく、企業のデジタル・物理資産の「アクセス可能性・露出度・悪用可能性」を継続的かつ一貫して評価するためのサイバーセキュリティプロセスと能力の集合体である。（出典：Gartner、2022年。https://www.zafran.io/ctem、Gartner原典の直接URLは有料レポートのため、こちらはGartnerの定義を解説したサイト）。つまり、「脆弱性の管理」から「脅威への露出度の継続的管理」へとスコープを拡張したものと理解できる。

ゼロトラストとCTEMの役割分担

CTEMを理解するうえで、まずゼロトラストとの概念的な違いを整理しておく必要がある。ゼロトラストでは、まずDAASの観点からプロテクトサーフェスを定義する。次にトランザクションフローを可視化することで、プロテクトサーフェスに到達可能な経路を明らかにする。これにより、プロテクトサーフェスに対する実効的なアタックサーフェスや攻撃経路を特定できる。ゼロトラストはこれらの経路を厳密に制御・防御するコントロールを設計する。

CTEMはこれを補完する。ゼロトラストが設計した防御が実際に機能しているかを継続的に検証し、環境変化によって新たに生まれた攻撃経路を発見・修復し続ける。ゼロトラストが「プロテクトサーフェスへの攻撃経路を制御する構造を設計する」フレームワークだとすると、CTEMは「その構造が機能し続けているかを継続的に確かめる」フレームワークである。 したがって、両者は競合しない。ゼロトラストのプロテクトサーフェス定義がCTEMのScopingの優先順位を決め、CTEMのValidation（BAS）がゼロトラストのコントロールの有効性を検証し、CTEMが発見した新たな攻撃経路がゼロトラストのポリシー更新を促す。この循環が3層を同時に育てていくと言える。（出典：CSA「Seize the Zero Moment of Trust」2025.01 https://cloudsecurityalliance.org/blog/2025/01/31/seize-the-zero-moment-of-trust）

VulnOpsとCTEMの違い

VulnOpsが「発見した脆弱性をどう処理するか」に焦点を当てているのに対し、CTEMは「攻撃者の視点で自組織の露出度を継続的に評価し、最も悪用されやすい経路から優先的に塞ぐ」という攻撃者視点のフレームワークとなっている。

  • VulnOpsの視点
    • 脆弱性スキャンで発見したCVEを処理
    • CVSSスコアで深刻度を判定
    • パッチ適用を中心とした修復
    • 自組織の資産リストが起点
  • CTEMが加える視点
    • 攻撃者が実際に悪用できる経路を特定する
    • 実際の攻撃可能性（EPSS・BAS結果）で優先順位を決める
    • パッチ以外の軽減策（ZT・セグメンテーション）も活用
    • 攻撃者から見たアタックサーフェスが起点

CTEMの5つのステップ

GartnerのCTEMフレームワークは5つのフェーズで構成される。Mythosレディの文脈で読み解くと以下のようになる。

ステップフェーズ内容ゼロトラスト・AIエージェントとの接続
①Scoping（範囲定義）守るべき対象（アタックサーフェス）と露出（Exposure）の範囲を定義。ゼロトラストのプロテクトサーフェスの定義と直接対応。DAASの4カテゴリで整理。ゼロトラストのNSTACステップ①と完全に一致する起点。
②Discovery（発見）定義した範囲の中で、既知・未知の脆弱性・設定ミス・露出面を継続的に発見する。SBOMやASM（Attack Surface Management）ツールを活用。AIエージェントのMCPサーバー・APIも新カテゴリとして追加。
③Prioritization（優先順位付け）発見した問題の中から「攻撃者が実際に悪用できるか」を軸に優先順位を決める。リスクベーストリアージの複数要素（CVSS・EPSS・資産価値・攻撃経路・ビジネス影響度）を組み合わせて評価し、CVSSはその一要素として使う。Mythosクラスの攻撃が狙う「認証情報・高価値DB・内部API」を優先。
④Validation（検証）Breach & Attack Simulation（BAS）やペネトレーションテスト等で「実際に攻撃が通るか」を検証する。スコアではなく実証で優先度を確認する。ZTポリシーのセグメンテーションが有効に機能しているかの検証にもなる。
⑤Mobilization（実行・定着）修復・軽減策の実行を組織として定着させる。担当チーム・タイムライン・KPIを定義しサイクルで回す。VulnOpsループに統合する。

４．VulnOps×CTEMの実装フレームワーク

VulnOpsのループとCTEMの5ステップを統合した実装フレームワークを以下に示す。理論ではなく「すぐに始められる」具体的なステップとして構成した。

ステップ①　プロテクトサーフェスとアタックサーフェスの棚卸し（Scoping＋Discovery起点）

まず「守るべきもの」と「攻撃者から見える面」を一致させる。ゼロトラストで定義したDAASをCTEMのScopingに直結させる。これにより「VulnOpsが何を守るか」と「ZTが何を制御するか」が同じ土俵で管理できる。

AIエージェントが使うMCPサーバー・APIも、今後この棚卸しの対象として加える必要がある。Agentic Supply Chainのリスクは、エージェントが接続する外部サービスから侵入するパターンが増えている。

ステップ②　リスクベースのトリアージ（CVSSを超える優先順位付け）

発見した脆弱性をリスクベーストリアージで評価する。CVSSは脆弱性の技術的特性を標準化した指標であり、リスク評価の一要素に過ぎない。CVSS、EPSS、資産価値、攻撃経路、ビジネス影響度を組み合わせて「本当に悪用可能か」を評価することが基本である。

ここで、EPSSについて説明すると、EPSS（Exploit Prediction Scoring System）は、特定のCVEが今後30日以内にどこかで悪用される可能性を0〜1のスコアで予測する指標である。CVSSが「脆弱性の技術的特性」を示すのに対し、EPSSは「実際に攻撃に使われる可能性の予測」を示している。CVSSが高くてもEPSSが低ければ修復の緊急度は相対的に下がる。Mythosクラスの攻撃AIは実際に悪用可能な脆弱性を優先的に標的にするため、EPSSによるフィルタリングは特に重要である。

ステップ③　Breach & Attack Simulation（BAS）による実証検証

CTEMのValidationフェーズに対応する。スコアではなく「実際に攻撃が通るか」を自動化されたシミュレーションで確認する。BAS（Breach and Attack Simulation）は実際の攻撃者の戦術・技術・手順（TTP）を安全な環境でエミュレートし、セキュリティコントロールが実際に機能しているかを継続的・自動的に検証するツールだ。ファイアウォール・EDR・SIEMが期待通りに動作しているか、ゼロトラストのセグメンテーションが横展開を実際に阻止できるかを実証する。ペネトレーションテストを補完するが完全に置き換えるものではない。 ペネトレーションテストとの違いは「継続性」である。ペネトレーションテストは年1〜2回の点検であるのに対し、BASは環境変化のたびに再実行できる。MythosクラスのAIが修復猶予を数時間レベルに縮小させる可能性がある時代に、年1回の点検では間に合わない。

ステップ④　修復とZTポリシーの連動更新

脆弱性を発見・検証した場合、パッチ適用を最優先に行う。パッチがない場合・適用までに時間がかかる場合は、ゼロトラストのポリシーを一時的に強化することで影響を軽減する。以下のような対応が考えられる：

  • 発見された脆弱性のあるシステムへのアクセスを一時的にゼロトラストポリシーで制限する
  • 当該システムのセグメンテーションを強化し、横展開の経路を塞ぐ
  • パッチ適用後にポリシーを通常状態に戻し、BASで検証する

ステップ⑤　AIエージェントによる自動化とHuman-in-the-Loop

VulnOpsの各ステップにAIエージェントを組み込むことで、人間が追いかけられない速度のCVE増加に対応できる。ただしAIエージェントを「信頼されたオペレータ」として無制限に動かすことは、エージェント自体が攻撃の踏み台になるリスクを生む可能性がある。パッチ適用やポリシー変更を自律的に実行する権限を持つエージェントが侵害されれば、攻撃者はそのエージェントを通じて組織全体に影響を及ぼすことができる。CSAIのAgentic Control Planeが定義する5要素、すなわちエージェントのID管理（Identity）・何を許可するかの定義（Authorization）・複数エージェント間の調整（Orchestration）・実行時の行動監視（Runtime Behavior）・継続的な信頼検証（Trust Assurance）を、VulnOpsの自動化設計に組み込む必要がある。

AIエージェントをVulnOpsに組み込む際には以下の3点を考慮する：

  1. エージェントにもIDと最小権限を付与する（Identity・Authorization）。
  2. エージェントが実行する修復アクション（パッチ適用・ポリシー変更）は人間の承認ゲートを通す（Human-in-the-Loop）。
  3. エージェントの行動を継続的に監視し、異常な操作を検知する（Runtime Behavior）。VulnOpsを自動化することと、AIエージェントを無制限に動かすことは別の話である。

５．3層が育つ循環

ここまでの実装フレームワークを3層の循環として整理する。まず3層を簡単に復習しておく。

  1. 【第1層：基本的なセキュリティ対策】資産管理・パッチ適用・ログ収集・バックアップ・インシデント対応手順。すべての土台となる。
  2. 【第2層：ゼロトラスト】「信頼しない・常に検証する」のアーキテクチャ。プロテクトサーフェスを定義し、マイクロセグメンテーションと継続的検証で攻撃者の難易度を上げる。
  3. 【第3層：VulnOps・CTEMとAIエージェント】攻撃者に悪用される前に脆弱性を発見・修復する継続的な運営体制。

3層は順番に完成させるものではなく同時に育てるものである。たとえば、VulnOpsとCTEMを第3層として動かすことで、第1層と第2層にどう還流するかの例を以下に示す。

  • 【第3層→第1層】VulnOpsで発見された脆弱性は第1層のパッチ適用に直結する。継続的スキャンが「今週直すべき脆弱性」を特定し、パッチ適用を優先順位付きで実行する。
  • 【第3層→第2層】VulnOpsで発見されたリスクの高い経路は、即座にゼロトラストのポリシーに反映される。パッチがない期間のリスクゼロトラストTが一時的に軽減する。
  • 【第2層→第3層】ゼロトラストのプロテクトサーフェス定義がVulnOpsの対象資産を決め、セグメンテーションの設計がCTEMのScoping範囲を決める。
  • 【第1層→第3層】資産管理が整備されているほど、VulnOpsのカバレッジが上がる。ログ基盤が整備されているほど、BASの検証精度が上がる。

重要なのは「3層のどれかが完成してから次に進む」のではなく、「各層が少しずつ成熟するたびに全体のリスクが下がっていく」ということである。VulnOpsの最初のスキャンが粗くても、ゼロトラストのプロテクトサーフェスが一つだけでも、始めることに意味があると考える。

６．「AI脆弱性の嵐、CISOが押さえるべき重要ポイント」とブログの対応

ここで、「Mythosレディとは何か」の3つのブログと、「AI脆弱性の嵐」において「CISOが押さえるべき重要ポイント」と説明されている8つのポイントとの対応を明確にしてみたい。

  1. LLMベースの脆弱性発見・修復能力を活用する
    「Mythosレディとは何か　～　機械速度の攻撃時代における組織生存の条件」（ここからは「第1回と表記」）で、AIエージェント資産の把握として部分的に言及。「Mythosレディとは何か（続編）　～　Mythosレディにゼロトラストが有効な理由」（ここからは「第2回」と表記）では未扱い。本ブログ（ここからは「第3回」と表記）のVulnOps/CTEMが主テーマとして詳述。
  2. リスク・メトリックスを更新する
    第1回でCVSSではなく実際の悪用可能性で判断する考え方を言及。第3回でEPSS・リスクベーストリアージとして言及。
  3. コーディングエージェントの活用でチームを加速させる
    第3回でAIエージェントのVulnOps組み込みとして部分的に言及。
  4. より多くのインシデントへの対応を準備する
    第1回でセグメンテーション・egress等を言及。第2回でZTA・フィッシング耐性MFA・egress・セグメンテーションを詳述。第3回でゼロトラストポリシーとの連動として言及。
  5. 基本の強化に注力する
    第1回で基本強化の5領域（資産管理・セグメンテーション・パッチ管理・IAM・多層防御）として詳述。第2回で第1層として言及。第3回で第1層への還流として言及。
  6. 機械並みのスピードで迫る脅威には、人手だけでは太刀打ちできない。優先順位を見直し、業務を自動化し、バーンアウトに備える
    第1回・第2回・第3回すべてで未扱い。下記で補足。
  7. Mythosレディなセキュリティプログラムへ進化する
    第1回でMythosレディの定義・構造的リスクとして詳述。
  8. 今すぐ業界横断的な共同防御（Collective Defense）を構築する
    第1回・第2回・第3回では未扱い。集団防衛は下記で補足。

3つのブログでカバーできていない2つのポイントについて、以下に補足する。

バーンアウト対策

Mythos時代における脆弱性の爆発的増加は、セキュリティチームの作業量を構造的に増大させる。パッチ対応、インシデント対応、VulnOpsの継続運営が同時に求められる中で、既存の人員体制では限界が来る。本ブログで説明してきたAIエージェントによる自動化は、この問題への現実的な答えの一つである。ただし自動化整備には時間がかかる。その移行期間中、人間のチームが過負荷に陥らないための予備キャパシティと、チームのメンタルヘルスへの配慮が経営課題として浮上する。CISOはセキュリティの技術的課題と同時に、チームの持続可能性を考える必要がある。

業界横断的な共同防御

VulnOpsとCTEMは一組織内で閉じた取り組みとして機能するが、Mythosクラスの攻撃は産業横断的に同時多発する可能性がある。一組織が発見した脆弱性情報、攻撃パターン、修復知見を業界全体で共有することが、集団としての防御力を高めていく。JPCERT/CCや各業界のISACがこの役割を担っている。自組織のVulnOpsで得た知見をこれらの機関に積極的に共有し、逆に業界の脅威インテリジェンスをVulnOpsのトリアージに取り込むことが、Mythosレディを社会的に強化する道筋となる。

まとめ

VulnOpsとCTEMは「導入完了」という状態が存在しない。継続的に回し続けることが目的であり、回し始めることが成果である。「守るべき資産を一つ特定し、スキャンし、優先度をつけ、修復し、検証する」というような小さなサイクルを組織の習慣として定着させることがMythosレディへの道筋と考える。

これで、「Mythosレディとは何か」のブログシリーズ（3回連載）を終了する。次のブログでは、CSAがRSAC 2026で発表したCSAI Foundationが2026年のミッションとして掲げている「Securing the Agentic Control Plane」について考察する予定である。AIのリスクはLLMモデル自体の安全性にとどまらず、エージェントがシステムに接続し、ツールを実行し、他のエージェントと連携する複雑なエコシステム全体——identity・authorization・orchestration・runtime behavior・trust assurance——へと拡大している。CSAIはこの領域を6つの戦略プログラム（AI Risk Observatory・Agentic Best Practices・Education & Credentialing・CxOtrust・Global Assurance・Future Forward）で包括的に取り組んでいる。次回はこの枠組みについて考えてみたい。（出典：https://csai.foundation/csai-mission）

以上

Mythosレディとは何か（続編）　～　Mythosレディにゼロトラストが有効な理由

コメントをどうぞ

2026年6月3日
AIWGメンバー　諸角昌宏

本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のないご意見をいただければ幸いである。

はじめに：前回のおさらいと本ブログの位置づけ

前回のブログ「Mythosレディとは何か　～　機械速度の攻撃時代における組織生存の条件」では、機械速度の攻撃が常態化した世界において組織が生存できる状態を維持することの重要性について説明した。Mythosは「すごいハッキングツール」への対抗問題ではなく、AIが攻撃サイクル全体を自律実行できる時代における構造的リスクであることを認識することが重要である。

本ブログではその続編として「なぜゼロトラストがMythosレディに有効なのか」について考察する。ゼロトラストは2010年代から語られてきた概念だが、Mythosの登場によってその意義が根本的に変わってきたと言える。つまり、「機械速度の攻撃環境で生き残るためにゼロトラストが有効である」ということである。本ブログでは、従来型セキュリティはなぜMythos時代に機能しなくなるのか。そして「信頼しない・常に検証する」というゼロトラストの原則がなぜ機械速度の攻撃に対して構造的に有効なのかを考えてみる。　

１．なぜゼロトラストがMythosレディに有効なのか

ゼロトラストとは「Never Trust, Always Verify（何も信頼せず、常に検証する）」という設計思想であり、製品でも特定技術でもない。その必要性はMythos以前から指摘されてきたが、Mythosが変えたのは「ゼロトラスト未導入組織が直面するリスクの速度・規模・緊急性」である。Mythosが加えたのは「ゼロトラストを導入していない組織のリスクが機械速度で顕在化する」という緊急性である。Mythosはゼロトラストを「いつかやるべきもの」から「今すぐでないと間に合わないもの」に変えたと言える。

以下、代表的な5つの理由でゼロトラストの各要素がMythos時代に持つ意義を考える。

①横展開（lateral movement）を構造的に阻止する

AIによる自律的な攻撃の実例が示すように、Mythosクラスの能力を持つAIによる攻撃は一点の侵入後に社内を自律的に横展開する。従来の境界防御では、境界を突破した攻撃者は社内を自由に動き回れることになる。

ゼロトラストはマイクロセグメンテーションによって、攻撃チェーンの各ステップで認証・認可が必要になるため、AIが自律的に横展開しようとするたびに阻まれることになる。

②最小権限が攻撃チェーンを分断する

「AI脆弱性の嵐」の「CISOが押さえるべき重要ポイント」において、「セグメンテーション、egressフィルタリング、ゼロトラスト・アーキテクチャ、フィッシング耐性のある多要素認証、シークレットのローテーションといった緩和コントロールを検証・有効化しエクスプロイトが発生した場合の影響を最小化する」と明示している。最小権限はこの「影響を最小化」を実現する最も直接的な手段である。以下、その理由についていくつか挙げる。

  • エージェント、ユーザー、サービスアカウントすべてに最小権限を適用する
  • Just-in-Time（JIT）アクセス：　必要な時だけ、必要な期間だけ権限を付与する
  • 過剰権限の定期棚卸し：　誰も使っていない権限を排除する
  • AIエージェント自体にも最小権限を適用する（次世代の課題：AIエージェントが組織全体に普及するにつれ、エージェント自体に付与する権限の管理がAgentic Control Planeの核心課題となると考える）

③継続的検証が「見えていない攻撃」を早期発見する

「AI脆弱性の嵐」のリスクレジスターはリスク#4として「AIが複雑な攻撃を構築するために必要な洗練度と時間が短縮されており、防御側の検知・対応能力はまだこれに追いついていない」と指摘している。また優先アクションPA9・PA10では行動監視・デセプション技術・自動化された対応能力の整備を求めている。

ゼロトラストの「継続的検証」は、ユーザーが一度認証すれば後は信頼されるというのではなく、行動・デバイス状態・アクセスパターンを常時監視・評価し続けることを求めている。これにより以下のようなことが可能になる可能性がある：

  • 認証情報が盗まれても、「いつもと違う行動」を検知できる
  • AIが自律的に異常な頻度でアクセスすれば、行動異常として検出される
  • AIが自律的に生み出す「人間の操作では考えられない速度・頻度のリクエストパターン」が早期に検知できる

④egressフィルタリングとの相乗効果

「AI脆弱性の嵐」の優先アクションPA8は「egressフィルタリングを実装すること（log4jの公開エクスプロイトをすべてブロックした実績がある）」と明示している。

多くの組織ではファイアウォールのinbound制御に注力する一方、outbound（内→外）の通信はデフォルトで広く許可されていることが多い。egressフィルタリングはこのoutboundを厳格に制御する対策であり、ゼロトラストと組み合わせることで相乗効果を発揮する。それは、Mythosクラスの能力を持つAIが生成した攻撃コードがC2サーバーに通信しようとする際、egressフィルタリングがこれをブロックすることが可能になる。

⑤フィッシング耐性MFAで認証情報窃取を無効化する

「AI脆弱性の嵐」の「CISOが押さえるべき重要ポイント」において、緩和コントロールとして「フィッシング耐性MFA」を明示し、PA8では「すべての特権アカウントにフィッシング耐性MFAを義務化する」としている。従来のSMS認証などはリアルタイムフィッシングで突破される可能性があるが、FIDO2/パスキーはフィッシングページに誘導されても認証情報を盗めない設計になる。

ゼロトラストは「常に検証する」原則として強力な認証を求めている。「AI脆弱性の嵐」はその実装としてフィッシング耐性MFAを推奨しており、FIDO2/パスキーはその代表例となる。

２．ゼロトラストはMythosレディの「時間を稼ぐ」戦略である

ゼロトラストはすべての攻撃を防ぐ魔法ではない。しかし「時間を稼ぐ」という観点でMythosレディに本質的に有効であると考える。

以前のブログ「ゼロトラストとCIA(後編）　～　情報セキュリティはコントロール可能にすること」で、情報セキュリティの目的は「コントロール可能にすること」とした。攻撃を100%防ぐことは不可能だが、影響を封じ込め、迅速に回復し、次の攻撃に備えられる状態を維持することを目的とすべきと考える。ゼロトラストはまさにこの「コントロール可能な状態」を実現するアーキテクチャである。

それでは、発見から武器化まで数時間のMythos時代において、ゼロトラストが「時間を稼ぐ」とはどういう意味となるのか。

この「時間を稼ぐ」ことの意味について以下のように考える：

  • 侵入から被害拡大までの時間を延ばす（マイクロセグメンテーションによる横展開阻止）
  • 被害範囲を小さく封じ込める（最小権限による爆発半径の制限）
  • 「見えていない攻撃」を早期に検知する（継続的検証による異常検出）
  • 人間が対応できる時間を確保する（機械速度の攻撃に対して「止める機会」を作る）

それでは、「時間を稼ぐ」ことがなぜ重要なのであろうか。Mythosレディは一夜にして完成するものではない。今すぐゼロトラストを導入することで、次の波・より高度な攻撃が来るまでの間に、VulnOpsやAgentic Control Planeの体制を整える時間を確保していくことを考えるべきと考える。

３．NSTACの5つのステップで実装するゼロトラスト

以下では、NSTACゼロトラスト・フレームワークに基づいて、この5ステップそれぞれがMythosクラスの能力を持つAIの攻撃チェーンのどの段階に対応するかを整理してみる。

ステップ本来の目的Mythostとしての意味
① プロテクトサーフェスの定義守るべき対象（DAAS）の特定と、そのプロテクトサーフェスの設定Mythosクラスの能力を持つAIによる攻撃が狙う認証情報、高価値DB、内部APIの棚卸し。
② トランザクションフローの把握データ・通信の流れを可視化AIエージェントがどのMCPサーバー、APIに接続しているかのマッピングに適用。
③ ゼロトラストアーキテクチャの設計プロテクトサーフェスにコントロールを配置マイクロセグメンテーション、最小権限、egressフィルタリングを組み合わせる。
④ ゼロトラストポリシーの策定５W1Hに基づいて、アクセスするかをポリシーに明記。人間向けのアクセスポリシーに対して、AIエージェントにも同じ枠組みが必要になる。エージェントID、許可するツールなどの要否を明記する。
⑤ 監視と維持テレメトリーの継続収集と改善フィードバック発見された脆弱性を即座にプロテクトサーフェスの定義とポリシーに反映する。「Long-term＝1四半期」でサイクルを回す。

なお、5ステップは一度やれば完了するものではなく、プロテクトサーフェスを定義・実装するたびに①から繰り返す。この反復のたびに組織のゼロトラスト成熟度は少しずつ上がっていく。最初から完璧なゼロトラスト環境を目指すのではなく、「守るべき資産を特定し、そこにゼロトラストを適用し、監視する」という小さなサイクルを回し続けることが、現実的な道筋である。

4．おわりに：ゼロトラストは手段であり、目的はコントロール可能な状態

ゼロトラストがMythosレディへの「解答」ではないが、「機械速度の攻撃時代に組織が生存できる状態を維持する」ための最も重要な構造的基盤の一つであると考える。

ゼロトラストの前にある「基本的なセキュリティ対策」という土台

ここで重要な視点を加えたい。ゼロトラストは「基本的なセキュリティ対策」の上に成り立つものであって、代替するものではない。「AI脆弱性の嵐」が「基本に立ち返り、環境をさらに強化する」をCRITICALな優先アクションとしている理由がここにある。

そこで、以下の３層をMythosレディへの道として定義したい：

  1. 第1層：基本的なセキュリティ対策
    資産管理、パッチ適用、ログ収集、バックアップ、インシデント対応手順など。第2層・第3層を育てながら、並行して継続的に強化する土台。
  2. 第2層：ゼロトラスト
    プロテクトサーフェスを定義するたびに少しずつ育てる。完成を待たずに第3層と並行して進める。
  3. 第3層：VulnOps、Agentic Control Plane
    第2層の成熟を待たずに着手できる部分から始める。

これらの3層が互いの成熟を促し合うプロセスとなる。3層は相互に依存し、第1層のログ基盤が第2層の継続的検証を強化し、第2層のプロテクトサーフェスの定義が第3層のVulnOpsの優先順位を決めていくことになる。また、第3層で発見された脆弱性が第1層のパッチ適用と第2層のポリシー更新に反映される。この循環がMythosレディに導いていくと考えられる。

3層が揃って初めてMythosレディになる

上記の３層は順番に行っていくものではない。3層を順番に完成させようとすると、「ゼロトラストが完成してからVulnOpsを始める」とか「基本対策が完璧になったらゼロトラストを導入する」となるが、そうではない。3層を同時に育てること、つまり、小さなプロテクトサーフェスから始め、ゼロトラストとVulnOpsを並行して育てるというような、基本対策の改善とゼロトラスト導入を同時進行させることで、各層が少しずつ成熟するたびにリスクが下がっていくことになる。これにより、Mythosレディへ着実に近づいていくことができると考える。つまり、基本的なセキュリティ対策（資産管理、パッチ、ログ、バックアップ、インシデント対応など）という土台の上に、ゼロトラストというアーキテクチャを重ね、さらにVulnOps、Agentic Control Planeへと発展させるという3層の積み重ねが「Mythosレディ」を実現するための重要なステップであると考える。

次回のブログでは「VulnOpsとCTEM：継続的脆弱性管理の具体的な実装」を取り上げる予定である。ゼロトラストで攻撃者の難易度を上げながら、VulnOpsで脆弱性を先に発見・修復するという両輪が、Mythosレディの中核を形成するものと考える。

以上

Mythosレディとは何か　～　機械速度の攻撃時代における組織生存の条件

1件のフィードバック

2026年5月26日
AIWGメンバー　諸角昌宏

本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のないご意見をいただければ幸いである。

はじめに

2026年4月7日、AnthropicがClaude Mythos Previewを公式発表した（出典：red.anthropic.com）。このモデルは汎用LLMであり、セキュリティ専用ツールとして設計されたわけではないが、コーディングと推論能力の向上から「自然に発生した」として際立ったセキュリティ能力を示した。代表的な成果として、Firefox 147 JavaScriptエンジンを対象とした特定のテストハーネスで181件の動作するexploitを生成した（同条件でClaude Opus 4.6は2件）。また約1,000回の試行・約2万ドルの計算コストをかけたキャンペーンで、27年間専門家の審査・ファジング・自動スキャンをくぐり抜けてきたOpenBSDのTCP SACK実装の脆弱性（DoS）を発見した。

「AI脆弱性の嵐」（CSA/SANS/OWASP/[un]prompted 緊急戦略ブリーフィング）
Mythosの発表から6日後の2026年4月13日、CSA, SANS, OWASP, [un]promptedの共同により「AI脆弱性の嵐（AI Vulnerability Storm）：Mythosレディなセキュリティプログラムの構築」が緊急公開された（現在v1.0、日本語版はV0.4）。60名以上の寄稿者・250名以上のCISOがレビューしたこの文書は、Mythosの登場を「最初の波に過ぎない」と位置づけ、CISOがすぐに実行できる具体的な行動指針を提示している。CSAジャパンでは、2026年5月25日にWGセミナーを行い、この文書の内容、CSAI foundationのミッション等について参加者とディスカッションを行った。

本ブログはこの文書の内容およびWGセミナー（2026年5月25日）でのディスカッションに基づいている（注：WGセミナーの資料およびビデオ録画はこちらの「WGセミナー：ビデオ録画、資料」のウエブページより参照）。

「AI脆弱性の嵐」の文書が明確にしている点は、Mythosの登場で生じた「AI脆弱性の嵐」は単一モデルへの対応問題ではないということである。AIが脆弱性発見のコストとスキルの敷居を、組織がパッチを適用できる速度よりも速く引き下げており、発見から武器化までの時間が数時間レベルに短縮されるという構造的な変化である。従来のパッチサイクル・対応プロセス・リスク指標はこのような環境を前提として設計されていない。

したがって、Mythosの登場が示したのは、「Mythosというすごいツールにどう対抗するか」ではなく、AIが攻撃サイクル全体を自律実行できる時代の到来という構造的な転換点である。この転換は、セキュリティの問題を超え、事業継続・安全工学・オペレーションレジリエンス・危機管理にまたがる社会システム全体の設計問題を提起している。

１．Mythosレディとは何か：ツール対抗ではなく構造的リスクへの認識

「Mythosレディ」という概念は、しばしば誤解されている。それは「Mythosというすごいハッキングツールに対抗する体制を整える」ということではない。つまり、脅威論として捉えるべきではない。Mythosレディとは、機械速度の攻撃が常態化した世界において、組織が生存できる状態を継続的に維持することである。重要なのは「Mythos」という特定のモデルへの対応ではなく、その背後にある構造的リスクを認識することである。防御と攻撃が同じ能力空間に存在し、高度なコード理解能力は、自然に攻撃構造理解へと接近する。これは特定ベンダーの問題ではなく、技術進化の構造的必然であるといえる。

「Mythosレディ」は以下の例のように考えられる。

Mythosレディではない状態Mythosレディな状態
四半期ペネトテストを実施している継続的・自動化されたスキャン
CVSSスコアでパッチ優先度を決めている自環境での実際の悪用可能性で判断
月次でセキュリティレポートを出しているリアルタイムのリスクダッシュボード
インシデント対応は人間チームが担当AIエージェントが初動・人間が監督

２．なぜ従来のセキュリティモデルは機能しなくなるのか：非対称性の構造

AIが攻撃サイクル全体を自律実行できる世界では、従来のセキュリティモデルは根本から機能しなくなる。その理由は「非対称性」にある。

機械速度 vs 人間速度の非対称性

攻撃側（AI）防御側（人間）
脆弱性発見 → exploit生成 → オペレーション実行を機械速度で自律完結検知→分析→対応→修復を人間速度で処理
発見から武器化まで：数時間（2026年）四半期ペンテスト・月次パッチサイクル
複数システムへの同時並行攻撃インシデントは1件ずつ対応（直列処理）
攻撃者は「一箇所突ければいい」防御側は「全部守らなければならない」

この非対称性は技術的なものだけではない。文化的・組織的な非対称性でもある。AIを活用しない防御チームは、技術スキルに関わらず、AI武装した攻撃者のスピードや規模に対抗することができなくなる。

つまり、「機械速度の攻撃に対しては機械速度の防御しか対抗できない」という現実を受け入れ、AIエージェントを例外的ツールではなく防御の基盤として制度化することが求められる。

３．これはサイバーセキュリティの課題を超えた社会システム設計の問題である

Mythosの影響は「サイバーセキュリティの問題」にとどまらない。人間の制御速度を超えた自律システムが存在する世界で、社会システム全体をどう設計・運営・管理するかという根本的な問いを提起している。

安全工学への影響

従来の安全工学は「障害は人間のミスか機械の故障」を前提とし、原因分析が可能で、設計段階でリスクを織り込めるという前提に基づいていた。 Mythosが崩す前提は「静的安全設計」である。昨日まで安全だったシステムが今日から危険になる。設計の思想は「壊れないように作る」から「壊されることを前提に設計する」へ転換しなければならない。

オペレーショナルレジリエンスへの影響

従来のBCP/DRは「障害からの復旧」を想定していたが、Mythos時代では復旧インフラ自体が攻撃対象になる。バックアップシステムの完全隔離、サプライチェーン全体でのレジリエンス評価が必須となる。

危機管理への影響

従来の危機管理は「発生を人間が認識できる」「対応に時間的猶予がある」を前提としていた。しかし複数の重大インシデントが同時発生し、発見した時には手遅れになっている可能性がある世界では、事前承認済みプレイブックとAIエージェントによる初動の自動化が不可欠となる。

これらの3つの領域に共通する点として、「人間の制御・認識・対応速度」を超えた自律システムが存在する世界で、社会システム全体をどう設計・運営・管理するかということであり、これに対する回答が「エージェンティックコントロールプレーン（Agentic Control Plane）のガバナンス」ということになる。

４．次の波に備える：Mythosは最初の波に過ぎない

Mythosの登場は「臨界点」として語られることが多いが、より正確には「能力進化の連続性の中で社会が初めて広く認識した転換点」である。

現在の第一波の正確な姿は、脆弱性発見・エクスプロイト生成・攻撃チェーン構築・オペレーション実行が最小限の人間入力で自律的に完結している。現在のMythosはまだ「人間が介在できる機械速度・規模」にとどまっている。アクセスは限定されており、複雑な標的には人間の方向づけが一部残る。しかし次の波では状況が変わる。

次の波のシナリオ

  • 第二波：自律エージェントによる継続・横展開・長期運用の完全自動化
  • 第三波：Mythos級能力の民主化（誰でも使える状態への拡散）
  • 第四波：電力・医療・金融・水道等の社会インフラへの攻撃

英国AISIの独立評価（2026年5月）では、GPT-5.5とMythosは同一ベンチマーク上のスコアが誤差の範囲内で収束していることが確認された（GPT-5.5：71.4%、Mythos：68.6%）。ただし能力の質・アライメント・セーフガードの強度は異なる。より重要なのは、フロンティアサイバー能力が単一ベンダーに限定されなくなったという構造的収束であり、「Mythosだけを管理すれば良い」という発想は、すでに現実から離れつつある。 だからこそ、「Mythos対応」という短期的・特定モデル対応の発想ではなく、「次の波・その次の波が来ることを前提とした継続的適応体制の構築」という長期的・構造的な視点が必要である。ただし、長期的という行動のために利用可能な時間は縮小している。戦略計画の最長単位は「1四半期」と考えるべきである。ロードマップは四半期単位で継続的に更新される設計でなければならない。

５．今すぐ始めること：基本の強化とコントロール可能な状態の実現

「機械速度の攻撃が来る前に、今できることをやる」。これがMythosレディへの最も重要な第一歩である。

情報セキュリティの目的：コントロール可能にすること

先のブログ「ゼロトラストとCIA(後編）　～　情報セキュリティはコントロール可能にすること」では、セキュリティの本質的な目的を「コントロール可能にすること」とした。攻撃を100%防ぐことは不可能だが、影響を封じ込め、迅速に回復し、次の攻撃に備えられる状態を維持することはできる。 この「コントロール可能な状態」を実現するための基盤が、まず基本的なセキュリティの強化である。高度な攻撃への対策より、基本の穴を塞ぐことが先決である。攻撃者は最も弱い点を狙う。

今すぐ取り組む基本強化の5領域

1.　資産管理：守るべき対象を把握していない状態で対策はできない

  • ITインベントリ：サーバー・PC・クラウドインスタンスの継続的把握
  • SBOM：使用しているOSSライブラリ・依存関係の管理
  • シャドウIT・未管理資産の自動発見：攻撃者が最も狙う「見えていない穴」
  • AIエージェント資産の把握：動作中エージェント・権限・MCPサーバーの新カテゴリ

2.　ネットワークセグメンテーション

  • 内部ネットワークを機能・リスク別に分離し、横展開（lateral movement）を遮断する
  • Mythos時代：攻撃チェーンの連鎖を物理的に切断する最も効果的な手段

3.　パッチ管理の継続化

  • KEV（既知悪用脆弱性）リストの優先的・継続的対応：CVSSスコアではなく実際の悪用リスクで判断
  • クリティカルパッチは24時間以内の適用を目標とする
  • パッチdiff分析：パッチ公開が即座にexploit設計図になる逆説を認識する

4.　アイデンティティとアクセス管理（IAM）

  • 最小権限の原則の徹底：必要最低限のアクセスのみ付与・過剰権限の定期棚卸し
  • AIエージェント自体への最小権限適用：エージェントの過剰権限が攻撃のリスクになる
  • フィッシング耐性MFA（FIDO2等）の全社的展開

5.　多層防御の再設計

  • 単一コントロールへの依存を排除：1つの防御が破られても次の層が機能する設計
  • egressフィルタリング：不審な外部通信の自動遮断
  • 継続的モニタリング：「見えていない攻撃」を検知する仕組みの整備

時間的余裕がある今のうちにこれらの取り組みを拡大していくことが必要である。Mythos能力の民主化が進む前に基盤を固めることが、組織が生存できる状態を維持するための最優先事項である。

おわりに：Mythosレディは到達点ではなく継続的な状態である

Mythosレディとは、特定の脅威に対応した状態のことではない。機械速度の脅威環境に継続的に適応し続けられる組織状態のことである。 「Mythosレディ」セキュリティプログラムの構築は、1つのモデルや発表に反応することではない。脆弱性が発見される速度と組織が対応できる速度のギャップを恒久的に埋めることである。

Mythosの影響を「サイバーセキュリティの問題」として矮小化してはならない。それは「人間の制御速度を超えた自律システムが存在する世界で、社会システム全体をどう設計・運営・管理するか」という問いであり、セキュリティ担当者だけではなく、経営層・取締役会・社会全体が向き合うべき課題である。 そして、その答えの第一歩は「今すぐ基本を強化し、コントロール可能な状態を実現すること」にある。

補足：CSAIのスタンスとミッション：制度として応答する

CSAは、AIセキュリティ・セーフティに特化した新しい非営利財団「CSAI Foundation」を正式に設立した。そのミッションは以下である。

「エージェンティックコントロールプレーン（Agentic Control Plane）をセキュアにする）」——自律型AIエージェントエコシステムを支えるアイデンティティ・認可・オーケストレーション・ランタイム動作・トラスト保証の層を統治すること。

CSAIのスタンスは明確である。Mythosを「危険なAIの登場」として警戒するのではなく、「エージェントAIが自律的に動く世界において、その制御・監視・信頼の仕組みを社会基盤として確立する」という建設的・制度的に答えることである。

CSAIの6つの戦略プログラム

  • AIリスクオブザーバトリー：MCPサーバーエコシステムの継続監視・CVE番号機関（CNA）として認定・RiskRubricによるリスクスコアリング
  • エージェンティックベストプラクティス：セキュアなエージェント実装のフルライフサイクルガイダンス・非人間アクターのID管理・権限ガバナンス
  • 教育＆資格認定：TAISE Agentic（実務者向け）・TAISE CxO（経営幹部向け）・将来的にはエージェント自体を認定するTAISE-Agent
  • CxOトラストCレベルリソース：経営層・取締役会がAIリスクを経営判断に変換するための支援
  • グローバルアシュアランス＆トラスト：NIST AI RMF・EU AI Act・ISO/IEC 42001との整合。STAR for AI Catastrophic Risk Annexによる最悪シナリオの監査可能化
  • フューチャーフォワード：既存標準のAIギャップ評価・統合リサーチの開発・CVE/MITRE/OWASPとの連携

以上

ゼロトラストとCIA(後編）　～　情報セキュリティはコントロール可能にすること　

1件のフィードバック

2026年5月21日
ゼロトラストWGリーダー　諸角昌宏

本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のないご意見をいただければ幸いである。

「情報セキュリティとはCIAを維持すること」という定義は40年以上にわたり使われてきた。しかしCIAを詳細に理解するほど、一つの問いが浮かび上がる。CIAを「維持すること」は情報セキュリティの目的として本当に正しいのか。本ブログでは、ブログ「ゼロトラストとCIA」の後編として、この問いをより突っ込んで考察した。結論から言うと、情報セキュリティの本来の目的は「コントロール可能にすること」にあるのではないかということに至った。

はじめに：ブログ「ゼロトラストとCIA」からの問い

ブログ「ゼロトラストとCIA」では、CIAとは何か・なぜ3つなのか・CIAは万能かという3点を考察した。その中で以下の一つの重要な事実を示した。それは、「CIAを維持すること」は必要条件であるが、そもそも情報セキュリティに「十分条件」は存在しない。脅威は常に進化し、守る対象も変化し続けるためである。では、CIAとは情報セキュリティにおいて何なのか。「定義」なのか「評価軸」なのか「目的」なのか。この問いに答えることが本ブログの目的である。結論から先に示すと以下の表のようになると考える：

概念位置づけ何を問うているか
CIA（機密性・完全性・可用性）評価軸情報の状態がどうあるべきか
CIAを維持すること手段評価軸上の状態をどう保つか
コントロール可能にすること目的情報セキュリティは何のためにあるか
NIST CSF（Identify・Protect・Detect・Respond・Recover・Govern） ＊ISO/IEC 27002:2022もコントロール属性として採用プロセスの体系（何をするか）組織はセキュリティのために何をすべきか

第1章　ブログ「ゼロトラストとCIA」の要点確認

ブログ「ゼロトラストとCIA」で確認した要点を本ブログの出発点として以下に整理する。

要点内容
CIAとは何か機密性（C）・完全性（I）・可用性（A）の3要素。情報はそれ自体として価値を持ち、CIAはその価値が損なわれないための条件を3つの独立した評価軸で整理したもの
なぜ3つなのか情報への被害は「漏えい・改ざん・利用不能」の3種類に整理できる。攻撃者が情報システムに対してできることは「見る・変える・使えなくする」の3つに集約されるため、この3軸で被害の分類と対策の方向性が明確になる
CIAの歴史的位置づけ1972年のAnderson Reportに起源を持ち、1986年頃「CIA」という略語が命名された。設計当初は「安全なシステムの評価軸」として提示されており、「情報セキュリティの目的」として設計されたものではない。「CIAを維持すること＝情報セキュリティ」という定義は後の標準化・教育化の過程で形成された
CIAは万能か必要条件だが十分条件にはなりえない。情報セキュリティに「十分条件」は存在しない。ISO/IEC 27000:2018はAuthenticity・Accountability・Non-repudiation・Reliabilityを追加し、NIST CSFはResilience・Governanceを体系化してCIAを補完している

これらの要点を踏まえた上で、本ブログでは「CIAを維持すること」という定義そのものを問い直し、情報セキュリティの本来の目的を考察する。

第2章　「CIAを維持すること」を問い直す

2.1　「維持すること」という動詞に潜む前提

「CIAを維持すること」という定義には「維持」という動詞に複数の前提が含まれている。これらの前提が現代では成立しにくくなっているといえるのではないだろうか。

「維持」が前提とすること現代の現実
守るべき状態が明確に定義できるAI・クラウド・OTの複合環境では守るべき境界が流動的。シャドーIT・SaaSが資産範囲を継続的に変化させる
状態への到達が確認できる侵害の検知自体が困難。侵害後の滞留時間は依然として長い
責任の境界が明確であるクラウド責任共有モデル・サプライチェーンの多層化で責任が分散・曖昧化している

2.2　CIAを維持していても攻撃にさらされる

「CIAを維持している企業がなぜサイバー攻撃にさらされるのか」という問いは、「CIAを維持すること」という目的設定の根本的な問題を示しているのではないだろうか。

理由CIAが問うこと実際に起きること
CIAは結果の評価軸であり攻撃への対応設計ではない現在この情報は漏れていないか・改ざんされていないか・使えるか（現状評価）攻撃者は、どこから侵入できるか・どう横展開するか、という攻撃設計を考えている
CIA評価の時点と攻撃の時点がずれるリスクアセスメントは定期的。評価時点での評価。攻撃者は継続的・動的に動く。侵害後の滞留時間は長い。
攻撃者は「正規に見せる」手法を使う不正なアクセス・改ざん・停止を評価する認証情報の窃取はC侵害で捕捉できるが、盗んだ認証情報でなりすましてアクセスする段階ではCIAのアクセス制御をすり抜ける（Authenticity問題）

「CIAを維持していること」は必要条件であるが、そもそも情報セキュリティに十分条件は存在しない。CIAの設計範囲外の問いに対してCIAで答えようとしてきたことが、この矛盾を生んでいると言える。

2.3　CIAは「状態の評価軸」であり「目的」ではない

ここで重要な概念的区別を確認してみる。CIAが「情報の状態を評価する軸」であることと、「情報セキュリティの目的」であることは異なる。

観点CIAとして正確な記述誤った記述
概念の性格情報の属性（C・I・Aの状態）を評価する軸情報セキュリティの目的そのもの
問いの構造この情報は機密性・完全性・可用性を満たしているか?情報を守るために何をするか
侵害後の設計評価軸の設計範囲外（Resilienceが扱う）「維持」という概念に含まれるかのように扱われる

第3章　情報セキュリティは何をすることか

3.1　3つの定義の層

情報セキュリティの定義は時代とともに進化してきた。3つの層として整理できる。

定義の層内容限界
古典的定義 （CIAベース）情報の機密性・完全性・可用性を維持すること静的・状態記述的。「維持」の前提が現代では成立しにくい。侵害後の回復・Authenticity・Privacyなどを扱えない
拡張定義 （ISO 27000:2018 ＋NIST CSFベース）CIA＋Authenticity・Accountability・Non-repudiation・Reliability：ISO/IEC 27000:2018。

Identify・Protect・Detect・Respond・Recover：NIST CSF 1.0（2014年）が体系化。ISO/IEC 27002:2022もコントロール属性として採用

Govern：NIST CSF 2.0が追加		より網羅的。NIST CSFはプロセス（何をするか）を体系化した点でISOの状態記述を補完するが、「コントロール可能にすること」という目的は明示していない
現代的定義 （本ブログの考察）情報・情報システム・それを取り巻く人・組織・社会に対して生じうるあらゆる事象を、把握し・対処し・回復し・説明できる状態を継続的に保ち続けること確定した定説ではない

3.2　情報セキュリティの本来の目的：コントロール可能にすること

CIAの歴史的形成過程・各フレームワークの方向・拡張概念の性質を考察すると、情報セキュリティの本来の目的は「CIAという状態の維持」ではなく「コントロール可能にすること」にあったのではないかと考える。つまり、情報セキュリティの目的 　＝　「コントロール可能にすること」 ── 何が起きても、把握し・対処し・戻れる状態を保ち続けること。

この定義はCIAを否定していない。CIAはコントロール可能性を評価するために有効であり続ける。ただしCIAの維持それ自体は目的ではなく、コントロール可能性という目的を達成するための評価軸として考えるのが良いと思われる。

観点「CIAを維持すること」「コントロール可能にすること」
構造C・I・Aを満たしているかいかなる事象が起きても対処できる状態にある
時間軸現在の状態の評価過去・現在・未来にわたる継続的な能力
侵害後評価軸の設計範囲外回復・説明・再発防止を含む
一般への伝わり方技術的概念として受け取られやすい「コントロールできているか」は経営判断・日常感覚に近い
関係評価軸目的

3.2b　具体的に何をすればよいか

「コントロール可能にすること」は5つの能力として具体化できる。これらの能力を継続的に維持・向上させることが、情報セキュリティの実践であると考える。

能力意味具体的な実践例関連するCIA・拡張概念
把握する （Visibility）何が起きているかを見えるようにする。資産・通信・ユーザー行動・脅威を可視化する資産台帳の整備（何があるか知る）
ログ収集、SIEM
継続的な脆弱性スキャン、ネットワーク通信の監視		C（誰がアクセスしているか） I（何が変更されたか） Accountability（誰が何をしたか）
対処する （Control）侵害の影響を制限・封じ込める。攻撃者が自由に動ける範囲を最小化するアクセス制御、最小権限の原則
ネットワーク分割（マイクロセグメンテーション）
ゼロトラストの実装（常に検証・最小権限）
エンドポイント保護（EDR）		C（許可された人だけがアクセスできるか） Authenticity（本当に正規ユーザーか）
戻れる （Resilience）侵害後に資産と業務を回復できる設計をする。「防げなかった後」を前提に組み込むバックアップ、オフライン保管（3-2-1ルール）
RTO/RPOの設定と定期的な復旧訓練
インシデント対応手順（IRP）の整備
Assume Breachの設計思想を取り込む		A（使えない状態からの回復） Resilience（NIST CSF Recover機能）
説明できる （Accountability）何が・なぜ起きたかを後から証明できる。監査・法的対応・再発防止に不可欠監査ログの保全（改ざん不可の形で）
インシデント記録、タイムライン整備
デジタルフォレンジックの準備
Non-repudiation（電子署名・タイムスタンプ）		Accountability、Non-repudiation
適応できる （Adaptability）新たな脅威・技術・法令の変化に継続的に対応できる。「現時点で完璧」は存在しない継続的なリスクアセスメント（年1回から常時評価へ）
脅威インテリジェンスの活用
PDCAの仕組みの整備
NIST CSF Govern機能による経営層の関与		NIST CSF Govern機能 継続的改善（ISO/IEC 27001 PDCAサイクル）

これら5つの能力は独立しているのではなく相互に支え合っている。「把握する」なしに「対処する」はできない。「戻れる」設計なしに「Assume Breach」は実現しない。「説明できる」なしに再発防止はできない。5つを一体として継続的に維持・向上させることが「コントロール可能にすること」の実践である。

3.3　先行研究は？

「コントロール可能性」を情報セキュリティの目的として明示的に定義した文献について調べてみた。この方向性を示唆する先行研究が以下のように見つかった。

文献主張していること本考察との関係
Lundgren & Möller (2019) “Defining Information Security” Science and Engineering Ethics, 25(2): 419-441 Division of Philosophy, Royal Institute of Technology (KTH)CIAは定義として「広すぎかつ狭すぎる（too broad and too narrow）」と論証。またCIAを「目標（goals）」とみなす立場も「CIAの特性は必要条件ですらないため目標としても機能しない」と退けている。代替定義として「Appropriate Access（適切なアクセス）」を提案している。CIAを目的から評価軸へ変更させる先行的根拠を与えていると考える
Yin et al. (2020) “Hierarchically defining IoT security: From CIA to CACA” International Journal of Distributed Sensor NetworksCACA（Confidentiality・Availability・Controllability・Authentication）を提案。CIAにControllabilityを加えた点が本ブログの考察との接点。なおYin et al.はIntegrityをAuthenticationに置き換えているが、特に言及しない。「Controllability」を情報セキュリティの定義に明示的に組み込んだ最も直接的な先行文献である。ただしCIAの代替特性として提案しており本ブログの上位目的概念とは異なっている。
NIST CSF 2.0（2024年）Identify・Protect・Detect・Respond・RecoverはNIST CSF 1.0（2014年）が体系化した。ISO/IEC 27002:2022も同5概念をコントロール属性として採用している。GoverはNIST CSF 2.0（2024年）で追加されている。2014年版（CSF 1.0）でRecover機能を独立した柱として体系化。2024年版（CSF 2.0）でGovern機能を追加しサプライチェーンセキュリティも強調。「侵害後に回復できるか」と「ガバナンス（誰が責任を持つか）」をセキュリティの核心に置いている。コントロール可能性という目的概念に最も近接したフレームワークと言える。

第4章　コントロール可能にすることとゼロトラスト

4.1　ゼロトラストはCIAを否定するか

ゼロトラストはCIAという評価軸を否定しない。ゼロトラストはネットワーク上の境界防御モデルを置き換えるにとどまらず、アイデンティティ・デバイス・アプリケーション・データを含むすべてのアクセスに「常に検証・最小権限・侵害前提（Assume Breach）」という原則を適用する広い設計思想である。CIAはゼロトラスト下でも有効な評価軸として機能し続ける。

観点ネットワーク境界防御モデル（従来の主流実装）ゼロトラスト（新しい実装）CIAトライアド（評価軸）
信頼の前提内部ネットワークは信頼する内部・外部を問わず信頼しない内部・外部という概念を持たない
侵害への取り組み侵害を防ぐことを前提とする侵害を前提として設計する（Assume Breach）CIAは侵害前提を否定していない
アクセス制御境界で一括制御セッション単位で動的に検証アクセスのC（誰に）を問う（動的・静的を問わない）
置き換え関係ゼロトラストに置き換えられるアイデンティティ・デバイス・アプリ・データ全体に「常に検証」を適用するどちらの実装モデル下でも有効

4.2　3層構造で整理する

CIAとゼロトラストの関係が混乱する根本原因は、「目的・評価軸・実装」という異なる層に属する概念が混同されてきたことにあると考える。これは、3層に整理すると関係が明確になる。

層概念問い役割
目的層コントロール可能にすることなぜ守るのか何が起きても把握・対処・回復できる状態を保ち続けること
評価軸層CIA＋拡張概念 （Authenticity・Non-repudiation等）何を守るのか守るべき情報の属性を評価する
実装層ゼロトラストどう実現するのかコントロール可能性を達成するための設計原則・アーキテクチャ

この3層構造において：

  • ゼロトラストはCIAの「上位互換」でも「否定」でもない。実装層の概念であり、評価軸層のCIAとは層が異なる
  • CIAはゼロトラスト下でも評価軸として機能する。「このアクセスは機密性を守れているか」という問いはゼロトラスト環境でも有効
  • コントロール可能性はCIAもゼロトラストも包含する上位目的として機能する

4.3　3層構造の根拠

なぜこの3層で整理できるのか。以下の4つの根拠があると考える。

根拠内容
概念カテゴリの区別「何のために（目的）」「何を評価するか（評価軸）」「どう実現するか（実装）」は概念的に異なるカテゴリであり互いに還元できない。
混同が生んだ問題の実証CIAを「目的」として扱った結果「CIAが問題なし＝安全」という誤った等式が生まれた。
先行研究との整合Lundgren & Möller (2019) は「CIAは目標ではなく特性」と論証。NIST CSFはResilience・Governanceを体系化しコントロール可能性に最も近接。ISO/IEC 27000:2018はCIAの並列拡張で評価軸層の網羅を試みている。
エンジニアリングとの整合実装が変わっても（ネットワーク境界防御→ゼロトラスト）、評価軸（CIA）は維持され、目的（コントロール可能性）は不変であるという安定した構造が得られる

まとめ

情報セキュリティとは何をすることか

ブログ「ゼロトラストとCIA」からの問いを辿っていくと、以下の結論に至る。

  • CIAは情報セキュリティの「評価軸」として有効な基礎概念である。しかし「目的」ではない
  • 「CIAを維持すること」という定義は、評価軸を目的として扱ってきた歴史的経緯の産物である
  • 情報セキュリティに「十分条件」は存在しない。脅威は常に進化し、守る対象も変化し続ける
  • ゼロトラストはCIAという評価軸を否定しない。ゼロトラストはネットワーク境界防御モデルを起点に、すべてのアクセスに「常に検証・最小権限・侵害前提」を適用する広い設計思想である
  • CIAの歴史・各フレームワークの収束方向・拡張概念の性質を考察すると、情報セキュリティの本来の目的は「コントロール可能にすること」にあったのではないかと考えられる

以上の観点から、本ブログでは、「情報セキュリティとは、コントロール可能にすること」と結論づける。 すなわち、何が起きても、把握し・対処し・戻れる状態を保ち続けることが情報セキュリティの目的である。CIAはその目的を達成するための評価軸であり、ゼロトラストはその目的を実現するための設計思想である。この3層の関係を正しく理解することが、現代のセキュリティを議論する出発点となると考える。

以上

ゼロトラストとCIA（前編）

2件の返信

2026年5月15日
ゼロトラストWGリーダー　諸角昌宏

本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のない意見をいただければ幸いである。

ゼロトラストに色々と触れていくうちに、情報セキュリティの定義である「CIAを維持すること」がゼロトラストの考え方と本当に合っているのかという疑問が生じてきた。この疑問に答えるには、まずCIAという概念を正確に理解することから始める必要がある。本ブログはその出発点として、CIAとは何か、なぜ3つなのか、どこまで有効でどこから先は別の概念が必要なのかを整理してみる。その上で、本ブログの続編として、ゼロトラストとCIA、さらに、ゼロトラスト環境において情報セキュリティをどのように捉えるかを考察してみる。

CIAとは何か

CIAとは、情報セキュリティにおける3つの基本要素を示す概念である。まずこの3要素を正確に理解しておくことが重要である。

記号英語日本語一言で言うと
CConfidentiality機密性見せるべき人だけが見られる
IIntegrity完全性正確な内容が保たれている
AAvailability可用性必要なときに使える

情報システムは、この3要素が維持されることで安全かつ信頼可能とみなされる。ただし重要な前提がある。情報はそれ自体として価値を持つ。CIAはその価値が損なわれないための条件を3つの軸で整理したものであり、「CIAが整っていれば情報に価値が生まれる」のではなく、「CIAが損なわれると情報の価値が損なわれる」という関係にある。

機密性（Confidentiality）

機密性とは、許可された人だけが情報へアクセスできる状態を維持することを意味する。

代表的な対策：

  • 認証・多要素認証（MFA）
  • アクセス制御（IAM）
  • 暗号化（通信・保存データ）
  • 最小権限の原則（PoLP：Principle of Least Privilege）

機密性が失われると：

  • 情報漏えい・不正閲覧
  • 認証情報の窃取
  • 競合他社・攻撃者による悪用

機密性が問うのは「誰に見せるか」というアクセスの選択性である。ただし「正規のアクセス者が情報を目的外に使用する」という問題は機密性の範囲外である。この「目的外利用」を扱う概念は対象によって異なる。対象が個人データであればプライバシーが扱う（GDPRの「目的制限の原則」等）。対象が組織情報・営業秘密であれば守秘義務やAccountability（説明責任）が扱う。いずれの場合も、「アクセスを許可するかどうか」という機密性とは別軸の問題である。

完全性（Integrity）

完全性とは、情報やシステムが正確であり、意図せず改ざんされていない状態を維持することを意味する。

代表的な対策：

  • ハッシュ関数による改ざん検知
  • デジタル署名
  • 変更管理・バージョン管理
  • 監査ログ

完全性が失われると：

  • データ改ざん・不正送金
  • 偽ソフトウェアの配布（サプライチェーン攻撃）
  • 意思決定の誤り（改ざんされたデータに基づく判断）

「信頼できるシステム」において、完全性は重要な中核要素である。システムが動作していてもデータや処理結果が改ざんされていれば、そのシステムは信頼できない。

完全性が問うのは「情報が改ざんされていないか」という内容の正確性である。「誰が作ったか・送ったか」という発信者の同一性はAuthenticity（真正性）という別の観点が扱う。フィッシングメールやサプライチェーン攻撃は真正性の問題であり、完全性だけでは十分に捉えきれない。

可用性（Availability）

可用性とは、必要なときにシステムや情報を利用できる状態を維持することを意味する。「可用性」はavailabilityの訳語としてIBM系文脈で普及したとされる。日常会話では使われないが、IT・セキュリティ分野では標準的な用語として定着している。

代表的な対策：

  • 冗長化（サーバー・ネットワーク・電源）
  • バックアップ・災害対策（DR）
  • DDoS対策
  • 障害復旧計画（RTO・RPO の設定）

可用性が失われると：

  • サービス停止・業務停止
  • 社会インフラの停止（医療・電力・交通）
  • ランサムウェアによる業務不能

情報自体の価値は存在しても、それを活用できなければ実質的な価値を発揮できない。そのため可用性は重要である。

可用性が問うのは「今、使えるか」という現在の状態である。「侵害後にいかに回復するか」という設計はレジリエンス（Resilience）という概念が扱う。NIST CSF 2.0はこのRecover機能を独立した柱として体系化している。

なぜCIAで「安全かつ信頼可能」が説明できるのか

情報システムへの主要な被害は、最終的に次の3種類に整理できる。

被害の種類対応するCIA要素具体例
漏えい機密性（C）の侵害個人情報流出・営業秘密の盗取・認証情報窃取
改ざん完全性（I）の侵害データ改ざん・不正送金・偽ソフトウェア配布
利用不能可用性（A）の侵害DDoS攻撃・ランサムウェア・システム障害

なぜ被害は3種類に整理できるのか。それは「情報が使われるとき、必ず3つの行為が関係する」という理解モデルとして整理できる。

情報が使われるとき、誰かが（アクセスする）・何かを（読み書きする）・いつか（使う）という3つの行為が必ず発生する。この3行為それぞれに対応する被害が「漏えい・改ざん・利用不能」であり、C・I・Aはこの3行為を保護対象とする評価軸として設計された。

さらに「攻撃者が情報システムに対してできること」を整理しても、同じ3種類に行き着く。攻撃者にできることは「見る（C侵害）・変える（I侵害）・使えなくする（A侵害）」の3種類に集約される。例えば、近年の二重恐喝型ランサムウェアでは、データ窃取（C侵害）と暗号化による利用不能化（A侵害）が組み合わされる。なりすましは正規ユーザーのアクセス権を奪う（C侵害）ことで実現する。

3つの概念が互いに還元できない独立した軸であることも重要である。機密性が保たれていても完全性は失われうる（例：暗号化された通信が改ざんされた場合や、脆弱性を突いた外部攻撃者によるデータ書き換え）。完全性が保たれていても可用性は失われうる（例：正確なデータがシステム障害やDDoS攻撃で使えない場合）。この独立性により、被害の種類を明確に特定でき、対策の方向性を誤らない。多くのセキュリティ事故はこの3軸のいずれかへの侵害として分類できる。そのためCIAは膨大な脅威を整理するための共通モデルとして広く利用されている。CIAが有用である理由は、3つの概念がそれぞれ独立していることにある。機密性はアクセスの「誰に」を問い、完全性は内容の「何が」を問い、可用性はアクセスの「いつ」を問う。この独立性により、どの軸が侵害されたかを明確に特定でき、対策の優先順位をつけやすい。

CIAの問い侵害の特定対策の方向性
誰に見せるか（C）不正なアクセスがあったか認証強化・暗号化・アクセス制御
何が正確か（I）改ざんがあったかハッシュ・署名・監査ログ
いつ使えるか（A）使えない状態になったか冗長化・バックアップ・復旧計画

CIAはどのように形成されたか

CIAは単一の設計者・文書から生まれたのではなく、複数の文脈で独立に発展した概念が段階的に収束した。この経緯を知ることで、CIAが「情報セキュリティの唯一の真理」ではなく「当時の問題意識から収束した共通語彙」であることが分かる。

年出来事意義
1972Anderson Report（米空軍）C・I・Aの3概念が安全なシステム設計の評価軸として登場
1975Saltzer & Schroeder論文（MIT）C・I・Aを安全なシステム設計の基本目標として公開文献に明示
1986頃Steve Lipner（米国防総省）「CIA」という略語を命名。3概念がトライアドとして固まる
1988Morrisワーム初期インターネットに大規模な可用性障害を引き起こした代表的事例
2005ISO/IEC 27001初版CIAを情報セキュリティ定義の核として国際標準に採用

C・I・Aはそれぞれ独立した問題意識から別々の研究者によって生まれ、後に収束したと考えられる。設計当初は「情報セキュリティの定義」として提示されたのではなく、「安全なシステムを設計するための評価軸」として使われていた。「情報セキュリティとはCIAを維持すること」という定義は、後の標準化・教育化の過程で形成されたものと考えられる。

CIAは必要条件だが十分条件にはなりえない

情報セキュリティに「十分条件」は存在しない。脅威は常に進化し、守る対象も変化し続けるためである。CIAは当時の問題意識に対して有効な評価軸として形成されたが、時代とともにCIAの設計範囲を超えた脅威が顕在化してきた。CIAの設計範囲を超えた概念は、出所によって2つに整理できると考える。

ISO/IEC 27000:2018が明記する拡張概念

概念意味CIAでは捉えにくい事例
Authenticity（真正性）情報の送信者・作成者が主張通りの存在であることフィッシングメール自体は送信者真正性の問題として現れる。サプライチェーン攻撃（正規ルートからの侵害）
Accountability（説明責任）誰が何をしたかを追跡・証明できること内部不正（正規の権限で行われる不正行為の追跡・証明）
Non-repudiation（否認防止）事象・行動の発生とその起源を証明できること。「送っていない」と後から否定できない状態電子契約・電子署名・金融取引における否認
Reliability（信頼性）意図した動作および結果と一致する特性。システムが設計通りに一貫して正確に動作するか計算ロジックのバグで誤結果を一貫して返すシステム・AIの一貫した誤判断

NIST CSFが体系化した概念

概念出所意味CIAでは捉えにくい事例
Resilience（レジリエンス）NIST CSF 1.0（2014年）Recover機能侵害後に資産と業務を回復させる能力。可用性の「維持」とは設計思想が異なるランサムウェア感染後の復旧・Colonial Pipeline攻撃（復旧・事業継続能力の重要性を示した代表例）
Governance（ガバナンス）NIST CSF 2.0（2024年）Govern機能として独立サイバーセキュリティリスク管理の戦略・ポリシー・役割を組織全体で統括する機能。経営層の関与を含む経営層がリスクを把握せず投資判断を誤る・セキュリティと事業戦略が連動しない
Supply Chain SecurityNIST CSF 2.0（2024年）で強調第三者（ベンダー・パートナー・ソフトウェアプロバイダー）を通じたリスクの管理・検証SolarWinds攻撃（正規のソフトウェアアップデート経由でマルウェアが混入）

これらの追加概念も、最終的にはCIAを補強・拡張するものが多い。そのためCIAは現在でも情報セキュリティの基礎概念として維持されている。

「CIAを維持している企業がなぜサイバー攻撃にさらされるのか」という問いも、この文脈で理解できる。攻撃者は認証情報を盗む（これはC侵害であり、CIAで捕捉できる）。しかし盗んだ認証情報を使って正規ユーザーになりすましてアクセスする段階では、CIAのアクセス制御をすり抜ける。これはAuthenticity（真正性：本当に正規ユーザーか）の問題であり、CIAだけでは捕捉しにくい。さらに正規のツールで横展開し、サプライチェーン経由で正規ソフトウェアに混入するといった手法も同様に、CIAの設計範囲を超えた攻撃ベクターである。CIAが評価軸として有効であっても万能ではないことを示していると言える。

まとめ

問い答え
CIAとは何か情報セキュリティにおける3つの基本要素（機密性・完全性・可用性）を示す概念
なぜ3つなのか情報が使われるとき「誰が・何を・いつ」という3つの行為が必ず発生し、それぞれへの被害が「漏えい（C）・改ざん（I）・利用不能（A）」である。3つは互いに還元できない独立した評価軸
なぜCIAで「安全かつ信頼可能」が説明できるのか膨大な脅威を3軸で整理できるため、被害の特定・対策の方向性・優先順位づけが可能になる
CIAは万能か情報セキュリティに「十分条件」は存在しない。脅威は常に進化し、守る対象も変化し続けるため、固定した条件で「完全に安全」とは言えない。CIAはどの時代にも有効な評価軸。ISO/IEC 27000:2018はAuthenticity・Accountability・Non-repudiation・Reliabilityを追加。NIST CSF 1.0はResilience（Recover機能）を体系化。NIST CSF 2.0はGovernance・Supply Chain Securityをさらに強調
現代でも有効かゼロトラスト・クラウド・AI時代においても、CIAは情報セキュリティの評価軸として有効であり続ける。ただしCIAは「目的」ではなく「評価軸」として正しく位置づけることが重要

CIAとは、「情報が漏れず・改ざんされず・必要時に利用できる状態」を評価するための基本的な軸である。この3要素を整理して理解した上で改めてゼロトラストを見ると、ゼロトラストはCIAという評価軸を否定するものではない。ゼロトラストは、CIAという評価軸ではなく、CIA実現の前提として広く用いられてきた「境界防御中心の信頼モデル」を再設計する考え方である。CIAはゼロトラスト下でも有効な評価軸として機能し続ける。ただしCIAだけでは捉えきれない問題（真正性・説明責任・レジリエンス等）が現代の脅威環境では重要性を増しており、これらを補完する概念と組み合わせて用いることが求められる。CIAを正確に理解することが、ゼロトラストを含む現代のセキュリティを正しく議論するための出発点となる。

次回のブログ（続編）では、この部分をさらに掘り下げ、情報セキュリティの目的の観点で考えてみることとする。

以上

小規模組織のリモートアクセスをどう守るか

コメントをどうぞ

2026年4月25日
諸角　昌宏

本ブログは、CSAジャパンとしての正式な見解ではなく、あくまで筆者の個人的な意見としてまとめたものである。しかしながら、この問題はクラウドセキュリティに関わる人に幅広く関係することとして、このCSAジャパン・ブログに掲載させていただく。皆さんの屈託のない意見をいただければ幸いである。

CSAジャパン・ブログでは、「VPNは本当に危ないのか」というテーマで2回の投稿を行った。最初のブログでは、VPNをめぐるリスクの構造を三層に分けて整理し、国内の統計データの正確な読み方、よくある意見への答え、そして対策の方向性について考察した。続編では、VPNの設計思想の問題に対してZTNAが提供している「ダークIP」について掘り下げてみた。なお、これらについては、本ブログの最後に記述する参考資料から参照していただきたい。

これらの2回のブログで十分整理できたと考えていたが、先日の「SaaSセキュリティリーグ」において小規模組織の観点がカバーできていないと指摘された。確かに、「VPNは危ない、ZTNAに移行すべきだ」という議論において、多くの場合それは大規模組織を念頭に置いた話である。専任のセキュリティチームがあり、IdPが整備され、ある程度の予算がある組織を前提にしている。では、IT担当者が一人または兼任で、予算も限られた小規模組織はどうすればいいのか。

本ブログでは、小規模組織に合わせた現実的な選択肢を整理してみたい。なお、本ブログの作成にあたって、「SaaSセキュリティリーグ」の皆様に管理的・技術的な観点でのご教授をいただいた。この場を借りて感謝いたします。

小規模組織でも「リスクの構造」は同じ

まず認識しておくべきことは、VPNのリスク構造は組織の規模に関係なく同じであるということである。VPNのリスクの構造を三層に整理した以下の内容である。

  • 第1層：製品脆弱性（CVE）：　パッチを当てていなければ規模に関係なく標的になる
  • 第2層：認証情報管理：　漏洩パスワード・MFA未設定・ゾンビアカウントは小規模組織ほど放置されやすい
  • 第3層：設計思想の欠陥：　公開ポートによるアタックサーフェスとラテラルムーブメントの許容は構造的な問題であり規模は関係しない

パッチ適用の遅れ、退職者アカウントの放置、外部ベンダーへのVPN発行後の管理不足等は、大企業より小規模組織で起きやすい。Colonial Pipeline事件も「IT担当者が見落としていた休眠アカウント」が発端であった。したがって、「うちは小さいから狙われない」は誤解であり、ランサムウェア攻撃の多くは組織の規模を問わず自動スキャンで脆弱な機器を探し出している。小規模組織は「狙いやすい標的」になりうる。

大規模組織と小規模組織の違い

以下にこの違いについて表でまとめてみる。完全な内容ではなくあくまで特徴的な点をまとめたものである。

観点大規模組織小規模組織
IT専任担当いる（チームで対応）いない・兼任が多い
IdP整備状況Entra ID等すでにあるMicrosoft 365、Google Workspace導入済みなら実質整備済み。オンプレADのみの場合はクラウドIdPが未整備
ポリシー設計・維持専任チームが担える誰がやるか問題になる
予算ある程度確保できる限られることが多い
外部ベンダー管理数十社。管理が複雑数社。関係は密だが管理が属人化しやすい
リスクの特徴攻撃対象になりやすいパッチ対応、アカウント管理が遅れやすい

大規模組織向けのZTNA移行論では「まずIdPを整備し、ポリシー設計チームを組んで…」という前提が当たり前のように語られる。しかし小規模組織にとってこれらは高いハードルになりうる。IdPについては、Microsoft 365やGoogle Workspaceをすでに導入している組織であれば実質的に整備済みであり、このハードルは低い。一方、オンプレADのみの組織では、クラウドIdPの整備が先行課題になる。いずれにせよ、VPNを使い続けることのリスクは規模に関係なく存在する。

したがって、「大規模組織と同じアーキテクチャを目指しながら、小規模組織の制約（人員、予算、IT成熟度）に合った現実的な進め方はないか」ということを考えてみたい。以下にその選択肢を示す。

小規模組織向けの現実的な選択肢

選択肢A：クラウドZTNA（SaaS型）の直接導入

小規模組織にとって最も現実的なアプローチは、SaaS型のZTNAを直接導入することであると考える。近年、以下に示すように中小向けの価格設定、シンプルな管理画面を持つ製品が増えているので、これを利用することを考えたい。

製品・サービス特徴小規模向けの適合性
Cloudflare Zero Trust無料枠あり（50ユーザーまで）。セットアップが比較的容易。◎　無料枠で試せる点が強み
TailscaleWireGuardベースのL4型。
UIがシンプル・設定が少ない・無料プランあり		◎　IT担当が少ない組織に向く
Twingateエージェントレス対応あり。SaaSライクな管理画面・中小向けプランあり○　外部ベンダー管理に有効
Microsoft Entra ID + アプリプロキシMicrosoft 365ユーザーなら追加コスト低い。IdP兼用できる○　M365導入済みなら検討しやすい

これらの製品の共通点は「IdPとしてGoogle WorkspaceやMicrosoft 365を使える」という点である。Microsoft 365やGoogle Workspaceを導入済みの組織であれば、ZTNAに必要なIdP機能はすでに手元にある。オンプレADのみの組織と異なり、IdP整備のためだけに新たな製品、費用が発生しない点でZTNA移行のハードルが低い。ただしライセンスプランによっては条件付きアクセスやデバイスポスチャ評価に必要な機能が含まれない場合があるため、事前に確認が必要だ。

【技術的な補足】三層への対応と残存リスク

第1層（CVE）：　VPNアプライアンスを廃止するためダークIPが実現し、CVEを突く直接攻撃の入口がなくなる。ただしIdP自体は外部公開されており、そこへの攻撃は別途対策が必要になる。
第2層（認証情報）：　IdP連携でMFAを必須化しやすく、アカウントの即時失効も容易になる。残存リスクはMFA疲労攻撃・AiTMフィッシングのようなセッション乗っ取りなどがある。
第3層（設計思想）：　「公開ポートをなくす」と「認証後のネットワーク全体アクセスを制限する」の両方が実現できる。残存リスクはポリシー設計が粗い場合の形骸化と、移行期にVPNとZTNAが並存することによるハイブリッドリスクが考えられる。

【補足】ADドメイン非参加の独立ネットワーク（子会社・グループ会社等）への適用

子会社やグループ会社が、親会社のADドメインに参加しておらず、IdPやZTNA基盤を含めて独立した環境を運用していることがある。このような場合でも、エージェント型ZTNAは各組織単位で独立して導入・運用できる。ZTNAの実装は必ずしも親会社とのIdP統合やディレクトリ統合を前提とするものではなく、各組織が自らのIdPとポリシー基盤を用いてアクセス制御を完結させる構成も技術的に成立する。
一方で、IdPとZTNA基盤が組織ごとに分離された構成では、アクセス制御ポリシーと認証・認可の判断が各組織内で完結するため、組織横断的なポリシーの一元適用や統合的なアクセス制御は実現されない。親会社と子会社の間でユーザー属性やデバイス状態に基づく統一したコントロール（条件付きアクセスやリスクベース認証など）を実現したい場合は、IdPの統合またはSAML・OIDCによるフェデレーションが前提条件になる。
整理すると、エージェント型ZTNAはIdP統合の有無にかかわらず導入できる。ただし「各組織が独立して運用する構成」と「組織横断的に統合して運用する構成」では実現できることが異なる。そこで、まず子会社単体でZTNAを導入し、その後グループ全体でのIdP統合・フェデレーションを段階的に進めるアプローチが現実的と思われる。
なお、グループ共通のIDaaS基盤が整備されていればスムーズだが、現実にはアカウント構成が組織ごとに異なるケースが多い。製品によって対応は様々だが、以下のようなパターンで環境に合わせた接続設計を検討することが考えられる。

  • IDaaSとのSSO連携：　子会社が独自のIdPを持つ場合、SAML・OIDCによるフェデレーションでZTNA製品と連携させる（上記内容）
  • インストーラへのユーザー情報埋め込み：　エージェントのインストーラにユーザー情報をあらかじめ組み込み、端末単位で設定を完結させる
  • メール認証の利用：　IDaaS統合が難しい環境では、メールアドレスベースの認証で接続を許可する構成も選択肢になる

いずれのパターンも、組織単位、場合によっては端末単位での個別設計が必要になる。「まず動かせる構成で導入し、IdP統合は並行して進める」というような段階的なアプローチが現実的と考える。

選択肢B：外部ベンダーアクセスだけをZTNA化する

全社員のリモートアクセスをZTNAに切り替えるのが難しくても、「外部ベンダー・委託先のアクセスだけをZTNAに変える」という部分的なアプローチは小規模組織でも現実的である。
外部ベンダーへのVPN発行は、小規模組織でも特にリスクが高い部分である。保守ベンダーが退職しても誰も気づかずアカウントが残る、複数のベンダーが同じVPN認証情報を共有しているなど、こういった問題は小規模組織では起きやすい。
ZTNAで外部ベンダーのアクセスを管理することで、以下のような効果が得られる。

  • アクセスを「必要なサーバー、ポートのみ」に限定できる（保守対象サーバーへのSSHのみ等）
  • 契約終了時にアクセス権を即時削除できる（ゾンビアカウントの防止）
  • アクセスログを記録し、不審な操作を把握できる

【技術的な補足】三層への対応と残存リスク

第1層（CVE）：　外部ベンダー向けのVPNアプライアンスをなくすことができるが、社員向けVPNが残る場合は第1層のリスクが継続する。
第2層（認証情報）：　外部ベンダーのゾンビアカウント、アクセス過剰という最も典型的な第2層のリスクを効果的に抑制できる。SDPアーキテクチャを採用することで、ベンダーデバイスにエージェントなしで制御を適用できる。
第3層（設計思想）：　外部ベンダーの部分ではラテラルムーブメントを抑制できるが、社員向けVPNが残る限りそちらの設計思想の欠陥は解消されない。部分的な対処にとどまる点を認識した上で、段階移行の第一歩として位置づけるのが現実的と思われる。

選択肢C：VPNを維持しながら第2層を徹底する

今すぐZTNAに移れない場合でも、認証情報管理（第2層）を徹底するだけでリスクを大幅に低減できる。これは予算がほぼかからない対策でもあるし、「VPNを使い続けながらできる最低限の対策」と考えられる。ZTNAへの移行計画と並行して、今日から実施できるものである。

  • 全VPNアカウントにMFAを設定する
  • 退職者・外部委託先の未使用アカウントを今すぐ棚卸しして無効化する
  • パスワードポリシーを強化し、過去に漏洩したパスワードが使われていないか確認する。Have I Been Pwned等のサービスで自社ドメインのメールアドレス漏洩を確認するのも有効である。

【技術的な補足】三層への対応と残存リスク

第1層（CVE）：　VPNを維持するため第1層のリスクはそのまま残る。パッチ未適用の期間が「無防備な状態」であることは変わらない。
第2層（認証情報）：　MFA徹底とアカウント棚卸しで最も頻度の高いリスクを直接低減できる。コストがほぼかからない割に効果が大きいと思われる。残存リスクはMFA疲労攻撃・AiTMフィッシングなどがある。
第3層（設計思想）：　VPNの設計思想の欠陥は解消されない。公開ポートは残り続け、認証後のラテラルムーブメントも許容されたままである。

選択肢D：MSP（マネージドサービスプロバイダ）の活用

IT担当者が一人または兼任の組織では、ZTNAの導入・運用を自社でやりきることが難しい場合がある。その場合、ZTNAの導入・運用をMSPに委託するアプローチが現実解になりうる。
日本国内でもZTNAの導入支援・運用代行を提供するMSPが増えつつある。ポリシー設計・監視・インシデント対応を含めて委託することで、「担当者が一人でも動かせる」体制を作れる可能性がある。

ただし、MSPに委託する場合は、責任分界点、ログへのアクセス権、インシデント発生時の対応などのSLAを契約段階で明確にしておくことが重要である。「任せきり」にすることは、問題が起きたときの対応が遅れるリスクになる。

【技術的な補足】三層への対応と残存リスク

第1層・第3層（CVE・設計思想）：　選択肢Aと同様の効果が得られる。MSPがZTNAを運用することでVPNアプライアンスを廃止でき、ダークIPと最小権限アクセスを実現できる。
第2層（認証情報）：　MSPがアカウント管理・棚卸しを代行することで、属人化リスクを軽減できる。

残存リスクとして、MSP自体が侵害された場合に自組織のZTNA環境に影響が及ぶ可能性がある。また責任分界点が不明確なままだとインシデント対応が遅れるリスクがある。MSP選定時にはSLAの確認が重要である。

発展形としてのSSE（Security Service Edge）

選択肢ではないが、SSE（Security Service Edge）がある。GartnerがSASEのセキュリティ機能部分として定義したもので、以下の機能をクラウドで統合して提供する。

  • SWG：　Webトラフィックのフィルタリング・マルウェア検査
  • CASB：　SaaS/クラウドアクセスの可視化・制御・データ漏洩防止
  • FWaaS：　クラウド型ファイアウォール

SaaSを中心に業務を行っている小規模組織では、ZTNAだけでは「誰がどのSaaSに接続しているか」「シャドーITが発生していないか」「SaaS上のデータが外部に持ち出されていないか」といった可視性・制御の課題が残りやすい。SSEはこれらをZTNAと一体で解決できる点で、SaaSセキュリティに課題を抱える組織に特に適している。
SSE導入について、小規模組織にとっての現実的な進め方としては、まずZTNA（選択肢A）から始め、SaaSの可視性・制御の課題が顕在化した段階でSSEに発展させる段階的なアプローチが適切と考える。Zscaler、Netskope、Cloudflare One等の主要SSE製品は中小向けのプランを提供している。

【技術的な補足】三層への対応と残存リスク

第1層・第3層（CVE・設計思想）：　ZTNAを前提とするため、VPNアプライアンスを廃止でき、ダークIPと最小権限アクセスが実現する。
第2層（認証情報）：　ZTNAのMFA必須化・アカウント管理に加え、CASBによりSaaS上の異常なデータアクセスの検知も可能になる。
残存リスクはZTNA単体と同様で、IdPへの攻撃、ポリシー形骸化、ハイブリッド移行期のリスクがある。加えてSSEは機能が多い分、設定の複雑さが増す点は考慮が必要かもしれない。

以上の4つの選択肢とSSEについて、VPNのリスク三層を表にまとめると以下になる。

選択肢三層対応残存リスク
選択肢A（SaaS型ZTNA導入）第1層◎ 第2層○ 第3層◎IdP自体への攻撃、ポリシー設計の粗さ、移行期のハイブリッドリスク
選択肢B（外部ベンダーのみZTNA化）第1層△ 第2層○ 第3層△社員のVPNは残るため第1層・第3層の問題は社員アクセス部分で継続
選択肢C（VPN維持＋第2層の徹底）第1層✕ 第2層○ 第3層✕第1層・第3層は未解決のまま。CVE発見時の無防備期間とラテラルムーブメントリスクは継続
選択肢D（MSP経由のZTNA）第1層◎ 第2層○ 第3層◎MSPへの依存による責任分界点の不明確化、MSP自体が侵害された場合の影響拡大のリスク
SSE（ZTNA＋SWG＋CASB）第1層◎ 第2層◎ 第3層◎IdPへの攻撃、ポリシー形骸化、設定の複雑さが増大（MSP経由が代案）

（注：◎＝根本的に対処、○＝対処できる、△＝部分的、✕＝対処できない）

小規模組織が陥りやすい落とし穴

「外部ベンダーと長い付き合いだから大丈夫」

信頼関係がある外部ベンダーだからこそ、アクセス権の見直しが後回しになりやすい。しかし攻撃者はベンダーの認証情報を狙ってくる。ベンダーとの信頼関係とアクセス権の適切な管理は別の話として考える。

「うちはSaaSしか使っていないからVPNは関係ない」

SaaS中心の組織でもVPNを使っているケースは多い。バックオフィスシステム、社内ファイルサーバー、クラウド管理コンソールへのアクセスにVPNを使っていないか等、今一度確認することが必要と考える。

「無料プランのZTNAで十分」

無料プランはスタートに最適だが、ユーザー数、ログ保存期間、サポートに制限がある場合が多い。特にログ保存はインシデント発生時の調査に不可欠であり、無料プランの制限を把握した上で判断する必要がある。

「スプリットVPNで設定したから大丈夫」

スプリットVPNは、通信先によってVPN経由と直接インターネット経由を使い分ける設定である。たとえば「社内リソース宛てはVPN経由、Microsoft 365やYouTubeは直接インターネットへ」という形で通信経路を分割する。SaaSアクセス時のバックホール問題（遅延・帯域圧迫）を軽減できるため、テレワーク環境で広く使われている。
課題としては、VPN外に出るトラフィック（SaaS・クラウド宛て）には、社内のセキュリティポリシーが適用されなくなる。シャドーITが発生しても可視化できず、社外からの通信がそのままエンドポイントに届く状態になる。またスプリットVPNはVPNの第3層の設計思想の問題（公開ポートによるアタックサーフェスとラテラルムーブメントの許容）は残るので、利用にあたってはこのような点を注意する必要がある。

小規模組織が今日から始められること（優先順位順）

小規模組織が取れる行動を、コストと緊急度で整理すると以下のようになると考える。

  • 【今すぐ・コストほぼゼロ】VPNアカウントの棚卸し：　退職者・外部委託先の未使用アカウントを洗い出して無効化する
  • 【今すぐ・コストほぼゼロ】MFAの全アカウントへの設定：　Microsoft 365やGoogle Workspaceの認証機能を使えばほぼ無料で実現できる
  • 【今すぐ・コストほぼゼロ】VPN機器のパッチ確認：　使用中のVPN製品の最新CVEと適用状況を確認する
  • 【短期・低コスト】外部ベンダーアクセスをZTNAに移行：　Cloudflare Zero TrustやTailscaleの無料プランで試験導入できる
  • 【中期・要予算検討】全社員のリモートアクセスのZTNA化：　Microsoft 365等のIdPを活用し、段階的に移行する

まとめ

小規模組織には、小規模組織向けの方法がある。「VPNは危ない」という問題は規模に関係なく当てはまるが、解決策は大規模組織と同じである必要はない。SaaS型ZTNAの活用、外部ベンダーアクセスからの部分的移行、MSPの活用など、規模に合った現実的な選択肢が存在する。まず今日できることから始め、段階的にアーキテクチャを近代化することが重要であると考える。

参考資料

以上

VPN利用の現状と脱VPNの現実性について

1件のフィードバック

第5回SaaSセキュリティリーグ会議

「SaaSセキュリティリーグ」は、SaaSユーザー企業の実務者同士で情報交換を行う取り組みである。SaaS管理者やセキュリティ担当者を横串でつなぎ、知見交換を行うことで、セキュリティレベル向上に貢献していくことを目的としている。ここでは、「SaaSセキュリティリーグ」が行った第5回会議の内容をまとめて公開する。

問題点の概要

「VPNは危険だ」という言説が広まっている。ランサムウェア被害の報道でVPNが侵入経路として言及されることが増え、セキュリティベンダーはこぞって「脱VPN・ゼロトラスト移行」を訴えている。

このような状況を受けて、今回のSaaSセキュリティリーグでは、VPN利用の現状、ZTNAへの移行状況等についてディスカッションを行った。

ディスカッション内容

  1. VPN利用状況の現状：VPNをどのような用途で使っているか
    VPN自体は、現状各組織で使われている状況である。VPNの問題自体は認識されており、ZTNAへの移行に向けての作業、準備が進められている。
    VPNの利用については、以下の3つのポイントで考える必要があり、この中で、VPNの廃止を進めているのは、リモートアクセスおよびサードベンダー用アクセスということである。
    • 従業員のリモートアクセス
    • サードベンダー用アクセス
    • 拠点間アクセス

      また、お客様の方でVPNアクセスを求められることがあり、これはVPN接続せざるをえないという指摘があった。その際には、運用として会社のネットワークからは使わせないようにする対応を取っているとのことである。
  2. SaaS/クラウドへのアクセスはVPN経由かどうか
    リモートアクセスとSaaSアクセスは特に区別せず同じ扱いをしている。
    一旦オンプレにつないでからクラウドにアクセスしている。
    スプリットVPNも使われているが、あくまで限定した形での利用とている。特に、Zoom・Teams等のリアルタイム通信が必要とされる場合に利用している。

    クラウドアクセスのパターンは以下の3つに分けられる:
    • SASE/CASB経由
    • 端末からダイレクトにクラウドサービスに接続（パフォーマンス、可用性の問題）。
    • ZTNAであっても、一旦社内に持ってきてからインターネットに接続する（アクセス元を管理したいケースに利用）。IPアドレスでコントロールし、外に出るIPアドレスで経路を特定することができる。
  3. VPN廃止の検討、計画の状況
    従業員のリモートアクセスおよびベンダーアクセスVPNは全廃の方向で進めている。従業員のリモートアクセスについては、インターネット経由はすでに無くしているところもあり、ZTNAに移行している。リモートデスクトップに近いやり方で制御している。
    ベンダーアクセスについては、なるべく無くす方向で進めている。主要な相手とは専用回線のVPNで対応している。
    拠点間アクセスは、継続してVPNを利用している。
  4. ZTNA（SASE）への移行の問題点
    VPNを廃止する場合の問題点として、以下が上げられた：
    • SIPがルーターを超えられないので、VPN接続せざるを得ないところがある。コールセンターの音声系など。
    • SASEが高い。
    • 子会社の一部などADドメインに参加していない独立したネットワークがある。ADドメインに参加していない子会社の端末でも、ZTNAエージェントをインストールしてIdPでログインできれば、同じポリシーで制御できるのではないか。
    • SaaS製品の問題がネットワーク側の問題とされるケースがあるが、SASEとほかの製品との問題点の切り分けは特に問題にはなっていない。
  5. その他
    • 中小企業向けの対策としてZTNAはどうなのか、軽量な接続方法としてVPNは残るかという観点での検討が必要ではないかという指摘があった。Tailscale などの利用の検討する必要があるとのことである。また、SaaSを中心に業務を行っている小規模組織に対しては、SSEの利用も考えられるのではという指摘があった。
    • 経済産業省「サプライチェーン強化に向けたセキュリティ対策評価制度に関する制度構築方針」において、発注者（委託元）が取引先（受注者・委託先）に対してセキュリティ強化を依頼した場合に、セキュリティ対策コストの価格転嫁ができるとの意見があった。これにより、ZTNAへの移行が進められるかもしれないという指摘である。
  6. 参考資料

以上

　「AI脆弱性の嵐 (AI Vulnerability Storm)」： 「Mythosレディ」なセキュリティプログラムの構築」を公開しました。

コメントをどうぞ

2026年4月19日
CSAジャパン　諸角昌宏

本ブログでは、「AI脆弱性の嵐 (AI Vulnerability Storm)」： 「Mythosレディ」なセキュリティプログラムの構築」について記載します。

「AI脆弱性の嵐 (AI Vulnerability Storm)」： 「Mythosレディ」なセキュリティプログラムの構築」は、CSA CISO Community, SANS, [un]prompted, the OWASP Gen AI Security Project,等のコミュニティが公開した「The “AI Vulnerability Storm”: Building a “Mythosready” Security Program」をCSA本部の承認のもとに翻訳して公開したものになります。
AIを活用した脆弱性発見とエクスプロイト開発は劇的に加速しています。脆弱性の公開から悪用されるまでの期間は短縮しており、セキュリティチームには、現在の運用モデルでは対応しきれないほどの迅速な対応が求められています。本ブリーフィングは、CISOおよび経営層向けの枠組みと実践的なガイダンスとして、AI主導の攻撃が新たな基準となった世界で活動するために必要な、即時の対応策、短期的な優先事項、そして長期的な変革の概要を解説しています。
なお、本資料は、16名の著者、約250名のCISOおよび実務家によるレビューア、CISA、NSA、ホワイトハウスの元幹部らによる驚くべき共同作業で作られています。

こちらからダウンロードしてご覧ください。