ゼロトラストネットワーク
2.1.1 攻撃者のランク(低いものから)
スクリプトキディ
標的型攻撃者
インサイダー脅威
内部犯行 権限レベルは普通。
信頼されたインサイダー
特権を持った内部犯
国家レベルの攻撃者
2.1.2 RFC3552 インターネットの脅威モデルの定義
通信路は全く安全でないと仮定する。
通信相手は安全であるという仮定を普通は置く。
ゼロトラストネットワークが対処できるのは、「信頼されたインサイダー」まで。
しかし普通はそれで十分。
X509
ローテーションも大事。
「多くの場合、ローテーションの頻度は、ローテーションのコストに反比例する」
2.3.3 priv PKI vs pub PKI
前者が良い。
CAの信頼性、コスト、自動化
しかし無いよりは断然マシ。
2.4 最小権限の原則
"sudo" モード
2.6 コントロールプレーンとデータプレーン
カーネル空間とユーザ空間のようなもの。
...
6.6.1 シャミアの秘密分散法
8.2 SPA single packet authorization
fwknop
8.5.2 mTLS
曲線に注意
業界屈指の頭脳を持つ人々の中には、こうした(楕円曲線の)定数が国家レベルのアクターに解読されていて、安全性に問題があると考えている人がいる。
これすき
このような理由によりECDHのほうが計算量やパフォーマンスの面で優れているにも関わらず、一部の専門家はECDHよりDHEを推奨している。
9.1.1 ゼロトラストネットワークをやっていくにあたって必要なこと
ネットワークフローは全て処理される前に認証されなければならない(MUST)。
これができないと、それはネットワークを信用しているということである。
ネットワークフローは全て送信される前に暗号化 されるべき(SHOULD)である。
ネットワーク層を信頼するな。「本書の重要な教訓」とある。
認証と暗号化はネットワークのエンドポイントで実行されねばらない(MUST)。
ネットワーク層を信頼するな。
VPNとかを使っても、口を結局信頼するということになる。
ゼロトラストを名乗るにはE2Eである必要が結局ある。
システムがアクセス制御できるために、ネットワークフローは列挙されねばならない(MUST)。
ネットワークの期待される挙動を定義しないと不信な行動を定義できない。
列挙されたDBが自由に弄れるようになっていたら、内部犯にやられる。
最も強力な認証/暗号化スイートを使うべき(SHOULD)である。
ネットワークは敵である。
認証にパブリップPKIを使うべきではなく(SHOULD NOT)、priv PKIを使うべきである。
CAは信頼できるか？
CAが信頼できたとして、国家レベルのアクターに強制されることもある。
privならそもそもそういうことは起きない。
デバイスのスキャン、パッチ、ローテーションは定期的に行うべきである(SHOULD)。
エンドデバイスの信頼は根幹である。
アンチウイルスソフトウェアは完璧ではない。
デバイスのセキュリティが破られるリスクは時間とともに増加する。つまりデバイスの信頼性は時間とともに低下する。
デバイスのイメージを定期的に再生成してきれいな環境にすると信頼性が保たれる。
サーバは四半期ごと、パーソナルデバイスは2年ごとが目標となる。
ヤバ
9.2 システム図の作成
これは重要な一歩である。
今更か？
9.3 フローの理解
ネットワークフローとは、src systemとtgt sytem巻の期限付き通信のこと。
TCP等を使っている場合、「1つのフロー」と「やりとり全体」が対応付きうる。
一方UDP等単方向の時は通信の半分しか表現していないこともある。
フローはIPアドレスレベルとかでやるべきではなくて、論理レベルでやっていくべき。
全てのネットワーク接続をキャプチャするのは大変。
ゼロトラストへ行くのは大変か？
そんなことはない！ 一歩づつやっていきましょう。
ゼロトラストな領域を旧モデルでの「ゾーン」ごとにやっていけばよい。
9.4 コントロールプレーンが無いアーキテクチャ
普通は無いわ。
9.4.2 アプリケーションの認証/認可
ゼロトラストではsrc/dstで信頼はしないことにしているので、全てのサービスが認証/認可する必要がある。
アプリケーション毎にユーザー名、パスワードを格納していったりしたら爆発する。
中心に認証と認可を一元的に管理する君を置くのが良い。SAMLとか。OpenID Connectとか。
とは言っても、アプリケーションに認証の責務を終わせてはならない というわけではない。
一方、認可はアプリケーション毎に行なわれるのが正しい。
9.4.3 LBとproxyの認証
ぴ
9.4.4 コントロールプレーンが無いとき
動的なものをあきらめる。
リレーショナルなポリシー
2つのデバイス間の通信がFWを通して制御され、TLSを話す。
9.4.5 ポリシーの分散
コントロールプレーンは無いので、構成管理ツールでがんばる。
9.6 ゼロトラストプロキシ
2つのモードのプロキシ
リバースプロキシ
接続相手を認証して許可すべきかを考えてから転送する。
フォワードプロキシ
ゼロトラストでないコンポーネントからゼロトラストなコンポーネントへの通信を可能とする君。
10章 攻撃者の視点
10.1 なりすまし
10.2 DDoS
10.3 エンドポイントの列挙
これはつまり、誰がどこにアクセスしているかはネットワーク層からわかるということ？
ゼロトラストによって機密性は保たれるが、プライバシーは保たれない。
10.4 信頼されないコンピュータ
これに対策するのは難しい。
弱い乱数を産むhwが仕込まれていたりしたらつらい。
10.5 ソーシャルエンジニアリング
エンドユーザのトレーニング
はい
シャミアの秘密分散
一人が騙されても大丈夫
ただし日常的に使うものには使いづらいから必殺技にだけしか使えない。
10.6 物理的な脅威
国境検問による政府の強制力
現実的にはこれには勝てない。
情報の保護のために身体の危機を選ぶべきではない。
物理的な脅威がアクセスできるものは機密性の低いものだけになるように限定する方向性で戦う。
グループ認証が脅威の低減に役立つ。
ラップトップに変なUSBデバイスを挿されるとかの脅威は、デバイスとクレデンシャルのローテーションで対処する。
ローテーションされないデバイスのスキャンもまぁ役立つ。
10.7 無効化
クレデンシャルが無効になってもTCPセッションが残ってるようなものは許せるか？ おそらく許せないだろう。
細かな認可
定期的なリセット(ライフタイム)
エンフォーサによる追跡 これは大変。
10.8 コントロールプレーンのセキュリティ
これが破られるとなんでもできる。
誰にも気づかれずにこれの変更ができたりすべきではない。
変更があるとみんなが知るように。
厳格な認証/認可
グループ認証/認可
システムの分離
境界モデルに戻ってしまうといけない。
これでは何をやっているかわからない。