Zero Trust、VPN、TLS検査はそれぞれ別の役割を担う

調達文書はゼロトラスト、VPN、TLS検査を同じ買い物であるかのように扱いますが、それぞれが他の二つには答えられない問いに答えます。トンネルは保護された経路を作り、検査ゲートウェイは終端できるトラフィックを読み、ポリシーは名前の付いた主体が名前の付いたリソースに対して名前の付いた操作を行えるかを決めます。そのうち認可の判断であるのは最後の一つだけです。製品が最初の二つを完璧にこなしても、本当の問いは開いたままになります。

三つの仕組み、三つの問い

トンネルはトラフィックがどうネットワークに届くかに答えます。検査ゲートウェイは、TLSを終端する権限がある場所で中間装置が何を見て何を行えるかに答えます。ポリシーエンジンは、誰がどのリソースに何を行えるかに答え、そのうえでその答えを適用できる執行点を必要とします。NISTのゼロトラストアーキテクチャはリソースを中心に置き、パケットがどこから来たかから信頼を推し量ることを拒みます。

この枠組みはラベルより満たすのが難しく、レビューで偽装するのはさらに困難です。また、どの製品が配備されているかという問いを、どの判断が何によって執行されるかという問いへ移します。

判断が実際に適用される場所

一つの要求を考えます。サポートエンジニアがサービスコンソールを開き、同じスイッチにつながれた個人の端末が、近くにあるというだけでその権限を引き継いではなりません。許可される操作、端末の条件、それらを執行する構成要素を書き出し、配置がすべてを決めることを忘れないでください。アプリケーションゲートウェイ、サービスプロキシ、ホスト制御、あるいは組織が実際に支えられる別の境界であり、その構成要素が何であれ、遠隔からの試行と現地からの試行の両方の経路上に置かれなければなりません。

VPNの入口を決して通らないトラフィックは、そこで行われる検査がどれほど徹底していても、その検査には統治されません。この一つの隙間が、ゼロトラストの図と実際に動く配備との間の距離の大部分を説明します。アーキテクチャを描く前に、要求の経路を描いてください。

復号は認可ではない

傍受は狭い検査目的に奉仕し、証明書、信頼されたルート、プライバシー審査、そしてその下で壊れるアプリケーションという独自の負担を伴います。そのどれもがゼロトラストの意味ではなく、そのどれもがポリシーの判断の代わりにはなりません。一つのパケットも復号せずに人を認証しサービスを認可することは完全に可能です。復号されたフローは、その中で運ばれる操作を利用者が正当に持っていたかについては何も語りません。

ポリシーが必要とする証拠は一種類であり、復号はそれではありません。端末の健全性は、身元、リソースの機密度、文脈と並ぶ一つの入力であり、一度通したからといってその端末にネットワークの残りを渡すことにはなりません。両者を混ぜると、認可の問いが証明書のプロジェクトに変わります。

ゲートウェイが経路上にどこにもない場合

遠隔ゲートウェイに触れずに移動するものとは、ローカルセグメント上の端末間の通信、あるワークロードから別のワークロードへの呼び出し、クラウドアカウント内で直接到達されるエンドポイントです。経路ごとに、今日実際に配備できる執行方法を挙げてください。エージェントを載せられない機器には、明示的に支援される別の制御が依然として必要であり、エージェントが後から来るという前提は今何も閉じません。サービス間のアクセスは通常、別のオーバーレイネットワークよりも、ワークロードの身元とリソースに対して書かれた検査によく合います。

設計は図ではなく、どの操作が許可され、どれが拒否され、それぞれの答えがどこで執行されるかという振る舞いで受け入れてください。具体的に許可・拒否する操作を承認し、ゲートウェイに決して届かないローカルの経路を一つ含めてください。ポリシーの所有者が誰か、どう変わるか、失効がどう働くかを記録します。

名前を貼り替えたトンネルはやはりトンネルです。ポリシーが決め、何かがそれを執行しなければなりません。