Cet article explique le rôle des Connecteurs d'application dans l'architecture d'Accès Privé Cato et le flux de trafic de bout en bout pour accéder aux Applications Privées. Il décrit comment la résolution DNS, CGNAT, les Groupes de Connecteurs d'application, l'équilibrage de charge et les mécanismes de haute disponibilité fonctionnent ensemble pour sécuriser les connexions des utilisateurs aux applications internes.
Aperçu
Lorsqu'un administrateur publie une Application Privée dans l'Application de Gestion Cato (CMA), l'application est associée à un Groupe de Connecteurs d'application et définie par son domaine d'application publié, sa destination interne et ses ports et protocoles autorisés. Le PoP de Cato est le courtier ZTNA qui enregistre l'application publiée dans le plan de contrôle Accès Privé et attribue une adresse IP synthétique au domaine d'application publié. Cette adresse IP représente l'application au sein de l'architecture courtier de Cato et empêche les utilisateurs d'apprendre ou de se connecter directement à l'adresse IP interne de l'application.
Tout accès aux Applications Privées publiées est initié par l'utilisateur et courtier par le Cloud Cato.
Le plan de contrôle valide l'identité de l'utilisateur, évalue la Politique d'Accès Privé et détermine si l'application demandée, le port et le protocole sont autorisés.
Le plan de données transporte le trafic autorisé à travers le Cloud Cato et le Connecteur d'application sélectionné vers le serveur d'application interne.
Les requêtes d'application non autorisées sont refusées avant qu'une session sur l'environnement d'application soit établie.
Flux de Trafic
L'utilisateur se connecte au Cloud SASE Cato en utilisant le Client Cato, ou une autre méthode d'accès supportée.
L'utilisateur tente d'accéder à une Application Privée publiée en envoyant une demande DNS pour le domaine d'application publié au service DNS Cato.
Le PoP de Cato (courtier ZTNA):
Identifie l'Application Privée associée au domaine demandé.
Évalue la Politique d'Accès Privé pour déterminer si l'utilisateur authentifié est autorisé à accéder à une application publiée avec ce domaine.
Le DNS Cato traite la demande selon le résultat de l'autorisation:
Si l'utilisateur est autorisé, le DNS Cato renvoie l'adresse IP synthétique (CGNAT) attribuée au domaine d'application publié.
Si l'utilisateur n'est pas autorisé, le DNS Cato refuse la demande
Le domaine ne se résout pas, et aucune session sur l'environnement d'application n'est établie.L'utilisateur initie une connexion à l'adresse IP synthétique retournée. Le Cloud Cato sanctionne la session.
Sélectionne le Connecteur d'application optimal dans le Groupe de Connecteurs d'application associé.
Relie la session utilisateur autorisée à l'application interne via le tunnel DTLS sortant établi par ce Connecteur d'application.
Le Connecteur d'application résout la destination de l'application interne configurée lorsque la résolution DNS interne est requise, et transmet le trafic sur le réseau local au serveur d'application interne.
Tout au long du flux, la validation de l'identité, l'autorisation DNS, l'application des ports et protocoles, et la médiation des sessions sont effectuées par le Cloud Cato. L'utilisateur communique avec l'adresse IP synthétique attribuée au domaine d'application publié et ne reçoit pas la joignabilité directe du réseau à l'environnement d'application.
DNS et Connecteurs d'application
Le DNS lie les utilisateurs autorisés aux Applications Privées publiées sans exposer l'adressage des applications internes. Les appareils utilisateurs doivent utiliser le service DNS Cato à 10.254.254.1 afin que les requêtes pour les domaines d'application publiés soient traitées par le PoP.
Le Connecteur d'application utilise un chemin DNS séparé pour la résolution des applications internes. Par défaut, il utilise DHCP pour obtenir son adresse IP LAN, sa passerelle par défaut et son serveur DNS interne. Lorsqu'une application interne est identifiée par un FQDN, le Connecteur d'application utilise le serveur DNS interne pour résoudre l'application sur le réseau local.
Bientôt disponible: Support pour la configuration statique d'IP LAN et DNS dans les environnements sans DHCP.
CGNAT et Abstraction d'IP
Lorsqu'une Application Privée est publiée via un Groupe de Connecteurs d'application, le PoP l'enregistre dans le plan de contrôle Accès Privé et lui attribue une adresse IP synthétique unique de la gamme CGNAT des Applications Privées du compte. Cette IP synthétique représente l'application au sein du Cloud Cato et garde son adresse IP interne cachée des utilisateurs.
Ces plages ne doivent pas chevaucher les plages réseau des clients ou d'autres services de Cato et peuvent être personnalisées si nécessaire.
Les utilisateurs accèdent à l'application via son domaine publié et représentation IP synthétique plutôt que son adresse interne.
Cette abstraction est particulièrement utile dans les environnements avec des espaces d'adressage chevauchants, tels que les fusions et acquisitions, car les applications peuvent être publiées sans réadressage des réseaux sous-jacents.
Limitation connue: Les adresses IP synthétiques sont générées automatiquement par Cato et ne sont pas exposées pour une référence directe dans les règles de Politique Réseau.
Groupes de Connecteurs d'Application
Un Groupe de Connecteurs d'application est la couche de connectivité logique entre le Cloud Cato et un ensemble d'Applications Privées. Les Applications Privées sont associées à un groupe plutôt qu'à un Connecteur d'application individuel, et chaque application peut être publiée via un seul Groupe de Connecteurs d'application à la fois.
Note: Un Groupe de Connecteurs d'application peut inclure jusqu'à 10 Connecteurs d'application.
Le PoP sonde continuellement les connecteurs dans le groupe et évalue leur disponibilité et leurs performances. Pour chaque session autorisée, le PoP sélectionne le connecteur optimal et relie la session via ce connecteur à l'application interne.
Des Groupes de Connecteurs d'application multiples peuvent être utilisés pour représenter des environnements, régions ou zones de sécurité distincts, tels que la production, le rétablissement en cas de sinistre, le cloud, ou les réseaux sur site. Le groupe associé à une Application Privée doit contenir au moins un connecteur qui peut accéder à l'application via le LAN. Chaque application ne peut être publiée qu'à un seul Groupe de Connecteurs d'application à la fois.
Bonne pratique: Déployez et connectez les Connecteurs d'application avant de publier des Applications Privées via le groupe. Si aucun connecteur du groupe n'est connecté, l'Application Privée est indisponible et apparaît comme désactivée.
Basculement Automatique
Le basculement automatique maintient l'accès aux Applications Privées lorsqu'un Connecteur d'application devient indisponible. Le PoP sonde continuellement les connecteurs dans un Groupe de Connecteurs d'application et évalue leur disponibilité et leurs performances.
Si un connecteur devient inaccessible, le PoP arrête de le sélectionner pour de nouvelles sessions et route les sessions autorisées suivantes via le prochain connecteur disponible du groupe. Les sessions existantes peuvent avoir besoin d'être réétablies via le connecteur nouvellement sélectionné.
Le basculement se produit automatiquement au sein du Groupe de Connecteurs d'application et ne nécessite pas d'intervention de l'administrateur. Les Applications Privées restent disponibles tant qu'au moins un connecteur du groupe est connecté et a une accessibilité LAN au serveur d'application interne.
Pour maintenir la disponibilité à travers les régions ou environnements cloud, déployez des Connecteurs d'application dans chaque environnement qui héberge l'application. Les connecteurs doivent appartenir à un Groupe de Connecteurs d'application associé à l'Application Privée correspondante et doivent avoir une accessibilité LAN à cette instance d'application.
Haute disponibilité
La haute disponibilité est atteinte en déployant plusieurs Connecteurs d'application dans le même Groupe de Connecteurs d'application. Étant donné que les Applications Privées sont associées au groupe plutôt qu'à un connecteur individuel, l'accès à l'application peut continuer tant qu'au moins un connecteur reste connecté et a une accessibilité LAN au serveur d'application interne.
Déployez au moins deux Connecteurs d'application par groupe et assurez-vous que chaque connecteur peut accéder aux mêmes destinations d'application. Le PoP évalue continuellement la santé et les performances du connecteur et distribue les sessions autorisées parmi les connecteurs disponibles.
Pour les déploiements cloud, placez les connecteurs dans des zones de disponibilité ou régions distinctes pour réduire la dépendance à un seul emplacement d'infrastructure. Pour les déploiements physiques, placez les connecteurs dans des racks distincts, des domaines d'alimentation ou des zones de panne.
Le basculement du Connecteur d'application est conçu pour rétablir l'accès à l'application en moins de 30 secondes. La continuité des sessions dépend du protocole d'application et de l'état de la session, et certaines sessions actives peuvent nécessiter d'être réétablies.
Bientôt disponible: Support pour les App Connecteurs physiques redondants avec des prises Cato en paire HA.