「ゼロトラストネットワーク」を読んだので要約する

目的

少しずつ実際のソリューションが登場しつつあるゼロトラストネットワークについて、その成り立ちや設計思想、セキュリティの構成や実運用の課題について解説された「ゼロトラストネットワーク」の要約をしてみます。
特に、組織のネットワーク構築や運用を担当する情報システム部門の担当であれば、今後のネットワークの在り方を考える上で指針になる一冊だと思います。
https://www.oreilly.co.jp/books/9784873118888/

ゼロトラストネットワークの成り立ちと概要

• 1967年まで遡り、主に軍事・学術目的で通信するために、各ノードがパケットを交換しあうARPANETというネットワーク設計が考案されました。今のインターネットの前身です。
• 設立した当初はネットワーク上のノードの身元がほとんど判別できる状態だったので情報の漏えいや改ざんを気にする必要がなかったのですが、ネットワークの参加者が増えるにつれてセキュリティの必要性が高まります。
• 当初のアーキテクチャでは「境界モデル」という、各境界がそれぞれに干渉できないようにネットワークをゾーニングしていました。
  • 信頼できるゾーン(tsust zone)、出来ないゾーン(untsust zone)、DMZ(DMZ zone)に分割
    参照：ファイアウォールについて
• ネットワークをよりセキュアに運用する考え方は時代によって変わってきましたが、クラウド環境で機密データを扱うようになってきた近年、ゼロトラスト(前提として、授受する全てのパケットを信頼しない)で構成するネットワーク環境やソリューションが少しずつ広まってきています。

第1章　ゼロトラストの基礎

ゼロトラストネットワークには、5つの原則がある。

• ネットワークは常に安全ではないとみなされる。Never trust, Always verify.（決して信頼せず必ず確認せよ）
• ネットワーク上には外部および内部の脅威が常に存在する。(信頼に足る安全なネットワークはない。)
• ネットワークを信用できると判断するには、ローカルネットワークでは不十分である。
• デバイス、ユーザー、ネットワークフローは1つ残らず認証・認可されなければならない。
• ノードAからノードBに対するアクセスポリシー(認可)は動的に変化するものあり、できるだけ多くの情報源に基づいて作成されなければいけない。

ゼロトラストネットワークの実運用のためは以下のような機能が必要となる。

• ネットワーク内にコントロールプレーンシステムを構築する。
  • デバイスとユーザとアプリの各エンティティについて、個別ではなくまとめて認証・認可を行う。
  • コントロールプレーンによって算出されたスコアとアクセスポリシーの突合・アクセス許可を行う。
• データプレーンシステムを構築する。
  • 単純なトラフィック処理をするレイヤー。なるべく高速な処理が求められる。

「境界モデル」が有効だった時代はともかく、VPNは攻撃者にとっては誰にも疑われないバックドアになり得るので非推奨。

第2章　信頼と信用の管理

ゼロトラストネットワーク内で、いかにエンティティを信頼するかという仕組みについて。

• トラストチェーンの構成

  • 運用者が特定のシステムを信頼することを宣言し、そのシステムが別のシステムを信頼することで生まれる信頼の回帰。
  • 運用者はトラストアンカー(信頼の基点)となる。

• PKI証明

  • デバイス、ユーザー、アプリケーションというそれぞれのエンティティはPKIによってアイデンティティを証明する。
  • 政治的な理由で変動する公的機関のCAを信頼することは難しいので、パブリックPKIを使うことは推奨されない。

• ネットワーク内の全てのアクションは信頼スコアに基づいて動的に評価される。

  • トラストエンジンは各種のエンティティデータとアクティビティのデータから信頼スコアを計算する。
  • トラストエンジンはアクセスリクエストを認可するためのエージェントファイルを作成し、ポリシーと突合してアクションの可否を評価する。

• 最もセキュアなネットワークは、高い権限を持つシステム管理者がいないネットワーク

第3章　ネットワークエージェント

