NIST SP 800-207：ゼロトラストの7原則とアーキテクチャ

「社内ネットワークに接続している」「会社が貸与したパソコンを使っている」という理由だけでは、そのアクセスが安全だとは判断できません。正規のアカウントが盗まれたり、会社の端末がマルウェアに感染したりすることもあるためです。

NIST SP 800-207は、この前提に立ち、必要な人やサービスに、必要なリソースへの、必要最小限のアクセスを認めるための設計と運用を説明した文書です。

本記事は、2020年8月に公開された原文と、PwCコンサルティング合同会社による日本語訳をもとにした要約です。対策例は、原則を理解するために補ったものであり、特定製品の採用を求めるものではありません。

NIST SP 800-207とは

NIST SP 800-207は、日本語で「にすとえすぴーはちひゃくのにひゃくなな」と読みます。

NISTは、アメリカ国立標準技術研究所（National Institute of Standards and Technology）です。 SPはSpecial Publicationの略で、SP 800シリーズでは情報セキュリティに関する指針などを公開しています。

SP 800-207の名称は「Zero Trust Architecture（ゼロトラスト・アーキテクチャ）」です。セキュリティ設計者を主な読者とし、管理者やセキュリティ責任者にも役立つ内容になっています。

ゼロトラストの基本的な考え方に加え、それをシステムに組み込むための構成要素、構成パターン、利用場面、残る脅威、移行の進め方を示しています。誰でも無料で読め、日本の企業でも設計の参考にできます。

ただし、企業ごとの業務や資産を考慮せず、そのまま適用できる一律の導入手順書ではありません。

文書に書かれていること

章	主な内容	読み取れること
第1章：はじめに	背景、目的、文書の構成	境界型防御への依存を見直す理由
第2章：ゼロトラストの基本	定義、7つの基本原則、ネットワークの前提	何を基準にアクセスを認めるか
第3章：論理コンポーネント	PE・PA・PEP、判断に使う情報、構成パターン	判断と制御をどう組み合わせるか
第4章：導入シナリオ	拠点、マルチクラウド、外部委託先、組織間連携など	どの業務で活用できるか
第5章：関連する脅威	判断機構の侵害、障害、認証情報の窃取など	導入後も対策が必要なリスク
第6章：既存の政府指針との関係	RMF、プライバシー、ID管理などとの整合	既存の管理制度と組み合わせる考え方
第7章：移行	現状把握、ポリシー設計、試行、拡大	段階的に導入する方法

付録では、用語、技術や標準化の課題、今後の研究領域も整理されています。

ゼロトラストとZTAの違い

ゼロトラスト（ZT）はアクセス判断の考え方、ゼロトラスト・アーキテクチャ（ZTA）はそれを実現するための設計です。

ZTでは、ネットワーク内に攻撃者がいる可能性を前提とし、ネットワークの場所や資産の所有者だけを理由に、暗黙の信頼を与えません。アクセス要求ごとに、認証、権限、端末の状態などを評価します。

ZTAでは、その考え方を、ID管理、アクセス制御、端末、アプリケーション、ネットワーク、監視、運用ルールなどに落とし込みます。

認証は「誰・何なのか」を確認すること、認可は「何へのアクセスや操作を許すか」を判断することです。ログインに成功しただけで、すべてのシステムを利用できるようにはしません。

なぜ必要なのか

企業のシステムは、社内だけで完結しなくなっています。クラウド、SaaS、在宅勤務、委託先との連携などにより、守る対象とアクセス元が多様化しています。

境界型防御は外部からの侵入を防ぐうえで有用ですが、境界を突破された後の横展開や、内部の不正利用への対策には限界があります。

そこで、社内ネットワーク全体を信頼するのではなく、個々のリソースへのアクセスを制御します。例えば、人事システムにアクセスできる社員でも、給与データを閲覧できるか、変更できるかは、役割や状況に応じて別に判断します。

ゼロトラストの7つの基本原則

第2.1節では、ゼロトラストの設計を導く7つの基本原則（Tenets）を示しています。

これらは設計の指針であり、原文は、すべての原則を完全な形で実装できるとは限らないことも説明しています。 達成状況を確認し、業務とリスクに応じて段階的に近づけていくことが重要です。

原則1：すべてのデータソースとコンピューティングサービスをリソースとみなす

保護対象はサーバーだけではありません。データ、アプリケーション、SaaS、端末、IoT機器なども含めて考えます。企業のリソースにアクセスする個人所有端末も、管理対象として扱う場合があります。

具体例： 顧客データベース、ファイル共有、クラウド管理画面、業務APIなどを棚卸しし、利用者、管理者、情報の機密性を把握します。

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

社内LANやプライベートネットワークであっても、安全だと決めつけません。通信の機密性と完全性を保護し、通信相手を確認します。

具体例： 外部との通信だけでなく、内部のサービス間通信についても、TLSなどによる暗号化や認証を検討します。

原則3：企業リソースへのアクセスはセッション単位で付与する

