2026年8月29日
ゼロトラストWGリーダー　諸角昌宏

この回のねらい

第1回で守る対象（プロテクトサーフェス＝DAAS）を定義し、第2回でその周りのトランザクションフローを可視化した。守るものと、その動きが見えたら、次はいよいよ実装である。ここでは、ステップ3「ゼロトラストアーキテクチャの構築」を扱う。

図1：ゼロトラスト導入の5ステップと、本ブログが扱うステップ3（CSA文書の5段階プロセスを基に作成）

ステップ3のねらいは、第2回でマッピングしたトランザクションフローを基盤に、ポリシー実施ポイント（PEP）を適切に配置したゼロトラスト環境を設計することである。「誰が・何に・どんな状況でアクセスできるか」を、各プロテクトサーフェスの出入口で実際に検証・制御できる形に落とし込んでいく。

おさらい：ゼロトラストの原則

アーキテクチャを設計する前に、拠り所となる原則を確認しておく。ゼロトラストは、次のような考え方に立っている。

• 敵対的な環境を想定する／すでに侵害されていると想定する（assume breach）
• 決して信頼せず、常に検証する（既定で拒否し、ユーザー・デバイス・アプリ・トランザクションを継続的に検証）
• 明示的に精査する（複数の属性を用いて、安全な方法で一貫してアクセスさせる）
• 統合的な分析を適用する（データ・アプリ・ネットワークに横断的な分析と挙動監視を効かせる）

これらを設計に落とすと、次の原則になる。認証・認可が済むまでアクセスを与えない（パケット1つに至るまで検査）／アクセスは一時的で再検証が必要／最小特権（必要最小限のアクセスだけを付与）／コントロールの有効性を継続的に監視する。

ゼロトラストアーキテクチャの中核 — PDPとPEP

アクセスの可否を判断するには、まず3つの中核要素、通信（アクセス要求）・アイデンティティ（要求する主体）・リソース（守る対象）が必要になる。さらに、判断を支える2つの要素として、ポリシー（誰が・何に・いつ・どのようにアクセスできるかを定める規則）と、データソース（ポリシーを動的に更新するための状況情報）がある。

NIST SP 800-207 は、これを2つの仕組みで表現している。判断を下すPDP（ポリシー定義ポイント）と、それを実際に強制するPEP（ポリシー実施ポイント）である。両者はトラフィックのアクセス経路上に置かれ、リソースへのアクセスを制御する。

図2：ゼロトラストアーキテクチャの中核（PDP／PEP）（NIST SP 800-207 の論理モデルを基に作成）

• PDP（コントロールプレーン）：ポリシーエンジン（PE）とポリシー管理者からなる。データを分析してルールに変換し（PE）、そのルールをPEPに伝える（ポリシー管理者）。
• PEP（データプレーン）：ゲートウェイ（関所）として働き、正しい主体に、正しいアクセスレベルで、承認されたリソースへのアクセスだけを許可する。

PDPの判断は、多様なデータソースから供給される状況情報（コンテキスト）に支えられる。IdP／Active Directory、IDS／IPS、脅威インテリジェンス、PKI（証明書失効リスト）、資産・デバイス管理（CDM＝継続的診断・対策など、資産のOS・ソフト構成や脆弱性・健全性を継続的に把握する仕組み）、SIEM、法令・規制要件などである。これらの情報が豊富なほど、より的確なアクセス判断ができる。

なお、ゼロトラストではPEPの数が大幅に増えるため、アクセスモデルを手作業で管理するのは現実的でない。自動化が、細かな制御と全体制御の両立に不可欠となる。

設計の柱 — 何を組み込むか

PDP／PEPという骨格の上に、以下のようなゼロトラストらしさを与える具体的な設計要素を組み込んでいく。

マイクロセグメンテーション

ネットワークをより小さな独立したセグメントに分割し、ワークロードやアプリ、デバイス単位で境界（マイクロペリメータ）を設ける。トランザクションフローの理解に基づいて論理的にグループ分けすることで、万一侵入されてもラテラルムーブメントを封じ込め、アタックサーフェスを縮小できる。

