SDPを使用したマルチクラウドなプライベートアプリへの安全な接続

今日、大多数の企業が、プライベート・アプリケーションをさまざまなタイプのインフラストラクチャ上で実行しています。これは、従来のデータセンターのハードウェアから、パブリッククラウド、またはAzureやAWSなどのIaaSプロバイダーまで多岐にわたります。顧客と仕事をする中で、1つのIaaSプロバイダーだけに全面的に依存する企業は稀であることに気付きました。実際、今日の企業の約50%が2社以上のクラウド・プロバイダーを導入しています。つまり、複数のサービス・プロバイダーにまたがるアプリケーションへのアクセスを管理し、安全に管理できることが求められているのです。しかし、どのようにしてでしょう?

長年にわたり、企業のセキュリティチームは、オンプレミス環境とパブリッククラウドを異なるIT環境として扱ってきました。これには2つの要因があると考えています。1つ目は、セキュリティ専門家が、他の誰かがホストしているセキュリティ技術に頼るのではなく、自分たちのセキュリティアプリケーションを管理することに抵抗感を持っていないことです。第二に、クラウドのセキュリティは、44%の場合、実際のセキュリティ組織以外の誰かが管理しています。これでは、全体的なセキュリティ戦略を取るのではなく、チームは全く別のセキュリティ技術に頼らざるを得なくなります。これでは、不必要な数のセキュリティ技術を管理するために必要な時間とエネルギーの量が増えるだけでなく、コストも増えてしまいます。アプリケーションがAWS、Azure、またはデータセンターで実行されているかどうかを考えなければならないユーザーを考慮に入れると、最終的には、より複雑なIT環境とイライラするユーザー体験になってしまいます。

レガシー方式:

  • ユーザーが接続できるように単一のアクセス・パス(ゲートウェイ)を構築し、さまざまな場所間のバックエンド・ネットワークを経由してユーザーをルーティングします。
  • 場所ごとに複数のアクセスパスを構築し、ユーザーが必要とする場所にオンデマンドで接続できるようにします。

これらのオプションにはどちらもメリットと課題がありますが、どちらもエンドユーザーが仕事をしようとするときに必要とするシンプルさを提供していません。

Zscalerでは、世界最大級の企業と協力して、マルチクラウドとハイブリッドクラウドという新しい空間をナビゲートし、よくある間違いを回避し、クラウドの導入がセキュリティ機能を上回ることがないように支援しています。

その鍵となるのは、Gartner 社がSDP(Software-Defined Perimeter)と呼んでいるものを企業が採用できるように教育し、可能にすることです。これは、インバウンド VPN ゲートウェイ・アプライアンスに代わる新しいセットアップであり、アプリケーション・アクセスをネットワーク・アクセスから完全に切り離し、アプリをインターネットに公開することなく、ユーザーがアプリに接続する方法を再定義します。SDP アーキテクチャは、既存のネットワーク中心のプロセスに代わる、より高速で安全な代替手段として機能します。これまでは、サイト間の機能を追加設定し、仮想ファイアウォールを展開し、アプライアンスやIaaSサービスごとにACLやポリシーを管理する必要がありましたが、SDPアーキテクチャは、従来のネットワーク中心のプロセスに代わる、より高速で安全なプロセスを提供します。

今回のアーキテクチャ白書では、以下の内容を取り上げます:

  • レガシーネットワークセキュリティ(リモートアクセス VPN など)と最新のユーザー定義セキュリティアーキテクチャ(SDP など)のアーキテクチャの違い
  • マルチクラウド向けの真のゼロトラスト・セキュリティ・アーキテクチャがどのようなものかを示す
  • マルチクラウド上で動作するプライベート・アプリへのアクセスを確保するためのフェーズ

このガイドでは、典型的な企業のシナリオを例として説明します。私たちの架空の企業は、スイスのジュネーブに拠点を置くメーカーである Geo-Enterprise SA と呼ばれています。Geo-Enterprise は従来、アプリケーションをジュネーブとニューヨークの 2 つのオンプレミス拠点のうちの 1 つでホストしていましたが、マルチクラウド戦略の採用を検討しています。これにより、データセンターや単一のIaaSプロバイダーだけに頼っても達成できないレベルのコスト削減と規模の改善が可能になります。歴史的に、Geo-Enterpriseは、プライベート・リンクを介して、それぞれのアプリケーション・ロケーションへのクラウド・アプリケーションへのアクセスをルーティングしてきました。ユーザー・トラフィックは、支店からプライベート・リンクを経由して、またはリモート・アクセス・ポイントから、オンプレミス・データセンターのアクセス・ゲートウェイを経由してルーティングされます。クラウドアプリのロケーションはインターネットパスに最適化されているため、一般的にプライベート・リンクはピーク時には圧倒され、維持するのが煩雑になります。

