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）

以上

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

以上

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 Networks	CACA（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層の関係を正しく理解することが、現代のセキュリティを議論する出発点となると考える。

以上

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

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

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

CIAとは何か

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

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

情報システムは、この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が「情報セキュリティの唯一の真理」ではなく「当時の問題意識から収束した共通語彙」であることが分かる。

年	出来事	意義
1972	Anderson Report（米空軍）	C・I・Aの3概念が安全なシステム設計の評価軸として登場
1975	Saltzer & Schroeder論文（MIT）	C・I・Aを安全なシステム設計の基本目標として公開文献に明示
1986頃	Steve Lipner（米国防総省）	「CIA」という略語を命名。3概念がトライアドとして固まる
1988	Morrisワーム	初期インターネットに大規模な可用性障害を引き起こした代表的事例
2005	ISO/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 Security	NIST 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ユーザーまで）。セットアップが比較的容易。	◎　無料枠で試せる点が強み
Tailscale	WireGuardベースの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は本当に危ないのか（続編）　～　ダークIPで防げること・防げないこと」
• 「VPN経由のサイバーインシデントを未然に防ぐための包括的セキュリティマネジメント：現代の脅威分析と組織的防衛戦略」記事

以上