アクセスは、対象となるリソースとセッションに対して、業務に必要な最小限の権限で認めます。あるリソースへの認証・認可が、別のリソースへのアクセスを自動的に許可するわけではありません。

具体例： 顧客情報の閲覧を許可しても、変更、削除、他システムの利用まで一括で許可しません。

セッション単位の判断は、毎回ユーザーにパスワードを入力させるという意味ではありません。SSOなどを使いながら、対象ごとにアクセス条件を確認する設計も可能です。

原則4：アクセスは、複数の情報を使う動的なポリシーで決定する

ユーザーやサービスのIDだけでなく、端末の状態、利用するアプリケーション、行動、環境などを組み合わせて判断します。リソースの機密性や許容できるリスクも考慮します。

具体例： 給与データには人事担当者だけがアクセスでき、端末が管理下にあり、必要な更新が適用されていることを条件にします。通常と異なるアクセスでは、追加認証や拒否を検討します。

原則5：すべての資産の完全性とセキュリティ状態を監視・測定する

正規の端末でも、状態が変わればリスクは変わります。OSやソフトウェアの更新状況、脆弱性、構成、感染の兆候などを継続的に把握します。

具体例： 重大な脆弱性が未修正の端末や、感染が疑われる端末からのアクセスを制限します。修正後に状態を再評価します。

原則6：認証と認可を動的に行い、アクセスを許可する前に厳密に実施する

接続前に認証と認可を行い、セッション中も必要に応じて信頼性を再評価します。状況の変化に応じ、再認証やアクセスの取り消しを実施します。

具体例： 重要な操作にはMFAを求め、アカウント無効化や端末の感染検知が起きた場合は、継続中のアクセスも見直します。

原則4は主に「何を材料に判断するか」、原則6は「いつ判断し、どう継続的に適用するか」を説明しています。

原則7：資産・通信などの情報を収集し、セキュリティの改善に利用する

資産の状態、ネットワーク、アクセス要求、通信などの情報を集め、ポリシーの作成と改善に使います。

具体例： 認証ログ、端末の検知情報、アプリケーションのアクセスログを分析し、権限の過剰付与や異常なアクセスを見つけます。誤った拒否が多い場合も、原因を調べて条件を調整します。

情報を集めるだけでは不十分です。分析結果をアクセス判断や運用の改善につなげることが、この原則の要点です。

ゼロトラストの論理コンポーネント

第3章では、アクセスを判断する仕組みと、その判断を実施する仕組みを分けて整理しています。「論理コンポーネント」は役割の区分であり、必ず別々の製品やサーバーにするという意味ではありません。

中核となるPE・PA・PEP

コンポーネント	名称	主な役割	人事システムでの例
PE	Policy Engine：ポリシーエンジン	ポリシーと収集情報を使い、アクセスの許可・拒否・取り消しを判断する	担当者の権限、端末状態、要求内容を評価する
PA	Policy Administrator：ポリシーアドミニストレータ	PEの判断に従い、接続の確立・終了を管理し、PEPに指示する	許可されたセッションを開始するよう指示する
PEP	Policy Enforcement Point：ポリシー実施点	主体とリソースの間で接続を許可し、監視し、終了する	ゲートウェイやエージェントなどでアクセスを制御する

PEとPAを合わせた役割は、PDP（Policy Decision Point：ポリシー決定点）と呼ばれます。

アクセスの流れは、おおむね次のようになります。

ユーザーやサービスが、リソースへのアクセスを要求する。
PEがID、権限、端末状態などをポリシーと照合し、判断する。
PAがその判断に従い、PEPに接続の開始・終了を指示する。
PEPがアクセスを制御し、接続を監視する。
新たなリスク情報などに基づき判断を見直し、必要なら接続を終了する。

判断・管理の通信はコントロールプレーン、業務データが流れる通信はデータプレーンとして区別されます。

判断を支えるシステムと情報

PE・PA・PEPだけでは、適切な判断の材料が足りません。文書は、次の情報源や機能も示しています。

情報源・機能	提供する情報や役割
CDM（Continuous Diagnostics and Mitigation）システム	資産の構成、更新状況、脆弱性などの把握と改善
業界のコンプライアンス情報	適用される規制や業界要件に関するポリシー
脅威インテリジェンス	攻撃、マルウェア、脆弱性などの情報
ネットワーク・システムの活動ログ	認証、通信、リソースへのアクセスなどの記録
データアクセスポリシー	誰がどのリソースに何をできるかというルール
PKI（公開鍵基盤）	証明書の発行・管理によるユーザー、端末、サービスなどの識別支援
ID管理システム	アカウント、役割、属性、割り当てられた権限などの管理
SIEM（Security Information and Event Management）システム	セキュリティ情報の集約・分析と、ポリシー改善への活用

例えば、ID管理では「人事担当者」と分かっていても、端末の監視で「感染の疑い」が示されれば、PEはアクセスを拒否する判断ができます。

トラストアルゴリズムとは