Geo-Enterpriseの現在のアーキテクチャ

Geo-Enterprise は、ユーザーが環境全体でプライベート・アプリケーションにアクセスする方法に取り組み始めています。従業員の約 40% は完全なモバイル・リモート・ワーカーであり、さらに 30% は、自宅で仕事をしながらのリモート・アクセスや出張によるリモート・アクセスを必要とするキャンパス・ベースのユーザーです。

Geo-Enterpriseは現在、Microsoft Azure(Azure)とAmazon Web Services(AWS)上でプライベート・アプリを実行しているほか、長年使用してきた現職のデータセンターのインフラストラクチャを利用しています。この統合は、米国と欧州の2つのグローバルリージョンに分割された相互接続されたプライベートMPLSネットワークによって行われています。

 

最近では、経営陣が主導して、同社のアプリケーションの大部分を今後12ヶ月間にクラウド環境に移行させ、36ヶ月間にクラウドへの移行を完了させることを目標としています。同社では、これはビジネス全体のコストを削減するための重要な方法と考えています。ただし、一部のアプリケーションはデータセンター環境に残り、オンプレミスのプレゼンスをジュネーブの最小限のデータセンターに集約することを目標としています。

アプリケーションロケーションのシフトを超えて、ユーザーとサービスネットワークの機能を分離し、ゼロトラスト・ネットワーキング戦略に移行するという将来のモデルのビジョンがあります。

Geo-Enterprise は現在、リモートアクセス VPN 技術として Cisco AnyConnect を使用しています。しかし、データセンターやパブリッククラウド(IaaS / PaaS)環境で稼働しているプライベート・アプリケーションにアクセスするためには、VPNへの依存度を下げたいと考えています。

従来、すべてのリモートアクセストラフィックは、パブリッククラウド・プロバイダーにホストされているプライベート・アプリ向けのトラフィックを含めて、プライマリデータセンターのVPNコンセントレータにルーティングされていました。これは、リモートユーザーにとって大きな待ち時間の課題となっていました。VPNアプライアンスの配布と拡張には複雑さと費用がかかり、それをサポートして保護するために必要な複雑なインフラストラクチャが必要となるため、継続的な課題となっています。

目的

既存のデータセンター環境だけでなく、新興のクラウド環境でも社内アプリケーションに直接アクセスできるようにするために、よりシンプルなアーキテクチャモデルが必要とされています。

主なビジネスドライバーは、アプリケーションがクラウドに移行することで、現代の労働力に次世代のアプリケーション配信を提供するための準備ができていることです。Geo-Enterpriseはすでにクラウドホスト型ソリューションを採用しており、戦略を定義しています。しかし、Geo-Enterprise は、この戦略を実行するにあたり、エンドユーザーがより柔軟でシームレスなアプリケーション配信サービスを継続的に要求してくると予想しています。これを実現するためには、Geo-Enterprise は、データセンターのアプライアンスから脱却し、集中管理を可能にするグローバルに分散されたクラウドホスト型セキュリティプラットフォームを採用する必要があります。

プライベート・アプリケーションがパブリッククラウド・プロバイダーに移行するケースが増える中、データセンターやクラウド環境でユーザーがアプリに同時にアクセスできるようにすることが重要になりますが、その一方で、低速でコストのかかるバックホールを可能な限り回避することも重要になってきます。ネットワークの変化に伴い、コスト効率の高い導入モデルを維持しつつ、セキュリティ管理も行う必要があります。パブリッククラウドで実行されるアプリへのアクセスの設定と監視を最適化するための、より効果的なツールが必要となり、追加のリスクが発生しないようにする必要があります。

この旅の一環として、Geo-Enterprise は、プライベート・アプリのゼロトラスト・モデルを採用したいと考えています。この新しいモデルでは、クライアントは、接続元のネットワークではなく、彼らのアイデンティティと体制に基づいてアプリケーションへのアクセスを提供されます。このアーキテクチャは、リモートかオンプレミスかにかかわらず、すべてのユーザー・エンドポイントを従来のセキュリティ境界線の「外側」とみなすことができるため、企業ネットワークのセキュリティを確保するためのコスト構造と管理負担を根本的に変えます。

