城と堀の終焉：標準ゼロトラストアーキテクチャ (NIST SP 800-207) を解剖する

TL;DR： NIST SP 800-207 が定義するゼロトラストアーキテクチャ（Zero Trust Architecture: ZTA）の本質は、ネットワークの「物理的な場所」に基づく暗黙の信頼を完全に撤廃し、すべてのリクエスト単位でアイデンティティとリアルタイムのコンテキストを動的に検証することです。この構造は4つの論理エンティティ（サブジェクト、リソース、ポリシー適用ポイント PEP、ポリシー決定ポイント PDP）に集約され、南北（ユーザー対アプリ）および東西（ワークロード対ワークロード）という2大ドメインで稼働します。各ベンダーのゼロトラスト製品群をこれら4エンティティと4プレーンにマッピングできるようになれば、難解に見えるソリューションも統一的なアーキテクチャとして見通せるようになります。

🎥 動画解説: 本記事の要点をテンポよくまとめたアニメーション解説動画を公開しています: ゼロトラストアーキテクチャ徹底解説（YouTube / 1分53秒）

ここ1年ほど、生成AI技術の急速な進化と普及に伴い、IT業界全体でサイバーセキュリティインシデントの発生頻度が著しく跳ね上がっています。その背景は明快です。攻撃者が新たなツールを手にして攻撃手法を迅速に反復できるようになったことで、「境界の内側は安全である」という従来の防御モデルが許容できるマージンは、もはや完全に消失しました。

私自身がこの領域を深く掘り下げるに至ったきっかけは、日常のエンジニアリング業務にあります。私は Google Cloud 上で Apigee 製品のサポートを担当していますが、日々の業務を通じて、このプロダクトの根底には極めて洗練されたゼロトラストの思想が息づいていると常に感じていました。そこで、その抽象的な直感を一度体系的なアーキテクチャとして厳密に整理したいと考えたのが本連載の出発点です。本記事（第1回）では、APIゲートウェイの固有機能には踏み込まず、NIST が定めるカノニカルなゼロトラストアーキテクチャの理論と構造に特化して解説します。続く第2回において、Apigee をはじめとする現代のインフラがこの哲学をいかに具現化しているかを詳述します。

1. 境界の幻想：なぜネットワークの「場所」は信頼の根拠たり得ないのか

ゼロトラストとは、いかなる通信リクエストもその発信元ネットワークの「場所」を理由に信頼せず、アイデンティティと動的コンテキストに基づいて常に認証・認可・暗号化を実施するセキュリティモデルです。 米国国立標準技術研究所（NIST）は、これを SP 800-207 として正式に規格化しました。その核心を表す金言が「決して信頼せず、常に検証せよ（Never Trust, Always Verify）」です。

旧来のセキュリティモデルは、いわば中世の「城と堀」でした。ファイアウォールと企業VPNが深い堀を形成し、跳ね橋を渡って一度城門を通過した人間は、城内のほぼすべての部屋へ自由に立ち入ることが許されていました。アプリケーション、物理サーバー、そして全従業員が同一のオフィスビルの中に閉じていた時代には、この境界防御は十分に機能していました。しかし現代において、その前提は完全に崩壊しています。

1.1 3つの不可逆な構造変化

1. アプリケーションのクラウド移行： ワークロードはマルチクラウド、プライベートクラウド、オンプレミスに分散しています。すべてを囲い込める単一の境界壁はもはや存在しません。
2. 従業員の分散化： 自宅、カフェ、コワーキングスペースなど、組織の管理が及ばない多様なネットワーク環境からアクセスが行われます。
3. 内部トラフィックの爆発的増大： マイクロサービス化により、単一のユーザー操作が内部で7〜8回のマイクロサービス間通信を誘発します。トラフィックの過半数は「東西方向（サービス間）」となり、境界ファイアウォールからは全く見えなくなりました。

この変化がもたらす最大の脅威が**横方向への侵害拡大（ラテラルムーブメント: Lateral Movement）**です。単一の従業員資格情報が漏洩したり、コンテナの脆弱性が1つ突かれただけで、侵入者は「社内ネットワークの正規住人」としての特権を獲得し、同一サブネット内の重要サーバーへ自由に攻撃の手を伸ばすことができてしまいます。

