レッスン1：ゼロトラストの定義を精密にする——NIST の 7 原則

このレッスンで学ぶこと

本コースが扱う範囲と、扱わない範囲を区別できる
「城と堀」モデルがなぜ長く機能したかを説明できる
ゼロトラストという概念の系譜を、Forrester と BeyondCorp の 2 つの出来事から把握する
NIST SP 800-207 が定める 7 つの基本原則を、原典の構成に沿って説明できる
ゼロトラストにまつわる 3 つの誤解を見分け、本コースの中核メッセージを持ち帰る

「ゼロトラスト」という言葉は、この数年で急速に一般的になりました。経営会議でも取引先との商談でも、「うちもそろそろゼロトラストを」という発言を耳にする機会が増えています。一方で、「ゼロトラストとは何か」を一文で説明できる人は増えても、「自社のゼロトラストを、どこから測り、どう設計し、何年かけて動かすか」を語れる人は、まだ多くありません。本コースは、その空白を埋めるために設計されています。

本コースの立ち位置——「何か」の先にある「どう動かすか」

「ゼロトラストとは何か」という問いには、すでに情報セキュリティ関連の入門コースやクラウド関連の入門コースが答えを出しています。本コースは、その定義を土台としながらも、主眼をまったく別の場所に置きます。つまり、自社のゼロトラストを、どこから測り、どう設計し、何年かけて移行するかです。ゼロトラストは製品ではなく、5 つの柱ごとに進む成熟度の階段です。この一文が、本コース全体を貫く出発点になります。

先に、本コースが扱わない範囲を明確にしておきます。読者が「これは別のコースで学ぶべき内容だ」と迷わないための地図です。

多要素認証・シングルサインオン・パスキーの仕組み、パスワードの守り方、暗号化の方式は、情報セキュリティ関連の入門コースで扱われています
ID 基盤の製品選定、アカウント連携の運用、端末管理ソフトの製品比較、機器のキッティングは、情シス関連の入門コースの守備範囲です
クラウド事業者と利用者の役割分担、鍵管理、保管時と通信時の暗号化は、クラウド関連の入門コースが扱っています
インシデント対応の手順や、発生後の調査・報告体制は、情報セキュリティ関連の入門コースの範囲です
攻撃者の手口と脅威の動向は、今後のサイバー攻撃関連の入門コースに委ねます
通信の仕組み、アドレスと名前解決、経路の設計は、今後のネットワーク関連の入門コースの領域です

本コースは、これらの前提知識をおおよそ持っている読者を想定し、認証・認可・多要素認証・暗号化の役割といった基礎用語は説明を短く受け流しながら、ゼロトラストという設計思想の中身——測る・設計する・動かすという 3 つの動作に集中します。

🔰 初学者の方へ 認証と認可の違い、多要素認証の仕組みに自信がない場合は、情報セキュリティ関連の入門コースを先に読むと理解が早まります。本コースでも初出の場面では簡潔に触れますが、詳しい解説は割愛します。

「城と堀」モデルが長く機能した理由

企業のネットワーク設計は、長いあいだ「城と堀」のような発想で組み立てられてきました。城壁の内側にいる者は仲間とみなし、外側から来る者は関所（ファイアウォール）で確認する。一度、関所を通って城内に入ってしまえば、あとは比較的自由に動き回れる。この発想を、セキュリティの世界では境界防御と呼びます。

この発想は、決して怠慢だったわけではありません。業務システムは自社のデータセンターに置かれ、社員は会社支給の PC で、オフィスという物理的な場所から接続する。「社内ネットワークの内側にいる」という一点さえ確認できれば、利用者・端末・アプリケーションの所在がほぼ一致していた時代には、境界を固めることが最も効率のよい防御でした。関所を厳重にすればするほど、投資対効果の高い防御が実現できたのです。

📝 補足 境界防御そのものが誤りだったわけではありません。当時の企業システムの実態——利用者・端末・データの所在がほぼ一致していたこと——に対して、合理的に設計された防御方式でした。ゼロトラストは境界防御を否定する思想というより、前提が変わった環境に合わせて設計をやり直す発想だと捉えると理解しやすくなります。

やがて、クラウドサービスの普及、テレワークの広がり、私物端末の業務利用が進むにつれて、「城の内側にいる人はみな仲間」という前提そのものが、現実と合わなくなっていきました。業務データは自社のデータセンターの外にあり、社員は自宅やカフェから接続し、端末は必ずしも会社が管理しているとは限りません。「内側と外側」という区分が、業務の実態を映さなくなったのです。

ゼロトラストという概念の系譜

「ゼロトラスト」という語そのものは、比較的新しい歴史を持ちます。系譜を押さえておくと、この後に学ぶ NIST の定義がなぜ今の形になったのかが理解しやすくなります。

Forrester の提唱——2010 年

ゼロトラストという語は、調査会社フォレスター・リサーチのアナリスト、ジョン・キンダーバーグが 2010 年に発表したレポート「No More Chewy Centers: Introducing the Zero Trust Model of Information Security」で提唱しました。レポートのタイトルにある「chewy center（柔らかい中心）」という比喩は、「殻は硬いが中身は柔らかい菓子」を指し、境界だけを固めて内部を無防備にしている当時のネットワーク設計を皮肉ったものです。この提唱が、ゼロトラストという概念の出発点になりました。

