NIST SP 1800-35「ゼロトラスト実装ガイド」をざっくり読んでみた

未経験でバックエンドエンジニアになった、元看護師の主婦です。
最近、情報セキュリティ分野にハマり、勉強しています。

はじめに

NIST が 2025年6月に最終版（FINAL）として出した 「NIST SP 1800-35: Implementing a Zero Trust Architecture」 を読んだので、要点をまとめてみました。

ゼロトラスト（ZTA）の「概念」を語る資料は世の中にたくさんありますが、これは 「じゃあ実際どう作るの？」を 19パターンの実装例で見せてくれる のが面白いところです。

文書は無料で読めます。

DOI: https://doi.org/10.6028/NIST.SP.1800-35

何の文書なのか？

作っているのは NIST の中にある NCCoE（National Cybersecurity Center of Excellence）。産業界・政府・大学が一緒にセキュリティ課題を解く場所で、2012年にできた組織です。
立ち位置としては、「ゼロトラストの教科書」である NIST SP 800-207 の内容を、実機で形にしてみた ガイド、という感じ。
なので「ゼロトラストって何？」というレベルの人向けではなく、SP 800-207 はもう読んだ前提 で書かれています。連邦政府専用というわけでもなく、一般企業も対象です。

どのくらいの規模でやったの？

技術ベンダー 24社 と組んで（CRADA という共同研究契約のもと）
ラボに 19個の実装（"builds"） を作って実証
それぞれについて、構成・使った製品・統合のしかた・試したユースケースを細かく記録

…という、なかなか手の込んだプロジェクトです。

対象に入るもの・入らないもの

対象：ノートPC・デスクトップ・サーバー・モバイルなど、よくある普通の企業 IT 環境向けの ZTA。資産や通信フローの「発見（discovery）」も含みます。
対象外：産業制御システム（ICS）、OT 環境、IoT デバイス向けの ZTA。あとデータの分類みたいな話も今回はスコープ外です。

ゼロトラストってどういうもの？（この文書での説明）

ざっくり言うと、ZTA の狙いは 「データ漏洩を防ぐ」と「侵入された後に中で広がられるのを防ぐ（横展開の阻止）」 の2つです。

文書では特徴としてこんなことが挙げられています。

ユーザーがどこにいても、どんなデバイス（会社管理でも私物でも）でも、アクセスをちゃんとさばける
データや資産を、オンプレかクラウドかに関係なく守れる
攻撃者が中で動き回りにくくなる。内部の人間も「中にいるから信頼」とはしない
常時リアルタイムで監視・ログ・リスク評価をやる

ポイントは リスクベース なところ。アクセス要求を一度通したら終わりではなく、ずっと「これ大丈夫？」と見続けます。

アーキテクチャの基本

中心になる3つの部品

部品	略称	ざっくりした役割
Policy Engine	PE	「通す／通さない」を判断する頭脳
Policy Administrator	PA	判断を受けて、実際にセッションを張ったり管理したり
Policy Enforcement Point	PEP	現場でアクセスを許可・遮断する門番

PE と PA をセットで PDP（Policy Decision Point） と呼ぶことが多いです。

判断を助ける脇役たち

PDP が判断するための材料（データやルール）を渡してくれるのが、こちらのコンポーネント群。

ICAM（ID・資格情報・アクセス管理）
エンドポイントセキュリティ（EDR / EPP）
セキュリティ分析
データセキュリティ
リソース保護

これらが出してくる判断材料を PIP（Policy Information Point） と呼びます。図にすると「単純な部品が PDP にぶら下がってる」ように見えますが、実際は ICAM や EDR/EPP なんかは 裏でかなり複雑なインフラを抱えている ことが多い、と文書も注意しています。

動きは3つのプロセスで整理

Resource Management — R()：リソース自身の認証と健全性チェック。オンラインの間も定期的に再チェック。
Session Initiation — I()：ユーザーとリソースが初めてつながるまでの流れ（I(1)〜I(5)、順番通り）。
Session Management — S()：つながった後、PDP がセッションを継続的に見張る（S(A)〜S(D)、順番は特にない）。

