Politique de certificat & Gouvernance

Introduction

Lorsqu'une organisation gère une poignée de certificats, la gouvernance est simple. Quelqu'un demande un certificat, quelqu'un d'autre l'approuve, et une feuille de calcul suit les dates d'expiration. Mais les entreprises modernes ne gèrent pas une poignée ; elles gèrent des dizaines de milliers, parfois des centaines de milliers, à travers plusieurs Autorités de certification, fournisseurs de cloud, et unités commerciales.

À cette échelle, l'absence de politique n'est pas la liberté ; c'est le chaos. Les équipes choisissent différents algorithmes de clé, les certificats sont délivrés avec des conventions de nommage incohérentes, les périodes de validité varient considérablement, et personne ne peut dire avec certitude quels AC sont réellement utilisés. Le résultat est un environnement difficile à auditer, coûteux à maintenir et vulnérable tant aux pannes qu'aux violations de sécurité.

La politique de certificat et la gouvernance résolvent ce problème en établissant un ensemble clair de règles qui définissent qui peuvent demander des certificats, quels types de certificats sont autorisés, comment ils doivent être configurés, et comment la conformité est vérifiée. Ce chapitre explique comment construire et appliquer ce cadre.

Politique de certificat vs Déclaration de pratique

Deux documents fondamentaux définissent le fonctionnement d'une PKI. Bien qu'ils soient souvent confondus, ils servent des objectifs distincts et sont tous deux essentiels à un environnement bien gouverné.

Politique de certificat (CP)

Le CP est un document de haut niveau qui indique ce que l'organisation exige. Il définit les règles, obligations et attentes concernant l'utilisation des certificats : quels types de certificats sont autorisés, quels niveaux d'assurance sont requis, et sous quelles conditions les certificats peuvent être émis ou révoqués. Considérez-le comme la "constitution" de votre PKI.

Déclaration de pratique de certification (CPS)

Le CPS décrit comment le CA met en œuvre les exigences définies dans le CP. Il couvre les procédures opérationnelles, les contrôles techniques, et les mesures de sécurité physique en place. Si le CP indique "les certificats doivent utiliser RSA 2048 ou supérieur," le CPS explique exactement comment le CA applique cette exigence dans son processus d’émission.

Cadre RFC 3647

Le cadre standard pour la rédaction des documents CP et CPS est défini dans le RFC 3647. Il fournit une structure commune avec neuf sections couvrant tout, des obligations et responsabilités aux contrôles de sécurité techniques, facilitant la comparaison des politiques entre les organisations et les AC.

Pourquoi les deux sont importants

Sans un CP, il n'existe aucune règle convenue. Sans un CPS, les règles n'existent que sur papier. Ensemble, ils créent une chaîne de gouvernance complète : le CP définit la norme, et le CPS prouve que la norme est respectée. Les auditeurs et les régulateurs s'attendent à ce que les deux soient à jour et alignés.

Politique clé Décisions

Chaque politique de certificat doit aborder un ensemble de décisions fondamentales. Ces choix façonnent la posture de sécurité de l'ensemble de l'organisation et déterminent la facilité (ou la difficulté) avec laquelle les certificats seront gérés au fil du temps.

Autorités de certification approuvées

Quels AC sont autorisés à délivrer des certificats pour votre organisation ? Cela inclut à la fois les AC publiques (pour le TLS exposé à l'extérieur) et les AC internes (pour le mTLS, l'identité des appareils et la signature de code). Une liste d'AC approuvée empêche les équipes d'obtenir des certificats auprès de fournisseurs non fiables ou non vérifiés, réduisant le risque de certificats fantômes.

Algorithmes de clé & Force

Définir les types et tailles de clés minimaux acceptables. La plupart des organisations aujourd'hui exigent RSA 2048 (ou supérieur) et migrent vers ECDSA P-256 ou P-384 pour de meilleures performances et une sécurité renforcée. Votre politique doit également aborder la préparation post‑quantique et définir un calendrier pour les transitions d'algorithmes.

Périodes de validité

Quelle est la durée de validité des certificats ? Les certificats TLS publics sont déjà limités à 398 jours par le forum CA/Navigateur et passeront bientôt à 90 jours (et éventuellement 47 jours). Les certificats internes peuvent avoir des exigences différentes. Votre politique doit définir la validité maximale pour chaque type de certificat et chaque cas d’utilisation.

Conventions de nommage

Les noms distinctifs de sujet (DN) standardisés et les noms alternatifs de sujet (SAN) facilitent l’identification, la recherche et la gestion des certificats. Une bonne politique de nommage spécifie les champs obligatoires (Organisation, Unité organisationnelle, Pays), interdit les certificats génériques lorsqu’ils ne sont pas nécessaires, et définit les modèles de SAN pour différents environnements.

Mise en œuvre de la politique Application

Rédiger une politique n'est que le début. Le vrai défi est de s'assurer que chaque certificat délivré dans l'ensemble de l'organisation respecte réellement cette politique. Il existe deux approches fondamentales, et la plupart des organisations matures utilisent une combinaison des deux.

