7 erreurs d’automatisation courantes qui mettent vos certificats SSL/TLS en danger

Résumé

Alors que la durée de vie des certificats se réduit à 47 jours, la pression s'exerce sur les administrateurs PKI. Vous connaissez déjà les risques : les certificats expirés sont synonymes d'interruptions, d'exercices d'évacuation et d'appels nocturnes. Notre directeur mondial de l'ingénierie des ventes, Brendan Bonner, présente les sept erreurs les plus courantes qu'il constate chez les clients qui mettent leurs certificats en péril.

Le problème est que les équipes s'attaquent au défi des certificats de 47 jours d'aujourd'hui avec des solutions dépassées, d'une durée d'un an. Elles assemblent des portails, des scripts ou des flux de travail de gestion des services informatiques (ITSM) qui ressemblent à de l'automatisation mais n'y parviennent pas. Trop souvent, l'« automatisation » ne concerne que l'administrateur de la PKI. Les certificats atterrissent dans un coffre-fort central, mais les administrateurs système, cloud et réseau doivent encore les récupérer et les installer manuellement. Cela peut cocher une case pour la PKI, mais cela ne résout pas le vrai problème pour l'entreprise.

Il y a aussi la fausse économie des wildcards. Une wildcard de 100 dollars peut sembler rentable par rapport à des certificats à domaine unique ou à domaines multiples, mais ces économies peuvent rapidement s'évaporer. Lorsqu'une wildcard expire ou est compromise, elle peut facilement se transformer en une interruption de service ou en une violation d'une valeur d'un million de dollars. En fait, certaines entreprises, comme les sociétés de capital-investissement, exigent désormais que les entreprises de leur portefeuille suppriment complètement les certificats Wildcard après des échecs répétés et coûteux.

J'en ai été le témoin direct. Dans un cas, une grande entreprise pensait avoir automatisé son système jusqu'à ce que Sectigo le démonte et découvre qu'elle n'avait qu'un portail pour les demandes de certificats. Pas de déploiement. Pas de renouvellement. Juste des demandes.

En réalité, une véritable automatisation de bout en bout existe déjà. Pour de nombreux administrateurs, le déclic se produit la première fois qu'ils voient un certificat déployé directement à partir d'une interface, sans jamais se connecter au serveur web. Ils réalisent ensuite que la mise en place de l'automatisation est souvent plus rapide que la poursuite des installations manuelles.

Ce blog explore sept erreurs d'automatisation courantes qui ralentissent les équipes et explique comment aborder l'automatisation d'une manière pratique, avant-gardiste et durable.

Étape 1 : La gestion centralisée des clés n'est pas de l'automatisation

Le problème : les coffres-forts de clés centralisés fonctionnaient lorsque les certificats duraient un an ou plus. Les administrateurs de la PKI pouvaient stocker les certificats et les équipes d'application les retiraient en cas de besoin.

Là où ça ne marche pas : En pratique, la plupart des organisations n'ont pas de certificats déployés sur les points de terminaison avec l'automatisation. Au lieu de cela, les administrateurs système, les administrateurs cloud et les administrateurs réseau doivent encore extraire le certificat du coffre-fort, le télécharger et l'installer manuellement. Cela peut ressembler à de l'automatisation pour l'administrateur PKI, mais cela n'est pas évolutif dans un monde de renouvellement de 30 à 47 jours. De plus, la clé privée est dispersée en plusieurs endroits au lieu d'être liée à l'appareil.

Une meilleure solution : Pousser l'automatisation jusqu'à la périphérie. Une véritable automatisation émet des certificats directement sur l'appareil. La clé privée ne quitte jamais l'appareil, la demande de signature de certificat (CSR) est envoyée en toute sécurité à l'autorité de certification (CA), et le renouvellement et l'installation se font de bout en bout.

Étape 2 : Les flux de travail à la demande ne sont pas de l'automatisation

Le problème : De nombreuses organisations se disent « automatisées », mais en réalité, elles n'ont fait qu'accélérer les demandes. Une CSR peut être générée automatiquement et envoyée à l'autorité de certification, mais quelqu'un doit encore se connecter, télécharger et installer le certificat.

Les points faibles : Il s'agit d'un progrès, mais seulement à moitié. Les certificats s'empilent dans l'attente d'un clic et des interruptions se produisent lorsque le « dernier kilomètre » n'est pas franchi. Une grande entreprise avec laquelle j'ai travaillé pensait être automatisée jusqu'à ce que nous découvrions que son processus n'était qu'un portail de demande. Pas de déploiement. Pas de renouvellement.

