2026年8月25日
ゼロトラストWGリーダー　諸角昌宏

この回のねらい

第1回では、ゼロトラストの出発点である「プロテクトサーフェスの定義」を扱い、守るべき対象をDAAS（データ、アプリケーション、資産、サービス）として業務単位で束ねる考え方を扱った。守る対象が定まったら、次は何をするか。それが本編のステップ2「トランザクションフローのマッピング」である。

図1：ゼロトラスト導入の5ステップと、本稿が扱うステップ2（CSA文書を基に作成）

ステップ2のねらいを一言でいえば、プロテクトサーフェスの周りを、データやトランザクションがどこをどう流れているかを可視化・文書化することである。これにより、業務システムが実際にどう動くかを理解し、後続のステップ3（アーキテクチャ構築）とステップ4（ポリシー作成）でコントロールをどこに置くかを判断できるようになる。ここでは、CSAが公開した「ゼロトラストのためのトランザクションフローのマッピング」（以降、CSA文書と略称）の内容を元に説明する。

トランザクションフローとは何か

トランザクションとは、アプリケーションやサービスを通じたデータへのインターフェースであり、データの取得・処理・移動・永続化を含んでいる。ここでいうトランザクションフローは、金融取引や特定の機密情報だけを指すのではなく、あらゆる情報・データのフローを意図している。データは複数のプラットフォーム・サービスプロバイダ・地理的領域・ユーザーを横断して流れるため、その全体像を捉えるのは複雑な作業になる。

ステップ2で理解・文書化するのは、たとえば次のような事項である。

• アプリ、データ、インフラにアクセスするリソース（ユーザー、API、Webサービスなど）
• 各アプリケーションとそのデータの関係（取得、転送、移動、永続化を含む）
• DAAS要素が、相互に、またプロテクトサーフェス外の資源とどう相互作用・通信するか
• トラフィックがネットワークをどう通過し、異なるセグメントや境界を越えて流れるか
• 各インタラクションやデータフローの背景にある業務上の文脈と根拠

なぜマッピングするのか — 何が分かるか

これらを可視化・文書化することで、組織は次のような知見を得られる。いずれも後続のステップに直接つながる。

• 各プロテクトサーフェスを効果的に囲むネットワークセグメンテーションの方法
• セキュリティコントロールとポリシー実施ポイント（PEP）を戦略的に配置すべき場所
• ポリシーに基づき明示的に認可・拒否すべきトラフィックパターンと通信チャネル
• DAAS要素の機能や相互作用に整合したZTアーキテクチャの設計方法
• アイデンティティ・デバイス・ネットワークの要素を反映した、プロテクトサーフェスごとのアクセスポリシー

何を可視化するか — ステップ2の活動

CSA文書は、ステップ2の活動を次のように整理している。ステップ1で作った「守る対象の一覧」を、動きの面から検証・精緻化していくイメージである。

• DAAS要素を検証し、そのメタデータを精緻化する
• ユーザーと、使用するエンドポイント端末の種類を特定・文書化する
• 依存関係（関連する業務システムや外部サービス）を特定する
• DAAS要素間・ユーザー・他システム・外部サービスとのトランザクションを特定する
• データフローをマッピングし、システムの動作を文書化する
• 本番／バックアップ・災害復旧／単一障害点（SPOF）／開発・テストのどれに当たるかを見極める

マッピングの進め方 — 2つのアプローチ

DAAS要素の機能と相互作用を理解し文書化するには、大きく2つのアプローチがある。両者は互いに補い合う形になる。

① 包括的なシステム分析（既存アーティファクトの活用）

ネットワーク図、アプリケーションアーキテクチャ図、データフロー図、ユーザーインタラクション図、脅威モデル、事業継続／災害復旧計画といった既存の資料を持ち寄り、足りなければ新たに作成する。そのうえで、業務システムオーナーやネットワーク・アプリ・エンタープライズの各アーキテクト、データ管理者などのステークホルダーと連携し、システムの動作・目的・主要リスクを理解する。現代のアプリケーションはモノリシックから、マイクロサービス・コンテナ・サーバーレスといったモジュール化・分散化へと変化しているため、マルチティア（N層）構成での層内・層間のデータフローにも注意する。

