Netskope Private Accessを使用したIdPのソースIPアンカー

Background

多くの組織は、ユーザーのクレデンシャルが悪意のある攻撃者によって侵害された場合に追加のセキュリティを確保するために、自社のクラウド アプリで IP アドレスのホワイトリストを利用しています。 この許可リストには、データセンターおよびリモートオフィスのすべての送信元IPアドレスが含まれます。通常、リモートユーザーの場合、プライベートアプリケーションと企業クラウドアプリケーションの両方にアクセスするには、VPN接続が必要です。

Netskopeでは、 Netskope Client使用するとトラフィックの流れが変わります。 Netskope Client Netskopeプロキシへの接続により、クラウドアプリケーションとIdPプロバイダーは企業の送信IPアドレスを認識せず、代わりにNetskopeのPOPのIPアドレスを認識するようになります。

推奨される解決策は、NetskopeのPOP IPアドレスを条件付きアクセス用のIPアドレス許可リストに追加し、IDプロバイダー（IdP）で多要素認証（MFA）を導入することです。したくない場合 MFA を使用したり、 Netskopeの POP IP アドレス範囲にクラウド アプリケーションへのアクセスを許可したりしたくない場合は、 SaaSアプリケーションや Web サイトにアクセスする際に専用 IP アドレスを維持するための代替ソリューションとして、以下が挙げられます。

解決

あなたが OktaのようなIdPプロバイダーであり、すべてのトラフィックに対してデータセンターが1つしかないと仮定しましょう。

デフォルトでは、OktaのすべてのトラフィックはNetskopeプロキシに転送されます。このメソッドは、このデフォルトの動作を変更します。この方法では、OktaのトラフィックをNetskopeプロキシ経由で送信する代わりに、OktaのURLをNetskope Private Access内のプライベートアプリケーションとして定義します。

Netskope Publisherいくつか選択肢があります。既存の企業データセンター内にパブリッシャーを導入することも可能です。パブリッシャーからのすべてのトラフィックは、既存の送信元IPアドレス（1.1.1.1）として認識されます。

別の方法としては、Oktaインスタンスの設置場所を特定し、Oktaインスタンスに近いリージョン内のAWS、GCP、またはAzureにパブリッシャーをデプロイする方法があります。

ターミナル/コマンドシェルを開き、テナントURLにpingを試してみてください。

応答を見ると、この Okta テナントは AWS 内の US-West-2 リージョンに配置されていることがわかります。お客様は東海岸に拠点を置いているため、AWSのUS-West-2リージョンにパブリッシャーをデプロイすることをお勧めします。そうすることで、Netskope Security Cloudは、リモートユーザーの所在地に関わらず、Oktaへの最適なパスを提供できます。Oktaのために西海岸のデータセンターにアクセスするためだけに、東海岸のデータセンターにルーティングする必要がなくなります。

AWSでは

AWSコンソールにアクセスしてください。

パブリッシャーAMIイメージをAWSの西リージョンにデプロイし、パブリックIPアドレスをメモしておきます。パブリッシャーの本番環境へのデプロイにおけるベストプラクティスは パブリッシャーが再起動されてもIPアドレスが維持されるように、伸縮自在なIPアドレスを使用することです。

Netskopeでは

Netskopeテナントで、 Settings > Security Cloud Platform > App Definitionに移動し、 Private App Segmentsタブをクリックして、 New Application Segmentをクリックします。表示されているパラメータを入力し、 Saveをクリックします。

このプライベート アプリ セグメントは、 Private Accessのリアルタイム保護ポリシーで使用します。

これにより、OktaトラフィックのみがNPAパブリッシャー経由で送信されるようになります。パブリッシャーIPアドレスは、顧客がAWSからレンタルしているIPアドレスであり、他の顧客からはnot shared認識されます。

クラウドアプリケーションへのログインが成功すると、クラウドアプリのすべてのトラフィックはNetskope Clientから直接Netskopeプロキシに送信されます。

In Okta

Okta管理では、企業データセンターの出口IPアドレス(1.1.1.1)のみをIP許可リストにしてくださいNPAのパブリッシャーIPアドレス(54.193.39.10)です。これらは、Okta テナントがログインを許可する唯一の送信元 IP アドレスです (悪意のある攻撃者がNetskopeのネットワークを侵害した場合でも)。

クラウドアプリケーションにおいて

NetskopeのPOP IPアドレスと、自社の送信元IPアドレスの両方を許可する必要があります。

NetskopeのIPアドレス範囲を持つアプリを許可リストに追加するための段階的なアプローチの概要を以下に示します。

Summary

上記の構成では、悪意のある攻撃者が何らかの方法で侵害されたクレデンシャルを入手し、かつNetskope Security Cloudのユーザーである場合、企業のクラウドアプリケーションのいずれかにアクセスしようとすると、認証はOktaにリダイレクトされますが、認証要求がパブリッシャーまたは企業の送信元IPアドレスから送信されていないため、有効なクレデンシャルを使用してもログイン試行は失敗します。

この段階的なアプローチは、約120のSaaSアプリケーションをIPアドレスの許可リストに登録しているユーザーによって導入されています。

Phase 1Netskopeの 120 個のアプリすべてをバイパスします。 各SaaSアプリでNetskopeのIPアドレス範囲を許可リストに追加するまでは、アプリを操作しないでください。既存の SWG の代わりにNetskope Secure ウェブ ゲートウェイを使用すると、最大 2,300 の未承認のクラウド アプリケーションとすべてのウェブ サイトのトラフィックを即座に可視化できるようになります。

Phase 2: Netskope IP 範囲を許可されたアプリに追加します。 一度にすべて追加する必要はありません。当社の製品範囲を複数回に分けて追加することも可能です。

Phase 3Netskope IP 範囲をSaaSアプリの許可リストに追加したら、 SaaSアプリをNetskopeステアリング設定に再度追加して、可視化、制御、DLP、脅威検出などのためにNewEdgeネットワークを経由するようにします。 注：当社は/17ネットワークを購入したため、今後世界各地に追加していくPOP（接続拠点）のための十分な容量を確保しています。弊社のIPアドレス範囲を追加すれば、弊社が保有するパブリックIPアドレス空間のおかげで、再度調整する必要はありません。120個のSaaSアプリすべてにNetskopeのIPアドレス範囲が許可されたリストに追加されるまで、この手順を続けてください。