事業継続性に関するお客様の懸念とZscalerの対策：2つの大規模IT障害を踏まえた解説

IT担当者、セキュリティ担当者、経営幹部、取締役にとって、2024年7月の数週間は例年にも増して慌ただしいものとなりました。7月18日には、MicrosoftのAzure Central USの障害により、数十のAzureサービスに影響が生じました。その翌日の7月19日には、CrowdStrikeの障害により、世界中のWindowsマシン(クライアントおよびサーバー)がブルー スクリーン エラー(BSOD)で使用不能となる事態が発生しました。

Zscaler Zero Trust Exchangeはミッションクリティカルなサービスであるため、これらのインシデントを受け、ZscalerもCrowdStrikeのようなリスクにさらされているのではないかと懸念するお客様から、多くのお問い合わせをいただきました。そこで当社では、超満員となったCXO向けのブリーフィングや、一般公開のウェビナー「Preventing Cloud Outages for Zscaler Customers」を通じ、Zscalerを現在ご利用中またはご検討中のお客様に向けて詳細な説明を行いました。この記事では、その中の特に重要なポイントを取り上げていきます。

1. Zscalerに同様の障害が起こる可能性

2. Zscaler Client Connectorのカーネル空間での動作

3. Zscalerのアップグレード管理方法

4. クラウド レジリエンスに対するZscalerのアプローチ

5. オペレーショナル レジリエンスを強化するための推奨事項

CrowdStrikeおよびAzureの障害の概要

クラウドの世界で障害の原因になりやすいのは、(直感的にはるかに想像しやすい)物理的な障害よりも、コードのバグや構成変更です。実際、7月18日と19日に発生した障害は、いずれもプロバイダー側が行った変更に起因するものでした。Microsoftは不完全な許可リストの変更をプッシュし、信頼されたVMホストからUS CentralのAzure Storageへの重要なアクセスが遮断されました。CrowdStrikeの障害の原因は不具合のある応急対応用のコンテンツ更新(挙動シグネチャー)で、これが850万台のエンドポイントに一斉配信されたことでメモリー エラーが発生し、BSODを引き起こしました。

Zscalerに同様の障害が起こる可能性

どのようなクラウド ベンダーも問題と無縁ではいられませんが、Zscalerではリスクを大幅に低減するための複数の対策を備えています。Zscalerも独自のエンドポイント エージェントを持っていますが、その機能や配信される更新の種類は、エンドポイント セキュリティ ベンダーとは大きく異なります。

• アップグレードを開始するのはZscalerのお客様自身。Zscalerでは、クライアントのアップグレードを強制したり、慎重を要する更新をエンドポイントに自動配信したりしないという方針を創業当初から一貫して採用しており、お客様がすべてを制御することができます。Client Connector App Storeの更新設定をカスタマイズして、特定のユーザー グループのみに更新を適用し、7日間にわたって段階的にロールアウトすることで、組織の環境で更新をテストおよび検証することが可能です。
  
• 更新の大半はエンドポイント エージェントではなくクラウド側で実施。Client Connectorは、認証、トラフィックのインターセプトおよびクラウドへの転送を担う軽量エージェントです。ポリシーはクラウド側で施行され、カーネル空間やユーザー空間での複雑なセキュリティ検出やポリシーの施行をClient Connectorが行うことはありません。
• Zscalerは自社環境で最初に更新をテスト。当社では「ドッグフーディング」文化を大切にしており、ZscalerのIT部門はすべての新しいリリース候補(GA前の段階も含む)を最初に導入しています。

Zscaler Client Connectorのカーネル空間での動作

Windows Client Connectorのプロセスのほとんどはユーザー空間で実行されますが、トラフィックのインターセプトや改ざん防止(マルウェアによるClient Connectorの停止の防止など)といった一部の機能は、カーネル ドライバー アーキテクチャーでのみ動作します。

Client Connectorの主な機能の1つは、ローカル アプリケーションによって生成されたアウトバウンド トラフィックをインターセプトし、ZIAトンネルまたはZPAトンネルを介してZscalerクラウドにIPパケットを転送することです。特にZIAにおいては、トンネル モードにおけるトラフィック インターセプト用ドライバーはカーネル空間で実行する必要があります(ローカル プロキシを使用したトンネルなど、他のインターセプト方式ではカーネル ドライバーは不要です)。ZIAトンネル モード(ルートベース)では、Client Connectorは仮想ネットワーク アダプター ドライバーを実行し、ZIAトンネル モード(パケットフィルター ベース)では、WindowsのLightweight Filter Driver (LWF)を実行して、お客様が定義したフィルターに基づいてパケットを専用のClient Connectorプロセスに転送します。

Zscaler Client Connectorのトンネル モードにおけるWindowsパケット フィルターの使用

