【解説】NISTが定義する「ゼロトラスト」7つの基本原則

本記事では、ゼロトラストアーキテクチャのバイブルとされる米国国立標準技術研究所（NIST）の文書「NIST SP 800-207」に基づき、ゼロトラストを構成する「7つの基本原則」を徹底的に解説します。

Table of Contents

なぜ今、NIST SP 800-207なのか？

7つの原則に入る前に、前提を整理しましょう。なぜ従来のファイアウォールやVPNでは不十分なのでしょうか。それは、守るべき「境界」が消滅したからです。

クラウドサービスの利用、テレワークによる社外からのアクセス、モバイルデバイスの多様化。これらにより、データは社内外のあらゆる場所に分散しました。もはや「内側」という安全地帯は存在しません。

NIST SP 800-207は、このカオスな状況において「どのようにシステムを設計すれば安全を担保できるか」という技術的な正解を示した文書です。ここで定義される7つの原則は、ゼロトラスト製品を選定する際の基準であり、自社のセキュリティレベルを測るための絶対的な物差しとなります。

徹底解説：ゼロトラストの7つの基本原則

それでは、NISTが定義する7つの原則を一つひとつ詳細に見ていきましょう。これらは独立したものではなく、互いに密接に関連し合いながら一つの堅牢なシステムを形成します。

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

【概念の拡張】 従来のセキュリティでは、「守るべきもの（リソース）」といえば、社内のファイルサーバーや顧客データベースといった特定の重要資産を指すことが一般的でした。しかし、ゼロトラストではこの定義を極限まで拡張します。

【具体的な解釈】 ネットワークに接続される「あらゆるもの」がリソースです。

デバイス: 従業員のPCやスマートフォンはもちろん、プリンター、IP電話、会議室のモニター、工場のIoTセンサー、空調管理システムまで。
クラウド: SaaS（Microsoft 365, Salesforceなど）、IaaS上の仮想サーバー、コンテナ、サーバーレス機能。
データ: データベースの中身だけでなく、APIがやり取りする個々のデータパケットやログデータ。

【ここが重要】 「これは重要度が低い端末だから管理外でいい」という例外を一切認めません。攻撃者は最も弱いデバイス（例えば管理されていないIoT機器）を踏み台にしてネットワークに侵入し、重要資産へと横展開（ラテラルムーブメント）を行うからです。すべてを管理対象として認識することが、ゼロトラストの第一歩です。

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

【境界の撤廃】 「社内LANからのアクセスだから安全」「VPNを経由しているから信頼できる」という考え方を完全に捨て去ります。ゼロトラスト環境において、ネットワークの「場所」は信頼の根拠になりません。

【具体的な解釈】

信頼済みゾーンの廃止: 社内の会議室からのアクセスであっても、スタバのWi-Fiからのアクセスであっても、まったく同じレベルの脅威として扱います。
暗号化の強制: 内部ネットワーク上の通信であっても、すべて暗号化（TLSなど）が必要です。「社内だから平文通信でいい」という甘えは許されません。
認証の必須化: 通信が発生するたびに、それが正当なものであるかを確認します。

【ここが重要】 これは、かつて「イントラネット」と呼ばれた安全神話の崩壊を意味します。すべての通信リクエストは、あたかもインターネットという危険な荒野から来たものとして、厳格に処理されなければなりません。

原則3：個々の企業リソースへのアクセスは、セッション単位で許可される

【鍵の概念の変更】 従来のVPN接続は、一度認証を通ればネットワーク全体へのアクセスが可能になることが多く、いわば「マスターキー」を渡している状態でした。ゼロトラストではこれを否定し、「ワンタイムの使い捨てキー」のような運用を求めます。

【具体的な解釈】

最小特権の原則: ユーザーには、その瞬間の業務に必要な最小限の権限しか与えません。
セッションごとの認可: 「メールサーバーへのアクセス」が許可されたからといって、自動的に「ファイルサーバーへのアクセス」も許可されるわけではありません。別のアプリケーションやデータに触れようとするたびに、改めてアクセス許可の審査が行われます。
時間の制限: 許可されたアクセス権（セッション）には明確な期限があり、一定時間が過ぎれば自動的に無効になります。

【ここが重要】 これにより、万が一IDが盗まれたりマルウェアに感染したりしても、被害をその一つの小さなセッション内に封じ込めることができます。攻撃者がネットワーク内を自由に動き回ることを防ぐための重要な原則です。

原則4：リソースへのアクセスは動的なポリシーによって決定される

【判断基準の高度化】 これこそがゼロトラストの「脳」にあたる部分です。アクセスを許可するかどうかの判断を、「IDとパスワードが合っているか」という静的な情報だけで決めるのは不十分です。

【具体的な解釈】 「コンテキスト（文脈）」に基づいた動的な判断を行います。以下の要素を複合的に分析します。

