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

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

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

図

説明文の自動生成

図1: Zero Trust Exchangeの概要

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

図2: Zero Trust Exchangeのアーキテクチャ

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

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

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

アプリケーションポリシー - Zero Trust Exchangeは、リクエストされたアプリケーションがパブリックアプリケーションなのかプライベートアプリケーションなのかを識別し、SaaSアプリケーションを公認 (M365など会社が購入したアプリケーション) もしくは非公認 (従業員が個人的に使用するもの) に分類します。アプリケーションの種類に応じて、URLフィルタリング、CASB (Cloud Access Security Broker) 保護などのソリューションとアプリケーションリスクインデックスを活用してアプリケーションリスクの分類とアクセスポリシーの運用を行います。また、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は、クラウドネイティブで透明性の高いゼロトラストアクセスを実現し、シームレスなユーザエクスペリエンス、最小限のコストと複雑さ、可視性ときめ細かい制御、そしてゼロトラストセキュリティへの最新のアプローチによってパフォーマンス向上をもたらします。

ゼロトラストに関する詳細は、なぜファイヤーウォールではゼロトラストが実行できないのか (英語) をご覧ください。何がゼロトラストで何がそうでないか、そして導入のためのベストプラクティスを学ぶことができます。