コンテキストベースのアクセス制御（動的ポリシー）（CBAC)

アクセス判断は静的ではなく、動的かつ状況依存で行う。ユーザーのアイデンティティ、デバイスの状態、場所、実行中のトランザクションといったコンテキストを評価して、その都度アクセスの可否を決める。第2回でマッピングしたトランザクションフローが、この判断材料になる。

最小特権

役割やアプリに不可欠なトランザクションだけを許可し、タスクの実行に必要な最小限のアクセスに制限する。トランザクションフローマッピングは「正常な動作の基準」を与えるため、そこからの逸脱や異常を検知し、アラートや対応につなげられる。

暗号化とデータ保護／監視とログ

通信・データを暗号化して保護する。あわせてデータ損失防止（DLP）で機微情報の持ち出しを防ぐが、暗号化された状態では中身を検査できないため、DLPは平文が現れる地点のエンドポイントや、通信を復号する検査ポイントで効かせる。また、集中型のログ記録と、SIEMによるリアルタイムのモニタリング・相関分析を導入し、コントロールの有効性を継続的に監視する。

実装パターン — アーキテクチャの選択肢

ゼロトラストアーキテクチャを実際に実現する方式には、代表的なものがいくつかある。いずれもPDP／PEPという共通の土台の上に立ち、相互に影響し合ってきた。用途に応じて選び、組み合わせることになる。

実装パターン	特徴	主な用途
SDP	接続を事前検証（SPA等）し、認証・認可されるまで既定で全拒否。リソースを外部から隠す	リソースの隠蔽、境界の動的生成
ZTNA	SDPとほぼ同じ発想。ユーザーとアプリのアクセスを検証し、必要なアプリだけに接続を許す	リモートアクセス、VPN置き換え
BeyondCorp	Googleが自社向けに実装。所在地を信頼せず、デバイスとユーザーの状態で判断	リモートアプリアクセス
NISTアプローチ（SP 800-207）	PDP／PEPを中核とする論理アーキテクチャ。各方式に共通する土台	設計の基本モデル

表1：代表的なゼロトラストアーキテクチャの実装パターン

プロテクトサーフェス単位で設計する

ゼロトラストアーキテクチャは、プロテクトサーフェスごとに、その出入口（マイクロペリメータ）へPEPを配置して設計する。第2回でマッピングした「どの主体が・どの経路で・どのDAAS要素にアクセスするか」を、そのままPEPの配置とポリシーに写し取るイメージである。

第1回・第2回で用いたクレジットカードサービスの例で示すと、次のようになる。

図3：クレジットカードのプロテクトサーフェスにPEPを配置する（CSA文書を基に作成）

顧客・営業担当・ATMからの入口、アプリとカード会員データの間、そして信用調査機関・規制報告・住宅ローン／預金といった外部・他システムとの接続点、それぞれにPEPを置き、マッピングしたフローに沿ったアクセスだけを許可する。組織によっては、まず粗い粒度のマクロセグメンテーションから始め、時間をかけてマイクロセグメンテーションへ進めるのが現実的な場合もある。

実際のアーキテクチャはどうなるのか

ここまでの図は、役割（誰が判断し、誰が強制するか）を示す論理アーキテクチャである。では、これを実際の構成に落とすと何になるのか。ポイントは、論理的な役割を具体的なコンポーネント（製品・機能）に割り当てることである。

• PEPの実体：単一の製品ではなく、守るDAASの各出入口に分散した実施点の集合。次世代ファイアウォール、マイクロセグメンテーション製品、ゲートウェイ／プロキシ、SDP／ZTNAゲートウェイ、APIゲートウェイ、サービスメッシュのサイドカー（コンテナ）、エンドポイントのエージェントなど。
• PDPの実体：ポリシーエンジンとポリシー管理者を担うポリシー制御基盤（ゼロトラスト管理コンソール、ポリシーサーバー、IdP／IGA、SDPコントローラ等）。PEPは判断を持たず、PDPに問い合わせて判定に従う。
• データソースの実体：IdP／AD、IDS／IPS、EDR、脅威インテリジェンス、PKI、資産管理、SIEM等が、PDPに状況（コンテキスト）を供給する。