トラストアルゴリズムは、PEがアクセスを判断するための処理です。要求内容、主体や資産の属性、過去の行動、脅威情報などを使います。

文書では、条件に合うかを判定する方式や、情報を重み付けしてスコアを計算する方式などを紹介しています。全企業で共通の点数や計算式を指定しているわけではありません。

実現方法は一つではない

第3.1節では、次の3つのアプローチを説明しています。これらは組み合わせて利用できます。

アプローチ	中心となる考え方
拡張されたIDガバナンス	ID、属性、権限を中心にアクセスを判断する
マイクロセグメンテーション	リソースや小さな区画ごとに制御し、横展開を抑える
ネットワーク基盤・SDP	動的な接続制御により、必要な通信経路を提供する

第3.2節では、端末エージェントとゲートウェイ、区画を保護するゲートウェイ、リソースポータル、アプリケーションのサンドボックスなどの配置例も示しています。

導入時は、端末にエージェントを入れられるか、社外の利用者がいるか、対象の通信プロトコルを扱えるか、といった業務上の条件で選びます。

どのような場面で使えるか

第4章は、支社やリモート勤務、マルチクラウド、委託先などの社外利用者、企業間の共同作業、公開・顧客向けサービスを扱っています。

共通する課題は、「自社のネットワークにいるか」だけでは、利用者、端末、対象の安全性や権限を判断できないことです。

一方、匿名で公開するWebページなどに、社員向けと同じ認証条件をそのまま課すわけではありません。対象サービスの性質に合わせ、公開領域と保護が必要な領域の条件を設計します。

ゼロトラストにも残るリスク

第5章は、ゼロトラストを導入してもリスクがなくなるわけではないと説明しています。

リスク	注意すべきこと
判断機構の侵害・設定ミス	PEやPAが侵害されると、不正な許可や拒否につながる。管理権限、変更管理、監査が重要
DoS・ネットワーク障害	判断や接続管理に必要な機能が停止すると、業務アクセスに影響する。可用性・復旧設計が必要
認証情報の窃取・内部不正	正規の権限内の不正は起こり得る。最小権限や行動の監視を継続する
可視性の限界	暗号化通信や管理外端末では見える情報が限られる。メタデータや他の検知情報も使う
監視情報の漏えい	ログや構成情報は攻撃者にも有用。これら自体のアクセス制御が必要
独自仕様への依存	製品間連携や移行が難しくなる場合がある。相互運用性や切り替えコストを確認する
自動化された管理主体の悪用	管理エージェントやAPIの認証情報が悪用される可能性がある。権限と認証を管理する

第6章では、既存のリスク管理やプライバシー、ID管理などとの関係も説明しています。アクセス制御を改善しても、組織全体のセキュリティ管理や事業継続の取り組みは必要です。

導入は現状把握から段階的に進める

第7章では、既存環境を一度に置き換えるのではなく、業務単位で段階的に移行する考え方を示しています。境界型防御とZTAが共存するハイブリッド構成も想定されています。

ステップ	実施すること	整理する内容の例
1. 主体を特定する	利用者、管理者、委託先、サービスアカウントなどを把握する	ID、役割、権限、利用目的
2. 資産を特定する	端末、アプリ、クラウド、データなどを棚卸しする	管理者、構成、状態、管理外資産
3. 主要な業務とリスクを評価する	業務フロー、データフロー、依存関係を整理する	重要度、停止時の影響、移行候補
4. ポリシーを設計する	対象業務の許可条件と拒否条件を決める	対象リソース、主体、操作、端末条件
5. 実現方法を選ぶ	構成とソリューションを比較する	エージェントの要否、ログ、対応プロトコル、業務への影響
6. 試行導入して監視する	判断結果を記録し、業務を妨げないか確認する	誤った許可・拒否、性能、利用者への影響
7. 改善して対象を広げる	ポリシーを調整し、他の業務にも展開する	継続監視、変更時の再評価、次の導入候補

最初の試行では、文書は監視・報告を中心とする運用を勧めています。ただし、認証失敗や明らかに不正な要求まで許可するという意味ではありません。

また、試行対象を選ぶ際は、重要度だけでなく、移行による業務停止のリスクや学習のしやすさも考慮します。十分な知見を得てから、より重要な業務に広げる進め方ができます。

設計で押さえたいこと

SP 800-207が示すのは、製品名ではなく、リソースへのアクセスをどう判断し、制御し、改善するかという設計の考え方です。

まず「誰が、何に、何のためにアクセスするか」を把握します。そのうえで、必要最小限の権限、通信の保護、端末状態の確認、継続的な再評価、ログの活用を組み合わせます。

MFAやネットワーク分割はその一部を支える手段です。個々の対策を導入することに加え、業務のアクセス条件と運用の仕組みを整えることが重要です。

参考資料

主な根拠はNIST SP 800-207の第2.1節、第3章、第4〜7章です。日本語の説明は添付のPwCコンサルティング合同会社による翻訳を参照し、原文と照合しています。

補助的な解説記事：