Libérez-vous de votre VPN avec Cloudflare Access

Bonjour à tous, bienvenue sur Cloudflare TV. Je crois que c'est la première session en français.

Je m'appelle Stéphane et aujourd'hui, on va faire une démo live, une petite présentation de comment faire de l'accès distant sans VPN avec Cloudflare Access.

Ça me touche beaucoup, c'est la première session, je crois. En Europe, on a commencé hier.

Bienvenue. Vous voyez cette session comme une session de yoga.

Je vais essayer de prendre ma voix la plus douce possible. Prenez un café, détendez-vous.

Cette session va durer 30 minutes. Vous avez aussi la possibilité de poser des questions directement.

Envoyez-les via un email que vous allez voir plus tard dans la présentation.

Alors, la session du jour. Déjà, je vais me présenter.

Moi, je suis Stéphane Nouvellon. Je suis solution engineer chez Cloudflare, à base à Paris.

Ça fait trois ans que je suis à Paris. L 'équipe solution engineering s'occupe de l 'architecture pour nos clients, les aider à intégrer au mieux nos solutions.

Autant en avant-ronde qu'en après-vente. Donc, on est expert autant sur les solutions de nos clients, leur écosystème, que les solutions de Cloudflare et les aider au mieux à les intégrer.

Aujourd'hui, dans l 'agenda, avant de parler de Cloudflare Access, on va faire une présentation générale de Cloudflare.

Qu'est-ce que le réseau ? Qu'est-ce que fait Cloudflare en dehors de ce qu'on va voir aujourd'hui ?

Voir la différenciation des concepts de VPN avec le 0.3 Security, qui nous intéresse dans le cas de Cloudflare Access avec des petits schémas.

Lister quatre points clés et avantages de Cloudflare Access.

La démonstration live, comme le nom de la présentation l'indique. On va voir comment rapidement mettre une application en ligne, la protéger avec Cloudflare Access et qu'est-ce qui est accessible à vous pour suivre un petit peu l'authentification et l'outil en général.

On va se garder un petit peu de temps pour une session de questions-réponses à la fin.

Donc, je vous invite à envoyer vos questions directement à livestudio .Cloudflare.tv.

Je recevrai directement les questions, je les traiterai en live à la fin de la présentation.

Donc, qu'est-ce que Cloudflare ?

Cloudflare, c'est un réseau global, un réseau immense, présent sur 200 villes dans le monde avec une grosse capacité réseau, donc capacité réseau qui sert à gérer la capacité des sites et des propriétés web de nos clients, mais aussi les attaques parce que vous savez qu'on traite trois grands piliers chez Cloudflare, la sécurité, la performance et la reliabilité, la disponibilité.

Aujourd 'hui, ce réseau est mis à disposition des clients, donc ils peuvent créer leur Edge directement chez Cloudflare, peu importe où se trouve leur propriété web, qu'elle soit cloud, qu'elle soit on-premise, qu 'elle soit sur du Docker, qu'elle soit virtualisée ou pas.

Et en fait, Cloudflare, qu'est-ce qu'il fait ?

Il s 'intègre entre les clients ou les attaques et les serveurs web de nos clients.

Donc en fait, plutôt que d'avoir un client vers un serveur, on a un client vers Cloudflare, vers le serveur final.

On est un des réseaux les mieux interconnectés au monde, donc ça, c'est ce qui nous permet de faire la sécurité aujourd'hui.

On traite 26 millions de propriétés web et 11 millions de requêtes par seconde en moyenne.

Donc, ça vous donne un petit peu le niveau d'échelle que l'on traite chez Cloudflare.

Maintenant, la notion, les deux concepts qu'on va voir aujourd'hui, donc le titre de la présentation, c'était faire de l'accès distant sans VPN.

VPN, qu 'on se mette d'accord, il y a beaucoup de terminologie et c'est utilisé dans beaucoup de sens.

Ici, j'entends VPN au sens accès distant vers un réseau cloisonné qui est autorisé pour l'accès distant.