従来のリモートアクセスVPNインフラストラクチャは、常にネットワーク上にユーザを置くことで脅威の表面を広げるため、Geo-Enterpriseにリスクをもたらします。Zscaler Private Access (ZPA) は、4つの主要なセキュリティの考え方に従うことで、このリスクを克服します。

  • 内部ネットワークに持ち込むことなく、プライベート・アプリケーションにユーザーを接続することができます。
  • インサイドアウト接続により、プライベート・アプリがインターネットにさらされることはありません。
  • 複雑でコストのかかるネットワーク・セグメンテーションに頼らないアプリケーション・セグメンテーション
  • L3 IPsec VPNに頼らない安全なネットワークトランスポートとしてのインターネットの利用

この安全なアプローチは、他のGeo-Enterpriseアプリケーションへの横移動がないことを意味します。さらに、ユーザーがアクセスできないアプリケーションは完全に暗闇のままで、アプリケーションがユーザーから直接インバウンド接続を受信しないため、ホストされた環境に向けられたローカルまたはインターネットから、ポートスキャンまたは他のメカニズムを介して発見することができません。

ビジョン

Geo-Enterpriseはすでに、ロードウォリアーがアプリケーションへの安全なアクセスを必要とし、オフィスを拠点とする従業員がクラウドベースのアプリケーションに直接接続する必要がある状態にまで達しています。より良い結果を得るために、ZPAは以下を提供しています。

グローバルで統一された安全でシンプルなアクセス:
ユーザーやアプリケーションの場所に関係なく、シームレスで高速なアプリケーションへのアクセスは、ビジネスの機能にとって非常に重要です。プライベート・アプリが動作するインフラストラクチャが多様化していることは、すべてのユーザーに対するセキュリティとアクセス制御をグローバルに設計・適用し、ユーザーがアプリにアクセスするための最も効率的な経路を確保できるようにする必要があることを意味しています。アプリケーションは、オンプレミスのユーザーもリモートのユーザーも、デスクトップやモバイルデバイスから等しくアクセスできるようになります。これは、Geo-Enterpriseの接続体験に革命をもたらすでしょう。

セキュリティの可視性と制御の向上:
内部アプリケーションへのすべてのトラフィックフローは、許可されたユーザーのみがアプリケーションにアクセスできるように制御されます。誰がどのアプリにアクセスしているかを包括的に可視化することで、現在のワークフローを確実に把握し、IT とエンドユーザーのニーズに合わせたきめ細かなアクセスポリシーを設計することができます。

コストの回避:
リモートユーザーのアクセスを可能にし、関連するリスクを軽減するために必要とされていたセキュリティとネットワークインフラは、このプロジェクトの一環として削減されるか、あるいは廃止される可能性があります。その結果、ネットワークインフラや運用コストを最小限に抑えることができます。

クラウドへの対応力:
アプリケーションがクラウドに移行し、ユーザーのモバイル化が進む中、セキュリティを適用する唯一のスケーラブルな方法は、エンドポイントとネットワークを接続するのではなく、ユーザーとアプリケーションを接続することです。Zscalerプラットフォームを活用することで、Geo-Enterpriseは、現在および将来のインフラコストに制約されることなく、クラウドアプリケーションを継続的に採用することができます。

ゼロトラスト:
ネットワーク接続ではなく、アイデンティティと姿勢を利用してアクセスを提供するアプリケーション・アクセスのモデルに移行することで、企業のネットワークと情報を横移動、不正アクセス、インサイダーや外部からの脅威から保護することができます。

Zscaler Private Access (ZPA)

Zscaler Private Access(ZPA)は、ユーザーをネットワーク上に置いてインターネットに晒すことなく、シームレスで安全なプライベート・アプリケーションへのアクセスを実現するクラウドサービスです。従来のリモートアクセス方法で使用されていたネットワーク層のトンネルの代わりに、ZPAは、必要に応じてのみ作成される暗号化されたセッションごとのマイクロトンネルを介して、許可されたユーザーに特定のアプリケーションへのアクセスを提供します。このSDP(Software-Defined Perimeter)サービスは、2008年に初めて開発されたゼロトラスト・ネットワーキングの概念に基づいて構築された、Gartner社のリモート・アクセスのためのCARTA(Continuous Adaptive Risk Trust Assessment)フレームワークを提供します。

