Proteger ses applications internes sans VPN

C'est parti ! Bonjour à tous, je m'appelle Thibault Meunier, je suis ingénieur système à Cloudflare et aujourd'hui je vais vous présenter comment protéger vos services internes sans utiliser VPN. Pour cela, au cours de l'appréhension et de la démonstration que je vais vous faire, on va commencer par parler du système qu'on va vouloir protéger. Ensuite, on va passer sur Cloudflare Access et comment Cloudflare permet de protéger ce système de manière simple. Finalement, on va passer sur une démonstration sur comment on a réussi à protéger ce système via Cloudflare Access. Tout d'abord, comme je vous l'évoquais, nous allons présenter le système à protéger. Ce système est relativement simple, c'est une machine virtuelle qui fait tourner Ubuntu qui tourne sur mon ordinateur. Cette machine virtuelle fait tourner deux applications qui vont nous intéresser. Elle fait tourner une application web qui est Jira, qui est un outil de project management qui est fourni par Atlassian. Et on a également un serveur SSH, SSHD, qui permet d'administrer la machine à distance et ce par une équipe technique. Les objectifs qu 'on a sur ce système et ce qu'on aimerait effectuer, c'est que la machine ait seulement accès à Internet en connexion sortante et pas de connexion en trans, ce qui nous permet d 'avoir un pare-feu beaucoup plus sécurisé. Ensuite, on voudrait pouvoir que les utilisateurs se connectent à Jira sans accéder à un VPN. Ils puissent se connecter directement depuis leur navigateur web avec leur système d 'authentification normal. Et finalement, on aimerait également que les administrateurs aient une politique d 'accès différente, qu'ils puissent accéder au service SSH pour se connecter directement à la machine. Pour cela, comme je vous l'ai dit, on va utiliser Cloudflare Access, qui est une solution proposée par Cloudflare qui permet de s 'authentifier et d'accéder et de protéger vos ressources. Dans l'ensemble, Cloudflare Access s'inscrit au milieu de notre infrastructure et agit un peu comme un reverse proxy. Les utilisateurs se connectent à Cloudflare Access qui va ensuite parler à votre fournisseur d 'identité, que ce soit Google, Azure AD ou d'autres fournisseurs d'identité qui sont intégrés à Cloudflare. Et finalement, vous avez vos ressources qui, avec une connexion sortante, vont se connecter directement à Cloudflare. Dans l'exemple et le cas qui nous intéresse, les ressources que nous avons à protéger, c 'est la machine virtuelle et plus particulièrement deux services. Ces deux services sont Jira, qui est une application web, et le serveur SSH, SSHD. Le fournisseur d'identité que nous allons utiliser, c'est GitHub. Mais comme je l'ai mentionné précédemment, vous pouvez tout à fait intégrer Google, Azure AD ou d'autres services qui sont proposés par Cloudflare Access. Et finalement, l'utilisateur dans tout ça, pour l'instant ce sera moi, qui vais jouer à la fois le rôle d'utilisateur habituel de l'entreprise et également le rôle d'administrateur, puisque je vais pouvoir me connecter en SSH. Cette politique d'accès est définie via le panneau de configuration de Cloudflare avec une stratégie d'accès. Comme vous pouvez le voir, j'ai autorisé sur tous les domaines qui sont en dessous de tibo.uk seulement les utilisateurs qui ont un email terminant par tibomini.com ou tibo .uk à s'identifier. Et cette politique, vous pouvez créer plusieurs politiques, vous pouvez également avoir des groupes, comme nous le verrons par après. Finalement, nous aimerions comprendre un peu le chemin d'une requête et comment est -ce que tout ça marche. La requête est tout d'abord initiée par l'utilisateur. Et cet utilisateur va vouloir accéder à un domaine qui est en dessous de tibo.uk. tibo.uk est un DNS qui est géré par Cloudflare. L'utilisateur va faire une requête vers Cloudflare. Cloudflare va faire tout un service d'identification que je vais présenter juste après et va retourner un jeton JWT à l'utilisateur, lui indiquant les droits et les permissions qu'il a sur le système. L 'utilisateur accédant à tibo.uk depuis son navigateur web, ce token est stocké en cookie, ce qui lui permettra par la suite, de manière transparente, de repasser ce token dans les requêtes futures. Ensuite, nous avons l'identification, qui est gérée par Cloudflare et votre fournisseur d 'identité, dans le cas de GitHub. Cloudflare va proposer à l'utilisateur de s'identifier via GitHub et utiliser via le protocole OAuth une identification, le callback de cette authentication OAuth revient à Cloudflare, ce qui nous permet en tant que Cloudflare de vérifier l 'identité de l'utilisateur. Et finalement, la connexion au serveur, donc c'est les ressources que l'on veut protéger. Comme on peut le voir sur le graphique, le serveur n'est pas exposé directement à l 'utilisateur et donc l'IP n'est pas publique. Le tunnel sortant qui tourne sur votre infrastructure se connecte à Cloudflare et cette connexion est initiée par ce serveur. On remarque également que comme vous êtes connecté directement à Cloudflare, plutôt que d'utiliser une ressource qui tourne directement dans votre centre de données, vous bénéficiez des divers services de sécurité et de performance qu'offre Cloudflare, c'est-à -dire une répartition de charges, un pare -feu, des protections contre des démis de services et également l'accélération de trafic. Maintenant que je vous ai fait cette petite introduction, on va pouvoir passer à la démonstration et concrètement comment est-ce qu'on a réussi à protéger nos diverses applications et pour cela on va commencer par une démonstration, une présentation un peu plus détaillée du système. Le système, comme je vous l'ai dit, c'est une machine virtuelle qui fait tourner le compte tout. J'ai également Jira qui joue le rôle d'application web et HTTP qui tourne sur le port 8080. J'ai mon serveur SSH qui tourne sur le port 22. J 'ai également préalablement installé Cloudflare-D. Cloudflare-D est disponible à l'adresse suivante. C'est également un client dont la source est sur GitHub et que vous pouvez recompiler pour votre infrastructure si vous avez des besoins particuliers. Le client est disponible pour Linux, Mac et Windows donc la plupart du temps vous aurez juste à installer le binaire qui est fourni par Cloudflare. Nous allons utiliser deux domaines qui sont sous tibou.uk qui est le domaine que nous allons utiliser dans la démonstration. On va utiliser jira.tibou .uk qui nous permettra de nous connecter à Jira. On va également utiliser ssh.tibou .uk qui nous permettra aux administrateurs de se connecter en SSH au système. Pour cela, je vais vous présenter la machine virtuelle. La machine virtuelle est ici. J 'ai ouvert un terminal dedans. Sur cette machine virtuelle, comme je vous l'ai dit, je fais tourner Jira sur le port 8080. Quand j'accède depuis mon navigateur web et navigateur web de la machine à localhost 8080, il me demande de me connecter à Jira. C'est en interne. Je vais lui demander de retenir ma connexion. Ce sera plus rapide. Quand je me connecte, j'accède au système Jira sur lequel je suis administrateur et donc j'ai toute la partie administration directement en local. C'est une machine à laquelle j 'aimerais accéder à distance. Pour l 'instant, quand j'accède à jira.tibou.uk, rien n'est disponible, mais j'ai quand même protégé l'application via Cloudflare Access. Comme vous pouvez le voir, cette application est protégée par Cloudflare Access. C'est un logo que vous pouvez tout à fait adapter en fonction de votre entreprise. Vous pouvez modifier à peu près toute la partie design, c'est-à-dire avoir votre logo, avoir une couleur de fond qui reflète celle de votre entreprise. On pourra se connecter avec GitHub ou avec un token, un jeton qui est envoyé une fois par Cloudflare. Pour ce faire, il faut d'abord qu'on puisse récupérer un certificat pour s 'authentifier à Cloudflare. C'est ce qui permet d'avoir une connexion sortante. On va obtenir un certificat à Cloudflare et après, pour les connexions futures, le tunnel va utiliser ce certificat pour s 'authentifier auprès de Cloudflare et être identifié comme le possesseur du domaine. Pour ce faire, on utilise le daemon Cloudflare-d, comme je vous l'ai dit précédemment. On utilise Cloudflare-d -tunnel-login, ce qui veut ouvrir une page web. Sur cette machine virtuelle, je m 'étais également connecté à mon compte Cloudflare, ce qui me propose les domaines qui sont gérés par Cloudflare sur mon compte et on veut se connecter à tibou.uk. Est-ce que je vais autoriser une connexion à votre tunnel pour tibou.uk ? Oui. Je l 'autorise. Cloudflare génère le certificat et va enregistrer le certificat sur la machine. Comme on le voit, c'est une réussite et Cloudflare va installer le certificat sur la machine. Si on revient sur le terminal, ce certificat a été installé, la commande s'est terminée et mon certificat est disponible sur le chemin suivant, qui est le chemin de mon initiateur par défaut, dans le dossier Cloudflare-d et le certificat est cert .pen. Ce certificat, vous pouvez le générer sur une machine qui n'est pas la machine virtuelle et ça vous permet de le transférer. Une fois qu'on a obtenu le certificat, on va vouloir maintenant se connecter aux applications directement à Cloudflare. Pour commencer, on va vouloir connecter Jira. Pour connecter Jira, maintenant que le certificat est installé, j'utilise Cloudflare des tunnels. Nous voulons nous connecter à une URL locale, c 'est-à-dire HTTP localhost 8080, qui est l 'URL de Jira en local. Ensuite, nous voulons également exprimer sur quel domaine on veut se connecter à distance. Ce domaine auquel on veut se connecter à distance et pour lequel nous voulons que l 'application soit disponible, c'est jira .io.uk. J'utilise tout ça, j'ai pas mal d 'informations qui sont affichées sur la console. Ces informations, on peut voir que le tunnel, il va transférer les requêtes de localhost, comme nous l'avons dit. On a également un serveur de métrique Prometheus qui est hébergé en local, ce qui nous permet d'avoir et de surveiller le trafic qui passe. On remarque qu'il s 'est connecté quatre fois. En fait, quand vous vous faites tourner Cloudflare Day, il ouvre plusieurs connexions aux divers centres de données Cloudflare, ce qui permet, en cas d'une connexion défaillante, que votre application reste toujours en ligne. Votre application est très certainement disponible et nous allons pouvoir voir sur mon ordinateur. Si j'accède à jira.io.uk, normalement, il nous redirige directement vers Jira. Et c'est le cas. Donc là, on s 'est connecté via Github, etc. Ce que je vais faire, c'est que je vais me déconnecter. Et quand je me déconnecte, on voit que je suis passé par Cloudflare Access. Si je réessaye de m'authentifier à Jira, on va me demander de me connecter à Github ou avec un one-time password. Je vais me connecter via Github et ça me permet de m'authentifier directement à Jira comme si j'étais sur la machine. Comment est-ce que j'ai l'authentification ? C'est effectué. J'ai une politique d 'accès depuis le dashboard Cloudflare qui utilise un one-time password et Github, comme je vous l'ai dit précédemment, et une stratégie d'accès qui est définie, qui permet d'autoriser tibomanu.com et tibou .uk. Mon email Github se termine par tiboumanu.com. La politique d'accès étant validée, il m'autorise à accéder à Jira. On voit également la connexion que j'ai effectuée il y a 9 minutes et les diverses modifications que j'ai pu faire à cette politique d'accès. Ça, c'est l'ensemble des modifications que j'ai pu faire à cette politique d'accès que j'ai configurée hier avec diverses valeurs, ce qui vous permet d'avoir un audit des diverses permissions que vous avez données à vos utilisateurs. Si par exemple, désormais, je modifie cette politique d'accès pour refuser les connexions de tibou.manu.com et tibou.uk et que je révoque le token, utilisateur mensuel, je révoque la session, je révoque les tokens individuellement. Normalement, lorsque je vais redemander un token à Jira, mon accès ne sera pas autorisé. Et c'est ce qu'on voit, ce compte n'a pas accès. J 'ai réautorisé pour les besoins de la démonstration par la suite et notamment pour pouvoir se connecter en SSH, mais ça permet un contrôle fin des permissions. On peut également préciser directement une adresse e-mail ou des groupes d'accès, par exemple, si vous êtes configuré via Azure AD. J'ai réautorisé la session, le token est toujours révoqué, nous le révoquons. Je vais essayer de me reconnecter via GitHub et cette fois-ci, je vais juste vider mes tokens, rafraîchir tibou.uk et normalement, via GitHub, la politique s 'est propagée. Ah, le token a expiré, dommage. Toc, je reconnecte à jira.tibou .uk avec GitHub, la connexion s'effectue. Les tokens étant stockés via les cookies, il se peut qu'il y ait une persistance pendant la durée de validité du cookie de la session. Pour finir, le Jira, en tant que client, je me suis connecté avec mon utilisateur et un compte qui était autorisé avec la Flare Access. J'ai accédé à jira.tibou.uk via un navigateur web. Je me suis connecté avec GitHub, ce qui m'a permis d'accéder directement à Jira. L'un des détails qui a été important lors de cette connexion à Jira, je me suis connecté directement en tant qu 'utilisateur Jira. C'est un plugin installé sur le serveur Jira pour avoir accès à cette application. Ce plugin est disponible directement sur le GitHub de Cloudflare. GitHub.Cloudflare.com, Cloudflare Access pour être la sienne. C 'est un plugin que j'ai installé sur le serveur et que je vais vous montrer dès à présent. Sur le serveur, dans la partie administration, lorsque vous gérez les applications, je me connecte en tant qu 'administrateur. Vous allez pouvoir trouver dans Gérer les applications, ici la page Charge, dans Gérer les applications, j'ai installé la politique, le plugin qui nous permet d 'accéder à Cloudflare. Ce plugin va lire le token JWT qui est envoyé à Jira, le décompresser, regarder si cette signature est valide par rapport au domaine d'accès, et également, Cloudflare Access, lire l'email qui est associé au token. Cet email étant identique à l'email que j'ai configuré pour mon utilisateur Jira, c'est -à-dire mail.tibo.com, est identique à l 'email que j'utilise sur GitHub, le token va être vérifié. Ici, vous avez un token d 'audience qui vous est fourni par Cloudflare. Vous avez également le domaine d'identification, ce sera votre entreprise, dans le cas présent, c'est tibo.Cloudflareaccess.com, et finalement, les domaines que j'autorise à avoir une identification directe, ce sera tibo.com. Je gère les utilisateurs via email, et c 'est comme ça que je peux me connecter directement. Maintenant, la deuxième partie, c'est avoir un serveur qui me permet de me connecter en SSH. La connexion SSH va fonctionner de manière similaire, c'est exactement la même commande, mais plutôt qu'avoir un protocole HTTP, on va se connecter directement en SSH. C'est toujours Cloudflare qui va faire du tunnel, on va ouvrir toujours un tunnel Argo, mais cette fois-ci, l'URL, à la place d'être en HTTP, c'est une URL SSH, qui se connecte en localhost sur le port 22. L'hostname que nous voulons utiliser, c'est ssh.tibo.uk, et nous allons ouvrir le tunnel. Il semblerait que j'ai mal tapé la commande, donc à la place de Cloudflare, c'est Cloudflare-d. Le tunnel marche, il me connecte aux différentes destinations, comme précédemment. Les destinations ici, c'est Manchester et London East Road, étant donné que je suis basé à Londres, ça part à peu près cohérent, c'est les centres de données de Cloudflare les plus proches de ma localisation. On a toujours un serveur de métrique qui s'est connecté. Désormais, ce qu'on va essayer de faire, c 'est se connecter depuis le client, et pour se connecter depuis le client, ça passe également par Cloudflare Access. Cloudflare Access va nous permettre de nous identifier contre Cloudflare via notre navigateur, générer un certificat, et passer ce certificat pour la connexion sortante SSH. Pour cela, je vais utiliser une configuration SSH en local, qui va me dire que le host ssh.tibo.uk, il va utiliser la commande Cloudflare D pour accéder aux connexions SSH. Si je regarde ma configuration SSH, cette configuration SSH, c'est exactement celle que vous avez écrit ici, elle utilise le domaine ssh .tibo.uk, et pour toutes les requêtes qui vont être faites pour ce domaine, je vais passer la commande SSH à travers Cloudflare D. Du coup, s'ils essayent de me connecter en tant que Thibaut à la machine, qui est ssh.tibaut.uk, il va me demander de me connecter et ouvrir une session via mon navigateur web. Comme je vous ai expliqué précédemment, tout ça passe par GitHub, et j'ai réussi à me connecter avec succès. Le token a été généré, et on voit que là, je suis déjà à l'entrée de notre infrastructure, et on demande le mot de passe pour Thibaut sur cette machine. En entrant le mot de passe, on voit que je me suis connecté directement sur la machine via SSH, et je peux, par exemple, lister l'ensemble des fichiers qui sont ici. On voit qu'ici, j 'ai mon installation Atlassian et les divers fichiers que Ubuntu installe par défaut. Sur la machine virtuelle, je liste les fichiers, j'ai exactement les mêmes, j 'ai la même liste. On voit qu'il n'y a pas de fichier précis. Si, sur ces fichiers, je vais en AZT1, par exemple, drapeau.txt, si je vais sur cette machine, ma machine virtuelle, le drapeau .txt a bien été ajouté. C'est ainsi qu'on peut, bien qu'avec l'accès via un tunnel Argo, directement se connecter en SSH. Le cookie étant sauvegardé, si je me déconnecte de la machine, là, je suis du retour sur la machine locale, et pas sur la machine virtuelle. Si je réessaye de me connecter à Thibaut sur ssh.thibaut.uk, le token est déjà enregistré et sauvegardé localement, ce qui me permet de me reconnecter directement. Et avec, toujours, drapeau.txt, les fichiers qui sont présents sur la machine. Ces tokens sont tous sauvegardés dans le dossier CLAFLRD, comme pour la machine, et on peut voir que j'ai mon token, ssh .thibaut.uk token, qui me permet de m 'identifier. Pour finir, il pourrait être intéressant de voir le token qui a été généré, le token JWT qui est généré. Je ne suis pas sûr que je puisse le régénérer ici. Visiblement, si. Est-ce que je l'ai en réponse ? Non, du tout. Si j'accède à jira .thibaut.uk, on va juste ouvrir le navigateur pour avoir les connexions sortantes. Il y avait un rafraîchissement. On va essayer de le rafraîchir pour voir les connexions sortantes. Dans les connexions sortantes, on va récupérer ce token JWT, qui n'a pas été mis là, qui est censé être dans les cookies, qui est la seule autorisation. Si je copie ce token et que je le mets dans mon débugger pour JWT, on voit que le mail qui est utilisé, c'est mail.thibaut.uk, que le domaine sur lequel je veux m 'identifier, c'est thibaut.clapleuraccess .uk, qui gère ma politique d'accès. Mon AUD, c'est ce que j'ai entré dans le jira, qui permet de valider la connexion. Et vous avez également la signature du token, que vous pouvez vérifier par un rafraîchissement. Ceci conclut ma présentation. Si vous avez des questions, je vais regarder le chat pour voir si vous m'avez envoyé des questions. Pour l'instant, je n'ai pas reçu de questions. Il semblerait que la présentation a été enregistrée. Vous allez pouvoir y accéder en voie de diffusion. Merci à vous. Je vous laisse avec la présentation, un panel qui est géré par John-Krahan Cumming sur comment est-ce qu 'on pourra être sécurisé via le web. Merci à vous. Donc, des questions. Pas de questions pour l'instant. Je reste à votre disposition, évidemment. On peut voir, bien sûr, sur jira.tigo.uk, toutes les requêtes qui ont été faites, comme je vous l'ai expliqué, avec ce cookie. C'est ce cookie qui permet de s 'identifier à table. Si je vais un peu plus dans les détails de comment créer des politiques d'application, une chose qui est également intéressante, c'est si vous voulez authentifier un service, par exemple un backup, une sauvegarde pour authentifier vos jetons de jira, vous pouvez tout à fait générer des jetons. Disons que le jeton s'appelle jetons -sauvegarde-ticket -jira. Jeton-ticket-jira, le jeton a été généré avec une clé secrète et un identique client, ce qui me permet ensuite d 'intégrer ce jeton directement dans ma politique d'accès. Pour autoriser ce jeton sur tigo.uk, je vais ajouter une nouvelle stratégie. Cette stratégie, ce sera jetons -sauvegarde-ticket-ticket-jira. Ce jeton sauvegarde, je vais l'autoriser. Ce jeton sauvegarde aura l'identité par défaut. Ce n'est pas quelque chose que Jira aura besoin de garder. J'aimerais qu'un jeton de service, le jeton de sauvegarde-ticket -ticket-jira, puisse être autorisé directement. On voit que cette politique d'accès a été modifiée pour inclure le jeton de sauvegarde-ticket-ticket-jira. Je vous invite également à contacter directement le Cloudflare si vous voulez plus d 'informations sur comment protéger vos applications et pour discuter comment intégrer Cloudflare directement dans votre système. Merci à vous. Optimizely est la plus grande plateforme d 'expérimentation du monde. Nos clients viennent à Optimizely pour développer leur entreprise. Ils peuvent tester toutes leurs assumptions et faire plus de décisions en basant sur des insignes et des données. Nous servons des entreprises les plus grandes du monde. Et ces entreprises ont de très hautes standards pour la scalabilité et la performance des produits qu'Optimizely apporte à leur organisation. Nous avons un snippet de javascript qui va sur les sites web de nos clients et qui exécute tous les expérimentations qu'ils ont configurées, tous les changements qu'ils ont configurés pour les expérimentations. Ce javascript prend du temps pour l'enregistrer, pour l 'enregistrer et pour l'exécuter. Et donc, les clients sont de plus en plus conscients de la performance. La raison pour laquelle nous avons partagé avec Cloudflare est pour améliorer les aspects de performance de certains de nos produits d'expérimentation fondamentaux. Nous avions besoin d'un moyen de pousser ce type de décision-faire et de la compétition à l'extrême. Et les travailleurs ont finalement apparaîtu comme le moyen de choisir. Une fois que nous avons commencé à utiliser les travailleurs, c'était très rapide d'aller vite. C'était comme, oh, je peux juste aller dans ce playground et écrire du javascript, ce que je sais totalement comment faire, et puis ça marche. Donc, c 'était assez cool. Nos clients pourront réaliser 10X, 100X le nombre d 'expérimentations. Et de notre point de vue, cela signifie ultimement qu'ils auront plus de valeur. Et l'impact de l 'entreprise sur notre point de vue fondamental et notre point de vue supérieur va aussi commencer à mirer cela. Workers nous a permis d'accélérer notre vitesse de produit autour de l'innovation de performance, ce qui m'excite beaucoup. Mais c'est juste le début. Il y a beaucoup que Cloudflare fait d'un point de vue technologique que nous sommes vraiment enthousiastes de partener pour que nous puissions améliorer notre innovation. Cloudflare Cloudflare Cloudflare Cloudflare Cloudflare Cloudflare Cloudflare Cloudflare Cloudflare Cloudflare Cloudflare Cloudflare Cloudflare Cloudflare