Donc, ça représente quelques limites de notre vision chez Cloudflare et c'est pour ça qu'on s'est orienté vers Zero Trust Security et notamment créer la suite Cloudflare Access de par la disponibilité au travers de ces 200 villes dans le monde.

Donc, une proximité géographique limitée, je prends un exemple, si vous avez un VPN qui est hébergé quelque part, ce quelque part sera, pour ainsi dire, la seule porte d 'entrée pour une performance optimale.

Qu 'est-ce qu'il arrive si vous avez des employés qui se connectent beaucoup plus loin de ça ?

Il faut déjà accéder à la VPN Appliance, l'Appliance VPN, pour pouvoir profiter de l'accès.

Donc ça, ça peut poser des problèmes de performance. Ensuite, la scalabilité.

C'est très difficile de mettre en place des Appliances VPN et des réseaux qui sont partagés de manière scalable, le grossir.

Plus on ajoute des nouvelles entités, c 'est le cas de plus en plus aujourd'hui, quand vous avez une installation qui est principalement un premise dans vos propres datacenters, que vous commencez à créer du cloud, un deuxième cloud, peut-être un cloud privé, etc.

La notion de VPN devient compliquée dans le sens où il faut répliquer l'existant de ce VPN au travers d'infrastructures qui sont différentes, où une harmonisation n'est pas impossible, mais disons difficile.

Bien souvent, ces VPN nécessitent un client.

Donc là, on parle plutôt de usabilité. C'est la notion de, est-ce que l'utilisateur va avoir une expérience optimale ?

Est-ce que ça va être difficile à mettre en place ?

On n'a pas forcément que des populations techniques qui utilisent du VPN, ça peut être surtout avec les conditions actuelles avec le COVID.

C'est l'ensemble, pour ainsi dire, tous les employés qui sont concernés par du VPN.

Donc, ce n'est pas uniquement des populations techniques, c 'est comment leur mettre en place l'outil et leur mettre à disposition de la plus simple des façons.

Et enfin, un accès est attribué au réseau et par extension aux applications, et non aux applications directement.

En général, un accès VPN est donné à un réseau d'interconnexion et ce réseau d'interconnexion est un bassin d 'applications qui est donné à cet utilisateur.

Donc, il y a un accès attribué au réseau.

Là où on va voir que le Zero Trust Security diffère un petit peu.

Donc, la première chose, c'est que le Zero Trust Security, c'est comme son nom l 'indique, pas de confiance.

La sécurité sans jamais de confiance, c'est les users qu'ils soient en interne ou en externe.

D 'ailleurs, cette terminologie-là n'existe plus vraiment.

Il n'y a plus cette notion de je suis au bureau, donc c'est trusté, je suis en extérieur, donc je mets en place de la sécurité.

Zero Trust Security met en place la sécurité partout où vous soyez, basé sur l'utilisateur vers une notion de propriété web, application, peu importe un asset.

Cloudflare Access l 'implémente au travers de son réseau.

Donc, on l'avait vu plus tôt sur la partie performance et la partie sécurité.

Donc, Cloudflare Access fait partie du carcan sécurité.

C'est un réseau immense qui résout un petit peu la proximité géographique limitée.

Là, Cloudflare Access va être votre edge authentifiant et va toujours être très proche de vos clients où qu'ils se connectent.

Il y a une prise en charge des applications, peu importe leur type de localisation.

Donc, ça, ça rejoint un petit peu l 'escalabilité.

Cloudflare Access est le edge.

Cloudflare est agnostique. Notamment, vous pouvez placer une application, mettre en place de l 'authentification dessus, peu importe où elle est, son type, elle sera prise en charge et ça sera harmonisé derrière une authentification unique, une interface d 'administration unique qu'on verra plus tard dans la démonstration.

