第7章: Zero Trust アーキテクチャと現代の認可設計

境界防御の崩壊 — 「内側は信頼する」モデルの終焉

2000年代まで、エンタープライズセキュリティの主流はパラメーター防御（境界防御）でした。 企業ネットワークをファイアウォールで囲い、「外部は危険・内部は安全」という前提のもと、 内側に一度入ったユーザーやデバイスには広範な信頼を付与するモデルです。 VPN接続さえ成功すれば社内システムへのアクセスが大幅に緩和される、という設計がその典型です。

この前提は、現代のIT環境においてことごとく崩れています。 攻撃者は標的型メールや脆弱なサプライチェーンを通じてネットワーク内部への侵入に成功し、 内部の信頼を悪用して横展開（Lateral Movement）を行います。 2020年のSolarWindsサプライチェーン攻撃はその象徴的な事例です。 正規のソフトウェアアップデートを経由してネットワーク内部に侵入した攻撃者は、 内部の「信頼」を利用して数か月にわたり検知されずに活動を続けました。

同時期、クラウド移行とリモートワークの急拡大が境界防御の前提をさらに揺るがします。 業務アプリケーションの大半はパブリッククラウドに移行し、 従業員は世界中の多様なネットワークから接続します。 「守るべき境界」はもはや定義できない状態になりました。

ZTAの本質 — 「Never Trust, Always Verify」

Zero Trust の概念は2010年にForrester ResearchのJohn Kindervagが提唱しました。 その核心は「Never Trust, Always Verify（決して信頼せず、常に検証する）」という一文に集約されます。 ネットワーク位置に関わらず、すべてのリクエストを毎回検証するというアプローチです。

2020年8月、NIST（米国国立標準技術研究所）は NIST SP 800-207「Zero Trust Architecture」 を公開し、 ZTAの定義・原則・アーキテクチャを正式に標準化しました。 NISTによる定義は「企業のリソース・アカウントに対して暗黙の信頼を与えない」という点を核心としています。 従来モデルが「まず信頼し、疑わしければ検証する」であったのに対し、 ZTAは「まず検証し、アクセスを最小限に許可する」という原則を採用します。

2023年には NIST SP 800-207A「A Zero Trust Architecture Model for Access Control in Cloud-Native Systems」 が追加され、 マルチクラウド環境でのZTA実装においてABACベースのポリシー決定ポイント（PDP）を推奨実装として明示しました。

NIST SP 800-207の7つの原則

NIST SP 800-207はZTAの基盤となる7つの原則（Tenets）を定義しています。 これらはZTA実装における「達成すべき状態」を記述したものです。

ZTAの三層コアアーキテクチャ

NIST SP 800-207はZTAの制御構造をControl PlaneとData Planeに分離した三層モデルで定義しています。 この分離は第5章で解説したXACMLアーキテクチャ（PEP/PDP/PAP/PIP）と本質的に同じ設計思想を継承しています。

graph TB
  subgraph CP[Control Plane]
    PE[Policy Engine PE]
    PA[Policy Administrator PA]
  end
  subgraph DP[Data Plane]
    PEP[Policy Enforcement Point PEP]
    RES[保護対象リソース]
  end
  subgraph SIG[シグナル入力]
    ID[アイデンティティとクレデンシャル]
    DEV[デバイス状態]
    LOC[場所と時間]
    THR[脅威インテリジェンス]
  end
  ID --> PE
  DEV --> PE
  LOC --> PE
  THR --> PE
  PE -->|許可 or 拒否| PA
  PA -->|セッション作成 or 終了| PEP
  PEP -->|アクセス可| RES
  style CP fill:#1e1b4b,stroke:#6d28d9,color:#c4b5fd
  style DP fill:#1c1917,stroke:#78716c,color:#d6d3d1
  style SIG fill:#052e16,stroke:#16a34a,color:#86efac

Policy Engine（PE）— 許可・拒否の意思決定者

