Qu'est-ce que l'Accès Privé Cato ?

L'Accès Privé Cato offre un accès utilisateur-à-application via une architecture intermédiaire. Les utilisateurs ne se connectent pas directement au réseau qui héberge l'application. Au lieu de cela, l'accès est établi uniquement pour des applications qui sont explicitement définies et exposées par des Connecteurs d'Application.

L'Accès Privé ne prend en charge que l'accès initié par l'utilisateur. Les applications n'initient pas de connexion vers les utilisateurs, et les modèles de communication initiés par le serveur ou bidirectionnels ne sont pas pris en charge. Ce design impose une isolation stricte entre les utilisateurs et les environnements applicatifs et élimine le besoin d'exposer les réseaux internes ou d'annoncer des routes.

Les scénarios nécessitant une communication initiée par le serveur ou bidirectionnelle dépassent la portée de l'Accès Privé et sont pris en charge par l'architecture réseau complète de Cato, incluant IPsec et les sites Socket.

Pour plus d'informations, voir Accès Zero Trust aux Applications Privées avec le Cato SASE Cloud.

Le service d'Accès au cloud privé est sous licence par les utilisateurs par groupe régional. Pour plus d'informations, veuillez contacter votre représentant Cato ou revendeur officiel.

Les Applications Privées représentent les applications internes que vous publiez via Cato.

Pour chaque application, vous publiez des ressources internes en définissant comment les utilisateurs accèdent à l'application et quel Groupe de Connecteurs fournit la connectivité autorisée. Les applications sont abstraites de l'adressage IP interne, et les utilisateurs accèdent au domaine publié plutôt qu'au réseau interne.

Vous déployez des Connecteurs d'Application dans le même environnement que l'application protégée (centre de données, cloud VPC, ou LAN) pour connecter cet environnement au Cloud Cato de manière sécurisée. Chaque connecteur établit un tunnel DTLS uniquement sortant et ne transfère que les sessions explicitement autorisées par la politique. Étant donné que les connecteurs n'acceptent pas les connexions entrantes et ne nécessitent pas de changements de routage, vous pouvez introduire l'Accès Privé sans redessiner le réseau de l'application. Vous pouvez déployer plusieurs connecteurs pour augmenter la résilience et l'évolutivité.

Les Groupes de Connecteurs d'Application regroupent logiquement les connecteurs pour offrir une haute disponibilité, une répartition de charge et une séparation opérationnelle. Les applications privées sont attachées à un Groupe de Connecteurs plutôt qu'à un connecteur spécifique. Cela signifie que si un connecteur spécifique rencontre un problème, l'application peut automatiquement utiliser un autre connecteur disponible dans le groupe.

Vous utilisez la Politique d'Accès Privé pour contrôler qui peut accéder à quelles applications privées et sous quelles conditions. La politique vous permet d'accorder un accès au niveau de l'application basé sur l'identité de l'utilisateur et le contexte tout en maintenant une posture de refus par défaut. L'autorisation est évaluée au PoP avant qu'une session ne soit établie avec l'environnement applicatif, garantissant que seules les connexions explicitement autorisées sont sécurisées vers l'application.

Exposez en toute sécurité les applications internes sans modifier le routage, annoncer les sous-réseaux, ou modifier l'architecture WAN.

L'Accès Privé ne nécessite aucune règle de pare-feu entrant, utilise des tunnels uniquement sortants depuis l'environnement applicatif, ne nécessite pas de réadressage IP, et ne nécessite pas de site d'embarquement. Cela le rend idéal pour une intégration rapide des applications privées tout en préservant la conception réseau existante.

Dans les scénarios de fusions et acquisitions, les plages IP chevauchantes retardent souvent l'intégration.

L'Accès Privé publie des applications sans nécessiter de réadressage IP, abstrait l'adressage interne en utilisant CGNAT et mappage DNS, et permet un accès utilisateur sans intégration de domaine de routage. Cela permet une intégration rapide et non perturbatrice des environnements acquis.

Si une connectivité bidirectionnelle ou initiée par le serveur est requise ultérieurement, vous pouvez intégrer l'environnement en tant que site Cato complet.