ソリューションとその様々な要素を検討する前に、システム設計の目的を考えることが有用です。

セキュリティ – セキュリティは、 ほぼすべてのネットワーキング機器の設計において考慮すべき事項ですが、ZPA の作成においては基本的な要件となりました。ZPA がアクセスを提供するプライベートな内部アプリケーションは、通常、組織の最も機密性の高いデータを保持しているため、この事実が最も重要な考慮事項となります。デバイス アーキテクチャやデバイス間通信など、ZPA のすべての要素は、移動中のデータと静止中のデータのセキュリティを保証するように構築されています。

信頼性 – ミッションクリティカルな内部リソースへのアクセスを提供するために設計されたシステムは、信頼性が高く、常に利用可能でなければなりません。ZPAソリューションは、グローバルに分散され、Zscalerによって24時間365日メンテナンスされているインフラストラクチャで信頼性を提供します。インフラストラクチャの個々のコンポーネントは、ユーザーへの影響を最小限に抑え、セキュリティ保護を損なうことなく、適切に障害が発生しないように設計されています。さらに、インフラストラクチャの個々の要素は、エンドユーザーに影響を与えることなく、段階的にアップグレードすることができます。

スケーラビリティ – ZPA は、グローバルに分散した多くの組織のユーザーが、多様なアプリケーションに同時にアクセスすることをサポートするように設計されています。グローバルなZPAソリューションは、組織を横断して拡張し、組織とともに成長していくため、トラフィックの急増にも中断することなくシームレスに対応できます。

管理性 – この品質は、ZPAシステムを日常的に使えるようにするための属性の集合体を含んでいます。ZPAは、特定のコンピューティング環境に依存することなく、さまざまな顧客構成と相互作用します。このソリューションは、導入、管理、監視、トラブルシューティングが容易で、ZPA が保護する資産のデリケートな性質を考慮すると、すべての重要な属性を備えています。ZPAはアプライアンスではなくサービスなので、展開、テスト、管理、アップグレードのためのハードウェアがありません。最後に、このソリューションは、アプリケーションが存在するネットワークからアプリケーションを抽象化し、アプリケーションのロケーションの変更を簡素化し、データセンターからクラウドへの移行を容易にすることで、企業のインフラストラクチャ全体を簡素化します。

革新的な設計

  1. ZPA ZENs – ユーザーからアプリへの安全な接続 クラウドポリシーエンジン – ユーザーからアプリへのアクセス権
  2. Z-App / Browser Access – アプリへのアクセスを要求する
  3. App Connectors – アプリの前に座る – アウトバウンド専用接続

Z-ConnectorとZ-App間の安全な接続をZscalerのクラウドブローカで実現

内部アプリケーションへのゼロトラスト・アクセス用に構築

  1. ユーザーがネットワーク上にいることはない
  2. アプリは目に見えない、インターネットにさらされない
  3. ネットワークセグメンテーションなしのアプリセグメンテーション
  4. リモートアクセスVPNを使わずに安全なネットワークとしてインターネットを利用する

ZPA がリモートアクセスに内在するセキュリティリスクにどのように対処しているかを検討する前に、まず、リモートアクセス VPN がもたらすリスクについて考えてみましょう。リモートアクセス VPN を使用するには、企業がインフラストラクチャをインターネットに公開してリクエストを終了させる必要があります。IPsecトンネルの暗号化強度にかかわらず、トンネルの「端が開いている」ことは、攻撃の可能性を大幅に高めます。また、感染したデバイスがプライベート・ネットワークに接続し、そのネットワーク上の他のデバイスを攻撃する可能性もあります。ZPAでは、以下のように、それぞれのリスクに対応したアーキテクチャを構築しています。

エンドデバイスはアプリケーションが存在するネットワークに直接接続されることはありません。代わりに、ZPA はフォワードプロキシとリバースプロキシが一緒に動作するのと同様の機能を提供します。これにより、ネットワークやアプリケーションがオープンなL3ネットワークトンネルに感染したり、悪用されたりすることはありません。

ユーザーが利用可能なアプリケーションを表示できるのは、ユーザーが接続を許可されているアプリケーションに限定されます。ZPA は、名前付きユーザーから名前付きアプリケーションへのアクセスのみを提供するように設計されています。これにより、マイクロセグメンテーションとアクセス制御のメリットを享受できます。