② スキャン・モニタリングツールの活用

既存資料だけでは実態と食い違うことがあるため、実際のトラフィックを観測するツールを組み合わせる。これらは直接トランザクションをマッピングするわけではないが、収集情報を突き合わせることでフローの理解を深められる。

ツールの種類（例）	取得できる主なデータ
アプリ可観測性（Jaeger、OpenTelemetry等）	トレースデータ、パフォーマンス指標
ログ分析（Splunk、ELK等）	ユーザー活動（認証・アクセス・データ変更）、各種ログ
APIモニタリング（Postman、Apigee等）	API呼び出し・ステータス・利用状況（利用パターン、トラフィック）
ネットワーク（Wireshark、Nagios等）	トラフィック（ヘッダー・ペイロード・プロトコル）、機器状態
コンテナ（Cilium、Calico等）	コンテナのトレース、トラフィック種別、サービス定義・ラベル

表1：トランザクション把握に使うスキャン・モニタリングツールの例（CSA文書 を基に作成）

なお、暗号化はメタデータや内容を隠すためマッピングを難しくしてしまう。その場合は、パケットサイズ・タイミング・方向などのメタデータ分析（復号せず、通信の外形から推測）、管理された環境でのTLS検査（通信路で復号して直接見る）、あるいはアプリログ・テレメトリを用いたアプリケーション層の可視性（通信路ではなく、アプリの記録から見る）で補う必要がある。

具体例：クレジットカードサービスのトランザクションフロー

CSA文書は、第1回と同じ架空の金融サービス組織を例に用いている。ここでは重要な業務システムとしてクレジットカードサービスを取り上げ、そのトランザクションフローをたどる。まず、このプロテクトサーフェスを構成するDAAS要素を検証する。

DAAS要素	クレジットカードサービスでの内容（例）
データ	カード会員データ、個人識別情報（PII）
アプリケーション	クレジットカードWebアプリ、引受審査アプリ
資産	アプリケーションとデータベースをホストするサーバー
サービス	カード申請・決済取引・カード審査・カード照合・カード印刷・レポート生成、DNS、アイデンティティサービス

表2：クレジットカードサービスのDAAS要素（CSA文書 を基に作成）

次に、このシステムに関わる人間ユーザーと非人間ユーザー（APIや外部インターフェースのアイデンティティ）を特定する。人間ユーザーは、内部・外部の全関係者を、それぞれの情報源から洗い出す。

人間ユーザー	例	情報源
内部ユーザー	従業員、契約社員、派遣社員、システム管理者、特権ユーザー	IAM、従業員ディレクトリ、人事記録、アクセスログ
外部ユーザー	顧客、パートナー、サプライヤー、ベンダー、第三者サービス、ゲスト	顧客データベース、パートナーポータル、ベンダー管理システム

表3：プロテクトサーフェスの人間ユーザー（CSA文書を基に作成）

続いて依存関係を特定する。内部依存（他のプロテクトサーフェスやライブラリ）、プロセス依存（ワークフロー、バッチ処理）、外部依存（サードパーティ、外部データソース、規制・契約）を洗い出す。クレジットカードサービスでは、信用調査機関・連邦規制報告・ATMといった外部サービスや、Active Directory・住宅ローン／預金サービス・DNS・アイデンティティサービスといった他の保護対象が関わってくる。

これらを踏まえてトランザクションフローをマッピングすると、次のように可視化できる。

図2：取引をマッピングしたクレジットカード・プロテクトサーフェス（CSA文書を基に作成）

各トランザクションは、送信元・宛先・通信方法（プロトコル、暗号化）・認証・サービスといった属性まで具体的に文書化する。抜粋すると次のようになる。