図1：侵害された同一の端末における挙動比較。境界防御モデルでは被害半径（ブラストレイディウス）が社内網全域に及びますが、ゼロトラストでは明示的に認可されたリソース境界内に完全に封じ込められます。

1.2 ゼロトラストを支える3大原則

これら3つの原則は、ゼロトラストを規定するあらゆる公的仕様の土台であり、具体的な実装技術へと直結しています。

身近な現実の例えとして最も適切なのが、**「外堀のない最新の高セキュリティオフィスビル」**です。建物の周囲に堀はありませんが、エレベーターに乗る際、各フロアに入る際、そしてサーバールームの扉を開ける際、その都度社員証カードをかざす必要があります。システムは「社員証の有効期限」「会社支給の合规PCを携帯しているか」「今この瞬間にこの部屋に入る権限が職位上認められているか」を瞬時に判定します。ロビーに入れたからといって、奥の役員室に無条件で入れるわけではないのです。

2. NIST SP 800-207 の基石：4つのコア論理エンティティ

NIST SP 800-207 における「論理エンティティ」とは、システムアーキテクチャ上の責務（ロール）を定義したものであり、個別の市販ソフトウェア製品を指すものではありません。 1つの製品が複数の論理エンティティの機能を兼ね備えることもあれば、1つの論理エンティティが複数のコンポーネントによって分散実装されることもあります。製品ベンダーのマーケティングに惑わされずに本質を見抜くためには、この論理モデルの理解が欠かせません。

NIST はアーキテクチャを構成する4つのコア論理エンティティとして、サブジェクト (Subject)、リソース (Resource)、ポリシー適用ポイント (Policy Enforcement Point: PEP)、そして ポリシー決定ポイント (Policy Decision Point: PDP) を定義しています。さらに PDP は、ポリシーエンジンとポリシー管理者の2つに明確に分割されます。

2.1 サブジェクトとリソース：人間だけがアクタではない

• サブジェクト (Subject)： リクエストの発行主体。MacBook から操作を行うリモートのSREエンジニアはもちろん、Kubernetes 内の checkout-service Pod、CI/CD パイプラインの実行ランナー、自律型 AI エージェントもすべてサブジェクトに該当します。
• リソース (Resource)： アクセス対象となる資産。本番の PostgreSQL データベース、社内専用の gRPC 決済エンドポイント、重要データが格納されたクラウドストレージバケットなどです。

ここで Pod や AI エージェントを明示的にサブジェクトとして扱う視点が極めて重要です。マイクロサービスやソフトウェアはパスワードを入力できません。そのため、これら機械のための暗号学的アイデンティティ基盤（後述のアイデンティティプレーン）が必要不可欠となります。

2.2 ポリシー適用ポイント (PEP)：独自の認可判断を持たない実行の「筋肉」

ポリシー適用ポイント (PEP) は、実際のトラフィック経路上に配置されます。その役割は明快です。通信をインラインで遮断し、コントロールプレーンに判定を仰ぎ、返された指示（通過許可、パケット破棄、チャレンジ要求、セッション即時強制切断）を忠実に執行します。PEP 自身は複雑な認可ロジックを保持しません。

現実の比喩で言えば、駅の自動改札機や要所の警備員に相当します。警備員は自ら規則を考案するのではなく、警備本部の判断指示システムに従ってゲートを開閉します。

実環境における PEP の具体例としては、コンテナにサイドカーとして添えられる Envoy プロキシ、Web アプリの前段に立つ Google Cloud Identity-Aware Proxy (IAP)、Cloudflare Access などの ZTNA コネクタが挙げられます。

2.3 ポリシー決定ポイント (PDP)：なぜ NIST は「頭脳」と「司令官」を分けるのか

ポリシー決定ポイント (PDP) はトラフィック経路の外側に位置し、2つのサブコンポーネントから構成されます。

• ポリシーエンジン (Policy Engine: PE)： 認可判定を下す「頭脳」。企業ポリシーと収集されたコンテキストを照合し、「サブジェクト S は、現在のコンテキスト C のもとで、リソース R に対するアクション A を実行可能か？」 という問いに対して確定的な真偽値を返します。具体例：Open Policy Agent (OPA/Rego)、AWS Cedar、Google BeyondCorp の Access Context Manager (ACM)。
• ポリシー管理者 (Policy Administrator: PA)： 実行指示を取り仕切る「司令官」。PE が許可を出した場合、PA は PEP が通信を開通させるために必要な短期チケット、mTLS証明書、トークンを発行します。逆に拒否判定が下った場合は、PEP に対してコネクション切断コマンドを送出します。具体例：プロキシに構成や証明書を配布する Istio の istiod、ZTNA セッションブローカー。