Google の BeyondCorp——2009 年から 2014 年へ

もう一つの重要な出来事が、Google 社内で始まった BeyondCorp という取り組みです。Google は 2009 年に受けた攻撃をきっかけに、社内施策としてこの取り組みを始めました。境界の内側を無条件に信頼する設計が攻撃を許した反省から、「社内ネットワークにいるかどうか」ではなく「利用者とデバイスの状態」でアクセスを判断する仕組みへと、社内システムを作り替えていったのです。この取り組みの詳細は 2014 年に論文として公開され、ゼロトラストという発想が理論だけでなく実装可能な設計であることを世に示しました。

Forrester の提唱が「なぜ発想を転換すべきか」を言語化し、Google の BeyondCorp が「実際に動く形にするとどうなるか」を示した。この 2 つが合流し、その後の標準化につながっていきます。

NIST SP 800-207 の 7 つの基本原則

ゼロトラストという発想を、実装可能な形で定義したのが、米国国立標準技術研究所（NIST）が 2020 年 8 月に発行した文書「Zero Trust Architecture」、通称 NIST SP 800-207 です。既刊の情報セキュリティ関連の入門コースでもゼロトラストという語自体は紹介されていますが、本コースでは、この文書が定める 7 つの基本原則を、原典の構成に沿って正確に確認します。ここが、本コースが最初に踏み込む一歩です。

NIST SP 800-207 は、ゼロトラストを実現するための設計思想を、次の 7 つの基本原則として整理しています。

すべてのデータ源と計算サービスをリソースとみなす：業務システムだけでなく、データそのもの、計算処理を行うサービスも、保護すべきリソースとして扱います
ネットワークの場所によらず、すべての通信を保護する：社内ネットワークにいるかどうかで通信の安全性を判断せず、どこからの通信であっても同じ水準で保護します
個々の企業リソースへのアクセスは、セッション単位で許可する：一度アクセスを許可したら継続的に信頼するのではなく、セッションごとにアクセス可否を判断します
リソースへのアクセスは動的なポリシーで決定する：利用者の識別情報、アプリケーションやサービス、要求元の資産の観測可能な状態を含み、行動や環境の属性も判断材料に含みうる、動的なポリシーでアクセスの可否を決めます
すべての保有資産と関連資産について、完全性とセキュリティ状態を監視・測定する：組織が保有する端末やシステムの状態を、常に監視し測定し続けます
すべてのリソースの認証と認可は動的かつ厳格に、アクセスを許可する前に実施する：アクセスを許可する前に、認証と認可を毎回、厳格に行います
資産・ネットワーク基盤・通信の現状について可能な限り多くの情報を収集し、セキュリティ態勢の改善に用いる：収集した情報は、その場限りの判断だけでなく、組織全体のセキュリティ態勢を継続的に改善するために活用します

💡 ポイント 7 原則を読むと、「セッション単位」「動的なポリシー」「監視・測定」「アクセスを許可する前に」という言葉が繰り返し登場することに気づきます。これは偶然ではありません。ゼロトラストの本質は「信頼しない」ことではなく、「毎回確かめる」ことです。確かめる材料をどう集め、どう判断に使うかが、設計の中身になります。この視点は、レッスン 3 以降で柱ごとの設計を扱う際に何度も立ち返る軸になります。

論理コンポーネント——判断する仕組みの内側

NIST SP 800-207 は、ゼロトラストを実現する仕組みを、3 つの論理コンポーネントに分けて説明しています。「論理」という言葉が付いているのは、これらが特定の製品や装置を指すのではなく、役割として理解すべき概念だからです。

ポリシー実施点：利用者や端末からのアクセス要求を実際に受け取り、通す・止めるを実行する場所です。企業リソースへの通信経路上に置かれます
ポリシー管理者：ポリシー実施点に対して、通信を確立してよいか、切断すべきかを指示する役割です
ポリシーエンジン：アクセスを許可するかどうかを、ポリシーと収集した情報にもとづいて判断する頭脳にあたる部分です

3 つの関係を図で整理すると、次のようになります。

flowchart LR
  U[利用者と端末] --> PEP[ポリシー実施点]
  PEP --> R[企業リソース]
  PEP --> PA[ポリシー管理者]
  PA --> PE[ポリシーエンジン]
  PE --> PA
  PA --> PEP

利用者や端末からのアクセス要求は、まずポリシー実施点で受け止められます。ポリシー実施点は自分では判断せず、ポリシー管理者に問い合わせます。ポリシー管理者は、ポリシーエンジンの判断結果を受け取り、その結果にもとづいてポリシー実施点に「通してよい」「切断せよ」と指示します。判断そのものを担うポリシーエンジンと、判断を実行に移すポリシー実施点、両者を仲立ちするポリシー管理者。この役割分担が、ゼロトラストの技術的な骨格になります。

