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の攻撃チェーンのどの段階に対応するかを整理してみる。

なお、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レディの中核を形成するものと考える。

以上

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1　3つの定義の層

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

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

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

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

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

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

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

3.3　先行研究は？

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

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

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

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

4.2　3層構造で整理する

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

この3層構造において：

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

4.3　3層構造の根拠

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

まとめ

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

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

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

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

以上

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

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

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

CIAとは何か

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

情報システムは、この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種類に整理できる。

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

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

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

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

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

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

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

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

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

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

NIST CSFが体系化した概念

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

「CIAを維持している企業がなぜサイバー攻撃にさらされるのか」という問いも、この文脈で理解できる。攻撃者は認証情報を盗む（これはC侵害であり、CIAで捕捉できる）。しかし盗んだ認証情報を使って正規ユーザーになりすましてアクセスする段階では、CIAのアクセス制御をすり抜ける。これはAuthenticity（真正性：本当に正規ユーザーか）の問題であり、CIAだけでは捕捉しにくい。さらに正規のツールで横展開し、サプライチェーン経由で正規ソフトウェアに混入するといった手法も同様に、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担当者が見落としていた休眠アカウント」が発端であった。したがって、「うちは小さいから狙われない」は誤解であり、ランサムウェア攻撃の多くは組織の規模を問わず自動スキャンで脆弱な機器を探し出している。小規模組織は「狙いやすい標的」になりうる。

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

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

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

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

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

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

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

これらの製品の共通点は「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のリスク三層を表にまとめると以下になる。

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

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

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

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

「うちは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は本当に危ないのか（続編）　～　ダークIPで防げること・防げないこと」
• 「VPN経由のサイバーインシデントを未然に防ぐための包括的セキュリティマネジメント：現代の脅威分析と組織的防衛戦略」記事

以上