ゼロトラストアーキテクチャの基礎：原則・構成要素・導入アプローチ

はじめに

従来のネットワークセキュリティは、ファイアウォールやVPNで企業ネットワークの「境界」を守る境界防御モデルに基づいていました。しかし、クラウドの普及、リモートワークの拡大、BYODの浸透により、信頼できる「内側」と信頼できない「外側」の境界線は曖昧になっています。

**ゼロトラストアーキテクチャ（Zero Trust Architecture, ZTA）**は、「決して信頼せず、常に検証する（Never trust, always verify）」を原則とするセキュリティモデルです。

ゼロトラストの歴史

境界防御モデルの構造的な欠陥

なぜ「決して信頼せず、常に検証する」という設計思想がここまで重視されるのか。境界防御モデルの限界を、攻撃者の視点から追うと論理的な必然性が見えてきます。

「城と堀」モデルの暗黙の前提

境界防御は**「城と堀（Castle-and-Moat）」モデル**に喩えられます。ファイアウォールとVPNが堀の役割を果たし、認証を一度パスして城内（社内LAN）に入った通信は、以後どのリソースにアクセスする際も暗黙的に信頼されます。この設計には、次の2つの前提が埋め込まれています。

1. 信頼の基準はネットワークの場所である（境界の外は敵、内は味方）
2. 認証は入口で一度行えば十分であり、そのセッションの間は信頼し続けてよい

侵入後に何が起きるか

この前提が崩れたときの被害は一気に拡大します。典型的な侵害の連鎖は次のように進みます。

1. 初期侵害: フィッシングメールで従業員の1台の端末にマルウェアを送り込む、あるいは漏洩したVPN認証情報でリモートアクセスする
2. 内部探索: 境界内は「信頼されたネットワーク」であるため、内部向けのポートスキャンやActive Directoryへの問い合わせがほとんど検知されずに実行できる
3. 横移動・認証情報窃取: 内部のファイル共有やリモートデスクトップ（RDP/SMB）経由で他端末へ移動し、キャッシュされた認証情報を窃取する
4. 目的達成: ドメイン管理者権限を奪取し、機密データへのアクセスやランサムウェア展開を行う

境界防御モデルの構造的な欠陥は、ステップ1さえ突破すればステップ2以降がほぼ無検証で進んでしまう点にあります。VPNは「全社ネットワークへの一括トンネル」であることが多く、認可の粒度がネットワーク単位までしかありません。一度VPN接続が確立すると、それが正規ユーザーによるものか、窃取した認証情報を使う攻撃者によるものかを、個々のリソースへのアクセスのたびに区別する仕組みが存在しないのです。

ゼロトラストが解決する論理

後述するNIST SP 800-207の7原則は、この攻撃連鎖の各ステップを個別に潰す設計になっています。

• 原則2（すべての通信を保護）と原則6（アクセス前の厳密な認証・認可）は、ステップ2の「内部だから無検証」という前提そのものを破壊します。社内LANであっても通信は暗号化され、リソースごとに認証を要求するため、境界内に侵入しても素通りできる区間が存在しません。
• 原則3（セッション単位のアクセス許可）と原則4（動的ポリシー）は、ステップ3の「一度の認証情報窃取で複数リソースに横移動する」ことを防ぎます。認可はリソースごと・セッションごとに再評価されるため、ある端末で窃取した認証情報が有効でも、デバイスの健全性スコアが低ければ他のリソースへのアクセスは拒否されます。
• 原則5（整合性の継続的監視）は、侵害された端末が信頼スコアの低下を通じて自動的に隔離される経路を提供します。

つまりゼロトラストは、境界防御が抱える「入口さえ破られれば内部は丸裸になる」という単一障害点を、認可判断をリソース単位・セッション単位に分散させることで構造的に解消しています。マイクロセグメンテーションが横移動を機能的に防ぐのも同じ論理の帰結であり、動的ポリシーは「一度成功した侵害が持続する時間」を最小化します。

基本原則（NIST SP 800-207）

NIST SP 800-207では、ゼロトラストの7つの基本原則が定義されています。

1. すべてのデータソースとコンピューティングサービスはリソースとみなす

   • 個人所有デバイスも企業リソースにアクセスする場合はリソースとして管理

2. ネットワークの場所に関係なく、すべての通信を保護する

   • 社内LANでも通信は暗号化し、認証を要求する

3. 個々のリソースへのアクセスはセッション単位で許可する

   • 一度の認証で永続的なアクセスを与えない

4. リソースへのアクセスは動的なポリシーで決定する

   • ユーザーID、デバイス状態、場所、時間、行動パターン等を総合的に判断