Un meilleur chemin : L'automatisation doit couvrir l'ensemble du cycle de vie : demande, délivrance, installation et renouvellement. Si votre équipe continue de se connecter à chaque cycle, vous n'avez résolu qu'une partie du problème.

Étape 3 : Les soucis de format freinent l'automatisation

Le problème : Les équipes bloquent l'automatisation à cause des formats de certificat : PFX, PEM, PKCS#12. Elles s'inquiètent de l'incompatibilité ou de l'enfermement.

Ce qui ne fonctionne pas : Cette « paralysie des formats » retarde les progrès alors que les certificats continuent d'expirer.

Une meilleure solution : Utiliser un gestionnaire de cycle de vie des certificats (CLM) qui prend en charge nativement plusieurs formats. L'automatisation devrait permettre de fournir des certificats dans le format requis par l'appareil sans que votre équipe n'ait à effectuer de travail supplémentaire. Ne vous en préoccupez pas, automatisez-le.

Étape 4 : Les goulets d'étranglement de la gestion du changement freinent l'automatisation

Le problème : La gestion des changements est essentielle, mais elle est souvent appliquée de manière trop littérale aux certificats. Certaines organisations créent des demandes de changement pour chaque renouvellement, ce qui oblige les administrateurs à se connecter et à approuver ou installer un certificat tous les 30 à 40 jours.

Les lacunes : Il ne s'agit pas de gouvernance, mais d'automatisation par simple clic. Elle entraîne des retards, fait perdre du temps aux administrateurs et ne fonctionne plus du tout pendant les périodes de gel des modifications, lorsque les certificats peuvent encore expirer.

Une meilleure solution : Garder la gestion du changement à sa place : approuver les flux de travail d'automatisation pendant la configuration, avec les bons contrôles et les bons équilibres. Une fois l'automatisation approuvée, laissez-la s'exécuter.

Un exemple concret : Sectigo a travaillé avec un administrateur PKI qui comprenait les risques de lier les renouvellements à la gestion des changements, mais son équipe InfoSec s'y opposait. Elle pensait que chaque approbation de renouvellement était nécessaire pour la sécurité. En théorie, ils n'avaient pas tort : la gouvernance est importante. En réalité, le processus qu'ils appliquaient créait davantage de risques, les certificats continuant d'expirer pendant les périodes de gel. Après une discussion approfondie et une évaluation des compromis, ils ont reconnu que l'automatisation avec une forte journalisation était la voie la plus sûre à suivre.

Étape 5 : Traiter l'ITSM comme le CLM bloque l'automatisation

Le problème : De nombreuses organisations tentent de reconstruire la gestion des certificats au sein de plateformes ITSM telles que ServiceNow ou Remedy. Il semble logique de suivre les certificats comme d'autres actifs, mais les plateformes ITSM n'ont pas été conçues pour une gestion complète du cycle de vie des certificats.

Les lacunes : Les systèmes ITSM peuvent enregistrer les certificats et les lier à l'inventaire, mais ils ne peuvent pas les découvrir, les renouveler ou les déployer à la vitesse des cycles de 47 jours. J'ai travaillé avec des clients qui ont investi dans des flux de travail ITSM personnalisés, pour ensuite les abandonner en raison des frais généraux de développement et de gestion.

Une meilleure solution : Utiliser l'ITSM pour la gouvernance et la visibilité, mais laisser le CLM faire ce pour quoi il a été conçu : la découverte, l'émission, le déploiement et le renouvellement. Sectigo, par exemple, s'intègre directement à ServiceNow (et à d'autres systèmes ITSM par le biais d'API), ce qui vous permet d'obtenir le meilleur des deux mondes : les enregistrements dans l'ITSM, l'automatisation dans le CLM et moins de frais généraux. Utilisez le plus grand nombre possible d'intégrations prêtes à l'emploi.

Étape 6 : La réutilisation des certificats dans différents sites nuit à la sécurité

Le problème : certaines organisations utilisent encore le même certificat et la même paire de clés sur plusieurs serveurs. Elles automatisent le processus sur un serveur, puis le copient sur les autres.

Défauts : cette pratique nuit à la fois à la sécurité et à l'automatisation. C'est comme dans un hôtel où toutes les chambres ont la même carte d'accès : pratique, mais risqué.