L'autre intérêt, je dirais, c'est le fait que Cloudflare ne fasse pas que Cloudflare Access, évidemment, on fait aussi de la performance, on fait aussi de la sécurité, pas que de l'authentification, mais du D2, c'est du WAF.

La possibilité d'avoir directement de l'accélération au réseau et des fonctionnalités de sécurité en plus de l'authentification.

Donc, la capacité de jouer d'autres fonctions pour encore améliorer l'expérience des utilisateurs ou encore améliorer la sécurité au-delà de l 'authentification de vos utilisateurs.

L 'accès web se fait sans client.

Pour l 'accès web, c'est Cloudflare Access qui authentifie avec un jeu de redirection.

C 'est assez simple. L'utilisateur est guidé vers son provider d'authentification préféré.

Il va s'authentifier comme il a l 'habitude de faire.

Une fois qu'il sera authentifié, ce provider, je ne sais pas lequel vous l'utilisez, il y en a plein de gérés, on le verra plus tard, va revenir vers nous en disant « oui, cet utilisateur a été authentifié » et on va donner accès à la ressource.

Enfin, l'accès se fait par application, pas par réseau. Il n'y a pas de notion de réseau.

Il y a une application qui est identifiée par son hostname, son chemin, son port.

Peu importe, on authentifie une ressource, une application, une propriété web et on donne accès à une équipe de users, à un groupe directement.

Code Fair Access en quatre points, je dirais, il y en a beaucoup, mais les quatre principaux avantages, c'est que c 'est un contrôle des accès utilisateurs aux applications.

Pas une notion de réseau, mais vraiment vous avez la notion d'application par application, donc une grosse granularité, et des politiques d 'accès vraiment très avancées par application, possibilité de répliquer des groupes d'utilisateurs que vous allez réutiliser beaucoup par exemple sur beaucoup d'applications et de publier sur pas mal de domaines, pas mal de comptes directement dans l'interface.

Déployer et maintenir des contrôles d'accès simplement et rapidement.

Ça se fait via une interface qui est assez user-friendly et tous les changements sont pris en compte directement.

Ça, c'est le cas sur l 'ensemble des choses que vous ferez sur le dashboard de Code Fair.

À chaque fois que vous cliquez, c'est pris en compte dans les trois secondes.

Mise à disposition des applications rapidement et à tout type de périphérique.

Alors, Code Fair Access se lie bien avec ce qu'on appelle Argo Tunnel.

Je ne vais pas l'expliquer ici, mais plus dans la démonstration plus tard.

C'est notamment la question que vous aurez « oui, mon application est on-premise, elle est assez complexe, j'ai des firewalls devant, je fais du NAT, c'est compliqué, il me faut des matrices de flux.

» Code Fair a la possibilité de vous proposer des VPN directement, enfin des VPN, des petits tunnels de vos applications vers le Edge de Code Fair pour vraiment simplifier tout ça.

En gros, en clair, ce n'est pas Code Fair qui va s 'authentifier à vos applications, mais vos applications qui vont s'authentifier à Code Fair pour que les questions de NAT, les questions de matrice de flux soient vraiment simplifiées.

La connexion est sortante de votre application vers Code Fair et Code Fair gère l'authentification sur cette application.

Ça peut permettre d 'accélérer la mise à disposition d 'applications quand vous avez des processus longs de sécurité qui se posent les questions de qui accède à quoi, comment on met en place, quel type d 'authentification, etc.

Code Fair Access et Argo Tunnel peuvent aider à ça.

Enfin, une posture entreprise, c'est toujours la notion, après l'authentification, c'est la non-réplication, c'est l'accès aux journaux de log, qui s'est connecté, quand, où, quelles modifications ont été faites, même intégrées dans une notion de SOC.

Tout est disponible, il y a des journaux d'accès, il y a les changements de configuration, il y a la possibilité d 'exporter les logs directement via un outil de log management ou un SIEM, directement, et on verra ça pendant la démonstration.

Justement, la démonstration, on en parle.

Là, vous avez un petit schéma, une cinématique de comment se passe l'authentification avec Code Fair Access.