そして、1回のアクセスがどう流れるかを追うと、実際の動作が見えてくる。クレジットカードの例で、顧客がカードWebアプリにアクセスする場面を示すと以下のようになる。

図4：1回のアクセスがゼロトラストで処理される流れ（NIST SP 800-207 のPDP／PEPモデルを基に作成）

要求はまずアプリ手前のPEPに届くが、PEPは自分では判断せず、PDPに照会する。PDPはデータソース（IdPで本人性、EDRで端末状態、脅威インテリジェンスでリスク）を評価してポリシーに照らし、判定をPEPに返す。PEPは許可／拒否を強制し、許可ならアプリへ通す。さらにアプリからカード会員データへ進む際には、その間の別のPEPが同じ手順を繰り返す。

この「各出入口で、要求ごとに、PDPへ照会して強制する」という反復こそが、ゼロトラストの実際のアーキテクチャの姿である。従来の境界防御のように「一度入れば中は自由」ではなく、どのPEPも毎回PDPに確認する。前掲の実装パターンでいえば、SDP／ZTNAはコントローラ（PDP役）とゲートウェイ（PEP役）、BeyondCorpはアクセス制御エンジン（PDP役）とアクセスプロキシ（PEP役）として、この構図を実現している。

具体例：SDPによるベンダーニュートラルな実装

ここではSDPを使ってアーキテクチャの実装をもう少し具体化してみる。CSAのSDPは、特定製品に依存しない標準仕様として構成要素が定義されており、ベンダーニュートラルな実装例として分かりやすい。SDPは次の3つの要素からなる。

• IH（起動ホスト）：SDPクライアントを載せた接続元の端末（顧客・営業担当の端末、ATMなど）。暗号署名した接続要求を出す。
• AH（受入ホスト）＋ドロップオール・ゲートウェイ：守るサービスをホストする側。既定ですべての通信を落とし（ドロップオール）、認可されるまで外部から見えない（cloaked）。つまり、PEPの実体。
• コントローラ：コントロールプレーンで認証・認可を判断する頭脳。IAMなどのデータソースを参照する。つまり、PDPの実体。

これらを、クレジットカードサービスのプロテクトサーフェスに当てはめると、次のような構成になる。

図5：SDPによるベンダーニュートラルな実装例

顧客がカードWebアプリにアクセスするのは、次の順でつながる。

1. ① IH → コントローラ：SDPクライアントが単一パケット認可（SPA）と認証情報を送り、本人性・デバイス状態を検証してもらう。（SPAの解説はこちらのブログを参照）。
2. ②③ コントローラ → AH／IH：判断の結果、このIHが接続してよいAH（カードWebアプリ）をAH側に許可し、IHには接続先を通知する。
3. ④ IH → AH：IHがAHにSPAを送ると、それまで全拒否だったドロップオール・ゲートウェイが、そのIHのためだけに開く。
4. ⑤ IH ⇄ AH：相互TLS（mTLS）で暗号化された接続を直接確立し、はじめてデータが流れる。

ポイントは、認証・認可がすべて“接続の前”にコントロールプレーンで済むこと、そして許可されるまでリソースが存在すら見えない（ドロップオールで不可視）ことである。これにより、正体不明のトラフィックはそもそもリソースに到達できず、アタックサーフェスが大きく縮小する。コントローラ＝PDP、AH＋ゲートウェイ＝PEP、という役割対応も、この例で明確である。

なお、ここで挙げたIH・AH・コントローラ・SPA・mTLS・ドロップオールはいずれもSDP仕様の用語であって特定製品名ではない。実際には、SDP・ZTNA・BeyondCorpといった枠組み（コントローラ＝PDP、ゲートウェイ／プロキシ＝PEP）のいずれかを土台に選び、そこへIdPやEDRといったデータソースを接続して実装する。

PDPの中身：CBAC（コンテキストベースアクセス制御）をどう実装するか

