Maîtrisez vos administrateurs malhonnêtes : comment gérer les certificats SSL

Alors que les organisations adoptent la transformation numérique et les technologies de pointe, l'échelle et la distribution des certificats SSL/TLS ont augmenté rapidement, créant de nouveaux défis.

Sami Van Vliet, Principal Product Manager chez Keyfactor, et Mrugesh Chandarana, Senior Product Manager chez HID, ont discuté des meilleures pratiques pour gérer les certificats SSL lors de leur session au Keyfactor Virtual Summit. Ce blog propose un récapitulatif des idées et des recommandations abordées lors de la session.

La prolifération des appareils IoT dans l'écosystème de l'entreprise et l'avènement de la virtualisation et des pratiques DevOps ont fait grimper en flèche les cas d'utilisation des certificats SSL/TLS .

Alors que les organisations poussent à un déploiement plus rapide et plus efficace des applications d'entreprise, de nombreuses équipes DevOps déploient des certificats sans coordination avec les équipes informatiques et de sécurité.

Le manque de visibilité et de contrôle sur les certificats et les autorités de certification émettrices est un problème grave. 74% des organisations ne savent pas combien de clés et de certificats leur organisation possède réellement. La visibilité de vos certificats est la base de la gestion et de la protection de ces actifs précieux.

Malgré leur importance, les certificats SSL sont souvent laissés sans suivi et sans gestion. Presque toutes les entreprises ont connu une panne d'application due à un certificat expiré. En fait, un récent rapport deKeyfactor et Ponemon indique que 87 % des personnes interrogées ont connu des pannes non planifiées dues à des certificats expirés.

Une autre tendance observée est la réduction de la durée de validité des certificats SSL . Depuis 2012, le forum CA/Browser (CA/B) a imposé la réduction de la durée de vie des certificats émis publiquement de 60 à 27 mois.

With the use of SSL/TLS certificates expanding and creating bigger threat surface, Google more recently proposed in 2019 a reduction to one-year lifespans, without success. Apple then strong-armed the CA/B forum by limiting certificate lifespans in its ecosystem to <398 days. These developments prompted Google Chrome and Mozilla to follow suit, forcing the CA/B Forum to set the new lifespan of certificates to just 13 months or 398 days.

Dans les années à venir, nous nous attendons à ce que cette tendance se poursuive. Néanmoins, il n'est pas rare aujourd'hui que des organisations émettent des certificats dont la durée de validité n'est que de quelques jours ou de quelques heures.

Avec l'utilisation accrue des certificats et la réduction de leur durée de vie, la charge de travail des équipes PKI et de sécurité a effectivement doublé, alors que leur budget reste le même. Cette situation a créé un certain nombre de nouveaux défis pour les organisations :

• Manque de visibilité. Les équipes informatiques doivent avoir une visibilité complète non seulement sur les certificats des serveurs, mais aussi sur les certificats d'authentification des clients.
• Processus manuels. Les demandes de certificats, les renouvellements et le provisionnement effectués à l'aide de méthodes manuelles et de feuilles de calcul prennent des heures, voire des jours. Outre le fait qu'elles prennent du temps, ces méthodes sont également sujettes à des erreurs.
• Changement de personnel informatique. Les administrateurs vont et viennent, les courriels peuvent également changer et, par conséquent, les notifications d'expiration ne sont pas reçues. Les pannes dues à des certificats expirés ne sont plus qu'à un courriel près.
• Absence de responsabilité. Bien souvent, les administrateurs déploient des autorités de certification "bricolées" ou intégrées sans aucun contrôle de sécurité.
• Une réponse lente. Lorsqu'une panne de certificat expiré se produit, l'identification et le remplacement du certificat expiré dans tous les sites est un processus qui prend du temps et qui peut durer plusieurs heures, voire plusieurs jours.

Au-delà du risque de panne, les vulnérabilités des algorithmes et les progrès de l'informatique ont fait naître le besoin d'une agilité cryptographique. Les principales raisons pour lesquelles les organisations doivent être agiles en matière de crypto-monnaie sont les suivantes :

• Révocation en masse: Que se passe-t-il si les certificats sont révoqués par votre autorité de certification dans un délai très court (par exemple, DigiCert a révoqué 50 000 certificats en juillet 2020) ?
• L'obsolescence des algorithmes: Les vulnérabilités des algorithmes cryptographiques sont constamment évaluées. La migration vers SHA-2 a pris des années et ce ne sera pas le dernier changement d'algorithme.
• Compromission de l'autorité de certification : si une autorité de certification est violée par un attaquant, toute la chaîne de confiance est rompue. Les certificats émis par l'autorité de certification ne sont plus valables et de nouveaux certificats doivent être installés sur tous les serveurs possédant des certificats de l'autorité de certification compromise.
• Agilité de l'autorité de certification: La possibilité d'ajouter/supprimer ou de passer d'une autorité de certification à une autre est essentielle pour la souplesse de l'entreprise et pour éviter l'enfermement dans l'autorité de certification.
• Les bogues des bibliothèques cryptographiques: Si un bogue est découvert dans les fonctions de génération de clés d'une bibliothèque cryptographique, toutes les clés générées depuis l'introduction du bogue doivent être remplacées. Des vulnérabilités telles que Heartbleed dans OpenSSL exposent les certificats et les clés privées à des risques.
• Cryptographie quantique: les progrès de la quantique obligent les organisations à se préparer à la mise en œuvre inévitable d'algorithmes post-quantiques. C'est aujourd'hui qu'il faut commencer à planifier une cryptographie à sécurité quantique.

