2026年8月6日
ゼロトラストWGリーダー 諸角昌宏
はじめに
「ゼロトラスト」という言葉は、いまやセキュリティの世界で組織の資産を守るための欠かせないフレームワークとして定着している。一方で、「結局、何から手をつければいいのか分からない」「壮大すぎて自社では無理だ」と感じている方も多いのではないだろうか。
本シリーズでは、ゼロトラストを「全部を一度にやる巨大プロジェクト」ではなく、順を追って小さく始められる5つのステップとして整理し、全5回にわたって解説していく。利用するのは、米国家安全保障通信諮問委員会（NSTAC）の大統領向け報告書が示した5ステップの実装プロセスと、Cloud Security Alliance（CSA）のゼロトラスト・ワーキンググループによる解説文書「Defining the Zero Trust Protect Surface（ゼロトラスト プロテクトサーフェスの定義）」である。 第1回となる今回は、まず5ステップの全体像をつかみ、その第1ステップである「プロテクトサーフェスの定義」を掘り下げる。
ゼロトラストと5ステップモデルの背景
ゼロトラストは、2010年にForrester ResearchのアナリストだったJohn Kindervag氏が提唱した戦略である。その根底にあるのは「決して信頼せず、常に検証する（never trust, always verify）」という考え方である。ネットワークの内側か外側かにかかわらず、あらゆる接続を暗黙に信頼しないことを前提とする。従来の「城と堀」型、つまり境界の内側を信頼するアーキテクチャは、資産やユーザーがもはや「城」の中に収まっていない分散・クラウド・リモートワークの時代には通用しない、というのが出発点である。
重要なのは、ゼロトラストが特定の製品ではなく「戦略」だという点である。技術は時代とともに変わるが、戦略そのものは変わらない。「製品を1つ買えば終わり」というものではなく、組織として段階的に作り上げていくものである。 この戦略を「どう実行するか」を5つのステップに落とし込んだのが、NSTACの報告書「Zero Trust and Trusted Identity Management」で示された実装プロセスである。
5ステップの全体像
ゼロトラスト実装プロセスは、次の5ステップで構成される。
- プロテクトサーフェスの定義 — 何を守るべきか（DAAS要素）を特定する
- トランザクションフローのマッピング — データやトランザクションがどこをどう流れているかを把握する
- ゼロトラストアーキテクチャの構築 — リスクと露出を最小化する構成を設計する
- ゼロトラストポリシーの作成 — 誰が・何にアクセスできるかを定義する
- ネットワークの監視と保守 — 運用しながら継続的に改善する
このプロセスで押さえておきたいのは、一度きりで完結するものではなく、反復的（iterative）に回していくものだということである。1つの対象に対して5ステップを一巡させ、セキュリティ・ポスチャを一段引き上げたら、次の対象へ。これを繰り返すことで、組織全体のゼロトラスト化を「少しずつ、無理なく」進めていく。
図1：ゼロトラストは「プロテクトサーフェス→トランザクションフロー→アーキテクチャ構築→ポリシー→モニタリング」を回す反復サイクル
ステップ1：プロテクトサーフェスの定義
なぜ「アタックサーフェス」ではなく「プロテクトサーフェス」なのか
従来のセキュリティは、攻撃を受けうる範囲、すなわちアタックサーフェス（攻撃対象領域）全体を守ろうとしてきた。しかしアタックサーフェスは、クラウド化やリモートワークの進展とともに際限なく拡大し、組織が正確に把握しきることは事実上不可能である。「すべてを守る」は、裏を返せば「どこも守りきれない」になりかねない。
そこでゼロトラストは発想を逆転させる。攻撃される範囲全体を追いかけるのではなく、本当に守るべきものは何かに焦点を絞る。この「本当に守るべきもの（DAAS要素）だけを対象とした領域」がプロテクトサーフェス（保護対象領域）であり、ゼロトラストポリシーによって保護される、組織の技術環境の一部分を指す。 プロテクトサーフェスの優れた点は2つある。1つは、アタックサーフェスよりも桁違いに小さいこと。もう1つは、常に把握可能（knowable）であることである。アタックサーフェスの全体像は誰にも描けなくても、「自社にとって最も重要な資産は何か」は、調べれば必ず分かる。
Protect Surface is much smaller and more knowable than the Attack Surface.（プロテクトサーフェスは、アタックサーフェスよりもはるかに小さく、はるかに把握しやすい。）
— John Kindervag
従来のセキュリティは、いわば「インターネット側にいる攻撃者」を見て、その攻撃を防ぐことに注力してきた。ゼロトラストはこの視点を反転させ、攻撃者ではなく「自分が何を守りたいのか」を起点に考える。攻撃の手口は無数にあり追いきれないが、守るべき対象は有限であり、必ず見定められる。では、何を守るべきか。その中身を整理する手がかりが、次に述べるDAASである。
守るべき対象「DAAS」
では、何をプロテクトサーフェスとして定義すればよいのか。その手がかりが、4つの頭文字をとったDAASである。
- D — Data（データ）：流出または悪用された場合に最大のリスクをもたらす機微なデータ。ペイメントカード情報（PCI）、保護された医療情報（PHI）、個人を特定できる情報（PII）、知的財産などが代表例である（政府機関であれば、機密情報や国家安全保障情報なども含まれる）。
- A — Applications（アプリケーション）：機微なデータを使用したり、重要な資産を管理したりするアプリケーション。SaaSとして提供されることも、オンプレミスやクラウド（IaaS／PaaS）で自社運用されることもある。
- A — Assets（資産）：組織のIT・OT・IoT機器。サーバーやノートPCだけでなく、医療機器、POS、センサー、プリンター、産業用ロボット、SCADA、ICS（産業制御システム）、BMS（ビル管理システム）まで幅広く含む。
- S — Services（サービス）：組織が最も依存する基盤サービス。DNS、DHCP、ディレクトリサービス、NTP、カスタマイズされたAPIなど。それ自体がプロテクトサーフェスであり、停止・悪用されれば広範囲に影響する。
DAASは、何かを厳密に分類するための枠ではなく、「データ・アプリケーション・資産・サービス」という4つの切り口で自社を見渡し、守るべきものを洗い出すための着眼点である。だから「DNSはアプリケーションかサービスか」といった分類に頭を悩ませる必要はない。大切なのは、一歩引いて全体を見渡し、業務にとって意味のあるまとまりを見つけることである。ゼロトラストは個々のサーバーだけを単独で守る発想ではなく、業務上意味のある単位（プロテクトサーフェス）を起点に保護を設計する。
具体例：架空の金融サービス組織の「決済システム」
CSAの文書は、架空の金融サービス組織を例として用いている。この組織には、ATM、決済（Payments）、SWIFTゲートウェイ、取引ポータル、メインフレーム、Active Directory、DNS／NTP、ローン、VDI、PKIなど、多数のプロテクトサーフェスが存在する。そのそれぞれに「関連度（重要度）スコア」と「現在のZTセキュリティ成熟度」が割り当てられ、次にどこへ取り組むかを判断する材料になる。
そのうちの1つ、「決済システム」というプロテクトサーフェスを取り出してみる。これは単一の要素ではなく、関連する複数のDAAS要素から構成される、1つの業務情報システムである。
- データ：カード会員データ（取得と支払い処理のためのデータ）。
- アプリケーション：カード会員データを管理し、支払いを処理するWebアプリケーション。
- 資産：そのカード会員データを保存するデータベースをホストするサーバー。
- サービス：外部のクレジットカード決済処理サービス、およびDNS。
CSAの文書の「表1」には、このほかにもCRMシステム、文書リポジトリ（SharePoint Online）、産業制御システム（化学プラント）、スマートエネルギー計測・課金システムなど、業種をまたいだプロテクトサーフェスのサンプルが、それぞれのDAAS内訳とともに示されている。いずれも『関連するDAASを束ねた1つの業務情報システム』として定義されている点が共通している。
図2：決済システムのプロテクトサーフェスを構成するDAAS要素（「ゼロトラスト・プロテクトサーフェスの定義」表1を基に作成）
| 業務情報システム | データ | アプリケーション | 資産 | サービス |
| CRMシステム | 顧客データ（製品・サービス・連絡先・イベント等） | CRMアプリ（SaaS） | CRM SaaS事業者のCRMサーバー | 顧客・組織のアイデンティティサービス、DNS |
| 文書リポジトリ | ファイルとメタデータ | SharePoint Online | Microsoftのインフラ | IDaaS（Azure Active Directory） |
| 決済システム | カード会員データ | 決済処理を行うWebアプリ | DBをホストするサーバー | 外部クレジットカード決済処理、DNS |
| 産業制御システム | 化学プロセスの制御・センサーデータ | 化学プロセス制御アプリ | プラントのセンサーとPLC | HVAC（空調） |
| スマートエネルギー計測・課金 | 電力消費量・顧客データ | 顧客モニタリング・請求システム | スマートメーター | スマートメーター無線ネットワーク |
表1：プロテクトサーフェスのサンプル（「ゼロトラスト・プロテクトサーフェスの定義」表1の内容を基に作成）
こうしてプロテクトサーフェスを選んだら、その中身を具体的に書き出していく。手順は大きく2段階である。まず①として、そのプロテクトサーフェスを構成するDAAS要素（データ・アプリケーション・資産・サービス）を、責任者や業務上の重要度とあわせて洗い出す。決済システムなら、データ＝カード会員データ、アプリ＝決済Webアプリ、資産＝DBサーバー、サービス＝外部の決済処理サービスやDNS、責任者＝決済システムの担当リーダー、重要度＝最高（関連度スコア100点。止まれば売上に直結する）、といった具合である。次に②として、洗い出した各DAAS要素を、実際の技術的な実体に対応づける。ただし、その「実体」の捉え方は環境によって異なる。物理サーバーやVMなら特定のIPアドレスやホストになるが、コンテナのように動的な環境では、IPが頻繁に変わり物理サーバーとの対応も崩れるため、クラスタ・名前空間・サービス名やワークロードのアイデンティティ（ラベル、サービスアカウント等）で捉える。いずれにせよ、ネットワーク上の位置（IP）そのものではなく、その要素の“正体”に紐づけるのがゼロトラストの発想である。CSAの文書も、これらの情報を『プロテクトサーフェスを特徴づける重要なメタデータ』と位置づけている。ここまで具体化して初めて、後続のステップ（トランザクションフローの可視化やポリシー設計）で『実際に守る対象』として使えるようになる。
誰が、どこまで定義するのか
プロテクトサーフェスの定義は、技術担当者だけで決めてはならない。業務プロセスのオーナー、CISO、運用担当者など、立場の異なる人々を集めて「自社にとって重要な資産は何か」を議論する必要がある。業務オーナーだけに任せれば、Active Directoryのように『業務からは見えにくいが、極めて価値あるデータを保持するもの』を見落としかねない。逆にIT部門だけでは、業務側の重要度を捉えきれない。
そのため、ステップ1に入る前段として、「これからゼロトラストに取り組む」という組織的な合意形成が要る。いきなり業務オーナーを会議に呼んでも話は通らない。あわせて、後続ステップでは時間や新たな製品への投資が生じるため、経営層の理解と予算承認をあらかじめ得ておくことが望ましい。 進め方としては、業務プロセスやエンタープライズアーキテクチャ、アプリ一覧から降ろしていくトップダウンが理想である。それが難しければ、使用中のIPアドレスからサーバー、そしてアプリを辿るボトムアップでも網羅できる。いずれにせよ、まずは責任者・保有データ・重要度といったメタデータを書き出し、最終的にIPアドレス・サーバー・クラウドリソースへ対応づける。「定義のための定義」で終わらせず、実際に守るために使うことが肝心である。
「特定・分類・評価」する
CSAの文書では、プロテクトサーフェスの定義を、単なる棚卸しではなく、組織のDAAS・事業リスク・現在のセキュリティ成熟度を「特定し、分類し、評価する」プロセスとして位置づけている。
実務上のポイントは、DAAS要素を個別にバラバラに扱うのではなく、「業務情報システム」という意味のあるまとまりとして整理することである。たとえば架空の金融機関を例にとると、関連するデータ・アプリケーション・資産・サービスを業務システム単位でグルーピングし、それぞれの重要度を見極めていく。
ここで重要なのは、CSA文書がこの業務情報システムを1つのプロテクトサーフェスと等価とみなしている点である。すなわち、1つのプロテクトサーフェスは複数の関連するDAAS要素から構成され、それらがまとまって1つの業務システムを形づくる。そのうちの1つが、事業上・リスク上の観点で「主要な要素（primary element）」と位置づけられることが多い。なお、すべてのプロテクトサーフェスがDAASの4種別すべてを備えるとは限らず、大規模で複雑な業務情報システムは、リスクレベルの異なる技術が混在する場合に、相互に関連する複数のサブシステム（＝別個のプロテクトサーフェス）へ分割されることもある。
文書の図4では、同じ組織の中に複数のプロテクトサーフェスが定義され、互いに連携する様子が描かれている。たとえば、カード会員データを扱う決済システム（高リスクの主要な業務情報システム）、プライバシー要件のある内部向けのHRMS（人事）システム、内部・外部向けで商業的要件をもつCRM、そして全体を支えるIAM（Active Directory）やDNSといったサポートサービスが、それぞれ独立したプロテクトサーフェスとなり、相互に影響し合う。1つのプロテクトサーフェスは孤立して存在するのではなく、他とインターフェースをもつ点が重要である。 粒度の取り方も重要である。アプリケーションとそのデータのように一体として守るべき関連DAASは、まとめて1つのプロテクトサーフェスとする。逆に、大規模で複雑な業務情報システムは、リスクレベルの異なる技術が混在する場合、サブシステムに分割する。たとえばCSAの文書では、大きな「サービス監視・課金業務システム」の一部であるOTのスマートメーター測定システムを、別個のサブシステム（プロテクトサーフェス）として扱う例を挙げている。完璧な区分けを最初から求めず、反復のなかで適切な粒度に整えていけばよい。
優先順位をどうつけるか
すべてのプロテクトサーフェスを同時に守ろうとすれば、結局は最初の壮大なプロジェクトに逆戻りである。そこで欠かせないのが優先順位づけである。ただし注意したいのは、ゼロトラストには性質の異なる2つの順序があることだ。1つは、各プロテクトサーフェスが事業にとってどれだけ重要かを測る「重要度のランク付け」。もう1つは、実際にどこから手をつけるかという「着手の順番」である。この2つはしばしば一致しない。まずは重要度のランク付けから見ていく。判断軸は、リスク・重要度（クリティカリティ）・組織の現在のセキュリティ成熟度であり、ビジネスインパクト分析（BIA）があればそれを起点に、なければ資産の棚卸しを行って、価値の高い順にランク付けする。
CSAの文書では、この重要度のランク付けを「関連度（重要度）スコア」による相対評価として示している。先の金融サービス組織の例では、決済（Payments）やSWIFTゲートウェイ、ATMといった中核業務は100点、取引ポータルは95点、VDIやローンは88点、PKIは80点、というように相対的な点数が与えられている。ここで「うちは全部100点だ」となりがちだが、まさにその議論こそが必要である。すべてが最優先なら、何も優先していないのと同じだからである。
点数化の材料としては、関わるデータの分類（規制・法令の対象か、PCI／PHI／PIIや知的財産にあたるかなど）やコンプライアンス要件、そして機密性・完全性・可用性（CIAトライアド）の要件と、侵害・停止が起きた場合の潜在的な影響を考慮する。たとえば文書の浄水場の例では、フッ化物濃度を制御する資産が侵害されれば水質、すなわち完全性（インテグリティ）が損なわれうる。このようにCIAの観点から、各プロテクトサーフェスのリスクを見立てていく。
では、この重要度のランク付けどおりに、重要なものから着手すればよいのか。実はそうではない。ここで2つめの「着手の順番」が関わってくる。ゼロトラスト実装で繰り返し強調されるのは、最初から組織全体を網羅する完璧なアーキテクチャを目指さないことである。対象を1つ（あるいは数個）に絞って起点とし、1つずつ積み上げていく。「一口サイズ」に分割して反復的に進める。そして着手の順番としては、いきなり最重要の本命に挑むのではなく、まず重要度の低いもので練習して経験を積み、その後に本命へ進むのが定石である（次節で詳述）。つまり、重要度のランク付けと着手の順番は別物であり、両者を切り分けて考えることが、矛盾なく進めるコツである。
よくある落とし穴と反復ロードマップ
最大の落とし穴は、最初から全部をやろうとすることである。よほど小さな組織でない限り、すべてを一度にマッピングしようとすれば必ず頓挫する。まず思いつくものを10〜15個書き出し、そのうえで5つほどに絞って作り込むのがよい。5という数は、達成可能で「やり切った」という区切りも得やすい、ちょうどよい目安である。
最初の1〜2個は、あえて重要度の低いものを「練習台」に選ぶとよい。後続のステップで実装作業に入った際、万一障害が起きても業務影響が小さく、落ち着いて手順を習得できるからである。腕が上がったところで、本命である「企業の重要資産（クラウンジュエル）」へ進めば、セキュリティ・ポスチャを大きく前進させられる。この「学習→練習→重要資産」という進み方は、John Kindervag氏（Palo Alto）による『ゼロトラストの学習曲線（The Zero Trust Learning Curve）』として知られ、CSAの文書でも図として引用されている。
そして重要なのが、ステップ1を全対象で終えてからステップ2へ、という進め方をしないことである。選んだ5つ（あるいは1つ）について5ステップを通しで回し、それを反復する。全部を一度に進めようとすれば、いつまでもステップ5にたどり着けない。さらに、発見の過程で役割が不明なDAAS要素が出てきても、慌てて削除・廃止してはならない。一見不要に見えて、実は業務運営上の重要な役割を担っていることが少なくない。 最終的には、このプロセスを業務の「第二の習慣」として根付かせる。新しいプロジェクトが立ち上がるたびに「これはどのプロテクトサーフェスか」を問い、5ステップを回す。そして、「最初の5つを2か月で完了させ、次の5つへ」というようにロードマップを持って進める。こうすると、限られたセキュリティ予算が「ファイアウォールの定期更新」ではなく、本当に守るべき業務へと向かう。既存のファイアウォールやエンドポイントを活かしながらでも、この順序で取り組むこと自体に価値がある。
まとめと次回予告
第1回では、ゼロトラスト実装の5ステップ全体を俯瞰し、その出発点である「プロテクトサーフェスの定義」を見てきた。要点は次の4つである。
- ゼロトラストは製品ではなく戦略であり、5ステップを反復的に回して育てるものである
- 守る対象を絞ったプロテクトサーフェスは、アタックサーフェスより小さく、常に把握できる
- DAASを業務情報システム（＝プロテクトサーフェス）単位で特定・分類・評価し、リスクと成熟度に応じて優先順位をつける（決済＝100点、PKI＝80点のように相対評価する）
- 最初から全部をやろうとせず、5つ程度に絞り、低リスクのもので練習してから本命へ。対象ごとに5ステップを通しで回し、ロードマップを持って反復する
次回（第1.5回）は、ISO/IEC27005の資産管理の考え方である主要資産と支援資産と、プロテクトサーフェスの考え方を検討し、ISMSでの資産の考え方とプロテクトサーフェスの関係を明確にしてみる。
そのうえで、次々回（第2回）で、ステップ2「トランザクションフローのマッピング」を取り上げる。守るべき対象が決まったら、次はそのデータやリソースが「どこから来て、どこへ流れているのか」を可視化していく。
以上