Comment faire en sorte que tous les certificats de votre organisation respectent les mêmes règles de sécurité ? Pour de nombreuses équipes, c'est plus facile à dire qu'à faire. La bonne nouvelle : vous disposez déjà d'un moyen intégré d'assurer la cohérence : Les demandes de signature de certificat (CSR).
Une RSC permet de normaliser la taille des clés, les algorithmes et les champs d'identité afin que chaque certificat réponde aux exigences de sécurité et de conformité de votre organisation.
Vous générerez une CSR chaque fois que vous aurez besoin d'un nouveau certificat de la part d'une autorité de certification (AC). Une fois approuvée, l'autorité de certification fournit le certificat contenant la clé publique et les informations d'identification, tandis que la clé privée reste en sécurité sur le système du demandeur. Les CSR sont nécessaires à plusieurs étapes du cycle de vie de la gestion des certificats: émission, renouvellements impliquant de nouvelles paires de clés, ou lors de la mise à niveau de votre organisation vers de nouvelles normes cryptographiques, entre autres.
Quand devez-vous générer une RSE ?
Dans cet article, nous allons déterminer à quel moment du cycle de vie de la gestion des certificats vous pouvez avoir besoin d'un certificat et comment utiliser les CSR pour une mise en œuvre cohérente des politiques au sein de votre organisation.
Quand générer un RSC ?
Le cycle de vie de la gestion des certificats comporte plusieurs étapes au cours desquelles vous devrez demander un nouveau certificat ou une mise à jour.
Première émission
Vous générerez une nouvelle CSR la première fois que vous aurez besoin d'un certificat pour mettre en place un nouveau serveur web, un VPN ou une application interne. Par exemple, la demande d'un certificatTLS auprès d'une autorité de certification publique telle que DigiCert ou Let's Encrypt nécessite une CSR en entrée.
Ajoutez toutes les nouvelles CSR à l'inventaire des clés PKI de votre organisation, afin de pouvoir contrôler le moment où elles doivent être renouvelées.
Renouvellements avec du nouveau matériel clé
Les certificats arrivant à expiration doivent être renouvelés ou retirés, et de nombreuses politiques exigent le renouvellement simultané des clés. Lorsque vous avez besoin d'une nouvelle paire de clés, vous avez besoin d'un nouveau certificat. La génération d'une nouvelle RSC signifie que la nouvelle clé privée est unique, ce qui empêche la réutilisation cryptographique.
Si des clés ont été exposées lors d'une violation de données, vous devez renouveler tous les certificats concernés afin d'empêcher tout accès non autorisé. En fait, c'est comme changer de mot de passe pour s'assurer qu'une personne possédant un mot de passe (ou une clé) périmé ne puisse pas accéder à vos ressources.
Amélioration de la puissance cryptographique
Outre le renouvellement des certificats, vous pouvez (et devez) mettre à jour les algorithmes de protection utilisés par votre organisation. Les algorithmes cryptographiques évoluent au fur et à mesure que les technologies de décryptage gagnent en maturité, ce qui oblige les organisations à mettre à jour leurs algorithmes ou à risquer des violations de données et d'autres incidents de sécurité lorsque des algorithmes obsolètes sont décryptés.
La clé publique change lorsque votre organisation passe d'un algorithme à l'autre, ce qui nécessite une nouvelle CSR pour obtenir un certificat mis à jour. Ces mises à jour continueront d'être populaires car les algorithmes les plus faibles deviennent obsolètes et donc plus risqués.
Une autre raison pour laquelle les organisations doivent envisager de mettre à jour leurs algorithmes est la suivante cryptographie post-quantique (PQC), qui décrit comment la cryptographie devra évoluer lorsque l'informatique quantique sera une technologie suffisamment mature. La plupart des algorithmes seraient décryptés par les ordinateurs quantiques en un rien de temps, ce qui signifie que votre organisation devrait déjà revoir ses algorithmes cryptographiques pour se préparer à la PQC. Débarrassez-vous des certificats utilisant des algorithmes obsolètes au profit d'algorithmes plus sûrs.
Migrations d'AC ou d'infrastructures
Lorsqu'une organisation modifie son infrastructure PKI , notamment en passant d'une solution sur site à une solution en nuage, la hiérarchie des AC change, la hiérarchie de l'autorité de certification change. Chaque système devra générer à nouveau une CSR pour rétablir la confiance.
Assurez-vous d'avoir pris en compte tous les certificats existants avant une migration importante de l'autorité de certification ou de l'infrastructure, et mettez-les à jour le plus rapidement possible (à l'aide d'un outil automatisé).
Environnements automatisés DevOps
Lorsque vous automatisez votre pipeline DevOps, vous aurez besoin d'un grand nombre de certificats temporaires de courte durée. Les charges de travail Kubernetes utilisent généralement les protocoles Automated Certificate Management Environment (ACME) ou Enrollment over Secure Transport (EST) pour générer dynamiquement des CSR et demander des certificats de courte durée. Le processus se déroule à la vitesse de la machine, mais le principe est le même : une CSR est toujours nécessaire pour chaque certificat.
Assurez le bon fonctionnement de vos pipelines DevOps en automatisant la génération de RSE en même temps que d'autres processus.
IoT et identité des appareils
Les appareils de l'internet des objets Les appareils de lIoT) génèrent des CSR localement lors de la fabrication ou de l'approvisionnement afin de confirmer leur identité et d'obtenir des certificats. Par exemple, un appareil médical intelligent génère une CSR pour demander son certificat d'identité avant de pouvoir se connecter au réseau d'un hôpital.
Veillez à évaluer les algorithmes de sécurité afin de vous assurer que les appareils IoT n'exposent pas les utilisateurs à des risques d'incidents de sécurité.
Comment les RSE sont-ils générés ?
La génération d'une RSC est essentielle pour protéger la base de confiance de chaque certificat utilisé par votre organisation, en particulier pour des raisons telles que signature de code. Lorsque vous générer une CSRvous créez essentiellement une nouvelle paire de clés. La moitié publique de la paire est envoyée dans la demande et la moitié privée reste locale.
Le processus comporte deux étapes fondamentales :
- Générer un CSR. Les CSR regroupent des informations telles que le nom commun (CN), les noms alternatifs du sujet (SAN), des informations sur l'organisation et parfois des extensions telles que l'utilisation de la clé ou les algorithmes de signature. Assurez-vous que vos CSR sont définies sur les algorithmes appropriés et qu'elles correspondent aux paramètres utilisés dans votre organisation.
- L'autorité de certification délivre un certificat. L'autorité de certification vérifie les informations contenues dans votre CSR, la signe et délivre un certificat qui lie la clé publique à une identité.
- Si la CSR est mal formée (mauvais SAN, algorithmes faibles), l'autorité de certification la rejette ou délivre un certificat qui ne répond pas aux exigences de sécurité et de conformité.
Une fois ce processus terminé, votre certificat sécurisé doit être mis à jour. Veillez à ce que les certificats soient stockés en toute sécurité et testez-les pour vous assurer qu'ils répondent aux exigences de votre organisation en matière de sécurité et de conformité.
Pièges courants (et solutions suggérées) de la génération de la RSE
Lorsque vous générez une RSC pour appliquer des politiques de sécurité au sein de votre organisation, vous incluez de nombreuses données que l'autorité de certification doit vérifier. Si ces données sont manquantes ou incorrectes, votre entreprise risque de ne pas pouvoir émettre ou renouveler des certificats vitaux avant leur expiration.
Voici quelques pièges courants de la RSE et des solutions suggérées.
| Écueil | Solution |
| Noms alternatifs de sujets (SAN) manquants ou incorrects. Les navigateurs et clients modernes s'appuient sur les SAN au lieu des CN, de sorte que les CSR qui en sont dépourvus peuvent provoquer des pannes. | Automatiser la génération de CSR avec une plateforme de gestion des certificats afin d'éliminer les fautes de frappe, de garantir des SAN appropriés et d'appliquer des modèles cohérents. |
| PKI distribuée et non normalisée. Certains outils utilisent par défaut des algorithmes obsolètes lors de la génération des CSR, de sorte que les certificats résultants échouent aux audits de conformité. Au sein de l'organisation, différentes équipes peuvent générer des CSR avec des conventions de dénomination ou des structures de champs incohérentes. | Normaliser les modèles de RSE pour aider chaque équipe à générer des demandes avec les mêmes algorithmes approuvés, les mêmes informations sur l'organisation, les mêmes conventions de dénomination, etc. Cela permet d'accélérer et de réduire le coût des audits. |
| Stockage non sécurisé des clés. Lorsque les clés privées sont générées sur un serveur de construction partagé ou copiées entre des machines, elles peuvent être consultées par des personnes non autorisées, ce qui menace la sécurité des données de votre organisation. | Sécuriser les clés dans le système dans lequel elles sont créées et utilisent des modules de sécurité hardware (HSM), des coffres-forts pour clés ou des enclaves sécurisées pour les garder verrouillées. Les CSR doivent également être conservées en toute sécurité et cryptées si possible. |
| Génération manuelle de CSR. Sans automatisation, les CSR de renouvellement sont souvent générés tardivement, ce qui crée une situation difficile pour émettre et déployer de nouveaux certificats avant que les anciens n'expirent. La demande de certificats est élevée et augmente en raison de la croissance du nombre d'utilisateurs et d'appareils. | Suivez chaque certificat dans votre organisation, y compris leur date d'expiration, à l'aide de plateformes de gestion automatisée des certificats. Nous recommandons également d'utiliser des API comme ACME ou EST pour générer automatiquement des CSR à l'échelle là où c'est nécessaire, comme dans les environnements DevOps ou informatiques. |
Comment la génération de CSR s'inscrit-elle dans une gestion mature des certificats ?
Le cycle de vie de la gestion des certificats est massif, intégré et entremêlé dans les environnements modernes, et vital pour le bon déroulement des opérations. Chaque certificat doit être demandé, émis, suivi, déployé, renouvelé avant expiration et finalement retiré. La plupart des organisations gèrent des dizaines de milliers, voire des millions de certificats. Les certificats mal gérés deviennent des sources de failles de sécurité et de pannes qui coûtent des milliers d'euros aux entreprises.
La génération de CSR est une étape critique pour garantir que vos certificats sont valides, à jour et sécurisés. Les processus de découverte et d'inventaire permettent de s'assurer que chaque certificat est pris en compte, mais ce sont les CSR qui sont à l'origine des nouveaux certificats. Les outils de gestion des certificats doivent permettre d'automatiser la génération de CSR dans la mesure du possible.
Des flux de travail matures et automatisés s'étendent de la création des CSR à l'ensemble du cycle de vie des certificats : émission, approvisionnement, renouvellement et révocation. L'endroit le plus simple pour appliquer les politiques de gouvernance des certificats de votre organisation, de la taille de la clé au choix de l'algorithme, est le suivant avant l'émission du certificat. La génération d'une RSC avec les bons paramètres et les bonnes informations permet de s'assurer que les certificats qui en résultent passent les audits de sécurité.
Traiter la création de la RSE comme un processus automatisé, axé sur la politique. Keyfactor Command peut vous aider en découvrant chaque certificat, en automatisant les renouvellements et en évitant les pannes coûteuses, le tout à partir d'une plate-forme unique conçue pour s'adapter. Simplifiez vos opérations PKI et redonnez à votre équipe le temps de se concentrer sur ce qui compte.
