ゼロトラストへの唯一の道であるZero Trust Exchange

前回のブログでは、ファイアウォールや境界型ネットワーク セキュリティ ソリューションが、どのような理由でゼロトラストを実現できないかについて説明しました。ファイアウォールやVPN、仮想ファイアウォールなどのクラウドベースの境界モデル、クラウドベースのポイント ソリューションは、いずれも真のゼロトラストの枠組み(NISTやその他の主要機関によって定義されたもの)に準拠していません。そうすると「これらのモデルでゼロトラストを実現できないとしたら、何がどのように実現できるのだろうか」という疑問が残ります。

その答えは、Zscaler Zero Trust Exchangeです。独自のアーキテクチャーを持つこのクラウドネイティブなプラットフォームは、従来のネットワーク セキュリティ技術ではできなかったゼロトラストを実現します。図1に示されているように、Zero Trust Exchangeは、プロキシ アーキテクチャーをベースに、ユーザーとアプリ、アプリ間、マシン間を含むあらゆるデバイス、ネットワーク、ロケーションで安全に接続するスマートな交換機の働きをします。アプリケーションに通信要求を許可する前に、アイデンティティーとコンテキストに基づく検証を義務付けています。

Zero Trust Exchangeは、インターネット、SaaS、プライベート アプリケーションがホストされている場所(インターネット、データ センター、プライベート クラウドまたはパブリック クラウド)へのアクセスを保護することで、ユーザー、アプリケーション、ワークロードにゼロトラストを提供します。

Zero Trust Exchangeが実績あるアーキテクチャをどのように使ってゼロトラストを大規模に実現するのか、詳しく見ていきましょう。図2では、接続しようとするモバイルデバイスやIoTなど (図の下部) と、それらがアクセスしようとするクラウドアプリケーション、SaaSアプリケーション、インターネットアプリケーションなど (図の上部) の間に、Zero Trust Exchangeがポリシー実行者および意思決定者として位置しています。Zero Trust Exchangeは、ポリシーやコンテキストをさまざまな方法で適用しながら実行判断を下し、リクエストされたリソースへの接続認可を仲介します。

本人確認 - 最初のステップは、本人確認です。これを行うために、Zero Trust Exchangeは最初にすべての接続を終了させます。最初のステップで接続を終了させるというのは、不可解に思われるかもしれませんが、これには明確な理由があるのです。Zero Trust Exchangeはセッションを停止し、IAM (アイデンティティーとアクセス管理)システムから取得したアイデンティティー情報と比較して、このユーザー/個人が誰であり、どのようなコンテキストがそのアイデンティティーに関連しているかを検証することで、接続を確認します。Zero Trust Exchangeは、アプリケーションの種類に応じて、ID Proxy、SAMLアサーション、MFA (IdPオプション付き)などの認証要件を適用することができます。

アイデンティティー チェックに失敗した場合やアイデンティティーのコンテキストに基づいてユーザーが特定のリソースへのアクセスを許可されていない場合、接続がその場で終了します。これは、ファイアウォールのパススルー型アーキテクチャーとは対照的に、プロキシ型アーキテクチャーで行われます。ファイアウォールはデータを通過させてから帯域外の分析を行うため、未知の脅威が検出されずに通過してしまうのです。Zero Trust Exchangeは、Okta、Ping、Active Directory/Azure ADなどの主要なアイデンティティー プロバイダーとAPI統合しており、これらを使ってアイデンティティーを確立することができます。

デバイス認証 - 次のステップは、デバイスの状態に関するコンテキストを構築することです(デバイスは会社のものか個人のものか、管理対象なのか非管理対象なのか、コンプライアンスに準拠しているかどうかなど)。デバイス コンテキストは、ユーザーの役割、アクセスしようとしているアプリケーション、交換するコンテンツなど、他の形式のコンテキストと組み合わされます。これらの条件が、許可されるアクセスのレベルを決定します。Zero Trust Exchangeは、Microsoft Defender、VMware Carbon Black、Crowdstrike Falconなどの主要なエンドポイント保護ソリューションと統合し、コンテキストやエンドポイントのセキュリティを確保します。