Il y a quatre groupes. Il y a les employés, partners, attackers, tout ce que vous voulez, les clients publics qui s'authentifient à leurs ressources.

Code Fair Access est le produit directement situé dans le Edge, qui va gérer, qui va jouer l 'authentification.

L'Identity Provider, qui n'est pas Code Fair, mais qui est vraiment ce que vous utilisez pour vous authentifier.

Là, vous avez des petits logos, des choses qu'on supporte.

On en supporte beaucoup plus. Si vous avez de l 'AD on-premise, si vous avez de l'Azure AD, si vous avez du SML générique, si vous avez du Google, ça sera géré directement, directement configuré dans Code Fair, proposé à vos utilisateurs de se connecter.

La troisième partie, j'en parlais, c'est la partie Argo Tunnel.

C 'est la capacité que vous avez d'ouvrir des tunnels privés de vos applications vers le Edge de Code Fair pour simplifier la notion de mise en place de règles, de NAT, de publications d'applications, simplement.

Et le dernier groupe, enfin, c 'est votre infrastructure, application interne, propriété web, appelez-le comme vous voulez, c'est ce que vous mettez à disposition à vos employés.

Voilà pour cette partie.

Alors, la première chose qu'on va faire, donc là, dans cette démo, ce que je vais faire, je vais faire tourner un petit Docker, un petit serveur web qui s'appelle HTTP Bean, pour ceux qui connaissent.

En fait, ce que je veux mettre en exergue ici, c'est le fait que moi, je suis sur un ordinateur, je suis sur une connexion Freebox qui n'a pas de connexion extérieure, c'est du NAT sortant, il n'y a rien d'entrant et c'est la possibilité que j'aurais si je me mettais dans la peau d'un développeur, de développer une application, de la mettre en place sur un Docker et de montrer à mes collègues cette application pour qu'ils s 'y connectent.

Sauf que je ne veux pas qu 'ils s'y connectent sur Internet directement, étant de chez eux et moi de chez moi, on n'a pas de réseau commun authentifié, je vais vouloir mettre de l 'authentification au-dessus.

Là vient jouer Cloudflare Access.

Donc, la première étape, ce que j'aimerais faire, c'est lancer ce Docker, si je fais dans mon historique, c'est un Docker que je n'ai pas construit, c'est un Docker qui existe déjà, qui s'appelle HttpBin, comme je vous ai dit, qui va créer, je vais refermer ça, et si je vais sur mon localhost, normalement, je devrais voir apparaître ce petit serveur HttpBin, qui est plutôt pratique, et on verra plus tard, qui renvoie des headers, ce qui va me servir à vous montrer comment je joue l 'authentification.

C'est plutôt pratique. En fait, c'est ça que je vais chercher à authentifier, à mettre public sur l 'Internet.

Là, mon serveur tourne sur mon localhost. La deuxième chose à faire, si on revient au schéma, c'est de mettre en place Argo Tunnel pour que cette application soit créée, publiée sur Cloudflare au travers de Tunnel, et là, encore une fois, c'est super simple.

Cloudflare a un binaire à faire tourner sur vos applications directement, ou vous pouvez vraiment le dissocier et le mettre sur un layer vraiment destiné que à Argo Tunnel.

Ça s'appelle Cloudflare D. La première phase, c'est de faire Cloudflare D login, et normalement, vous serez redirigé directement vers la page Cloudflare Dashboard pour authentifier votre binaire.

C'est normal, vous allez créer un tunnel, vous allez mettre en place quelque chose qui se connecte à Cloudflare, qui ouvre des tunnels, qui est sécurisé.

Vous allez devoir prouver. Moi, je suis déjà connecté sur le Dashboard, c 'est pour ça que ça ne m'a rien demandé.

Ne vous inquiétez pas. Je suis bien authentifié en tant que Stéphane à Cloudflare.com.

Le domaine sur lequel je vais faire la démo sera stéphane.ja.

