Avant les règles Zero Trust basées sur l'identité, certaines applications SaaS sur l'Internet public se fiaient à l'adresse IP d'un utilisateur connecté pour établir un modèle de sécurité. Les utilisateurs se connectaient depuis des sites connus, avec des plages d'adresses IP fixes, et l'application SaaS vérifiait leur adresse en plus de leurs identifiants de connexion.
De nombreux systèmes proposent encore cette méthode du « deuxième facteur ». À cette fin, les clients utilisant Cloudflare One peuvent utiliser une adresse IP de sortie dédiée dans le cadre de leur adoption d'un modèle Zero Trust. Contrairement aux autres solutions, cette option n'impose pas aux clients qui l'utilisent de déployer leur propre infrastructure. Toutefois, il n'est pas nécessaire que tout le trafic utilise ces adresses IP de sortie dédiées.
Aujourd'hui, nous annonçons des politiques qui permettent aux administrateurs de contrôler à quel moment Cloudflare utilise leurs adresses IP de sortie dédiées. Plus précisément, les administrateurs peuvent utiliser un générateur de règles depuis le tableau de bord Cloudflare, afin de déterminer quelle adresse IP de sortie est utilisée et à quel moment, en fonction d'attributs tels que l'identité, l'application, l'adresse IP et la géolocalisation. Cette fonctionnalité est disponible pour tout client souscripteur d'une offre Entreprise souhaitant ajouter des adresses IP de sortie dédiées à son abonnement Zero Trust.
Pourquoi l'avons-nous développée ?
Dans l'environnement de travail hybride actuel, les organisations aspirent à déployer une sécurité et des expériences informatiques plus cohérentes pour gérer le trafic sortant de leurs employés provenant des bureaux, des datacenters et des appareils d'utilisateurs itinérants. Pour proposer une expérience plus rationalisée, de nombreuses entreprises adoptent des services de proxy modernes mis en œuvre depuis le cloud, à l'image des solutions Secure Web Gateway (SWG), et renoncent à leur ensemble hétéroclite complexe d'équipements sur site.
L'une des caractéristiques pratiques traditionnelles de ces outils hérités est la possibilité de créer des politiques de liste d'autorisation basées sur des adresses IP sources statiques. Lorsque les utilisateurs travaillaient principalement dans un même endroit, la vérification du trafic en fonction de l'emplacement de sortie était assez facile et fiable. De nombreuses organisations souhaitent ou sont tenues de conserver cette méthode de validation du trafic, même si leurs utilisateurs ne se trouvent plus dans un même endroit.
Jusqu'à présent, Cloudflare soutenait ces organisations en fournissant des adresses IP de sortie dédiées en complément de ses services de proxy Zero Trust. Contrairement aux adresses IP de sortie par défaut, ces adresses IP de sortie dédiées ne sont pas partagées avec d'autres comptes Gateway, et sont uniquement utilisées pour gérer le trafic sortant du proxy pour le compte désigné.
Comme nous l'avons expliqué dans un précédent article de blog, les clients utilisent déjà les adresses IP de sortie dédiées de Cloudflare pour mettre fin à leur dépendance vis-à-vis des VPN ; ils les utilisent pour identifier le trafic traité en proxy de leurs utilisateurs ou pour ajouter ces derniers aux listes d'autorisation de fournisseurs tiers. Ces organisations bénéficient ainsi toujours de la simplicité qu'offre l'utilisation d'adresses IP fixes et connues, et leur trafic évite les goulets d'étranglement et le réacheminement caractéristiques des équipements traditionnels sur site.
Quand utiliser les politiques de trafic sortant
Le générateur de politiques de sortie de Gateway offre aux administrateurs une flexibilité et une spécificité accrues, leur permettant de gérer le trafic sortant en fonction de l'identité de l'utilisateur, du niveau de sécurité de l'appareil, des adresses IP source/de destination, etc.
La géolocalisation spécifique du trafic sortant pour proposer des expériences géolocalisées (par ex. format linguistique, différentes pages régionales) à certains groupes d'utilisateurs est un scénario d'utilisation courant. Par exemple, Cloudflare travaille actuellement avec le département marketing d'un conglomérat mondial de médias. Les designers et experts web de ce département, situés en Inde, doivent souvent vérifier la mise en page de publicités et de sites web proposés dans différents pays.
Toutefois, ces sites web restreignent ou modifient l'accès en fonction de la géolocalisation de l'adresse IP source de l'utilisateur. L'équipe devait donc auparavant utiliser un service VPN supplémentaire uniquement à cette fin. Les politiques de sortie permettent aux administrateurs de créer une règle établissant une correspondance entre l'adresse IP du domaine ou la géolocalisation de l'adresse IP du pays de destination et les employés du département marketing, permettant à ces derniers de configurer le trafic sortant depuis une adresse IP de sortie dédiée, géolocalisée dans le pays dans lequel le domaine doit être confirmé. Cette approche offre davantage de sérénité à l'équipe de sécurité, qui n'a plus besoin de maintenir cette faille dans son périmètre de défense, ni de gérer un autre service VPN uniquement pour le marketing, et peut appliquer toutes ses autres fonctionnalités de filtrage à ce trafic.
Un autre exemple de scénario d'utilisation est la configuration de listes d'autorisation d'accès à des applications ou des services gérés par un tiers. Si les administrateurs de sécurité peuvent contrôler de quelle manière leurs équipes accèdent à leurs ressources et peuvent même appliquer un filtrage à leur trafic, ils sont souvent en revanche dans l'incapacité de modifier les contrôles de sécurité mis en œuvre par des tiers. Par exemple, lorsqu'ils coopéraient avec une grande société de traitement de crédit, ils ont eu recours à un service tiers pour contrôler le risque lié aux transactions acheminées sur son réseau Zero Trust. Ce tiers nécessitait qu'ils ajoutent ses adresses IP source à sa liste d'autorisation.
Pour atteindre cet objectif, ce client aurait pu se contenter d'utiliser des adresses IP de sortie dédiées ; toutefois, cela aurait signifié que l'ensemble de son trafic était désormais acheminé par l'intermédiaire du datacenter, avec ses adresses IP de sortie dédiées. Par conséquent, si un utilisateur souhaitait accéder à d'autres sites, son expérience serait médiocre, car son trafic n'emprunterait peut-être pas le chemin le plus efficace vers le serveur en amont. Toutefois, grâce aux politiques de sortie, ce client peut désormais uniquement appliquer cette adresse IP de sortie dédiée au trafic de ce fournisseur tiers et autoriser l'acheminement du reste du trafic utilisateur sortant via les adresses IP de sortie par défaut de Gateway.
Développer des politiques de sortie
Pour démontrer la facilité avec laquelle un administrateur peut configurer une politique, examinons ce dernier scénario. Mon organisation a recours à un service tiers qui, en plus d'une connexion avec nom d'utilisateur et mot de passe, nous demande d'utiliser une adresse IP source ou une plage d'adresses réseau statiques pour accéder à son domaine.
Pour configurer cela, il me suffit d'accéder à la section « Egress Policies » (Politiques de sortie) sous Gateway, dans le tableau de bord Zero Trust. Je peux alors cliquer sur « Create egress policy » (Créer une politique de sortie) :
Pour mon organisation, la plupart de mes utilisateurs accédant à ce service tiers se trouvent au Portugal. Je vais donc utiliser mes adresses IP de sortie dédiées, qui sont attribuées à Montijo, au Portugal. Les utilisateurs vont accéder à exemple.com, hébergé à l'adresse 203.0.113.10. Je vais donc utiliser la fonction de sélection d'adresse IP de destination pour affecter tout le trafic à ce site ; voici la configuration de la politique :
Après avoir créé ma politique, j'ajoute une autre politique servant de « fourre-tout » pour mon organisation, afin de m'assurer qu'elle n'utilise pas d'adresses IP de sortie dédiées pour des destinations non associées à ce service tiers. Cette politique est essentielle, car elle me permet de m'assurer que mes utilisateurs bénéficient de l'expérience réseau la plus performante, tout en préservant leur confidentialité grâce à l'acheminement de leur trafic sortant via le pool d'adresses IP partagées de notre offre Entreprise ; voici la configuration de la politique :
Si vous regardez la liste des politiques de sortie, vous voyez que les deux politiques sont activées et que maintenant, lorsque les utilisateurs essaient d'accéder à exemple.com, ils utiliseront, comme adresse IP de sortie, la plage primaire ou secondaire d'adresses dédiées IPv4 ou IPv6. Et pour le reste du trafic, les adresses IP de sortie par défaut de Cloudflare seront utilisées.
Prochaines étapes
Nous sommes conscients qu'à l'heure où les entreprises délaissent les équipements sur site, elles souhaitent continuer à bénéficier de la simplicité et du contrôle de ces solutions, tout en traitant par proxy une part croissante de leur trafic par l'intermédiaire de leur pile de sécurité cloud. Grâce aux politiques de sortie de Gateway, les administrateurs peuvent désormais contrôler les flux de trafic de leur personnel toujours plus décentralisé.
Si vous souhaitez créer des politiques reposant sur les adresses IP de sortie dédiées de Cloudflare, vous pouvez les ajouter à une offre Entreprise avec Cloudflare Zero Trust ou contacter votre responsable de compte.