5. すべての資産の整合性とセキュリティ態勢を監視・測定する

   • パッチ未適用、構成不備のデバイスは信頼度を下げる

6. リソースの認証と認可はアクセス前に厳密に実施する

   • 認証は多要素（MFA）、認可は最小権限の原則

7. 収集したデータを継続的に活用してセキュリティ態勢を改善する

   • ログ分析、異常検知、ポリシー最適化のサイクルを回す

主要コンポーネント

論理アーキテクチャ

ユーザー/デバイス
    ↓
[Policy Enforcement Point (PEP)]  ← アクセスの制御点
    ↓
[Policy Administrator (PA)]       ← 接続の確立/終了
    ↓
[Policy Engine (PE)]              ← アクセス判断の頭脳
    ↑
  ┌─────────────────┐
  │ データソース      │
  │ ・Identity Provider (IdP) │
  │ ・SIEM / ログ分析        │
  │ ・脅威インテリジェンス     │
  │ ・デバイス管理 (MDM)      │
  │ ・コンプライアンスDB      │
  └─────────────────┘

検証：Policy Engineの認可判断をOpen Policy Agentで実際にシミュレーションする

Policy Engine (PE) は、「ユーザーの認証状態」「デバイスの健全性」「要求されたリソースへの権限」「コンテキスト（時刻・場所等）」を総合し、動的にアクセス可否を判断します。この判断ロジックを、実際に業界で広く使われている認可エンジンOpen Policy Agent (OPA) のポリシー言語Regoで実装し、複数の入力パターンに対する許可/拒否の判断を実際に実行して確認しました。

package zerotrust.authz

import rego.v1

default allow := false

# PEPがPolicy Engineに問い合わせる認可判断:
# 「ユーザーが認証済み」かつ「デバイスが健全」かつ
# 「最小権限のロールがリソースを許可」かつ「アクセス時刻・場所が正常」の
# すべてを満たした場合のみ allow = true（常に検証・最小権限の原則）
allow if {
	input.user.authenticated == true
	input.user.mfa_verified == true
	device_compliant
	role_permits_resource
	within_business_hours
}

device_compliant if {
	input.device.os_patch_level == "current"
	input.device.edr_healthy == true
	input.device.managed == true
}

role_permits_resource if {
	some role in input.user.roles
	permission := data.role_permissions[role]
	input.resource in permission.allowed_resources
}

within_business_hours if {
	input.context.hour_utc >= 0
	input.context.hour_utc < 24
	not input.context.is_anomalous_location
}

# 拒否理由をPEPに返し、監査ログ・ユーザーへのフィードバックに使う
deny_reasons contains "device_not_compliant" if not device_compliant
deny_reasons contains "role_denied" if not role_permits_resource
deny_reasons contains "anomalous_context" if not within_business_hours

このポリシーに対して、opa eval（OPA CLI）で4つのシナリオを実行しました。

実行結果（opa eval --format pretty -d policy.rego -d data.json -i inputN.json 'data.zerotrust.authz.allow'）は次の通りで、いずれも設計通りの判断が得られました。

=== input1_allow ===       => true,  deny_reasons: []
=== input2_device_fail ===  => false, deny_reasons: ["device_not_compliant"]
=== input3_role_fail ===    => false, deny_reasons: ["role_denied"]
=== input4_anomalous ===    => false, deny_reasons: ["anomalous_context"]

この結果は、NIST SP 800-207の原則4（動的ポリシーによるアクセス判断）と原則6（アクセス前の厳密な認証・認可）が、実装レベルでは「複数シグナルの単一のANDルール」ではなく、認証・デバイス健全性・権限・コンテキストという独立した検証項目の組み合わせとして実装されることを示しています。シナリオ2〜4はいずれも「MFA検証は済み」、つまり認証情報そのものは正しいにもかかわらず拒否されている点に注目してください。境界防御モデルであれば、正しい認証情報を持つ通信は（VPN接続後は）他のリソースにもそのままアクセスできてしまいますが、ゼロトラストでは1項目でも条件を満たさなければ、他の全項目が正常でも通信は拒否されます。これが、前章で述べた「認証情報の窃取だけでは横移動が成立しない」という構造の実装レベルでの裏付けです。

境界防御モデルとの比較

CISAゼロトラスト成熟度モデル（ZTMM v2.0）

NIST SP 800-207が「何を満たすべきか」という原則を定義するのに対し、米国CISA（Cybersecurity and Infrastructure Security Agency）が2023年4月に公開した**Zero Trust Maturity Model version 2.0 (ZTMM)**は、「組織が現在どの段階にあり、次に何をすべきか」を測定するための実務的な評価軸を提供します。

