SSL/TLS Les certificats émis par des autorités de certification (AC) de confiance, qu'elles soient publiques ou privées, sont utilisés pour authentifier un seul domaine dans les sites web publics. Les organisations possédant une poignée de domaines et sous-domaines publics devraient émettre et gérer un nombre égal de certificats numériques, ce qui accroîtrait la complexité de la gestion du cycle de vie des certificats. La bonne nouvelle, c'est qu'il existe une solution pour éviter ce fardeau.
Les certificats Wildcard promettent la simplicité, mais sont-ils la solution à toutes nos prières ?
Ce blog est co-écrit avec Robert Masterson de Thales.
Le passage à des applications natives pour le nuage modifie les éléments constitutifs de l'informatique. Dans de nombreux cas, le développement et la maintenance de l'infrastructure et des applications en interne ne sont tout simplement plus une option. Le développement d'applications cloud-natives et l'utilisation de conteneurs et de frameworks d'orchestration comme Kubernetes offrent des avantages indéniables en termes de performance, de portabilité et d'échelle.
Cependant, il est évident pour les équipes de sécurité que la surface d'attaque possible s'est accrue en conséquence. Le déploiement à la demande et à grande échelle des ressources informatiques dans un ensemble de nuages publics et privés signifie que les vulnérabilités ou les exploits en matière de sécurité peuvent souvent passer inaperçus. Savoir à qui et à quoi on peut faire confiance est un combat permanent, car les codes malveillants, les connexions non fiables et les mauvaises configurations ne mènent qu'à une chose : plus de risques.
Plusieurs mécanismes aident les équipes chargées des applications et de la sécurité à atténuer ces risques, mais l'identité est au cœur du dispositif. Identifier toutes les "choses" (par exemple, les charges de travail, les services, le code) dans chaque nuage ou réseau, vérifier l'intégrité et chiffrer les connexions de bout en bout, c'est la moitié du chemin à parcourir. Deux fonctions essentielles rendent cela possible : l'application de la signature et l'authentification de la confiance, qui peuvent toutes deux être réalisées grâce à l'utilisation de certificats X.509.
Signer tout
Les développeurs devraient toujours signer numériquement le code afin de protéger les utilisateurs finaux contre le téléchargement et l'installation d'un code compromis. La signature du code garantit que l'application ne peut pas être modifiée par un utilisateur non autorisé et donne l'assurance que seul le code authentique développé et vérifié par le fournisseur sera exécuté. Une fois que le site software est conditionné en conteneurs pour être déployé dans le nuage, les conteneurs peuvent également être signés. Par exemple, Docker prend en charge la sécurité et la signature des conteneurs pour permettre la vérification de l'intégrité et de l'éditeur des conteneurs.
Nous recommandons les deux niveaux de signature. Si l'application est signée, mais que le conteneur ne l'est pas, un utilisateur malveillant pourrait potentiellement exécuter d'autres codes malveillants sur le conteneur en plus du code légitime. L'application des signatures est sans aucun doute nécessaire, mais il est encore plus important de protéger les certificats - et leur clé privée associée - utilisés pour la signature. Si ces clés sont compromises, les attaquants peuvent les utiliser pour signer du code malveillant, en lui donnant l'apparence d'être authentique et fiable, au même titre que votre site software.
Keyfactor Code Assure a été conçu pour résoudre ces problèmes. La plateforme fournit aux développeurs un accès programmatique aux certificats pour signer le code, tandis que l'équipe de sécurité conserve une piste d'audit précise de toutes les activités de signature et s'assure que les clés privées restent en sécurité dans un HSM Thales intégré. Le stockage des clés privées dans un HSM Thales de niveau 3, conforme à la norme FIPS 140-2 - sur site ou dans le cloud - garantit que, même si quelqu'un a accès à l'emplacement, il ne peut pas extraire ou copier le certificat.
La signature peut notamment être effectuée à distance, ce qui élimine la nécessité de distribuer des clés sensibles à plusieurs équipes ou sites. Le fournisseur de stockage cryptographique (CSP) et les API de Keyfactor permettent l'intégration dans presque tous les pipelines CI/CD ou processus de construction, que vous utilisiez Microsoft SignTool pour les exécutables Windows, jarsigner pour l'authentification Java ou un outil plus complexe comme Jenkins.
Établir des identités sécurisées pour tout
La meilleure pratique consiste à s'assurer que chaque connexion vers, depuis ou à l'intérieur d'un conteneur ou d'un cluster utilise SSL/TLS pour permettre une authentification mutuelle et un cryptage de bout en bout. Cela permet d'éviter que des adversaires non autorisés n'établissent une connexion susceptible de compromettre la sécurité des conteneurs d'un cluster entier. Il est également important de surveiller et d'auditer les certificats SSL/TLS émis et actifs. Des certificats inconnus, erronés ou non conformes peuvent entraîner une panne inattendue ou, pire encore, une utilisation abusive permettant un accès involontaire à des systèmes restreints.
Par exemple, Kubernetes peut générer et émettre des certificats de son propre chef, mais la plupart des utilisateurs estiment qu'il n'offre pas la visibilité dont ils ont besoin pour s'assurer que les certificats n'ont pas été émis de manière inappropriée. Cependant, Kubernetes prend également en charge le protocole ACME, qui peut être utilisé pour obtenir des certificats d'autres sources, telles que Let's Encrypt. Cette prise en charge du protocole s'intègre au serveur Keyfactor ACME, inclus dans Keyfactor Command - notre PKI-as-a-Service et plateforme d'automatisation des certificats - pour obtenir des certificats de n'importe quelle PKI prise en charge par l'entreprise, qu'elle soit publique ou privée, qui est configurée dans la plateforme Keyfactor . Cela permet l'émission automatique et sécurisée d'un certificat d'identité unique et fiable pour chaque conteneur lors du déploiement. Cela se fait avec un contrôle d'accès robuste basé sur les rôles aux différents modèles ou produits de certificats, ainsi qu'avec des capacités étendues de flux de travail, d'audit et d'alerte, afin de garantir la tranquillité d'esprit qu'aucun certificat n'est émis ou utilisé lorsqu'il ne devrait pas l'être.
Les certificats émis pour les conteneurs doivent être de courte durée afin de limiter le nombre de certificats non expirés actifs à un moment donné, qui peut souvent dépasser des milliers. Cela permet de réduire le risque de compromission et d'atténuer l'impact du vol d'un certificat, puisqu'il expirera de toute façon bientôt. Cependant, le certificat qui ne peut pas avoir une durée de vie courte est aussi le plus important : le certificat de l'autorité de certification (AC) elle-même.
Comme pour la signature de code, il est essentiel de sécuriser les autorités de certification qui émettent les certificats. Si une AC est compromise, les attaquants peuvent émettre leurs propres identités qui seront approuvées par défaut dans votre écosystème, ce qui peut être extrêmement coûteux à corriger, car cela invalide effectivement toutes les identités émises par cette AC. La plateforme Keyfactor Command , intégrée aux HSM de Thales pour sécuriser les certificats et les clés de l'autorité de certification, garantit une protection solide et une visibilité complète, l'application de politiques et l'automatisation pour tous les certificats.
Découvrez comment l'automatisation du cycle de vie des certificats peut vous aider à atteindre vos objectifs en matière de DevOps et de sécurité. Téléchargez l'eBook DevOps.com :