なぜ「決定（判定）」と「執行（適用）」を物理的・論理的に分離するのでしょうか。最大の理由は、データプレーンのレイテンシとスループットを保護するためです。 PEP が判定結果をローカルキャッシュしたり、暗号署名された短期トークンをインメモリでオフライン検証できるようにすることで、大半のパケットが遠隔の PDP との同期通信を待つ必要がなくなります。これこそが、「ゼロトラストは通信を遅くする」という懸念を解消するための基本原則です。

図2：4つの論理エンティティを経由する1つのリクエストの流れ。データプレーンの実通信パス（サブジェクト $\rightarrow$ PEP $\rightarrow$ リソース）と、コントロールプレーンの判定ループ（管理者とエンジン）が明確に分離されています。

3. 論理エンティティからインフラへ：本番環境を支える4つのプレーン

アーキテクチャにおける「プレーン（Plane）」とは、同一の機能責務を担うインフラストラクチャ群のまとまりを指します。 第2節の論理エンティティが「誰が何を担うか」を定義したのに対し、プレーンは「それらが実際のインフラ上でどこに配置されるか」を示します。システムは、データプレーン、コントロールプレーン、アイデンティティプレーン、そしてコンテキスト＆シグナルプレーンの4つに大別されます。

なお、NIST SP 800-207 の原文仕様書では主に「コントロールプレーン」と「データプレーン」の2面を定義し、ID情報や端末監視、脅威インテリジェンスを外部の補足入力として整理しています。本記事でそれらを「アイデンティティプレーン」および「コンテキスト＆シグナルプレーン」として独立したプレーンに昇格させて整理しているのは、現代のクラウドネイティブ環境においてコンポーネントの配置関係を直感的に把握しやすくするための実践的な分類フレームワークです。

図3：4つのアーキテクチャプレーンと各コンポーネントの配置関係。破線はコントロールプレーンに集約されるコンテキスト情報、太い実線は実際の通信トラフィックを表します。

3.1 データプレーンとコントロールプレーン

データプレーン (Data Plane) は、サブジェクトから PEP を経由してリソースへと至る、実際のビジネスデータを運びます。ここにあるコンポーネントは、超高速で動作し、障害発生時にもフェイルクローズ（安全な遮断）を保証しなければなりません。具体例：Pod 脇の Envoy サイドカー、Linux カーネル内の eBPF データパス、社内 Web アプリの前段に位置するリバースプロキシ。

コントロールプレーン (Control Plane) は、PDP が常駐する場所です。パケット転送のインラインパス上に存在しないため、より高度で複雑な計算処理を行うことが許容されます。具体例：OPA や Cedar のエンジン、数千ものプロキシへ構成と証明書を動的に流し込む istiod。

Kubernetes を触ったことがあれば、直感的に理解できるはずです。API サーバーや各種コントローラが「コントロールプレーン」として理想状態を計算し、各ノードの kubelet やコンテナランタイムが「データプレーン」として実際にコンテナを動かすのと全く同じ役割分担です。

3.2 アイデンティティプレーン：人間と機械のための暗号学的身元証明

いかに強固なポリシーを定義しても、呼び出し元の身元が詐称可能であれば意味をなしません。このプレーンは「誰が、あるいは何がアクセスを求めているのか」を暗号学的に証明します。

• 人間向け (Humans)： OIDC または SAML 2.0 に対応した IdP（Okta、Microsoft Entra ID、Google Cloud Identity 等）を用い、FIDO2 ハードウェアキーや多要素認証（MFA）を強制します。
• ワークロード向け (Workloads)： 機械はパスワードを持たないため、CNCF 標準規格である SPIFFE / SPIRE が用いられます。各サービスには、spiffe://prod.example.internal/ns/finance/sa/payment-processor のような URI を含む短命の X.509 SVID 証明書が動的に配布されます。SPIRE エージェントは、まず TPM やクラウドのインスタンスメタデータを用いてノード自身の正当性を証明し、次いで Linux カーネルの /proc/<PID> を検査してコンテナの UID、K8s 名前空間、サービスアカウントを検証した上で、ローカルの UNIX ドメインソケット経由で安全に証明書を手渡します。