送信元	トランザクション	通信（プロトコル等）	宛先	サービス
顧客	新規申込（PIIを含む）	HTTPS、JSON、TLS	カードWebアプリ	カードの申し込み
ATM	現金引き出し・カード情報	XML/JSON、EMVチップ認証	ATM	決済取引
カードWebアプリ	新規カード判定（PIIを含む）	HTTPS、RESTful、OAuth2.0、TLS	引受審査アプリ	カード審査
引受審査アプリ	与信照会（顧客の詳細）	HTTPS、RESTful、OAuth、JWT	信用調査機関	信用調査API
引受審査アプリ	規制報告（PIIを含む）	HTTPS、XML、TLS	連邦政府	規制報告
住宅ローン	ローン詳細の確認	SOAP、JSON、JWT	引受審査アプリ	ローンサービス

表4：クレジットカード・プロテクトサーフェスの取引詳細（抜粋。CSA文書 基に作成）

環境ごとの違い — クラウドとOT／IoT

マッピングの進め方は、環境によって大きく異なる。クラウドでは、IaaSの仮想マシン、PaaSのFunction、コンテナ（K8s）ワークロード、SaaS APIで性質が違うため、資産の重要度と望ましいコントロールレベルを設定する。CSPが提供するモニタリング・分析ツール（CloudWatch、Azure Monitor等）やクラウド固有のログを活用して可視化する。

OT／IoTでは、産業用制御システム（ICS）、SCADA、ビル管理、PLCといった対象があり、センサー／アクチュエーター（エッジ）、IoTゲートウェイ、IoTプラットフォーム、クラウド／リモートサービスの相互作用を確実に含める。デジタル環境全体でトランザクションを統一的に把握するには、オンプレ・クラウド・OT/IoTのデータを統合した一元的なビューを作ることが鍵になる。

マッピングの成熟度モデル

CSA文書は、トランザクションフローマッピングのプロセス成熟度を評価・改善するための5段階モデル（TFMPMM）を示している。臨機応変な段階から、自動化・リアルタイム化へと段階的に高めていく。

図3：トランザクションフローマッピングの成熟度モデル（CSA文書を基に作成）

マッピングでプロテクトサーフェスを精緻化する

トランザクションフローマッピングは、データフローの全体像を与え、すべてのユーザーとDAAS要素を特定できるようにする。その結果、理解されていない・冗長な・廃止された・業務に不可欠でなくなったフローを見つけ出せる。不要なDAAS要素を除去し、不足している要素を追加して、当初のプロテクトサーフェスを精緻化する。

注意：重要なサービスを止める前には、業務中断・セキュリティ課題・データ損失を避けるための備えが要る。関係部門（IT・セキュリティ・コンプライアンス・業務・アプリ所有者）と影響を確認し、依存関係をマッピングし、少なくとも1年分のログ・利用パターンを確認して利用頻度や役割を判断する。停止がセキュリティに与える影響も評価し、問題が起きたときに素早く戻せるロールバック計画を用意しておく。

こうして公開サービスを最小限に抑え、明確に定義され保護された境界を確立することで、アタックサーフェスを効果的に削減できる。精緻化を自動化すれば、削除・制限したサービスやプロトコルが再出現しても事前に検知・緩和でき、アタックサーフェスを長期にわたり最小に保つことができる。

まとめ

第2回では、守るべき対象（プロテクトサーフェス）の周りを、データとトランザクションがどう流れるかを可視化するステップ2を扱った。要点は次のとおりである。

• 目的は、業務システムの動作を理解し、コントロールをどこに置くかを後続ステップに示すこと
• 活動は、DAASの検証・ユーザーと依存関係の特定・トランザクションとデータフローのマッピング・本番／バックアップ等の区別
• 進め方は、既存アーティファクトの分析とスキャン・モニタリングツールの組み合わせ（暗号化はメタデータ分析等で補う）
• 成果として、プロテクトサーフェスを精緻化し、アタックサーフェスを削減できる

