ハードル低めのゼロトラストネットワークのはじめ方

デジタル庁 (2022) 「ゼロトラストアーキテクチャ適用方針」やRais et al.(2025) 『ゼロトラストネットワーク 第2版』などの影響で、やたら長くて細々したゼロトラスト語りを見かけるようになった。残念ながら長すぎて、顧客や営業はもちろん、ソフトウェア・エンジニアも9割ぐらいの人はついてこない。

ゼロトラストの提唱者John Kindervag氏へのインタビュー記事によると、ゼロトラストネットワークは、誰が（何が）どこからどのデータを参照する必要があるかというビジネス要件を把握し、それを可能にしつつも、なるべく小さい権限を設定する最小権限戦略（Least Privilege Strategy）がグランド・ストラテジーだ。「何が」には、ネットワーク機器などのハードウェアや、サービスなどのソフトウェアが含まれる。

抽象的過ぎる？ — よろしい。まずはデータフロー図（DFD）を描きたまえ。それで業務データを誰がどこで何に入力し、誰がそれをどこで何で閲覧・更新し…と言うビジネス要件の全体像が掴める。大事なことだから繰り返す。まずはデータフローダイアグラムを描け。描くんだ。業務継続計画にもとづくバックアップなど、エンドユーザーが直接触れないデータフローを忘れないように描け。Kindervag氏へのインタビュー記事では、こうやってビジネス要件とデータのトランザクションの関係を把握（Mapping）しろと言う話になっていた。

保護対象（Protect Surface）はデータ以外もある？ — アプリケーションもアセット（機器）もサービスも、データと独立していることは無いから、DFDから漏れることはない。逆に言うと、ハードウェアやミドルウェアやアプリケーションもDFDに書きこんでおこう。ビジネス要件がつかめれば、後はやることは見えてくる。DFDから保護対象（Protect Surface）と、ヒトやモノの役割（ロール）をリストするのは容易だ。

DFDからは、職位と職務（や場所や日時）に応じたユーザーが必要なデータの閲覧や編集の範囲が、データベースのテーブルのカラムやレコードといった粒度で明確になる。IdPでユーザーを細かく分類すれば、不要な権限を与えずに済み、ゼロトラストに整合的になる。エンドユーザーやアプリケーション開発者、保守要員のクレデンシャルが漏洩したり、もしくは当人が不正したときに、被害を抑制できる。

モノの方は、例えば、

1. 医療機器監視用VPN機器は、接続元は委託会社に限られ、接続先は医療機器だけで済むのがわかる。ゼロトラストでは、医療機器監視用の独立した（仮想）ネットワークを用意すべきとなる。実際、VPN機器にセキュリティーホールがあっても、医療機器しか攻略されない。接続元IPアドレスの制限があれば、そのリスクも大きく減らせる。
2. 業務システムのサーバーが、自分からクライアントに接続しようとはしないことがわかる。（ポートや接続元の制限に加えて）クライアントからのインバウンド接続のみを許可し、サーバーからアウトバウンド接続は許さないようにネットワーク機器でアクセス制限すれば、サーバーがランサムウェアに感染したとしてもデータ流出は原則防げる。境界防御に分類されそうだが、Kindervag氏がゼロトラストの例として出していた。
3. 取得済みのバックアップは、データ更新をすることはなく、障害時に復旧に使うとき以外は閲覧する必要もないことがわかる。ゼロトラストでは、ネットワーク的に隔離された場所にバックアップは保管すべきとなる。ランサムウェアに侵入されても、バックアップまで暗号化されて業務継続が困難にならなくなる。

ネットワーク機器やソフトウェアにも最低限の権限しか与えないようにすることがどういうことか、それにどういう御利益があるかは大概の場合そう難しい話ではない^*1。

Kindervag氏の昔の論文では、①あらゆる通信の暗号化と認証、②ロールベースのアクセス制御を厳格に定め運用、③すべてのトラヒックを検査・ログを記録（さらに自動防御）が、ゼロトラストの基本コンセプトとして紹介されていた。これらは上述の大方針を満たすために必要なことである。なお、あらゆる通信（とメディア）の暗号化は、サーバー/ネットワーク保守要員や通信機器などが業務に不要なデータを閲覧する権限を与えない、すべてのトラヒックを検査は業務上必要な頻度や時間帯などでしかデータ閲覧を不問にしないと言う観点で、大方針の実現するための手段となる。

実施にあたって注意すべきこと^*2、難しいこともあるのだが、ユーザーやアプリケーションやサーバー/ネットワーク機器などのデータアクセスのビジネス要件を把握しておくのがまず大事。ビジネス要件が分からないし、ビジネスの阻害をしたくない…と言う理由で、過剰に大きな権限を与えてしまうと言うことは往々にあるものだ。逆に、ビジネス要件に対して権限が小さすぎて現場が野良デバイスを不用意に使い出すようなこともある。無数に立った野良AWSサービスの整理の必要性からFinOpsという発想が生まれたそうだが、乱立は社内のオンプレミス環境の制限が強すぎたためのところも多いはず。

なにはともあれ、まずはDFDを描こう。描き始めよう。完璧なモノでなくても、検討漏れがすぐわかるという御利益がある。ゼロトラストの第一歩だ。

*1難しくなる場合もある。暗号技術の発達で、データ作成者と、バックアップの作成者と、バックアップの保管者と、リストア実施者の権限を細かく分けることも、不可能ではなくなった。もちろん、費用や労力はかさむため、ここまで細かくロールを分けるべきかは、状況による。

*2例えば、一般的なネットワーク機器やOS、ミドルウェアでできる事を実施し、特殊なセキュリティーアプライアンス製品の導入はビジネス上の必要性が本当にあるのかはよく検討した方がよい。リモートでノートPCなどのモバイル機器のデータを消去できる製品があったが、OSのドライブ暗号化で間に合うかも知れないし、その製品のセキュリティーホールが発覚していた。2020年頃からトラストスコアのようなものを用いた動的な権限付与がトレンドになっているが、攻撃者の多い海外からのIPアドレスを動的に制限するような機能が本当に必要なのかは謎だ。海外からのリモートアクセスを禁止するようなシンプルな運用で間に合うことも多い。