この仕組みにより、ワークロードのアイデンティティが動的な IP アドレスから完全に切り離されるという決定的な利点が生まれます。Pod が再スケジューリングされて IP が変わっても、暗号化された身元証明は変わりません。

3.3 コンテキスト＆シグナルプレーン：動的テレメトリをポリシーの入力へ変換する

認証が成功したとしても、それは「そのユーザーが本人である」と確認できたに過ぎません。利用している端末にマルウェアが潜伏していないか、起動中のプロセスがランサムウェアの挙動を示していないかは別問題です。このプレーンは、端末の健全性や環境リスクをリアルタイムに収集し、ポリシーエンジンへ供給します。

このプレーンの存在によって、初めて「継続的検証」が実現します。午前 9:00 のログイン時に下された「許可」の判断は、9:15 にシグナルが悪化した場合、即座に「拒否」へと覆されます。

4. 運用ドメイン A：南北向 (North-South) —— コンテキスト認識型プロキシによる VPN の置き換え

南北向トラフィックとは、企業の外部にいるユーザー（従業員、外部委託先、ビジネスパートナー）が、パブリックネットワークを越えて社内アプリケーションへアクセスする通信を指します。 ゼロトラストにおける南北向の最大のゴールは、企業 VPN の完全な廃止です。利用者の端末を社内ネットワークに直接接続させることは二度とせず、PEP として機能するリバースプロキシが各アプリケーションへの接続を個別に仲介します。具体例：Google BeyondCorp Enterprise (Cloud IAP)、Cloudflare Access、Zscaler Private Access。

4.1 判定モデル：南北向の信頼関数

南北向において、ポリシーエンジンによるアクセス可否の判定は、以下のような多元関数として表現できます。

$\text{Access Granted} = f(\text{User Identity}, \text{Device Health}, \text{Contextual Risk}, \text{Resource Sensitivity})$

同一の正当な従業員であっても、アクセス先のリソースの重要度によって要求される水準は動的に変化します。管理下の端末から社内 Wiki を閲覧するだけであれば標準的な SSO セッションで十分ですが、本番データベースの管理コンソールを開く場合には、ハードウェアキーによる MFA、最新の OS パッチ適用、指定された承認済み地域からの接続が追加で要求されます。

4.2 アイデンティティ認識型プロキシ (IAP) の内部処理フロー

本番環境の IAP における代表的な処理フローは以下の4ステップで進行します。

1. ユーザーが社内アプリにアクセスすると、PEP であるプロキシが未認証通信をインターセプトし、IdP へリダイレクトして認証と MFA を要求します。
2. プロキシは取得したユーザー情報と、クライアントから収集された端末健全性データ（コンテキストプレーンから提供）を合わせ、ポリシーエンジンへ認可判定を照会します。
3. 判定が許可となった場合、プロキシはクライアントから送られてきたヘッダー（偽装の可能性がある X-Forwarded-User 等）を完全に削除した上で、プロキシ自体の秘密鍵で暗号署名した内部用アサーショントークン (Signed JWT) を新たに生成・注入してバックエンドへ転送します。
4. バックエンドアプリケーションは自前で複雑な認証機構を実装する必要がなく、プロキシの公開鍵を用いてそのアサーションの署名と有効期限を検証するだけで、安全にユーザーを特定できます。

ステップ3は南北向アーキテクチャの要です。アプリケーションは「自端末に TCP 到達できたパケット」を盲信することをやめ、「信頼できるプロキシの有効な署名を持つリクエスト」のみを受け入れるようになります。

4.3 継続的検証の実践：セッション途中のリアルタイム強制切断

セッション確立時の静的な検証だけでは、ログイン後の端末乗っ取りに対抗できません。以下のようなタイムラインを想定してみます。

• 09:00： 開発者が会社支給の端末から社内システムにアクセス。MFA を通過し、EDR も正常と報告したため、プロキシはセッションを確立。
• 09:15： 開発者の端末上で情報窃取型マルウェアが不正実行され、EDR が異常なメモリダンプの挙動を検知。
• 09:15 + 数秒： EDR が即座にセキュリティイベントを発行。コントロールプレーンのポリシーエンジンがこれを受信して再評価を行い、ポリシー管理者が PEP へセッション破棄を指令。次のパケットから即座に通信が遮断されます。