ユーザー属性: 誰か？役職は？所属部門は？
デバイスの状態: 会社支給のPCか？ OSは最新か？ウイルス対策ソフトは稼働しているか？暗号化されているか？
環境属性: 現在の時刻は？場所（国、IPアドレス）は？
振る舞い: 普段と異なる大量のデータをダウンロードしようとしていないか？

【ここが重要】 例えば、「経理部のAさんが、会社支給のPCで、平日の日中に会計システムにアクセスする」なら許可します。しかし、「同じAさんのIDでも、未登録の個人スマホから、深夜に、海外のIPアドレス経由でアクセスしてきた」場合は、IDとパスワードが正しくても「拒否」あるいは「追加認証（多要素認証）を要求」します。このように、状況に応じて瞬時に判断を変える柔軟性が求められます。

原則5：企業は、すべての資産の整合性とセキュリティ動作を監視・測定する

【継続的な健康診断】 「認証されたデバイス」と「安全なデバイス」はイコールではありません。昨日は安全だったPCが、今日は脆弱性を抱えている可能性があります。

【具体的な解釈】

ポスチャ管理: デバイスやアプリケーションの現在のセキュリティ状態（ポスチャ）を常に監視します。
CDM（継続的な診断と緩和）: 脆弱性パッチが当たっていない端末、古いOSを使用している端末、不正なアプリがインストールされた端末などを検知します。
検疫と是正: セキュリティ要件を満たさないデバイスからのアクセスはブロックし、「OSをアップデートしてください」といった是正措置を促します。

【ここが重要】 攻撃者は脆弱なエンドポイントを狙います。したがって、アクセス元のデバイスが「健康」であることを確認せずに、重要データへのアクセスを許してはいけません。ゼロトラストにおいて、資産管理とセキュリティ監視はセットで機能する必要があります。

原則6：すべてのリソースの認証と認可は、アクセスが許可される前に動的かつ厳密に行われる

【継続的な信頼の検証】 原則3や4とも関連しますが、ここでは「タイミング」と「厳密さ」に焦点を当てています。信頼は「静的な状態」ではなく「一時的なもの」です。

【具体的な解釈】

アクセスの直前に審査: ユーザーがリソースを使おうとするその瞬間に、ポリシーに基づいた審査を行います。
信頼レベルの変動: ユーザーが作業をしている最中であっても、リスク評価はバックグラウンドで継続されます。もし作業中にデバイスのセキュリティ設定がオフになったり、不審な通信が発生したりすれば、即座に信頼レベルを下げ、セッションを切断します。

【ここが重要】 「朝イチでログインしたから、夕方までずっと信頼する」という考え方は通用しません。常に「本当に本人か？」「本当に安全か？」を疑い続け、動的に認可プロセスを回し続けるサイクル（ループ）が必要です。これを実現するためには、高度なID管理システム（IAM）と自動化されたポリシーエンジンが不可欠です。

原則7：企業は、資産、ネットワークのインフラ、通信の状態について可能な限り多くの情報を収集し、セキュリティ対策の改善に利用する

【学習と進化】 ゼロトラストは導入して終わりではありません。日々進化する脅威に対応するため、システム自体も学習し続ける必要があります。

【具体的な解釈】

ログの統合: ネットワーク機器、クラウドサービス、エンドポイント、ID管理システムなどから出力される膨大なログデータを一箇所（SIEMなど）に集約します。
分析と可視化: 集まったデータを分析し、通常とは異なる異常なパターンや新たな攻撃の予兆を発見します。
ポリシーの最適化: 分析結果をもとに、原則4で触れた「動的ポリシー」の精度を高めます。「この挙動はブロックすべきだった」「このアクセスは許可して問題なかった」というフィードバックを回し、防御の穴を塞いでいきます。

【ここが重要】 データに基づいた改善サイクル（PDCA）を回すことです。現状のシステム全体の状態を可視化し、そこから得られた知見を次の防御策に活かすことで、ゼロトラスト環境はより強固なものへと成長していきます。

論理コンポーネント：PDPとPEPの理解

これら7つの原則を技術的に実現するために、NIST SP 800-207では重要な2つのコンポーネントを定義しています。これも合わせて理解しておくと、製品選定がスムーズになります。

PDP（Policy Decision Point：ポリシー決定ポイント）
- 司令塔の役割です。ユーザーのID、デバイスの状態、ポリシーなどを総合的に判断し、「アクセスを許可するか否か」を決定します。
- 具体例：IDaaS（ID管理クラウド）、コントローラー機能
PEP（Policy Enforcement Point：ポリシー適用ポイント）
- ゲートキーパーの役割です。リソースの前に立ち、PDPからの命令に従って、実際に通信を通したり遮断したりします。
- 具体例：SASEのエッジ、ゲートウェイ、エージェントソフト

ゼロトラストの実装とは、優れた「脳（PDP）」を持ち、適切な場所に「門番（PEP）」を配置し、7つの原則に従って運用することだと言い換えられます。