Si j 'autorise, normalement, le binaire a mis en attente quelque chose.

C'est déjà fini. Il a mis en attente quelque chose. Il y avait une rotation, il y avait une attente.

Ça a détecté le clic de mon côté, donc l'authentification.

J'ai bien eu la preuve que j'étais authentifié. Et là, il y a un certificat qui a été téléchargé sur ma machine.

Ce certificat-là, le login, en gros, ce binaire-là, vous pouvez le gérer en mode démo.

Évidemment, on ne va pas vous demander du login et password.

L 'authentifiant sera directement inclus dans le certificat.

La deuxième démarche, c'est de créer le tunnel. Là, la commande, elle ressemble à ça.

Elle est assez simple. CloudFerdy, tunnel. Vous verrez toujours le binaire avec ce que vous voulez faire.

Avant, j'ai fait du login. Maintenant, je crée un tunnel.

Je crée un tunnel pour ce hostname-là, puisque mon application, je vais la mettre à disposition de mes collègues, comme j'ai dit, et ils auront accès via demo.stephane .jl.

Et l'URL que ce binaire va connecter à ce hostname, publiquement, il va connecter à mon localhost.

Si ça avait été sur une autre machine, je n'aurais pas mis localhost, j'aurais mis une destination autre.

Mais là, comme ça tourne sur localhost, je vais la mettre ici. Là, ce qui va se passer, c'est que le binaire va vérifier le certificat, qu'il ait bien la possibilité de s'authentifier, d'aller créer un hostname, parce qu'il y a un appel fait à l'API.

La création de l 'entrée DNS est faite par CloudFerdy. Aussi, vous n'avez rien à faire, il y a juste à lancer cette commande, à l'arrêter quand vous avez fini, tout sera fait automatiquement.

Et enfin, ouvrir des tunnels.

Là, vous voyez que ici, depuis, moi je suis basé à Paris, j'ai ouvert deux tunnels.

Un premier vers Bruxelles et un deuxième vers Charles de Gaulle. Ça, c'est des notions de disponibilité.

S'il y a un problème d'accès dans un des deux datacenters, le binaire pourra directement récupérer les connexions si elles sont perdues.

Là, la route est en train de propager. Normalement, il me dit que ça va mettre une minute pour la nouvelle route à être disponible.

Et là, cette fois, je devrais avoir la possibilité de démo .stephane.ie Là, j'y ai directement accès.

Vous y avez directement accès également, c 'est directement sur Internet.

Vous accédez sur Internet à une application qui est sur Cloudflare et qui finit directement sur mon laptop sans avoir la possibilité de vous connecter directement sur mon laptop.

Là, la prochaine étape, comme je vous ai dit, je vais partager cette URL avec mes collègues.

Je ne veux pas avoir de personnes qui s'y connectent que je ne connais pas.

Donc, mettre en place de l'authentification, c'est plutôt approprié ici.

Ce qu'on va faire, c'est qu 'on va aller dans l'interface de Cloudflare.

Je ne sais pas si vous la connaissez déjà. Ce n'est pas le but ici de la présenter, mais en général, elle est vraiment très simple à utiliser.

Beaucoup de boutons ici qui représentent l'ensemble des fonctions qu'on vient de citer.

Access, notamment, se trouve ici avec la petite porte.

Ici, on retrouve les types de familles qu'on a cités avant.

Les Identity Providers, ce qu'on appelle Login Methods ici, si je peux en créer d'autres.

Par exemple, ici, d'autres méthodes. Moi, celle que j'utilise, c'est Google.

Assez simple, que j'ai déjà configuré. On ne va pas voir comment le configurer ici, mais en gros, c'est assez simple de le faire.

Vous avez une démarche très bien expliquée.

Vous allez sur votre compte Google, client secret, client ID.

Tout va marcher directement. Vous avez un bouton de test aussi pour vérifier que ça va bien marcher.

Deuxième chose, la création de la policy.

