Publié le 18 novembre 2021, mis à jour le 11 avril 2022.
Chez les grosses boîtes...
Imaginez-vous : vous travaillez dans une grande entreprise et, cherchant à bien faire les choses, vous cherchez à sécuriser les échanges d'une application. Un serveur web, une API... Qu'importe. Par ailleurs, cette étape de sécurisation des flux réseaux est primordiale pour une équipe de sécurité. Cependant, cette dernière ne validera jamais votre passage en production si ce n'est pas aux normes de leurs critères d'acceptance.
Aussi, vous vous rapprochez de l'équipe s'occupant de la génération de vos certificats. Pour lancer une demande, il convient de passer par l'outil de ticketing favori de l'entreprise, pour l'exemple, Service Now. Celui-ci vous propose donc un workflow pour vous demander quel est le FQDN de votre application, sur quelle VM est-il requis (vous pensiez à un cluster Kubernetes ?), bref, toute la description de votre application. Ces informations seront ensuite stockées pour référencement interne dans un lointain fichier Excel, avant même une éventuelle validation de ladite équipe sécurité demandant elle-même ledit certificat.
Temps total : entre 1 et 5 jours, en fonction de la disponibilité de l'équipe certificats, de l'équipe sécurité, et de votre agenda pour remplir la demande initiale. Nous sommes dans le meilleur cas, où vous aviez déjà connaissance de la procédure à suivre, bien sûr 🙂
Et à la maison ?
Sur une infra perso, ces problèmes disparaissent ! La gouvernance de vos certificats est à votre discrétion, et vous pouvez donc utiliser l'autorité de certification que vous désirez. La mode du plus grand nombre va vers Let's Encrypt, qui permet de générer des certificats SSL pour vos échanges sur le réseau, mais il existe cependant des alternatives, telles que ZeroSSL par exemple.
Pour se rapprocher davantage d'une approche DevOps, d'aucun peut alors se doter d'un client implémentant le protocole ACME. Ce dernier a vocation d'automatiser les échanges entre les serveurs web et les autorités de certification : le client ACME va créer un fichier à la racine d'un site web, permettant après notification à l'autorité de certification la récupération automatisée puis l'installation d'un certificat SSL sur le site web associé. L'opération peut être réitérée pour chaque site du serveur web, ou même optimisée par un certificat wildcard.
En choisissant l'autorité de certification ainsi que la méthode susmentionnées, il devient alors très simple de déployer efficacement des certificats sur une flotte. Le concept peut bien évidemment être appliqué à une structure plus importante : aussi, de nombreuses sociétés ont recours à la solution Let's Encrypt pour la sécurisation de leurs sites web.
Optimisations et choix techniques
Si les clients ACME installent le certificat, les configurations par défaut laissent parfois à désirer. Aussi, la génération et l'installation simples, en suivant la documentation de Let's Encrypt ne permettent que d'obtenir un petit B à un test SSL Labs.
Se pose alors la question de l'accessibilité de votre application : souhaitez-vous permettre à vos utilisateurs utilisant d'anciennes versions de navigateurs d'y accéder, au détriment de la sécurité du réseau ? Il n'y a pas de bonne ou de mauvaise réponse à cette question, il s'agit d'un curseur à positionner selon les spécificités de vos utilisateurs et la criticité des données que vous traitez.
La fondation Mozilla propose un outil en ligne permettant de générer des configurations de serveurs web et de proxies personnalisés en fonction de votre choix. Cette configuration, une fois appliquée sur votre infrastructure, vous permet de ne déléguer au client ACME que la seule génération et le renouvellement de votre certificat. Un bonheur !
Et au sein d'un cluster Kubernetes ?
Au sein d'un cluster Kubernetes, la mise en place d'un reverse-proxy moderne peut suppléer le client ACME. Par exemple avec Traefik, une certaine configuration permet l'auto-discovery des services et leur enregistrement auprès de l'autorité de certification. Cependant, la sécurisation des flux ne doit pas se faire que pour l'extérieur de votre infra. En effet, en cas d'intrusion à l'intérieur de votre cluster, vous préférerez que les échanges entre vos pods soient faits de manière chiffrée.
Problème : si une autorité de certification peut être utilisée de manière conjointe avec un client ACME, celle-ci ne peut faire de la certification que sur les services exposés à Internet. Comment donc sécuriser sur un procédé similaire le cœur de la communication de votre cluster Kubernetes ?
La solution moderne à cela est l'utilisation d'un service mesh, tel qu'Istio. Il permet ainsi le chiffrement des données réseau en utilisant des proxies, positionnés directement avant les pods. Istio créé sa propre autorité de certification au sein de votre cluster : cela vous permet de chiffrer le traffic de proxy à proxy. Le seul flux réseau restant n'étant pas sécurisé se situe entre les proxies et les pods applicatifs.
Une telle architecture vous dote ainsi d'une topologie réseau plus granulaire, qui peut s'avérer être un gros plus en matière de déploiement. Le service mesh permet une topologie réseau complexe entre les différentes versions de vos applications, permettant par exemple la mise en place de canary releases.
La sécurité est l'affaire de tous, et particulièrement des administrateurs systèmes. Comme vu précédemment, de nombreuses alternatives existent de chiffrer les flux vitaux de son infrastructure, mais les choix techniques vous appartiennent. Utiliser Istio au sein de votre cluster, avec Let's Encrypt pour sécuriser la partie exposée sur Internet, s'avère être une redoutable association d'outils pour l'implémentation de la sécurisation des flux réseaux. Pour aller plus loin, vous pourriez également étudier le chiffrement at rest de vos données sur disque 🙂