このリアルタイムなイベント連携を支える業界標準が、OpenID Foundation の Shared Signals and Events (SSF) に属する Continuous Access Evaluation Protocol (CAEP) です。イベントは暗号署名された Security Event Token (SET, RFC 8417) として伝送されます。デコードされた device-compliance-change（端末コンプライアンス状態変更）イベントの例を以下に示します。

Copy{
  "iss": "https://edr.example.com",
  "jti": "24c63fb56e5a2d77a6956d147f0f9f4b",
  "iat": 1761802500,
  "aud": "https://zt-controller.example.com",
  "sub_id": {
    "format": "email",
    "email": "dev@example.com"
  },
  "events": {
    "https://schemas.openid.net/secevent/caep/event-type/device-compliance-change": {
      "event_timestamp": 1761802497,
      "previous_status": "compliant",
      "current_status": "not-compliant",
      "reason_admin": {
        "en": "EDR: credential-dumping behavior detected"
      }
    }
  }
}

（注：上記は標準的な構造を説明するための概念例です。実運用のシステム構築時には、OpenID の最新ドラフト仕様におけるフィールド名をご確認ください。）

図4：同期的な業務アクセス経路（1-2）と、非同期な脅威検知・セッション即時遮断ループ（A-D）の連携関係。

5. 運用ドメイン B：東西向 (East-West) —— 敵対的な内部ネットワークにおけるマイクロセグメンテーション

東西向トラフィックとは、同一クラスタ内、同一VPC内、またはハイブリッド環境におけるワークロード間（サービス間）の通信を指します。 この環境にはパスワードを都度入力する人間は介在しません。東西向における第一の鉄則は、「IP アドレスやサブネット CIDR には、認可上の重みを一切持たせない」 ということです。

5.1 東西向ゼロトラストが解決する致命的課題

設定ファイルを並べる前に、東西向の保護を怠った場合にどのような障害・侵害が発生するのかを整理します。

5.2 多層防御を支える3つの技術レイヤー

Kubernetes 等のコンテナ環境において、東西向のゼロトラストは以下の3つのレイヤーが重なり合って成立します。

1. 暗号学的ワークロード識別基盤 (SPIFFE/SPIRE)： 稼働中の各 Pod に対し、改ざん不能な X.509 SVID 証明書を自動的にプロビジョニングします（第 3.2 節参照）。
2. トランスポート層暗号化と L7 認可 (Service Mesh Envoy PEP)： Pod に寄り添う Envoy プロキシが通信を中継し、厳格な mTLS 1.3 を確立した上で、相手の SPIFFE ID を読み取り、「edge-tier の ID を持つ Pod からの POST /v1/transactions のみ許可」といった精緻なルールを適用します。
3. パケットレベルの物理的遮断 (CNI L3/L4 NetworkPolicy)： Linux カーネル層や CNI プラグイン（Calico、Cilium eBPF など）に設定されたデフォルト全拒否（Default-Deny）のネットワークポリシーにより、万が一プロキシのトラフィック転送ルールをバイパスしようとする不審パケットが存在しても、カーネルのネットワークスタックが直接パケットをドロップします。

東西向の代表的なアーキテクチャモデルには、それぞれわかりやすい比喩があります。

• Sidecar 方式： クラスター内のすべてのサービス Pod に対し、専属の「私設ボディーガード」を常駐させて監視させる形態です。
• Sidecarless（サイドカーレス）方式（Istio Ambient や Cilium eBPF）： ビル全体に「スマートセンサー付きの床」を敷き詰めるような形態です。ノード単位のコンポーネントが L4 の暗号化とアイデンティティ転送をカーネル空間で一括処理し、高度な L7 検査が必要な場合のみ専用の共有プロキシへトラフィックを迂回させるため、大幅な省リソース化が図れます。

図5：東西向のゼロトラスト防護構造。プロキシ間のエンドツーエンド mTLS 暗号化と、下層の CNI ネットワークポリシーによる二重の防御。

5.3 パフォーマンスへの疑念：東西向マイクロセグメンテーションの実際のレイテンシ