Là, je n'ai pas de politique en place. J'ai juste un access group de tests.

Une politique, c'est comment dire à Cloudflare que quel requête va être authentifiée et comment.

Là, je n'en ai pas, donc tout mon trafic qui passe sur stephane.ga.

Vous l'avez vu, si je me connecte, pas d'authentification, j'ai directement l'accès à la propriété, etc.

Super. Maintenant, ce qu'on veut faire, c 'est créer une politique d'accès pour mon démo.stephane.ga, pour mon accès – on va l 'appeler comme ça – développeur.

Mon accès développeur.

Le domaine qui est en question, c'est démo.stephane.ga. Vous avez la possibilité de restreindre l 'authentification uniquement sur un chemin précis.

Je prends l'exemple de WordPress. C'est celui qui va parler à tout le monde, le slash wp-admin, par exemple.

Si ce n 'est que celui-là qui vous intéresse, vous avez la possibilité de l'authentifier.

Si vous n'en mettez pas, on voit dans ces optionnels, l'ensemble des choses sera authentifié.

On reçoit une connexion sur démo.stephane.ga, ça va triggerer cette règle-là et on va commencer l 'authentification.

La durée de la session, ça représente la durée pendant laquelle le cookie va être valide.

Une fois que vous vous authentifiez, vous avez un cookie qui est droppé.

Vous verrez, c'est une autorisation. On le verra plus tard. C'est un token JWT.

Et là, je crée ma politique. Mes devs, je vais les autoriser quand leur email termine par Cloudflare.com.

Assez simple. Dépendant du service provider que vous utilisez pour l'authentification, vous aurez d'autres paramètres, notamment les groupes.

Si vous avez de l'Azure AD, par exemple, vous avez des groupes, le groupe membership qu'on l'appelle.

Possibilité de récupérer ça et de le faire pas sur les emails, mais directement sur des groupes.

Il n'y a pas que l 'authentification par login, password.

Il y a des choses qui sont plus programmatiques.

Vous pouvez aussi authentifier avec du MutualTLS. Vous pouvez authentifier avec du service token.

Vous verrez ici ValidCertificate, des services token, etc.

Ce n'est pas le but de la présentation aujourd'hui, mais c 'était juste pour vous préciser que l 'authentification ne se fait pas uniquement par login, password.

Elle peut se faire par d'autres choses parce qu'il y a beaucoup de questions qui se posent sur j'aimerais authentifier des services, par exemple, de monitoring.

Mais ces services de monitoring, évidemment, qui ne vont pas utiliser du login, password.

J'aimerais le faire de manière programmatique. Donc, oui, la réponse est oui.

C'est possible de le faire. Les politiques peuvent se stacker, se mettre en plus, exclure certaines personnes.

Donc, c'est les emails qui terminent par Cloudflare, mais j'exclus de ces personnes ce type-là.

Et des advanced settings qui concernent uniquement les course settings, donc le cross-site origin configuration.

Ces headers-là peuvent être configurés directement dans Cloudflare Access.

Je vais bouger ça.

Normalement, il devrait être bon. Donc là, j'ai mis en démo que je sauvegarde.

OK, super. Donc, mon accès développeur, normalement, est fait sur demos.stephane.ie.

Je vais demander aux gens de s'authentifier et je vais laisser passer uniquement ceux qui ont un email terminant par Cloudflare.com.

Donc là, on voit que si je rafraîchis la page, tout de suite, Cloudflare a pris en compte.

J'ai appuyé sur Save, j'ai peut-être attardé 5 secondes.

Vous voyez, c'est déjà mis en place.

J'ai ma login page et mon look and feel. Je l'ai mis avec l'orange de Cloudflare, le petit logo de Cloudflare.

Vous pouvez mettre le vôtre, il n'y a pas de problème.

La page sera la même, l 'expérience sera la même pour l'ensemble de vos utilisateurs.