Policy Engine（PE）はZTAの頭脳です。 複数のシグナルソースから入力を受け取り、ポリシーに照らして「このリクエストを許可するか否か」を決定します。

入力となるシグナルには多様な情報が含まれます。アイデンティティとクレデンシャル（ユーザーIDプロバイダー・多要素認証の結果・証明書）、デバイス状態（OSバージョン・パッチ適用状況・MDMコンプライアンス・EDRの評価）、場所と時間（IPアドレス・地理位置情報・業務時間内かどうか）、脅威インテリジェンス（既知の悪意あるIPリスト・振る舞い分析結果）が代表的なシグナルです。

NISTはPEを3つの動作モードで定義しています。 組織が信頼するクラウドサービスのみ利用するホワイトリストモード、 アクセス要求をAIが評価してリスクスコアを算出するリスクスコアリングモード、 そして組織内部システムで完全制御するオンプレミスモードです。 多くの大企業の実装では、これらをシステムの機密度に応じて組み合わせます。

Policy Administrator（PA）— セッション制御の実行者

Policy Administrator（PA）はPEの決定を受け取り、実際のセッション制御を実行します。 PEが「許可」を決定した場合、PAはセッションの作成・認証トークンの発行・一時的クレデンシャルの生成を行います。 PEが「拒否」を決定した場合、あるいはセッション中にシグナルが変化してリスクが高まった場合は、 PAが既存セッションを終了させます。

この「セッション中の動的な判断」がZTAの本質的な特徴です。 従来モデルでは認証成功時のみ権限チェックが行われましたが、 ZTAのPAはセッション継続中もシグナルを監視し、 デバイスのコンプライアンス状態が変化した瞬間にアクセスを自動失効させます。

PEP（Policy Enforcement Point）— リソース境界での強制

PEP（Policy Enforcement Point）はData Planeに位置し、 実際のリソースアクセスを物理的に制御するコンポーネントです。 PAからの命令を受けてセッションを有効化・無効化し、 保護対象リソースへの通信を制御します。

PEPの実装形態はリソースの種類によって異なります。 Webアプリケーションの場合はAPIゲートウェイやリバースプロキシ、 ネットワークリソースの場合はマイクロセグメンテーションソフトウェア、 データベースの場合はデータベースプロキシや接続ポリシーエンジンとして実装されます。 重要な点として、PEPはポリシーを「評価しない」——評価はPEが行い、PEPはその決定を「執行する」だけです。

ABACとZTAの統合 — なぜRBACでは不十分か

ZTAのPolicy Engineは実質的にABACエンジンです。 では、第4章で解説したRBACではなぜZTAの要件を満たせないのでしょうか。

RBACの根本的な制約は「ロールが静的」であることにあります。 ロール付与はセッション開始前に行われ、セッション中にデバイスが侵害されても ロールは失効しません。 一方、ZTAのPolicy EngineはABACエンジンとして機能することで、 「業務時間内かつデバイスコンプライアンス適合かつMFA完了済み」という多次元条件を リアルタイムで評価し続けます。

実績として、AT-ZTACモデル（ABAC with Time-context ZTA Control）は 1,850 req/sのスループットを達成し、従来ABACと比べて54%向上、精度96.8%という結果が MDPIの2025年の研究で報告されています。 これはABACエンジンをZTAアーキテクチャに最適化することで、 性能と精度の両立が実現できることを示しています。

JITアクセスとPAM — 最小権限の動的実現

ZTAの原則3「セッション単位での最小権限付与」を実装する具体的な手段が、JIT（Just-In-Time）アクセスとPAM（Privileged Access Management）です。

JITアクセスの3フェーズパターン

JITアクセスは特権権限の「平常時ゼロ・要求時付与・タイムアウト後自動失効」という ライフサイクルを管理するパターンです。

graph LR
  A[平常時: 標準権限のみ] -->|昇格リクエスト + 承認| B[昇格中: 管理者権限 時間制限付き]
  B -->|タイムアウト or 手動失効| C[復帰: 標準権限に自動降格]
  C --> A
  style A fill:#1e3a5f,stroke:#3b82f6,color:#bfdbfe
  style B fill:#4c1d1d,stroke:#dc2626,color:#fecaca
  style C fill:#1e3a5f,stroke:#3b82f6,color:#bfdbfe