📝 補足 実際の製品では、これら 3 つの役割が 1 つの製品にまとめて実装されていることもあれば、複数の製品が分担して担っていることもあります。「どの製品がポリシーエンジンか」を探すよりも、「自社のどの仕組みが、どの役割を担っているか」を役割で捉える方が、設計を見誤りません。

Never Trust, Always Verify の正確な含意

ゼロトラストを説明するときによく引用される標語が、「Never Trust, Always Verify（決して信頼せず、常に確かめる）」です。この標語は、しばしば誤解されます。

「信頼しない」という言葉だけを切り取ると、「社員を疑ってかかる」「すべての通信を敵とみなす」という意味に受け取られがちです。しかし、正確な含意はそうではありません。「一度確認したら、その後もずっと信頼し続ける」という発想をやめ、「アクセスのたびに、そのつど確かめる」設計に切り替える、という意味です。7 原則の 3 番目にある「セッション単位で許可する」、6 番目にある「アクセスを許可する前に実施する」が、この標語の技術的な裏付けになっています。

利用者を疑う話ではなく、判断のタイミングを変える話。この理解が、本コースを読み進めるうえでの土台になります。

ゼロトラストにまつわる 3 つの誤解

ここまでの内容を踏まえたうえで、現場でよく見かける 3 つの誤解を整理しておきます。移行を検討する組織が、計画の初期段階でつまずきやすいポイントです。

誤解 1：製品を買えば実現する

「ゼロトラスト対応」を謳う製品は数多く存在します。しかし、特定の製品を導入した瞬間にゼロトラストが完成することはありません。7 原則が示すのは、リソースの捉え方から、アクセス判断の方法、監視の継続性まで、組織全体の設計思想です。製品は、その設計思想を実現するための部品の一つにすぎません。

誤解 2：VPN 廃止が目的である

「ゼロトラスト移行＝VPN を止めること」と捉えられることがありますが、これは目的と手段を取り違えています。VPN を止めることそのものが目的ではありません。VPN を止められる状態を作ることが目的です。アイデンティティやデバイスの判断材料が十分に整っていない段階で VPN だけを止めれば、業務が止まるか、別の抜け道が生まれるだけです。この論点は、レッスン 5 で詳しく扱います。

誤解 3：一度で完成する

ゼロトラストには「完成」という状態がありません。5 つの柱それぞれに成熟度の段階があり、脅威の状況や事業の変化に合わせて、継続的に見直していく性質のものです。「今年度中にゼロトラストを完成させる」という目標設定そのものが、誤解にもとづいています。

⚠️ 注意 3 つの誤解に共通するのは、「ゼロトラストを、ある時点で完了するプロジェクト」として捉えている点です。本コースでは、ゼロトラストを「柱ごとに進む成熟度の階段」として扱います。階段には終わりがなく、上り続けるものだという前提が、レッスン 2 以降の設計の土台になります。

本コースの中核メッセージ

ここまでの内容を踏まえ、本コース全体を貫く 6 つの中核メッセージを提示します。以降のレッスンで、これらを繰り返し、さまざまな角度から確認していきます。

ゼロトラストは製品ではなく、5 つの柱ごとに進む成熟度の階段である
「信頼しない」ではなく「毎回確かめる」。確かめる材料をどう集めるかが設計の中身である
柱ごとに成熟度が違ってよい。全部を同時に上げようとすると必ず止まる
VPN を止めることが目的ではない。止められる状態を作ることが目的である
アクセスを判断する材料は、認証だけでなく端末の状態にもある
経営に説明できない移行計画は、2 年目の予算で必ず削られる

最後の 6 番目は、技術の話というより組織運営の話に聞こえるかもしれません。しかし、講師である私自身が移行 PMO を務めた経験から言えば、技術的に正しい設計を描けても、経営に説明できなければ計画は止まります。この視点は、レッスン 8 で改めて詳しく扱います。

まとめ

このレッスンでは、以下のことを学びました。

本コースは「ゼロトラストとは何か」の先にある、「どこから測り、どう設計し、何年かけて移行するか」を扱う
境界防御（城と堀のモデル）は、利用者・端末・データの所在が一致していた時代に合理的な設計だった
ゼロトラストという語は、Forrester のジョン・キンダーバーグが 2010 年のレポートで提唱した
Google の BeyondCorp は 2009 年の攻撃を機に社内施策として始まり、2014 年に論文として公開された
NIST SP 800-207 は、ゼロトラストを 7 つの基本原則として定義している
ポリシーエンジン・ポリシー管理者・ポリシー実施点という 3 つの論理コンポーネントが、判断と実行の役割を分担する
Never Trust, Always Verify は「社員を疑う」ではなく「アクセスのたびに確かめる」という意味である
ゼロトラストには、製品を買えば実現する、VPN 廃止が目的である、一度で完成する、という 3 つの誤解がある

次のレッスンでは、自社のゼロトラストが今どの段階にあるのかを測るための道具、CISA ゼロトラスト成熟度モデルを学びます。5 つの柱と 4 段階の成熟度を使い、自社を自己診断する具体的な方法に踏み込みます。

確認クイズ

このレッスンの理解度をチェックしましょう。