いきなり完璧を目指さない「段階的」アプローチ

このプロジェクトは、まっさらなラボに「よくある企業環境」を作ってから、少しずつ ZTA に進化させていきました。多くの企業も「いきなり全部入れ替え」ではなく 既存環境から徐々に育てる はずだよね、という考え方です。

フェーズは3段階

EIG Crawl フェーズ
- EIG（Enhanced Identity Governance）= ID を軸にした制御で、ZTA の土台になる部分。
- まだ クラウドは扱わず、オンプレのリソース保護だけ。
- ICAM・エンドポイント・セキュリティ分析（SIEM のみ）に絞り、ICAM が PDP も兼ねる構成。
EIG Run フェーズ
- Crawl の上に積み増して、制約を少し緩める。PDP を ICAM 製品が担わなくてもよくなる。
- オンプレに加えて クラウド上のリソースも保護対象に。
- 新しいデバイスの発見、ルール違反デバイスの遮断、エンドポイント〜リソース間のトンネル確立などができるように。
SDP / マイクロセグメンテーション / SASE フェーズ
- もう制約なし。フルスペックの構成。
- マイクロセグメンテーション：リソースを専用ネットワークに切り分けたり、エンドポイントにエージェントを置いたり。
- SDP：アクセス判断に応じてネットワーク構成を組み替える。
- SASE：SD-WAN・SWG・CASB・NGFW・ZTNA をまとめてサービスとして提供。

19個の実装、ぜんぶ一覧

各 Build は「どの製品を Policy Engine（頭脳）にしたか」と「どのアプローチか」で整理されています（文書の Table 4-1 / 6-1 ベース）。

EIG Crawl（3件）

Build	Policy Engine	アーキテクチャ
E1B1	Okta Identity Cloud / Ivanti Access ZSO	EIG Crawl
E2B1	Ping Identity PingFederate	EIG Crawl
E3B1	Azure AD (Conditional Access)	EIG Crawl

EIG Run（3件）

Build	Policy Engine	アーキテクチャ
E1B2	Zscaler ZPA Central Authority (CA)	EIG Run
E3B2	Microsoft Azure AD (Conditional Access) / Intune / Forescout eyeControl / eyeExtend	EIG Run
E4B3	IBM Security Verify	EIG Run

SDP / マイクロセグメンテーション / SASE（13件）

Build	Policy Engine	アーキテクチャ
E1B3	Zscaler ZPA Central Authority (CA)	SDP
E2B3	Ping Identity PingFederate / Cisco ISE / Cisco Secure Workload	Microsegmentation
E3B3	Microsoft Azure AD (Conditional Access) / Intune / Sentinel / Forescout eyeControl / eyeExtend	SDP + Microsegmentation
E1B4	Appgate SDP Controller	SDP
E2B4	Symantec Cloud SWG / Symantec ZTNA / Symantec CASB	SDP + SASE
E3B4	F5 BIG-IP / F5 NGINX Plus / Forescout eyeControl / eyeExtend	SDP
E4B4	VMware Workspace ONE Access / UAG / NSX-T	SDP + Microsegmentation + EIG
E1B5	Palo Alto Networks NGFW / Prisma Access	SASE + Microsegmentation
E2B5	Lookout SSE / Okta Identity Cloud	SDP + SASE
E3B5	Microsoft Entra Conditional Access / Microsoft Security Service Edge	SDP + SASE
E4B5	AWS Verified Access / Amazon VPC Lattice	SDP + Microsegmentation
E1B6	Ivanti Neurons for Zero Trust Access	SDP + Microsegmentation
E2B6	Google CEP – Access Context Manager	SASE

文書中の注記：VMware の End User Computing 部門の製品を入れた後で、VMware は Broadcom に買収され、その後この部門は Omnissa LLC として独立・再編されました。Microsoft 側も「Azure AD → Entra ID」「Defender for Cloud Apps → Defender for Apps」、Tenable も「Tenable.ad → Tenable Identity Exposure」と名前が変わっています。