平常時、エンジニアは本番環境のデータベースへの管理者アクセスを持ちません。 インシデント対応が必要な場合、JITシステムに「本番DB管理者権限・理由：インシデント#1234・期間：2時間」 という形で昇格リクエストを送ります。 上長承認後、PAMシステムが2時間限定のセッションを作成します。 2時間経過後、またはエンジニアが手動で終了した時点で権限は即座に失効します。 すべての操作はセッション記録（Session Recording）として保存され、監査証跡となります。

PAM（特権アクセス管理）ソリューション

CyberArkとDelinea（旧Thycotic）は、 エンタープライズPAM市場をリードする二大ベンダーです。 いずれも特権認証情報の安全な保管（Vault）、JITアクセスの実装、 セッション記録と監査を中核機能として提供します。

Gartnerの分析によると、クラウドアイデンティティの90%が過剰権限の状態にあります。 これは「取り敢えず付与した権限を削除し忘れる」Permission Creep（権限の肥大化）が 長期運用の中で構造的に発生するためです。 JITアクセスはPermission Creepに対する最も効果的な対策であり、 「そもそも常時権限を持たせない」設計でCreepの発生源を排除します。

Entitlement Decay — 権限の自動失効

Entitlement Decay（権限減衰）はZTAのセッション継続監視を実装する概念です。 セッション開始時には問題なかったデバイスのコンプライアンス状態が、 セッション継続中に変化した場合（例：ウイルス定義ファイルが古くなった・MDMエージェントが停止した）、 PAがリアルタイムでPEPに通知し、進行中のセッションへの権限を段階的または即時に失効させます。

さらに、Analytics-Driven自動化が実際のアクセスログを分析することで、 過去90日間一度も使用されなかった権限を特定し、削除を推奨するという手法も 現代のIAM（Identity and Access Management）ソリューションに組み込まれています。 これにより、JITアクセスと組み合わせて「付与する権限の最小化」と「使われない権限の継続的削除」 の両輪で最小権限原則を維持します。

実装アーキテクチャ — ハイブリッド構成の設計

ZTAは理念的には「すべてをゼロから再設計する」アーキテクチャですが、 現実の企業システムはレガシーと新規の混在環境です。 ここでは実践的な4層ハイブリッド構成と、ZTA特有の実装課題を解説します。

4層ハイブリッド構成の推奨設計

アクセス制御モデルは一律に選択するのではなく、 リソースの特性ごとに最適なモデルを組み合わせる設計が現実的です。

BLS閾値署名による単一障害点の排除

Policy AdministratorがPEPへ送る制御命令は、 PAが侵害された場合に攻撃者によって悪用されるリスクがあります。 この単一障害点を排除するために、BLS閾値署名スキーム（BLS Threshold Signature）を 採用する設計が研究されています。

閾値署名では、署名鍵をN個のノードに分散し、うちK個以上が合意した場合のみ 有効な署名が生成されます（K-of-N署名）。 PAの命令に閾値署名を適用することで、単一ノードの侵害では命令の偽造が不可能になります。 この方式は、ZTAの「暗黙の信頼を与えない」原則をアーキテクチャコンポーネント自体にも適用する考え方です。

短期トークンとIdentity Broker

ZTAの「セッション単位の認可」を実装する際、長期有効なAPIキーや永続的なクレデンシャルは 根本的にZTAの原則に反します。 推奨アプローチは短期トークン（Short-Lived Token）の活用です。 例として、AWSのSTS（Security Token Service）は最短15分・最長12時間のアクセストークンを発行します。 長期クレデンシャルを持つサービスアカウントをIdentity Brokerに登録し、 アプリケーションはBrokerから都度短期トークンを取得する設計が マルチクラウド環境でのZTA実装の標準パターンとなっています。