本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「セキュリティアーキテクチャ」カテゴリ第6弾として、ゼロトラストについて解説する記事です。
「Never Trust, Always Verify（何も信用せず常に検証する）」というセキュリティ思想で、Google BeyondCorpが原型です。本記事ではゼロトラスト5原則、ZTNA／SASE／マイクロセグメンテーション／継続的監視の構成要素、段階的導入ロードマップ、AI時代に人間とAIエージェントを同列に扱う新常識を解説します。
本記事のテーマについてさらに詳しく知りたい方は『セキュア・バイ・デザイン』も参考にしてみてください。
この記事の結論
- IAM+MFAから段階導入する（一気に全部やらない）
- VPNはZTNAで置き換える
- セッション中も継続検証し、AIエージェントも人間と同列に扱う
この記事を読む前に
本記事は認証・認可・暗号化といったセキュリティ用語が多めに登場します。IT用語にあまり馴染みがない方は、基礎編の「セキュリティと認証の基本」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもゼロトラストとは何か
空港のセキュリティを思い浮かべてください。乗客全員が──航空会社の社員であっても──手荷物検査を受け、パスポートを確認され、搭乗ゲートで再び本人確認されます。「関係者だから顔パスでOK」という仕組みは存在しません。
ゼロトラストはこれと同じ発想です。社内ネットワークにいるからといって無条件に信頼せず、すべてのアクセスを毎回検証するセキュリティモデルです。ユーザーが誰か・端末は安全か・場所は正当か・時間帯はおかしくないか──こうした文脈情報を総合的に評価し、アクセスのたびに許可・拒否を判定します。
もしゼロトラストがなければ、一度社内ネットワークに侵入した攻撃者はどこへでも自由に移動できてしまいます。実際に多くの大規模情報漏洩事件は、最初の侵入口は小さくても、内部で横展開されて被害が拡大しています。
なぜ必要か ― お城と堀では、もう戦えない
従来の「境界型」（Perimeter-based）セキュリティは「社内LANは安全、VPNの内側は信頼」という前提でした。しかしこの前提は3つの現実によって崩壊しています。
第一に、境界が消滅しました。社員はリモートワーク、データはSaaS、サーバーはクラウド──もはや「社内」という概念が存在せず、守るべき境界線が物理的に引けません。第二に、内部脅威と横展開攻撃です。攻撃者は1台のPCを突破すれば社内LAN内で横展開（Lateral Movement）できてしまうため、境界突破後の被害拡大を防ぐには内部も信頼しない設計が必須です。第三に、Salesforce・Slack・GitHub・AWSと全てが外部にあるため、全通信が社外を経由し、境界防御そのものが機能しません。
なおゼロトラストは製品名ではなく思想です。何かを導入すれば終わりではなく、全社的な設計変更です。
ゼロトラストの5原則と境界型との違い
NIST SP 800-207で定義された基本原則は、①全リソース（データ・デバイス・ユーザー）を保護対象とする、②全通信を暗号化・認証する（内部通信でもmTLS）、③セッション単位でアクセスを判断し継続検証する、④コンテキスト（場所・時間・端末）で動的にポリシーを適用する、⑤全アクセスを監視・ログ化する──の5つです。これらを貫けば自動的にゼロトラストになる、というガイドラインです。
境界型との違いは次の1枚に集約されます。
| 境界型（従来） | ゼロトラスト | |
|---|---|---|
| 信頼の基準 | ネットワーク位置 | 認証・コンテキスト |
| 検証頻度 | 入口で1回 | 毎リクエスト |
| 内部通信 | 暗号化不要 | 必ず暗号化 |
| VPN | 中心的 | 不要（ZTNAへ） |
| アクセス単位 | ネットワーク | アプリ・リソース単位 |
境界型は「お城+堀」、ゼロトラストは誰が来ても一人ずつ身分証チェックに例えられます。
主要構成要素
ID・認証 ― すべての土台
ゼロトラストの核は強固な認証・認可基盤です。本人確認が曖昧なら、いくら通信を検証しても意味がありません。IdP（Okta・Microsoft Entra ID）による中央ID管理、MFA必須化（FIDO2推奨）、デバイス認証（管理外端末の拒否）、場所・時間・端末で判断する条件付きアクセス、セッション中も再検証する継続的認証──これらが土台になります。詳細は認証・認可とIAM設計の記事を参照してください。
ZTNA ― VPNの後継
ZTNAはVPNの代替となるアプリ単位アクセスの仕組みです。VPNはネットワーク全体に接続させますが、ZTNAは「このユーザーはこのアプリだけに接続可」と個別に制御するため、突破時の横展開を根本的に防げます。主役は手軽でCloudflare統合のCloudflare Accessと、WireGuardベースでシンプルなTailscale。その他、エンタープライズ向けのZscaler Private Access、開発者向けのTwingate等があります。設定はVPNより簡単でユーザー体験も良好なため、新規構築ならVPNよりZTNAが第一候補です。
SASE ― ネットワーク+セキュリティの統合
SASEは、ZTNA・SWG（Web経由の脅威フィルタ）・CASB（SaaS利用の可視化・制御）・FWaaS（クラウド型ファイアウォール）・DLP（機密データ流出防止）を1つのクラウドプラットフォームで提供する統合形態です。代表サービスはZscaler・Cloudflare One・Palo Alto Prisma・Netskope。SaaS中心・クラウドファーストの組織には、SASE導入がゼロトラスト化の最短ルートになります。
マイクロセグメンテーションと継続的監視
ネットワークを細かく区切り、サービス間通信を最小化する設計です。Service Mesh（Istio・Linkerd）を使えばマイクロサービス間の通信を全てmTLSで相互認証でき、1サービスが侵害されても他への横展開を防げます。
そしてゼロトラストは1回検証して終わりではありません。SIEM（ログ統合・相関分析）・UEBA（行動分析・異常検知）・SOAR（対応自動化）でセッション中も監視し続けます。「平日17時にログイン→深夜3時に海外IP」のような異常をUEBAで自動検知し、権限を一時停止する──ここまで揃って初めて5原則が満たされます。
GoogleのBeyondCorp
ゼロトラストの実装例として最も有名なのがGoogleのBeyondCorpです。2009年の中国からの攻撃（Operation Aurora）をきっかけに、VPNを全廃し、全社員を外部扱いする大胆な設計に踏み切りました。デバイス証明書を持つ管理端末のみ許可し、場所・端末状態のコンテキストで判断し、アプリ単位でアクセス制御する──Google社員はどこからでも同じ方法で業務アプリに接続でき、「社内LANへの接続という概念がGoogleには存在しない」状態です。
導入の現実的ロードマップ
ゼロトラストは一夜で実現できない組織変革です。いきなり全社展開すると業務が止まるため、数年がかりで段階的に導入します。
| フェーズ | 期間目安 | 実装内容 | 効果 |
|---|---|---|---|
| Phase 1: IAM基盤 | 〜6ヶ月 | IdP導入（Okta / Entra ID）+ MFA必須化 | なりすまし対策の土台 |
| Phase 2: デバイス管理 | 〜1年 | MDM（Jamf / Intune）+ デバイス証明書 | 管理外端末の遮断 |
| Phase 3: ZTNA | 〜1.5年 | VPN → ZTNA段階移行 | アプリ単位アクセス制御 |
| Phase 4: マイクロセグメント | 〜2年 | Service Mesh + mTLS全通信 | 横展開攻撃の遮断 |
| Phase 5: 継続監視 | 〜3年 | SIEM + UEBA + SOAR | 異常行動の自動検知・対応 |
「最初のステップはIAM+MFA強化」です。Phase 1を疎かにしたままZTNAだけ入れても効果はゼロ──なりすまされたら全て無意味になります。最初の土台に6ヶ月〜1年を投資するのが、ゼロトラスト全体の成否を決めます。
3つのシナリオで考える
個人開発・スタートアップの場合
Google WorkspaceとCloudflare Zero Trustの無料枠で始めましょう。VPNは最初から導入せずに、社内ツールへのアクセスはCloudflare Accessで保護します。会社支給の端末はMDMで管理して、個人端末からの業務アクセスは禁止です。全社員分でも月数万円に収まってしまいますし、実はこれだけで境界型の中堅企業より強い防御になってしまうのです。
中小SaaS企業の場合
OktaにCloudflare One（SASE）、JamfやIntuneを組み合わせるのが定番構成です。SSOで全てのSaaSを一元管理して、SASEでWeb通信を全てクラウド経由にすればDLPやフィルタを一括適用できます。既存のVPNについては、新規アプリからZTNAへ段階的に置き換えて廃止していく形が現実的でしょう。
大企業の場合
Entra IDにZscaler、SIEM（SentinelやSplunk）という構成になります。既存のVPNを一気に止めると業務が停止してしまいますので、新規アプリはZTNA・既存はVPNの並行運用で、3〜5年計画の置き換えになると思います。金融・医療・政府系ではNIST SP 800-207準拠の全要素実装に加えて、UEBAやSOARによる「継続的監視」と24/7 SOCへの投資が最重要です。
AI判断軸 ― AIエージェントも「検証対象」に含める
AIエージェントをゼロトラストの対象に含める設計
AIエージェントは人間のユーザーと同じくゼロトラストの対象として扱う必要があります。エージェントがDBにアクセスする場合、毎回認証・認可を通し、操作内容を監査ログに記録し、異常なパターン（大量のSELECT・通常と異なるテーブルへのアクセス）を検知した時点で即座にトークンを失効させる設計が求められます。
従来の「サービスアカウントに強い権限を付けて放置」する設計では、プロンプトインジェクション等でAIエージェントが乗っ取られた場合の被害が甚大になります。エージェント別のID・毎アクション認可・短命トークンで、操作範囲を最小化し異常時に即停止できる仕組みが前提です。
継続的検証とAI異常検知の組み合わせ
ゼロトラストの「継続的検証」は、セッション確立後も常にユーザー / エージェントの振る舞いを監視し続ける仕組みです。UEBAをAIで実装すれば、「通常9時〜18時にしかログインしないユーザーが深夜3時にアクセスしている」「通常100件/分のAPI呼び出しのエージェントが10,000件/分に急増した」といった異常を自動検知できます。検知後の対応（トークン失効・アクセス遮断・管理者通知）まで自動化すれば、人間のオンコール対応を待たずに被害を最小化できます。
やってはいけないこと
ゼロトラスト導入で事故る典型を、特に危険な6つに絞ります。どれも「製品を買えば解決」と誤解している構造を持ちます。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| 製品を買えばゼロトラストになると誤解 | 思想・設計・運用が本体 → 経営・人事・インフラ・開発を巻き込んだ全社変革として推進する |
| IAM + MFAを後回しにしてZTNAだけ導入 | なりすまされたら全て無意味 → Phase 1（IdP + MFA）から順に積む |
| VPNを一気に廃止してZTNAへ移行 | 既存アプリで業務停止 → 新規ZTNA + 既存VPNの並行運用で段階移行する |
| デバイス検証なしで個人端末からの業務アクセスを許可 | マルウェア感染端末が直結する → MDM + デバイス証明書を必須にする |
| 内部通信を平文のまま運用 | 横展開攻撃で一気に全サービス掌握 → Service MeshでmTLS全通信化する |
| 退職者・異動者の権限を即座に停止しない | 2020年Twitter内部ツール侵害のパターン → IdP中央管理で入退社と権限を連動させる |
筆者メモ — 「信頼できる経路」こそが最大の攻撃面だった事例
2020年12月に発覚したSolarWinds事件（Sunburst攻撃）では、信頼されていた監視ソフトの更新ファイルに攻撃コードが仕込まれ、米国政府機関を含む約1万8千組織の社内に正規ルートで侵入を許しました。同じく2020年のTwitter内部ツール侵害では、スピアフィッシングで従業員の認証情報が盗まれ、Obama・Biden・Elon Muskら著名アカウントが乗っ取られました。「社内ツールは社内の人間しか触らない」という暗黙の信頼が、実はMFAもデバイス検証もない状態で支えられていた実態が浮き彫りになった事件です（詳細は付録「重大インシデント事例集」）。
筆者も前職で、VPNの設定だけで「中は安全」と信じ込んでいた結果、退職者のアカウントが半年近く有効なまま放置され、本人が悪意なく開発環境に繋いでしまった、というヒヤリハットを横目で見たことがあります。どれも信頼された経路が突かれた事例で、Googleが2009年以降BeyondCorpでVPN全廃に踏み切った判断の正しさを裏付けました。「誰が・どの端末で・今繋いでいるか」を常に問い直す発想が、ゼロトラストの核です。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- IdPの選定（Okta / Entra ID / Google Workspace）
- MFA必須化の範囲（全社 / 管理職のみ）
- デバイス管理（MDM、Jamf・Intune等）
- ZTNAサービス（Cloudflare Access等）
- SASE導入の要否（全社SASE化か段階か）
- マイクロセグメンテーション（Service Mesh等）
- SIEM・UEBAの採用（継続的監視）
こうした決定はADR（アーキテクチャ決定記録）として残しておくと、後からの見直しに効きます。
この記事に関連する記事
まとめ
本記事はゼロトラストについて、NIST SP 800-207の5原則・ZTNA・SASE・マイクロセグメンテーション・継続監視・段階的ロードマップ・AI時代に人間と機械を同列に扱う設計まで含めて解説しました。如何だったでしょうか。
IAM+MFAから段階導入し、ZTNAでVPN代替、継続監視+UEBAでセッション中も検証、AIエージェントも同列に扱う。これが2026年のゼロトラストの現実解です。
次回は秘密情報管理（API Key・パスワード・証明書の保管）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は Google BeyondCorp も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（57/95）