多くのエンジニアが懸念するのが、「すべてのサービス間通信で暗号化とポリシー検査を行ったら、レイテンシが悪化するのではないか」という点です。

結論から言えば、正しく設計されたアーキテクチャであれば問題になりません。なぜなら、すべての証明書検証やアクセスルール照合は、プロキシのローカルインメモリ（C++/Rust 実装）で完結しており、外部のコントロールプレーンへ通信待ち合わせを行うことがないからです。採用するアーキテクチャごとの追加レイテンシの目安は以下の通りです（実務上の参考指標）：

ここから導かれる鉄則はシンプルです。「認可判定ロジックはワークロード直近のメモリまたはカーネル空間に配置し、内部の軽微なRPCごとに遠隔の中央サーバーへ問い合わせる設計を徹底的に避けること」 です。

---

6. 統合：ゼロトラストの統一的メンタルモデル

ゼロトラストとは、単一のセキュリティ製品でもなければ、単純なオン／オフのスイッチでもありません。あらゆる境界において徹底されるべき「アーキテクチャ上の規約」です。 通信がインターネットから社内アプリへ入る「南北向」であっても、クラスタ内のコンテナ同士を行き交う「東西向」であっても、その根底にある基本思考は同一です。すなわち、ポリシー適用ポイントがすべての通信をインラインで捕捉し、ローカルまたはコントロールプレーンの規約に照らし合わせ、偽造不可能な暗号学的アイデンティティと最新の健全性証明を絶えず要求し続けます。

6.1 南北向 vs. 東西向：主要技術次元の比較一覧

論理的な構成要素は共通ですが、実運用において直面する制約や採用プロトコルには明確な違いがあります。

6.2 懐疑論への回答：エンジニア組織で直面する3大反論

社内でゼロトラストへの移行を推進する際、多くのアーキテクトが直面する典型的な3つの反論があります。アーキテクチャの真のメカニズムを理解していれば、これらに自信を持って論理的に回答することができます。

反論 1（経営陣・ビジネス側より）：「すでに高いVPNを導入しているのに、なぜわざわざゼロトラストに投資するのか？」

• 懸念の内容： 現行のファイアウォールとVPNで事故なく運用できているのに、全社的なアクセス基盤を作り直すのはコストの無駄ではないか。
• 技術的事実： VPN が提供するのは大雑把な「ネットワーク全体への暗黙の信頼」です。一度認証を突破されると、社内ネットワーク全体に侵入者が放たれた状態になります。標的型攻撃やランサムウェアが蔓延する現在、たった1台のPCが侵害されただけで、攻撃者は社内の人事、財務、開発サーバーを横断的に探索できてしまいます。ゼロトラストは「社内網への接続」という概念そのものを解体します。ユーザーは社内インフラの物理ネットワークには決して入れず、端末の健全性評価をクリアした上で、指定の単一アプリケーションのみがプロキシ経由で中継されます。これにより、万が一侵害が発生しても、被害範囲を最小限に局所化できます。

反論 2（開発・インフラチームより）：「全通信で認証や mTLS を行ったら、レイテンシが跳ね上がってシステムが死ぬのでは？」

• 懸念の内容： 内部で毎秒数万〜数十万回も飛び交うマイクロサービスの通信すべてに暗号化とポリシー判定を挟むと、レスポンスが悪化してサービスが破綻するのではないか。
• 技術的事実： ゼロトラストは、判定を行う PDP と執行を行う PEP を明確に分離しています。パケットが飛ぶたびに遠隔の判定サーバーへ問い合わせに行くわけではありません。東西向通信においては、プロキシやカーネル内の eBPF が、あらかじめ同期済みの RBAC 規則と TLS 1.3 のセッション再開機能を利用して、ローカルメモリ上で瞬時に判定と暗号化を完了します。実測される追加レイテンシはサイドカー方式で $1\text{ ms}$ 未満、eBPF 方式では $0.2\text{ ms}$ 未満であり、分散システムのパフォーマンス予算に十分に収まります。

反論 3（セキュリティ・監査部門より）：「社内システムをリバースプロキシ経由で外部公開するのは、プライベート網に隠しておくより危険ではないか？」

