Meilleures pratiques en matière d'accès privé

Cette section présente les meilleures pratiques recommandées pour la gestion des efforts de récupération et de migration de Netskope Private Access (NPA) Publisher.

L'éditeur, tel qu'il est déployé, ne contient pas d'informations sensibles ou persistantes qui doivent être maintenues et préservées séparément en dehors du plan de gestion. Pour être connecté au locataire Netskope, un éditeur doit être enregistré avec un code d'enregistrement unique.

Il peut arriver que vous soyez confronté à la nécessité de reconstruire ou de récupérer l'éditeur. Voici quelques-unes de ces situations :

En raison de la nature de l'architecture et de la configuration des éditeurs, il n'est pas utile d'essayer de récupérer les images existantes de l'éditeur, mais plutôt de déployer une image de l'éditeur New et de l'enregistrer sous la même définition de l'éditeur. Nous vous recommandons, en cas de panne ou de perte d'accès à l'éditeur, de procéder comme suit :

Après avoir effectué les étapes ci-dessus, votre éditeur New prendra automatiquement le rôle et la définition de l'ancien et commencera à servir les applications auxquelles l'ancien éditeur était assigné.

Cette section explique comment utiliser correctement la fonctionnalité Utiliser le DNS de l'éditeur dans une définition d'application de segment d'application privée. Tout d'abord, revenons sur le fonctionnement du NPA lorsque cette fonction est désactivée.

Lorsque vous définissez une destination sur le segment des applications privées et que vous attribuez cette application à un utilisateur via une stratégie, NPA écoute les requêtes de nom DNS et, si l'une d'entre elles correspond au nom d'hôte de l'application privée, NPA la résout en une adresse IP fictive. Dans les versions précédentes, la plage d'adresses IP était 191.x.x.x, mais dans les versions actuelles, nous utilisons un espace d'adresses CGNAT de 100.64.0.0/16 (appelons cela une adresse IP stub). Ensuite, lorsqu'un processus envoie une requête à cette adresse IP de base, le site NPA l'intercepte, l'achemine vers un éditeur, et l'éditeur effectue une résolution de nom New sur la base des serveurs DNS vers lesquels il pointe afin de résoudre l'adresse IP interne de l'application publiée.

Lorsque vous activez l'option Utiliser le DNS de l'éditeur, le concept d'utilisation d'une stub d'adresses IP disparaît. La requête DNS réelle pour le nom d'hôte spécifié dans la requête est capturée et transmise à l'éditeur, et la réponse reçue par le client est l'adresse IP réelle renvoyée par la requête DNS aux serveurs DNS vers lesquels l'éditeur pointe.

Par exemple, si vous essayez d'accéder au segment d'application privée portal.company.com et que ce nom d'hôte est résolu en 10.10.10.10 par le serveur DNS de l'éditeur, l'adresse IP renvoyée au processus de point de terminaison (comme un navigateur) sera 10.10.10.10 au lieu de l'adresse IP stub (191.x.x.x ou 100.64.0.0/16, selon la version). Le navigateur effectue ensuite une requête à l'adresse IP 10.10.10.10, qui est aussi arbitraire que n'importe quelle adresse IP peut l'être, et NPA doit savoir qu'il doit intercepter et tunneliser le trafic destiné à cette adresse IP. C’est pourquoi vous devez inclure soit un bloc CIDR couvrant l’adresse IP de l’application privée, soit l’adresse IP exacte de l’application privée, dans la définition de l’application du segment d’application privée.

Cette approche indique à NPA sur le point d'extrémité qu'il doit intercepter le trafic destiné à 10.10.10.10 et l'envoyer par le tunnel NPA.

C’est un concept très puissant, mais il exige que vous exerciez une diligence raisonnable pour identifier l’espace IP privé exact qui doit être desservi par une application particulière. Si vous spécifiez accidentellement une plage plus large que celle que devrait gérer une seule application, vous risquez d’envoyer involontairement du trafic vers toutes les applications privées qui ont activé le drapeau Utiliser le DNS de l’éditeur vers un seul éditeur ou groupe d’éditeurs défini sur l’application couvrant la plage IP et non via le Publisher sur lequel le nom d’hôte de l’application est défini. Pour un exemple pratique de déploiement des meilleures pratiques avec le mode DNS du publicateur, veuillez consulter le guide NPA .

Approches de la gestion et de la définition des segments d'applications privées

