ゼロトラスト ― 何も信用せず常に検証する ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「セキュリティアーキテクチャ」カテゴリ第6弾として、ゼロトラストについて解説する記事です。

「Never Trust, Always Verify（何も信用せず常に検証する）」というセキュリティ思想で、Google BeyondCorp が原型。本記事ではゼロトラスト5原則、ZTNA／SASE／マイクロセグメンテーション／継続的監視の構成要素、段階的導入ロードマップ、AI時代に人間とAIエージェントを同列に扱う新常識を解説します。

本記事のテーマについてさらに詳しく知りたい方は『セキュア・バイ・デザイン』も参考にしてみてください。

そもそもゼロトラストとは何か

空港のセキュリティを思い浮かべてください。乗客全員が──航空会社の社員であっても──手荷物検査を受け、パスポートを確認され、搭乗ゲートで再び本人確認されます。「関係者だから顔パスでOK」という仕組みは存在しません。

ゼロトラストはこれと同じ発想です。社内ネットワークにいるからといって無条件に信頼せず、すべてのアクセスを毎回検証するセキュリティモデルです。ユーザーが誰か・端末は安全か・場所は正当か・時間帯はおかしくないか──こうした文脈情報を総合的に評価し、アクセスのたびに許可・拒否を判定します。

もしゼロトラストがなければ、一度社内ネットワークに侵入した攻撃者はどこへでも自由に移動できてしまいます。実際に多くの大規模情報漏洩事件は、最初の侵入口は小さくても、内部で横展開されて被害が拡大しています。

お城と堀では、もう戦えない

従来の「境界型」（Perimeter-based）セキュリティは「社内LANは安全、VPNの内側は信頼」という前提でしたが、クラウド・SaaS・リモートワークで境界が曖昧になり、もはや内側は安全の前提が成立しない時代になりました。

ゼロトラストは製品名ではなく思想。導入すれば終わりではなく、全社的な設計変更です。

なぜ必要か

① 境界が消滅した

社員はリモートワーク、データはSaaS、サーバーはクラウド──もはや「社内」という概念が存在しません。守るべき境界線が物理的に引けないのです。

② 内部脅威・横展開攻撃

攻撃者は1台のPCを突破すれば、社内LAN内で横展開（Lateral Movement）できてしまいます。境界突破後の被害拡大を防ぐには内部も信頼しない設計が必須です。

③ クラウド・SaaS時代の現実

Salesforce・Slack・GitHub・AWS──全てが外部にあります。全通信が「社外」を経由するため、境界防御は機能しません。

ゼロトラストの5原則

NIST SP 800-207 で定義されたゼロトラストアーキテクチャの基本原則です。これらを貫けば自動的にゼロトラストになる、というガイドラインです。

境界型との比較

境界型は「お城 + 堀」、ゼロトラストは誰が来ても一人ずつ身分証チェックに例えられます。

主要構成要素①（ID・認証）

ゼロトラストの核は、強固な認証・認可基盤です。本人確認が曖昧なら、いくら通信を検証しても意味がありません。IAM・MFA・パスキー・SSO がゼロトラストの土台になります。

主要構成要素②（ZTNA）

ZTNA は、VPNの代替となるアプリ単位アクセスの仕組みです。VPNはネットワーク全体に接続させますが、ZTNAは「このユーザーはこのアプリだけに接続可」と個別に制御します。VPN突破時の横展開を根本的に防げます。

ZTNA は VPNより設定が簡単で、ユーザー体験も良好です。新規構築ならVPNよりZTNAが第一候補です。

主要構成要素③（SASE）

SASEは、ネットワーク + セキュリティを統合したクラウドサービスで、ゼロトラストの実装形態として注目されています。ZTNA・SWG（Secure Web Gateway）・CASB・FWaaS を1つのプラットフォームで提供します。

代表サービス：Zscaler・Cloudflare One・Palo Alto Prisma・Netskope。

主要構成要素④（マイクロセグメンテーション）

ネットワークを細かく区切り、サービス間通信を最小化する設計です。Service Mesh（Istio・Linkerd）を使えば、マイクロサービス間の通信を全てmTLSで相互認証でき、1サービスが侵害されても他への横展開を防げます。

