ゼロトラストネットワークアクセス(ZTNA)の採用・実現ガイド

プライベートアプリケーションがクラウドに移行し、ユーザーがリモートで作業するようになると、企業は、摩擦のないユーザー体験を提供しながら、プライベート・アプリケーションへの安全なアクセスを保証するサービスを必要とします。ゼロトラスト・セキュリティが話題になっていますが、一部の企業では、ネットワークへのアクセスのために構築された次世代ファイアウォールに依存する現行のネットワーク中心のアーキテクチャを、アプリケーションへのユーザー接続を制限する方法として使用しようとしています。これらの現存するアーキテクチャは、今日のニーズとのミスマッチであり、承認されたユーザーを特定のアプリに接続するようには設計されていませんでした。これらのアプリはユーザーをネット上に強制的に配置し、他のアプリへの横移動のリスクや、ネットワークの端に座って受信pingを聞くVPNコンセントレータを介してインターネットDDoS攻撃にさらされたIPアドレスにつながることがよくあります。

多くの企業が、VPNの代替としてゼロトラストネットワークアクセス(ZTNA)サービスを検討しています。実際、Gartner社は、2021年までに60%の企業が既存のVPNからZTNAサービスに移行すると考えています。しかし、現実には、どんな大規模な(グローバルな)組織でも、ユーザーがアプリケーションにアクセスする方法を少し変えるだけでも、大きな課題になることがあります。この文書では、ビジネスを中断することなく、迅速にZTNAを導入できるように、どこから始めればよいのかを理解することができます。

このガイドでは、以下の内容を説明します。

  • 現行のアクセス技術とZTNAのアーキテクチャの違い
  • ZTNAを展開するためのリファレンス・アーキテクチャを見る
  • 社内にZTNAを導入する際に考慮すべき3つのフェーズ
  • ZTNAの導入を最大限に活用するためのアドバイスと考慮すべき点

このブログでは、ゼロトラストネットワークアクセス(ZTNA)サービスの概要を説明しています。

今や、ネットワーク上に配置することなく、許可されたユーザーを特定のプライベート・アプリケーションに接続する手段として、ZTNAアーキテクチャを探求する時が来ました。

今日はどこにいるの?- 企業内VPNを見てみる

多くの組織で非常に共通していることがわかっているアーキテクチャは、この高レベルのダイアグラムに描かれています。そうです、データセンター、ルーター、ファイアウォール、VPNコンセントレータ、MPLSネットワークの数と場所は図と同じではないと思いますが、コンポーネントの詳細な描写を提供してくれると信じています。インラインプロキシ、サンドボックス、L7ファイアウォール、AVやDLPソリューションなど、組織が導入しているネットワークやセキュリティデバイスは他にもたくさんあります。シンプルにするために、私は、インターネット上のセキュリティ概念全体を、図の中のセキュリティ・スタックとして統合しました。

 

この手の伝統的なアーキテクチャの中で、私の好きな点がいくつかあります。

  1. リモートユーザーはデータセンターのいずれかにVPNをかけ、企業ネットワーク上に配置されます。多くの組織での私の経験では、ネットワークは比較的フラットで、ACLはかなり限られており、したがって、各リモートユーザーに企業のデータセンターのインフラストラクチャとネットワークのすべてを公開しています。
  2. リモートユーザーは、組織が所有している(ハードウェア)セキュリティスタックを使用しての検査のためのデータセンターへのすべてのインターネットバウンドトラフィックのバックホールがあります。これはフルトンネルVPNとして知られています。企業ネットワークから離れていてもユーザーの安全を確保する必要があるセキュリティチームには理想的ですが、すべてのインターネット/SaaSアプリケーションがローカルにアクセスする代わりにバックホールされると、ユーザー体験に悪影響を及ぼす可能性があります。現在、多くのユーザーは、いくつかの企業WANパイプよりも高速なホームブロードバンドインターネット接続を持っています(テネシー州のやや田舎でも、私は私のISPを介して1Gbpsのファイバー接続を持っています)!
  3. 内部ユーザーは通常、物理ネットワークでも無線ネットワークでも、デバイス/ユーザー・ネットワーク上にいますが、すべてのデータセンター・ネットワークは伝統的に「信頼された」ネットワークであるため、一般的にはルーティング/接続が可能です。内部のアプリケーションへのアクセスはLANを介してルーティングされ、インターネット/SaaSアプリケーションは、ISPに侵入する前にセキュリティスタックを通過します。この状況の問題は、ネットワークを「所有」して制御しているからといって、そのネットワーク上のすべてのユーザーやデバイスを自動的に信頼すべきだという誤った思い込みです。