Si vous définissez des applications avec la fonction Utiliser le DNS de l'éditeur, vous avez plusieurs options. La première consiste à s'assurer que chaque définition d'application de segment d'application privée inclut une plage CIDR appropriée correspondant aux noms d'hôte en cours de résolution. Si vous publiez plusieurs applications, cette approche peut devenir fastidieuse car vous devez vous assurer que, pour chaque application, la plage CIDR spécifiée est unique et ne se chevauche pas avec les définitions d'autres applications afin d'éviter le conflit de direction sur l'endroit où envoyer le trafic.

Une autre façon d'aborder la question consiste à définir des segments d'application privés par CIDR qui sont desservis par le même [ensemble d'] éditeurs. Examinons le scénario suivant.

Vous définissez trois applications privées : hosta.company.com, hostb.company.com, et hostc.company.com, toutes accessibles par l'éditeur same. Vous savez que la plage de réseau CIDR des éditeurs desservant ces trois applications est 172.16.0.0/16, mais vous n'êtes pas sûr des IP spécifiques de chaque application, ou ces IP peuvent changer à l'avenir.

Approche de la configuration

Vous pouvez définir trois applications distinctes avec leurs noms d'hôtes/ports respectifs si la fonction Utiliser le DNS de l'éditeur est activée. Ensuite, vous créez également une application privée pour le réseau de l'emplacement A, par exemple, et vous la définissez par CIDR 172.16.0.0/16 en désactivant la fonction Utiliser le DNS de l'éditeur. Ainsi, NPA interceptera tout le trafic destiné aux réseaux 172.16.0.0/16 et au(x) port(s) d'application que vous avez défini(s) et l'enverra via le tunnel NPA. La définition CIDR ne doit pas nécessairement faire partie de la même définition de l'application privée qui utilise la fonction Utiliser le DNS de l'éditeur. Reportez-vous au tableau ci-dessous pour une représentation visuelle des définitions de l'application :

Cette configuration vous permettra d'accéder à l'App A, à l' App B et à l 'App C par nom d'hôte, ainsi qu'à toute ressource interne définie par le bloc CIDR de l'Emplacement A. Vous pouvez également constater que la définition CIDR de l'application Location A peut entraîner des actions de pilotage non souhaitées, car elle couvre une plage RFC1918 très large qui peut interférer avec les ressources du réseau local, et des conflits ou des irrégularités de pilotage peuvent se produire. La définition d'une application privée par un tel bloc CIDR expose toutes ses adresses IP à l'accès de l'utilisateur auquel cette application est attribuée, ce qui peut constituer une violation du principe du moindre privilège du concept d'accès au réseau de confiance zéro (ZTNA).

La manière la plus sûre de définir des applications privées avec la fonctionnalité Utiliser le DNS de l'éditeur est de fournir des définitions IP précises basées sur le CIDR pour les applications privées dans leur définition. Par exemple, lorsque vous définissez l'application privée A, vous devez indiquer le nom d'hôte hosta.company.com, et, s'il se résout en interne en 10.10.10.10, vous devez indiquer 10.10.10.10/32 comme valeur CIDR dans la définition de l'application. Ensuite, dans la définition de l'application privée B, vous mettez le nom d'hôte hostb.company.com, et, s'il se résout en interne à 10.10.10.11, vous mettez 10.10.10.11/32 comme valeur CIDR dans cette définition d'application également. Cette approche vous permet d'éviter efficacement une surexposition accidentelle au réseau interne ou la création de conflits d'adresses IP. Vous trouverez dans le tableau ci-dessous les définitions recommandées pour les applications privées afin d'atteindre cet objectif :

Pour les utilisateurs individuels, NPA prend en charge l'accès à un nombre illimité d'applications privées, quelle que soit la spécification de l'application dans une définition d'application privée. Chaque définition d'application de segment d'application privée est référencée par un nom de segment d'application (1). Dans une définition d'application, les spécifications de destination (2) peuvent être soit des adresses IP individuelles ou des sous-réseaux IP, des noms d'hôtes ou des domaines génériques (*.corp.com).

Les définitions de segment d'application privé sont énumérées dans une politique de protection en temps réel pour permettre à l'utilisateur final d'accéder aux spécifications du segment d'application. Sur la base des définitions de politiques, pour chaque utilisateur, NPA construit une association logique de spécifications de segments d'application, et supporte jusqu'à un maximum de 6000 spécifications de segments d'application. Pour plus de 6 000 spécifications d'application par utilisateur, vous devriez envisager d'agréger les adresses IP ou les noms d'hôte en sous-réseaux IP ou en domaines de cartes génériques.

Un administrateur doit s'assurer que la stratégie de protection en temps réel d'un utilisateur ne dépasse pas 40 Mo. La taille de la politique en temps réel pour un utilisateur donné est indiquée dans le résultat de l'outil NPA Troubleshooter.