Configurer la publication d'applications Zero Trust

La publication fournit un point d'accès via un cluster proxy et transfère les requêtes aux cibles configurées. Cluster, service publié, application et restrictions doivent être préparés et vérifiés séparément. La création ne prouve pas que les instances sont en ligne, que le DNS résout, que les certificats sont disponibles ou que la cible est accessible.

Préparation

• Utilisez un compte superadministrateur disposant des droits Zero Trust nécessaires. Lecture, création, modification et suppression peuvent exiger des droits différents.
• Confirmez avec les administrateurs réseau et application le domaine d'accès, le déploiement proxy, protocole et port cible, certificats et personnes ou réseaux autorisés. Commencez par une application de test et un périmètre contrôlé ; obtenez l'approbation requise.
• Préparez selon la cible des nœuds Zero Trust ou des ressources réseau. Pour limiter les nœuds autorisés à accéder à un service HTTP privé, créez ou choisissez un groupe sous le contrôle d'accès, ouvrez ses détails et utilisez « Add Endpoints » pour ajouter les nœuds pilotes autorisés. Vérifiez les autres références avant modification.
• Vérifiez politiques, routes, pare-feu cible et chemin de retour nécessaires. Groupes, authentification du service et politiques réseau ont des rôles distincts ; leur enregistrement ne prouve pas l'accès de bout en bout.

Créer un cluster proxy

1. Dans la publication d'applications Zero Trust, ouvrez les clusters proxy et choisissez « Create Proxy Cluster ».
2. Saisissez le nom et le domaine public puis enregistrez. Le domaine public doit correspondre à la configuration du proxy ; confirmez domaine, résolution et certificats avec les responsables.
3. Traitez le jeton selon la page. Le jeton de création n'est affiché qu'une fois. Transmettez-le par un canal sûr aux personnes autorisées à déployer le proxy, sans le placer dans des documents, conversations ou tickets ordinaires.
4. Déployez les instances selon la procédure approuvée et vérifiez leur présence en ligne et leurs capacités. Si la page attend une instance, ne supposez pas les services privés ou ports personnalisés disponibles. Créer le cluster ne démarre pas une instance.

Créer un service et ses cibles

1. Ouvrez les services publiés et choisissez « Create Published Service ». Sélectionnez cluster, nom, domaine de publication et mode proxy HTTP, TCP, UDP ou TLS. Vérifiez la conformité du domaine avec le déploiement.
2. Hors HTTP, choisissez le mode d'attribution et vérifiez le port d'écoute. La disponibilité d'un port personnalisé dépend des capacités annoncées du cluster ; vérifiez pare-feu et conflits.
3. Ajoutez une cible : « Endpoint », « Network Resource » ou « Proxy Host Direct ». Pour un terminal ou une ressource, sélectionnez aussi l'objet correspondant ; s'il est indisponible, vérifiez son état et ses références.
4. Saisissez l'adresse et vérifiez protocole et port réels du backend. HTTP utilise une adresse http:// ou https:// et un chemin si nécessaire ; les autres modes demandent hôte et port selon la page. Pour un terminal ou une ressource exacte, vérifiez l'objet et la cible affichée ; un nom d'exemple ne constitue pas une autorisation distincte.
5. Ajoutez d'autres cibles si nécessaire et contrôlez objet, adresse, port et service. Les exemples illustrent le format et ne garantissent pas l'accessibilité. Pour un service HTTP, chaque chemin de cible doit commencer par / et être unique dans le service ; le chemin par défaut / ne peut lui aussi être utilisé qu’une fois. Avant d’ajouter plusieurs cibles, prévoyez des chemins distincts, par exemple /reports et /sales, puis vérifiez chaque transfert. En cas d’échec d’enregistrement, recherchez une utilisation répétée de /.

Limite de sécurité Proxy Host Direct : selon la page, le proxy accède directement à la cible sans passer par le routage Zero Trust, le contrôle d'accès et l'isolation du réseau local ; les adresses de boucle locale, lien local ou multidiffusion sont interdites. Évaluez indépendamment les réseaux accessibles au proxy, le pare-feu et la protection de la cible. Ne supposez pas que ces contrôles réseau Zero Trust limitent encore ce chemin. Pour une cible exprimée par un nom d’hôte, un enregistrement réussi ne signifie pas que chaque adresse effectivement résolue par le proxy autorise la connexion. Une connexion peut être refusée si la résolution donne une adresse restreinte, notamment de boucle locale, de lien local ou de multidiffusion. Vérifiez la résolution et l’accès à la cible depuis l’environnement du proxy et retestez après tout changement DNS ; ne tentez pas de contourner les restrictions en changeant le nom.

Accès au service HTTP

La page d'authentification HTTP propose des approches distinctes. Définissez public et exigences de sécurité avant de choisir :