Application manuelle

S'appuie sur des examinateurs humains pour vérifier les demandes de certificat par rapport à la politique avant d'approuver l'émission. Cela fonctionne à petite échelle, mais devient un goulot d'étranglement à mesure que le volume de certificats augmente. Les revues manuelles sont également sujettes à l'incohérence : différents examinateurs peuvent interpréter la même politique différemment.

Application automatisée

Utilise CLM platforms pour valider chaque demande de certificat par rapport aux règles de la politique avant que le certificat ne soit émis. Les demandes non conformes sont automatiquement rejetées ou signalées. Cette approche s'adapte à n'importe quel volume et garantit une cohérence à 100 %.

Contrôles pré-émission

L'application la plus efficace se produit avant la création du certificat. L'émission basée sur des modèles (où les demandeurs choisissent parmi des profils de certificats préapprouvés) élimine par conception des catégories entières de violations de politique, plutôt que de les détecter après coup.

Surveillance post-émission

Même avec des contrôles pré-émission solides, les organisations ont besoin d'une surveillance continue pour détecter les certificats émis en dehors du pipeline géré. L'analyse des réseaux, des environnements cloud et des journaux de transparence des certificats révèle des certificats non conformes ou inconnus qui nécessitent une remédiation.

Accès basé sur les rôles & Flux d'approbation

La gouvernance nécessite plus que des règles concernant les configurations de certificats. Elle exige également une responsabilité claire : qui est autorisé à faire quoi, et qui doit approuver les opérations sensibles.

Définitions des rôles

Définissez des rôles distincts pour vos opérations de certificats. Les rôles courants incluent Requester (peut soumettre des demandes de certificats), Approver (peut approuver ou rejeter les demandes), Administrator (peut gérer les configurations et modèles de l'CA), et Auditor (accès en lecture seule aux journaux et rapports). La séparation des fonctions est essentielle : la personne qui demande un certificat ne doit pas être la même que celle qui l'approuve).

Flux d'approbation

Tous les certificats ne nécessitent pas le même niveau d'examen. Un certificat interne à faible risque pour un environnement de développement peut être approuvé automatiquement s'il correspond à un modèle préapprouvé. Un certificat générique ou un certificat pour une passerelle de paiement en production doit nécessiter une approbation explicite d'un membre de l'équipe de sécurité. Les flux de travail d'approbation à plusieurs niveaux équilibrent rapidité et contrôle.

Responsabilité & Redevabilité

Chaque certificat doit avoir un propriétaire clair : une équipe ou un individu responsable de son renouvellement, de sa configuration et de sa mise hors service. Sans cartographie de la propriété, les certificats deviennent orphelins avec le temps, et lorsqu’ils expirent, personne ne sait qui contacter. Un cadre de gouvernance doit rendre l’attribution de la propriété obligatoire au moment de l’émission.

Audit & Conformité Rapports

La gouvernance n'est pas complète tant que vous ne pouvez pas la prouver. Les cadres réglementaires comme ISO 27001, eIDAS et NIS2 exigent que les organisations démontrent que leurs actifs cryptographiques sont gérés conformément aux politiques documentées. Les auditeurs veulent des preuves, pas des promesses.

Une audit efficace et des rapports de conformité pour les certificats nécessitent plusieurs capacités. Premièrement, un inventaire complet de tous les certificats de l'organisation, y compris ceux émis par des AC externes. Deuxièmement, tableaux de bord de conformité des politiques qui montrent d'un coup d'œil quels certificats sont conformes à la politique et lesquels la violent (algorithme incorrect, expiré, AC inconnue, propriétaire manquant). Troisièmement, journaux d'audit immuables qui enregistrent chaque action : qui a demandé un certificat, qui l'a approuvé, quand il a été émis, et quand il a été renouvelé ou révoqué.

Les organisations qui investissent dans gouvernance PKI prête à la conformité constatent que les audits deviennent plus rapides et moins stressants. Au lieu de se précipiter pour rassembler les preuves manuellement, ils exportent les rapports directement depuis leur plateforme CLM. La politique est documentée, l'application est automatisée, et chaque action est enregistrée.

Evertrust & Gouvernance des politiques

Définir et appliquer des politiques de manière centralisée: Evertrust CLM vous permet de définir des politiques de certificat (CAs approuvés, algorithmes de clé, limites de validité, règles de nommage) et de les appliquer automatiquement à chaque demande de certificat, quel que soit le CA émetteur.

Contrôle d'accès basé sur les rôles: RBAC intégré avec des flux de travail d'approbation configurables garantit que les bonnes personnes approuvent les bons certificats. La séparation des fonctions est appliquée par la plateforme, pas par la convention.

Rapport prêt pour l'audit

Émission basée sur des modèles: Evertrust PKI

PKI

CLM

Cas d’utilisation

Secteurs

Conformité

Apprendre

Outils & analyses

Événements & Communauté