オライリーのゼロトラストネットワークを読んでみたよ日記。
2020年8月に夏休みの宿題本として買っていたけど、怠けに怠けて2021年1月にようやく読み終えた。
なので今回はそのまとめを書いたよ。
↓読んだのはこの本。
全体通しての感想
もっと概念的なものを説明しているのかなと思ったけど、まあまあ具体的な話をしていたから、システム構築には役に立ちそうな気がした。
でも、結局のところ、"何をどうすればゼロトラストネットワークと呼べるのか"という定義がなく、ベンダごとに異なるので、各ベンダが提供しているゼロトラストネットワークの構築方法や、今回読んだような本をベースラインとして、あくまで、"ゼロトラストっぽい"ようなネットワークを作るしかないねと現状は思った。
例えば、マイクロソフトはO365を利用したゼロトラストネットワークの構築方法が掲載されているよ。
ゼロトラストネットワークは、最近バズワードになっているので、意識高い系の人たちや経営者たちが話題に上げることが多くなっている。
でも、現状はなんちゃってゼロトラストしかできないんだよ、というあたりの話は、どんなに疎まれてもしっかり説明し、理解させる必要がありそう。
ここからは、各章の要約を記載します。
第1章
ここではゼロトラストの概念が記載されている。
これまでは境界ごとにセキュリティを設計していた。
たとえば、エリアごとに高い壁を作る感じ。進撃の巨人みたく。
家で例えるなら外は信用できないエリア、家の中は信用できるエリアと分けて、
その境界は門で閉ざしていた。そこに門番おくとかね。
だけど、これだと門番を突破されたらあとは家の中を自由に仕放題。
たとえば住人に変装した悪いやつが家の鍵を偽装していたとする。
この門番を騙して、偽の鍵を使用されてしまったら、家の中に侵入されて家漁られちゃうよねえ。
それを良しとしないのがゼロトラストモデル。
みーんな悪者よ。という前提のもと考えられたモデル。
ゼロトラストは、平たくいうと家の中でもだーれも信用しないよということ。
家の中だったら、家に入ってしまったらあとは財布とか、通帳とかは普通に
とってこれちゃうけど、ゼロトラストはそんなことはさせない。
財布や通帳のありかは知られても、その代わり、だれが、どうやって、どんな信用度を
持っているかどうかで、財布や通帳をとってよいかを決めることがゼロトラストでは可能になる。
概念的には、コントロールプレーンとデータプレーンの2つで構成されるネットワークになる。
コントロールプレーン
保護されているリソースへのアクセスリクエストを受け付け、
デバイスとユーザを認証、認可し、様々なポリシーを適用することで、
OKと判断されたら、データプレーンにアクセスできる？
データプレーン
コントロールプレーン以外のすべてのもの。
ネットワーク上のトラフィックを管理する。
ユーザがアクセスするところと思ってよいかも？
例えば、データ、サーバ、アプリケーションとか諸々。
ゼロトラストモデルには重要な3要素というものがあるよ。
ユーザ認証、デバイス認証、信用の3つ。
ユーザ認証
これまでと同様で、たとえば門にはいるのに必要なもの。
顔とかね。
デバイス認証
門を開ける鍵が、正当な鍵かどうかを認証する。
これは従来あまりしてこなかったものみたい。
まあ確かに鍵の正当性を見ることって、あんまりないよね。
信用
これはスコアで示される。
クレジットカードの信用みたいなもんかね。
これら３つの要素を組み合わせて、こいつには何をしてもよい権限を与える、何をしたらだめみたいな権限を与える、的な感じ
どこにアクセスするにも、これら３要素からアクセスしてもよいのか悪いのか判断されるようなフィルターを通されるみたいな。
疑問点としては、結局通信、デバイス、ユーザすべてを信用しないとしても、
それを信用するかどうかを決める何者かは必要なわけだよね。
ということは、そいつが悪いやつだったりすると、悪さされる。
単一障害点になりえそうな気がするけども。セキュリティ的に単一障害点って、あまり良くないよな。
ただ、信用できるかどうかを、ビットコインみたく、ブロックチェーン的な感じでみんなで計算しあって
証明書発行したりするんだったらちょっと面白いかもねって、思った。
第2章
信用と信頼の管理
PKIを使って管理しようということを話していたと思う。(ここうろ覚え)
第3章
ネットワークエージェントの話
ネットワークエージェントとは、認可判断の対象になるもの。
エージェントの作成には、様々なデータが利用されることになる。
しかも目まぐるしく変化するよ。
組織にアクセスするときに、会社支給端末からの操作とかならよいけど、個人端末からの操作だと、結構あやしいよね。組織は認証済みのユーザだったら、デバイスはなんでもよい。という状況は求めてない。こういった概念がゼロトラストだと出てくる。
ネットワークエージェントとは、ネットワークリクエストをするエンティティについてわかっているデータの組み合わせを表す用語のこと。
通常は、ユーザ、アプリ、デバイスをデータとして含むらしい。
ちなみに、エージェントは認可判断には使うけど、認証には一切関与しないよ。実際問題、認証はエージェントが形成される前に実施され、ユーザとデバイスに対して別々に実施される。デバイスはx509証明書、ユーザは多要素認証を使ったりとか。ここはこれまでのネットワークと同じっぽいね。
ちなみに標準的なエージェントのデータモデルは現状ない。
SNMPとか、MIBは使えるかもしれんどねー。ということらしい。
第4章
ゼロトラストの認可についての話。
4つの要素を利用して認可を行う。こいつらも概念的な話。
エンフォーサ
データプレーン上にあるもの。
認可の判断をデバイスとか、ユーザとかアプリに適用するやつ。
例えば、具体的にはロードバランサ、プロキシ、FWに実装されたりする。
リクエストを受け付けたロードバランサはそのリクエストが認可されるかどうかを
知る必要があるよね。
そのリクエストをコントロールプレーンに送って、認可判断をまかす。
ポリシーエンジン
コントロールプレーン上にあるもの。
認可可否を判断するやつ。その時に利用するリスク分析はトラストエンジンに任す。
トラストエンジン
コントロールプレーン上にあるもの。各エンティティの信用スコアを計算するやつ。
データストア
コントロールプレーン上にあるもの。認可の判断に使うデータたち。
第5章
デバイスの信頼と信用の話。
まず、デバイスをセキュアに受け取ろうとう話。めっちゃ物理的だな。
受け取り方法は、常に品質が保証されたイメージを使用すべきということ。
へんちくりんなイメージを利用していると、怪しげなソフトウェアとかをインストールされる可能性あり。
そのへんは、セキュアブートという方法で対策できたりする。
セキュアブートは、ファームウェアに公開鍵が読み込まれることで、ドライバやブートローダの署名を検証し、
変に弄くられてないかを確認することができるよ。
デバイスの識別に使用いできる署名された証明書を提供する場合は、秘密鍵を安全な場所に保存する必要がある。
それは、一般にHSM、TPMと呼ばれるところに保存する。ここには、OSもアクセスすることが難しいところらしい。
コントロールプレーンではX509とかTPMとかでデバイスを認証するよ。そして信用は時間とともに失われるので、適宜更新しないといけない。
構成管理システムによって提供される、デバイスの種類とか、ロールとかIPアドレスとか、イメージの経過時間とか、アクセス履歴とか位置とか、通信パターンとかを認証に含めたほうがよさげ。
第6章
ユーザの信頼と信用の話。
アイデンティティには非公式のアイデンティティと正式なアイデンティティがあるよね。
非公式は適当なSNSでのアカウントになる。正式なものだと、現実世界では政府発行の個人IDとか、運転免許証とかね。
デジタルアイデンティティの生成は、人間が関与する確認方式が最も強力というのは、あまり変わっていないらしい。
通常、新しい社員を採用するときは、信頼されるユーザが、採用者を登録するよね。そんな感じ。
以後、ユーザを認証するときは、ユーザの専用ディレクトリLDAPとかを使って組み込むのが良いよ。
そこでは、something you know、something you have、Something you areの要素を
複数利用した多要素認証を利用しよう。
アウトオブバウンド認証つかったり、SSO認証も使うのもよいね。
第7章
アプリケーションの信頼と信用。
サプライチェーンセキュリティみたいに、コード作成の部分から考える必要あり。
ソースコード→ビルド→ディストリビューション→実行
これらのフローすべてがセキュアじゃないといかんよ。
意図的でも、意図的でなくても脆弱性が組み込まれる場合がある。
ソースの保存場所はリポジトリにあるので、そこに最小アクセスの原則で
セキュアにアクセスさせることと、コードが改ざんされてないかを確認する。
GITとかはまさにその例。あと、コードレビューね。
ビルド
ビルドサーバは標的型攻撃を受けやすいらしい。
ビルドサーバって昇格されたアクセス権限を持っていて、
本番環境で実行されるコードを生成されるから。
リスクとしては、以下の通り。
- ビルドしたソースはちゃんと意図したコードか。
- ビルドプロセスは大丈夫か。
- ビルド自体正常で、改ざんされてないか。
ビルドシステムは署名されたコードを読み込んで署名された出力を生成するけど、
ビルドそのものは暗号化されないんだって。以下の点に注意しよう。
- 入力を信用するように、署名されたものを入力させること。
- ビルドの冪等性を確保し、誰がビルドしても同じバイナリが生成されること。
- リリースバージョンと成果物バージョンを切り離すこと。
バージョンとビルドIDを管理すること。
改ざんされないように、ハッシュ化と署名をすること。
ディストリビューションのネットワークが不正なものじゃないか確認すること。
あと、全体通して、極力人間が関わる部分を限定させたほうがよいよ。
アプリケーションは、バージョンとビルドIDをちゃんと管理された状態で適切にアップデートさせること、何らかのシークレットを利用して認可を受けたアプリを利用すること。
また、ランタイムも注意しよう。人も含む。アプリをハックするより人を買収したほうが早かったりするよ。
アプリケーションは、アクセスできるリソースをアプリごとに制限しよう。
そうすると、変に攻撃されても、侵害される範囲を制限できるよ。
SELinuxとか、仮想化とかね。
加えて、アプリの挙動も監視しような。
第8章
トラフィックの信頼と信用
ゼロトラストでのトラフィックは、当然暗号化は必要だけど、もう一つ、完全性を確保しておかないといけないよ。
最初のパケットの信頼の確立はファーストパケットと呼ばれる。
これは事前認証と呼ばれる手法で解決できるらしい。SPAというもの。
事前認可鍵を持っているパケットは署名されたパケットを送信できるようになる。
この実装はfwknopを利用されるらしい。
あとは暗号化しようね。
ちなみに、ゼロトラストはOSI参照モデルでいうとでどこに位置するのかという話があった。
ゼロトラストの暗号化によく使われるのは、TLSとIPSEC。
ゼロトラストは全てセキュアしようというのが基本的な考えなので、より下位にある
IPSECのほうがうってつけとされる。
ただ、IPSECってまだあまり普及しきってない。
レガシーに比べて比較的あたらしいプロトコルだから、機器が対応してなかったりするとかなんとか。
そうなん？ここあまりピンとこなかったけど。
なので、クライアントとサーバのやり取りはmTLS、サーバ間のやり取りはIPSECかなってこの本では言ってる。
あとはフィルタリングしようや。
第9章
ここまでは、概要に加えて信用と信頼の話をしてきた。
この賞ではゼロトラストをどう構築していくかという話をする。
ゼロトラは最初から満たさなきゃいけない要件のリストじゃなくて、それらを目標として取り組んでいくもんやで。
この筆者の見解としては、以下にまず取り組むことが大事とされる。
- ネットワークフローはすべて処理される前に認証されなければならない (MUST)。
- ネットワークフローはすべて送信される前に暗号化されるべきである (SHOULD)。
- 認証と暗号化はネットワーク内のエンドポイントで実行されなければならない(MUST)。
- システムがアクセス制御を実行できるようにするために、ネットワークフローはすべて列挙されなければならない(MUST)。
- ネットワーク内では最も強力な認証 / 暗号化スイートを使用すべきである (SHOULD)。
- 認証にパブリック PKI プロバイダを使用すべきではなく(SHOULD NOT)、 代わりにプライベート PKI を使用すべきである。
- デバイスのスキャン、パッチ、ローテーションは定期的に実行すべきである (SHOULD)。
次にシステム図を作ろう。
その後にネットワークフローをとりましょう。全てのパケットをみるような感じ？かなり大規模になるけど。
構築当初は、最初のうちはコントロールプレーンがないアーキテクチャがある。その場合どうするか。
構成管理ツールを使ってズルするといった方法がある。
- 構成管理ツールを使うことで、システム対する変更を一貫した方法で適用できる。
- 構成データをバージョン管理システムに保存すると、変更とその理由がわかる。
- 構成管理システムによって設定ズレが起きない。といったメリットがある。
アプリケーションの認証と認可をしよう。
アプリごとに認証システムを実装するよりは、認証と認可を一元的に提供しとく。SAMLとか、openIDとかね。
ロードバランサとプロキシの認証をしよう。
ロードバランサとプロキシでユーザとデバイスの認証・認可をすることができるよ。
リレーショナルなポリシーを作ろう
2つのデバイス間の通信がFWといった従来のシステムで構成されていた場合、
これらのFWに設定されたポリシーを使ってリレーショナルなポリシーを運用させる感じかね？
ポリシーの分散をしよう。
これも、構成管理システムを使って代替できなくはない。
リレーショナルなポリシーに基づいてソフトウェアFWを設定すれば、
ホストごとのエンフォースメントを作れるし、通信もmTLSを使ってやればよい。
そしてポリシーの導入しましょうね。
次にゼロトラストプロキシを導入しよう。
具体的にアプリケーションプロキシのこと。認証、認可、暗号化を処理するためのもの。
こいつらは、リバースプロキシとフォワードプロキシで稼働させることができる。
どちらか一方の場合もあれば、両方使う場合もある。
第10章
ゼロトラストに対する攻撃者の視点を解説する章
なりすまし
クレデンシャルが盗まれるとやばいよ。
ゼロトラストでは、デバイス、ユーザでそれぞれ認証されるから、
従来よりは安全だけどさ。多層防御的になってるからかな？
DDoS
DDoSは従来から継続的に脅威になるよ。
オンラインのDDoSサービスは使ったりしたほうがよいよね。
エンドポイントの列挙
ゼロトラストでは、機密性は保証されるけど、プライバシーは未保証。
サイト間トンネルを使ってトラフィックを隠蔽することは、ゼロトラストでも可能らしい。
ちょっとようわからん。
コンピューティングプラットフォーム
信用されていないコンピューティングプラットフォーム使うとやばいよ。
コンピュータも永続データのメモリとか暗号化したほうがよさげ？
これも従来から引き続き注意してね。
物理的な脅威
脅迫とかね。あとUSBデバイス差し込まれたりとか。
無効化
実行中のセッションが数日間確立されたままだとあれだから、適宜無効化したりとか？
コントロールプレーンのセキュリティ
ここは俺もおもったわ。ここが侵害されると終わりだよね。
基本は限定的なネットワーク接続と厳密なアクセス制御から。
あと、コントロールプレーンをシステム管理の観点から分離させる。
専用のアカウントで管理されるか、より厳重なアクセス制御が適用される
データセンタの一部で動作させるとかね。