• 懸念の内容： 従来はプライベートIPでインターネットから隔絶されていた業務システムを、外部公開されたプロキシの背後に置くのは攻撃対象面を広げる行為ではないか。
• 技術的事実： バックエンドの業務システム自体はパブリックIPを持たず、外部ポートも一切開けません。インターネット側に露出するのは、DDoS対策と WAF で厳密に保護されたプロキシのエッジ窓口のみです。さらに、クライアント証明書、IdP による強固な MFA、そして端末健全性チェックをすべて通過しない限り、バックエンドへ向けた TCP 接続自体が確立されません。認証されない通信はエッジの段階で遮断されるため、単に社内LANに無防備に接続されている状態よりも遥かに高い防御能力を発揮します。

6.3 よくある技術的質問 (FAQ)

NIST SP 800-207 における4つのコア論理エンティティとは何ですか？

サブジェクト（操作を行うユーザーやPod）、リソース（保護対象となるデータやAPI）、ポリシー適用ポイント PEP（通信をインラインで捕捉し指示を実行するプロキシ）、ポリシー決定ポイント PDP（ルールとコンテキストを評価して判定を下す頭脳。内部にポリシーエンジン PE とポリシー管理者 PA を内包）の4つです。

ゼロトラストと従来の企業 VPN の決定的な違いは何ですか？

従来の VPN は境界通過時に一度だけ認証し、内部ネットワーク全体への自由なアクセスを許すため横方向の攻撃に脆弱です。ゼロトラストは「決して信頼せず常に検証せよ」を徹底し、通信の都度、身元と端末状態を評価して特定アプリへのアクセスのみを最小権限で許可します。

ポリシー適用ポイント (PEP) とポリシー決定ポイント (PDP) の違いは何ですか？

PEP は実際の業務通信経路上に配置され、通信の遮断や通過を物理的に執行する役割を担います。PDP は通信経路の外側に位置し、各種セキュリティシグナルを収集・評価してアクセスの可否を判定し、PEP へ執行命令を発行します。

SPIFFE/SPIRE とは何ですか？なぜ東西向ゼロトラストに必要なのですか？

SPIFFE は分散システム内の各ソフトウェアに改ざん不能な暗号学的ID（SVID）を割り当てるオープン標準です。SPIRE はその実装であり、コンテナやノードの属性を自動検証して短命の X.509 証明書を発行・ローテーションすることで、信頼できない IP アドレス認証を完全に排除します。

サービス間のマイクロセグメンテーションは大幅な性能低下を招きますか？

いいえ。判定ロジックと執行が分離されているため、通信ごとの暗号検証とルール適用はノードのローカルメモリやカーネル内で完結します。サイドカー方式での追加レイテンシは通常 1 ミリ秒未満、カーネル内 eBPF 方式では 0.2 ミリ秒未満に収まります。

6.4 今後の展望：API ゲートウェイはどこに位置づけられるのか？

本記事では、NIST SP 800-207 のカノニカルな青写真（4つのエンティティ、4つのプレーン、そして南北向・東西向という2つの運用ドメイン）の全体像を解き明かしました。

しかし、注意深く読まれた方は、1つの明確な空白にお気づきのはずです。ここまでの議論において、エンタープライズの API ゲートウェイ（Apigee 等）や外部パートナー向けの API 管理、コンシューマー資格情報に関する言及は一切登場していません。

実際のエンタープライズ環境において、サービスメッシュはクラスタ内部の機械アイデンティティ管理やトランスポート暗号化には長けていますが、API の収益化、クォータ制限、外部パートナーのセルフサインアップ、ペイロード変換といった機能は一切備えていません。一方で、パブリックロードバランサはエッジ保護を行いますが、業務レベルの API コントラクトを解釈することはできません。

続く第2回では、このギャップを埋めるべく、API ゲートウェイがゼロトラストエコシステムにおいて担う真の役割に迫ります。

• Apigee Hybrid のスプリットプレーン（Split-Plane）構造が、いかに物理レベルで NIST の PDP／PEP 分離モデルを忠実に再現しているか。
• 外部の多様なトークンをエッジで終端し、下流のマイクロサービス群に向けて改ざん不能な内部向け短期 JWT を発行するアイデンティティファサード (Identity Facade) パターン。
• 爆発的に普及する自律型 AI エージェントのセキュリティを担保し、固定 API キーの漏洩を根絶する RFC 8628 (デバイス認可グラント) の実装。
• 高スループットなエンタープライズ環境において、API ゲートウェイとサービスメッシュの境界をどのように整理し、余分なレイテンシ税を回避すべきか。