クライアント側とアプリケーション側の要素は証明書に固定されています。Zscalerは独自の認証局(CA)として動作し、クライアント側のZscalerアプリとアプリケーション側のZENコネクタは、CAになりすました攻撃者がセッションを乗っ取るリスクを排除するために証明書がピン留めされています。ゼロトラスト・モードでは、顧客は署名付き証明書を提供して完全なプライバシーを確保することができます。

有用なベンチマークは、PCI-DSS や HIPAA などの要件から導き出すことができますが、これらはいずれも、動作中のデータや休息中のデータを保護するために文書化されたセキュリティ管理を義務付けています。もう 1 つの基準は、リモートアクセスのソリューションを介してアクセスされるミッションクリティカルな資産の可用性です。

01 / Geo-Enterpriseの未来のSDPアーキテクチャ

ZPA プラットフォームを活用することで、Geo-Enterprise は、分散化されたユーザーによるプライベート・アプリへのアクセスを、異なる環境で体験することができます。最初の生産段階では、このアクセスは、南北アメリカ、ヨーロッパ、アジアのGeo-Enterpriseの中核拠点全体で利用され、SAPなどの重要なアプリケーションへの管理ユーザーのアクセスが組み込まれます。

その後のフェーズでは、Geo-Enterpriseは、オンプレミスとリモートの両方のユーザーのためのクラウドマイグレーションされたアプリケーションへのアクセスや、AzureでホストされているM&Aの実験など、追加のユースケースを探求していきます。これらのフェーズでは、ユーザーが地域や中央のデータセンターにバックホールするのではなく、パブリッククラウド・プロバイダーの環境にあるプライベート・アプリに直接アクセスできることが重要です。この要件は、他のクラウド・アプリケーションが展開される際にも当てはまります。

 

Geo-Enterprise がクラウドへの道を歩む上で、次のステップに進むべき重要なステップは、異種環境にあるプライベート・アプリへのユーザーのアクセスを分散化することです。この旅を成功させた最初で最も重要なアプリケーションの 1 つが SAP でした。ユーザーは、地域や中央のデータセンターにバックホールするのではなく、パブリッククラウド・プロバイダー環境のプライベート・アプリに直接アクセスできることが重要です。この要件は、他のクラウド・アプリケーションが展開される際にも当てはまります。

シンプルさと俊敏性が成功の鍵となります。ZPAのクラウドプラットフォームを使用してセキュリティ対策を実施することで、セキュリティが向上するだけでなく、アプリをクラウドに移行するために必要な俊敏性とシンプルさも実現できます。上の簡単な図にあるように、Zscalerは、データセンターやクラウド環境のプライベート・アプリケーションへの最適化されたパスを、グローバルなクラウドフットプリント全体に渡って提供します。Geo-EnterpriseのユーザーはZ Appまたはブラウザベースのアクセスを介してZscalerのグローバルクラウドプラットフォームに接続し、Zscalerがすべてのプライベート・アプリのトラフィックのワンパスとなります。これにより、すべてのポリシーコントロール、レポート、可視性を単一の統一プラットフォームに集約します。ダイバーシティとフェイルオーバーは、分散したZscalerクラウド、App Connectorグループと冗長性によって提供されます。鍵となるのは、この移行の間、Zscalerが一貫したエンドユーザー体験と、ビジネスで必要とされるポリシーコントロールを提供することです。

Zscalerアプリとブラウザベースのアクセス方法で、社内のすべてのトラフィックをZscalerクラウドに持ち込み、App Connectorを経由してデータセンターやクラウド環境のプライベート・アプリに配信します。これは段階的なアプローチとなるため、Geo-EnterpriseがZscalerでリモートアクセスに対応した後は、Zscalerプラットフォームがサポートする完全なゼロトラスト・アプローチに時間をかけて移行することができます。これには、構内ユーザーだけでなくリモートユーザーも含まれ、最終的にはGeo-EnterpriseがZPAを介してすべてのユーザートラフィックを転送し、アクセスの可視化、制御、および配布を行うことができるようになります。

02 / SDPアーキテクチャを採用するための段階的な旅

フェーズI 初期ユースケース – アクセシビリティを優先する

