Chapter 4 Making Authorization Decisions
みなさんこんにちは、こんばんは、おはようございます。
前回に引き続き、教科書はこちら
今回はゼロトラストネットワークの第4章「認可の判断」に関する内容です。
どんな内容となっているのか、一緒に学んでいきましょう！
認可の判断
いかなるネットワークも信頼しない「ゼロトラストネットワーク」においては、どのユーザー/デバイスからどのリソースを使わせるのかという「認可の判断」がもっとも重要なプロセスであり、ゼロトラストモデルを実現するにあたって必要不可欠なパーツとなります。
本章では、適切な「認可の判断」を下すには、以下4つに分類された機能が必要とされています。
- エンフォーサ
- ポリシーエンジン
- トラストエンジン
- データストア
全体の概要構成イメージは以下のようになりますので、まずは頭に入れておきましょう。
ここからは、これら4つの論理的な機能がどういったもので、どのように連携していくのかをひとつひとつ確認していきます。
エンフォーサ
エンフォーサは、認可を構成する4つの機能の中では唯一、データプレーンに存在する必要がある機能であり、ネットワークフローに直接的に関与します。
具体的には、その他の機能（ポリシーエンジン、トラストエンジン、データストア）によって判断された「認可の結果」をネットワークフローに対して適用する責務を持つ機能です。
実際に通信を制御する必要があるため、ロードバランサーやファイアウォール、プロキシ等、ネットワーク上の中間者として機能する機器を使って実装することになります。
ただし、エンドポイントとエンフォーサの距離が遠くなればなるほど、直接的に制御できない通信が増えてしまいます。
これは、ゼロトラストを弱体化させることに繋がりかねないため、エンドポイント（ユーザーが利用する端末など）にできるだけ近いところへエンフォーサを配置することが望ましいとされています。
ポリシーエンジン
ポリシーエンジンは、認可を行うための「定義されたポリシー（ルール）」に基づき、判断を下す機能です。
判断のためには事前定義されたポリシーとトラストエンジンで計算されたスコアを用います。
エンフォーサとは異なり、ネットワークフローに直接は関与しないため、データプレーンに存在する必要はありません。
ポリシーエンジンは、ポリシーに適合することで得た「認可の結果」をエンフォーサにわたすことが責務となります。
ポリシーエンジンの構成
ポリシーエンジンは、認可の判断を下す重要なシステムです。
そのため、本書においては、ポリシーエンジンは他の機能から物理的に独立していることが望ましいとされ、さらに、適用するルールである「ポリシー」と判断を下す「ポリシーエンジン」を別の場所に格納すべきとされています。
具体的には、ポリシーはポリシーストレージに格納されるべきであり、バージョン管理システムによって管理されるべきとされています。
ポリシーエンジンとポリシーストレージ（バージョン管理システム）を分離することで、
① ポリシーの変更履歴を記録できる
② ポリシーの変更経緯をトレースできる
③ ポリシーの期待される動作をテストできる
というメリットがあります。
また、実際のポリシー運用時には（とくに成熟した組織では）ポリシーを扱うチームは複数に分断されることが想定されるため、
④ 定義されたポリシーを複数の人/チームがレビューできる
という点も副次的なメリットです。
ポリシーの扱い
ゼロトラストネットワークでは、「現在の状態」に基づいてポリシーを適用する必要があるため、従来のIPアドレスベースのポリシーではなく、論理コンポーネントをベースとしたポリシーを定義する必要があります。結果として、従来では制御できなかったリスクを低減できるようになります。
| 従来型のネットワーク制御 | ゼロトラストモデルのネットワーク制御 | |
| 制御単位 | ネットワーク情報 ・IPアドレス ・IPアドレスレンジ | ネットワークに存在する論理コンポーネント ・ネットワークサービス ・デバイスエンドポイントクラス ・ユーザーロール |
| 制御に必要な情報 | ネットワーク情報 ・IPアドレス ・IPアドレスレンジ | ネットワークエージェント情報 ・ネットワークエージェントの信用スコア ・ネットワークエージェントを構成するデータ（静的データやユーザーやデバイスの信用スコアに代表される動的データを含む） |
ゼロトラストネットワークでは、ポリシー制御をきめ細かく行うことが望まれますが、細かくポリシー制御をおこなうには大変な労力がかかるため、先に述べた複数のチームに分割して管理する運用が効果的です。
また、ポリシーエンジンは実際に認可の判断を下す重要なシステムなので、定義するポリシーの内容は慎重に精査されるべきです。
この観点からも、バージョン管理システムを活用し、複数の人/チームがポリシーをレビューする運用が効果的といえます。
トラストエンジン
トラストエンジンは、データストアに格納されたさまざまな情報を参照し、信用スコアを計算（リスク分析）することが責務です。
信用スコア
計算された信用スコアをもとに、ポリシーエンジンが認可の判断を下します。
信用スコアを計算する対象は、「ネットワークエージェント」と「ネットワークエージェントを構成するエンティティ」の双方です。
これは、たとえば悪意のある第三者が正規のデバイスを使って攻撃を仕掛けてきた場合に、攻撃を仕掛けているという振る舞いに基づいてネットワークエージェントのスコアを低下させるかもしれません。
たしかに、悪意のある第三者から受け取ったネットワークエージェントのスコアを低下させることは有効です。
しかし、異常な振る舞いという観点では、攻撃されている側のユーザーについてもネットワークエージェントのスコアが低下するかもしれません。
これは、求めている結果ではありません。本来は悪意のある第三者のデバイスのスコアを低下させるべきです。
複数のスコアを用いた計算は複雑度が高いものの、ゼロトラストネットワークを理想形に近づけるためには「ネットワークエージェント」と「ネットワークエージェントを構成するエンティティ」の双方のスコアが適切に計算されることが望まれます。
スコアの計算
スコアの計算には静的なルールと機械学習モデルによって生成されるスコア関数が用いられます。
たとえば、静的なルールに使われる情報には以下のようなものがあります。
- デバイスのチェックが最後に行われた日時
- 特定のハードウェアセキュリティ機能の有無
- 最新のソフトウェアパッチが適用されているか
- 認証を繰り返し失敗しているユーザーがいないか
機械学習モデルでは、訓練データと呼ばれるアクティビティーデータの一部を使用して客観的な事実を作り出します。
- 訓練データ（生の観測データ）から特徴量を割り出す
- 特徴量からモデルと呼ばれるスコア関数を生成する
- 訓練データと同種のデータにスコア関数を使用し、スコアを得る
このようにして得たスコアを、静的なルールの結果と比較することで、品質の改善や未知のリクエストの危険度の予測に役立てられます。
データストア
データストアは、現在の状態を格納する「インベントリ」と過去の状態を格納する「履歴」に分けられます。
インベントリは、ユーザーデータやデバイスデータなど、検査対象となるリソースの状態を記録しておくことが目的で使用されます。
履歴は、過去の状態を記録しておき、必要に応じて参照することで、リスク分析を行う目的で使用されます。
信頼できるデータソースは、真実を語る情報源となり、トラストエンジンもポリシーエンジンもデータストアに格納されている情報をもとにすべての判断を行います。
すなわち、大変に重要な情報をもつシステムであり、データストアの信頼性に対してコストを投じることは自然な流れといえます。
まとめ
第4章では、認可を判断するために必要なコンポーネントについて学びました。
認可の判断と判断結果による通信制御は、以下の流れで行われることがわかりました。
- データストアに格納された情報をもとに、トラストエンジンがスコアを計算
- ポリシーエンジンはデータストアに格納された静的な情報とトラストエンジンの計算結果（と場合によってはポリシーストレージに格納されたポリシー定義）を参照することで、認可の判断を下す
- ポリシーエンジンから受け取った認可の判断結果をもとに、エンフォーサが実際のネットワークフローを制御する
同時に、ゼロトラストネットワークにとって認可の仕組みはキモであり、ここの理解なくしてゼロトラストネットワークの理解はできないこともわかりました。
今回はここまでとなります。
次回は第5章：Trusting Devices です。
ここまで見てくださり、ありがとうございました。
それではまた次回。
