Nous sommes heureux d'annoncer aujourd'hui de nouvelles fonctionnalités destinées à aider nos clients à passer d'un modèle de sécurité à base d'équipements de pare-feu physiques vers un pare-feu véritablement cloud-native, conçu pour les réseaux de dernière génération. Cloudflare One propose une plate-forme Zero Trust sécurisée et performante aux administrateurs qui cherchent à appliquer des politiques de sécurité cohérentes à l'ensemble de leurs utilisateurs et de leurs ressources. Mieux encore, cette plate-forme s'appuie sur notre réseau mondial. Vous n'aurez donc jamais besoin de vous soucier de l'évolutivité, du déploiement ou de l'entretien de vos équipements de sécurité en périphérie.
Dans le cadre de cette annonce, Cloudflare a également lancé le programme Oahu aujourd'hui, afin d'aider ses clients à abandonner leurs équipements physiques traditionnels. Cet article détaillera les nouvelles fonctionnalités qui contribueront à résoudre les problèmes rencontrés par les générations de pare-feu précédentes et permettront aux équipes informatiques d'économiser du temps et de l'argent.
Comment en sommes-nous arrivés là ?
Afin de comprendre où nous en sommes aujourd'hui, il serait utile de commencer par un bref historique des pare-feu IP.
Filtrage de paquets sans état pour les réseaux privés
La première génération de pare-feu réseau était principalement destinée à répondre aux exigences des réseaux privés en matière de sécurité. L'architecture de type « château et douves » (castle and moat) que nous avons définie comme la Génération 1 dans notre article d'hier en constituait les prémices. Les administrateurs de pare-feu pouvaient développer des politiques autour de signaux disponibles au niveau des couches 3 et 4 du modèle OSI (principalement des adresses IP et des ports). Ce mode opératoire se révélait parfait pour permettre (par exemple) à un groupe de collaborateurs travaillant à un étage donné d'un immeuble de bureaux d'accéder à des serveurs situés à un autre étage par l'intermédiaire d'un réseau local (LAN).
Cette fonctionnalité de filtrage de paquets s'est révélée suffisante jusqu'à ce que les réseaux gagnent en complexité, notamment après leur connexion à Internet. Les équipes informatiques ont alors commencé à avoir besoin de protéger le réseau de leur entreprise contre les acteurs malveillants issus de l'extérieur, soit un processus qui nécessitait l'emploi de politiques plus sophistiquées.
Une meilleure protection grâce à l'inspection dynamique et à l'inspection des paquets en profondeur
Les pare-feu physiques ont évolué pour inclure l'inspection dynamique des paquets et les balbutiements de l'inspection en profondeur. Les concepts de base du pare-feu s'en trouvèrent alors étendus grâce au suivi de l'état des connexions qui transitaient par ces derniers. Ce changement permettait aux administrateurs de bloquer, par exemple, l'ensemble des paquets entrants sans lien avec une connexion sortante déjà présente.
Ces nouvelles fonctionnalités offraient une protection plus sophistiquée contre les acteurs malveillants. Cette avancée se fit toutefois à un certain prix : le niveau de sécurité accru nécessitait une plus grande quantité de ressources, en termes de calcul et de mémoire. Pour les équipes chargées du réseau et de la sécurité, ces conditions impliquaient une obligation de procéder à une meilleure planification de la capacité dont elles avaient besoin pour chaque nouvel équipement, de même que la nécessité de faire des compromis entre le coût et la redondance sur le réseau.
En plus des compromis sur les coûts, ces nouveaux pare-feu ne proposaient que des statistiques limitées sur la manière dont le réseau était utilisé. Les administrateurs pouvaient voir que les utilisateurs accédaient à l'adresse 198.51.100.10 sur le port 80, mais s'ils souhaitaient savoir à quoi ces utilisateurs accédaient exactement, une recherche inversée de l'adresse IP s'imposait. De plus, en suivant cette procédure, l'enquêteur se retrouvait simplement sur la page d'accueil du fournisseur, sans bénéficier d'informations concernant les ressources auxquelles les utilisateurs accédaient ou sur la réputation du domaine/de l'hôte. De même, il ne profitait d'aucune donnée lui permettant de répondre à la question « Cet accès constitue-t-il un événement de sécurité sur lequel je devrais enquêter plus avant ? » En outre, la tâche consistant à déterminer la source s'avérait particulièrement difficile elle aussi, car elle nécessitait de mettre en corrélation une adresse IP privée transmise via DHCP avec un appareil, puis avec un utilisateur (si vous vous rappeliez de définir des durées de bail suffisamment longues et de ne jamais partager les appareils).
La reconnaissance des applications grâce aux pare-feu de nouvelle génération
Afin de répondre à ces défis, le secteur a lancé le pare-feu de nouvelle génération (NGFW, Next Generation Firewall). Ces solutions occupaient depuis toujours la première place du secteur en termes d'équipements de sécurité périphérique pour l'entreprise et l'occupent encore dans certains cas. Elles reprenaient l'ensemble des fonctionnalités des générations précédentes, tout en ajoutant une fonction de reconnaissance des applications permettant d'offrir aux administrateurs un degré de contrôle supérieur sur les éléments qui franchissaient leur périmètre de sécurité. Les NGFW ont introduit le concept d'informations sur les applications communiquées par les fournisseurs ou par des sources externes, c'est-à-dire la capacité à identifier les applications de par les caractéristiques du trafic. Ces informations pouvaient ensuite être incluses dans des politiques définissant ce que les utilisateurs pouvaient faire ou non au sein d'une application donnée.
À mesure qu'un nombre toujours croissant d'applications migraient vers le cloud, les fournisseurs de NGFW ont commencé à proposer des versions virtualisées de leurs équipements. Ces dernières permettaient aux administrateurs de ne plus avoir à se soucier des délais entre deux versions physiques, tout en leur assurant une plus grande flexibilité en matière de déploiement sur plusieurs emplacements.
Au fil des ans, tandis que le paysage des menaces continuait d'évoluer et que les réseaux devenaient plus complexes, les NGFW ont commencé à intégrer de nouvelles fonctionnalités de sécurité, dont certaines facilitaient la consolidation de plusieurs équipements. Suivant les fournisseurs, ces fonctionnalités comprenaient les passerelles VPN, les systèmes IDS/IPS, les pare-feu d'applications web, voire d'autres solutions, comme la gestion des bots et la protection contre les attaques DDoS. Toutefois, même avec ces fonctionnalités, les NGFW avaient leurs inconvénients : les administrateurs devaient toujours passer du temps à concevoir et à configurer des équipements redondants (au moins une ligne principale et secondaire), tout en choisissant les emplacements qui disposeraient d'un pare-feu et subiraient les pénalités de performances liées à la redirection du trafic depuis d'autres emplacements. Et même alors, une gestion prudente des adresses IP s'avérait nécessaire en cas de création de politiques permettant d'appliquer le principe de pseudo-identité.
L'ajout de mesures de contrôle au niveau de l'utilisateur permet la migration vers le Zero Trust
À mesure que les fournisseurs de pare-feu ajoutaient de nouvelles mesures de contrôle plus sophistiquées, un changement de paradigme au niveau de l'architecture réseau fut initié en parallèle afin de répondre aux problématiques de sécurité apparues lorsque les applications et les utilisateurs ont commencé à quitter le « château » de l'entreprise pour rejoindre le réseau Internet. La sécurité Zero Trust implique qu'elle ne fait confiance, par défaut, à aucune communication provenant de l'intérieur ou de l'extérieur du réseau. Quiconque tente d'accéder aux ressources situées sur le réseau doit ainsi se plier à une procédure de vérification. Les pare-feu ont commencé à inclure les principes du Zero Trust en intégrant les fournisseurs d'identité et en permettant aux utilisateurs de définir des politiques centrées autour de groupes d'utilisateurs (avec des concepts du type « Seuls le service financier et le service des RH peuvent accéder aux systèmes de paie »). Ces mesures offraient ainsi un contrôle plus précis et permettaient de réduire la nécessité de s'appuyer sur les adresses IP pour se faire une idée de l'identité d'un utilisateur.
Ces politiques ont aidé les entreprises à verrouiller leurs réseaux et à se rapprocher du modèle Zero Trust, mais les CIO se retrouvent toujours aux prises avec certains problèmes : que faire lorsque le réseau doit intégrer le fournisseur d'identité d'une autre entreprise ? Comment accorder un accès aux ressources de l'entreprise aux sous-traitants, et ce en toute sécurité ? De même, ces nouvelles mesures de contrôle ne répondent pas aux problèmes fondamentaux liés à la gestion des équipements physiques, qui existent toujours et deviennent de plus en plus complexes à mesure que l'activité des entreprises évolue, suite à l'ajout et à la suppression d'emplacements ou à l'adoption de formes de travail hybrides. Les CIO ont besoin d'une solution capable de s'intégrer dans l'avenir des réseaux d'entreprise, plutôt que de bricoler des solutions qui ne répondent qu'à certains aspects de leurs besoins.
Le pare-feu cloud-native, conçu pour les réseaux de nouvelle génération
Cloudflare aide ses clients à développer l'avenir de leurs réseaux d'entreprise en unifiant la connectivité réseau et la sécurité Zero Trust. Les clients qui adoptent la plate-forme Cloudflare One peuvent abandonner leurs pare-feu physiques au profit d'une approche cloud-native. En résolvant les problèmes liés aux générations précédentes, cette dernière facilitera grandement la vie de leurs équipes informatiques.
Reliez n'importe quelle source ou destination grâce à des accès directs flexibles
Plutôt que de gérer différents appareils pour différents scénarios d'utilisation, l'ensemble du trafic de votre réseau (issu des datacenters, des bureaux, des propriétés cloud et des appareils des utilisateurs) devrait pouvoir transiter par un pare-feu mondial unique. La plate-forme Cloudflare One vous permet de vous connecter au réseau Cloudflare à l'aide de toute une gamme de méthodes d'accès direct flexibles, notamment les tunnels en couche réseau (tunnels GRE ou IPsec) ou en couche applicative, la connexion directe, l'approche BYOIP et l'utilisation d'un client sur appareil. La connectivité à Cloudflare implique l'accès à l'intégralité de notre réseau mondial, qui élimine bon nombre des défis posés par les équipements physiques ou virtualisés :
- Ne vous souciez plus de planifier votre capacité : la capacité de votre pare-feu est égale à la capacité du réseau mondial de Cloudflare (plus de 100 Tb/s à ce jour).
- Dites adieu à la planification d'emplacements : l'architecture réseau Anycast de Cloudflare permet au trafic de se connecter automatiquement à l'emplacement le plus proche de sa source. Vous n'aurez plus à choisir de régions ou à vous soucier de l'endroit dans lequel se situent vos équipements principaux ou de secours. La redondance et le basculement sont intégrés par défaut.
- Dites au revoir aux interruptions de service pour maintenance : comme tous nos produits, les améliorations apportées aux capacités du pare-feu de Cloudflare sont déployées en continu depuis notre réseau périphérique mondial.
- Une protection contre les attaques DDoS intégrée : ne vous inquiétez plus de voir vos pare-feu submergés par les attaques DoS. Le réseau de Cloudflare bloque automatiquement les attaques à proximité de leur source et n'envoie que du trafic légitime vers sa destination.
Configurez des politiques complètes, du filtrage des paquets au Zero Trust
Les politiques de Cloudflare One peuvent servir à sécuriser et à acheminer le trafic de votre entreprise le long des divers chemins empruntés par ce dernier. Ces politiques peuvent être conçues à l'aide des mêmes attributs que ceux disponibles au sein d'un NGFW traditionnel, mais peuvent également inclure les attributs Zero Trust. Ces derniers peuvent intégrer un ou plusieurs fournisseurs d'identité ou fournisseurs de sécurité des points de terminaison.
Si l'on examine strictement les couches 3 à 5 du modèle OSI, les politiques peuvent se baser sur l'adresse IP, le port, le protocole et d'autres attributs, à la fois sans état et avec état. Utilisés en conjonction avec n'importe lequel des attributs d'identité et notre client sur appareil, ces attributs peuvent également vous servir à développer votre propre réseau privé sur Cloudflare.
En outre, afin de contribuer à alléger les lourdeurs liées à la gestion de listes d'autorisation/blocage, Cloudflare propose un ensemble de listes gérées applicables à la fois aux politiques sans état et avec état. Histoire de pousser encore plus loin la sophistication, vous pouvez également procéder à une inspection des paquets en profondeur et rédiger des filtres de paquets programmables, afin d'appliquer un modèle de sécurité positive et de déjouer les attaques les plus vastes.
Les informations issues du réseau Cloudflare nous aident à soutenir les catégories d'applications et de contenu de nos politiques de couche 7, que vous pouvez utiliser pour protéger vos utilisateurs contre les menaces, empêcher l'exfiltration de données et procéder à l'audit des ressources de l'entreprise. Tout commence par notre résolveur DNS protégé, qui s'appuie sur les performances incomparables de notre service 1.1.1.1, destiné aux consommateurs. Le DNS protégé permet aux administrateurs d'empêcher leurs utilisateurs de résoudre ou de se rendre à des adresses constituant des sources connues ou potentielles de risques de sécurité. Une fois la résolution d'un domaine effectuée, les administrateurs peuvent appliquer des politiques HTTP afin d'intercepter, inspecter et filtrer le trafic d'un utilisateur. De même, si ces applications sont auto-hébergées ou SaaS, vous pouvez les protéger à l'aide d'une politique d'accès Cloudflare, qui agira en tant que proxy d'identité basé sur le web.
Dernier point, mais non des moindres, afin d'empêcher l'exfiltration de données, les administrateurs peuvent verrouiller l'accès aux applications HTTP externes en utilisant notre solution d'isolation de navigateur à distance. De même, les administrateurs pourront bientôt consigner et filtrer les commandes qu'un utilisateur peut exécuter au cours d'une session SSH.
Simplifiez la gestion des politiques : propagez vos règles partout où vous le souhaitez, en un seul clic
Les pare-feu traditionnels nécessitaient le déploiement de politiques sur chaque appareil ou la configuration et l'entretien d'un outil d'orchestration permettant de faciliter ce processus. À l'inverse, Cloudflare vous permet de gérer les politiques sur l'ensemble de notre réseau à partir d'un simple tableau de bord ou d'une API. Vous pouvez également utiliser Terraform pour déployer votre infrastructure sous forme de code. Les modifications se propagent à la périphérie en quelques secondes grâce à notre technologie Quicksilver. Les utilisateurs peuvent bénéficier d'une certaine visibilité sur le trafic circulant à travers le pare-feu grâce à des logs, désormais configurables.
Consolidez plusieurs scénarios d'utilisation du pare-feu sous une plate-forme unique
Les pare-feu doivent traiter une myriade de flux de trafic pour répondre à divers besoins de sécurité, notamment le blocage du trafic entrant malveillant, le filtrage des connexions sortantes (de manière à garantir que les collaborateurs et les applications n'accèdent qu'à des ressources sûres) et l'inspection des flux de trafic internes (« Est/Ouest ») afin d'appliquer les principes du Zero Trust. Un équipement différent couvre souvent un ou plusieurs scénarios d'utilisation selon l'emplacement. Nous estimons qu'il semble logique d'en consolider autant que possible afin de simplifier le processus et d'établir une source unique de vérité pour les politiques de pare-feu. Examinons certains des scénarios d'utilisation auxquels les pare-feu physiques répondent d'ordinaire et expliquons de quelle manière les équipes informatiques peuvent y répondre à l'aide de Cloudflare One.
Protection d'un bureau régional
Traditionnellement, les équipes informatiques avaient besoin de prévoir au moins un pare-feu physique par emplacement de bureau physique (plusieurs s'il était nécessaire de mettre en place une redondance). Ce mode opératoire impliquait l'estimation préalable de la quantité de trafic circulant au sein d'un bureau régional donné, de même que la commande, l'installation et l'entretien du ou des équipements. Un client peut désormais connecter le trafic des bureaux régionaux à Cloudflare depuis n'importe quel équipement déjà en sa possession (un routeur standard prenant en charge les protocoles GRE ou IPsec fera parfaitement l'affaire) et contrôler les politiques de filtrage sur l'ensemble du trafic à l'aide du tableau de bord de Cloudflare.
Étape 1 : établir un tunnel GRE ou IPsec
La majorité des fournisseurs d'équipements conventionnels prennent en charge les méthodes de tunneling GRE et/ou IPsec. Cloudflare fournira une adresse IP Anycast à utiliser en tant que point de terminaison du tunnel de notre côté. Quant à vous, vous devrez configurer un tunnel GRE ou IPsec standard sans étapes supplémentaires (l'adresse IP Anycast confère une connectivité automatique à chaque datacenter Cloudflare).
Étape 2 : configurer les règles de pare-feu au niveau de la couche réseau
L'intégralité du trafic IP peut être filtré par l'intermédiaire du service Magic Firewall, qui inclut la possibilité de développer des politiques basées sur n'importe quelle caractéristique de paquet (IP source ou destination, port, protocole, pays ou correspondance des champs de bits). Le service Magic Firewall s'intègre également avec la solution IP Lists et inclut des fonctionnalités avancées, comme le filtrage de paquets programmable.
Étape 3 : mettre à niveau le trafic pour les règles de pare-feu au niveau de l'application
Une fois la circulation à travers Magic Firewall effectuée, le trafic TCP et UDP peut être « mis à niveau » à des fins de filtrage plus précis par l'intermédiaire de Cloudflare Gateway. Cette mise à niveau débloque une suite entière de fonctionnalités de filtrage, comme la reconnaissance des applications et du contenu, la mise en application de mesures d'identité, la mise en proxy SSH/HTTP et la DLP (protection contre les pertes de données).
Protection d'un datacenter ou d'un cloud privé virtuel (VPC) à trafic élevé
Les équipements de pare-feu utilisés pour traiter les données au sein d'un siège ou d'un datacenter au trafic élevé peuvent compter parmi les dépenses d'investissement les plus onéreuses dans le budget d'une équipe informatique. Traditionnellement, les datacenters sont protégés par des équipements robustes, capables de traiter de forts volumes sans problème, moyennant un coût accru. Dans l'architecture de Cloudflare, comme chaque serveur figurant sur notre réseau peut partager la responsabilité du traitement du trafic client, aucun appareil ne peut créer de goulot d'étranglement. De même, aucun d'entre eux ne nécessite de coûteux composants spécialisés. Les clients peuvent connecter directement le trafic à Cloudflare par l'intermédiaire du BYOIP (un mécanisme de tunneling standard) ou de Cloudflare Network Interconnect, afin de permettre à leurs règles de pare-feu de traiter en toute fluidité un trafic pouvant atteindre plusieurs térabits par seconde.
Protection d'effectifs nomades ou hybrides
Pour se connecter aux ressources de l'entreprise ou bénéficier d'un accès sécurisé à Internet, les utilisateurs d'architectures réseau traditionnelles doivent établir une connexion VPN depuis leurs appareils vers un emplacement central abritant les pare-feu. Leur trafic y est alors traité avant d'être autorisé à rejoindre sa destination finale. Cette architecture entraîne des pénalités en termes de performances. En outre, si les solutions de pare-feu modernes peuvent activer des contrôles au niveau de l'utilisateur, elles n'atteignent pas nécessairement le Zero Trust. Cloudflare permet à ses clients d'utiliser un client sur appareil en guise d'accès direct aux politiques Zero Trust. Restez à l'écoute cette semaine pour découvrir de nouvelles mises à jour quant à la manière de déployer le client à grande échelle en toute fluidité.
Et maintenant ?
Nous avons hâte de continuer à faire évoluer cette plate-forme afin de lui permettre de répondre à de nouveaux scénarios d'utilisation. D'après nos sources, certains de nos clients cherchent à étendre la fonctionnalité NAT de Gateway à l'aide de Cloudflare One, souhaitent profiter d'outils d'analyse, de reporting et de suivi de l'expérience utilisateur sur l'ensemble des capacités de notre pare-feu et se révèlent très enthousiastes à l'idée d'adopter une suite complète de fonctionnalités de DLP pour l'ensemble de leur trafic transitant via le réseau de Cloudflare. Nous vous communiquerons bientôt d'autres informations sur ces sujets, parmi bien d'autres (restez à l'écoute).
Les nouvelles fonctionnalités de pare-feu de Cloudflare sont disponibles dès aujourd'hui pour les clients de niveau Enterprise. Vous trouverez d'ailleurs plus d'informations à ce sujet ici. N'oubliez pas non plus de vous rendre sur la page du programme Oahu afin d'en apprendre plus sur la procédure à suivre pour migrer de vos pare-feu physiques au Zero Trust (vous pouvez également discuter avec l'équipe chargée de votre compte pour commencer le processus dès aujourd'hui).