これまでの記事では、ゼロトラストの基本原則や個々の構成要素（アイデンティティ、デバイス、ネットワーク、データ保護など）について解説してきました。本記事では、これらの要素を統合し、組織全体のゼロトラストアーキテクチャ（ZTA）を設計する方法を解説します。
NIST SP 800-207「Zero Trust Architecture」は、ゼロトラストアーキテクチャ設計における事実上の標準となっています。本記事では、このガイドラインに基づき、以下の内容を解説します。
- ゼロトラストアーキテクチャの論理コンポーネントと役割
- Policy Decision Point（PDP）とPolicy Enforcement Point（PEP）の詳細設計
- 3つのデプロイメントモデル（エージェント型、エンクレーブ型、リソースポータル型）
- 信頼アルゴリズムとアクセス判定のデータフロー
- 実際のソリューションへのマッピング
この記事を読むことで、標準的なゼロトラストアーキテクチャを理解し、組織に適した構成を設計できるようになります。
前提知識
本記事を理解するために、以下の知識があることを前提としています。
- ゼロトラストの基本原則と7つの柱を理解している
- 条件付きアクセスポリシーの概念を把握している
- ネットワークセキュリティの基本（ファイアウォール、プロキシ等）を知っている
ゼロトラストの基本原則についてはゼロトラストセキュリティ入門 - 基本原則と7つの柱を理解するを先に読むことをお勧めします。
期待される学習成果
本記事を読み終えると、以下のことができるようになります。
- NIST SP 800-207の論理コンポーネント構成を説明できる
- PDP、PA、PEPの役割と相互関係を理解できる
- 3つのデプロイメントモデルの特徴と使い分けを判断できる
- 信頼アルゴリズムの設計要素を把握できる
- 組織のセキュリティ要件に合わせたアーキテクチャを選択できる
NIST SP 800-207とは
NIST SP 800-207「Zero Trust Architecture」は、2020年8月に米国国立標準技術研究所（NIST）が発行したゼロトラストアーキテクチャに関する包括的なガイドラインです。政府機関向けの文書ですが、民間企業においてもゼロトラスト実装の標準的なリファレンスとして広く参照されています。
NIST SP 800-207の位置づけ
flowchart TB
subgraph standards["ゼロトラスト関連標準・ガイドライン"]
direction TB
subgraph nist["NIST"]
sp800207["SP 800-207<br/>Zero Trust Architecture<br/>（基本アーキテクチャ）"]
sp800207a["SP 800-207A<br/>ZTA Cloud<br/>（クラウド向け拡張）"]
cswp20["CSWP 20<br/>Planning for ZTA<br/>（計画ガイド）"]
end
subgraph cisa["CISA"]
ztmm["Zero Trust<br/>Maturity Model<br/>（成熟度モデル）"]
end
subgraph dod["DoD"]
dodzt["DoD Zero Trust<br/>Reference Architecture<br/>（国防総省参照モデル）"]
end
end
sp800207 --> sp800207a
sp800207 --> cswp20
sp800207 --> ztmm
sp800207 --> dodztSP 800-207は、ゼロトラストの抽象的な原則を具体的なアーキテクチャコンポーネントに落とし込んだ点で画期的です。これにより、組織はベンダーに依存しない標準的な設計指針を得ることができます。
SP 800-207が定義するゼロトラストの前提
NIST SP 800-207では、ゼロトラストアーキテクチャを設計する際に前提とすべき事項を明確に定義しています。
| 前提 | 説明 |
|---|---|
| ネットワークは常に敵対的 | 企業ネットワーク内部であっても、攻撃者が存在する可能性を前提とする |
| 暗黙の信頼の排除 | ネットワークの場所だけでは信頼を付与しない |
| デバイスは企業所有とは限らない | BYOD、契約先デバイスなど多様なエンドポイントを想定 |
| すべての通信を保護 | ネットワーク内部の通信であっても暗号化する |
| リソースアクセスは動的に許可 | セッションごとに認証・認可を評価し、継続的に検証する |
これらの前提に基づき、SP 800-207は論理コンポーネントとデプロイメントモデルを定義しています。
ゼロトラストアーキテクチャの論理コンポーネント
NIST SP 800-207では、ゼロトラストアーキテクチャを構成する論理コンポーネントを定義しています。これらは概念的なコンポーネントであり、実際の実装では複数のコンポーネントが単一の製品に統合されることもあります。
コアコンポーネントの全体像
flowchart TB
subgraph subject["サブジェクト（アクセス要求者）"]
user["ユーザー"]
device["デバイス"]
app["アプリケーション"]
end
subgraph controlplane["制御プレーン（Control Plane）"]
subgraph pdp["Policy Decision Point"]
pe["Policy Engine<br/>（ポリシーエンジン）"]
pa["Policy Administrator<br/>（ポリシー管理者）"]
end
end
subgraph dataplane["データプレーン（Data Plane）"]
pep["Policy Enforcement Point<br/>（ポリシー実施点）"]
end
subgraph resources["企業リソース"]
apps["アプリケーション"]
data["データ"]
services["サービス"]
end
subgraph infosources["情報源（Policy Information Point）"]
cdm["CDMシステム<br/>（デバイス状態）"]
idm["ID管理システム<br/>（ユーザー属性）"]
siem["SIEMシステム<br/>（ログ・分析）"]
threat["脅威インテリジェンス<br/>（外部脅威情報）"]
compliance["コンプライアンス<br/>（ポリシー準拠状態）"]
activity["アクティビティログ<br/>（行動履歴）"]
end
subject -->|"1. アクセス要求"| pep
pep -->|"2. 認可要求"| pa
pa -->|"3. ポリシー照会"| pe
infosources -->|"4. 情報提供"| pe
pe -->|"5. アクセス判定"| pa
pa -->|"6. セッション確立指示"| pep
pep -->|"7. アクセス許可"| resourcesPolicy Engine（PE）- ポリシーエンジン
Policy Engineは、アクセスの許可または拒否の最終決定を行うコンポーネントです。ゼロトラストアーキテクチャの「頭脳」として機能します。
Policy Engineの主要な責務
- 信頼度の評価: サブジェクト（ユーザー、デバイス）の信頼度を算出
- ポリシーの適用: 組織のアクセスポリシーに基づいて判定
- リスクの計算: 複数の情報源からのシグナルを統合してリスクスコアを算出
- アクセス判定: 許可、拒否、追加認証要求などの決定を下す
flowchart LR
subgraph inputs["入力情報"]
subject_info["サブジェクト情報<br/>・ユーザーID<br/>・ロール/グループ"]
device_info["デバイス情報<br/>・セキュリティ状態<br/>・準拠状況"]
resource_info["リソース情報<br/>・機密レベル<br/>・アクセス要件"]
context_info["コンテキスト情報<br/>・時刻/場所<br/>・脅威レベル"]
end
subgraph pe["Policy Engine"]
trust_algo["信頼アルゴリズム"]
policy_eval["ポリシー評価"]
risk_calc["リスク計算"]
end
subgraph outputs["出力"]
decision["アクセス判定<br/>・許可<br/>・拒否<br/>・追加認証要求<br/>・条件付き許可"]
end
inputs --> pe
pe --> outputsPolicy Administrator（PA）- ポリシー管理者
Policy Administratorは、Policy Engineの判定結果に基づいて、実際のアクセスパス（通信経路）を確立または終了するコンポーネントです。
Policy Administratorの主要な責務
- セッション確立: PEの許可に基づきPEPにセッション確立を指示
- 認証トークン生成: サブジェクトがリソースにアクセスするための認証情報を生成
- セッション終了: PEの指示やタイムアウトに基づきセッションを終了
- PEPの構成管理: アクセスルールをPEPに配布
sequenceDiagram
autonumber
participant Subject as サブジェクト
participant PEP as Policy Enforcement Point
participant PA as Policy Administrator
participant PE as Policy Engine
participant Resource as リソース
Subject->>PEP: アクセス要求
PEP->>PA: 認可要求
PA->>PE: ポリシー判定要求
PE->>PE: 信頼度評価・リスク計算
PE->>PA: 判定結果（許可）
PA->>PA: セッショントークン生成
PA->>PEP: セッション確立指示
PEP->>Subject: アクセス許可（トークン付与）
Subject->>PEP: リソースアクセス（トークン提示）
PEP->>Resource: リクエスト転送
Resource->>PEP: レスポンス
PEP->>Subject: レスポンス転送Policy Enforcement Point（PEP）- ポリシー実施点
Policy Enforcement Pointは、サブジェクトとリソースの間に配置され、アクセス制御を実際に実施するコンポーネントです。ゲートキーパーとして機能し、許可されたアクセスのみを通過させます。
Policy Enforcement Pointの主要な責務
- アクセス要求の受付: サブジェクトからのアクセス要求を受け付ける
- 認可の確認: PAから受けた指示に基づきアクセスを許可/拒否
- 通信の仲介: 許可されたトラフィックをリソースに転送
- セッションの監視: 確立されたセッションを継続的に監視
- ログの記録: すべてのアクセス試行を記録
flowchart TB
subgraph pep_detail["Policy Enforcement Pointの機能"]
direction TB
subgraph ingress["入口処理"]
receive["リクエスト受信"]
validate["トークン検証"]
authz["認可確認"]
end
subgraph process["処理"]
decision{"許可?"}
proxy["プロキシ処理"]
encrypt["暗号化/復号"]
end
subgraph egress["出口処理"]
forward["リクエスト転送"]
log["ログ記録"]
monitor["セッション監視"]
end
receive --> validate
validate --> authz
authz --> decision
decision -->|"Yes"| proxy
decision -->|"No"| log
proxy --> encrypt
encrypt --> forward
forward --> monitor
monitor --> log
endPolicy Information Point（PIP）- 情報提供元
Policy Information Pointは、Policy Engineがアクセス判定を行うために必要な情報を提供する各種システムの総称です。SP 800-207では、以下の情報源を定義しています。
| 情報源 | 提供する情報 | 具体例 |
|---|---|---|
| CDMシステム | デバイスのセキュリティ状態 | パッチ適用状況、マルウェア検知結果、暗号化状態 |
| ID管理システム | ユーザーの属性・権限 | ロール、グループ、認証履歴 |
| 脅威インテリジェンス | 外部の脅威情報 | 既知の悪意あるIP、攻撃パターン |
| アクティビティログ | 過去の行動履歴 | アクセスパターン、異常行動検知 |
| データアクセスポリシー | リソースのアクセス要件 | 機密レベル、必要なクリアランス |
| PKIシステム | 証明書情報 | 証明書の有効性、失効状況 |
| SIEMシステム | セキュリティイベント | インシデント検知、相関分析結果 |
信頼アルゴリズム（Trust Algorithm）
Policy Engineの中核となるのが信頼アルゴリズムです。複数の情報源から収集したシグナルを統合し、アクセス要求の信頼度を数値化します。
信頼アルゴリズムの評価要素
flowchart TB
subgraph factors["信頼度評価要素"]
direction TB
subgraph identity["アイデンティティ要素"]
auth_strength["認証強度<br/>（MFA、パスワードレス等）"]
user_risk["ユーザーリスクスコア<br/>（過去の行動、漏洩情報）"]
session_age["セッション経過時間"]
end
subgraph device["デバイス要素"]
compliance["コンプライアンス状態<br/>（ポリシー準拠）"]
health["デバイスヘルス<br/>（マルウェア、パッチ）"]
managed["管理状態<br/>（MDM登録、企業所有）"]
end
subgraph context["コンテキスト要素"]
location["アクセス元<br/>（地理、ネットワーク）"]
time["アクセス時刻<br/>（業務時間内外）"]
behavior["行動パターン<br/>（通常との乖離）"]
end
subgraph resource["リソース要素"]
sensitivity["機密レベル"]
access_type["アクセス種別<br/>（読取、書込、削除）"]
end
end
subgraph algorithm["信頼アルゴリズム"]
calc["スコア計算"]
threshold["閾値判定"]
end
subgraph result["判定結果"]
allow["許可"]
deny["拒否"]
stepup["追加認証要求"]
conditional["条件付き許可"]
end
factors --> algorithm
algorithm --> result信頼度計算の例
信頼アルゴリズムは、各要素にスコアと重みを割り当て、総合的な信頼度を計算します。以下は概念的な例です。
flowchart LR
subgraph input["入力シグナル"]
s1["認証: MFA済み<br/>スコア: 90"]
s2["デバイス: 準拠<br/>スコア: 85"]
s3["場所: 社内ネットワーク<br/>スコア: 80"]
s4["行動: 通常パターン<br/>スコア: 95"]
end
subgraph calc["スコア計算"]
weighted["重み付け平均<br/>= (90×0.3 + 85×0.3 + 80×0.2 + 95×0.2)<br/>= 87.5"]
end
subgraph threshold["閾値判定"]
t1["高機密リソース: 90以上"]
t2["中機密リソース: 70以上"]
t3["低機密リソース: 50以上"]
end
subgraph decision["判定"]
d1["高機密: 追加認証要求<br/>（87.5 < 90）"]
d2["中機密: 許可<br/>（87.5 ≥ 70）"]
end
input --> calc
calc --> threshold
threshold --> decision動的なポリシー適応
信頼アルゴリズムの重要な特徴は、状況に応じて動的にアクセス判定を変更できる点です。
シナリオ例：同一ユーザーの異なる状況での判定
| シナリオ | 認証 | デバイス | 場所 | 総合スコア | 判定 |
|---|---|---|---|---|---|
| 通常業務 | MFA | 管理端末 | 社内 | 88 | 許可 |
| 在宅勤務 | MFA | 管理端末 | 自宅 | 82 | 許可 |
| 出張中 | MFA | 管理端末 | 海外 | 70 | 条件付き許可 |
| 不審なアクセス | パスワードのみ | 未登録端末 | 未知のIP | 35 | 拒否 |
デプロイメントモデル
NIST SP 800-207では、ゼロトラストアーキテクチャを実装する3つのデプロイメントモデルを定義しています。組織の既存インフラ、セキュリティ要件、運用能力に応じて最適なモデルを選択します。
モデル1：デバイスエージェントとゲートウェイモデル
エンドポイントにエージェントをインストールし、ゲートウェイと連携してアクセス制御を行うモデルです。最も一般的に採用されているアプローチです。
flowchart TB
subgraph subject["サブジェクト"]
device["デバイス"]
agent["エージェント<br/>（PEP機能）"]
end
subgraph controlplane["制御プレーン"]
pdp["PDP<br/>（クラウド/オンプレミス）"]
end
subgraph gateway["ゲートウェイ"]
gw_pep["ゲートウェイPEP"]
end
subgraph resources["リソース"]
r1["オンプレミスアプリ"]
r2["クラウドサービス"]
r3["データベース"]
end
agent -->|"認証・認可要求"| pdp
pdp -->|"アクセストークン"| agent
agent -->|"暗号化トンネル"| gw_pep
gw_pep --> r1
gw_pep --> r3
agent -->|"直接アクセス"| r2特徴
| 項目 | 内容 |
|---|---|
| 適用場面 | 管理対象デバイスからの企業リソースアクセス |
| メリット | デバイス単位での詳細な制御、オフライン時のローカルポリシー適用 |
| デメリット | エージェントのインストールが必要、BYODへの適用が難しい |
| 実装例 | Microsoft Entra ID + Intune、Zscaler Private Access、Cloudflare Access |
エージェントの役割
- デバイス認証情報の提供（証明書、ハードウェアアテステーション）
- デバイスコンプライアンス状態の報告
- 暗号化トンネルの確立
- ローカルでのアクセス制御実施
モデル2：エンクレーブベースモデル
ネットワークの特定セグメント（エンクレーブ）をゲートウェイで保護し、エンクレーブ内のリソースへのアクセスを一括制御するモデルです。
flowchart TB
subgraph subject["サブジェクト"]
user["ユーザー/デバイス"]
end
subgraph controlplane["制御プレーン"]
pdp["PDP"]
end
subgraph enclave1["エンクレーブA（開発環境）"]
gw1["ゲートウェイPEP"]
dev1["開発サーバー"]
dev2["テストDB"]
dev3["CIツール"]
end
subgraph enclave2["エンクレーブB（本番環境）"]
gw2["ゲートウェイPEP"]
prod1["本番アプリ"]
prod2["本番DB"]
end
subgraph enclave3["エンクレーブC（機密データ）"]
gw3["ゲートウェイPEP"]
sensitive["機密データストア"]
end
user -->|"開発アクセス"| gw1
user -->|"本番アクセス"| gw2
user -->|"機密データアクセス"| gw3
gw1 --> dev1 & dev2 & dev3
gw2 --> prod1 & prod2
gw3 --> sensitive
pdp --> gw1 & gw2 & gw3特徴
| 項目 | 内容 |
|---|---|
| 適用場面 | レガシーシステムの保護、データセンター内のマイクロセグメンテーション |
| メリット | エージェントレスで導入可能、既存インフラへの影響が小さい |
| デメリット | エンクレーブ内での横方向移動は制御できない |
| 実装例 | ネットワークファイアウォール、マイクロセグメンテーション製品 |
エンクレーブの設計原則
- 機密レベルによる分離: 機密度の異なるリソースを別エンクレーブに配置
- 機能による分離: 開発、本番、バックアップなど環境ごとに分離
- 規制要件による分離: PCI DSS対象システムなど規制要件ごとに分離
モデル3：リソースポータルモデル
Webポータル経由でリソースにアクセスさせ、ポータルがPEPとして機能するモデルです。エージェントのインストールが不要で、BYODや外部パートナーのアクセスに適しています。
flowchart TB
subgraph subject["サブジェクト"]
user["ユーザー<br/>（ブラウザのみ）"]
end
subgraph controlplane["制御プレーン"]
pdp["PDP<br/>（IdP統合）"]
end
subgraph portal["リソースポータル（PEP）"]
proxy["リバースプロキシ"]
session["セッション管理"]
rendering["画面レンダリング"]
end
subgraph resources["バックエンドリソース"]
webapp["Webアプリ"]
legacy["レガシーアプリ"]
file["ファイルサーバー"]
end
user -->|"HTTPS"| portal
portal -->|"認証・認可"| pdp
pdp -->|"トークン"| portal
portal --> resources特徴
| 項目 | 内容 |
|---|---|
| 適用場面 | BYOD、外部パートナー、契約社員のアクセス |
| メリット | エージェント不要、ブラウザのみでアクセス可能 |
| デメリット | ポータルがボトルネックになる可能性、レイテンシの増加 |
| 実装例 | Azure AD Application Proxy、Citrix Secure Private Access |
リソースポータルの追加機能
- シングルサインオン（SSO）: 一度の認証で複数リソースにアクセス
- セッション録画: 特権アクセスの監査証跡
- クリップボード制御: データの外部持ち出し防止
- ウォーターマーク: 画面キャプチャへの抑止
デプロイメントモデルの比較と選択
flowchart TB
start["アクセス要件の確認"]
q1{"管理対象デバイス<br/>からのアクセス？"}
q2{"エージェント<br/>インストール可能？"}
q3{"レガシーシステム<br/>の保護が主目的？"}
q4{"外部ユーザー<br/>のアクセスが多い？"}
m1["モデル1<br/>エージェント+ゲートウェイ"]
m2["モデル2<br/>エンクレーブベース"]
m3["モデル3<br/>リソースポータル"]
hybrid["ハイブリッド<br/>（複数モデルの組合せ）"]
start --> q1
q1 -->|"Yes"| q2
q1 -->|"No"| q4
q2 -->|"Yes"| m1
q2 -->|"No"| q3
q3 -->|"Yes"| m2
q3 -->|"No"| m3
q4 -->|"Yes"| m3
q4 -->|"No"| hybrid選択基準のまとめ
| 選択基準 | モデル1 | モデル2 | モデル3 |
|---|---|---|---|
| 管理対象デバイス中心 | 最適 | 適用可 | 適用可 |
| BYOD・外部ユーザー | 不向き | 適用可 | 最適 |
| レガシーシステム保護 | 適用可 | 最適 | 適用可 |
| 導入の容易さ | 中 | 高 | 高 |
| きめ細かい制御 | 高 | 中 | 中 |
実際の組織では、これら3つのモデルを組み合わせたハイブリッドアプローチが一般的です。たとえば、社内ユーザーにはモデル1、外部パートナーにはモデル3、レガシーシステムにはモデル2を適用するといった構成です。
制御プレーンとデータプレーンの分離
ゼロトラストアーキテクチャでは、アクセス判定を行う「制御プレーン」と、実際のトラフィックが流れる「データプレーン」を明確に分離することが重要です。
分離の意義
flowchart TB
subgraph controlplane["制御プレーン（Control Plane）"]
direction LR
pdp["PDP<br/>（認証・認可判定）"]
policy["ポリシーDB"]
logs["監査ログ"]
end
subgraph dataplane["データプレーン（Data Plane）"]
direction LR
pep["PEP<br/>（トラフィック制御）"]
tunnel["暗号化トンネル"]
traffic["アプリケーショントラフィック"]
end
controlplane -->|"判定結果のみ"| dataplane分離のメリット
- スケーラビリティ: データプレーンの負荷と制御プレーンの負荷を独立してスケール
- セキュリティ: 制御プレーンを隔離することで攻撃対象を限定
- 可用性: データプレーン障害時も制御プレーンは影響を受けない
- 監査性: ポリシー判定とトラフィック処理を別々にログ取得
暗黙的信頼ゾーンの排除
従来のネットワークでは、「DMZ」「内部ネットワーク」「信頼済みゾーン」といった暗黙の信頼ゾーンが存在しました。ゼロトラストでは、これらの暗黙的な信頼を排除します。
flowchart TB
subgraph traditional["従来のゾーンベースセキュリティ"]
direction TB
internet1["インターネット<br/>（非信頼）"]
dmz1["DMZ<br/>（半信頼）"]
internal1["内部ネットワーク<br/>（信頼）"]
internet1 -->|"FW"| dmz1
dmz1 -->|"FW"| internal1
end
subgraph zerotrust["ゼロトラストアーキテクチャ"]
direction TB
any["あらゆる場所<br/>（すべて非信頼）"]
pep2["PEP"]
resource["リソース<br/>（個別に保護）"]
any -->|"毎回検証"| pep2
pep2 -->|"許可時のみ"| resource
end実際のソリューションへのマッピング
NIST SP 800-207の論理コンポーネントは、実際の製品・サービスにどのようにマッピングされるのでしょうか。代表的なソリューションでの対応関係を示します。
Microsoft Entra ID + Intune
flowchart TB
subgraph nist["NIST SP 800-207コンポーネント"]
direction LR
pe_nist["Policy Engine"]
pa_nist["Policy Administrator"]
pep_nist["Policy Enforcement Point"]
pip_nist["Policy Information Point"]
end
subgraph microsoft["Microsoftソリューション"]
direction LR
ca["Conditional Access<br/>（条件付きアクセス）"]
entra["Entra ID<br/>（Azure AD）"]
intune["Intune<br/>（デバイス管理）"]
defender["Defender for Endpoint"]
sentinel["Microsoft Sentinel"]
end
pe_nist -.->|"実装"| ca
pa_nist -.->|"実装"| entra
pep_nist -.->|"実装"| intune
pip_nist -.->|"実装"| defender
pip_nist -.->|"実装"| sentinel| NISTコンポーネント | Microsoftソリューション | 役割 |
|---|---|---|
| Policy Engine | Conditional Access | リスク評価・アクセス判定 |
| Policy Administrator | Entra ID | セッション管理・トークン発行 |
| Policy Enforcement Point | Intune、Defender for Cloud Apps | デバイス制御・アプリアクセス制御 |
| Policy Information Point | Defender for Endpoint、Sentinel | 脅威情報・デバイス状態提供 |
Google BeyondCorp Enterprise
flowchart TB
subgraph nist["NIST SP 800-207コンポーネント"]
direction LR
pe_nist2["Policy Engine"]
pa_nist2["Policy Administrator"]
pep_nist2["Policy Enforcement Point"]
end
subgraph google["Googleソリューション"]
direction LR
access["BeyondCorp Enterprise"]
iap["Identity-Aware Proxy"]
workspace["Google Workspace"]
endpoint["Endpoint Verification"]
end
pe_nist2 -.->|"実装"| access
pa_nist2 -.->|"実装"| workspace
pep_nist2 -.->|"実装"| iapZscaler Zero Trust Exchange
| NISTコンポーネント | Zscalerソリューション | 役割 |
|---|---|---|
| Policy Engine | Zero Trust Exchange | 中央集中型ポリシー判定 |
| Policy Administrator | Zscaler Admin Portal | ポリシー管理・配布 |
| Policy Enforcement Point | Zscaler Client Connector | デバイスエージェント |
| Policy Enforcement Point | Zscaler Private Access | アプリケーションアクセス制御 |
アーキテクチャ設計のベストプラクティス
ゼロトラストアーキテクチャを設計する際の重要な考慮事項とベストプラクティスを紹介します。
設計原則
1. アイデンティティを中心に設計する
ネットワークの場所ではなく、アイデンティティ（ユーザー、デバイス、ワークロード）を中心にアクセス制御を設計します。
flowchart LR
subgraph identity_centric["アイデンティティ中心の設計"]
id["誰が（Who）"]
device["何で（What device）"]
context["どこから（Where）"]
resource["何に（What resource）"]
action["何を（What action）"]
end
id --> device --> context --> resource --> action2. 最小権限の原則を徹底する
すべてのアクセスにおいて、必要最小限の権限のみを付与します。Just-In-Time（JIT）アクセスとJust-Enough-Access（JEA）を組み合わせます。
3. 暗号化をデフォルトとする
ネットワークの場所に関係なく、すべての通信を暗号化します。内部ネットワークであってもTLS/mTLSを適用します。
4. 継続的な検証を実装する
初回認証だけでなく、セッション中も継続的にリスクを評価し、必要に応じてアクセス権限を動的に調整します。
データフロー設計のポイント
flowchart TB
subgraph design_points["データフロー設計のポイント"]
direction TB
p1["1. 単一障害点の排除<br/>PDPの冗長化"]
p2["2. レイテンシの最小化<br/>PEPの分散配置"]
p3["3. スケーラビリティ<br/>水平スケール可能な設計"]
p4["4. フェイルセーフ<br/>PDP障害時のフォールバック"]
endフェイルクローズ vs フェイルオープン
| モード | 動作 | 適用場面 |
|---|---|---|
| フェイルクローズ | PDP障害時はすべてのアクセスを拒否 | 高機密リソース |
| フェイルオープン | PDP障害時はキャッシュされたポリシーで判定 | 業務継続性重視 |
一般的には、フェイルクローズをデフォルトとし、業務継続性が特に重要なリソースに対してのみフェイルオープンを検討します。
移行時の共存アーキテクチャ
既存の境界型セキュリティからゼロトラストへ移行する際は、段階的なアプローチが必要です。
flowchart TB
subgraph phase1["フェーズ1: 共存期"]
direction TB
legacy1["既存境界セキュリティ"]
zt1["ゼロトラスト（パイロット）"]
legacy1 --> |"大部分のアクセス"| resources1["リソース"]
zt1 --> |"特定ユーザー/アプリ"| resources1
end
subgraph phase2["フェーズ2: 拡張期"]
direction TB
legacy2["既存境界セキュリティ<br/>（縮小）"]
zt2["ゼロトラスト<br/>（拡大）"]
legacy2 --> |"レガシーアクセス"| resources2["リソース"]
zt2 --> |"主要アクセス"| resources2
end
subgraph phase3["フェーズ3: 完了期"]
direction TB
zt3["ゼロトラスト<br/>（全面適用）"]
zt3 --> resources3["リソース"]
end
phase1 --> phase2 --> phase3まとめ
本記事では、NIST SP 800-207に基づくゼロトラストアーキテクチャの設計について解説しました。
論理コンポーネントの理解
- Policy Engine（PE）: アクセス判定の中核、信頼アルゴリズムを実行
- Policy Administrator（PA）: セッション確立・終了の管理
- Policy Enforcement Point（PEP）: 実際のアクセス制御を実施
- Policy Information Point（PIP）: 判定に必要な情報を提供
3つのデプロイメントモデル
- エージェント+ゲートウェイモデル: 管理デバイス向けの標準的なアプローチ
- エンクレーブベースモデル: レガシーシステム保護に適したセグメント型
- リソースポータルモデル: BYODや外部ユーザー向けのエージェントレス型
設計のポイント
- 制御プレーンとデータプレーンの分離
- アイデンティティを中心とした設計
- 継続的な検証の実装
- 段階的な移行アプローチ
次の記事では、ゼロトラスト成熟度モデルと段階的導入ロードマップについて解説し、CISAの成熟度モデルを活用した導入計画の策定方法を紹介します。