Cahier des charges KMS neutre : 90 exigences en 9 groupes, grille de notation, questions aux éditeurs, signaux d'alerte, tests de PoC et clauses de sortie.
Ce modèle de cahier des charges KMS vous donne un ensemble d'exigences neutre vis-à-vis des éditeurs pour un appel d'offres de gestion des clés de chiffrement : neuf groupes d'exigences, environ 90 exigences avec leur priorité et la preuve à demander, une grille de notation pondérée, des questions aux éditeurs, des signaux d'alerte, un plan de test de faisabilité (PoC) et des clauses de sortie. Il couvre la gestion de clés sur HSM, cloud, externe (HYOK, DKE, XKS, EKM, BYOK) et fondée sur le MPC. Tous les tableaux peuvent être copiés dans un tableur.
Cette checklist s'adresse aux architectes sécurité, RSSI, acheteurs et équipes conformité qui doivent émettre un appel d'offres, une demande d'information (RFI) ou un cahier des charges pour un KMS. Elle suppose que vous savez déjà pourquoi centraliser la gestion des clés ; sinon, commencez par notre guide de la gestion des clés en entreprise et utilisez le guide de la meilleure solution KMS pour comprendre le marché.
Mode d'emploi :
Les exigences sont rédigées pour que des produits sérieux de plusieurs catégories (plateformes centrées sur le HSM, KMS multicloud, KMS fondé sur le MPC, gestion des clés en tant que service) puissent les satisfaire et les prouver. Les éléments que seules certaines architectures fournissent sont étiquetés Avancé.
Consacrez une semaine à ces questions. La plupart des projets KMS échouent ici, pas dans le choix de l'éditeur.
Périmètre.
Inventaire.
Parties prenantes.
Contraintes et moteurs.
Critères de décision. Fixez les pondérations de la grille ci-dessous avant de voir la moindre réponse. Modifier les poids après les démonstrations est la porte d'entrée des biais.
Légende : O = Obligatoire, R = Recommandé, A = Avancé (différenciant). La colonne Preuve indique ce que l'acheteur doit demander dans la réponse.
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| KL-01 | Générer des clés symétriques et asymétriques dans le produit avec un générateur de nombres aléatoires documenté | O | Document d'architecture ; description du générateur |
| KL-02 | États de clé explicites (par exemple pré-activation, active, suspendue, désactivée, compromise, détruite) conformes à NIST SP 800-57 | O | Modèle d'états dans la documentation ; démonstration |
| KL-03 | Rotation manuelle conservant les versions antérieures disponibles pour déchiffrer les données existantes | O | Documentation ; test PT-04 |
| KL-04 | Rotation planifiée (automatique) par clé ou par politique, à intervalles configurables | R | Documentation ; démonstration d'un calendrier |
| KL-05 | Rotation sans réétiquetage, rechiffrement ni reconfiguration des services dépendants lorsque la plateforme le permet | R | Documentation d'intégration ; PoC |
| KL-06 | Application de la période cryptographique : une clé ne peut plus protéger de nouvelles données après son terme | R | Capture de la configuration de politique |
| KL-07 | Destruction de clé avec preuve (trace de destruction conservée, métadonnées gardées) | O | Extrait du journal d'audit |
| KL-08 | Import de clé (BYOK) avec enveloppe de protection et cérémonie de clé documentée | R | Procédure |
| KL-09 | Export de clé en formats standard (par exemple PKCS#8, PKCS#12, KMIP) pour les clés désignées exportables, sous permission et audit | R | Documentation ; test PT-09 |
| KL-10 | Attributs par clé : propriétaire, usage, étiquettes, expiration, unité organisationnelle | R | Modèle de données |
| KL-11 | Révocation et désactivation d'urgence d'une clé ou de toutes les clés d'une application, effectives immédiatement | O | Procédure d'exploitation ; test PT-06 |
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| KC-01 | L'éditeur indique qui peut techniquement utiliser ou exporter une clé complète (client, éditeur, fournisseur cloud) | O | Déclaration écrite sur la garde |
| KC-02 | Aucun matériau de clé en clair au repos ; hiérarchie de protection documentée | O | Document d'architecture |
| KC-03 | Prise en charge d'un backend HSM, avec modèle de HSM et numéro de certificat FIPS 140-3 (ou 140-2 si toléré) à jour | R | Numéro de certificat CMVP |
| KC-04 | Les validations de module de l'éditeur sont listées par module et version, non par société | O | Liste de certificats |
| KC-05 | Séparation entre magasin de clés et magasin de données : l'hébergeur des données ne détient pas la clé utilisable (option HYOK) | R | Architecture ; liste d'intégrations |
| KC-06 | Option d'hébergement maîtrisé par le client : sur site, compte cloud du client ou tenant dédié chez l'éditeur | R | Guide de déploiement |
| KC-07 | Isolation des tenants : les clés d'une unité métier ou d'un client sont séparées cryptographiquement et administrativement | O | Modèle d'isolation ; test |
| KC-08 | Clé jamais assemblée en un seul lieu pendant la génération, l'usage et la sauvegarde (cryptographie à seuil ou calcul multipartite) | A | Description du protocole ; revue indépendante |
| KC-09 | Les opérateurs de l'éditeur n'accèdent pas au matériau de clé du client ; contrôles techniques et procéduraux documentés | R | Politique d'exploitation et d'accès ; rapport SOC 2 ou ISO |
| KC-10 | Plusieurs backends de clés sélectionnables par coffre (logiciel, HSM, KMS cloud, MPC) depuis une seule console | A | Démonstration |
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| IN-01 | Serveur KMIP (version prise en charge, par exemple 2.1) avec la liste des opérations implémentées | O | Tableau de couverture des opérations |
| IN-02 | Bibliothèque PKCS#11 (version indiquée) avec la liste des fonctions prises en charge | O | Tableau de couverture des fonctions |
| IN-03 | Prise en charge du proxy AWS KMS External Key Store (XKS) | R | Documentation ; client référent |
| IN-04 | Point d'accès Microsoft 365 Double Key Encryption (DKE) et/ou prise en charge de Customer Key | R | Documentation ; PoC sur votre tenant |
| IN-05 | Gestion externe des clés pour les clés gérées par le client Azure (Managed HSM EKM ou équivalent) | R | Documentation |
| IN-06 | Gestion externe des clés Google Cloud ou chiffrement côté client | R | Documentation |
| IN-07 | Chiffrement des bases : Oracle TDE, SQL Server EKM, PostgreSQL, MySQL, MongoDB, Cassandra selon vos besoins | R | Guide par base |
| IN-08 | Clés gérées par le client des SaaS : Salesforce, ServiceNow, Snowflake, Workday selon vos besoins | R | Guide par plateforme |
| IN-09 | Chiffrement d'infrastructure : disques et machines virtuelles (LUKS, BitLocker, VMware, Nutanix) via KMIP ou PKCS#11 | R | Guide ; test |
| IN-10 | Plateformes de secrets : auto-déverrouillage et seal wrap de HashiCorp Vault ou OpenBao via PKCS#11 | R | Guide |
| IN-11 | API REST couvrant toutes les opérations d'administration et de cryptographie, versionnée, avec référence publiée | O | Documentation de l'API |
| IN-12 | Prise en charge de l'infrastructure as code (par exemple un fournisseur Terraform) | R | Documentation du fournisseur |
| IN-13 | SDK clients ou service cryptographique pour les applications sur mesure | R | Documentation des SDK |
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| CR-01 | AES-128/192/256 avec modes authentifiés (par exemple GCM), et enveloppe de clé | O | Liste des algorithmes |
| CR-02 | RSA (2048 à 4096 bits) et courbes elliptiques (P-256, P-384, P-521) pour la signature et le chiffrement | O | Liste des algorithmes |
| CR-03 | HMAC et hachage avec les familles SHA-2 et SHA-3 | R | Liste des algorithmes |
| CR-04 | Politique cryptographique : les administrateurs restreignent algorithmes, tailles de clé et opérations autorisées par coffre ou par clé | R | Captures de politique ; test de refus |
| CR-05 | Prise en charge des standards post-quantiques du NIST : ML-KEM (FIPS 203), ML-DSA (FIPS 204) et SLH-DSA (FIPS 205), ou feuille de route datée | R | Notes de version ; engagement de feuille de route |
| CR-06 | Modes hybrides (classique plus post-quantique) d'établissement de clé ou de signature | A | Documentation |
| CR-07 | Agilité cryptographique : changer d'algorithme par politique sans modifier le code applicatif | A | Démonstration |
| CR-08 | Export d'un inventaire cryptographique (quel algorithme protège quoi), par exemple un CBOM | A | Exemple d'export |
| CR-09 | Déclaration du statut de validation des modules qui exécutent les opérations cryptographiques | O | Numéros de certificat |
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| AC-01 | Connexion des administrateurs via le fournisseur d'identité de l'entreprise (OIDC ou SAML) avec authentification multifacteur | O | Documentation ; démonstration |
| AC-02 | Contrôle d'accès par rôles fin, avec rôles personnalisés limités à des clés, coffres ou unités organisationnelles | O | Modèle de rôles |
| AC-03 | Séparation des tâches : ceux qui gèrent les clés ne peuvent pas s'en servir pour déchiffrer des données, et inversement | O | Matrice de rôles |
| AC-04 | Approbation par quorum (M sur N, quatre yeux) pour les actions sensibles : suppression, export, restauration, changement de politique | O | Documentation ; test PT-05 |
| AC-05 | Autorisation à l'exécution de l'usage d'une clé par groupe d'identité, pas seulement par utilisateur | R | Documentation |
| AC-06 | Conditions contextuelles d'usage des clés (plage IP, pays, heure) | A | Exemple de politique ; test de refus |
| AC-07 | Règles de refus explicites qui l'emportent sur les autorisations, pour la réponse à incident | R | Ordre d'évaluation des politiques |
| AC-08 | Plusieurs fournisseurs d'identité simultanés (par exemple Entra ID et un autre fournisseur OIDC) | R | Guide de configuration |
| AC-09 | TLS mutuel ou contrôle de certificat client optionnel sur les appels d'usage de clé | A | Guide de configuration |
| AC-10 | Les règles d'accès s'appliquent immédiatement après modification, sans redémarrage ni redéploiement | R | Démonstration |
| AC-11 | Procédure de secours (break-glass) avec identifiants scellés et revue obligatoire | R | Procédure |
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| AM-01 | Chaque opération sur les clés et d'administration est journalisée avec identité, heure, source et résultat | O | Exemple de schéma de journal |
| AM-02 | Export des journaux vers un SIEM (syslog/CEF, Splunk, Microsoft Sentinel, QRadar) en quasi temps réel | O | Guide d'intégration |
| AM-03 | Journaux infalsifiables (enregistrements signés ou chaînés par hachage) | A | Description technique |
| AM-04 | Les journaux consignent aussi les opérations refusées et les décisions de politique, pas seulement les succès | R | Extrait de journal |
| AM-05 | Durée de conservation configurable et export vérifiable par les auditeurs | R | Paramètres de rétention |
| AM-06 | Tableau de bord de santé et d'usage (requêtes, erreurs, latence, nombre de clés) | R | Démonstration |
| AM-07 | Protocoles de supervision standard (SNMP v2c/v3, métriques Prometheus ou équivalent) pour les équipes d'exploitation | R | Documentation |
| AM-08 | Alertes sur les événements de clés : expiration, approbations échouées, volume de requêtes anormal | R | Configuration des alertes |
| AM-09 | Rapports de conformité alignés sur ISO/IEC 27001:2022 Annexe A.8.24 et sur vos cadres réglementaires | R | Rapport type |
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| AV-01 | Conception haute disponibilité sans point de défaillance unique pour les opérations de clés | O | Schéma d'architecture |
| AV-02 | Engagement de disponibilité (SLA) documenté pour le service managé, ou architecture de référence pour l'auto-exploitation | O | Texte du SLA |
| AV-03 | Déploiement multi-sites ou multi-régions résistant à la perte d'un centre de données | R | Architecture de référence |
| AV-04 | Sauvegarde et restauration des clés et de la configuration, avec procédure documentée et temps de reprise testé | O | Procédure ; test PT-07 |
| AV-05 | Objectifs de reprise indiqués (RTO et RPO) | R | Engagement écrit |
| AV-06 | Comportement lorsque le KMS est injoignable : effet documenté sur chaque plateforme intégrée | O | Déclaration par intégration |
| AV-07 | Chiffres de latence des opérations courantes sous charge, avec conditions de test | R | Rapport de performance |
| AV-08 | Modèle de capacité et de montée en charge (requêtes par seconde, nombre de clés) | R | Guide de dimensionnement |
| AV-09 | Mises à niveau progressives sans interruption de service | R | Procédure de mise à niveau |
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| DS-01 | Modes de déploiement proposés : hébergé par l'éditeur, cloud du client, sur site, hybride | O | Guide de déploiement |
| DS-02 | Le client choisit la région ou le pays d'hébergement ; aucune relocalisation silencieuse | O | Clause contractuelle ; documentation |
| DS-03 | Juridiction de l'éditeur, société mère et sous-traitants ultérieurs communiqués | O | Déclaration écrite ; liste des sous-traitants |
| DS-04 | Déclaration sur l'exposition à une contrainte légale hors UE ou hors Suisse et sur la manière dont l'architecture la limite | R | Déclaration juridique et technique |
| DS-05 | Fonctionne sur des systèmes d'exploitation et environnements d'exécution pris en charge, hors fin de vie | O | Liste de prérequis |
| DS-06 | Exploitation en environnement isolé (air gap) ou à réseau restreint si nécessaire | R | Guide de déploiement |
| DS-07 | Parts de clé ou magasins de clés placés dans plusieurs juridictions sous contrôle du client | A | Architecture |
| DS-08 | Déploiement en conteneurs ou Kubernetes (par exemple OpenShift) | R | Guide de déploiement |
| DS-09 | Provisionnement automatisé du raccordement aux plateformes (par exemple enregistrement d'applications chez le fournisseur d'identité) | A | Démonstration |
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| VS-01 | Exploitation de l'éditeur certifiée ISO/IEC 27001 (périmètre indiqué) ; rapport SOC 2 disponible sous NDA | O | Certificat ; rapport |
| VS-02 | Support 24/7 avec délais de réponse contractuels pour les incidents critiques | O | Politique de support |
| VS-03 | Licence de preuve de concept gratuite ou payante, conditions précisées | O | Offre |
| VS-04 | Documentation produit publique couvrant installation, administration et intégrations | O | URL de la documentation |
| VS-05 | Processus de divulgation des vulnérabilités et délais de correctifs | O | Politique |
| VS-06 | Feuille de route produit partagée sous NDA avec engagements datés pour le post-quantique | R | Feuille de route |
| VS-07 | Références clients de votre secteur et de votre taille | R | Deux références |
| VS-08 | Services professionnels et formation | R | Offre |
| VS-09 | Séquestre ou dispositif de continuité si l'éditeur cesse son activité | R | Texte contractuel |
| VS-10 | Métrique de prix transparente (par clé, par opération, par intégration, forfait) avec exemple chiffré pour vos volumes | O | Grille tarifaire |
Notez chaque groupe de 0 à 5, multipliez par le poids et additionnez. Fixez les poids avant de lire une réponse. Tout critère Obligatoire non satisfait est éliminatoire, quel que soit le total.
Échelle de notation par exigence ou par groupe
| Note | Signification |
|---|---|
| 0 | Non proposé, ou aucune preuve |
| 1 | Feuille de route seulement, ou proposé avec de fortes limites |
| 2 | Partiellement satisfait ; contournement ou développement spécifique nécessaire |
| 3 | Satisfait, prouvé par la documentation |
| 4 | Satisfait, prouvé par la documentation et démontré en PoC |
| 5 | Dépasse l'exigence ; vérifié en PoC ou auprès d'un client référent |
Exemple de pondération (à adapter à votre profil de risque ; la somme doit faire 100)
| Groupe | Poids |
|---|---|
| 1. Cycle de vie des clés | 12 |
| 2. Garde et protection des clés | 18 |
| 3. Intégrations | 18 |
| 4. Cryptographie | 8 |
| 5. Contrôle d'accès et quorum | 10 |
| 6. Audit et supervision | 9 |
| 7. Disponibilité et reprise | 10 |
| 8. Déploiement et souveraineté | 8 |
| 9. Éditeur et support | 7 |
| Total | 100 |
Exemple chiffré (valeurs inventées, à titre d'illustration uniquement). Trois éditeurs génériques A, B et C, avec des notes de groupe sur 5.
| Groupe | Poids | A | B | C |
|---|---|---|---|---|
| 1. Cycle de vie des clés | 12 | 4 | 3 | 4 |
| 2. Garde et protection des clés | 18 | 5 | 3 | 4 |
| 3. Intégrations | 18 | 3 | 4 | 3 |
| 4. Cryptographie | 8 | 3 | 3 | 4 |
| 5. Contrôle d'accès et quorum | 10 | 4 | 3 | 4 |
| 6. Audit et supervision | 9 | 3 | 4 | 3 |
| 7. Disponibilité et reprise | 10 | 4 | 4 | 3 |
| 8. Déploiement et souveraineté | 8 | 4 | 3 | 5 |
| 9. Éditeur et support | 7 | 3 | 5 | 3 |
| Score pondéré (sur 500) | 376 | 351 | 364 | |
| Pourcentage | 75 % | 70 % | 73 % |
Calcul pour A : 12x4 + 18x5 + 18x3 + 8x3 + 10x4 + 9x3 + 10x4 + 8x4 + 7x3 = 48 + 90 + 54 + 24 + 40 + 27 + 40 + 32 + 21 = 376. Laissez votre tableur faire ce calcul avec SOMMEPROD des poids et des notes. Un résultat serré (ici, A et C à quelques points) est un signal pour prolonger le PoC ou réexaminer les critères Avancés, pas pour trancher sur le seul prix.
Intégrez-les à l'appel d'offres comme questions ouvertes ; elles font apparaître ce qu'une case à cocher ne montre pas.
Menez le PoC sur vos propres tenants et charges pendant deux à quatre semaines, avec des critères de réussite fixés d'avance. Chaque test est réussi ou échoué.
| ID | Test | Critère de réussite |
|---|---|---|
| PT-01 | Déployer dans l'environnement cible avec la seule documentation de l'éditeur | Service opérationnel dans le délai convenu, sans accès shell de l'éditeur |
| PT-02 | Raccorder deux intégrations prioritaires (par exemple Microsoft 365 DKE et une base de données ou AWS XKS) | Chiffrement et déchiffrement de bout en bout réussis |
| PT-03 | Créer des clés de chaque type et algorithme requis | Toutes créées ; la politique cryptographique refuse un algorithme non autorisé |
| PT-04 | Renouveler une clé manuellement puis par calendrier ; déchiffrer des données protégées avant la rotation | Les anciennes données se déchiffrent ; les nouvelles utilisent la nouvelle version ; sans réétiquetage (ou effort mesuré) |
| PT-05 | Déclencher une action sensible (suppression, export) en tant qu'administrateur seul | Bloquée jusqu'à approbation du quorum ; approbations journalisées |
| PT-06 | Désactiver en urgence une clé ou un utilisateur en cours d'usage | Déchiffrement refusé dans le délai convenu |
| PT-07 | Sauvegarder, détruire le service principal et restaurer | Reprise dans le RTO annoncé ; clés utilisables |
| PT-08 | Faire tomber un nœud (ou un site) sous charge | Aucune opération en échec au-delà du seuil convenu ; temps de bascule consigné |
| PT-09 | Exporter une clé exportable en format standard et l'importer ailleurs | Import réussi ; une clé non exportable ne peut pas être exportée |
| PT-10 | Transmettre les journaux à votre SIEM et tenter de modifier un enregistrement | Les événements arrivent ; la tentative d'altération est détectable |
| PT-11 | Mesurer latence et débit pour votre schéma d'appel | Respecte le budget de l'application en pic de charge |
| PT-12 | Vérifier la connexion des administrateurs avec votre fournisseur d'identité et le MFA | Appliqué à chaque administrateur |
| PT-13 | Appliquer une règle contextuelle ou par groupe et tester une requête hors politique | Refusée et journalisée |
Consignez l'effort autant que le résultat : heures passées, étapes manuelles, tickets de support ouverts.
Négociez-les avant la signature, quand vous avez encore du poids.
Objet : appel d'offres, système de gestion des clés de chiffrement (KMS). [Organisation] sélectionne une solution de gestion des clés pour centraliser le cycle de vie, la garde, le contrôle d'accès et l'audit des clés cryptographiques de [plateformes cloud, applications SaaS, bases de données et infrastructures]. La solution doit maintenir les clés sous le contrôle de [Organisation], prendre en charge la gestion externe des clés pour [Microsoft 365, AWS, Azure, Salesforce, Snowflake, Oracle, SQL Server], exposer des interfaces standard (KMIP et PKCS#11) et une API d'administration, et fournir une journalisation d'audit infalsifiable, une approbation par quorum des opérations sensibles, la haute disponibilité et une voie de sortie documentée. Les réponses traiteront les groupes d'exigences de l'Annexe A (cycle de vie des clés, garde et protection des clés, intégrations, cryptographie, contrôle d'accès et quorum, audit et supervision, disponibilité et reprise après sinistre, déploiement et souveraineté, éditeur et support) selon l'échelle de conformité et les preuves demandées. Les éditeurs présélectionnés participeront à une preuve de concept sur l'environnement de [Organisation]. Les offres sont évaluées selon le modèle pondéré de l'Annexe B. Remise des réponses le [date] ; questions à [contact] avant le [date].
Q : Que doit contenir un cahier des charges KMS ?
Un cahier des charges KMS doit contenir le périmètre, un inventaire des clés et plateformes, une liste d'exigences groupées par cycle de vie, garde, intégrations, cryptographie, contrôle d'accès, audit, disponibilité, déploiement et support éditeur, une grille de notation pondérée, un plan de preuve de concept et des clauses contractuelles et de sortie. Chaque exigence porte une priorité et la preuve que l'éditeur doit fournir.
Q : Comment rédiger des exigences KMS qui ne favorisent pas un éditeur ?
Rédigez des exigences sous forme de résultats testables, comme « la rotation conserve les anciennes versions pour le déchiffrement », et non des fonctionnalités de produit. Classez les éléments propres à une architecture, comme le calcul multipartite ou un HSM précis, en Avancé et notez-les en bonus. Fixez les pondérations avant de lire la moindre réponse.
Q : Quelle différence entre un appel d'offres KMS et un appel d'offres HSM ?
Un appel d'offres KMS couvre cycle de vie, politique, intégrations et audit entre les systèmes. Un appel d'offres HSM se concentre sur la frontière matérielle : certification, performance, format et protection contre l'intrusion. La plupart des projets ont besoin des deux ; un cahier des charges KMS doit demander quels backends matériels sont pris en charge et quel certificat chacun détient.
Q : Quelles intégrations KMS faut-il exiger ?
Exigez uniquement les plateformes que vous utiliserez dans les 12 prochains mois, avec un guide par plateforme et un client référent pour chacune. Les listes typiques comprennent Microsoft 365 DKE ou Customer Key, AWS XKS, la gestion externe des clés Azure, Salesforce, Snowflake, Oracle TDE, SQL Server EKM, VMware et les plateformes de secrets comme HashiCorp Vault ou OpenBao.
Q : Combien de temps doit durer un PoC de KMS ?
Deux à quatre semaines en général, assez pour tester le déploiement, deux intégrations, la rotation, l'approbation par quorum, la reprise et la bascule sur vos charges réelles. Définissez d'abord les critères de réussite et d'échec, et mesurez l'effort autant que le résultat.
Q : Le support post-quantique doit-il être obligatoire en 2026 ?
Pour la plupart des acheteurs, c'est Recommandé : demandez la prise en charge de ML-KEM (FIPS 203), ML-DSA (FIPS 204) et SLH-DSA (FIPS 205), ou une feuille de route datée, et classez les modes hybrides et l'agilité cryptographique pilotée par politique en Avancé. Si vos données doivent rester confidentielles de nombreuses années, relevez la priorité.
Q : Comment comparer un KMS fondé sur le MPC et un HSM dans un appel d'offres ?
Centrez l'exigence sur le résultat, par exemple « aucun administrateur, nœud ou équipement seul ne peut utiliser une clé complète » et « validation FIPS 140-3 là où elle est imposée », et laissez chaque architecture montrer comment elle y répond. Comparez la latence en PoC pour votre schéma d'appel. Voir MPC et HSM.
Q : Existe-t-il une version prête à l'emploi de cette checklist ?
Les tableaux de cette page sont conçus pour être copiés dans un tableur, avec les identifiants en première colonne. Pour voir comment des éditeurs précis répondent à ces critères, consultez notre guide de la meilleure solution KMS et les pages de comparaison.
É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.