1. Zero Trust Network Only : vérifiez instances en ligne, mode proxy privé et prise en charge des services privés. Activez l'option et choisissez au moins un groupe préparé. La page indique que seuls les nœuds connectés correspondant au groupe peuvent accéder ; testez néanmoins les nœuds correspondants et non correspondants.
2. Autre mode : choisissez « No Authentication », PIN ou « Password ». À la création ou au changement vers PIN ou mot de passe, saisissez le secret ; le PIN comporte six chiffres. Réglez la durée de session selon l'organisation et conservez et transmettez les secrets par un canal sûr. Avant de choisir aucune authentification, évaluez exposition et risque ; ne supposez pas une authentification utilisateur automatique.
3. Les groupes d'un service privé et le PIN ou mot de passe d'un service non privé sont des solutions distinctes. Après bascule, revérifiez options, personnes autorisées et accès réel. Les modes non HTTP n'affichent pas cette page ; ne supposez pas automatiquement une protection équivalente.

Lors du choix ou du passage à l’authentification par PIN ou mot de passe, la page fixe la durée de session à 86400 secondes (24 heures). La plage acceptée est de 60 à 604800 secondes (1 minute à 7 jours). C’est la valeur initiale au changement, pas nécessairement celle d’un service existant. Réglez-la et enregistrez selon les exigences de l’organisation, puis revérifiez les identifiants et la durée après un changement de mode.

Restrictions et vérification

1. Dans « Access Control », renseignez si nécessaire « Allowed CIDRs » et « Blocked CIDRs ». Dans les paramètres avancés, vérifiez délais cibles, transfert et options applicables. Ne déduisez pas le résultat final d'une seule liste ; testez le déploiement.
2. Vérifiez certificats et exigences de connexion du service cible. La page propose d'ignorer la vérification TLS du backend pour un certificat autosigné invérifiable dans un réseau interne contrôlé. Évaluez la sécurité avant activation ; n'en faites pas le dépannage par défaut.
3. Avant d'enregistrer, contrôlez cluster, domaine, cibles, authentification, groupes et restrictions réseau. Ensuite vérifiez activation et état d'exécution dans la liste. Attente du proxy, tunnel non établi ou état lié au certificat ne signifie pas disponibilité.
4. Depuis un client autorisé, vérifiez DNS, port, certificat, authentification et application ; testez ensuite les restrictions depuis un client non autorisé. Pour l'accès privé, testez les nœuds correspondant et ne correspondant pas au groupe.
5. Consultez les journaux du service et les journaux d'audit pour rapprocher service et heure. Ils donnent des indices sur les étapes enregistrées sans remplacer les tests d'accès et de sécurité.

Exemple CIDR : si la liste d’autorisation n’est pas vide, l’adresse source doit correspondre à au moins une entrée ; une correspondance avec la liste de blocage reste refusée. Une liste d’autorisation vide ne restreint pas les sources par elle-même, mais la liste de blocage et les autres contrôles peuvent s’appliquer. Si 10.20.0.0/16 est autorisé et 10.20.5.0/24 bloqué, 10.20.4.10 passe ces contrôles CIDR, 10.20.5.10 est refusé par le blocage et 10.21.4.10 car hors de la liste d’autorisation. Les adresses sont des exemples. Les proxys en amont ou la traduction d’adresses réseau peuvent modifier l’adresse source reconnue ; vérifiez-la et testez-la dans le déploiement. Réussir le contrôle CIDR ne prouve pas que l’authentification, les groupes d’accès ou le service cible sont disponibles.

Interpréter la colonne d’authentification : pour les accès HTTP, le succès ou l’échec affiché peut dépendre du statut de réponse HTTP : 401 ou 403 peut apparaître comme un échec, tandis que d’autres statuts, y compris des erreurs de service, peuvent apparaître comme un succès. Pour les enregistrements non HTTP tels que TCP, UDP ou TLS, un échec affiché ne signifie pas nécessairement qu’une authentification utilisateur a échoué. Analysez ensemble le mode d’authentification du service, le code de réponse, la source et les journaux de l’application cible lors de tests contrôlés ; ne déduisez pas l’identité ni le succès ou l’échec de l’authentification de cette seule colonne. Les libellés anglais correspondants sont Authentication, Success et Failed.

Modifications et dépannage

• Enregistrement impossible : vérifiez cluster, nom, domaine, objet cible et format d'adresse ; pour non-HTTP, vérifiez le port. Pour HTTP privé, vérifiez instance en ligne, capacités et au moins un groupe ; saisissez le PIN requis.
• Créé mais inaccessible : vérifiez séparément activation et exécution, proxy, DNS, port, pare-feu, certificat, service cible et chemin réseau.
• Authentification ou accès inattendu : vérifiez mode privé ou authentification, groupes, réseaux autorisés et bloqués, autres politiques et protections cibles ; testez les sujets autorisés et refusés.
• Modifier, désactiver ou supprimer : vérifiez références, utilisateurs et dépendances, consignez les réglages et suivez l'autorisation. Revérifiez état, restrictions et service après changement. Traitez jetons et secrets par canal sûr.