守る対象が定まり、その周りの流れが見えたら、次はいよいよ実装である。次回（第3回）は、ステップ3「ゼロトラストアーキテクチャの構築」を扱う。マッピングしたトランザクションフローを基盤に、ポリシー実施ポイント（PEP）を配置し、マイクロセグメンテーションやコンテキストベースのアクセス制御、最小特権を設計していく。

以上

2026年8月11日
ゼロトラストWGリーダー　諸角昌宏

この回のねらい

第1回では、ゼロトラストの出発点である「プロテクトサーフェスの定義」を扱い、守るべき対象をDAAS（データ・アプリケーション・資産・サービス）として業務単位で束ねる考え方を見た。すると自然に、次のような疑問が湧いてくる。

「ゼロトラストは、組織の情報セキュリティ全体の中でどこを担うのか。ISMSやCSFといったリスク管理の枠組みがあれば、それで十分ではないのか。」

今回（第1.5回）では、この問いについて考える。ここでは、ゼロトラストを情報セキュリティリスクマネジメントの国際規格 ISO/IEC 27005（および ISO/IEC 27001）と突き合わせ、役割分担を明らかにすることとする。結論を先に言えば、ゼロトラストはリスク管理に取って代わるものではなく、その中で「技術的な情報資産への防御」を担う実装である。

結論：リスク管理の枠組みとゼロトラスト・アーキテクチャは役割が異なる

まず全体像を押さえる。ISMS（ISO/IEC 27001、27005）やCSFは、「何を・どこまで守るか」を決める“傘”（計画・統治）である。組織のあらゆる資産である情報・業務プロセス・ソフト・ハード・ネットワーク・要員・拠点・組織を洗い出し、リスクを評価し、対応方針（修正・保有・共有・回避）を決める。いわば防犯計画にあたる。

一方、ゼロトラストは、その計画に基づいて「情報資産へのアクセスを実際に守る」実装の一つである。防犯計画に対する「各部屋の鍵と、入るたびの本人確認」にあたる。計画書だけでは侵入者は止まらない。止めるのは実際の鍵であるゼロトラストのような具体策である。

図1：ISMS／CSFという「傘」（計画・統治）の下で、ゼロトラストが技術層を担う。物理・人・組織は別の層が担い、重ね合わせて全体を守る

重要なのは、両者は競合せず重ねて使うという点である。ISMS／CSFだけでは、計画はあっても実際に守る手段が空く。ゼロトラストだけでは、守る手段はあっても全体を見渡す計画がない。両方そろって初めて、計画に沿ってアクセスを確実に守れることになる。

前提の共有：ISO/IEC 27005 の資産分類

ISO/IEC 27005:2022 は、リスク特定の方法として資産ベース（asset-based）とイベントベース（event-based）の2つのアプローチを示している。両者は排他的なものではなく、リスクシナリオの構築において組み合わせて用いることができる。本ブログでは、ゼロトラストのプロテクトサーフェスとの関係を説明しやすい資産ベースの捉え方を軸に取り上げる。

ISO/IEC 27005 は、守るべき資産を2種類に分けて捉える。

• 主要資産（primary assets） — 組織にとって価値の源泉。「情報」と「業務プロセス・活動」の2つからなる。
• 支援資産（supporting assets） — 主要資産が依存する構成要素。ソフトウェア、ハードウェア、ネットワーク、要員、拠点、組織体制など。

ここで大切なのは、ISO/IEC 27005は、人・物理・組織まで含めた「すべての資産」を洗い出すことを前提にしている点である。何があるか分からなければリスクも評価できない、という建て付けであり、NIST CSFも最初の機能が「識別（Identify）」であるように、網羅はリスク管理の出発点になる。つまり、組織全体の「網羅」を担保するのは、この傘（ISMS）側の役割である。

補足：リスクの捉え方 — 資産ベースとイベントベース