• エージェントとは
  • ネットワークリクエストをするエンティティの持つ属性データの組み合わせ。
  • ユーザの信用スコア、デバイスの信用スコア、IPアドレスなどが属性データとなる。
  • エージェントに含まれる属性データを本当に信頼できるかという問題はある。
  • ユーザが自らのデータを改ざんしたりIPアドレスを変更している場合など。
  • ゼロトラストでの認可の判断はエージェント単位である。
  • ユーザやデバイスなどの個々のエンティティ単位での認可は推奨されない。
  • アクセスポリシーも、実際に認可される単位であるエージェントに対して定義される。
  • エージェントや認可リクエストの結果はキャッシュしない。
  • 認証はセッションごとに実施されるが、エージェントや認可リクエストは動的に変化するため、認可の判断は最新のデータを使うのが望ましい。
  • エージェントは機密情報を含むので、信頼されるコントロールプレーンシステムで管理する。

第4章　認可の判断

• 認可システム全体の構成として、以下の４つの役割を持つシステムで認可を行う。
  • エンフォーサ
    • データプレーンの機能の一つ。
    • ロードバランサー、プロキシ、FWとして実装される。
    • ネットワークリクエストをポリシーエンジンに送信する。
  • ポリシーエンジン
    • コントロールプレーンの機能の一つ。
    • 事前定義されたポリシーとトラストエンジンを利用して判断する。
  • データストア
    • コントロールプレーンの機能の一つ。
    • 各種エンティティの総合的なデータストアであり、信用スコア計算のための情報源となる。
  • トラストエンジン
    • コントロールプレーンの機能の一つ。
    • エンティティの信用スコアを計算する。

参照：Zero Trust Networks (4/10)

• ポリシーを定義するのは誰か

  • ポリシーを特定のシステム管理者だけで定義せず、各チームが担当するサービスのポリシーを定義する。
  • ポリシーはバージョン管理システムで管理し、変更時のレビュー体制を作る。

• 信頼スコアの公開

  • 機密情報ではないが、公開すると第三者による操作のきっかけになりかねないので公開すべきでない。
  • だが、エンドユーザはアクセスが拒否された時にスコアを確認できなければ拒否理由を把握できないので、改善することができない。

第5章　デバイスの信頼と信用

• デバイスは工場出荷時が一番信頼性が高い。
  • 使い続けるに従ってスコアは下がる。
  • 信用を継続的に更新するメカニズムが必要となる。
• デバイスのアイデンティティはTPMに秘密鍵を保管することで保護する。
  • TPMのようなセキュリティモジュールに格納された秘密鍵はOSでさえ直接アクセス出来ない。
• デバイス認証にはX.509CA証明書を使うのが望ましい。
• デバイスのスコア判定はリモートで行うのが望ましい。
  • ローカル判定だと、ホストを乗っ取れば情報が偽造になってしまう。

第6章　ユーザーの信頼と信用

• ユーザディレクトリを適正に管理する必要がある。
• 認証することでユーザの利便性を損ねてはならない。
  • UXが疎かなセキュリティはないがしろにされて抜け道を作られることになる。
  • よって、ユーザの信用スコアが十分に高い場合は、ユーザにそれ以上認証を求めるべきでない。
• SSOによって認証を一元化することが望ましい。
• グループ単位での認証
  • シャミアの秘密分散法という、１つのシークレットデータを複数のユーザに分配する手法で信頼性を確保する。

第7章　アプリケーションの信頼と信用

• アプリを信頼するためにセキュアなビルドパイプラインを構成する必要がある。

第8章　トラフィックの信頼と信用

• トラフィック自体は暗号化によって機密性を実現するが、暗号化したデータは復号化しないとトラブルシューティングが出来なくなるという問題がある。
  • とは言え、ネットワークプロトコルではほとんどのデータは暗号化は自動で行われるので、ゼロトラストでの認証と合わせて暗号化を行う。
• 暗号化プロトコルとしてIPsecを選択する場合、丸ごとカプセル化するトンネルモードではなくデータ部分だけをカプセル化するトランスポートモードを選ぶ。
• ホストフィルタリングを有効にする。
  • フィルタリングを有効化することにより、ネットワークのエンドポイントであるデバイスをセキュリティに積極的に関与させる。
  • ブックエンドフィルタリングという、パケットの送受信両方に対してフィルタリングをすることも推奨される。例えるなら集団免疫で、潜在的な脅威から保護する。

第9章　ゼロトラストネットワークの実現

• GoogleではGCPベースのゼロトラストソリューションとして「BeyondCorp」というセキュリティネットワークを利用している。