---

参考文献と補足情報 (Sources and References)

本記事の技術的論拠は、本プロジェクトのゼロトラスト知識ベースおよび業界の公式標準仕様に基づいています。

1. 知識ベースが参照している公開アーキテクチャ・コンポーネント資料

以下は、基礎資料においてゼロトラストのインフラ構成要素を論証するために参照された公開技術文書です（Apigee 製品固有のリンクを除く）：

• Google Cloud Identity-Aware Proxy (IAP) 公開鍵エンドポイント (JWKS) — Google Cloud。南北向のコンテキスト認識フローにおいて、下流の PEP が署名付き JWT アサーション (x-goog-iap-jwt-assertion) を暗号学的に検証するための公開鍵セット（第 4.2 節参照）。
• Google Cloud Web and API Protection (WAAP) — Google Cloud。Cloud Armor (WAF/DDoS) と IAP を統合したエッジ防衛リファレンスアーキテクチャ（第 4.1 節参照）。
• Envoy Proxy SSL/TLS セキュリティアーキテクチャ公式ドキュメント — Envoy Project。データプレーン PEP における相互TLS (mTLS) 設定、CA ルート検証、SAN 証明書マッチングに関する解説（第 3.1 節および第 5.2 節参照）。
• NGINX HTTP SSL モジュール技術仕様 — NGINX Documentation。リバースプロキシにおけるクライアント証明書検証および mTLS 構成に関する技術資料（第 4.2 節参照）。
• F5 BIG-IP Client SSL 認証アーキテクチャ — F5 DevCentral。ハイブリッド環境の ADC におけるハードウェアアクセラレーションによるクライアント証明書検証と mTLS 終端に関する解説（第 4.1 節参照）。
• Google Cloud ロードバランシング概要 — Google Cloud。エッジにおける TLS オフロード、mTLS パススルー転送、NEG バックエンドルーティングに関する解説（第 4.1 節参照）。

2. 公式業界標準およびプロトコル仕様

• NIST Special Publication 800-207: Zero Trust Architecture (2020年8月) — Scott Rose, Oliver Borchert, Stu Mitchell, Sean Connelly. 米国国立標準技術研究所 (NIST). DOI: 10.6028/NIST.SP.800-207. ゼロトラストの4大論理エンティティ、コントロールプレーンとデータプレーンの分離、3大原則を定めた公式基本仕様。
• SPIFFE & SPIRE 仕様ドキュメント — Cloud Native Computing Foundation (CNCF 卒業プロジェクト). ワークロード識別子の URI スキーマおよび X.509 SVID の発行・証明標準。
• OpenID Continuous Access Evaluation Profile (CAEP) / Shared Signals and Events (SSF) — OpenID Foundation Shared Signals Working Group. システム間でのリアルタイムセキュリティイベント連携およびセッション動的失効に関するコア標準。
• RFC 8417: Security Event Token (SET) (2018年7月) — P. Hunt, Ed., et al., Internet Engineering Task Force (IETF). セキュリティイベントを伝送するための暗号署名付き JWT 仕様。

3. 執筆背景およびフレームワークの補足説明

• 執筆者の背景と動機： 冒頭で触れた生成AI時代におけるセキュリティ脅威の増大、および Google Cloud 上で Apigee をサポートする中で培った知見をもとに体系化を試みた経緯は、執筆者個人の実務経験に基づく共有です。
• 「4つのプレーン」分類に関する補足： NIST SP 800-207 の原文では主にコントロールプレーンとデータプレーンが定義されています。本文においてアイデンティティ管理と環境テレメトリを「アイデンティティプレーン」「コンテキスト＆シグナルプレーン」として整理しているのは、大規模クラウドネイティブシステムにおける各コンポーネントの役割を分かりやすくするための実践的な整理法です。
• CAEP ペイロードの例示： 第 4.3 節に掲載した JSON ペイロードは、読者の理解を助けるために標準仕様に準拠して作成した概念的なサンプルです。実際のシステム導入時には、対象ベンダーがサポートする最新の OpenID スキーマ定義をご確認ください。