やってみて分かったこと（General Findings）

「これは外せない」とされた基本能力

アクセスを通すか、そしてセッションを続けさせるかを判断するうえで、土台になるとされた能力。

要求してきたユーザーの認証＆定期的な再認証
要求してきたエンドポイントの認証＆定期的な再認証
アクセスされる側（リソースをホストしているエンドポイント）の認証＆定期的な再認証
認証・再認証には、認可・再認可もセットで含む

さらに「できればやりたい」とされた能力。

要求元エンドポイントの健全性チェック＆定期的な再チェック
リソース側エンドポイントの健全性チェック＆定期的な再チェック

EIG Crawl で気づいたこと

多くの製品は、ICAM を PDP として動かすための 標準連携（out-of-the-box）が意外と揃っていない。
ルーター・スイッチ・ファイアウォールみたいなネットワーク系の PEP は、普通は ICAM と直接つながらない（ID 対応のものなら別）。
E1B1・E3B1 では、要求元ユーザー／エンドポイントの認証・健全性チェックはできたものの、アクセスされる側（リソースをホストするエンドポイント）のチェックまではできなかった。

EIG Run で気づいたこと

要求元エンドポイントから社内リソースへの 安全な直接トンネル を張ったり、コネクタでリソースをプロキシ化したり、クラウド上のリソースに（社内をぐるっと経由せず）直接アクセスしたり、といったことを実証。
E1B2（Zscaler）は、組む相手に EPP ベンダーがいなかったせいで、エンドポイントの問題を自動で直す仕組みがない／信頼スコアを出せない という制約がはっきり出ました。
ここでの教訓：ちゃんと互いに連携できる部品同士を選ぼう、ということ。

SDP / マイクロセグメンテーション / SASE で気づいたこと

効果を出すには、PDP がいろんなセキュリティツールとつながって、アクセスごとのリスクをリアルタイムに測れることが大事。
ZTA は PDP が複数あるのが普通。すると ポリシーが1か所にまとまらず、あちこちに散らばる。これが「全体として何を許可してるんだっけ？」を分かりにくくする。
しかも複数の PDP は普段つながっておらず、情報を共有しない。片方は「このエンドポイント怪しい」と知っていても、もう片方は知らない、みたいなことが起きる。→ PDP 同士で情報を共有できる作りが理想。
SIEM / SOAR が持っている情報や、データ保護ツールの情報、行動分析の結果なんかも、できればリアルタイムで PDP に渡したい。

機能の実証（Functional Demonstrations）

どうやって試したか

手動と自動の2本立て。MFA みたいに人の操作が要るものは手動。両方混ぜたハイブリッドもあり。
ラボ全体に Mandiant MSV（Security Validation）を入れて、攻撃者役を演じさせてセキュリティ制御がちゃんと効くか検証。
各企業が自分の監査用に MSV を使うパターンと、NCCoE チームが全体を横断監査するための「overarching director」を別チャネルで動かすパターンの、2役こなす構成。
MSV protective theater：マルウェア感染テストみたいな「壊す系」の検証を、本番に影響を出さずにやれる仮想環境。

試した8つのユースケース

記号	ユースケース
A	発見と識別
B	自社発行 ID でのアクセス
C	フェデレーション ID（信頼する他組織の ID）
D	Other-ID（他組織発行だけど登録済みの ID）
E	ゲスト（ID なし）のアクセス
F	信頼度・セッションの再評価
G	サービス間（API 同士）のやりとり
H	データの機密度に応じたアクセス

各ユースケースの中にさらに細かいシナリオが用意されていて、たとえば Use Case F だけでも「セッション中に再認証が失敗して切断」「準拠状態が改善したので再許可」「怪しいエンドポイントからのアクセスを拒否・切断」など、F-1〜F-17 まであります。

ゼロトラスト導入の道のり（7ステップ）

