Zscaler Zero Trust Exchangeによるマルチクラウド環境におけるワークロードの保護

多くの企業にとって、クラウドが新しいデータセンタになり、マルチクラウド環境が当たり前になりつつます。クラウドワークロードが他のクラウドワークロードやインターネットに安全に通信できるようにする必要がありますが、クラウド対クラウドやクラウド対インターネットの安全な接続をファイアウォールやVPNを使用して構築し、企業のWANをクラウドにまで拡張するために利用できるオプションは、セキュリティリスク、運用の複雑さ、パフォーマンスなどの課題を生み出します。

企業のWANのクラウドへの拡張にあたっての課題

従来は、2つの異なる環境がルータを使用して接続され、これらのルータを使用してVPNやIPSecのトンネルをターミネーションし、ルートを交換するため、それぞれの環境が他の環境のすべてのIPアドレスにアクセスできます。これらの環境間のアクセスをコントロールするため、ファイアウォールを使用して静的なアクセスコントロールを可能にすることで、ある環境の特定のIPのみが他の環境の特定のIPにアクセスできるようにします。これは、ほとんどの企業が採用することになっていた、従来型のIPとファイアウォールのアプローチです。

 

IPとファイアウォールのアプローチでは、フラットなIPフルメッシュ接続によってネットワークが脅威の水平移動の影響を受ける可能性が高いため、セキュリティリスクを生み出すことになります。

このアプローチには、クラウドの持続時間が短いワークロードの運用が複雑になるという問題もあります。IPが行き来するたびに、新しいIPをすべてルータが伝達する必要があります。新しいすべてのIPをファイアウォールにプログラミングする必要があり、これらのIPに重複がある場合、これらのネットワークに接続する前に解決しなければなりません。

最後に、このアプローチには、ルートのスケーラビリティ、スループットのボトルネック、高いレイテンシなどのスケーラビリティやパフォーマンスの課題があります。

これらの課題は、より多くのアプリケーションが複数のクラウドに分散し、コンテナ、PaaS、サーバレスなどのクラウドネイティブサービスが採用されると、さらに困難なものになります。

従来のアプローチでは、インターネットや他のクラウドのワークロードに接続されたすべてのトラフィックが中央のハブを経由することになり、このハブにはファイアウォール、Squidプロキシ、ルータなどが置かれ、データセンタの「城を堀で囲む」アーキテクチャのようになります。具体的には、次のような制限があります。

 

 

1. 限定的なセキュリティポスチャ：

完全なセキュリティポスチャという点では、スケーラブルなSSLインスペクションを仮想ファイアウォールでは実現できないため、プロキシやデータ保護などの機能を追加する必要があり、Squidプロキシやサンドボックスなどの仮想アプライアンスが追加されることになります。

2. フルメッシュネットワークによるリスク：

従来型のIPアーキテクチャでワークロード通信をマルチクラウド環境で可能にするには、異なる環境にルートが分散され、IPやサブネットの情報を共有するため、フラットなネットワークと静的なファイアウォールルールが作成され、脅威の水平移動が容易になります。

3. アプライアンスのパフォーマンスの制限：

最も弱いリンクによってスループット（この場合はファイアウォールの規模とパフォーマンス）が制限されます。コンテンツのSSLインスペクションなどのセキュリティサービスをファイアウォールで有効にすると、パフォーマンスが低下します。

4. オーケストレーションや管理のオーバーヘッド：

従来のファイアウォールでは、オーケストレーション、ポリシー、オペレーション、ライセンス管理に追加のVMが必要であるため、複雑さとコストがさらに増大します。これをクラウドプロバイダごとに複製することになれば、複数のクラウドの運用がさらに困難になります。

5. 送信先への複数のホップに起因する死角：

従来のIPベースのアプローチでは、ファイアウォール、SD-WANルータ、NACL、セキュリティグループなどの複数のツールが必要です。それぞれに専用のログが必要で、ログの相関付けが正しくないために、ネットワーキングやセキュリティのチームにとって、さらなる死角が生まれます。

ゼロトラストのクラウドワークロードへの拡張

幸いにもここ数年で、従業員のアクセスに関する企業のWANにこのような課題があることが明らかになりました。IPとファイアウォールによるアプローチのセキュリティとパフォーマンスの欠点を克服するため、ゼロトラスト戦略を採用する企業が増加しています。クラウドワークロードに固有のニーズに合わせて再構築されたゼロトラストの原則ことが、マルチクラウドネットワーキングの前進させる方法です。