ZTMM v2.0は、初版（2021年、3段階）からInitial段階を新設して4段階に拡張されました。これは「手動・サイロ化された管理」から「完全自動化」までの間に、実務上大きなギャップがあったためです。

• Traditional: 手動での設定・ライフサイクル管理、静的なセキュリティポリシー、暗黙的な信頼
• Initial: 一部の自動化とクロスピラー間の連携が始まる段階。動的ポリシーの部分導入
• Advanced: 自動化された制御、統合された可視性、リアルタイムシグナルに基づくポリシー適用
• Optimal: 完全自動化された動的ポリシー執行、継続的な検証、静的な信頼がほぼゼロ

評価の対象となる5本柱は、Identity（ID）・Devices（デバイス）・Networks（ネットワーク）・Applications and Workloads（アプリケーション/ワークロード）・Data（データ）です。これらを横断する形で**Visibility & Analytics（可視化・分析）・Automation & Orchestration（自動化・オーケストレーション）・Governance（ガバナンス）**の3つの機能が全体を下支えします。

下図は、各柱における4段階の代表的な特徴をまとめたものです（CISA ZTMM v2.0, April 2023の記述を要約）。

例えばNetworks（ネットワーク）の柱では、Traditional段階の「大きな境界によるマクロセグメンテーション」から、Advanced段階の「Ingress/Egressのマイクロ境界の拡大」を経て、Optimal段階では「アプリケーションプロファイル単位の動的なマイクロセグメンテーションとJust-in-Time/Just-Enough-Access (JIT/JEA) 接続」に到達します。これはまさに前章で述べた「横移動を構造的に防ぐ」ための具体的な到達点です。

多くの組織は5本柱すべてで同じ段階にあるわけではなく、例えば「Identityは Advanced だが Data は Traditional のまま」というように柱ごとに凸凹の成熟度を持つのが実情です。ZTMMはこの凸凹を可視化し、投資の優先順位付け（最も遅れている柱から着手する）に使うためのツールとして設計されています。

導入アプローチ

アイデンティティ中心型

ID管理と多要素認証を強化し、ユーザーとデバイスの信頼度に基づくアクセス制御を実現します。

• SSO + MFA の全面導入
• コンテキスト認証（デバイス、場所、時間、リスクスコア）
• Just-in-Time（JIT）アクセス

ネットワーク中心型

マイクロセグメンテーションにより、ネットワークを細かく分割してラテラルムーブメント（横移動）を防ぎます。

• VLAN / ファイアウォールルールの細分化
• ソフトウェア定義ネットワーク（SDN）
• 東西トラフィックの検査

ソフトウェア定義境界（SDP）

アプリケーション単位でアクセスを制御し、ネットワーク自体を隠蔽します。認証されるまでリソースの存在すら見えません。

段階的な導入計画

導入の課題（実務上の落とし穴）

レガシーシステムとの統合

古いシステムは最新の認証プロトコル（OAuth 2.0、SAML）に対応していない場合があります。プロキシやアダプタ層の導入が必要になることがあり、2025年にNIST NCCoEが公開した実装ガイド SP 1800-35（後述）でも、24社のベンダー製品を組み合わせた19種類の実例アーキテクチャの多くが、レガシー統合のためのゲートウェイ/アダプタ層を含んでいます。

認可判断のレイテンシ増大

境界防御モデルでは、一度VPN接続を確立すれば以後の通信は追加の認可オーバーヘッドをほとんど受けません。一方ゼロトラストでは、Policy Engineへの問い合わせがリソースへのアクセスのたびに発生し得ます。マイクロサービスが数十のサービス間呼び出しを行うアーキテクチャで、呼び出しの都度PEへ往復すると、チェーン全体のレイテンシが積み上がってしまいます。実務では、(1) 短いTTLでの認可判断のキャッシュ、(2) PEをリクエスト経路の近くにサイドカーとして配置する（後述のNIST SP 800-207Aが示すサービスメッシュ型の実装）、といった対策でオーバーヘッドを抑えます。ただしキャッシュのTTLを長くしすぎると、デバイスの状態変化（コンプライアンス違反への遷移等）が反映されるまでの遅延が生まれ、「常に検証する」という原則とのトレードオフになります。

過度に厳格なポリシーによる可用性低下

コンテキストベースの認可は、正当なユーザーであっても「普段と異なる場所からのアクセス」「時間外のアクセス」を機械的に拒否してしまうリスクがあります。前述のOPAシミュレーションのシナリオ4はまさにこのケースで、認証情報もデバイスも正常であるにもかかわらず、コンテキスト条件のみで拒否されました。過度に厳格なポリシーは、障害対応中のオンコールエンジニアや出張中の従業員の正当なアクセスまで遮断し、可用性を損ないます。緊急時に人手を介してポリシーを一時的に緩和するbreak-glass（緊急アクセス）手続きを、監査ログと組み合わせて用意しておくことが不可欠です。

