Dans le monde professionnel, l’utilisation des protocoles SSL/TLS est devenue incontournable pour sécuriser les connexions entre des applications, les appareils et les machines accessibles via Internet. Afin de réduire les risques de falsification et d’exploitations malveillantes, ces protocoles ont besoin de certificats pour garantir la sécurité des données grâce au chiffrement et à l’authentification. Les certificats les plus fiables sont émis et validés par des autorités de certification (AC) de confiance, établissant ainsi une chaîne de confiance essentielle pour l’authentification.
Dans cet article, nous examinons les risques associés aux certificats auto-signés et les raisons pour lesquelles leur utilisation est déconseillée pour sécuriser votre pipeline DevOps.
Qu’est-ce qu’un certificat auto-signé ?
- Un certificat de confiance publique, utilisé pour sécuriser les serveurs web publics et les applications publiques, doit être délivré par une autorité de certification externe tierce de confiance. Cette AC vérifie de manière fiable à qui appartient le domaine. Certaines organisations gèrent cependant leur propre infrastructure à clés publiques (PKI) interne et émettent leurs propres certificats SSL/TLS privés de confiance pour authentifier les appareils et les utilisateurs sur leurs réseaux internes.
- Un certificat auto-signé n’est, en revanche, pas signé par une autorité de certification publique ou privée. Les informations contenues dans ce type de certificat n’ont pas été vérifiées ni authentifiées par une autorité de certification de confiance. En conséquence, les navigateurs web et les systèmes d’exploitation peuvent générer des alertes de sécurité lorsqu’ils rencontrent un tel certificat. Cette situation pose problème, car les utilisateurs ne peuvent pas déterminer la fiabilité du certificat ou s’il a été créé par des acteurs malveillants, faute d’authentification par une autorité de certification reconnue.
Pourquoi les certificats auto-signés séduisent-ils les développeurs ?
Les certificats auto-signés sont utilisés par les développeurs dans des environnements à faible risque, ainsi que lors des phases de développement et de test de logiciels. Voici pourquoi ils sont considérés comme une solution intéressante :
- Flexibilité et rapidité : les certificats auto-signés offrent souplesse et rapidité à toutes les étapes du cycle de développement
- Zéro perte de temps : la génération de certificats auto-signés évite d’avoir à attendre la fin des procédures de vérification et de signature — une étape perçue comme une perte de temps, et une source de frustration et de perturbations.
- Absence de contraintes de durée de validité : contrairement aux certificats SSL/TLS de confiance publique qui sont actuellement limités à une durée de validité de 13 mois, les certificats auto-signés ne sont soumis à aucune contrainte de durée de validité.
Lorsque les développeurs recourent aux certificats auto-signés, des mesures strictes de protection et de sécurité d’accès doivent être mises en place. Une équipe dotée d’outils de suivi efficaces doit être constituée afin de surveiller l’ensemble des certificats et garantir leur authenticité. Malheureusement, la sécurité n’est pas toujours une priorité absolue, et de manière similaire aux risques inutiles liés au « Shadow IT », les certificats auto-signés peuvent engendrer des facteurs de risque importants.
Et pourtant, les développeurs doivent résister à la tentation d’utiliser des certificats auto-signés
L’absence de fiabilité des certificats auto-signés en fait une option fortement déconseillée. Pour toute utilisation en dehors des réseaux internes, il est indispensable que les certificats SSL/TLS soient signés par une autorité de certification de confiance. C’est ce qui garantit un niveau de confiance élevé en adéquation avec les attentes des utilisateurs. La validation par une AC publique de confiance est essentielle pour éliminer le danger que représentent les certificats frauduleux non traçables, ainsi que pour réduire les risques d’usurpation d’identité et de diffusion de codes malveillants.
Facteurs de risques liés à l’utilisation de certificats auto-signés
1. Absence de processus de révocation : en l’absence d’autorité de notification pour révoquer les certificats expirés ou compromis, le risque d’exploitation malveillante et de violations de données reste présent.
2. Manque de visibilité, de connaissance de l’inventaire et de contrôle : il est difficile pour les équipes de sécurité de connaître le nombre de certificats, de savoir où ils sont installés, qui en est propriétaire, d’avoir toutes les informations sur le stockage des clés privées, ou de savoir quand un certificat est compromis.
3. Assistance technique insuffisante : les certificats générés en interne ne sont pas assortis des outils de gestion et des mécanismes de révocation performants que fournissent les autorités de certification publiques.
4. Manque de conformité et d’alignement avec les normes de sécurité : on constate bien souvent une méconnaissance des réglementations et un manque de respect des bonnes pratiques de conformité réglementaire.
En quoi une PKI managée constitue-t-elle une alternative sûre et avantageuse dans un contexte DevOps
Une infrastructure à clés publiques (PKI) est un écosystème technologique englobant les politiques, les procédures, le matériel ainsi que les logiciels nécessaires pour émettre, gérer, stocker et révoquer les certificats numériques. La PKI facilite la création de certificats numériques qui servent à authentifier l’identité des appareils, des utilisateurs et des services. Pour cela, elle s’appuie sur le chiffrement des données, les signatures numériques et l’émission de certificats d’authentification par l’intermédiaire d’autorités de certification dignes de confiance.
Pour les développeurs, la PKI-as-a-Service (PKIaaS) offre une excellente alternative aux certificats auto-signés en termes de facilité d’utilisation, d’évolutivité, d’efficacité et de confiance.
Les avantages d’une PKI hébergée pour le DevOps
Une PKIaaS hébergée offre de nombreux avantages, notamment :
- Visibilité totale, surveillance et contrôle des opérations de PKI, et connaissance de chaque certificat délivré
- Élimination des risques de vulnérabilité liés aux certificats frauduleux, non fiables et non traçables, et en cas d’usurpation de certificats
- Émission plus rapide de certificats
- Amélioration de la sécurité des automatisations DevSecOps
- Réduction des coûts totaux associés à la gestion et la mise en place des SSL/TLS
- Automatisation du déploiement des certificats
- Racine de confiance publique compatible avec tous les systèmes d’exploitation et tous les navigateurs
- Élimination des tâches inhérentes à la gestion interne des certificats
- Gains de temps et d’argent sur la gestion de logiciels, la maintenance, la formation des employés, le suivi et le suivi de l’état général de l’infrastructure
Le service PKI de GlobalSign pour DevOps aide à résoudre les difficultés inhérentes aux certificats
En cas de difficultés liées à l’utilisation de certificats, GlobalSign offre des services d’autorité de certification (AC) hébergés, fiables et dignes de confiance. Dans le cadre des partenariats avec GlobalSign, les développeurs ont accès à une source unique pour répondre à tous leurs besoins en matière de certificats, ce qui leur permet de se concentrer sur leur cœur de métier. Notre expertise en matière de PKI garantit le respect des bonnes pratiques et des exigences en matière d’audit, tout en offrant une assistance et des accords de niveau de service (SLA) de premier ordre.
Les services de certificats PKI de GlobalSign sont déployés avec une rapidité adaptée aux besoins et aux contraintes économiques du DevOps, tout en garantissant la conformité permanente des certificats et des composants PKI aux meilleures pratiques et aux réglementations en vigueur
Caractéristiques de la PKI hébergée de GlobalSign
- Services de révocation hébergés conformes à la norme RFC 5280 (CRL ou OCSP), stockage sécurisé des clés hors ligne, hébergement et gestion de racines clients dédiées ou partagées, publiques ou privées
- Mise en œuvre par API GlobalSign ou intégration ACME
- Possibilité d’intégration directe avec Venafi as a Service et HashiCorp Vault
- Connexion de Kubernetes Certmanager via Atlas
- Interface en ligne de commande pour l’émission, le renouvellement et la révocation de certificats avec HVClient
- Réponse aux besoins en matière de certificats pour l’ensemble des applications
En savoir plus sur les services PKI hébergés de GlobalSign pour DevOps