SDPの例では、AH＋ゲートウェイ（PEP）が「どう強制するか」を具体化した。では、その判断を下すPDPの中身はどうなるのか。PDPはポリシーエンジン（PE）とポリシー管理者からなり、PEが「通す／通さない」を決め、ポリシー管理者がその判定をセッションとしてPEPに発行・失効させる。

PEの判断の核が、CBAC（コンテキストベースアクセス制御）である。従来のアクセス制御と並べると位置づけがはっきりする。

方式	判断の基準	特徴
RBAC（役割ベース）	役割（ロール）だけで静的に許可を決める	シンプルだが状況を見ない
ABAC（属性ベース）	主体・リソース・環境の属性を組み合わせて判断	柔軟。ゼロトラストの土台
PBAC（ポリシーベース）	属性を組み合わせたポリシー（ルール）で判断	ルールとして表現・管理
★CBAC（コンテキストベース）	PBACに加え、その場の状況（デバイス状態・場所・時刻・リスク）を入力として動的に評価	アクセスのたびに評価し直す

表2：アクセス制御方式とCBACの位置づけ

CBACは、ABAC／PBACの一種と捉えられるが、環境・状況の属性（コンテキスト）を重視し、アクセスのたびに動的に評価し直す点が要である。PEは、集めた属性をポリシー（＝トラストアルゴリズム）に照らし、「許可／追加認証（step-up）／拒否」を決める。

図6：PDPによるCBACの判断（NIST SP 800-207 のトラストアルゴリズムを基に作成）

クレジットカードの例で、引受担当者が引受審査アプリにアクセスする場面のポリシーを、擬似的に書くと次のようになる。

CBACポリシーの例（引受審査アプリへのアクセス）

• もし〔役割＝引受担当者〕かつ〔端末＝管理端末で準拠〕かつ〔場所＝社内／既知〕かつ〔MFA＝通過〕かつ〔リスクスコア＜しきい値〕ならば → 許可（セッションは短時間で失効。以後も再評価）
• 端末が非準拠、または見知らぬ場所・時刻 → 追加認証（step-up）を要求
• リスクスコアが高い、または権限外 → 拒否

重要なのは、この判断が一度きりではないことである。セッションの発行後も継続的に再評価し、途中で端末が非準拠になったり、リスクが上昇したりすれば、その場でアクセスを失効させる。これが「常に検証する」を実装レベルで成り立たせる仕組みであり、静的なRBACとの決定的な違いである。

なお、トラストアルゴリズムには、条件をすべて満たすかで判断する基準ベース（criteria-based）と、各属性に重みをつけてスコアで判断するスコアベース（score-based）がある。またリソースごとに独立して判断するか、主体の直近の行動履歴まで加味する（コンテキスト型）かでも設計が分かれる。組織のリスク許容度に応じて選ぶことになる。

CBACポリシーの具体例 — リソースごとに判断が変わる

CBACの勘所は、同じ人でも状況で結果が変わる／人間とワークロードで扱いが違うことにある。クレジットカードの例で、リソースごとにポリシーを並べると、その違いが具体的に見えてくる。

リソース	状況（コンテキスト）	判定	備考
引受審査アプリ（内部・機微）	引受担当者＋管理端末（準拠）＋社内／VPN＋MFA＋低リスク	許可	セッション短時間・再評価
引受審査アプリ	同じ担当者だが私物端末・自宅から	step-up＋読取のみ	権限を状況で縮小
カード会員データ（最重要・PII）	決済アプリのサービスアカウント＋mTLS＋想定経路	許可（該当レコードのみ）	正規ワークロード
カード会員データ	人間ユーザーが直接クエリ／大量エクスポート	拒否＋アラート	アプリ経由のみ許可
カード申込（外部・B2C）	顧客＋MFA＋既知デバイス＋低リスク	許可	—
カード申込	新規デバイス／不可能移動（地理的に不自然）	step-up（追加認証）	—
ATM（非人間）	登録済みATM＋証明書＋EMV認証＋営業時間内	許可（限度内）	—
ATM	証明書失効／未登録端末	拒否	—

表3：クレジットカードの各リソースに対するCBACポリシーの例

