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

本記事について

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

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

このカテゴリの他の記事

概要 ― 多層防御とゼロトラストの全体像 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-security-overview/

認証設計 ― IDaaS+Passkey+短命トークンの基本 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-security-auth/

認可とIAM ― 最小権限を貫く実務 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-security-iam/

暗号化 ― 鍵管理が暗号の強度を決める ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-security-encryption/

ネットワークセキュリティ ― 境界からゼロトラストへ ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-security-network/

秘密情報管理 ― ゼロ秘密化が最高の防御 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-security-secrets/

脆弱性診断 ― CIに組み込み毎日検査する運用 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-security-vuln/

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

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

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

なぜ必要か

① 境界が消滅した

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

② 内部脅威・横展開攻撃

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

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

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

ゼロトラストの5原則

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

flowchart LR
    subgraph OLD["境界型 (従来)"]
        WALL[ファイアウォール]
        IN[内側は信用]
        WALL -.|入口で1回認証| IN
    end
    subgraph ZT["ゼロトラスト"]
        REQ([全リクエスト]) --> POL[Policy Engine]
        POL --> CTX[コンテキスト評価<br/>ID/端末/場所/時間]
        CTX -->|許可| RES[リソース]
        CTX -->|拒否| DENY[アクセス拒否]
    end
    classDef old fill:#fee2e2,stroke:#dc2626;
    classDef new fill:#dcfce7,stroke:#16a34a;
    classDef policy fill:#dbeafe,stroke:#2563eb;
    classDef deny fill:#fef3c7,stroke:#d97706;
    class OLD,WALL,IN old;
    class ZT,REQ,RES new;
    class POL,CTX policy;
    class DENY deny;

原則	内容
全リソースを保護対象とする	データ・デバイス・ユーザー全て
全通信を暗号化・認証する	内部通信でもmTLS
セッション単位でアクセス判断	毎回検証、継続検証
動的ポリシー適用	コンテキスト（場所・時間・端末）で判断
全アクセスを監視・ログ化	後から追跡可能に

境界型との比較

	境界型（従来）	ゼロトラスト
信頼の基準	ネットワーク位置	認証・コンテキスト
検証頻度	入口で1回	毎リクエスト
内部通信	暗号化不要	必ず暗号化
VPN	中心的	不要（ZTNAへ）
アクセス単位	ネットワーク	アプリ・リソース単位
設計の前提	内部は安全	何も信用しない

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

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

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

要素	役割
IDプロバイダ（Okta・Azure AD）	中央でID管理
MFA必須（FIDO2推奨）	なりすまし防止
デバイス認証	管理外端末を拒否
条件付きアクセス	場所・時間・端末で判断
継続的認証	セッション中も再検証

主要構成要素②（ZTNA）

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

サービス	特徴
Cloudflare Access	手軽・Cloudflare統合
Zscaler Private Access	エンタープライズ
Tailscale	WireGuardベース・シンプル
Twingate	開発者向け
Palo Alto Prisma Access	フルセット

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

主要構成要素③（SASE）

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

構成要素	役割
SWG	Web経由の脅威フィルタ
CASB（Cloud Access Security Broker、SaaS利用を仲介し制御）	SaaS利用の可視化・制御
ZTNA	アプリ単位アクセス
FWaaS	クラウド型ファイアウォール
DLP（Data Loss Prevention、機密データ流出防止）	データ漏洩防止

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

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

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

技術	用途
Istio / Linkerd	Kubernetes内サービスメッシュ
Calico / Cilium	K8s ネットワークポリシー
Consul Connect	HashiCorp製サービスメッシュ
AWS App Mesh	AWS統合

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

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

要素	役割
SIEM（Security Information and Event Management、ログ統合監視。Splunk・Sumo・Sentinel等）	ログ統合・相関分析
SOAR（Security Orchestration, Automation, and Response、セキュリティ対応自動化）	自動対応・プレイブック
UEBA（User and Entity Behavior Analytics、ユーザー行動の異常検知）	行動分析・異常検知
XDR（Extended Detection and Response、複数層横断の脅威検知）	複数レイヤー統合検知

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

GoogleのBeyondCorp

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

BeyondCorpの特徴	内容
VPN不要	インターネット経由で直接
デバイス証明書必須	管理端末のみ許可
コンテキスト判断	場所・端末状態で判断
アプリ単位アクセス	ネットワーク単位ではない

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

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

導入の現実的ステップ

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

フェーズ	内容
Phase 1	IAM強化・MFA必須化
Phase 2	デバイス管理・条件付きアクセス
Phase 3	ZTNA導入・VPN段階廃止
Phase 4	マイクロセグメント・SASE
Phase 5	継続的監視・UEBA導入

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

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

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