ゼロトラストでは、ネットワークが信頼（トラスト）されないため、IPやルーティング情報が交換されることはありません。アイデンティティとコンテクストに基づき、きめ細かいレベルでワークロードへの接続が有効になるため、ファイアウォールルールを作成して環境間のIPアクセスを制限する必要はありません。

 

Zscaler Internet Access (ZIA)とZscaler Private Access (ZPA)は、インターネットやプライベートアプリケーションへのエンドユーザによるアクセスを保護する市場のリーダーです。Zscalerのワークロード通信は、Cloud Connectorによって実現され、これらのソリューションの拡張により、インターネットへのワークロードアクセスの保護が可能になり（ZIAによるワークロードの保護）、リモートプライベートワークロードへのプライベートアクセスの保護が可能になります（ZPAによるワークロードの保護）。この画期的な新しいアプローチは、セキュリティの強化、運用の複雑さの軽減、アプリケーションパフォーマンスの向上を同時に実現します。

 

ユースケース1：ワークロード対インターネット通信のゼロトラストの実現

Cloud ConnectorがワークロードをZscalerのクラウドにダイレクト接続することで、インターネットアクセスが可能になります。SSLプロキシ、データ保護、高度な脅威からの保護などのすべてのセキュリティサービスが、Zero Trust Exchangeでネイティブに実行されます。このアーキテクチャでは、どのクラウドからであっても、インターネットにアクセスするすべてのワークロードに同じセキュリティポリシーを適用できます。この点は、すべてのクラウドにファイアウォールとSquidプロキシで構成される城を堀で囲むアーキテクチャを構築する必要がある従来型のアーキテクチャとは大きく異なります。

 

ユースケース2：マルチクラウド環境におけるワークロード間通信のゼロトラストの実現

クラウドコネクタにより、ワークロードからZscalerのクラウドへのダイレクト接続が可能になります。任意のクラウド（AWS、Azure、データセンタ）のワークロードが、Zero Trust Exchange経由で相互に通信できます。Zero Trust Exchangeが、アイデンティティとコンテキストを使用してトラストを検証し、接続を確立します。この方法は、クラウド環境間でのIPルーティングが必要になる従来型のアーキテクチャと大きく異なります。

 

ユースケース3：VPC/VNET内のワークロード間通信のゼロトラストの実現

Zscaler Workload Segmentationでは、仮想マシン内の個々のアプリケーションやプロセスのレベルまでの細いセグメンテーションが可能です。ワークロードセグメンテーションエージェントがプロセスレベルでフィンガープリントを生成することで、ソフトウェアのアイデンティティを提供します。自動化された機械学習が、特定のプロセスやアプリケーションへの利用可能なすべてのパスを発見し、許可されたパスに関する推奨を導き出すことで、脅威の水平移動のリスクが高くなる不要なパスをすべて排除します。この点は、静的なACL（アクセスコントロールリスト）やSG（セキュリティグループ）を使用し、既存のルールへのピギーバックにより攻撃者が容易に侵入できる、従来型のアーキテクチャと大きく異なります。

ゼロトラストでIPやファイアウォールの制限を解決する方法

 

 

従来型のアーキテクチャの調査で、IP接続という共通する問題が存在することがわかりました。ネットワークとセキュリティは従来、別々の機能として考えられ、接続（IPルーティング）が最初に有効になった後に、セキュリティ（ファイアウォールフィルタリング）がその上位で有効になります。両者を単一アプライアンスに統合しているベンダもありますが、アプローチやアーキテクチャはその場合も同じです。

Zscaler Zero Trust Exchangeは、セキュリティが先で、接続が後という、他とは異なる独自のアプローチを採用しています。後でブロックする必要がある不要な接続を先に作成する理由があるのでしょうか？

ZscalerのZero Trustアプローチでは、誰も信用することなく、送信先のアプリケーションではなく、Zero Trust Exchangeが、送信元の唯一のデフォルト接続となります。すべてのワークロードのトラフィックがCloud Connectorに転送され、ワークロードがZero Trust Exchangeに接続されます。

Zero Trust Exchangeでは、以下のステップを経た後に、送信元と送信先が接続されます。