リモートアクセスに必要なインターネット(VPN)からのインバウンドアクセスと、社内ユーザーがIDに関係なくすべてのアプリケーションサーバーと直接通信できることに注意してください。

リスクを増やさずに内部アプリへのアクセスを提供するためのリファレンス・アーキテクチャ

ソフトウェア定義アーキテクチャの最終目標は、アプリケーションアクセスをネットワークアクセスから切り離すことです。ユーザーをネットワーク上に配置する必要がなくなり、プライベート・アプリケーションは許可されたユーザーのみがアクセスできるようになり、IPアドレスがインターネットにさらされることはなく、ネットワークセグメント、FWポリシー、ACLの管理の複雑さがなくなります。次の図は、最終的な結果を簡略化したものです。

この新しいソフトウェア定義アーキテクチャでは、データセンター/アプリケーションネットワーク、リモートユーザー、内部ユーザーが明確に分離されていることに気づくでしょう。あなたの組織が、米国を拠点とするデータセンターを2つだけ持っていても、グローバルなデータセンターを10数カ所持っていても、Azure/AWS/GCP環境をいくつか持っていても、結果は非常に分かりやすいものです。

  1. MPLSやサイト間VPNなどのプライベート・ネットワークは、サーバー間通信が必要なデータセンターとCloud IaaS環境間でのみ必要となるはずです。組織がWWWサイトのWeb層をAWSに移行したものの、バックエンドのSQLデータベースがまだ物理的なデータセンターにある場合、これらの場所間のプライベート接続(低遅延、高帯域幅)が必要となります。
  2. リモートアクセスは、vpn.company.comのようなユーザーのためのインバウンド接続を必要としなくなりました! このアーキテクチャは、オーケストレーション(制御)プレーンを、ユーザーからの通信が終了するクラウドに置きます。App Connectorsとして知られているゲートウェイは、インバウンドのリスニングポート、つまりパブリックIP/DNSレコードを必要としません。App Connectorsは、TLSを介してSaaSベースのオーケストレーション・プレーンとアウトバウンドで通信します。内部アプリケーションは、ユーザーのIDが確認され、アクセスポリシーと照合された場合にのみ仲介されます。・ユーザーが内部アプリケーション/リソースへのアクセスを許可されている場合、オーケストレーション・プレーンはコネクターとユーザーデバイスの間でアウトバウンドTLS接続をつなぎ合わせます。ただし、このユーザーはネットワーク上に配置されていないため、DNSベースのアプリケーションは難読化されており、アプリケーション・サーバーの真のプライベートIPアドレスはユーザーデバイスには公開されません。むしろ、クライアントがアクセスしているアプリごとに、合成IPアドレスが動的に作成されます。・ユーザーが内部アプリケーションへのアクセスを許可されていない場合、データセンターに入ってくるネットワーク・トラフィックが発生することはありません。このリクエストはクラウドでブロックされるため、ユーザーが重要なアプリケーション・サーバーの「フロントドア」にアクセスするリスクさえも排除されます。これを見る最も簡単な方法は、サーバへのSSHやRDPセッションを確立する前に、クラウドでユーザを遮断することです。たとえユーザが SSH/RDP セッションを認証できない可能性が高いとしても (ブルートフォースや盗まれた認証情報は別として)、このアーキテクチャはこのリスクを排除しています。一番の利点は?  これらの各試行はログに記録されるため、セキュリティ組織はユーザーが何をしようとしているのかを事前に(そして事後的に)監視できます。 1つの例として、すべてのログをSplunkなどのSIEMに送信し、ユーザーが同じサーバー/ポートでX分間にX数のブロックされたポリシーを生成した場合にアラートを作成します。たとえば、5分間にsap.company.comに20回SSHで接続しようとします。ユーザーがポリシーでブロックされている場合は安全で、ユーザーのデバイスが危険にさらされていないか、あるいはユーザーが悪意を持っているかどうかを確認するために、積極的に手を差し伸べることができます。ユーザーがポリシーによってブロックされなかった場合、SSHセッションは仲介されたはずですが、サーバーは誤った資格情報を拒否していました。このユーザーは承認されましたが、管理者(root)パスワードを忘れました!
  3. すべてのユーザーネットワークは、インターネットカフェまたはゲストWi-Fiネットワークとして扱われるべきです。ユーザーが本社のメインキャンパスにいようが、支社にいようが、製造工場にいようが、あるいは単に移動中であろうが、ユーザーがアプリケーション・サーバーやデータセンターを探索/経路探索できるネットワーク上にユーザーを置く理由があってはなりません。支店サイトによっては、ユーザーからアプリへのアクセス以外の要件がある場合があることに注意が必要です。その場合でも、IoTデバイスやサーバー間通信タイプの通信には、プライベートネットワークの接続性が必要になります。しかし、そのような要求があったとしても、これらのネットワークをユーザネットワークから分離するのが最善です。
  4. インターネットアクセス、別名「セキュリティスタック」もまた、最高のセキュリティとユーザー体験を可能にするために近代化されるべきです。ユーザーをネットワークから切り離す際には、検査のために中央のデータセンターにインターネットトラフィックを送るのではなく、ユーザーから直接インターネットトラフィックを送ることを検討すべきです。支店の場合は、既存のルータ、ファイアウォール、SD-WANデバイスを使用して、すべてのインターネット経由のトラフィックをクラウドセキュリティソリューションに誘導するだけで簡単です。