アプリケーション ポリシー - Zero Trust Exchangeは、リクエストされたアプリケーションがパブリック アプリケーションなのかプライベート アプリケーションなのかを識別し、SaaSアプリケーションを承認済み(M365など会社が購入したアプリケーション)もしくは未承認(従業員が個人的に使用するもの)に分類します。アプリケーションの種類に応じて、URLフィルタリング、CASB (クラウド アクセス セキュリティ ブローカー)保護などのソリューションとアプリケーション リスク インデックスを活用してアプリケーション リスクの分類とアクセス ポリシーの運用を行います。また、Zero Trust Exchangeはユーザーが利用できる最も近いアプリケーションのソースを決定し、そのソースを使用して接続を確立します。

セキュリティ態勢 - セキュリティ技術の究極の目標は、暗号化されたデータを含む機密データを保護することです。攻撃者の多くは、ファイアウォールが暗号化されたトラフィックを大規模に検査できないことを知ったうえでSSLにマルウェアを隠しているため、検出を回避しています。今日、トラフィックの90%以上は暗号化されています。ファイアウォールは暗号化されたデータをすべてインラインで検査できないのに対して、Zero Trust Exchangeはトラフィックを解読して中身を確認することができます。DLP (情報漏洩防止)に加え、サンドボックスからのインライン データへのサイバー脅威対策を提供し、前のステップで収集したコンテキストを使用して、異常な動作に目を光らせます。こういった検証は、各ステップにおけるユーザーのリスク レベルの特定に役立ちます。

ユーザがこれらの検証ステップをすべて通過した場合、「果たしてリクエストされたリソースへの接続を仲介しても大丈夫だろうか」という問題が浮上します。

ポリシーの実行 - 会社は、従業員がアクセスできるものとできないものをハイ レベルで指定するために、ビジネス ポリシーを決定します。このポリシーと個々のリクエストのコンテキストに基づいて、Zero Trust Exchangeはアプリケーションへのアクセスを許可または拒否します。プライベート アプリケーションはインターネットに公開されず、アクセスはアウトバウンド専用接続で仲介されるのに対し、パブリック アプリケーションは条件付きアクセスになります。

財務部門の従業員が、管理対象デバイスを使用して財務データにアクセスする場合を考えてみましょう。ポリシーが求めるコンテキストが満たされている場合は、アクセスが承認されます。しかし、従業員が非管理対象デバイスを使用する場合、完全なアクセス権限は付与されません。代わりに、代替ポリシーによりコンテナー化された環境における分離セッションからピクセルとしてデータをストリームするリモート ブラウザー セッション経由のアクセスを提供できますが、データ自体へのアクセスやダウンロード、デバイス上のキャッシュなどは許可しません。

Zero Trust Exchangeは、エンティティーからアクセスが許可されたリソースやアプリケーションへのきめ細かい接続を確立します。これがまさにゼロトラスト接続です。仮にセキュリティ上の脅威があったとしても、その影響はネットワーク全体ではなく、特定の要求元とアクセスしているアプリケーションの間の接続に限定されます。このアーキテクチャーは、NISTアーキテクチャーで定義された原則に完全に準拠しており、信頼できるアクセスを提供するためのセキュリティ ソリューションに不可欠なものです。

Zero Trust Exchangeは、複雑なMPLSネットワーク、境界ベースのファイアウォール制御、VPNを必要としません。高速で安全なクラウドへの直接アクセスと、バックホール、ルート分散、サービス チェーンを排除した安全なクラウド間接続を提供します。管理や維持が困難な複数のハードウェア ベースまたは仮想のセキュリティ ソリューションの代わりに、統合されたゼロトラスト ソリューションがひとつの総合プラットフォームですべてのインターネット、SaaS、プライベート アプリケーションのセキュリティを確保します。Zero Trust Exchangeは、クラウドネイティブで透明性の高いゼロトラスト アクセスを実現し、シームレスなユーザー エクスペリエンス、最小限のコストと複雑さ、可視性ときめ細かい制御、そしてゼロトラスト セキュリティへの最新のアプローチによってパフォーマンス向上をもたらします。

ゼロトラストに関する詳細は、Why Firewalls Cannot do Zero Trustをご覧ください。何がゼロトラストで何がそうでないか、そして導入のためのベスト プラクティスを学ぶことができます。