Et ils auront la proposition de se signer avec un provider. Donc moi, dans mon cas, je n'en ai qu'un, c'est Google.

Et donc, je vais m 'authentifier avec.

Et là, ça y est, j 'accède à demos.stephane.ie. Et j'ai été authentifié avec mon adresse email qui finit par Cloudflare.com.

Là, il y a des choses intéressantes qui arrivent.

C'est une première question qu'on a quand on n 'utilise pas forcément ArgoTunnel, mais qu 'on utilise l'intégration avec Cloudflare.

Donc Cloudflare qui est une entité publique et l'application unprotégée qui est une entité publique.

C'est comment faire en sorte que l'authentification de Cloudflare ne soit jamais bypassée.

Alors nous, quand on authentifie les gens, vous voyez que CFaccess, JWT, Assertion, on envoie systématiquement.

Déjà, on joue l 'authentification au niveau Cloudflare.

Vous voyez que l'authenticalité du user email, c'est bien stephane.ie.Cloudflare .com.

Ça matche bien avec ma politique. Ensuite, vous avez la possibilité d 'échanger avec l'application l 'authentification qui a été jouée et qu 'est-ce qui a été inclus dedans.

Dans ce JWT-là, vous avez d'un coup beaucoup de choses.

Vous pouvez les checker d'ailleurs si je vais sur jwt.io.

Vous pouvez le débugger. Il est ici, le débuggeur.

Voilà. Vous avez la possibilité de le décompiler et de vérifier la signature comme quoi ça arrive bien de Cloudflare directement via un certificat.

Certificat qui a récupéré, vous trouverez ça dans la documentation, a récupéré directement via une API spécifique pour vraiment vérifier la signature.

Vous verrez qu'ici, la signature est invalide. C'est normal. J'ai juste positionné le JWT.

Là, on voit bien que l'authentification a été faite pour stephane.Cloudflare.com.

Voilà pour cette partie-là. Là, j'ai été authentifié. L 'application reçoit bien.

Dans mon cas, je ne veux pas valider l'assertion JWT parce que j'ai de l'argot tunnel directement.

Si vous voulez le faire, vous avez la possibilité de le faire.

Vous avez des recettes disponibles sur developers .Cloudflare.com, section Cloudflare Access qui vous explique comment valider en plusieurs langages de développement ce JWT pour le reproduire de votre côté.

La dernière question qui se pose, c'est une fois que mes utilisateurs s'authentifient, comment gérer ma masse d'utilisateurs qui vient, qui s'authentifie, quand ou comment ?

Ça se passe ici. Vous avez des événements qui sont assez haut niveau, qui n'ont pas beaucoup de détails, mais qui valent la peine malgré tout.

Vous voyez qui se connecte, etc.

Vous voyez qui a été interdit aussi. Vous voyez les changements qui ont été faits sur les politiques.

C 'est plutôt utile pour voir qui modifie, qui crée des nouvelles politiques pour faire de l'audit, par exemple.

L'ensemble de ces choses est disponible à l'extérieur de Cloudflare aussi.

Vous n'avez pas utilisé le dashboard de Cloudflare.

Vous pouvez vraiment les exporter de votre côté.

Ce qu'on va faire maintenant, c'est que je vais vous montrer la capacité que vous avez si vous avez des projets SIEM, par exemple.

Moi, j'ai un Kibana qui tourne où j'ai les logs de Cloudflare directement dessus.

Je vais vous montrer la capacité que vous avez à corréler le trafic web que vous accélérez, que vous protégez, etc.

Mais le corréler également avec les utilisateurs qui s'y sont connectés.

En face de chaque log Cloudflare, quand on gère des logs normaux, on va dire HTTP, on voit du user -adjoint, est-ce que ça a été HTTP, etc.

On va positionner un nouveau header, un nouveau paramètre qui va être ce qui nous intéresse ici, l 'utilisateur qui a été authentifié.

Dans mon cas, vous voyez que cette requête-là qui a été faite, c'est la requête sur démo, vous voyez que j'ai une requête qui correspond à ça.