ISO/IEC 27005:2022 は、リスクを特定する方法として、性格の異なる2つのアプローチを認めている。

アプローチ	起点・向き	特徴
資産ベース（asset-based）	資産を起点に積み上げる（ボトムアップ）	資産 → 脅威・脆弱性 → 影響、と評価する。網羅的だが、資産が多いと粒度が細かくなり工数がかかる
イベントベース（event-based）	リスクシナリオを起点にする（トップダウン）	脅威源・望ましくない事象 → 影響する資産、と評価する。重要シナリオや脅威インテリジェンス・インシデント事例を取り込みやすい

表1：ISO/IEC 27005:2022 の2つのリスク特定アプローチ

2022年版では、この2つは排他ではなく組み合わせて使える。本ブログが資産ベースに軸足を置くのは、恣意的な省略ではない。ゼロトラストのプロテクトサーフェス定義（DAASの洗い出し）が、まさに資産を起点に積み上げる資産ベースと対応するからである。一方、イベントベースの「どう攻撃されるか」というシナリオ視点は、ゼロトラストのアタックサーフェスやステップ2（トランザクションフローのマッピング）の発想と親和する。つまりゼロトラストは、資産ベースを土台にしつつ、イベントベース的な視点も部分的に取り込む、と整理できる。

ゼロトラストは「技術的に扱える情報資産」を守る

では、ゼロトラストのプロテクトサーフェス（DAAS）は、この資産のうちどこを守るのか。答えを一言でいうと、技術的に扱える情報資産である。ISO/IEC 27005 の各資産を、その観点で対応づけると次のようになる。

ISO/IEC 27005 の資産	種別	性質	ゼロトラストでの扱い
情報	主要資産	技術資産	データ（D）＝守る対象の中核
業務プロセス・活動	主要資産	—	束ねる基準・守る理由（DAASを括る軸）
ソフトウェア	支援資産	技術資産	アプリケーション（A）
ハードウェア・ネットワーク	支援資産	技術資産	資産（A）／通信経路
サービス（DNS・IAM等）	支援資産	技術資産	サービス（S）＝それ自体もプロテクトサーフェス
要員（人）	支援資産	非技術	検証される主体（アイデンティティ）として扱う
拠点（サイト）	支援資産	技術＋非技術	機器は資産（A）／所在地はコンテキスト／建物は範囲外
組織（体制）	支援資産	非技術	ガバナンスが担う（範囲外）

表2：ISO/IEC 27005 の資産と、ゼロトラスト（DAAS）での扱い。太字はプロテクトサーフェスに束ねて守る技術資産

この表から、2つのことが読み取れる。1つは、情報（データ）を中核に、ソフトウェア・ハードウェア／ネットワーク・サービスという技術系の支援資産が、DAASとしてプロテクトサーフェスに束ねられること。DNSやIAMのような基盤サービスも、それ自体が独立したプロテクトサーフェス（守る対象）として扱われる。ここは、ゼロトラストが漏れなく守る範囲である。

もう1つは、生身の人・純粋な物理（建物や環境そのもの）・組織や統治といった「非技術の領域」は、DAASには束ねられないこと。技術的なコントロール（検証・分離・暗号化・監視）で守る以上、守れる対象も技術的に扱える資産に限られるからである。これらはゼロトラストの範囲の外にあり、後述のとおり別の層が担う。 なお、この線引きは「技術資産か、非技術の領域か」で捉えるのが正確であると考える。たとえばIAMやDNSは、一見すると業務を下支えする補助的な存在に見えるが、技術的な実体をもつため、サービス（S）として守る対象に含まれる。見た目の役割ではなく、技術的に対象化できるかどうかが分かれ目になる。

業務プロセスは「束ねる軸」