この旅の第一段階では、Zscalerを活用して安全なアプリケーションアクセスを可能にし、従来のリモートアクセスVPNソリューションであるCisco AnyConnectを置き換えることになります。多くの場合、企業は現在どのアプリにアクセスしているのか、どのユーザーがそのアプリにアクセスしているのかを包括的に把握することができません。いくつかのZPA機能がこのフェーズをサポートしており、混乱を最小限に抑えた初期の可視性を提供しています。

  • 選択的ZPA登録
  • Zscalerアプリと現在のVPNクライアントとの共存
  • 信頼されたネットワーク検出
  • アプリケーション検出
  • ログストリーミング
  • 柔軟なアクセスポリシー
  • カスタム再認証ポリシー
  • 複数のアクセス方法

すでにZscalerアプリを介してZscaler Internet Accessをユーザーに提供している組織では、選択的な登録により、どのZアプリユーザーがZPAに参加するかを完全に制御することができます。ZPAサービスの権限は、特定のグループのユーザーのみに設定できるため、概念実証からパイロットへの移行、ユーザーコミュニティの拡大へのスムーズな移行が可能になります。

Zscalerアプリは、すでにリモートアクセスVPNクライアントがインストールされているエンドポイントに、競合することなくプロビジョニングすることができます。ZPAに登録すると、ユーザーはVPN接続を終了し、通常通りにアプリケーションにアクセスするように指示することができます。設定やアクセスの問題が発生した場合、ユーザーはZPAサービスをオフにしてVPNに再接続することができ、ユーザーコミュニティ全体にZPAが展開されるため、ダウンタイムを最小限に抑えることができます。ZPA 上ですべてのアプリケーションが必要に応じて動作するようになったら、リモートアクセス VPN クライアントをエンドユーザーのデバイスから削除することができます。

ZPA トラフィック転送は、ユーザーが信頼されたネットワーク上にいるか、信頼されていないネットワークにいるかに基づいて制御できます。信頼されたネットワーク検出は、さまざまなネットワーク基準を活用できます。一般的な初期設定では、ユーザーがネットワーク外にいるときは ZPA がトラフィックを転送し、ユーザーがネットワーク上にいるときはバイパスするようにして、既存のリモートアクセス VPN の動作をミラーリングしています。

ZPAアプリケーションディスカバリは、社内アプリケーションのためのクラウドアクセスセキュリティブローカー(CASB)として機能し、管理者はパブリッククラウド(またはデータセンター)で実行されているこれまで知られていなかったアプリケーション(シャドーIT)を発見し、それらのアプリケーションに対して粒度の高いアクセス制御を適用してリスクを最小限に抑えることができます。チームは、リモートアクセスVPNのオープン接続と同様に、アプリケーションドメインまたはサブドメイン全体、およびIPアドレスの範囲へのアクセスを許可することで、初期のアクセスポリシーを大まかに開始します。ユーザーが特定のリソースにアクセスすると、それらのリソースは検出されたアプリケーションデータベースにキャプチャされ、アクセスの詳細(どのアプリ、どのユーザー、環境のどこにいるか)がログに記録され、syslog を介してバックエンドの SIEM やログ相関システムにストリーム配信して可視化とレポートを作成することができます。発見されたアプリデータベースと詳細なユーザーアクティビティログは、より詳細なアプリ中心のアクセスポリシーを開発するための基盤を提供します。

重要なアプリケーションによっては、最初の検出段階であっても、許可されたユーザーのみがアクセスできるようにするために、より厳格なアクセス制御が必要な場合があります。これらのアプリケーションは、アプリケーションの検出と並行して定義し、きめ細かいアクセス ポリシーを適用することで、適切なデバイス上の許可されたユーザーのみが初日からこれらのアプリケーションにアクセスできるようにすることができます。

Active Directory ドメイン・サービスなどの主要なインフラストラクチャ・サービスについては、標準の再認証ポリシーの適用除外を行うことで、ユーザが常にドメイン・コントローラにアクセスできるようにし、分散ファイル共有(DFS)、統合 Windows 認証(IWA)、および内部の Kerberos SSO へのシームレスなアクセスを保証します。

Webアプリケーションやその他のクライアントからサーバへのTCPおよびUDPアクセスを必要とするユーザーのために、Zscaler Appはシームレスで透過的なアプリケーションへのアクセスを提供し、オンプレミスでもリモートでも一貫したユーザー体験を提供します。Web ブラウザ経由でアクセスできる HTTP/HTTPS アプリケーションのみにアクセスする必要があるユーザーに対して、ブラウザベースのアクセスは、ユーザーのエンドポイントにソフトウェアをインストールすることなく、アプリケーションに簡単にアクセスすることができます。

