Modèle de cahier des charges PKI neutre : exigences AC privée et CLM, protection des clés, gouvernance, grille de notation, POC et clauses de sortie.
Ce modèle de cahier des charges PKI est un ensemble d'exigences neutre vis-à-vis des éditeurs, destiné à l'achat d'une autorité de certification (AC) privée et d'une plateforme de gestion du cycle de vie des certificats (CLM). Il suit les sept rubriques que couvre en général une réponse à un appel d'offres PKI : AC et émission, inscription, visibilité et automatisation, protection des clés, cas d'usage, gouvernance, déploiement et éditeur. Chaque exigence porte une priorité et les preuves à demander, et chaque tableau peut être copié dans un tableur.
Les exigences sont des capacités qu'une catégorie de produits sérieuse peut satisfaire et prouver. Les points que seules certaines architectures offrent sont signalés Avancé, pour que vous décidiez s'ils méritent un poids dans votre notation. Si vous hésitez encore entre plusieurs produits, lisez d'abord le guide d'achat de la meilleure solution PKI.
Ce guide s'adresse aux architectes sécurité, responsables de PKI, équipes infrastructure et achats qui remplacent ou complètent une PKI existante (souvent Microsoft AD CS), ajoutent une gestion du cycle de vie des certificats ou se préparent à des durées de validité plus courtes.
Mode d'emploi :
Légende des priorités :
Avant d'envoyer l'appel d'offres, faites une passe de découverte : scanner le réseau, interroger AD CS, lister les certificats des fournisseurs cloud et lire les secrets Kubernetes. Vous trouverez presque toujours des certificats sans propriétaire. Un éditeur ne peut pas dimensionner sa proposition sans ce chiffre, qui devient aussi la référence de votre POC.
Désignez un responsable pour chaque domaine : PKI et sécurité (politique d'AC), infrastructure et plateformes (cibles de déploiement), identité (AD, MDM), responsables applicatifs, risque et audit (preuves), juridique et achats (contrat, réversibilité) et, le cas échéant, l'équipe OT ou sécurité produit qui provisionne les équipements.
Fixez les pondérations avant de lire la moindre réponse (voir la grille ci-dessous). Décidez à l'avance si la juridiction, les certifications et la garde des clés sont éliminatoires ou simplement notées.
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| CA-01 | Créer et exploiter une hiérarchie d'AC privée (racine hors ligne ou protégée, intermédiaires, AC émettrices) avec cycle de vie configurable | Obligatoire | Schéma d'architecture, documentation d'administration, démonstration |
| CA-02 | Importer et exploiter des AC existantes, avec un chemin de migration documenté depuis la PKI actuelle | Souhaitable | Guide de migration, migration de référence |
| CA-03 | Profils ou modèles de certificats contrôlant sujet, SAN, usage de clé, EKU, validité et algorithme | Obligatoire | Documentation des profils, captures d'écran |
| CA-04 | Révocation par CRL et OCSP (RFC 6960) publiés par AC, avec disponibilité et mise en cache documentées | Obligatoire | Architecture de révocation, test du répondeur OCSP |
| CA-05 | La révocation d'une AC révoque ou invalide de façon maîtrisée les certificats qu'elle a émis (cascade) | Souhaitable | Documentation, démonstration |
| CA-06 | Pilotage d'AC externes (publiques et cloud, par exemple Let's Encrypt, DigiCert, Sectigo, AWS Private CA, Azure, Google, AD CS) pour mutualiser inventaire et renouvellement | Souhaitable | Liste des AC prises en charge et documentation des connecteurs |
| CA-07 | Services connexes : AC SSH et horodatage RFC 3161 | Souhaitable (Obligatoire si utilisés) | Documentation produit, démonstration |
| CA-08 | Plusieurs algorithmes de clé par AC (RSA, ECDSA et post-quantique, voir KP-05) | Souhaitable | Matrice des algorithmes |
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| EN-01 | ACME (RFC 8555), défis http-01 et dns-01 compris, utilisable par cert-manager, certbot et clients similaires | Obligatoire | Documentation du protocole, test d'interopérabilité |
| EN-02 | ACME Renewal Information (ARI) pour que les clients renouvellent quand l'AC l'indique | Souhaitable | Documentation, test avec un client compatible ARI |
| EN-03 | EST (RFC 7030), génération de clé côté serveur comprise si vos équipements l'exigent | Souhaitable (Obligatoire pour les flottes d'équipements) | Documentation du protocole, test |
| EN-04 | SCEP (RFC 8894) pour les plateformes MDM et équipements réseau | Obligatoire si vous utilisez un MDM ou NDES | Documentation, guide d'intégration MDM |
| EN-05 | CMP (RFC 4210) et profil allégé (RFC 9483) | Souhaitable (Obligatoire pour télécoms, industrie, automobile) | Documentation, test d'interopérabilité avec votre client |
| EN-06 | Auto-inscription Microsoft par stratégie de groupe pour les clients joints au domaine, limites indiquées | Obligatoire si vous utilisez Active Directory | Documentation, test sur vos versions de Windows |
| EN-07 | Distribution de certificats via Intune et autres MDM (SCEP ou PKCS) | Souhaitable | Guide d'intégration |
| EN-08 | Émetteur cert-manager pour Kubernetes, natif ou via ACME | Souhaitable | Documentation, test de bout en bout |
| EN-09 | API REST documentée couvrant émission, révocation, inventaire et déploiement | Obligatoire | Référence de l'API, exemples d'appels |
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| VA-01 | Découverte des certificats par scan réseau et/ou agents, y compris ceux non émis par la plateforme | Obligatoire | Documentation de la découverte, scan de votre réseau de test |
| VA-02 | Inventaire central avec propriétaire, expiration, algorithme et contrôles de conformité à une politique | Obligatoire | Démonstration, liste des contrôles intégrés |
| VA-03 | Renouvellement et redéploiement automatiques, avec reprises et temporisation, sans boucle de renouvellement sur les durées courtes | Obligatoire | Documentation, test à validité courte |
| VA-04 | Alertes d'expiration par seuil vers e-mail, messagerie collaborative et webhooks | Obligatoire | Démonstration de configuration des alertes |
| VA-05 | Déploiement push vers répartiteurs de charge, pare-feu, serveurs web, hôtes Windows et magasins de clés Java, avec validation et retour arrière | Souhaitable | Liste des cibles, démonstration du retour arrière |
| VA-06 | Fonctionnement démontré avec des certificats à 47 jours (ou moins) à votre volume | Obligatoire | Résultats de test de charge avec conditions précisées ; POC |
| VA-07 | Renouvellement unique entre réplicas (pas d'émission en double en cluster) | Souhaitable | Note d'architecture, test |
| VA-08 | Intégration ITSM/CMDB pour le propriétaire et les tickets de changement | Souhaitable | Documentation d'intégration |
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| KP-01 | Clés privées d'AC générées dans un module de sécurité matériel (HSM) ou un KMS managé et non exportables | Obligatoire | Liste des HSM/KMS pris en charge, preuve de génération |
| KP-02 | Niveau de validation du HSM indiqué (par exemple FIPS 140-2 ou 140-3) et fabricants pris en charge | Souhaitable | Numéros de certificat du fabricant du HSM |
| KP-03 | Prise en charge des cérémonies de clé pour les racines : racine hors ligne, génération documentée et témoignée, dépositaires M-sur-N | Souhaitable | Procédure de cérémonie |
| KP-04 | Sauvegarde, restauration et reprise après sinistre des clés et données d'AC, procédures testées | Obligatoire | Documentation PRA, dernier rapport de test |
| KP-05 | Certificats post-quantiques : ML-DSA (FIPS 204) et SLH-DSA (FIPS 205), idéalement hybrides ou composites, pour les AC privées | Souhaitable | Liste des algorithmes, certificat d'exemple, garde des clés PQC |
| KP-06 | Option de plateforme imposant que les nouvelles clés d'AC résident dans un coffre (aucune clé logicielle) | Avancé | Documentation de configuration |
| KP-07 | Clés de signature d'AC détenues par calcul à seuil ou multipartite, de sorte que la clé ne soit jamais entière en un seul endroit | Avancé | Document d'architecture, algorithmes pris en charge et limites |
| KP-08 | Option de clé détenue par le client : l'éditeur ne peut pas signer seul avec vos clés d'AC | Avancé | Architecture et modèle d'exploitation |
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| UC-01 | Certificats TLS pour serveurs et charges de travail (internes et entre services) | Obligatoire | Configuration de référence |
| UC-02 | Identité des équipements et objets connectés à grande échelle, avec des protocoles de provisionnement adaptés | Souhaitable (Obligatoire pour les flottes d'équipements) | Client de référence, volumes |
| UC-03 | S/MIME avec séquestre et récupération des clés, avec contrôle de qui peut récupérer | Souhaitable si vous utilisez S/MIME | Architecture du séquestre, workflow de récupération |
| UC-04 | Signature de code en tant que service : clés dans un coffre ou HSM, intégration à vos outils, contrôles d'approbation | Souhaitable si vous signez du code | Liste des outils pris en charge, démonstration |
| UC-05 | Certificats VPN, Wi-Fi et 802.1X | Souhaitable | Guides d'intégration |
| UC-06 | Certificats utilisateur et ordinateur pour l'ouverture de session Windows ou la carte à puce, avec comportement de mappage indiqué | Souhaitable si applicable | Documentation, test sur vos contrôleurs de domaine |
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| GV-01 | Contrôle d'accès par rôles avec séparation des tâches (administrateur d'AC, gestionnaire de certificats, auditeur) | Obligatoire | Matrice des rôles |
| GV-02 | Workflow d'approbation des opérations sensibles (création d'AC, révocation, profils à risque) | Souhaitable | Démonstration du workflow |
| GV-03 | Quorum d'approbation M-sur-N pour les opérations PKI les plus sensibles | Avancé | Documentation des opérations couvertes |
| GV-04 | Politique contextuelle sur les opérations PKI (utilisateur, IP, localisation, heure) | Avancé | Documentation de la politique, démonstration |
| GV-05 | Journal d'audit de tous les événements d'administration et d'émission, exportable et conservé selon votre politique | Obligatoire | Schéma du journal, paramètres de rétention |
| GV-06 | Journal d'audit infalsifiable (signé et/ou chaîné) pour que modifications et suppressions soient détectables | Souhaitable | Description technique et procédure de vérification |
| GV-07 | Transmission des événements d'audit à votre SIEM (Splunk, syslog, Elastic ou équivalent) | Obligatoire | Documentation d'intégration |
| GV-08 | Rapports de conformité selon le référentiel choisi (par exemple Mozilla, NIST, PCI) | Souhaitable | Exemples de rapports |
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| DV-01 | Options de déploiement conformes à votre politique : SaaS, mono-locataire hébergé, sur site, réseau isolé | Obligatoire | Architecture par option |
| DV-02 | Haute disponibilité et reprise après sinistre avec RTO et RPO indiqués | Obligatoire | Conception HA, SLA, résultats de test PRA |
| DV-03 | Support 24/7 avec délais de réponse écrits par niveau de gravité | Souhaitable | Politique de support |
| DV-04 | Certifications de l'éditeur : ISO 27001 et rapport SOC 2 ; WebTrust, statut qualifié eIDAS, Critères Communs ou certification nationale selon votre usage | Souhaitable | Certificats et rapports d'audit sous NDA |
| DV-05 | Juridiction de l'éditeur, localisation des données et sous-traitants communiqués ; aucun accès à vos clés d'AC sans votre autorisation | Obligatoire | Annexes contractuelles, liste des sous-traitants |
| DV-06 | Modèle tarifaire transparent (par certificat, par AC, par point de terminaison, par palier de volume) avec une estimation chiffrée | Obligatoire | Grille tarifaire |
| DV-07 | Politique de mises à jour et de correctifs, engagements de feuille de route sur le post-quantique et les changements de durée | Souhaitable | Notes de version, feuille de route sous NDA |
| DV-08 | Export de la configuration d'AC, de l'inventaire et des données d'audit dans des formats ouverts (voir clauses de sortie) | Obligatoire | Documentation de l'export, démonstration |
Notez chaque critère Souhaitable et Avancé de 0 à 5, multipliez par le poids et additionnez. Appliquez d'abord les critères Obligatoire en éliminatoire.
Échelle de 0 à 5.
| Note | Signification |
|---|---|
| 0 | Non proposé, ou sans preuve |
| 1 | Feuille de route seulement |
| 2 | Partiellement proposé, lacunes ou contournements importants |
| 3 | Proposé, attesté par la documentation |
| 4 | Proposé, démontré pendant le POC |
| 5 | Proposé, démontré pendant le POC et au-delà de votre besoin, avec un client de référence |
Pondérations d'exemple. Ce sont des chiffres génériques à titre d'illustration ; fixez les vôtres.
| Groupe | Poids d'exemple |
|---|---|
| AC et émission | 15 % |
| Inscription | 15 % |
| Visibilité et automatisation | 20 % |
| Protection des clés | 15 % |
| Cas d'usage | 10 % |
| Gouvernance | 15 % |
| Déploiement et éditeur | 10 % |
Exemple chiffré (chiffres inventés). L'éditeur A obtient des moyennes de 4, 3, 4, 3, 3, 4, 4 sur les sept groupes dans l'ordre ci-dessus : 0,15x4 + 0,15x3 + 0,20x4 + 0,15x3 + 0,10x3 + 0,15x4 + 0,10x4 = 0,60 + 0,45 + 0,80 + 0,45 + 0,30 + 0,60 + 0,40 = 3,60 sur 5. L'éditeur B obtient 3, 4, 3, 4, 4, 3, 4 : 0,45 + 0,60 + 0,60 + 0,60 + 0,40 + 0,45 + 0,40 = 3,50. Un écart aussi faible indique qu'il faut laisser le POC trancher.
Conseil : si vous incluez des critères Avancé comme les clés d'AC détenues par MPC ou le quorum M-sur-N, donnez-leur un poids qui reflète votre analyse de risque. Les pondérer fortement sans risque correspondant fausse simplement le résultat ; les pondérer à zéro alors que vous exploitez une racine de grande valeur est tout aussi erroné.
Demandez des réponses écrites avec liens vers la documentation, par ID d'exigence.
AC et émission
Inscription et automatisation
Protection des clés
Gouvernance
Déploiement et éditeur
Menez un POC limité dans le temps (deux à quatre semaines), avec des tests réussite/échec sur vos propres systèmes. Documentez conditions et résultats.
| N° | Test | Critère de réussite |
|---|---|---|
| 1 | Construire une hiérarchie à deux niveaux avec des clés d'AC résidant en HSM ou KMS | Les clés ne sont pas exportables ; la chaîne est validée par vos clients |
| 2 | S'inscrire via chaque protocole utilisé (ACME, EST, SCEP, CMP, auto-inscription) | De vrais clients obtiennent et renouvellent des certificats sans geste manuel |
| 3 | Émettre et renouveler à 47 jours de validité en préproduction, 500 à 1 000 certificats | Tous les renouvellements réussissent ; pas de déluge d'alertes ni d'émission en double |
| 4 | Simuler l'échec d'un déploiement vers un répartiteur de charge ou un serveur web | Le retour arrière rétablit l'ancien certificat ; le service reste disponible |
| 5 | Lancer la découverte sur un segment réseau contenant des certificats connus et inconnus | Les certificats inconnus sont trouvés et attribués |
| 6 | Révoquer un certificat puis une AC intermédiaire | CRL/OCSP reflètent le changement dans le délai annoncé |
| 7 | Tenter de modifier ou de supprimer un enregistrement d'audit, puis vérifier le journal | L'altération est détectée |
| 8 | Effectuer une opération sensible avec et sans les approbations requises | L'opération est bloquée sans approbation ; la preuve est journalisée |
| 9 | Restaurer la plateforme depuis une sauvegarde dans un environnement vierge | L'AC fonctionne et la garde des clés est préservée |
| 10 | Émettre un certificat post-quantique ou composite et le valider avec la partie utilisatrice visée | La chaîne est validée ; limites documentées |
| 11 | Transmettre les événements d'audit à votre SIEM | Les événements apparaissent avec les champs nécessaires |
Si vous avez retenu des critères Avancé, ajoutez : créer une AC dont la clé est détenue par seuil et signer par son intermédiaire ; exécuter une approbation par quorum M-sur-N ; appliquer une politique par IP ou par heure et vérifier qu'elle refuse les demandes hors politique.
[Organisation] recherche une plateforme de PKI privée et de gestion du cycle de vie des certificats couvrant [nombre] certificats sur [serveurs, charges de travail, postes, équipements, signature]. La solution doit exploiter des autorités de certification privées dont les clés sont protégées par du matériel ou un service de clés managé, servir les protocoles d'inscription listés au groupe 2, découvrir et inventorier les certificats de toutes provenances, automatiser le renouvellement et le déploiement pour des durées de validité de 47 jours ou moins, offrir une gouvernance par rôles avec une piste d'audit vérifiable, et pouvoir être déployée en [SaaS / sur site / hybride] sous [juridiction]. Les candidats répondent par écrit à chaque exigence numérotée en citant leur documentation, indiquent toute limite et participent à une preuve de concept sur les systèmes de [organisation]. Les réponses seront notées selon les critères pondérés de l'annexe [X] ; les exigences marquées Obligatoire sont éliminatoires.
Que doit contenir un cahier des charges PKI ? Il doit contenir le périmètre et les volumes, puis les exigences regroupées par AC et émission, protocoles d'inscription, visibilité et automatisation, protection des clés, cas d'usage, gouvernance, déploiement et conditions de l'éditeur. Ajoutez une grille de notation, un plan de POC et des clauses de sortie. Ce modèle fournit chacun de ces éléments.
Comment rédiger des exigences PKI neutres vis-à-vis des éditeurs ? Formulez chaque exigence comme une capacité testable (par exemple « ACME selon la RFC 8555 avec dns-01 ») plutôt que comme le nom d'une fonction de produit, et demandez des preuves. Classez les capacités différenciantes en Avancé pour qu'elles soient notées et non exigées.
Quels points rendre obligatoires dans un appel d'offres PKI ? En général : clés d'AC non exportables protégées par HSM ou KMS, révocation, protocoles d'inscription déjà utilisés, découverte et renouvellement automatique, RBAC, journal d'audit exportable avec transmission au SIEM, HA/PRA et clause d'export des données. Le reste dépend de votre parc et de vos risques.
Comment tester la préparation aux certificats à 47 jours ? Faites un test en préproduction à 47 jours de validité avec au moins quelques centaines de certificats, mesurez le taux de réussite des renouvellements, le volume d'alertes et le débit d'émission, et vérifiez l'absence de boucles de renouvellement. Le calendrier du CA/Browser Forum vise le TLS public, mais la même exigence d'automatisation s'applique à tout certificat de courte durée.
Faut-il exiger des certificats post-quantiques dans un appel d'offres PKI ? Intégrez-les en Souhaitable pour les AC privées, avec ML-DSA (FIPS 204) et SLH-DSA (FIPS 205), idéalement hybrides ou composites, et demandez comment les clés d'AC post-quantiques sont protégées. Le TLS public ne les accepte pas encore ; ne les exigez donc pas à ce niveau.
La garde des clés d'AC par MPC ou seuil doit-elle être obligatoire ? Seulement si votre modèle de menace exige qu'aucun HSM, administrateur ou hôte isolé ne puisse utiliser une clé d'AC. C'est une capacité différenciante que seuls certains éditeurs proposent ; notez-la en Avancé plutôt que d'écarter des candidats sur ce seul point.
Quel délai prévoir pour les réponses et le POC ? Prévoyez trois à quatre semaines pour les réponses écrites, puis deux à quatre semaines de POC avec les éditeurs présélectionnés. Un POC plus court couvre rarement la découverte, le renouvellement à volume réel et les tests de défaillance.
Puis-je transformer ces tableaux en tableur ? Oui. Copiez chaque tableau dans votre tableur, gardez la colonne ID et ajoutez des colonnes pour la réponse, la note et le lien de preuve de chaque éditeur.
Un bon cahier des charges PKI est une liste d'exigences testables, une grille de notation claire et une courte preuve de concept qui cherche à mettre en défaut les affirmations de l'éditeur. Utilisez les exigences Obligatoire pour filtrer, les Souhaitable pour différencier, et les Avancé seulement là où votre analyse de risque le justifie. Puis vérifiez chaque réponse dans votre propre environnement.
DuoKey publie ses capacités PKI selon ces mêmes critères sur les pages de comparaison et dans le guide d'achat. Pour dérouler le plan de POC ci-dessus avec DuoKey, démarrez un essai ou consultez la page produit gestion des certificats.
Écrit par
DuoKey Team
Ressources associées
Dites-nous où le contrôle est difficile aujourd’hui. Nous vous aiderons à définir une prochaine étape concrète.
