ゼロトラストネットワーク
境界防御の限界を超えるためのセキュアなシステム設計
Zero Trust Networks
Building Secure Systems in Untrusted Networks
https://gyazo.com/8d84c973011b369a2a744cb4f01205e8
hr.icon
はじめに
セキュリティは、システムの運用を(制限するのではなく)可能にするために絶えず存在していなければならない。
いい話
セキュリティをがっつりやっている人々、だいたいこういうことを言ってくれるイメージがある 本書の対象読者
ネットワークエンジニア、セキュリティエンジニア、CTO、そしてそれ以外のすべての人が、ゼロトラストを学ぶことから恩恵を受ける。本書に含まれている原理の多くは専門的な知識がなくても明確に理解できるものであり、ゼロトラストモデルを実現するための決定を行い、全体的なセキュリティレベルを徐々に改善していくのに役立つ。
心強いことだぜ
本書を執筆した理由
システム / ネットワーク設計へのアプローチについて私たちが業界カンファレンスで講演を行うようになったのは 2014 年のことである。
けっこう前だ
1章 ゼロトラストの基礎
ゼロトラストは、ネットワークに信頼を置くことに伴う問題の解決を目指すもの である。ネットワークに信頼を置かなくても、(トランスポート層の物理的セキュリ ティを合理的に無視しつつ)ネットワーク通信を効率的にセキュアにすることは可能 だ。これが見上げるほど高い目標であることは言うまでもない。ありがたいことに、 最近の暗号はかなりよくできており、正しく自動化されたシステムがあれば、この目 標は実際に達成可能である。
1.1 ゼロトラストネットワークとは何か
ゼロトラストネットワークには 5 つの基本的な原則がある。
・ネットワークは常に安全ではないと見なされる。
・ネットワーク上には外部および内部の脅威が常に存在する。
・ネットワークを信用できると判断するには、ローカルネットワークでは不十分である。
・デバイス、ユーザー、ネットワークフローは 1 つ残らず認証および認可される。
・ポリシーは動的であり、できるだけ多くの情報源に基づいて作成されなければならない。
https://gyazo.com/183f14f440979ce9910febc40e044f32
https://gyazo.com/411b271d20a318dfaef4e91de4e74fb0
1.1.1 ゼロトラストコントロールプレーン
サポーティングシステムはコントロールプレーン(control plane)と呼ばれる。そ れ以外のほとんどのものはデータプレーン(data plane)と呼ばれ、コントロールプ レーンによって管理される。
1.2 境界モデルの進化
本書で説明する従来のアーキテクチャは、物理的な防衛手段として用いられる城壁 にちなんで、よく境界モデル(perimeter model)と呼ばれる。この手法では、境界線 を引くことによって機密データを保護する。侵入者は、この境界線を突破しなければ データにアクセスできない。
1.2.1 グローバルIPアドレス空間の管理
1.2.2 プライベートIPアドレス空間の誕生
1980 年代の終わりから 1990 年代の初めにかけて IP の導入が進むと、アドレス 空間の無駄遣いが深刻な問題となった。
1.2.3 プライベートネットワークからパブリックネットワークへの接続
インターネット上でおもしろいことが次々に行われるようになると、すぐにほとん どの組織が少なくとも「何らか」の形で参加したいと考えるようになった。
いい話…
1.2.4 NATの誕生
NAT (Network Address Translation)
1.2.5 現代の境界モデル
ネットワーク運用者はビジネス上のさまざまな目 的に応じて扉を開かなければならないが、オフラインネットワークの強固なセキュリ ティを犠牲にするわけにはいかない。そこで、それぞれの扉に厳重なセキュリティ制 御を施すことで、リスクを最小限に抑えるのが当時の主流だった。
1.3 潜在的な脅威の進化
組織がインターネットに接続されたホストを導入するようになると、攻撃もそれに 応じて変化し、電話回線網ではなくインターネット経由で仕掛けられるようになっ た。
世界初の(ソフトウェア版の)トロイの木馬が出回り始めたのは、1990 年代の終 わり頃だった。
1.4 境界モデルの弱点
1.社員がフィッシングメールの標的となる
2.企業のマシンに不正侵入し、リモートコマンドシェルを取得する
3.企業ネットワークで横断的侵害を開始する
4.権限が付与されたワークステーションを特定する
5.このワークステーションでローカル権限に昇格し、キーロガーをインストールする
6.開発者のパスワードを盗み出す
7.権限が付与されたワークステーションから本番環境のアプリケーションホストに侵入する
8.開発者のパスワードを使ってアプリケーションホストの権限を昇格する
9.アプリケーションからデータベースのログイン情報を盗み出す
10.乗っ取ったアプリケーションホストを使ってデータベースの内容を抽出する
1.5 信用の在りか
境界モデル以外の選択肢について検討する際には、信用できるものと信用できない ものをしっかり理解しておかなければならない。
ゼロトラストモデルは、その名のとおり、ネットワークを盲目的に信頼しないモデ ルである。運のよいことに、私たちはそのようなネットワークとしょっちゅうやり取 りしている。そう、インターネットである。
1.6 成功要因としての自動化
ゼロトラストネットワークでは、新しいプロトコルやライブラリは要求されない。ただし、既存のテクノロジを斬新な方法で使用する。ゼロトラストネットワークを構 築して稼働させるには、自動化システムが必要である。
1.7 境界とゼロトラスト
これに対し、ゼロトラストモデルは基本的に負けを認め、「悪人」はどこにでもいるという現実を受け入れる。壁を築いて攻撃から弱い人々を守るのではなく、すべての住民を検閲者に変える。
ゼロトラストネットワークは、ユーザー / アプリケーション認証、デバイス認証、信用という 3 つの重要な要素で構成される。
突き詰めれば、境界モデルの欠点は、全体的な保護に欠けていることにある。頑丈 な殻に覆われた脆弱な体のようなものである。私たちが本当に求めているのは骨と肉 が詰まった堅牢な体である。
それで表紙の動物が甲殻類なのか？
ゼロトラストモデルの機能の大部分がエンドユーザーか らは透過的に実行できることも考えると、セキュリティと利便性のトレードオフを和 らげるとさえ思える ̶̶ セキュリティを強化すればするほど、利便性が高くなる。
1.8 クラウドへの適用
ゼロトラストモデルでは、同じデータセンター内であっても、デフォルトですべて のパケットを暗号化することが推奨される。このため、どのパケットがインターネッ ト経由のもので、どのパケットがそうではないのかについて運用者が考慮する必要は ない。
1.9 まとめ
2章 信頼と信用の管理
2.1 脅威モデル
2.1.1 一般的な脅威モデル
2.1.2 ゼロトラストの脅威モデル
2.2 強力な認証
2.3 公開鍵基盤
2.3.1 認証局とは何か
2.3.2 ゼロトラストにおけるPKIの重要性
2.3.3 プライベートPKIとパブリックPKI
2.3.4 パブリックPKI：ないよりは断然まし
2.4 最小権限
2.5 変化する信頼と信用
2.6 コントロールプレーンとデータプレーン
2.7 まとめ
3章 ネットワークエージェント
このユーザーとデバイスの組み合わせはゼロトラストによって導入される新しいコ ンセプトであり、本書でネットワークエージェント(network agent)と呼ぶものだ。 ゼロトラストネットワークでは、ユーザーとデバイスを別々に扱ったのでは不十分である。
3.1 エージェントとは何か
ネットワークエージェントとは、ネットワークリクエストをするエンティティについてわかっているデータの組み合わせを表す用語であり、通常は、ユーザー、アプリケーション、デバイスをデータとして含んでいる。
リクエストのコンテキスト全体に権限を付与すれば、クレデンシャルの窃取による影響が大きく低減される。
3.1.1 揮発的なエージェント
3.1.2 エージェントには何が含まれているか
検討すべきもう 1 つの点は、エージェントに含まれているデータが信用できるか どうかである。たとえば、調達プロセスから得られるデバイスデータは、そのデバイ ス上で実行されているエージェントから得られるデバイスデータよりも信憑性が高 い。
3.2 エージェントはどのように使用するか
ゼロトラストネットワークでの認可の判断において、実際に認可されるのはエー ジェントである。デバイスとユーザーを別々に認可したくなるが、そのようなアプ ローチは推奨されない。認可されるエンティティはエージェントであるため、ポリ シーもエージェントに対して定義される。
3.2.1 認証には使用されない
エージェントとの関連において認証と認可の違いを理解しておくことは重要である。
はい
一般に、認証はセッションごとに実施されるが、認可はリクエストごとに実施する のが最善である。このため、認証リクエストの結果はキャッシュしてもよいが、エー ジェントや認可リクエストの結果はキャッシュすべきではない。
認可を取り消してから認証を取り消す
なるほど？このあたりを自分の頭で考えたことなかったかもな〜
3.3 エージェントにはどのようにアクセスするか
ただし、データの機密性はユーザーだけにとどまらない。デバイスの詳細も、執拗 な攻撃者の手に渡れば、機密データになり得る。
3.4 標準は存在しない
本書の執筆時点では、ほとんどのゼロトラスト ネットワークが自社開発されたシステムで構成されている。それらのシステムはエー ジェントの標準を独自に策定しているが、公式の標準があればコントロールプレーン の可能性の扉が開かれ、さまざまなコンポーネントの組み合わせが可能になるだろう。
3.4.1 厳格さと流動性の両立
3.4.2 望まれる標準化
ありがたいことに、そのようなデータフォーマットを定義する規格がすでにいく つか存在する。SNMP(Simple Network Management Protocol)とそれに関連する MIB(Management Information Base)はその最たる例である。
このへん、ぼくにはぜんぜん馴染みがないな〜！
3.4.3 標準化されるまではどうするか
3.5 まとめ
4章 認可の判断
ゼロトラストネットワーク内で発生するプロセスの中で、認可は間違いなく最も重要なプロセスである。
4.1 認可アーキテクチャ
https://gyazo.com/dd04ce8a5ea3b4c3628b30358b3430e0
4.2 エンフォーサ
このコンポーネントは認可フローの「最前線」に位置し、認可システムの残りの部分による判断を実際に適用する。
4.3 ポリシーエンジン
ポリシーエンジンは認可の可否を判断するコンポーネントである。
4.3.1 ポリシーストレージ
ポリシールールはバージョン管理システムに格納するのが理想的であり、次のようなメリットがある。
● ポリシーの変更履歴を管理できる。
● ポリシー変更の経緯をバージョン管理システムでトラックできる。
● ポリシー適用時の期待される動作を実際のエンフォーサに対してテストできる。
4.3.2 よいポリシーの特徴
4.3.3 ポリシーを定義するのは誰か
4.4 トラストエンジン
トラストエンジンは、ゼロトラストネットワークにおいて特定のリクエストやアクションに対するリスク分析を行うシステムである。このシステムの責務は、特定のリクエスト / アクションを許可することの危険度を定量的に評価することにある。ポリシーエンジンは、最終的な認可の判断に、このスコアを使用する。
トラストエンジンが専門家会議で、ポリシーエンジンが政府って感じですかね
難しい計算問題を解くために機械学習が使用される機会は増えてきているが、だか らといって、トラストエンジンのより静的なルールが不要になるわけではない。スコアモデルの導出には限界があり、スコア関数のカスタマイズも求められる。このた め、トラストエンジンでは、静的なルールと機械学習を組み合わせて使用するのが一般的である。
4.4.1 スコア化すべきエンティティ
4.4.2 危険と見なされるスコアの公開
4.5 データストア
4.6 まとめ
5章 デバイスの信頼と信用
ゼロトラストネットワークでは、手放しでデバイスを信頼するのは非常に危険であ る。このことはまた、きわめて難しい問題でもある。セキュリティ対策の成否を決め るのはデバイスである。なぜなら、デバイスは戦場であり、セキュリティは勝つか負 けるかのどちらかだからだ。ほとんどの被害は、信頼していたデバイスに攻撃者が何 らかの方法でアクセスできるようになることから始まる。そのようなアクセスが可能 になったが最後、そのデバイスがいくら自身の安全性を訴えたとしても、それを信じ るわけにはいかなくなる。
5.1 信頼と信用を獲得する
5.1.1 アイデンティティの生成と保護
5.1.2 静的なシステムと動的なシステムでのアイデンティティのセキュリティ
比較的静的なインフラストラクチャやエンドユーザーデバイスでは、人間は手軽で 安全な選択肢だが、自動化されたインフラストラクチャでは当然ながら役に立たな い。
これらの責務を分割し、複数のシステムに正当性を検証させれば、このループから 人間を無事に(厳密には、できるだけ安全に)救い出すことができる。
5.2 コントロールプレーンによるデバイスの認証
5.2.1 X.509
X.509 は、デバイスのアイデンティティと認証に関する規格の中で、おそらく最も重要な規格である。この規格は、公開鍵証明書、失効リスト、証明書チェーンの検証 方式に対するフォーマットを定義する。X.509 のフレームワークはアイデンティティ の形成に役立つ。アイデンティティは、本書で取り上げるほぼすべてのプロトコルに おいてセキュアなデバイス認証に使用される。
X.509 は存在は知っているけれど身近に感じたことはないな〜 ゼロトラストネットワークでのデバイス認証に X.509 を応用するのはすばらしい ことである。ほぼすべてのプロトコルにとって、X.509 はデバイスを認証するための 礎石であり、エンドツーエンドの暗号化の実現に貢献する。ゼロトラストネットワー クでは、すべてのデバイスが X.509 証明書を取得すべきである。
5.2.2 TPM
Platform Configuration Register
Polymerase Chain Reaction じゃなかった…
成熟したゼロトラストネットワークにおいて、強力なデバイス認証に対する最善の選択肢が TPM であることは明らかである。
5.2.3 ハードウェアベースのゼロトラストサプリカント
認証クライアント・ソフトウェアのこと？
5.3 インベントリ管理
インベントリ管理では、デバイスとそれらのプロパティを分類する必要がある。こ れらのレコードを管理することは、サーバーでもクライアントデバイスでも等しく重 要である。場合によっては、これらを物理デバイスとして考えるよりも、ネットワー クエンティティとして考えるほうが効果的である。確かに通常は物理デバイスだが、 ネットワーク上の論理エンティティという見方もできなくはない。
インベントリ管理システムが複数存在するのは特に珍しいことではない。たとえば 多くの企業では、資産管理ソフトウェアと構成管理ソフトウェアを両方とも使用して いる。どちらも私たちにとって有益なデバイスメタデータを格納する。単に、別々の 方法で集められた別々のデータセットを格納しているだけである。
5.3.1 想定される挙動を把握する
クライアント向けシステムの動的な性質に対処するには、少し異なるアプローチが 必要である。1 つの方法は、単にサービスへのグローバルアクセスを許可し、mTLS で保護することである。この場合、クライアントがサービスと通信するには、デバイ ス証明書を提供しなければならない。デバイス証明書があれば、インベントリデータ ベースでそのデバイスを調べた上で、権限を付与するかどうかを判断できる。この方 法の利点は、mTLS をサポートするシステムがすでにたくさんあり、専用のクライ アントソフトウェアが厳密には必要ないことである。アクセシビリティやユーザビリ ティをそれほど損なわずに、それなりに強力なセキュリティを実現できる。
5.3.2 セキュアイントロダクション
新しいデバイスからの最初の接続は心もとないものである。結局のところ、これら のパケットはどこかで受信されなければならず、厳格に認証されなければ、リスクが 存在することになる。このため、新しいデバイスと初めて通信するシステムには、こ の最初の接続を認証できるようなメカニズムが必要である。
人間同士も最初はお互いに自己紹介するもんな
使い捨て
攻撃者が鍵を盗み出して再利用するのを防ぐために、イントロダクション関連のクレデンシャルや権限は使い捨てにすべきである。
短命
有効だが使用されない鍵が溜まるのを防ぐために、イントロダクション関連のクレデンシャルや権限は短命にすべきである。
第三者
イントロダクションに第三者を活用することで、責務の分離を実現すると 同時に、セキュリティ対策が手薄になるのを回避し、運用上の問題を軽減 できる。
5.4 デバイスの信用の更新
5.4.1 ローカル測定
5.4.2 リモート測定
5.5 ソフトウェアの構成管理
5.5.1 構成管理ベースのインベントリ
5.5.2 信頼できるセキュアな情報源
このため、これらの属性に対する書き込みアクセスを制限することが重要となる。 もちろん、自己申告された属性を判断に使用できないことはないが、いかなる場合も それらを事実と見なすべきではない。自己申告された属性については、事実ではなく ヒントであると考えればよいだろう。
5.6 ユーザーの認可にデバイスデータを使用する
5.7 信用のサイン
5.7.1 イメージの経過時間
5.7.2 アクセス履歴
5.7.3 位置
5.7.4 ネットワーク通信パターン
5.8 まとめ
6章 ユーザーの信頼と信用
6.1 アイデンティティ発行機関
6.2 プライベートシステムでのアイデンティティの生成
6.2.1 政府発行の識別証
6.2.2 物質界に勝るものなし
6.2.3 期待値
6.3 アイデンティティの格納
6.3.1 ユーザーディレクトリ
6.3.2 ディレクトリの管理
6.4 いつ認証するか
6.4.1 信用されるための認証
6.4.2 認証ドライバとしての信用
6.4.3 複数の経路の使用
6.4.4 アイデンティティと信用のキャッシュ
6.5 どのように認証するか
6.5.1 ユーザーが知っているもの：パスワード
6.5.2 ユーザーが持っているもの：TOTP
6.5.3 ユーザーが持っているもの：証明書
6.5.4 ユーザーが持っているもの：セキュリティトークン
6.5.5 ユーザー自身のもの：生体認証
6.5.6 アウトオブバンド認証
6.5.7 シングルサインオン（SSO）
6.5.8 ローカル認証への移行
6.6 グループの認証と認可
6.6.1 シャミアの秘密分散法
6.6.2 Red October
6.7 何かを見たら報告する
6.8 信用のサイン
6.9 まとめ
7章 アプリケーションの信頼と信用
コードの信用を確立するために必要なのは次の 4 つである。
● コードを生成する信用されたユーザー
● 正常に動作するコードで実行される信用されたアプリケーション
● 正常にデプロイされたインフラ上で実行される信用されたアプリケーション
● アプリケーションに対する悪意を持つ行動の監視
7.1 アプリケーションパイプライン
このプログラムはサプライチェーンセキュリティ(supply chain security)に似ている。
7.2 ソースコードの信用
7.2.1 リポジトリの保護
7.2.2 コードの真正性と監査証跡
7.2.3 コードレビュー
ふだん「悪用を防ぐ」って観点でコードレビューを実施しているわけではないけど。 7.3 ビルドの信用
7.3.1 リスク
Ruby を中心にやっているとビルドのことはあんまり考えませんねぇ。 7.3.2 信用できる入力、信用できる出力
7.3.3 再現可能なビルド
7.3.4 リリースバージョンと成果物バージョンを切り離す
このため、ビルドシステムを作成する場合は、一般に公開される バージョンとは別に、イミュータブルなバージョンを生成するとよいだろう。リリー スバージョンとビルド成果物バージョンのマッピングは、その後のシステム(ディス トリビューションシステム)で行えばよい。このようにすれば、使い勝手を犠牲にし たり、まずいセキュリティプラクティスを取り入れたりしなくても、イミュータブル なビルド成果物を維持できるようになる。
7.4 ディストリビューションの信用
7.4.1 成果物のリリース対象化
ビルド番号とリリースバージョンを区別する方法、なるほど。
7.4.2 ディストリビューションのセキュリティ
ソフトウェアディストリビューションは配電と似ている。
そんなふうに考えたことはなかった！配電は素人なもので…。
7.4.3 完全性と真正性
署名により、署名されたファイルに対して完全性と真正性が提供される。署名にはハッシュ値が含まれているため、 ファイルの内容が改ざんされていないことがわかる(完全性)。また、署名を問題な く復号できれば、その署名を生成した相手が秘密鍵を所有していることがわかる(真正性)。
7.4.4 ディストリビューションネットワークの信用
TLS 使いましょう。令和ですもんね。
7.5 人間が関わる部分を限定する
7.6 アプリケーションの信用
7.6.1 アップグレード限定ポリシー
7.6.2 認可を受けたアプリケーション
シークレットに有効期限を割り当てることは、シークレットの悪用を制限する上で きわめて効果的である。デプロイされるインスタンスごとに新しいシークレットを作 成し、そのシークレットに有効期限を割り当てるようにすれば、何が実行されている のかが正確にわかるはずである。というのも、生成されているシークレットの数、そ れらのシークレットが誰に付与されたか、そしてそれらのシークレットの有効期限 は正確にわかっているからだ。シークレットに有効期限を設定できるようにすると、「不正な」インスタンスがいつまでも動作することがなくなるため、そうしたインス タンスの影響が緩和される。
クラウドを活用するなどして動的にインスタンスを管理できるようにすると、こういうアプローチも採れるのだなあ。
たとえば HashiCorp の Vault には、レスポンスラッピング(response wrapping)という機能がある。
なるほど〜。
7.7 ランタイムのセキュリティ
たとえば一般的には、実際の政府職員を買収するほうが、職員になろうとしたりするよりも簡単である。
さらっとすごいことを言っている…！
負債を抱えている人には機密情報にアクセスする権限を与えないのが通例である。機密情報にアクセスする権 限が与えられた時点では完全に信用されていたかもしれないが、借金を抱えているとしたら、贈賄にどれくらい抵抗できるだろうか。この場合、彼らは信用できるだろうか。
なるほど……… 社会的信用………。
7.7.1 セキュアコーディングの実践
社内だとチェックリストが自動で投げつけられる仕組みがあるね。
7.7.2 分離
7.7.3 能動的な監視
7.8 まとめ
8章 トラフィックの信頼と信用
8.1 暗号化と認証
8.1.1 暗号化なしで真正性は確保できるか
8.2 信頼の確立：最初のパケット
8.2.1 fwknop
8.3 ネットワークモデルの概要
8.3.1 ネットワークの各層
8.3.2 OSIネットワークモデル
8.3.3 TCP/IPネットワークモデル
8.4 ゼロトラストはネットワークモデルのどこに位置するか
8.4.1 クライアントとサーバーの分離
8.5 プロトコル
8.5.1 IKE/IPsec
8.5.2 相互認証TLS（mTLS）
8.6 フィルタリング
8.6.1 ホストフィルタリング
8.6.2 ブックエンドフィルタリング
8.6.3 中間フィルタリング
8.7 まとめ
9章 ゼロトラストネットワークの実現
9.1 スコープの選択
9.1.1 実際に必要なのは何か
9.2 システム図の作成
9.3 フローを理解する
9.4 コントロールプレーンがないアーキテクチャ
9.4.1 構成管理による「ズル」
9.4.2 アプリケーションの認証と認可
9.4.3 ロードバランサとプロキシの認証
9.4.4 リレーショナルなポリシー
9.4.5 ポリシーの分散
9.5 ポリシーの定義と導入
9.6 ゼロトラストプロキシ
9.7 クライアント側とサーバー側の移行
9.8 ケーススタディの紹介
9.9 ケーススタディ：Google BeyondCorp
9.9.1 BeyondCorpの主要なコンポーネント
9.9.2 GFEの活用と拡張
9.9.3 マルチプラットフォーム認証の課題
9.9.4 BeyondCorpへの移行
9.9.5 教訓
9.9.6 まとめ
9.10 ケーススタディ：PagerDutyのクラウドに依存しないネットワーク
9.10.1 自動化プラットフォームとしての構成管理
9.10.2 動的に設定されるローカルファイアウォール
9.10.3 分散トラフィックの暗号化
9.10.4 分散されたユーザー管理
9.10.5 ロールアウト
9.10.6 プロバイダに依存しないシステムの価値
9.11 まとめ
10章 攻撃者の視点
10.1 なりすまし
10.2 DDoS
10.3 エンドポイントの列挙
10.4 信用されないコンピューティングプラットフォーム
10.5 ソーシャルエンジニアリング
10.6 物理的な脅威
10.7 無効化
10.8 コントロールプレーンのセキュリティ
10.9 まとめ
監訳者あとがき