2つある主要資産のうち、情報はプロテクトサーフェスに束ねられるが、もう一方の業務プロセスは、束ねられる中身ではなく、束ねる“軸”として働く。たとえば決済システムでは、カード会員データ（情報）は守る対象そのものだが、「支払いを処理する」という業務プロセスは、その周辺のデータ・アプリ・資産・サービスを1つのプロテクトサーフェスとしてまとめる基準になる。整理すると、業務プロセスを軸に、関連するDAASを束ねてプロテクトサーフェスを定義する、というのがいちばんシンプルな言い方になる。

図2：業務プロセスを軸に、関連するDAASを束ねてプロテクトサーフェスを定義する

非技術の領域は誰が守るのか — ISO/IEC 27002 の管理策

「ゼロトラストの範囲の外」と述べた人・物理・組織は、放置されるわけではない。ISO/IEC 27005 が参照する管理策の体系（ISO/IEC 27002:2022）は、管理策を4つのカテゴリに分けており、非技術の領域が、技術と並ぶ独立したカテゴリとして正面から扱われている。

ISO/IEC 27002:2022 の管理策	扱う領域・例	主な担い手
技術的管理策	アクセス制御・暗号化・ネットワーク・ログ・監視	ゼロトラスト（情報資産への防御）
物理的管理策	入退管理・施設と装置の保護・電源・災害対策	物理セキュリティ
人的管理策	教育・訓練・審査・雇用／退職の手続き	人事・教育（ZTでは人＝検証主体）
組織的管理策	方針・役割と責任・委託先管理・順守	ガバナンス（ISO/IEC 27001／27014）

表3：ISO/IEC 27002:2022 の4つの管理策カテゴリと、主な担い手

つまり ISO/IEC 27005／27002／27001 は、組織・人・物理・技術の4領域すべてを、「資産の洗い出し」と「管理策」の両面からカバーする。ゼロトラストが担うのは、このうち技術的管理策、得に情報資産へのアクセス防御である。人は人的管理策（教育・審査）とアイデンティティ管理で、物理は物理的管理策（入退管理）で、組織・統治は組織的管理策とガバナンス（ISO/IEC 27001・27014）で、それぞれ受け持つ。

それでもゼロトラストをやる理由

ここまでを踏まえると、「ゼロトラストは一部しか守らない。ならばISMSやCSFだけでよいのでは」という疑問が生じるかもしれない。しかし、これは計画と実装を同じ土俵で比べてしまう誤解である。ISMS／CSFは「アクセスを技術的に守れ」と指示するが、その具体的な設計・実装は別に用意しなければならない。ゼロトラストは、その最も効果的な答えの一つである。

しかも、従来の「社内ネットは信頼する（城と堀）」というやり方には、一度侵入されると内部を自由に横移動されてしまうという致命的な弱点があった。ISMSやCSFという計画は、この弱点そのものは直してくれない。ゼロトラストは、まさにこの「内部の暗黙の信頼」を解消するために生まれた具体策であり、クラウド・リモート・コンテナといった境界が消えた現代の環境に適合する。

また、ゼロトラストは「思想」だけの存在ではない。5ステップの後半、ステップ3（アーキテクチャの構築）やステップ4（ポリシーの作成）で、マイクロセグメンテーションやポリシーといった具体的な対策まで実装する。

要するに、「焦点を絞る」というゼロトラストの原則は、守る対象を賢く定める話（技術資産は漏れなく守る）であって、守備範囲を狭めて一部を見捨てる話ではない。足りない領域は他の層が担い、多層で重ねて全体をカバーする。これが設計思想である。

最後に、この位置づけは、ゼロトラストを最も強く推進する米国政府の施策にも表れている。ゼロトラスト導入を義務づけた大統領令14028（2021年）は、その実装を、NISTが標準・ガイダンスで示す移行ステップに沿って進めるよう定めており、ゼロトラストをリスク管理の一環として位置づけている。CISAのゼロトラスト成熟度モデルも、OMB（行政管理予算局）のゼロトラスト戦略を補完する「複数のロードマップの一つ」とされ、ゼロトラストを唯一の完全解ではなく、段階的に進める枠組みの要素として扱っている。本シリーズが土台とするNSTAC報告書は、ゼロトラスト導入を連邦のリスク管理報告（FISMA）と整合させるよう明確に勧告している。つまり、ゼロトラストを強力に進める政府自身が、それを既存のリスク管理と整合させながら実装する前提に立っているのである。