主要構成要素⑤（継続的監視）

ゼロトラストは1回検証して終わりではないのが特徴です。セッション中も継続的に監視し、異常を検知したら即座に権限を剥奪する仕組みが必要です。

「平日17時にログイン → 深夜3時に海外IP」のような異常は、UEBAで自動検知して権限を一時停止できます。

GoogleのBeyondCorp

ゼロトラストの実装例として最も有名なのが Google の BeyondCorp です。2009年の中国からの攻撃（Operation Aurora）をきっかけに、VPNを全廃し、全社員を外部扱いする大胆な設計に踏み切りました。

Google社員はどこからでも同じ方法で業務アプリに接続でき、社内・自宅・カフェの区別がありません。「社内LANへの接続という概念がGoogleには存在しない」状態です。

2020年12月に発覚したSolarWinds事件は、信頼されていた監視ソフトの更新ファイルに攻撃コードが仕込まれ、米国政府機関を含む約1万8千組織の「社内」に正規ルートで侵入を許しました。「信頼済み」という札がついた経路こそが最大の攻撃面になるという、ゼロトラストの必要性を突きつけた事件です。

導入の現実的ステップ

ゼロトラストは一夜で実現できない大規模変革です。現実的には数年かけて段階的に導入します。いきなり全社展開すると業務が止まるため、以下の順序が王道です。

「最初のステップはIAM + MFA強化」です。ここを疎かにしてZTNAだけ入れても、なりすまされれば意味がありません。

ゼロトラスト導入の段階別ロードマップ

ゼロトラストは「一夜では実現しない」組織変革で、数年がかりのロードマップが必要です。下記がNIST SP 800-207 に準拠した現実的な段階です。

「Phase 1（IAM + MFA）を疎かにしたままZTNAだけ入れても効果はゼロ」なりすまされたら全て無意味になります。最初の土台に6ヶ月〜1年を投資するのが、ゼロトラスト全体の成否を決めます。

ゼロトラストはIAM + MFAから始まる。土台なしにZTNAは効きません。

判断基準

① 組織規模

② クラウド採用度

ケース別の選び方

SaaS中心のスタートアップ（数十名・クラウドネイティブ）

Okta/Google Workspace + Cloudflare Access（無料枠）+ MDM。VPNを導入せず、最初からZTNA。MDMで会社支給Mac/PCを管理し、個人端末からの業務アクセスを禁じる。全社員で数万円/月。

リモートワーク中心の中堅SaaS企業

Okta + Cloudflare One（SASE）+ Jamf/Intune。SSOで全SaaSを一元管理、SASEでWeb通信を全てクラウド経由にしてDLP・WAFを一括適用。VPNは段階的廃止。

既存オンプレ資産のある大企業

Azure AD + Zscaler Private Access + 段階的ZTNA移行 + SIEM（Sentinel/Splunk）。既存VPNを一気に止めると業務停止するため、新規アプリはZTNA・既存はVPNを並行運用。3-5年計画で置換。

金融・医療・政府系

IdP + MFA（FIDO2）+ マイクロセグメンテーション + 24/7 SOC + UEBA。NIST SP 800-207 準拠の要件を満たすため、全要素を実装。特に「継続的監視」（UEBA・SOAR）への投資が最重要。

やってはいけないこと

ゼロトラスト導入で事故る典型パターンを整理します。どれも「製品を買えば解決」と誤解している構造を持ちます。

SolarWinds 2020年事件（詳細は付録「重大インシデント事例集」）とTwitter内部ツール侵害2020年（ソーシャルエンジニアリングで従業員認証情報盗取、Obama・Biden・Elon Muskアカウント乗っ取り）は、「信頼済み」という札がついた経路こそ最大の攻撃面という教訓を示しました。

ゼロトラストは思想であり組織変革。製品導入だけで完結しません。

AI判断軸

1. IAM + MFAから段階導入 — IdP中央管理 + FIDO2推奨、ここが全ての土台
2. ZTNAでVPN代替 — アプリ単位認可、横展開攻撃を根本から防ぐ
3. 継続的監視 + UEBA — セッション中も検証、異常時は権限即剥奪
4. AIエージェントも同列に扱う — 別ID・毎アクション認可・短命トークン