ZPAサービスが本番環境に導入されると、プライベート・アプリケーションへのすべてのリモートアクセストラフィックの流れがZscalerによって促進され、エンドユーザーの生産性と管理者の可視性が向上します。これにより、Geo-Enterpriseはグローバルにすべてのリモートアクセストラフィックを統合的に見ることができるようになります。また、データセンターとクラウド環境間のバックホールトラフィックを大幅に削減し、ポリシーを統一的に制御できるようになります。

この段階が完了すると、Geo-Enterprise は現在使用されているプライベート・アプリケーションの豊富な可視性を得ることができ、エンドユーザーのアクティビティを分析したり、重要なアプリケーションへのきめ細かなアクセス制御を可能にします。アプリのトラフィックが最初のユーザーグループのために完全にZscalerに移行されたら、次のステップはユースケース/ユーザーコミュニティを拡大し、より詳細なアクセスポリシーの開発を継続することです。

フェーズ II 初期ユースケース – クラウドアクセスの実現

ZscalerサービスがGeo-Enterprise内の主要なアプリロケーション内で本番環境に入ると、ZPAはAzureおよびAWSベースのロケーション上のすべてのプライベート・アプリへのアクセスを簡単に有効にすることができるようになります(ZPAはWebアプリのみに限定されません)。これは、Geo-Enterpriseアーキテクチャに応じて、必要なMicrosoft Azureリージョンまたはリソースグループ内でZPAコネクタを展開することで実現できます。ZPAのデフォルト機能を活用することで、アプリケーションアクセスは、ユーザーからアプリケーションへの最も直接的なパスを動的に見つけ出し、利用可能なコネクタを経由してAzureとAWSのアクセストラフィックを誘導します。

 

フェーズIII 初期のユースケース – すべてのユーザーを追加し、ローカルネットワークを排除する

Zscalerサービスが運用され、アプリケーショントラフィックがZPAを介してこれらのユーザーに運ばれるようになったら、次のフェーズでは、オープンなワイルドカードアクセスから、より粒度の高い、アプリケーション固有のアクセスポリシーに移行します。これは、重要なアプリケーションを特定し、現在誰がそれらのアプリケーションにアクセスしているかを判断し、アプリケーションへのアクセスを制御するためのアプリケーション固有のポリシーを構築することで実現できます。これらのアプリケーション固有のポリシーは、アプリケーションの検出と共存させることができ、オープンアクセスからマイクロセグメント化されたアクセスへの段階的な移行を可能にします。

  • この移行プロセスの主なステップは以下の通りです。
  • 検出されたアプリのレビューと優先度によるソート
  • 重要なアプリの診断ログを確認し、どのユーザーがどのアプリにアクセスしているかを特定する
  • アプリ中心、ユーザー中心、または混合型のポリシーアプローチを特定する
  • 重要なアプリケーションのための粒度の高いアクセスポリシーを作成する
  • デバイスの体制がアクセスポリシーの必須要素であるかどうかを判断する
  • 残りの既知のアプリケーションについて、処理を繰り返す
  • 未知のアプリケーションをレビューして優先順位を決定する
  • 幅広い接続性を維持するかどうかを判断する

Discovered Applications のダッシュボードには、ZPA インスタンスの使用期間中にユーザーがアクセスしたすべてのアプリケーシ ョンの累積リストが表示されます。オープンアクセスから粒度の高いポリシ ーへの移行プロセスを開始するための最初のステップとして、このアプリケーションのリストを確認し、既知のアプリをクリティカル、中程度、または低優先度に分類します。

アプリケーションを優先度で分類したら、ユーザーアクティビティの診断ログを使って、どのユーザーがどのアプリケーションにアクセスしているかのレポートを作成することができます。これらのユーザーリストを既存のユーザー属性(グループのメンバーシップ、役割、組織など)にマッピングしたり、新しい属性を定義して、特定のユーザーコミュニティのためのきめ細かいポリシー作成を可能にしたりすることができます。

