Ancrage de l'IP source pour un IdP avec Netskope Private Access

Background

De nombreuses organisations ont utilisé la liste des adresses IP autorisées sur leurs applications d'entreprise en nuage afin de garantir une sécurité supplémentaire au cas où les informations d'identification d'un utilisateur seraient compromises par un acteur malveillant. Cette liste d'autorisations comprend toutes les adresses IP de sortie de votre centre de données et de vos bureaux distants. En règle générale, les utilisateurs distants ont besoin d'une connexion VPN pour accéder aux applications privées et aux applications en nuage de l'entreprise.

Avec Netskope, le flux de trafic change lors de l'utilisation de Netskope Client. Comme le site Netskope Client chiffre ses connexions au proxy Netskope, les applications en nuage et les fournisseurs d'IdP ne voient plus les adresses IP de sortie de l'entreprise et voient à la place les adresses IP des POP de Netskope.

La solution préférée consiste à ajouter les adresses IP POP de Netskope à votre liste d'adresses IP autorisées pour l'accès conditionnel et à utiliser l'authentification multifactorielle (MFA) avec votre fournisseur IdP. Si vous ne souhaitez pas utiliser le MFA ou ouvrir l'accès à vos applications en nuage aux plages d'adresses IP POP de Netskope, voici une solution alternative pour préserver vos adresses IP dédiées lorsque vous accédez à des applications SaaS ou à des sites web.

Solution

Supposons que vous utilisiez un fournisseur d'IdP comme Okta et que vous n'ayez qu'un seul centre de données pour l'ensemble de son trafic.

Par défaut, tout le trafic Okta est dirigé vers le proxy Netskope. Cette méthode modifie ce comportement par défaut. Au lieu d'envoyer le trafic Okta via le proxy Netskope, cette méthode définit votre URL Okta comme une application privée à l'intérieur de Netskope Private Access.

Netskope Publisher: Il y a plusieurs possibilités. Vous pouvez déployer un éditeur dans le centre de données de votre entreprise. Tout le trafic de l'éditeur sera vu comme votre adresse IP de sortie existante (1.1.1.1).

Une autre option consiste à déterminer où se trouve votre instance Okta et à déployer un Publisher dans AWS, GCP ou Azure dans une région plus proche de l'instance Okta.

Ouvrez un Terminal/Command Shell et essayez d'envoyer un ping à l'URL de votre locataire :

Vous pouvez voir dans la réponse que ce locataire Okta est situé dans la région US-West-2 à l'intérieur d'AWS. Comme vous êtes basé sur la côte Est, il serait préférable de déployer un éditeur dans la région US-West-2 d'AWS afin que Netskope Security Cloud puisse fournir le chemin le plus optimisé vers Okta, quel que soit l'endroit où se trouve l'utilisateur distant, sans avoir à repasser par le centre de données de la côte Est juste pour aller au centre de données de la côte Ouest pour Okta.

Dans AWS

Accédez à la console AWS.

Déployez l'image AMI de l'éditeur dans la région Ouest d'AWS et notez l'adresse IP publique. La meilleure pratique pour un déploiement de production d'un éditeur est d'utiliser une adresse IP élastique de sorte que si l'éditeur est redémarré, il conservera l'adresse IP à travers les redémarrages.

Dans Netskope

Dans votre locataire Netskope, allez dans Settings > Security Cloud Platform > App Definition, cliquez sur l’onglet Private App Segments , puis cliquez sur New Application Segment. Saisissez les paramètres comme affichés et cliquez Save.

Utilisez ce segment d'application privée dans une politique de protection en temps réel pour Private Access.

Cela va forcer UNIQUEMENT le trafic Okta à être envoyé via l'éditeur NPA. L'adresse IP de l'éditeur est une adresse IP que le client loue auprès d'AWS et qui est accessible à d'autres clients à l'adresse not shared.

Lors d'une connexion réussie à l'application en nuage, tout le trafic de l'application en nuage sera envoyé de l'adresse Netskope Client directement au proxy Netskope.

In Okta

Dans l'interface d'administration d'Okta, assurez-vous de n'autoriser que l'adresse IP de sortie de votre centre de données d'entreprise (1.1.1.1). et l'adresse IP de l'éditeur NPA (54.193.39.10). Ce sont les seules adresses IP sources à partir desquelles votre locataire Okta autorisera une connexion réussie (même si des acteurs malveillants présents sur le réseau Netskope ont compromis leurs identifiants).

Dans les applications en nuage

Vous devez toujours autoriser les adresses IP POP de Netskope ainsi que les adresses IP de sortie de votre entreprise.

Vous trouverez ci-dessous une approche progressive pour autoriser les applications avec les plages IP de Netskope.

Summary

Avec la configuration ci-dessus, si un acteur malveillant obtient des informations d'identification compromises et que je suis également un utilisateur de Netskope Security Cloud, lorsqu'il tente d'accéder à l'une de vos applications cloud d'entreprise, l'authentification sera redirigée vers Okta, mais comme la demande d'authentification ne provient PAS de votre éditeur ou de l'adresse IP de sortie de l'entreprise, la tentative de connexion échouera, même avec des informations d'identification valides.

Cette approche progressive a été déployée par des utilisateurs qui ont inscrit sur leur liste d'adresses IP environ 120 applications SaaS.

Phase 1: Contournez toutes vos 120 applications sanctionnées dans Netskope. Ne pilotez pas les applications tant que vous n'avez pas autorisé les plages IP de Netskope dans chaque application SaaS.  Si vous utilisez Netskope Secure Web Gateway à la place de votre SWG actuel, vous bénéficierez d'une visibilité immédiate sur ~2300 applications en nuage non approuvées, ainsi que sur l'ensemble du trafic de votre site web.

Phase 2: Ajoutez les plages d'adresses IP de Netskope à vos applications sanctionnées.  Il n'est pas nécessaire de le faire en une seule fois - vous pouvez ajouter nos gammes par lots.

Phase 3: Lorsque vous autorisez les plages d'IP Netskope à vos applications SaaS, ajoutez les applications SaaS sanctionnées à la configuration de pilotage Netskope afin qu'elles passent par le réseau NewEdge pour la visibilité, le contrôle, la prévention des pertes de données (DLP), la détection des menaces, etc.  Note - nous avons acheté un réseau /17 afin d'avoir suffisamment de place pour les futurs POP que nous ajouterons dans le monde entier.  Une fois que vous avez ajouté nos plages, vous ne devriez plus avoir à les ajuster en raison de l'espace IP public dont nous disposons. Continuez jusqu'à ce que toutes vos 120 applications SaaS aient les plages IP de Netskope ajoutées à leur liste autorisée.