Policy Engineという単一障害点

ゼロトラストは境界防御の単一障害点（境界の1点を破られると内部全体が危険にさらされる）を解消する一方、認可判断を集中させるPolicy Engine自体が新たな単一障害点になり得ます。PEが停止・過負荷に陥ると、原則6（アクセス前の厳密な認証・認可）を字義通り適用する実装では、フェイルセーフとして全アクセスを拒否することになり、業務が完全に停止しかねません。これを避けるには、PEの冗長化（複数リージョンへの分散配置）、直近の許可判断のキャッシュによるグレースフルデグラデーション、SLA監視が必要です。CISAのZTMMでも、Automation & Orchestrationの成熟度としてこうした可用性設計が評価対象に含まれています。

コストと複雑性

段階的に導入し、投資対効果の高い領域（特権アクセス管理、重要データ保護）から着手することが推奨されます。ZTMMの5本柱評価で最も遅れている柱を特定し、そこから着手するのも有効なアプローチです。

最新の標準動向（2023年以降）

ゼロトラスト関連の標準・ガイダンスは2023年以降も継続的に更新されています。

• CISA Zero Trust Maturity Model v2.0（2023年4月公開）: 前身の3段階モデルにInitial段階を追加し、現行の4段階・5本柱モデルを確立しました。
• NIST SP 800-207A（2023年9月13日に確定版公開）: “A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments”。マルチクラウド・ハイブリッド環境のマイクロサービスに対して、APIゲートウェイやサイドカープロキシ、SPIFFEによるサービスIDを用いたネットワーク層/アイデンティティ層の認可モデルを提示しており、本章で述べたレイテンシ対策（PEをサイドカーとして配置する）の具体的な実装指針を与えています。
• NIST SP 1800-35（2025年6月10日に確定版公開）: NCCoE（National Cybersecurity Center of Excellence）が24社のベンダーと協力し、19種類のゼロトラストアーキテクチャの実例を構築・検証した実装ガイドです。理論（SP 800-207）と実装のギャップを埋める実務者向け資料として位置づけられます。
• CISA “Journey to Zero Trust” マイクロセグメンテーションガイダンス Part One（2025年7月29日公開）: 連邦政府機関向けにマイクロセグメンテーションの計画・導入手順を解説する新シリーズの第1弾で、本記事の「境界防御モデルの構造的な欠陥」で述べた横移動対策の実務ガイドとなっています。

関連記事

• OAuth 2.0/OIDC入門 - ゼロトラストの認証基盤であるOAuth 2.0/OIDCプロトコルを解説しています。
• RSA暗号の原理とPython実装 - ゼロトラストにおける暗号技術の基礎であるRSA暗号を解説しています。
• 情報セキュリティ資格の比較と選び方 - ゼロトラスト関連の資格取得パスを紹介しています。
• CISSP：セキュリティガバナンスにおける主要フレームワークの比較 - セキュリティフレームワーク全体の中でのゼロトラストの位置づけを理解できます。
• 主要セキュリティモデルの比較 - Bell-LaPadula等のアクセス制御モデルとゼロトラストの関係を解説しています。
• メール認証の仕組み（SPF, DKIM, DMARC） - ゼロトラストの一環としてのメール認証技術を解説しています。
• Micro Hardening研修参加レポート - セキュリティ実践訓練の体験を紹介しています。

参考文献

• Rose, S., Borchert, O., Mitchell, S., & Connelly, S. (2020). NIST SP 800-207: Zero Trust Architecture . National Institute of Standards and Technology.
• Chandramouli, R., & Butcher, Z. (2023). NIST SP 800-207A: A Zero Trust Architecture Model for Access Control in Cloud-Native Applications in Multi-Cloud Environments . National Institute of Standards and Technology.
• NIST NCCoE (2025). SP 1800-35: Implementing a Zero Trust Architecture . National Institute of Standards and Technology.
• CISA (2023). Zero Trust Maturity Model, Version 2.0 . Cybersecurity and Infrastructure Security Agency.
• CISA (2025). Microsegmentation in Zero Trust, Part One: Introduction and Planning . Cybersecurity and Infrastructure Security Agency.
• Ward, R., & Beyer, B. (2014). “BeyondCorp: A New Approach to Enterprise Security”. ;login:, 39(6).
• Executive Order 14028 (2021). “Improving the Nation’s Cybersecurity”.
• Open Policy Agent. Rego Policy Language Documentation .