粒度の細かいアクセスポリシーを定義する際には、概念的なセキュリティポリシーを、サブジェクトとオブジェクトを持つステートメントと考えると便利です。ユーザーとアプリは、サブジェクトとオブジェクトのどちらかになることもあれば、その逆もあります。ユーザー中心のポリシーでは、ユーザーを対象とし、そのユーザーコミュニティがアクセスを許可されている(または許可されていない)アプリケーションを特定します。アプリ中心のポリシーでは、アプリケーションを対象とし、どのようなユーザーコミュニティがアクセスを許可されているか、または許可されていないかを特定します。既存のユーザーアクセスを見直してみると、ほとんどの組織では、範囲の狭いユーザーコミュニティ(サードパーティのアクセスなど)に対するユーザー中心のポリシーと、アクセス要件が明確に定義されたリソース(PCI データへのアクセスに対する規制への準拠など)に対するアプリ中心のポリシーを組み合わせた、最も柔軟なアプローチが採用されていることがわかります。

これらの概念的なセキュリティポリシーは、単一のSAML属性をアプリケーション/アプリケーショングループにマッピングするか、複数のSAML属性を単一のアプリケーション/アプリケーショングループにマッピングすることで、ZPAアクセスポリシーで表現することができます。ユーザー中心のポリシーの例としては、 契約者グループを特定のアプリケーションまたはアプリケーションのセットにマッピングする ZPA アクセス ポリシーがあります。アプリ中心のポリシーの例としては、複数の従業員の役割を SAP などの内部リソースにマッピングする ZPA アクセス ポリシーがあります。粒度の細かいアクセスポリシーは、一般的な接続性ポリシーの上に構築され、様々なアプリケーション間でアクセス要件を徐々に厳しくすることができるようにするべきです。

詳細なアクセスポリシーを定義する際には、ユーザー属性に加えてデバイスの姿勢属性も考慮することができます。ZPA の姿勢プロファイルを使用すると、管理者は、ユーザーのデバイスが管理されているか管理されていないか、管理されているデバイスの場合は、そのデバイスが企業の資産か個人のデバイスかに基づいて、アプリケーションへのアクセスを制限することができます。姿勢プロファイルのテストには、ドライブが暗号化されているかどうか、信頼できるクライアント証明書があるかどうか、デバイスがジェイルブレイクされているかどうかなどの確認が含まれます。これらは、アプリケーションに広く適用されることもあれば、アプリケーションにアクセスする特定のユーザーコミュニティに狭く適用されることもあります。

重要なアプリケーションと主要なユーザーコミュニティに対応するために粒度の細かいポリシーを作成したら、次のステップとして、残りの既知のアプリケーションのレビューとポリシー定義のプロセスを繰り返すのが一般的です。ユーザー固有およびアプリ固有のアクセスポリシーセットが拡大し続けるにつれて、一般的な接続ポリシーを介して許可されるトラフィックはますます少なくなります。

すべての既知のアプリケーションに対して粒度の細かいポリシーが開発された後、未知のアプリケーションは、同じプロセスに従ってレビューされ、アプリケーションが正当なものであるかどうかを判断し、正当なものである場合には誰がアクセスできるようにすべきかを判断することができます。

最終的に、すべてのトラフィックが特性化されると、すべてのアプリケーションへの一般的なアクセスを許可するアクセスポリシーを維持するか(すなわち、禁止されていないものはすべて許可される)、定義されていないアプリケーションへのアクセスをブロックするように変更するか(すなわち、許可されていないものはすべて禁止される)を決定することができます。

結論

クラウドへの移行に伴い、ネットワークインフラは変化しなければなりません。世界中のあらゆる業界のあらゆる規模の企業は、マルチクラウドやハイブリッド・クラウドという新しい環境をナビゲートしながら、クラウド導入を断念させる可能性のある共通のミスを回避しなければなりません。また、クラウドの導入がセキュリティ機能を上回ることがないようにしなければなりません。これらはいずれも、一人で抱え込むべき課題ではありません。この白書では、これらのクラウド導入プロジェクトにどのようにアプローチするかについて、いくつかのガイダンスを提供しました。しかし、それだけではありません。

そのため、Zscalerはクラウドファーストのネットワークプロジェクトに取り組むアーキテクトのためのコミュニティを開発しました。Cloud-First Architectは、クラウド・インフラを活用したネットワークを設計するために必要なスキルをアーキテクトが身につけるために、さまざまな技術的なトピックについて議論する対話型のコミュニティです。ブログを読んでCloud-First Architectプログラムの詳細を確認した後、コミュニティに参加してベストプラクティスを発見したり、クラウドを最大限に活用するための仮想ワークショップに深く潜ったりしてください。

コメント

タイトルとURLをコピーしました