同じ「引受担当者」でも、管理端末・社内なら通し、私物・自宅なら追加認証のうえ読み取り拒否だけに絞る。カード会員データは、正規のワークロード（決済アプリ）からは許可するが、人間の直接アクセスや大量エクスポートは拒否する。誰か（役割）だけでなく、どこから・どの端末で・どんなパターンかまで見て判断するのがCBACである。

CBACをどんな技術で実装するか

では、こうしたポリシーを実際に動かすのは何か。CBACは単一の製品ではなく、次のような技術・仕組みの組み合わせで実装される。

• ポリシー言語／ポリシーエンジン：ABAC／PBACを表現・評価する仕組み。標準としてはXACML、軽量なものではOPA（Open Policy Agent）／Regoなどのポリシーエンジンで、属性と条件からなるルールを評価する。
• IdPの条件付きアクセス：多くのアイデンティティ基盤が、ログイン時に場所・デバイス状態・リスクを評価してMFAや拒否を出す「条件付きアクセス」機能を持つ。CBACの一部を担う。
• リスクエンジン（継続的評価）：UEBA（利用者・端末の挙動分析）やリスクスコアリングが、脅威・不審度をリアルタイムに算出してPEに供給する。
• 属性・信号のソース：デバイスのポスチャーはEDR／MDMから、本人性はIdPから、機微度はデータ分類から。これらが判断材料（属性）になる。
• 実施点（PEP）：ZTNA／SDPゲートウェイ、APIゲートウェイ、サービスメッシュ、リバースプロキシなどが、PEの判定を実際に強制する。

実装の型としては、判定を毎回外部のポリシーエンジンに問い合わせる型（PEP↔PDP分離）と、各サービスにポリシーを配布して手元で評価する型（サイドカー等）がある。前者は一元管理しやすく、後者は低遅延で大規模な環境に向いている。いずれも「属性を集め、ポリシーで評価し、動的に判定し、継続的に再評価する」という流れは同じである。

なお、ここで挙げたXACML・OPA・条件付きアクセス・UEBAなどは実装手段の代表例であり、特定製品の推奨ではない。自組織の環境（クラウド／オンプレ、コンテナの有無など）に応じて選択、および組み合わせることになる。

既存環境からどう移行するか

ゼロトラストアーキテクチャは、既存の仕組みを一度に置き換える「入れ替え」ではなく、段階的な移行として進める。次のような考え方が必要である。

• ギャップ分析：現状のアーキテクチャと、目指すゼロトラストの状態との差を洗い出す。
• 既存アーキテクチャからの移行：一斉ではなく、プロテクトサーフェス単位で少しずつ移行する（重要資産＝クラウンジュエルは、練習を積んでから）。
• 情報セキュリティポリシーとの整合：既存のポリシーやガバナンス（ISMS等）と齟齬がないように揃える。
• マネージドサービスか内製か：自組織の体制・スキルに応じて、外部サービスの活用と内製を選択する。

実装後は、トランザクションフローに照らしたアーキテクチャのレビュー、テスト、継続的改善を回していく。ここは次回のステップ4・5（ポリシー、監視と保守）にもつながる。

まとめ

第3回では、マッピングした流れを土台に、ゼロトラスト環境を設計するステップ3を扱った。要点は次のとおりである。

• 中核はPDP（判断＝ポリシーエンジン＋ポリシー管理者）とPEP（強制＝関所）。データソースが判断を支え、自動化が前提になる
• 設計の柱はマイクロセグメンテーション・コンテキストベースのアクセス制御・最小特権・暗号化・監視／ログ
• 実装パターンはSDP・ZTNA・BeyondCorp・NISTアプローチなど。用途に応じて選び、組み合わせる
• 設計はプロテクトサーフェス単位でPEPを配置し、既存環境からは段階的に移行する

守る対象を定め（ステップ1）、流れを可視化し（ステップ2）、アーキテクチャを構築した（ステップ3）。次回（第4回）は、ステップ4「ゼロトラストポリシーの作成」を扱う。配置したPEPに、実際にどのようなルール（誰に・何を・どの条件で許すか）を持たせるか。アクセスポリシーを具体的に定義していく。

以上