Une meilleure solution : Traitez chaque point d'extrémité avec une clé privée unique. Si vous avez besoin du même nom commun à différents endroits, par exemple un équilibreur de charge F5 et un serveur IIS, fournissez des certificats et des paires de clés distincts pour chacun d'entre eux.

Remarque spéciale sur les certificats Wildcard

Les certificats Wildcard ont toujours été utilisés pour gagner du temps, même en étendant un seul wildcard à plus d'un millier d'appareils. C'était une pratique courante ; je me suis moi-même rendu coupable de l'utiliser dans le passé.

Avec l'automatisation, ce raccourci n'a plus de sens. Un wildcard crée un point de défaillance unique. S'il expire ou est compromis, chaque appareil qui le partage est affecté.

Peut-on automatiser un certificat de type « wildcard » ? Absolument.

Est-ce que cela a du sens ? Non.

Ce certificat Wildcard de 100 dollars peut sembler bon marché par rapport aux certificats à domaine unique ou à domaines multiples, mais les fausses économies peuvent se transformer en une interruption ou une violation d'un million de dollars. Conclusion ? Traitez chaque point d'extrémité avec une clé privée unique.

Étape 7 : Essayer de tout résoudre en même temps

Le problème : certaines équipes pensent que l'automatisation des certificats doit être abordée dans le cadre d'un projet massif, en émettant et en remplaçant tous les certificats d'un seul coup.

L'échec : Cette approche conduit généralement à la paralysie. L'ampleur du projet semble démesurée et rien n'avance alors que les certificats continuent d'expirer.

Une meilleure solution : Il n'est pas nécessaire de bouleverser votre PKI du jour au lendemain. Avec une automatisation adéquate, vous pouvez laisser les certificats se renouveler naturellement, en les remplaçant automatiquement au fur et à mesure qu'ils arrivent à expiration. En divisant le problème en plusieurs étapes, la transition est plus douce, plus rapide et moins risquée. L'automatisation véritable est une question d'élan, pas d'ébullition de l'océan.

Un mythe répandu : L'automatisation est plus difficile que le travail manuel

La crainte : De nombreux administrateurs pensent qu'une véritable automatisation nécessite d'énormes ressources.

La réalité : En pratique, elle est souvent plus rapide. Dans mon laboratoire, j'ai comparé le déploiement manuel (4 minutes 12 secondes) à l'automatisation complète (2 minutes 44 secondes, y compris l'installation de l'agent). Dans les environnements réels, les installations manuelles prennent souvent des heures en raison de l'absence de prévalidation ou d'ancres de confiance.

Ce qui surprend le plus les administrateurs, c'est le déploiement. Historiquement, ils ont dû rechercher des serveurs, comprendre le processus d'installation, prévoir des temps d'arrêt et planifier en fonction des risques. Avec l'automatisation, le déploiement se fait en quelques secondes : pas de conjecture, pas de programmation et pas de temps d'arrêt.

Ce qu'il faut retenir : L'automatisation n'ajoute pas de travail, elle en supprime. Une fois qu'elle est en place, chaque renouvellement se fait sans que vous ayez à lever le petit doigt.

Conclusion

Si votre processus comporte encore des étapes manuelles, il est temps de chercher des moyens de l'automatiser. Si vous n'automatisez pas, vous courez un risque. J'ai vu les yeux des administrateurs s'illuminer la première fois qu'ils ont vu un certificat déployé directement sur un appareil sans toucher au serveur, et qu'ils ont réalisé que c'était en fait plus rapide que de le faire manuellement. C'est l'instant décisif qui change tout. Cela dit, il n'est pas réaliste d'automatiser tous les certificats aujourd'hui. Certains processus et programmes ne disposent pas encore d'API ou de crochets pour une automatisation complète, et c'est très bien ainsi. Ce qui compte, c'est d'automatiser la majeure partie de vos certificats.

Lorsque vous serez prêt à passer à l'étape suivante, consultez notre Guide de survie en 47 jours pour voir exactement à quoi devrait ressembler une véritable automatisation dans la pratique ou calculez le retour sur investissement moyen du passage à une plateforme CLM automatisée à l'aide de notre Calculateur de retour sur investissement en 47 jours.

Envie d'en savoir plus ? Contactez nous pour réserver une démo de Sectigo Certificate Manager !

Articles associés :

Comment prévenir les violations de données dans les entreprises

Le rôle de l'automatisation du cycle de vie des certificats dans les environnements d'entreprise

Pourquoi l'automatisation du renouvellement des certificats SSL est essentielle pour les entreprises de toutes tailles