Zscaler Web Secure Gatewayの監視

による投稿 2018年7月28日
2018年8月1日

ブランチオフィスからSaaSやIaaSへのダイレクトインターネットアクセス(DIA)への移行により、集中型ファイアウォールから分散型の「クラウド型Webセキュアゲートウェイ」への移行が始まっています。これらのセキュリティ・プロキシサービスには、URLフィルタリング、高度な脅威防御、マルウェアとウイルス対策、およびアプリケーション制御などの機能が含まれます。

ただし、このモデルは、クラウドセキュリティノードに到達するまでのネットワークにインターネットを経由するため、IT管理者やネットワーク管理者にとってそこに1つの大きな見えない世界が存在します。SNMPやフロー系のパッシブモニタリングを使用する従来のネットワーク監視ツールでは、自社が管理していない通信機器からデータを収集することができないため、インターネットを経由した監視が困難です。

ThousandEyesは、独自のアクティブモニタリング技術によりネットワークを監視し、ブランチのユーザーとSaaSあるいはIaaSサーバー間だけでなく、その間にあるすべてのSWG(セキュアWebゲートウェイ)プロバイダーも含めたホップバイホップのネットワーク可視化を実現します。ここでは、ThousandEyesが、クラウドセキュリティプロキシを導入されたお客様のネットワークをどのように監視しているかご紹介いたします。今回はZscalerを例にした説明ですが、ImpervaやCisco Cloud Web Security(CWS)などの他のクラウドセキュリティプロキシソリューションにも当てはまります。

IaaSとモジュール型アプリケーションアーキテクチャーの急速な普及により、企業が自社で所有または管理していないインフラとネットワークにまたがる複雑なサービス間通信が増加しています。さらに、このコミュニケーションの多くは、企業のミッションクリティカルな通信にまで進化したインターネットを利用しています。これらの複雑な環境は、慎重に管理されなければコストを押し上げる可能性があります。さらに、エンドツーエンドの可視化と監視は、顧客や社員に優れたデジタルエクスペリエンスを提供する上でとても重要です。

Zscalerのサービスアーキテクチャ

Zscalerプラットフォームは、プロキシが持つ標準的なコンポーネントを機能的に分散して巨大なグローバルサービスネットワークを構築し、スケーラブルなマルチテナントプラットフォームを提供するクラウド型ソリューションです。Zscalerには複数のアクセスタイプがありますが、通常は支社に設置されたインターネットルーターまたはファイアウォールからGREトンネル経由で最も近いZscaler Enforcement Node(ZEN)にトラフィックを送信します。 ZENのユーザートラフィックは、ユーザーレベルの粒度でセキュリティポリシー(URLフィルタリング、高度な脅威防御、マルウェア保護、アプリケーション制御など)を実施するインライン・プロキシによって検査されます。各ZENは、インターネットを介してSaaSプロバイダにトラフィックを送信します。

図1:Zscalerのサービスアーキテクチャ
図1:Zscalerのサービスアーキテクチャ

このようなクラウドSWG利用時には、クラウドサービスへのアクセスのエンドユーザーエクスペリエンスは、下記にあげた様々なプロバイダのパフォーマンスと可用性によって大きく変化します。

  1. ブランチオフィス側に接続を提供しているローカルISP。
    (グローバル企業の場合、地域または国により、異なる複数のプロバイダの場合があります)
  2. クラウド型セキュリティプロバイダへ接続する中継ISP
  3. クラウド型セキュリティプロバイダ
  4. セキュリティプロバイダからSaaSおよびIaaSプロバイダへの中継ISP
  5. SaaS、IaaSプロバイダー

パフォーマンス問題の分析例

ThousandEyesがどのようにZscalerのパフォーマンス問題の根本原因を迅速に特定し、問題解決に至ったかを、実際のイベントを例に見てみましょう。午前8時ごろ、Salesforceへのアクセスが遅いとユーザーからクレームの電話がありました。 幸いなことに、ThousandEyesユーザーであるあなたは、Salesforceのページロード時間の急な増加とHTTPサーバーエラーを示す自動アラートを受信していました。

ThousandEyesプラットフォームにログインすると、Salesforceへのアクセスのエンドユーザーエクスペリエンスを示す詳細情報が表示され、ページロード・ビュー(図2)を見ると、ページロード時のスパイクが確認できます。 通常時には、Salesforceログインページの読み込みは約1秒ですが、現在は約10秒かかっていることがわかります。

図2:ThousandEyesページロードビュー
図2:ThousandEyesページロードビュー

さらに、HTTPサーバービュー(図3)に移ると、多数のHTTP(接続、SSL処理、および受信)エラーとHTTP サーバー応答時間の急増が確認でき、赤の四角で囲った詳細のエラー情報も表示されます。

図3: HTTPサーバービュー
図3: HTTPサーバービュー

これらの解析は、パケットロスの増加や輻輳などのネットワークレイヤの問題解決に役立ち、その後のネットワークレイヤビューでの解析により、更なるトラブルシューティングのための詳細な情報を入手できます。

ネットワークパス・品質の監視

