Originally aired on June 11, 2020 @ 6:00 AM - 6:30 AM EDT
Using an isolated instance of Jira, Thibault will go through the process of setting it up through Cloudflare (opening argo tunnel, setting up access, configuring our plugin)
French
Security
Cloudflare Access
Authentication
Musique Bonjour à tous, je m'appelle Thibault Moulin, je suis chef d'équipe de l'équipe monier, 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 justement de protéger ce système de manière simple. Et 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. Le 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 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 entrante, 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. 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 va 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. L '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, 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, votre fournisseur d'identité, dans le cas de GitHub. Cloudflare va proposer à l'utilisateur de s'identifier via GitHub et d'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, 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élais de service, é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. 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 et 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, c'est ici. J'ai ouvert un terminal dedans et 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 demande de me connecter à Jira et ça 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 qui est directement 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 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 CloudflareD, comme je vous l'ai dit précédemment. On utilise CloudflareDTunnelLogin, ce qui va 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 veux autoriser une connexion ArgoTunnel 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 utilisateur par défaut, dans le dossier CloudflareD 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 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. On peut voir que le tunnel va transférer les requêtes de localhost, comme nous l'avons dit. On a également un serveur de métric 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. Notre application est très certainement disponible, et nous allons pouvoir voir sur mon ordinateur. Si j'accède à jira.tibot.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 l'authentification s'est effectuée ? 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 tibot -money.com et tibot.uk. Mon email GitHub se termine par tibot-money.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é à vos utilisateurs. Si par exemple, désormais, je modifie cette politique d'accès pour refuser les connexions de tibot.money.com et tibot.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. Je vais réautoriser 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 tibot.uk, et normalement, via GitHub, la politique s 'est propagée. Ah, le token a expiré, dommage. Je reconnecte à jira.tibot.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.tibot.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 qui est installé sur le serveur Jira pour avoir accès à cette application. Ce plugin, c 'est un plugin qui est disponible directement sur le GitHub de Cloudflare, donc 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. 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 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.jwt.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 tibot.Cloudflareaccess.com et finalement, les domaines que j'autorise à avoir une identification directe, ce sera tibotmoney .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 d '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 du tunnel, on ouvre toujours un tunnel Argo, mais cette fois -ci, l'URL, à la place d'être en HTTP, c 'est l'URL SSH, qui se connecte en localhost sur le port 22. L'hostname que nous voulons utiliser, c'est ssh.tibot.uk et nous allons ouvrir le tunnel. Ah, il semblerait que j'ai mal tapé la commande, donc à la place de Cloudflare, c'est Cloudflare-d. Voilà, 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 le plus proche 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.tibot.uk 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 je vous ai écrite ici, elle utilise le domaine ssh .tibot.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.tibot.uk, ils vont me demander de me connecter et ouvrir une session via mon navigateur web. Comme vous l'avez 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 fichiers précis. Si sur ces fichiers, je veux en ajouter un, 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 que la Flair accesse via un tunnel Argo, directement se connecter en SSH. Le cookie étant sauvegardé, si je me déconnecte de la machine, je suis du retour sur la machine locale et pas sur la machine virtuelle. Si je réessaye de me connecter à Thibault sur ssh.thibault.uk, le token est déjà enregistré et sauvegardé localement, ce qui me permet de me reconnecter directement. Avec toujours le drapeau.txt et les fichiers qui sont présents sur la machine. Ces tokens sont tous sauvegardés dans le dossier clave-flair-d, comme pour la machine, et on peut voir que j'ai mon token ssh.thibault.uk 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 .thibault.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ébuggeur pour JWT, on voit que le mail qui est utilisé, c'est mail.thibault.uk, que le domaine sur lequel je veux m'identifier, c'est thibault.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 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, et je vous laisse avec la présentation d'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. Pas de questions pour l'instant. Je reste à votre disposition, évidemment. On peut voir, bien sûr, sur jira.thibault .uk, toutes les requêtes qui ont été faites, comme je vous l'ai expliqué, avec ce cookie. C'est ce cookie qui permet au scientifique actable, 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-tickets -jira. Jeton-tickets-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 thibault.uk, je vais ajouter une nouvelle stratégie. Cette stratégie, ce sera jetons-sauvegarde. Ce jeton -sauvegarde, je vais l'autoriser. Ce jeton -sauvegarde, il y 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-sauvegarde -jira, puisse être autorisé directement. On voit que cette politique d'accès a été modifiée pour inclure le jeton-sauvegarde -tickets-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 Access Directo dans votre système. Merci à vous. Optimizely, c'est la plateforme d 'expérimentation la plus avancée du monde. Nos clients viennent à Optimizely pour développer leur entreprise. Ils sont en mesure de tester toutes leurs assumptions et de faire plus de décisions en basant sur des conseils 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 que Optimizely apporte à leur organisation. Nous avons un snippet de javascript qui va sur les sites web de nos clients. Cela exécute tous les expérimentations qu'ils ont configurés, tous les changements qu'ils ont configurés pour les expérimentations. Ce javascript prend du temps pour le downloader, le parser et 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, c'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 compétition à l'extrême. Et les travailleurs ont finalement apparaîtu comme un outil de choix. Une fois qu'on a commencé à utiliser les travailleurs, c 'était très rapide d'atteindre la vitesse. 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, ça signifie finalement qu'ils vont gagner plus de valeur. Et l'impact de l 'entreprise sur notre ligne d'arrivée et notre ligne supérieure va aussi commencer à mirer cela. Les travailleurs nous ont 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 de choses que Cloudflare fait, d'un point de vue technologique, que nous sommes vraiment excités de partager pour que nous puissions améliorer notre innovation. Cloudflare Cloudflare Cloudflare Cloudflare Cloudflare Cloudflare Cloudflare Cloudflare Sous -titres réalisés para la communauté d 'Amara.org