ZTNAアーキテクチャの採用を可能にする3つのフェーズ

建築家はしばしば「始めるための最良の方法は何ですか?」と尋ねます。私のお気に入りの答えの1つは「それは依存する」です。特定のニーズ、要件、構成に基づいて達成できる多くの結果があるので、多くのエンジニアや建築家がこれに関係することができることを知っています。しかし、この旅において組織にベストプラクティスの推奨事項を提供することは私たちの責任です。これは、このセクションで説明する段階的な旅のアプローチが、各組織が従わなければならない具体的な一連のステップではないという私の通知です。これは、現在の要件を満たすために多くのエンゲージメントで見つかった高レベルのアプローチですが、同時に、組織がゼロトラストネットワークの概念を採用できるようにします。管理者が設定したコンテキストポリシー(ユーザー、デバイス、サービスなど)に基づいて、信頼が暗示されることはなく、アクセスに適応します。

このアプローチは、ほとんど小さな一歩です。リモート・ユーザーから始めてセグメントを開発し、次にZTNAを活用して、場所に関係なくすべてのユーザーがプライベート・アプリにアクセスできるようにします。ユーザーがアプリケーションやサービスにアクセスする方法、ロケーション(データセンター、Cloud IaaS環境、従業員が勤務する物理的なロケーション)の分布(数量と種類)、プロジェクトベースのタイムラインを考慮する必要があります。多くの場合、VPN の更新は、現在の VPN と同じ課題をもたらす次世代 VPN や「常時接続」の VPN を購入するのではなく、ZTNA を採用するためのきっかけになるかもしれません。

フェーズ 1 リモート アクセスとアプリケーション ディスカバリのための ZTNA の導入

このフェーズでは、既存のリモートアクセス VPN ソリューションを置き換えることから始めます。そのためには、現在のリモートアクセス VPN と同様のアクセスレベルの ZTNA を導入する必要があるかもしれません。これは、新しいイニシアチブがリモートユーザーの生産性を阻害するものと見なされないようにするために重要なことです。

また、攻撃対象を減らし、Shadow IT を根絶するために、環境で実行されているプライベート・アプリを理解する必要があります。あなたが現在認識しているアプリよりもはるかに多くのアプリが存在する可能性があります。すぐれたソリューションは、アプリケーション・ディスカバリー機能でこれを解決します。各ユーザーがアクセスする必要のあるすべての内部アプリケーション/サービスを知ることは不可能なので、Application Discoveryでは、*.company.com、*.company.net、すべてのTCPおよびUDPポートなど、基本的にワイルドカードを使用することができます。

ユーザーがサービスに正常に登録されると、クライアントは、ユーザーが企業ネットワーク上にいなくなったことを自動的に検出し、ユーザーがネットワーク外にいる場合は、すべての内部アプリケーションがZTNAを介して流れるようになります。VPN クライアントを起動する必要がなくなり、ユーザーは以前と同じように内部リソースにアクセスすることができます。これらのアクセスログはすべて管理コンソールに表示され、選択したSIEMにほぼリアルタイムでストリーミングすることができるため、ユーザーがアクセスしているアプリケーションの詳細な可視性を確保することができます。

 

内部のプライベート・ネットワーク(MPLS、サイト間 VPN)がまだ存在する可能性が高いため、ユーザが企業ネットワークに戻ってくると、クライアントコネクタは自動的にオフにします。

フェーズ 2 マイクロセグメンテーションを活用して、最小特権の接続性を確保する

このフェーズでは、プライベート・アプリケーションをセグメントに分割するポリシーを定義し、ユーザー ID 属性を介してセグメントへのアクセスを提供する必要があります。

大規模な組織では、何百、何千ものユニークなアプリケーションやサービスがあるかもしれないので、多くの組織では、TCP 22 (SSH) や TCP/UDP 3389 (RDP) などの管理ポートをセグメント化して、IT ユーザーのためだけにこれらのポートへのアクセスをグローバルに提供することから始めたいと考えているかもしれません。もちろん、ワンオフの要件は常に存在しますが、このセグメンテーションは、アクセスできないはずのサーバーに接続するユーザーの表面を減らすのに役立ちます。例えば、営業担当者は、SAPアプリケーションをホストしているWindowsサーバ上のTCP 3389に到達できない可能性が高いです。フロントエンドのウェブ部分だけを取得する必要があり、同じサーバーになりますが、ポートはTCP 80/443です。

 

