ゼロトラスト – 質問すべきこと

「ゼロ トラスト戦略」を持つことは、「クラウド戦略」を持つこととよく似ています。何を達成しようとしているのか、現在の状況はどのようなものかというコンテキストがなければ、ほとんど意味がありません。 何かを信頼する必要があるため、名前でさえ誤解を招く可能性があります。 ゼロ トラストの基本的な定義は、「ネットワークの場所に基づいてユーザーまたはデバイスを信頼しない」というものですが、それがそれほど単純なものであれば、私たちはすでにそれを実装し終えているはずです。 F5 のグローバル ソリューション アーキテクトとして、私は多くのアクセス アーキテクチャを目にする機会がありますが、ゼロ トラストの目標を掲げているものが多くある一方で、ゼロ トラストの目標を達成しているものはほとんどありません。

信頼境界の範囲を、ネットワーク境界ではなく、ID、デバイス、アプリケーションを含むように再定義すると、より良い定義が見つかると思われます。 これは確かに新しいアイデアではなく、多くの顧客がこの方向で前進しているのを見てきましたが、ベンダーが、カスタム ソリューションを構築するための独自の開発者部隊がいない環境で実際に機能させるための中核的な課題に取り組んでいるため、現在ではさらに注目を集めています。 プロキシ、マイクロトンネル、マイクロセグメンテーション、プロキシレスなど、さまざまなモデルから選択できることや、マイクロセグメンテーションやソフトウェア定義境界 (SDP) などの競合する用語や関連概念があることも、混乱を招いています。 非常に多くの選択肢がある曖昧なもので成功をどのように定義し、解決策の評価をどこから始めるのでしょうか? まず、自分の目標と要件が何であるかを把握する必要があります。 それで、私は次のような質問から始めたいと思います...

どのような種類のアプリケーションを保護したいですか?

プロキシは、Web アプリケーションの処理、SSO 機能の提供、優れたユーザー エクスペリエンス、比較的簡単な展開と管理に優れている傾向があります。 サーバーアクセスにもゼロトラストを提供することをお考えですか? 一部のソリューションでは、SSH プロキシと RDP プロキシが提供されます。 これら 3 つのプロトコルすべてにおいて、アプリケーション コードまたはサーバー認証モジュールに直接統合されるプロキシレス ソリューションも利用可能ですが、この場合、トラフィックがサーバー/アプリケーションに到達する前に停止することができないため、リスクが増大することに注意してください。

アプリケーション ターゲットにこれを超えるものが含まれる場合は、トンネル ベースのソリューションに拡張する必要がある可能性があります。 すべてのトンネルソリューションが同じように作られているわけではありません。 一部は従来の VPN を活用しており、接続を単一のゲートウェイに制限しています。 マイクロトンネルは、さまざまなエンドポイントへの多数のトンネルを確立できるため、アプリがどこにあってもアクセス要件に対応できるため、より優れたアプローチになる傾向があります。

どのような種類の保護を実施する必要がありますか?

これは、すべてのアプリケーションに多要素認証、何らかの形のクレデンシャル スタッフィングとブルート フォース保護、ボット保護、データ損失防止や侵入防止システムなどのセキュリティ サービスの統合によるトラフィックの可視性、Web アプリ用の Web アプリ ファイアウォールが備わっていることを確認する絶好の機会です。 一貫したアクセス モデルを実装することで、これらすべてのサービスを挿入するための一貫した場所も作成されます。 エンドツーエンドの機密性ソリューションに注目してください。 すべてのセキュリティ サービスをバイパスする必要があることを理解するまでは、魅力的に聞こえます。 ゼロトラストによってセキュリティ体制が弱まることはありません。 ゲートウェイでトンネルを終了し、可視性およびセキュリティ アプライアンスを介してトラフィックをルーティングするのは、優れた戦略です。

シングルサインオン (SSO) が必要ですか?

トンネル ソリューションは通常、アプリケーションに ID を配信することができず、他のシームレスな認証が導入されている環境に依存する場合があります。 必要な SSO を提供するには、プロキシまたは直接的なコード統合が必要になる場合があります。 これを実現することが、多くの利害関係者にとって成功の鍵となる可能性があります。 適切なソリューションを適切に導入することで、セキュリティと同時にユーザー エクスペリエンスを向上させることができます。

あなたの分析戦略は何ですか?

ここでは大きな期待を持つべきです。 組織全体にわたってアクセスに関する一貫したポリシー フレームワークを展開する場合、主な利点は、誰がどのデバイスからどのリソースにいつアクセスしたかを把握できることです。 このデータ収集は、脅威を特定して軽減するために、他のセキュリティ ツールからのデータとともに使用および分析する必要があります。 これは、可視性、脅威の特定、軽減など、あらゆるステップでキルチェーンを強化することにより、組織内のリスクに対処する機会です。 この分野のベンダーはまだ完全なパッケージを提供していないため、サードパーティの分析をソリューションに統合して強化する方法を必ず探してください。 ここでは、すべてを単一のプラットフォームで提供しようとするのではなく、独自のソリューションに加えてパートナー統合に重点を置いているベンダーを探すのがよい戦略です。

どのようなタイプのユーザーエクスペリエンスを期待しますか?

プロキシは、ブラウザでのユーザーの動作を変更する必要がなく、クライアント側で必要なコンポーネントも少なくなるため、Web アプリケーションに優れたユーザー エクスペリエンスを提供する傾向があります。 ただし、他のソリューションではトンネル クライアントが必要になる場合があります。 エンドユーザーがトンネルの存在をまったく、またはほとんどまったく認識していないと予想するのは妥当です。 従来の VPN は、マイクロトンネルに比べてユーザーエクスペリエンスが劣る傾向があり、上記で説明したような他の制限もあります。

どのプラットフォームをサポートする必要がありますか?

一部のソリューションはデスクトップには優れたプラットフォームを提供しますが、モバイル デバイスには提供しません。 必ずソリューションを評価し、主要なデスクトップ OS、モバイル デバイス、ネイティブ モバイル アプリのユーザーのニーズを必要に応じて満たすことができるかどうか、また一貫したユーザー エクスペリエンスと機能セットがあるかどうかを確認してください。

次のステップ

目標を定義します。目標には、まずユーザー エクスペリエンスの向上、セキュリティ サービスの統合の改善、あらゆるものの多要素化、分析統合戦略などが含まれるはずです。 これにより、時間をかけてより深く評価する価値のあるベンダーとアーキテクチャを判断できるようになります。 次に、優れたパートナーシップ戦略を持つベンダーに注目します。 このアーキテクチャに期待されるすべての機能を提供するベンダーは 1 つもありません。そのため、構築できるプラットフォームが必要です。 長い目で見れば、あなたはもっと幸せになるでしょう、私を信じてください！