フェーズ	期間目安	実装内容	効果
Phase 1: IAM基盤	〜6ヶ月	IdP導入（Okta/Entra ID）+ MFA必須化	なりすまし対策の土台
Phase 2: デバイス管理	〜1年	MDM（Jamf / Intune）+ デバイス証明書	管理外端末からのアクセス遮断
Phase 3: ZTNA	〜1.5年	VPN → ZTNA段階移行（Cloudflare Access / Zscaler）	アプリ単位アクセス制御
Phase 4: マイクロセグメント	〜2年	Service Mesh（Istio）+ mTLS全通信	横展開攻撃の遮断
Phase 5: 継続監視	〜3年	SIEM + UEBA + SOAR	異常行動の自動検知・対応

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

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

判断基準

① 組織規模

規模	推奨
スタートアップ	Okta + Cloudflare Zero Trust 無料枠
中堅（100-1000名）	Okta + Cloudflare One + MDM（Mobile Device Management、端末管理）
大企業	Zscaler or Palo Alto フルセット + SIEM
政府・金融	オーダーメイド + 24/7 SOC

② クラウド採用度

利用形態	推奨
SaaS中心・クラウドファースト	SASE導入が最短
ハイブリッド	ZTNA + 既存VPN並行
オンプレ中心	IAM強化から段階的に

ケース別の選び方

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）への投資が最重要。

ゼロトラスト導入の鬼門・禁じ手

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

禁じ手	なぜダメか
製品を買えばゼロトラストになると誤解	思想・設計・運用が本体。Okta + Cloudflareを買うだけでは変わらない
VPNを一気に廃止してZTNAへ移行	既存アプリで業務停止。新規ZTNA + 既存VPN並行運用が現実的
IAM + MFAを後回しにしてZTNAだけ導入	なりすまされたら全て無意味。土台から順に
デバイス検証なしで個人端末から業務アクセスを許可	マルウェア感染端末が直接業務ネットワークに。MDM必須
内部通信を平文のまま運用	横展開攻撃で一気に全サービス掌握。mTLS全通信暗号化
監査ログをSIEMに集約しない	異常検知が手動レビュー頼みに。自動相関分析が必須
SaaS利用をCASBで監視しない	Shadow IT（無許可SaaS）が情報漏洩の温床に
退職者・異動者のアクセス権限を即座に停止しない	2020年Twitter内部ツール侵害のパターン
ゼロトラストをセキュリティチーム単独で推進	全社変革なので経営・人事・インフラ・開発の協調が必須

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

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

AI時代の視点

AI駆動開発（バイブコーディング）とAI活用が前提になると、ゼロトラストはAIエージェントも対象に含めた設計になります。AIエージェントが自律的にシステムを操作するため、エージェントにもID・認証・権限・監査を適用する必要があります。

AI時代に有利	AI時代に不利
エージェント別ID管理	共通API Key共用
毎アクション認可チェック	セッション冒頭のみ
全アクセスログ化	ログ欠損
短命トークン・自動失効	永続クレデンシャル

ゼロトラストの「何も信用せず、常に検証」は、AI時代により重要になります。AIは人間より速く・多く操作するため、1回の認可を信頼する境界型発想は完全に破綻します。

AI時代のゼロトラストは人間と機械を同列に扱う。エージェントも毎回検証します。

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

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

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

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

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

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

よくある勘違い

製品を買えばゼロトラストになる → ゼロトラストは思想・設計。製品は実装手段の1つ。運用と組織変革が本体
VPNを捨てればゼロトラスト → ZTNA化は第一歩。本質はIAM・デバイス・通信・監視の統合。一部だけではNG
社内PCだから信頼していい → ゼロトラストは社内PCもデバイス証明書・状態検証で毎回確認します。特別扱いしない
ゼロトラストは新技術 → 思想は2010年から存在。クラウド普及で必要性が顕在化しただけ

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

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

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

最終的な判断の仕方

ゼロトラストの核心は製品名ではなく思想であり、Okta + Cloudflareを買えば実現する話ではありません。守るべき境界線がクラウド・SaaS・リモートワークで物理的に引けなくなった時代、「何も信用せず、常に検証する」という設計原則を組織全体で貫くことが本体です。導入は一夜ではなく数年がかりで、IAM強化 → デバイス管理 → ZTNA → マイクロセグメント → 継続的監視という段階的なロードマップを踏みます。最初のステップをIAM + MFAに置くのが合理的な判断で、ここを疎かにしたままZTNAだけ入れても効果は出ません。

もう一つの決定的な軸は人間とAIエージェントを同列に扱うことです。AIは人間より速く大量に操作するため、1回の認可を信頼する境界型発想は完全に破綻します。エージェント別IDで毎アクション認可チェックし、短命トークン・自動失効を徹底するのが、AI時代のゼロトラスト設計の形です。

選定の優先順位

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

「何も信用せず、常に検証する」人間も機械も同じ基準で、段階的に組織変革します。

まとめ

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

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

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

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

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