ラボでの経験から、「これから ZTA をやる組織はこう進めるといいよ」というステップが示されています。

まず棚卸し
持っている資産（ハード・ソフト・アプリ・データ・サービス）を全部把握する。見落とすと、その分守られないので。
アクセスポリシーを決める
最小権限と職務分離が基本。原則「デフォルトは拒否」で、必要なぶんだけ許可。実際のアクセスパターンを観測してから決めると、厳しすぎて業務が止まる事態を避けられる。
今ある武器を確認する
ほとんどの組織はゼロからじゃない。既存の技術を活かしつつ、新しく入れるものがちゃんと連携できるかを見極める。
データの価値で優先度をつけてギャップを埋める
大事なリソースは専用ゾーンに隔離、そうでもないものは相乗りでOK。制御はアプリ・ホスト・ネットワークの複数レベルでかける。
段階的に部品を入れていく
ICAM を土台にして、リスクに応じた MFA を強く推奨。エンドポイント保護を組み合わせ、あとは必要に応じて少しずつ足していく。
ちゃんと効いてるか検証する
全トラフィックを常時監視して、「決めたポリシー通りに動いてるか」を継続チェック。オンプレ／クラウド、管理／私物デバイスなど、いろんなパターンで定期的にテスト。
環境の変化に合わせて改善し続ける
ZTA は一度作って終わりじゃなく、ずっと続くプロセス。新しい脅威への対応や、行動ベースでゼロデイを検知する仕組みを取り入れ、CISO・セキュリティチームが構成やポリシーを見直し続ける。

どこにマッピングしてるの？

文書では、ZTA のセキュリティ特性を以下にひも付けています。

NIST Cybersecurity Framework（CSF）1.1 と 2.0
NIST SP 800-53 Rev.5
NIST critical software security measures（重要ソフトウェアのセキュリティ対策）

このマッピングは2つの問いに答えるためのもの。

なぜ ZTA をやるべき？ → ZTA を入れると、CSF や SP 800-53 などの要件達成にも役立つよ、を示す。
どう ZTA をやる？ → 今ある CSF / SP 800-53 などの実装が、ZTA 構築をどう後押しできるか、を示す。

マッピングの作法は NIST IR 8477 の supportive relationship（Supports / Is Supported By / Equivalent）に従っています。

読んでみての所感

特に「なるほど」と思ったところを、本文の記述に沿って。

「これが正解」という単一のアーキテクチャはない。文書は何度も「全組織に最適な単一の移行方法は存在しない」「ZTA は技術仕様の集合ではなく、概念と原則の集合」と言っています。自分たちの要件・リスク許容度・既存資産に合わせて設計するしかない。
段階的に育てるのが現実的。Crawl → Run → SDP/SASE という流れは、まさに「既存環境から少しずつ」を体現したもの。
連携できるかどうかが勝負。EPP がいない、PDP 同士がつながらない、といった「連携の欠如」が制約として何度も出てきます。製品を選ぶときは標準連携の有無をちゃんと見ましょう、というのが刺さりました。
ポリシーが散らばる問題。PDP が複数あるとルールがあちこちに分散するので、「どのルールがどこにあるか」を意識して管理しよう、というのは実務的に重要そう。
結局は「棚卸し」と「検証し続けること」。完全な資産インベントリと、運用後もずっと監査・検証を続ける姿勢が、ZTA を機能させる土台になっているのが印象的でした。

参考

NIST SP 1800-35, Implementing a Zero Trust Architecture（2025年6月, FINAL）
https://doi.org/10.6028/NIST.SP.1800-35
NIST SP 800-207, Zero Trust Architecture（2020）
https://doi.org/10.6028/NIST.SP.800-207
NIST CSF 2.0（NIST CSWP 29）
https://doi.org/10.6028/NIST.CSWP.29
NIST SP 800-53 Rev.5
https://doi.org/10.6028/NIST.SP.800-53r5
NIST IR 8477
https://doi.org/10.6028/NIST.IR.8477