AIエージェントをゼロトラストの対象に含める設計

AIエージェントは人間のユーザーと同じくゼロトラストの対象として扱う必要があります。エージェントがDBにアクセスする場合、毎回認証・認可を通し、操作内容を監査ログに記録し、異常なパターン（大量のSELECT・通常と異なるテーブルへのアクセス）を検知した時点で即座にトークンを失効させる設計が求められます。

従来の「サービスアカウントに強い権限を付けて放置」する設計では、AIエージェントが乗っ取られた場合（プロンプトインジェクション等）の被害が甚大になります。エージェントの操作範囲を最小化し、異常時に即停止できる仕組みが前提です。

継続的検証とAI異常検知の組み合わせ

ゼロトラストの「継続的検証」は、セッション確立後も常にユーザー/エージェントの振る舞いを監視し続ける仕組みです。UEBA（User and Entity Behavior Analytics）をAIで実装すれば、「このユーザーは通常9時〜18時にしかログインしないのに深夜3時にアクセスしている」「このエージェントは通常100件/分のAPI呼び出しなのに10,000件/分に急増した」といった異常を自動検知できます。

検知後の対応（トークン失効・アクセス遮断・管理者通知）まで自動化すれば、人間のオンコール対応を待たずに被害を最小化できます。

筆者メモ — 「信頼できる経路」こそが最大の攻撃面だった事例

「内部は信頼できる」という前提がいかに危険か、近年の大型事件が突きつけた教訓として語り草になっています。

2020年12月に発覚したSolarWinds事件（Sunburst攻撃）では、信頼されていた監視ソフトの更新ファイルに攻撃コードが仕込まれ、米国政府機関（財務省・商務省・国土安全保障省）を含む約1万8千組織の社内に正規ルートで侵入を許しました。「信頼済みベンダーの札がついた経路こそが最大の攻撃面になる」、というゼロトラストの必要性を決定的に示した事件として、世界中のCISO（情報セキュリティ最高責任者）の認識を変えました。

もう一つ、同じく2020年のTwitter 内部ツール侵害事件では、ソーシャルエンジニアリング（スピアフィッシング）で一部従業員の認証情報が盗まれ、内部管理ツールから Obama・Biden・Elon Musk ら著名アカウントが乗っ取られました。「社内ツールは社内の人間しか触らない」という暗黙の信頼が、実はMFAもデバイス検証もない状態で支えられていた、という実態が浮き彫りになった事件です。

筆者も前職で、VPNの設定だけで「中は安全」と信じ込んでいた結果、退職者のアカウントが半年近く有効なまま放置され、本人が悪意なく開発環境に繋いでしまった、というヒヤリハットを横目で見たことがあります。どちらも信頼された経路が突かれた事例で、Googleが2009年のOperation Aurora以降 BeyondCorpでVPN全廃に踏み切った判断の正しさを、後年になって裏付けました。

「誰が・どの端末で・今繋いでいるか」を常に問い直す発想が、ゼロトラストの核です。

決めるべきこと — 自分のプロジェクトでの答えは？

以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

• IdPの選定（Okta / Azure AD / Google Workspace）
• MFA必須化の範囲（全社 / 管理職のみ）
• デバイス管理（MDM、Jamf・Intune等）
• ZTNAサービス（Cloudflare Access等）
• SASE導入の要否（全社SASE化か段階か）
• マイクロセグメンテーション（Service Mesh等）
• SIEM・UEBAの採用（継続的監視）

この記事に関連する記事

まとめ

本記事はゼロトラストについて、NIST SP 800-207の5原則・ZTNA・SASE・マイクロセグメンテーション・継続監視・段階的ロードマップ・AI時代に人間と機械を同列に扱う設計まで含めて解説しました。如何だったでしょうか。

IAM+MFAから段階導入し、ZTNAでVPN代替、継続監視+UEBAでセッション中も検証、AIエージェントも同列に扱う。これが2026年のゼロトラストの現実解です。

次回は秘密情報管理（API Key・パスワード・証明書の保管）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

本記事で扱った内容の詳細は Google BeyondCorp も合わせて参考にしてください。

それでは次の記事も閲覧いただけると幸いです。