補足：CISA ゼロトラスト成熟度モデルとの関係

米国CISAのゼロトラスト成熟度モデル（ZTMM）は、ゼロトラストを5つの柱（アイデンティティ、デバイス、ネットワーク、アプリケーションとワークロード、データ）と、それらを横断する機能（可視化と分析・自動化とオーケストレーション・ガバナンス）で表している。これは本ブログの整理とよく噛み合うと考えられる。なお、以下に示すDAASとの対応づけは、CISA ZTMMが定める公式な1対1の対応ではなく、概念上の整理である点に留意してほしい。

• 5つの柱は、DAAS（守る対象）にほぼ対応する。データ→データ、アプリケーションとワークロード→アプリ、デバイス→資産、ネットワーク→通信経路、アイデンティティ→サービス（IAM）と人の扱い。
• 「人＝アイデンティティ」 は、人を守る資産ではなく“検証される主体”として扱うという、本ブログの整理を柱として明示したものである。
• 横断機能のガバナンス が、ISMS／CSFという傘との接続点になる。純粋な物理や組織統制は、ここでも主対象ではない。
• ZTMMは「成熟度モデル」 であり、各柱を段階的に高めていく。プロテクトサーフェスごとに成熟度を評価し、練習から本命へ反復的に進めるという第1回の考え方と同じ筋である。

まとめ

ゼロトラストは、組織の情報セキュリティ全体の中でどこを担うのか——この回の答えは次のとおりである。

• ISMS（ISO/IEC 27001・27005）／CSFが「傘」として、全資産（組織・人・物理・技術）を網羅し、何を・どこまで守るかを決める（計画・統治）。
• ゼロトラストは、その中の「技術的な情報資産への防御」を担う実装。DAASの範囲は漏れなく守り、ステップ3・4で具体的な対策まで実装する。
• 人・物理・組織は、ゼロトラストの範囲外。ISO/IEC 27002の人的・物理的・組織的管理策や、アイデンティティ・ガバナンスが担う。
• 両者は競合せず、重ねて使う。網羅はリスク管理（ISMS, CSF）が担保し、技術的な防御はゼロトラストが引き受ける、という補完関係である。

したがって、「ゼロトラストは何のためにやるのか」への答えは、ISMS／CSFが求める“アクセスを技術的に守る”を、現代の環境で最も効果的に実現する手段だから、となる。次回（第2回）は本編に戻り、ステップ2「トランザクションフローのマッピング」を扱う。守るべき対象が定まったら、次はそのデータやトランザクションがどこをどう流れているかを可視化していく。

以上

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ステップで構成される。

1. プロテクトサーフェスの定義 — 何を守るべきか（DAAS要素）を特定する
2. トランザクションフローのマッピング — データやトランザクションがどこをどう流れているかを把握する
3. ゼロトラストアーキテクチャの構築 — リスクと露出を最小化する構成を設計する
4. ゼロトラストポリシーの作成 — 誰が・何にアクセスできるかを定義する
5. ネットワークの監視と保守 — 運用しながら継続的に改善する

このプロセスで押さえておきたいのは、一度きりで完結するものではなく、反復的（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つの業務情報システムである。

1.  データ：カード会員データ（取得と支払い処理のためのデータ）。
2. アプリケーション：カード会員データを管理し、支払いを処理するWebアプリケーション。
3. 資産：そのカード会員データを保存するデータベースをホストするサーバー。
4. サービス：外部のクレジットカード決済処理サービス、および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「トランザクションフローのマッピング」を取り上げる。守るべき対象が決まったら、次はそのデータやリソースが「どこから来て、どこへ流れているのか」を可視化していく。

以上