理想的には、ドメインコントローラー/サービス、セキュリティソフトウェアクライアント、ソフトウェア展開クライアントなどのインフラストラクチャサーバーで、これらは、ホストがよく知られているため、簡単にセグメント化できます。

アプリのセグメンテーションは現在進行中のプロセスであり、一般的な推奨事項としては、ビジネスにとって最も重要で、既知のユーザータイプのみがアクセスできるアプリに優先順位をつけることが挙げられます。

アプリケーションをセグメント化すると、それらはアプリケーション発見の「プール」から削除されます。これは、ユーザーが明示的に定義していないドメイン内のアプリケーションにもアクセスできるようにするだけでなく、必要とされるサービスポートで既知のアプリケーションにもアクセスできるようにするために、混在させることができることを意味します。

注意:インターネットのセキュリティを忘れずに

このガイドではプライベート・アプリケーションに焦点を当てていますが、インターネットに接続するすべてのトラフィックに対してもセキュリティスタックを提供することが同様に重要であることを認識することが重要です。多くの組織は、アプライアンスや仮想アプライアンス(ファイアウォールなど)に頼るのではなく、完全にクラウドベースの、より近代的なインバウンドとアウトバウンドのセキュリティスタックを模索しています。

フェーズ3  すべてのユーザーがプライベートアプリにアクセスできるZTNA (リモートに限らず)

これで最終段階への準備が整いました。これは、プライベート・アプリケーションへのすべてのアクセスが、デフォルトでは明示的な最低特権接続のみを有効にする正確な設定に基づいて行われることを意味します。

セッションごとにスピンアップされ、認証されたユーザーと特定のプライベート・アプリの間に1つのセキュアなセグメントを作成するTLS二重暗号化されたマイクロトンネルを介したインサイドアウト接続を提供します。

先ほど、Client Connectorが企業ネットワークを検出する方法についてお話しましたが、覚えている方も多いのではないでしょうか? つまり、各アプリケーションセグメントは、(1) 企業ネットワーク上でバイパスする、(2) 常にバイパスする、(3) バイパスしない、のいずれかの構成オプションを持っています。フェーズ1ではオプション1を使用してアプリセグメントを展開しましたが、リモートユーザーだけでなく、すべてのユーザーからの安全なアクセスについてはどうでしょうか? これを行うには、アプリケーション・セグメントを切り替えるだけで、バイパスしないようにすることができます。つまり、ユーザーが物理的なオフィスにいる場合でも、内部リソースへのすべてのアクセスは、この明示的な信頼アーキテクチャソリューションを介して仲介され、LAN上でデータセンターのアプリケーションサーバーに直接ルーティングされることはありません。

 

簡単でしょ? そうですね、このスイッチに関わる課題は、プラットフォーム自体の外に残ると思います。最終的な目標は、通常、すべてのユーザーネットワークからアプリケーションサーバー/データセンターネットワークを完全に削除することです。これは、支店や製造工場などからデータセンターへの接続がないことを意味します(明確にするために、これらの場所のユーザネットワークからの接続がないことを意味します)。

最終的な考えとプロのアドバイス

まだネットワークに接続されていない小さなオフィスから始めるのが一番簡単かもしれません。そのオフィスをブロードバンドインターネット接続だけで開設します。インターネットに接続されたすべてのトラフィックをクラウド・セキュリティ・プラットフォームに移動させ、プライベート・アプリケーションのトラフィックをプラットフォームを経由して流すようにします。

インターネットカフェを開くように、新しいオフィスを扱います。繰り返しになりますが、今日では、ユーザーがアプリケーションにこの接続を提供できることに注意してください。センサー、IoTデバイス、サーバーを備えた製造工場などの一部の場所では、引き続きプライベートMPLSまたはVPNを介してデータセンターと通信する必要があります。これらのロケーションネットワークをデータセンターとして扱い、そこからユーザーを遠隔操作するだけで、すべてのユーザーは「ゲストWi-Fi」になり、内部アプリへのアクセスは許可されたユーザーに仲介されます。

最終的には、ZTNA アーキテクチャには多くの興奮と話題がありますが、本当の目標は、プライベートアプリになると必要なセキュリティを備えたユーザーが望む体験を提供することです。あなたの組織がこの新しい方法を採用するには時間がかかりますが、ネットワーク・アーキテクトであるあなたは、それを可能にする基礎(プラットフォーム)を築くことができます。

コメント

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