How to Implement Cloudflare MCP Portal and MCP Servers with Access for SaaS

Bonjour, Antoine, Solution Engineer chez Cloudflare. Dans cette vidéo, on va parler de l'implémentation de Secure Access Service Edge avec Cloudflare. Peut-être que vous continuez aujourd'hui à gérer votre propre matériel VPN au bureau, on-prem, pour protéger l'accès de vos utilisateurs aux ressources internes et Internet. Mais aujourd'hui, je souhaitais vous présenter une nouvelle façon de fonctionner. Et pourquoi changer ? Parce que les équipements VPN aujourd'hui sont constamment attaqués. Il y a beaucoup de vulnérabilités qui sont signalées par toutes les grandes marques comme Cisco, Fortinet, Palo Alto. Et ce que je vous propose aujourd'hui de voir et d'explorer, c'est comment vous pouvez-vous passer de ces solutions et recréer votre réseau d'entreprise sur Cloudflare. Au cours des dix dernières années, on a assisté à un changement majeur dans l'architecture des réseaux. On utilisait avant le modèle du château fort, où les employés venaient au bureau, se connectaient au Wi-Fi ou en Ethernet et avaient accès aux applications de votre entreprise. Donc les serveurs de messagerie, SharePoint, etc. Ils y avaient accès parce qu'ils étaient dans le réseau. Aujourd'hui, on a migré quand même pas mal d'applications vers le web. Je pense à des applications SaaS, des infrastructures cloud comme AWS, Google. Et en fait, ce qu'il faut comprendre, c'est qu'aujourd'hui, Internet est devenu votre réseau d'entreprise. Donc, parce que la bande passante et la fiabilité du réseau sont quand même beaucoup à améliorer, vos utilisateurs, votre personnel, va accéder à des applications comme Workday, Salesforce, directement via le web. Ce qui fait que la façon dont on pense la sécurité doit changer. Donc, l'idée avec SASE, c'est de créer des réseaux dans le cloud et d'avoir cette sécurité, les contrôles que vous avez aujourd'hui on-prem, mais dans le cloud. Donc, d'avoir des contrôles partout, tout le temps pour tout le monde. Donc, c'est vraiment un changement de concept que SASE apporte. Donc, avec l'approche SASE, l'intelligence et les contrôles ne sont, comme je l'ai dit, plus sur site, mais vont aller s'exécuter dans le cloud. Donc, ce que vous faites aujourd'hui on-prem, le firewall, l'accès VPN, la surveillance des données, avec, par exemple, du DLP, l'idée, c'est de prendre ça et de le faire dans le cloud. Et dans le cas de Cloudflare, on va vraiment le faire à l'Edge. Donc, c'est vrai qu'on demande quand même beaucoup de choses ici au cloud, de gérer beaucoup de trafic, beaucoup d'utilisateurs. Donc, on a plus grand une grande capacité réseau et c'est vraiment ce que va proposer Cloudflare. Donc, le réseau Cloudflare, c'est l'un des plus importants du monde. On a 348 Teraoctets de capacité par seconde et on a 95% de la population connectée à Internet qui a 50 millisecondes ou moins du réseau Cloudflare. Donc, c'est vrai que ces chiffres, parfois, on a du mal à se les représenter, mais 348 Teraoctets par seconde, c'est 70 fois plus que la plus grande attaque des DOS observée sur Cloudflare à ce jour. Donc, maintenant, la question que vous posez, c'est comment on peut mettre en place l'architecture SACI avec Cloudflare. Donc, on a plusieurs composants dans cette architecture. Connecter les applications, connecter les réseaux, connecter les devices, etc. Mais pour commencer, l'idéal est de débuter avec les applications auxquelles vos utilisateurs ont accès. Ça va être le plus simple. Donc, quand on parle d'applications, on a deux types d'applications. Les applications auto-hébergées, donc les applications que vous gérez vous-même, et les applications SaaS comme Salesforce, Workday, etc. Et ces applications SaaS, même si vous n'avez assez peu de contrôle par rapport aux applications vous-auto-héberger, on peut les rendre uniquement accessibles à votre réseau. Donc, pour les applications auto-hébergées, la première chose qu'on peut faire, c'est de mettre en place des tunnels sécurisés entre vos serveurs et Cloudflare. Donc, pour rappel, l'idée, c'est que Cloudflare devienne votre réseau d'entreprise. Donc, on va en fait déployer un tunnel sur le serveur de l'application ou sur votre réseau local. Et ce tunnel, lui, va se connecter directement à Cloudflare avec plusieurs connexions, à plusieurs POPs Cloudflare pour avoir un maximum de résilience. Donc, les utilisateurs, en fait, se connecteront à Cloudflare. Il lui-même est connecté à votre application on-prem. Ça, c'est pour les applications auto-hébergées. Maintenant, comment ça marche pour les applications SaaS ? Alors, en fait, on a plusieurs techniques, mais la première, c'est d'utiliser Cloudflare comme un proxy SSO. Donc, je vais vous donner un exemple. Ici, quand mon utilisateur se logue sur Salesforce, en fait, on va rediriger le SSO sur Cloudflare. Ensuite, sur Cloudflare, notre utilisateur, il va devoir choisir son IDP. Donc, Okta, Google ou autre chose, vous choisissez. Et ensuite, Okta redirige sur Cloudflare avec les informations sur l'utilisateur, dans quel groupe il fait partie. Et en fait, on va pouvoir utiliser ces informations dans une politique d'accès sur Cloudflare pour autoriser l'accès ou non à Salesforce. Maintenant, aussi, pour aller protéger les informations de Salesforce, nos informations confidentielles qui existent en Salesforce, on ne va pas pouvoir demander à Salesforce d'installer des choses directement sur ses serveurs. Alors, comment on va faire pour protéger nos données, avoir une visibilité sur qui, quel utilisateur accède quoi sur Salesforce ? Je vous donne un exemple. Comment on va faire pour empêcher un utilisateur sur Salesforce de télécharger des contrats confidentiels alors qu'elle ne devrait pas ? Donc, ce qu'on peut faire sur ces applications SaaS, comme Salesforce, c'est premièrement, déjà, limiter quelles sont les IPs qui peuvent se connecter à Salesforce. Donc, dans Salesforce, on va autoriser les accès uniquement aux IPs de Cloudflare. Donc, pour nos utilisateurs, la seule façon qu'ils auront d'accéder à Salesforce, ça sera de passer par le réseau Cloudflare. Une autre application importante à connecter à Cloudflare pour vous, c'est la partie e-mail. Car c'est par e-mail que vous allez recevoir beaucoup d'attaques, comme le phishing, l'envoi de pièces jointes malicieuses, et j'en passe, et des moins bonnes. Donc ici, en fait, Cloudflare va pouvoir vous aider sur cette partie de deux façons. Donc, premièrement, redirigez vos MX Records vers Cloudflare. Donc, cette première option permet de filtrer les e-mails malicieux. Donc, ça marche avec n'importe quel service e-mail. Et la seconde option que l'on a en bas, c'est si vous utilisez Google ou Microsoft, c'est que Cloudflare se connecte via API à Google ou Microsoft et analyse, en fait, à posteriori, les e-mails. Donc, ici, si je récapite ce qu'on a vu pour l'instant, on a connecté nos applications SaaS et auto-héberger, et on a vu la protection des e-mails. Maintenant, la question que vous avez, c'est comment on peut recréer, en fait, votre réseau d'entreprise sur Cloudflare. La partie application, on a pu déployer des tunnels. La partie SaaS, limiter les accès aux adresses IP de Cloudflare et forcer une certification forte avec des politiques, etc. Mais sur la partie réseau, comment ça marche ? Première chose, en fait, on va pouvoir connecter vos hardware, votre hardware à Cloudflare. On peut, par exemple, connecter Cloudflare à des routeurs, à vos routeurs, à vos firewalls. On va pouvoir connecter, créer des tunnels GRI ou IPSect et les connecter directement au réseau Cloudflare. Et on peut même, par exemple, connecter un datacenter entier à Cloudflare. En fait, on utilise ce qu'on appelle le Cloudflare Network Interconnect. En gros, pour simplifier, on connecte vos switches, qui existent dans le datacenter, à nos switches sur Cloudflare. Donc, le trafic ne passe plus par Internet, mais par un lien privé. Maintenant, en fait, on a déjà parlé de la connexion des applications et des réseaux à Cloudflare, mais on n'a pas du tout parlé des utilisateurs. Donc, la question, c'est comment on connecte les utilisateurs qui ne sont pas connectés à un réseau, lui-même connecté à Cloudflare. Donc, l'initiateur qui n'est pas dans votre bureau ou qui est le bureau qui est lui-même connecté à Cloudflare. Donc, comment, en fait, on va connecter un device, un laptop, un téléphone mobile à Cloudflare ? Donc, en fait, on a un agent qui peut s'installer sur les devices et qui va, en fait, créer un tunnel, un petit peu de la même manière qu'on le fait pour les applications. Donc, ici, dans cet exemple, là, on a un tunnel entre le device de l'utilisateur et Cloudflare. Donc, comme je l'ai dit, on peut le faire sur tout type de device, iOS, Android, Windows, Mac, Linux, etc. Et parce que cet agent fait partie de votre réseau sur Cloudflare, en fait, il va pouvoir accéder à d'autres éléments qui constituent notre réseau. Bien sûr, ce qu'on va pouvoir faire, c'est aussi créer des politiques d'accès. On va le voir tout à l'heure pour dire, cet utilisateur a le droit d'accéder à telle ressource ou à telle autre. Donc, comment on fait cette vérification des utilisateurs ? C'est une bonne transition pour parler de la vérification des utilisateurs et des devices. Donc, en termes de vérification, premièrement, on va s'assurer de l'identité des utilisateurs, mais aussi, on va regarder la santé des appareils, la posture des appareils. Donc, pour la partie authentification des utilisateurs, on va s'intégrer à vos IDP existants, Okta et autres. Et on va être capable de synchroniser les groupes que vous avez sur Okta avec Cloudflare. Donc, pour un utilisateur, lorsqu'il souhaite accéder à une application, il va devoir prouver son identité. Il va pouvoir le faire de différentes manières. Donc, en utilisant, par exemple, Okta, il va arriver sur une mire avec plusieurs possibilités. Okta, par exemple, pour nos employés. Mais si on a besoin de donner aussi accès à certaines ressources de notre réseau, à un partenaire, on va pouvoir aussi accepter Azure AD. Et si, par exemple, on a quelqu'un d'externe, un contracteur, comme je l'ai mis ici dans ce slide, on peut aussi lui demander de prouver son identité en recevant un code par email qui devra ensuite rentrer dans la mire. Donc, bien sûr, en fonction de l'application, on peut décider d'accepter tel ou tel IDP. Donc, tout est vraiment configurable. Maintenant, comment on va sécuriser la partie des Vax ? Donc, l'agent Cloudflare One peut s'installer sur les appareils et ce qui va nous donner, en fait, pas mal d'informations sur la sécurité et la santé des appareils. Donc, par exemple, est-ce que le disque dur est chiffré ? Est-ce que le firewall est activé ? Est-ce que l'OS, le operating system, est à jour ? En fait, on va pouvoir vraiment checker l'appareil, faire des vérifications de l'appareil pour savoir si on donne accès ou pas à telle ou telle ressource. A noter qu'on va être aussi capable de s'intégrer avec CrowdStrike CrowdStrike ou SentinelOne ou Titanium pour décider de donner accès, oui ou pas, à une application pour vérifier la santé. Donc, on peut aussi, en fait, écrire une politique accès qui dira qu'on donne accès à une ressource uniquement si CrowdStrike nous dit que c'est OK. Donc, si on fait un récap rapide, ici, sur ce diagramme, on peut voir, en fait, comment les éléments de notre réseau peuvent être connectés ensemble en utilisant CloudFlare. Mais connecter tout ça ensemble, avoir de la visibilité sur nos utilisateurs, c'est utile, mais c'est utile que si on met en place, en fait, des politiques d'accès. Donc, maintenant, la question, c'est comment on décide qui a accès à quoi ? Donc, si je reformule, c'est comment on va écrire des politiques d'accès et comment elles vont fonctionner sur CloudFlareOne. Donc, au niveau des politiques d'accès, on a deux services principaux qui vont gérer les accès. Premièrement, ce qu'on appelle la Secure Access Web Gateway. Donc, typiquement, c'est là qu'on va appliquer des politiques pour du trafic qui va vers Internet, à destination d'Internet. C'est, par exemple, grâce à ça qu'on va s'assurer que nos utilisateurs n'accèdent pas à des sites qui ont des malwares, qui sont pour télécharger, pour faire des téléchargements illégaux, ce genre de choses. Et on a aussi, une deuxième façon, c'est la Zero Trust Network Access. Donc, c'est ici, en fait, qu'on va gérer les routes vers les applications et les réseaux, qui a accès à tel subnet ou pas. Donc, la Secure Web Gateway et le Zero Trust Network Access vont partager, en fait, des politiques qui vont être communes aux deux. Par exemple, la vérification de la posture de la santé des devices et ce que le device est sécurisé. Vérifier aussi l'identité de l'utilisateur, vérifier de quel réseau il vient ou encore faire de la Data Lost Protection pour vérifier, en fait, ce que contiennent les flux, ce que l'utilisateur envoie à l'autre bout du réseau. Donc, je vais vous donner un exemple très, très concret. Donc, ici, en fait, en bas à gauche, on a un employé sur un device qui est sécurisé, qui a notre agent Cloudflare One et lui, ici, il souhaite accéder à notre base de données et à l'outil d'administration de la base de données. Donc, comme il est sur un device sécurisé, la politique d'accès va lui donner accès à l'application, à la base de données. Mais ici, en haut, on a une autre personne, on a un partenaire, un externe, un contracteur qui, lui, par exemple, a aussi besoin d'accéder à cette application. Donc, ce qu'on va pouvoir faire, c'est lui donner accès à l'outil d'administration de la base de données, mais pas à la base de données en tant que telle. Donc, on va pouvoir avoir cette granularité. Et si on souhaite empêcher que cette personne se mette à télécharger des informations sensibles depuis la base de données, ce qu'on peut faire, c'est lui donner accès, mais uniquement dans un navigateur isolé, donc pas son propre navigateur. Et dans ce navigateur, on va pouvoir contrôler complètement, l'empêcher de faire des copies-collées ou de faire des téléchargements. Donc, si on regarde un petit peu plus en détail une politique d'accès, donc, celle de gauche, ici, va bloquer, en fait, des sites à haut risque. Donc, c'est une politique qui va utiliser Secure Web Access Gateway. Ici, en fait, on sélectionne les risques de sécurité, donc, tout ce qui va être malware, phishing, spyware. Et ces listes, ici, on voit Content Catégorie, c'est CloudFair qui va les maintenir pour vous. Des listes qu'on va, voilà, mettre à jour. Donc, ici, dans notre cas, on va interdire l'accès à ces contenus avec une action de bloc. Je vous montre un autre exemple. Donc, imaginons que vous souhaitiez donner accès à certains de vos employés à des sites que vous considérez comme risqués. Par exemple, voilà, Facebook, Instagram, TikTok, etc. Donc, imaginons que vous souhaitez donner accès à l'équipe marketing quand même. Ce qu'on va pouvoir faire, c'est leur donner accès dans un navigateur isolé. Encore une fois, on va pouvoir interdire le téléchargement, l'upload, ce genre de choses. On peut être très granulaire sur quel genre d'action ils pourront effectuer. Cloudflare One est aussi capable de protéger contre les exfiltrations de données ou l'upload de données sensibles dans des systèmes extérieurs à l'entreprise. Et ça, on va le faire avec une politique de Data Loss Prevention Protection. Donc, nous, notre solution a des profils préconstruits pour détecter les informations par exemple financières ou alors de la donnée personnelle ou du code source qui transite vers l'extérieur. Je vous montre un exemple. Ici, à gauche, on a une politique qui dit lorsque l'on détecte des informations liées à des clients et que le domaine fait partie des domaines de l'entreprise, donc les applications auto-hébergées ou alors nos applications SaaS et que la personne est un externe, alors on va vraiment bloquer toute possibilité de téléchargement. Là, c'est autre chose que la partie browser isolation. Là, on va vraiment dans le navigateur dans son propre navigateur l'empêcher de faire les téléchargements. À droite, on a une politique qui dit que lorsqu'on détecte des informations liées à vos clients, des informations financières, etc., on va empêcher qu'elles soient uploadées dans des systèmes externes, cloud, non autorisés par l'entreprise comme Dropbox, Google Drive, etc. Ici, on a une action bloc. On arrive à la fin de cette présentation. Cloud Cloud One est vraiment une plateforme unifiée pour aller connecter vos réseaux et sécuriser les accès. À bientôt. on a unifiée à bientôt. On a unifiée Merci.