Qu'est-ce qu'un certificat auto-signé ? Avantages, risques et alternatives

Le protocoleSSL / TLS concerne la sécurité et l'authentification. Il permet le cryptage des communications de données sur des réseaux ouverts, ce qui les protège contre la falsification et l'interception par des acteurs malveillants. En outre, l'utilisation de certificats SSL permet d'authentifier les parties qui communiquent, créant ainsi un environnement de confiance. La sécurité et l'authentification sont les fondements de la réussite des entreprises dans le monde numérique.

Pour établir le niveau de confiance requis et éliminer l'utilisation de certificats frauduleux usurpant l'identité d'entreprises légitimes, les certificats SSL doivent être signés et validés par une autorité de certification (AC) de confiance. Les autorités de certification émettent des certificats racine de confiance qui sont inclus dans les réserves de confiance. Les certificats numériques signés avec la clé privée de la racine sont reconnus par tous les appareils et applications dont la liste de confiance inclut les certificats racine. Une chaîne de confiance est ainsi créée, qui est utilisée pour authentifier les organisations.

Aujourd'hui, les certificats numériques sont utilisés pour sécuriser des milliers de connexions entre les machines, les appareils et les applications. Traditionnellement, les organisations utilisent des certificats SSL/TLS signés par des autorités de certification (AC) publiques de confiance. Avec la prolifération de technologies et d'initiatives telles que le cloud, la conteneurisation, IoT et les appareils mobiles, et l'explosion subséquente du nombre de certificats numériques, de nombreuses organisations ont également déployé des autorités de certification internes et privées pour sécuriser ces déploiements.

Examinons quelques-unes des principales différences :

Les certificats SSL/TLS de confiance publique sont utilisés pour les serveurs web et les applications qui font face au public. Un certificat de confiance public ne peut être délivré que par une autorité de certification tierce externe de confiance (par exemple Entrust, DigiCert, etc.) qui vérifie le propriétaire du domaine.

Les certificats privés SSL/TLS sont utilisés pour authentifier les utilisateurs et les appareils sur le réseau interne. Un certificat de confiance privé peut être délivré par une autorité de certification publique ou, plus souvent, par une organisation qui exploite sa propre infrastructure interne de clés publiques (par exemple, Microsoft CA).

Une autre stratégie consiste à émettre des certificats auto-signés à l'adresse SSL . Un certificat auto-signé est un certificat qui n'est pas du tout signé par une autorité de certification - ni privée, ni publique. Dans ce cas, le certificat est signé avec sa propre clé privée, au lieu de la demander à une autorité de certification publique ou privée.

Les certificats auto-signés offrent certains avantages lorsqu'ils sont utilisés dans les réseaux internes et dans les phases de développement de software . Cependant, ils peuvent également créer plusieurs risques en l'absence d'une visibilité et d'un contrôle adéquats.

Le plus gros problème des certificats auto-signés est que les équipes de sécurité manquent souvent de visibilité sur le nombre de certificats qu'elles possèdent, l'endroit où ils sont installés, leur propriétaire et la manière dont la clé privée est stockée. Il est déjà difficile de suivre les certificats émis par un certain nombre d'autorités de certification publiques et privées. Il est pratiquement impossible d'assurer le suivi des certificats auto-signés émis sans demande formelle ni processus d'approbation.

Si le réseau de l'entreprise est violé, il n'y a aucun moyen de savoir si un certificat auto-signé (et sa clé privée) a été compromis. Les certificats auto-signés compromis peuvent poser de nombreux problèmes de sécurité, car les attaquants peuvent usurper l'identité de la victime. Contrairement aux certificats émis par une autorité de certification, les certificats auto-signés ne peuvent pas être révoqués. L'impossibilité de trouver et de révoquer rapidement la clé privée associée à un certificat auto-signé crée un risque sérieux.

Ces risques sont accélérés par le nombre d'autorités de certification auto-signées intégrées dans les outils DevOps et les services cloud, ainsi que par les certificats auto-signés émis par les développeurs.

DevOps est synonyme de rapidité et d'agilité. Si les certificats auto-signés permettent aux développeurs d'obtenir des certificats rapidement et facilement, ils contournent souvent les politiques que vous avez mises en place pour assurer la sécurité de votre réseau. Que les développeurs créent un certificat auto-signé ou une autorité de certification auto-signée, ces méthodes créent un faux sentiment de confiance dans votre processus de développement et de livraison.

Alors, pourquoi les développeurs utiliseraient-ils des certificats auto-signés ? La meilleure question est de savoir pourquoi ils ne le feraient pas. Le processus manuel habituel consistant à soumettre une demande de signature de certificat (CSR), puis à attendre des heures pour la vérification et la signature n'est tout simplement pas intuitif. Pour gagner du temps et éviter les frustrations, il est logique que les développeurs optent pour des certificats auto-signés ou des AC intégrées comme HashiCorp Vault, Istio et Kubernetes.

Dans son rapport intitulé "Managing Machine Identities, Secrets, Keys and Certificates", Gartner recommande de "faire en sorte que les gestionnaires de secrets s'intègrent à des émetteurs conformes aux politiques (autorités de certification publiques ou privées)" et de "faire en sorte que les systèmes de gestion des certificats surveillent l'émission du gestionnaire de secrets afin de faciliter l'audit et la gestion du cycle de vie des certificats délivrés".

La simple mise en place d'une autorité de certification auto-signée et l'émission d'un grand nombre de certificats sans respecter les bonnes pratiques PKI et les politiques en matière de certificats n'est pas une option viable.

Malgré l'avantage évident d'accélérer le processus de développement, cette pratique présente plusieurs implications en matière de sécurité, car la sécurité est souvent négligée. Des certificats auto-signés non fiables et non suivis peuvent être utilisés dans les attaques de la chaîne d'approvisionnement software et permettre à des acteurs malveillants de télécharger des codes malveillants.

Les organisations doivent s'assurer que tous leurs certificats sont émis à partir d'une racine de confiance sécurisée, qu'ils sont conformes aux politiques et aux meilleures pratiques, et qu'ils sont gérés tout au long de leur cycle de vie.

La solution pour relever ce défi nécessite un changement fondamental dans la façon dont les équipes de sécurité et de développement travaillent ensemble. En fin de compte, vous devez permettre aux développeurs d'accéder rapidement et facilement aux certificats à partir de leurs flux de travail, sans sacrifier la confiance et la politique.

Sur Keyfactor, nous travaillons avec les équipes DevOps pour passer des certificats auto-signés aux certificats en tant que service. Cela signifie que les développeurs peuvent obtenir des certificats à l'aide de processus automatisés et d'API intégrés directement aux outils cloud-native tels que Jenkins, Ansible, Kubernetes, HashiCorp Vault, Istio et d'autres. Pendant ce temps, chaque certificat est émis à partir d'un PKI as-a-Service de confiance et la sécurité maintient une visibilité et un contrôle complets sur chaque certificat émis.

PKI La solution PKI as-a-Service (PKIaaS) est le bon mélange de confiance et de facilité d'utilisation. Les certificats sont émis à partir d'un site PKI fiable et privé, et les équipes DevOps peuvent facilement demander et émettre des certificats via des processus en libre-service, ce qui réduit le besoin de certificats auto-signés.

Pour en savoir plus sur la façon dont vous pouvez éliminer le besoin de certificats auto-signés et adopter l'automatisation du libre-service, demandez une démonstration de Keyfactor dès aujourd'hui.