La nécessité d'être agile sur le plan cryptographique rend l'automatisation indispensable pour relever tous ces défis de manière plus efficace.

1. Gagner en visibilité

Pour faire face aux risques liés aux certificats de serveur TLS , les organisations doivent établir et maintenir une visibilité claire de tous les certificats SSL/TLS dans leur environnement. L'inventaire doit porter sur les points suivants

• les autorités de certification (AC), qui sont à l'origine de la plupart des certificats et qui se synchronisent avec les AC internes et publiques.
• Réseau SSL/TLS Endpoints pour identifier l'endroit où tous les certificats sont installés sur le réseau.
• Key and Certificate Stores pour localiser les certificats qui ne sont pas exposés à un port du réseau.

Le processus d'identification des certificats d'entreprise SSL/TLS doit permettre de localiser l'endroit où tous les certificats sont installés et de créer un inventaire centralisé de tous les certificats émis. En outre, il doit identifier les propriétaires de tous les certificats et domaines et comprendre les serveurs web et applications associés.

2. Remédier à la situation

Une fois que tous les certificats ont été identifiés, l'étape suivante consiste à remédier aux points faibles. Ce processus doit permettre de détecter les vulnérabilités telles que des clés ou des hachages faibles et de contrôler l'utilisation de certificats de type "wildcard" et de certificats auto-signés.

Les certificats expirés doivent être renouvelés et les clés privées doivent toujours être protégées. Enfin, les certificats faibles ou frauduleux doivent être retirés de l'écosystème des certificats.

La récente panne d'une heure de Spotify, qui a affecté son service de streaming en raison de l'expiration d'un certificat Wildcard, est un excellent exemple de la raison pour laquelle la visibilité et la remédiation sont essentielles.

La panne de Spotify a permis de tirer de nombreux enseignements utiles. Les certificats Wildcard sont utiles dans certains cas, mais leur utilisation doit être limitée et faire l'objet d'un suivi permanent. Lorsque des certificats wildcard sont nécessaires, il convient de les générer avec des clés privées différentes afin de minimiser l'impact d'une panne.

3. Appliquer la politique

La politique doit être appliquée au niveau de l'entreprise pour couvrir tous les propriétaires et consommateurs possibles de certificats, tels que les administrateurs de réseau, les équipes DevOps, les équipes de sécurité, les administrateurs PKI et le personnel informatique.

Une politique de gestion des certificats à l'échelle de l'entreprise doit définir les propriétaires de certificats ainsi que leurs rôles et responsabilités. La délivrance et le renouvellement des certificats doivent être normalisés, et un système d'alerte précoce doit être mis en place pour envoyer des alertes d'expiration aux propriétaires de certificats. Enfin, des politiques doivent être mises en place pour la révocation et la suppression des certificats.

4. Automatiser et intégrer

L'utilisation croissante des certificats de serveur SSL pour sécuriser des applications importantes rend la gestion manuelle des certificats impraticable. L'automatisation est devenue importante pour traiter de manière rentable et efficace toutes les questions relatives à la gestion des certificats.

L'automatisation devrait être utilisée autant que possible pour l'inscription, l'installation, la surveillance et le remplacement des certificats. Une solution d'automatisation devrait permettre aux utilisateurs d'utiliser leurs propres certificats en libre-service et devrait permettre l'intégration avec les outils cloud et DevOps.

5. Contrôler et rendre compte

Pour s'assurer qu'une solution d'automatisation fonctionne correctement et en raison de l'utilisation généralisée des certificats dans toutes les communications critiques, les défaillances opérationnelles ou de sécurité liées aux certificats SSL/TLS peuvent avoir un impact significatif sur les activités de l'entreprise. SSL/ Les certificatsTLS doivent être surveillés en permanence pour éviter les pannes et les failles de sécurité.

Les certificats doivent être contrôlés pour vérifier qu'ils n'arrivent pas à expiration et qu'ils ne fonctionnent pas, qu'ils ne sont pas configurés correctement ou qu'ils sont vulnérables. En outre, l'analyse doit permettre de localiser les certificats générés en dehors des procédures établies.

Le processus de contrôle doit vérifier toute activité liée aux LCR/OCSP et auditer régulièrement le paysage des certificats pour s'assurer qu'il est toujours conforme aux politiques de certification.

La gestion des certificats SSL commence souvent par des processus manuels (feuilles de calcul) et s'étend jusqu'à l'automatisation dynamique et sans contact. En fonction des besoins de votre organisation, vous devrez déterminer où vous en êtes et comment améliorer votre position pour éviter les pannes et rester en tête de la courbe cryptographique.

Téléchargez le modèle de maturité de la gestion des certificats pour commencer.