Client Connectorの段階的な展開をお客様が制御できること、セキュリティ コンテンツの更新に比べてクライアント ソフトウェアの変更頻度が少ないこと、Client Connectorおよびそのトラフィック インターセプト ドライバーが軽量であること(ポリシーの処理はすべてクラウドで行われ、Client Connectorがセキュリティ検出を実行または自動ダウンロードしないこと)、および厳格なテスト プロセスにより、大きな損失をもたらすエンドポイント障害が防止されます。

Zscalerのアップグレード管理方法

前述のクライアント更新に加えて、Zscalerはクラウド セキュリティ フィードの更新とクラウド ソフトウェアのアップグレードという2種類の更新も実施します。どのような変更においても、スピードとリスク軽減のバランスを取ることがZscalerの基本的な設計原則となっています。

常に攻撃者に先回りで対応し、検出の有効性を改善するために、Zscalerは多数のセキュリティ フィード、シグネチャー、挙動検出、機械学習モデルの更新を継続的に配信し、エンド ユーザーを保護しています。これらの更新ではスピードが重要である一方、安全な展開も同様に重要です。Zscalerでは、初期段階での安定性テストとカナリア リリースを組み合わせて実施しています。

クラウド ソフトウェアにおいても、Zscalerは同様の「多層防御」モデルに従い、カナリア方式で数週間かけて段階的に更新を展開しています。

クラウド レジリエンスに対するZscalerのアプローチ

事業継続性や運用の継続性は、カーネルレベルの問題にとどまりません。ミッションクリティカルなクラウド サービスを提供するには、包括的なアプローチが求められます。

1. スケーラビリティー、パフォーマンス、セキュリティ、信頼性を最初から考慮して設計された、信頼性の高い本番クラウドを運用すること。
2. レジリエンスに優れたクラウド管理ライフ サイクルを展開すること。Andy Jassyの有名な言葉のとおり、経験のための圧縮アルゴリズムはありません。
3. ブラックアウト、ブラウンアウト、大規模障害など、あらゆる障害シナリオに対応できるツールを提供すること。

Zscalerの取り組みについては、レジリエンスに関するWebページおよびウェビナー「Preventing Cloud Outages for Zscaler Customers」をご覧ください。

オペレーショナル レジリエンスを強化するための推奨事項

1. Zscalerの導入にあたっては、ZIAおよびZPA向けのディザスター リカバリー(DR)を含む事業継続機能やベスト プラクティスを実装し、テクニカル アカウント マネージャーと共同でZscalerのレジリエンス監査を実施します。
2. 1つのプラットフォームに障害が発生した場合でも重要なサービスの可用性を最大限に維持できるよう、各領域で業界をリードする優れたプラットフォームを利用し、統合します。特に、エンドポイント、アイデンティティー、ゼロトラスト アクセス、アプリケーション プロバイダー(ハイパースケーラーを含む)については、単一のプラットフォームに依存しないようにすることを推奨します。
3. ソフトウェアやセキュリティの更新のロールアウトを段階的に行い、リスクを軽減します。まずは少数のユーザー グループで更新をソーク テストを行い、正常に動作することを確認してから、他のグループへ展開することを推奨します。
4. 重要なベンダーのアーキテクチャーおよびオペレーショナル レジリエンスを見直します。
   

お客様による制御が可能な事業継続性機能

これまで、特に規制の厳しい業界のお客様から「Zscalerのセキュリティ クラウドへの投資や取り組みを信頼しているものの、万が一の不可抗力(フォース マジュール)にはどう備えるべきか？」といった質問が寄せられていました。このようなユース ケースに対応するため、Zscalerは18か月前、お客様による制御が可能なディザスター リカバリー(DR)機能を業界で初めてリリースしました。この機能は、すでに当社の多くのお客様に広く採用されています。

この機能のリリースに続き、Zscalerでは近日、完全マネージド型またはお客様によるセルフホスト型のプライベートDRクラウドの提供をZIAおよびZPA向けに開始する予定です。

セルフホスト型のDRクラウドは、事業継続性が求められる場面においても一貫した機能を担保します。完全マネージド型のDRソリューションでは、これに加え、導入にかかる負担も軽減できます。 

エンドポイントの障害に対応する事業継続性機能

当然ながら、今回のインシデントを受けて、多くの組織が特にWindowsエンドポイントのオペレーショナル レジリエンスを強化する方法を再評価しています。セキュリティを損なうことなく、そこで求められるプロアクティブなレジリエンスを確保するには、ZscalerのCloud Browser Isolation (CBI)およびPRA (特権リモート アクセス)を導入し、エージェントレスの安全なBYODアクセスを実現することが効果的です。

エンドポイントに障害が発生した場合でも、ユーザーは自身の個人用デバイス(または代替デバイス)に切り替えて、セキュリティ リスクやデータ漏洩のリスクを冒すことなく重要なSaaSやプライベートWebアプリ、RDP | SSH | VNCシステムへのアクセスを維持できます。

エンドポイントにおける事業継続性を確保する新たなソリューションやCloud Browser Isolationの詳細については、こちらからお問い合わせいただくか、担当のアカウント チームにご連絡いただければ幸いです。事業継続性に関するリソース ハブもご覧ください。