J'ai beaucoup d 'informations, mais l'information qui m 'intéresse, c'est stephane.Cloudflare.com.

C'est plutôt intéressant si vous voulez mettre en place des scénarios d'analyse et de détection de fraude, si vous avez des comptes qui bougent beaucoup entre pays.

C 'est plutôt intéressant parce que nous, on propose vraiment beaucoup de choses déjà de base sur le caractère HTTP de la requête, comme je l'ai dit.

Le client qui s'est connecté, quel était le type de protocole, beaucoup de choses que vous pouvez croiser avec cette information d 'authentification.

Je pense que c'est bon pour la présentation.

Je vois qu'il est 10h26, il nous reste 4 minutes pour les questions.

Je vais regarder si on a reçu des questions.

On en a reçu.

Oui, on en a reçu. La première, c'est qu'en est-il des applications qui ne sont pas HTTP ?

Là, on a montré le HTTP. Évidemment qu'il est possible de faire aussi du non-HTTP.

On a un bel exemple chez Cloudflare. On a bougé pas mal de choses, beaucoup de nos process sur Cloudflare Access.

Cloudflare Access ne gère pas que de l'HTTP.

Nous-mêmes, au jour le jour, on ne gère pas que de l 'HTTP.

Sur la partie non-HTTP, néanmoins, il y aura un client nécessaire pour jouer cette authentification.

C'est le même que le côté serveur, le Cloudflare D, qu'on a vu sur mon ordinateur.

C'est le même côté client qui va agréger, qui va gérer l 'authentification de la personne et qui va après jouer le Zero Trust Security sur les destinations qui seront authentifiées directement.

Donc oui, on gère le non -HTTP.

Très bien, il n'y a pas de problème. La deuxième question, c'est une question par rapport au prix.

Le prix, le pricing model fonctionne par utilisateur, par mois roulant.

Je m'explique, c'est la quantité de users qui ont été authentifiés au travers de Cloudflare Access par mois.

C 'est une fenêtre glissante de 30 jours.

Vous pouvez avoir une compagnie de 5 000 utilisateurs par exemple, de 5 000 employés.

Ils ne vont pas tous se connecter chaque mois.

On va tourner. Et ça, c'est ce qu'on regarde pour le prix de Cloudflare Access.

Vous avez sur, si vous tapez dans Cloudflare Access pricing, vous avez un simulateur, vous mettez votre nombre d'utilisateurs, le service provider que vous utilisez pour authentifier, ça vous donnera un prix estimatif.

La licence par utilisateur par mois est à 3 $ le prix de départ.

Est-ce qu'on a d'autres questions ?

On n'a pas d'autres questions. On n'a pas d'autres questions.

Merci à tous. J'espère que c'était clair. Je pense que c'est un bon aperçu de Cloudflare Access, un peu rapide.

En 30 minutes, on ne peut pas voir beaucoup de choses, mais j'espère que ça vous donnera, mettra le pied à l'étrier pour expérimenter avec.

En termes de ressources utiles, je vais revenir rapidement à mes slides.

Il y a des choses que vous pouvez utiliser si vous êtes intéressé par Cloudflare Access.

La première chose, c'est Developers, j'en parlais.

C'est notre hub développeur qui vous donnera plein d'informations, Access en particulier, techniques dessus.

Une information et pas des moindres, c'est que Cloudflare Access est gratuit au travers du programme COVID-19 que nous avons chez Cloudflare.

Dans le dashboard, vous aurez la possibilité d'activer et d'utiliser Cloudflare Access gratuitement sans limite jusqu'au 1er septembre.

Après le 1er septembre, normalement, vous serez contacté directement via l'interface pour convertir ça, via un plan payant suivant votre utilisation.

Ça peut être plutôt utile si vous avez encore des employés travaillant à distance.

Voilà pour moi, c 'est tout.

A vous les studios. Merci beaucoup.