クラウドSWG導入の際には、ThousandEyesは図4に示すように、3つの重要なネットワークセグメントを個別のテストで監視して、完全な可視化を行うことを推奨しています。各テストでは、レイテンシ、パケット損失、MTU、QoSマーキングなどのホップごとのメトリックを収集します。

  • ①ブランチからセキュリティプロキシのGREトンネルバーチャルIP(VIP)への接続 – 青色の点線
  • ②ブランチからGREトンネル内の特定のクラウド型セキュリティプロキシサーバーへの接続 – 黒い実線
  • ③セキュリティプロキシサイトからSaaSまたはIaaSプロバイダへのアップストリーム接続 – 橙色の実線(エンタープライズエージェントからSalesforce.comへのエンドツーエンドのテスト)
図4:個別のネットワークセグメントの監視
図4:個別のネットワークセグメントの監視

①ブランチからGREトンネルVIPへの接続

Zscalerユーザーの多くは、GREトンネルを使用して最適なZENにトラフィックを送信してします。ブランチからZscaler ZENへのインターネット接続の健全性をテストするには、Zscalerカスタマーポータルに公開されているZscaler GRE仮想IP(VIP)アドレスに対してネットワークレイヤテストを実行します。このテストでは、ブランチオフィスからZEN GRE VIPまでのレイテンシ、ジッタ、パケットロスのデータ、およびネットワークパスのレイヤ3ホップごとの可視化データが提供されます。

例えばこのモニタリングテストの結果より、ブランチオフィスからZscaler フランクフルト ZEN GRE VIPアドレスまでのパケット損失が午前8時ごろから大きくなっていることがわかります。さらに図5に示すように、下段のネットワークパス可視化画面により、ターゲットまでの全てのパスやパケットロスが発生している特定のノードを確認することができます。

図5:GRE接続のパス可視化
図5:GRE接続のパス可視化

この可視化により、上流のISPであるEcotel Communications(AS 12312)内の特定のルータでパケット損失と輻輳が発生していることがわかるため、Salesforceの問題がまずネットワークの問題によるものかもしれないという最初の疑念を明らかにします。 ただし念のため、他のネットワークセグメントにも問題がないかさらに調査してみます。

②ブランチからセキュリティプロキシへの接続

ZEN VIPへの監視テストのほかに、ユーザーが接続している特定のプロキシサーバーの監視も設定します。 図6に示すように、ブランチオフィスのユーザーはZscalerフランクフルトZENのプロキシ(IPアドレス165.225.72.40)に接続しています。 Zscaler ZEN フランクフルト GRE VIPアクセスへのロスの原因となっているようなパケットロスの急増を確認することができます。

図6:プロキシサーバー接続のパフォーマンス問題の解析
図6:プロキシサーバー接続のパフォーマンス問題の解析

③セキュリティプロキシからSaaSプロバイダへのアップストリーム接続

最後に、Zscaler ZENからSalesforceへのアップストリーム接続用に設定したテストをチェックします。図7では、ブランチオフィスに設置したThousandEyesエンタープライズ・エージェントから、Zscaler フランクフルトZENを経由してna38.salesforce.comまでのエンドツーエンドのパスを確認できます。ユーザートラフィックは、アップストリームのプロバイダーであるZayoのネットワークを経由してフランクフルトからアムステルダム、ロンドン、そして大西洋を横断してワシントンD.C.に転送され、バージニア州エクイニクスのAshburnデータセンターのSalesforceネットワークに渡されます。さらにそのトラフィックは、Salesforceの内部ネットワークを経由して、サービス用のインスタンスがホストされていアリゾナ州フェニックスに送られています。

トラフィックがGREトンネルに入ると、下の青色の点線に示されているように、MTUが1500から1476に減少しました(24バイトのGREヘッダーオーバーヘッドのため)。この情報は、MTUに関連するパフォーマンス問題のトラブルシューティングの際に役立ちます。

図7:Salesforceへのアップストリームパスの可視化
図7:Salesforceへのアップストリームパスの可視化

Zscaler Zenの上流ではパフォーマンスの問題は確認できないので、この問題の根本原因がEcotel Communicationsネットワーク内の特定のルータでのパケットロスであることがわかりました。 ここでThousandEyesのスナップショット共有機能により、調査結果を他の担当者や関連部署・パートナーと共有し、エスカレーションすることができます。

エンドツーエンドのネットワーク解析

このZscalerのパフォーマンス問題解析例により、ThousandEyesの特徴が良くわかります。クラウドサービスへのアクセスは、ネットワークの経路がインターネットベースとなり複雑になります。その一方で、ユーザーのサービスレベルを保つためには、監視機能は引き続き維持する必要があり、その監視なくして問題の解析やトラブルシューティングはできません。

企業ネットワーク、インターネット、クラウドセキュリティプロキシ(Zscalerやその他)、SaaS間の複雑なネットワーク環境をエンドツーエンドで簡単に可視化し、さらにアプリケーションのパフォーマンスデータと関連付けられるのは ThousandEyesだけです。

クラウド型セキュリティ・プロキシサービス監視の更なる詳細については、こちらのホワイトペーパーをご参照ください(英語)。