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）を配置し、マイクロセグメンテーションやコンテキストベースのアクセス制御、最小特権を設計していく。
以上