Cahier des charges chiffrement et appel d'offres chiffrement : exigences, grille de notation, questions fournisseurs, tests de POC et clauses de sortie.
Ce cahier des charges chiffrement est un modèle d'appel d'offres chiffrement, neutre vis-à-vis des éditeurs, pour protéger les données au repos dans le cloud, les applications SaaS et les bases de données avec des clés que vous contrôlez. Il couvre onze groupes d'exigences (périmètre, modèles de chiffrement, maîtrise des clés et souveraineté, intégrations, disponibilité, cryptographie, politiques d'accès, audit, conformité réglementaire, déploiement et réversibilité, fournisseur et support), une grille de notation pondérée, 20 questions aux fournisseurs, des signaux d'alerte, un plan de POC et des clauses contractuelles. Chaque tableau peut être copié dans un tableur.
Ce modèle s'adresse aux architectes sécurité, RSSI, délégués à la protection des données, acheteurs et responsables de plateformes cloud qui doivent acquérir, ou remettre en concurrence, une solution de chiffrement des données d'entreprise dans laquelle le client, et non le fournisseur cloud ou SaaS, maîtrise les clés. Il s'applique que l'on parle de BYOK, de HYOK, de gestion externe des clés (EKM), de double chiffrement (DKE), de chiffrement côté client, de tokenisation ou de chiffrement au niveau des champs.
Mode d'emploi :
Les priorités sont Obligatoire (éliminatoire si absent), Souhaitable (noté, un écart est acceptable avec un plan) et Avancé (capacités différenciantes que certains produits proposent, à ne pas rendre obligatoires sauf si votre analyse de risque l'exige).
Cette page est une aide à l'achat, pas un avis juridique. Faites valider les références réglementaires par votre service juridique.
La plupart des projets de chiffrement échouent avant l'appel d'offres, sur le périmètre. Réglez d'abord cinq points.
1. Inventoriez et classifiez les données. Listez les plateformes qui hébergent des données réglementées ou confidentielles : Microsoft 365 (Exchange, SharePoint, OneDrive, Teams), Salesforce, ServiceNow, stockage et bases AWS, Azure, SQL Server, Oracle, Snowflake, Databricks, et services d'IA comme OpenAI. Associez une classification à chacune et notez volumes et contraintes de résidence.
2. Choisissez la menace à couvrir.
| Menace ou objectif | Ce qu'il faut |
|---|---|
| Personnel du fournisseur cloud ou intrusion chez lui | Clés détenues par le client, inutilisables sans votre service de clés |
| Demande judiciaire étrangère adressée au fournisseur | Clés sous votre juridiction, fournisseur incapable de déchiffrer seul |
| Régulateur ou auditeur demandant qui peut déchiffrer | Piste d'audit de l'usage des clés que vous maîtrisez |
| Initié ou compte administrateur compromis dans votre tenant | Politiques d'usage des clés, séparation des tâches, validations à quorum |
| Perte ou vol de supports | Le chiffrement au repos standard suffit |
3. Décidez du modèle par charge de travail. Un seul modèle convient rarement à toutes les plateformes. Voir Hold Your Own Key (HYOK) et le BYOK expliqué.
4. Nommez les parties prenantes. Architecture sécurité, propriétaires de plateformes, propriétaires d'applications, DPO ou juridique, exploitation/SRE (ils feront tourner le service de clés), achats et audit interne.
5. Fixez critères et pondérations avant de lire la moindre réponse.
Chaque groupe est un tableau : ID, Exigence, Priorité, Preuve à demander. Les exigences sont rédigées de façon à ce qu'un produit sérieux de la catégorie puisse les satisfaire et les prouver.
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| SC-1 | La solution prend en charge les plateformes de l'annexe A (votre inventaire) et indique, par plateforme, le modèle de chiffrement utilisé | Obligatoire | Matrice de support avec liens vers la documentation |
| SC-2 | La protection peut être appliquée par classification (données réglementées sous une autre clé que les données internes) | Souhaitable | Démonstration de clés par classification |
| SC-3 | Les échanges entre la plateforme et le service de clés sont protégés par TLS 1.2 ou supérieur | Obligatoire | Schéma d'architecture, configuration TLS |
| SC-4 | Le fournisseur indique ce qui n'est pas couvert (métadonnées, index de recherche, journaux, sauvegardes, caches) | Obligatoire | Déclaration écrite par plateforme |
| SC-5 | Le traitement des données nouvelles et existantes est décrit, y compris le rechiffrement de l'historique | Souhaitable | Procédure de migration, débits mesurés chez un client de référence |
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| EM-1 | Chaque plateforme est rattachée à son modèle : clés gérées par le fournisseur, gérées par le client (BYOK), clé externe (HYOK/EKM) ou côté client | Obligatoire | Matrice des modèles par plateforme |
| EM-2 | Pour les clés externes, le fournisseur explique où se fait l'opération cryptographique (côté fournisseur avec une clé enveloppée, ou dans votre service de clés) | Obligatoire | Schéma de flux d'un chiffrement et d'un déchiffrement |
| EM-3 | Lorsque la plateforme propose le double chiffrement, les deux clés sont nécessaires au déchiffrement (par exemple DKE de Microsoft 365) | Souhaitable | Documentation et test montrant l'échec sans l'une des clés |
| EM-4 | Un chiffrement côté client ou applicatif (SDK ou proxy) existe pour les plateformes sans clé externe native | Souhaitable | Documentation SDK, langages pris en charge |
| EM-5 | Tokenisation ou chiffrement au niveau des champs pour les données structurées, avec options préservant le format si nécessaire | Souhaitable | Documentation, exemple de schéma |
| EM-6 | Intégration du chiffrement transparent des bases (TDE) avec un gestionnaire de clés externe pour les bases du périmètre | Obligatoire (si bases concernées) | Versions prises en charge, guide d'installation |
| EM-7 | Si une plateforme ne peut pas utiliser des clés détenues par le client, le fournisseur le dit explicitement plutôt que de vendre un modèle plus faible sous le même nom | Obligatoire | Liste écrite des limites |
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| KC-1 | Les clés sont générées et stockées dans un gestionnaire sous le contrôle du client (datacenter propre, tenant dédié ou juridiction nommée) | Obligatoire | Options de déploiement, lieux d'hébergement |
| KC-2 | Le fournisseur liste qui (personnel, hébergeur, fournisseur cloud) peut accéder au matériel de clé ou déclencher des opérations, et à quelles conditions | Obligatoire | Déclaration écrite, description des contrôles d'accès |
| KC-3 | Le client peut révoquer unilatéralement l'accès de la plateforme, et l'effet sur les données est documenté (clés en cache comprises) | Obligatoire | Test de révocation, durées de cache |
| KC-4 | Le matériel de clé ne quitte jamais le gestionnaire en clair | Obligatoire | Description d'architecture, certification HSM ou équivalent |
| KC-5 | La juridiction du fournisseur et de l'entité qui héberge les clés est indiquée, avec son exposition aux demandes légales étrangères | Obligatoire | Organigramme juridique, extrait du contrat d'hébergement |
| KC-6 | Les clés racines peuvent reposer sur un HSM certifié FIPS 140-3 (ou FIPS 140-2 tant que valide) ou niveau d'assurance équivalent | Souhaitable | Numéros de certificat |
| KC-7 | Génération, rotation, désactivation, destruction et import de clés avec états de cycle de vie documentés | Obligatoire | Documentation du cycle de vie |
| KC-8 | Fractionnement des clés ou contrôle multipartite, de sorte qu'aucun administrateur ni machine ne détienne une clé complète | Avancé | Note d'architecture, démonstration de quorum |
Ne gardez que les lignes utiles. « Pris en charge » signifie documenté, testé sur les versions actuelles et supporté par l'éditeur, pas « faisable avec du développement spécifique ».
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| PI-1 | Microsoft 365 : double chiffrement (DKE) pour les contenus étiquetés et/ou Customer Key pour le chiffrement de service | Souhaitable | Guide de mise en œuvre, charges prises en charge, limites connues |
| PI-2 | Salesforce : Shield Platform Encryption avec un service de clés externe | Souhaitable | Modes d'usage des clés, guide |
| PI-3 | ServiceNow : intégration de clés contrôlées par le client | Souhaitable | Éditions prises en charge, guide |
| PI-4 | AWS : external key store (XKS) ou gestion de clés intégrée à KMS pour S3, EBS, RDS et services similaires | Souhaitable | Compatibilité du proxy XKS, liste des services testés |
| PI-5 | Azure : intégration Key Vault ou HSM managé, ou clé externe pour stockage et bases | Souhaitable | Document d'intégration |
| PI-6 | TDE SQL Server et Oracle via un gestionnaire de clés externe (EKM / PKCS#11) | Souhaitable | Versions, mesures de performance |
| PI-7 | Snowflake : clé détenue par le client dans Tri-Secret Secure | Souhaitable | Guide de mise en œuvre |
| PI-8 | Databricks et autres plateformes de données : clés gérées par le client pour stockage et espaces de travail | Souhaitable | Guide |
| PI-9 | Services d'IA (par exemple la gestion de clés d'entreprise d'OpenAI) : enregistrement d'une clé détenue par le client | Souhaitable | Documentation, place du service de clés dans le chemin des données |
| PI-10 | Interfaces standard pour les besoins spécifiques : KMIP, PKCS#11, API REST | Souhaitable | Documentation d'interface |
| PI-11 | Une intégration n'exige pas que le fournisseur reçoive des données métier en clair, sauf mention explicite | Obligatoire | Schéma de flux |
Un service de clés externe place votre gestionnaire de clés sur le chemin critique de vos données cloud. C'est le groupe le plus souvent sous-spécifié.
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| PA-1 | Le fournisseur documente, par plateforme, le comportement si le service de clés est injoignable : fail-closed (données inaccessibles) ou fail-open/cache | Obligatoire | Tableau des comportements, résultats de tests de panne |
| PA-2 | La latence ajoutée par opération de clé est indiquée par plateforme, avec les délais d'expiration propres à la plateforme | Obligatoire | Benchmark, référence de la documentation de la plateforme |
| PA-3 | Un déploiement haute disponibilité (actif-actif ou actif-passif sur nœuds ou zones indépendants) est pris en charge et documenté | Obligatoire | Architecture HA, test de bascule |
| PA-4 | Objectif de disponibilité (SLA) du service managé, ou recommandations de dimensionnement en auto-hébergement | Obligatoire | SLA, runbook |
| PA-5 | Capacité : opérations par seconde soutenues testées à votre pic prévu, avec marge | Souhaitable | Rapport de test de charge |
| PA-6 | Reprise après sinistre du service de clés lui-même (sauvegarde, restauration, reprise régionale) avec RPO et RTO | Obligatoire | Plan de reprise, date du dernier test |
| PA-7 | Maintenance et mises à jour sans interruption des opérations de clés | Souhaitable | Procédure de mise à jour |
| PA-8 | Procédure d'urgence (break-glass) documentée, avec sa propre piste d'audit et validation | Souhaitable | Procédure |
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| CR-1 | AES-256 pour les clés de chiffrement des données ; RSA (3072 bits ou plus) ou courbes elliptiques pour l'enveloppement des clés selon la plateforme | Obligatoire | Liste des algorithmes |
| CR-2 | Algorithmes et paramètres conformes aux recommandations nationales en vigueur (NIST SP 800-57 et équivalents, recommandations ANSSI) | Souhaitable | Déclaration de conformité |
| CR-3 | Rotation des clés sans interruption, en mode automatique et à la demande | Obligatoire | Démonstration |
| CR-4 | Feuille de route post-quantique : ML-KEM (FIPS 203), ML-DSA (FIPS 204) et SLH-DSA (FIPS 205), avec dates | Souhaitable | Feuille de route, état par algorithme |
| CR-5 | Agilité cryptographique : changement d'algorithme par configuration, sans refonte | Souhaitable | Description de conception |
| CR-6 | Génération d'aléa depuis une source validée | Obligatoire | Documentation, certificat |
| CR-7 | Option d'établissement de clé hybride (classique et post-quantique) lorsque la plateforme le permet | Avancé | Documentation produit |
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| AP-1 | Contrôle d'accès par rôle pour l'administration des clés, séparé de l'usage des clés | Obligatoire | Modèle de rôles |
| AP-2 | Politiques par clé définissant quelle application, identité, tenant ou service peut l'utiliser | Obligatoire | Exemples de politiques |
| AP-3 | Authentification forte des administrateurs (MFA, SSO avec votre fournisseur d'identité) | Obligatoire | Options d'authentification |
| AP-4 | Politiques conditionnelles d'usage (heure, réseau, attributs d'identité, débit) | Souhaitable | Référence du langage de politiques |
| AP-5 | Séparation des tâches : qui crée une clé ne peut pas seul en autoriser la destruction | Souhaitable | Démonstration du workflow |
| AP-6 | Quorum d'approbation (M sur N) pour les actions d'administration sensibles | Avancé | Configuration du quorum |
| AP-7 | Les changements de politique sont versionnés et consultables | Souhaitable | Historique d'exemple |
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| AU-1 | Toute opération de clé (usage, administration, changement de politique, tentative refusée) est journalisée avec identité, heure, clé et résultat | Obligatoire | Schéma de journal et exemple |
| AU-2 | Journaux exportables vers votre SIEM via formats ou API standard, quasi en temps réel | Obligatoire | Documentation d'intégration |
| AU-3 | Journaux protégés contre la modification ; durée de conservation configurable | Obligatoire | Description de la protection |
| AU-4 | Alertes sur usage anormal (pics, source inhabituelle, refus répétés) | Souhaitable | Règles d'alerte |
| AU-5 | Comportement défini si l'enregistrement d'audit ne peut pas être écrit (refuser l'opération ou continuer), configurable par le client | Souhaitable | Documentation du mode de défaillance de l'audit |
| AU-6 | Audit à preuve d'altération (chaînage de hachages ou enregistrements signés) vérifiable indépendamment par un auditeur | Avancé | Procédure de vérification |
| AU-7 | Rapports pour auditeurs reliant les contrôles de clés à vos référentiels | Souhaitable | Rapport d'exemple |
Demandez au fournisseur de relier ses capacités aux textes qui vous concernent, avec ses propres mots. Refusez une simple liste de logos. Les références ci-dessous sont des repères génériques, pas une affirmation de conformité.
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| RG-1 | RGPD : appui aux mesures techniques de l'article 32 (chiffrement, résilience) et aux responsabilités responsable de traitement/sous-traitant de l'article 28 ; traitement documenté des transferts hors UE | Obligatoire (données UE/EEE) | Accord de traitement des données, analyse des transferts |
| RG-2 | LPD suisse (nLPD) : appui aux obligations de sécurité des données et aux règles de communication à l'étranger | Obligatoire (données suisses) | Document de correspondance |
| RG-3 | DORA : appui à la gestion du risque TIC, y compris contrôles cryptographiques et gestion des clés (article 9), et aux exigences sur les prestataires TIC tiers | Obligatoire (entités financières UE) | Document de correspondance, dispositions contractuelles |
| RG-4 | NIS2 : appui aux politiques de cryptographie et de chiffrement exigées comme mesure de gestion des risques (article 21) | Obligatoire (entités concernées) | Document de correspondance |
| RG-5 | FINMA : appui aux attentes d'externalisation, de résilience opérationnelle et de protection des données des établissements supervisés (circulaire 2023/1) | Obligatoire (entités suisses supervisées) | Document de correspondance |
| RG-6 | HIPAA : appui aux garanties techniques de la Security Rule, dont le chiffrement des ePHI, et accord de signer un business associate agreement le cas échéant | Obligatoire (santé US) | Modèle de BAA, correspondance |
| RG-7 | Assurance indépendante du fournisseur (certificat ISO/IEC 27001, rapport SOC 2 ou équivalent) dont le périmètre couvre le service de clés | Obligatoire | Certificat et périmètre |
| RG-8 | Le fournisseur accepte les droits d'audit et d'inspection du régulateur et du client | Souhaitable | Clause contractuelle |
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| DX-1 | Options de déploiement : SaaS, tenant dédié, auto-hébergé/sur site ou hybride, avec les responsabilités de chacun | Obligatoire | Guide de déploiement |
| DX-2 | Délai de mise en œuvre d'une première plateforme, avec un plan réaliste | Souhaitable | Plan de projet d'un client de référence |
| DX-3 | Infrastructure as code ou automatisation par API pour clés et politiques | Souhaitable | Documentation API/Terraform |
| DX-4 | Sortie : les clés peuvent être exportées ou réenveloppées vers un autre gestionnaire selon une procédure documentée, ou les données rechiffrées sous de nouvelles clés | Obligatoire | Procédure de sortie |
| DX-5 | La sortie ne rend pas les données illisibles : le fournisseur décrit étapes et durée par plateforme | Obligatoire | Plan de sortie |
| DX-6 | Interfaces ouvertes (KMIP, PKCS#11, API REST documentée) pour limiter le verrouillage | Souhaitable | Liste des interfaces |
| DX-7 | Clés et politiques exportables dans un format documenté | Souhaitable | Exemple d'export |
| ID | Exigence | Priorité | Preuve à demander |
|---|---|---|---|
| VS-1 | Horaires et délais de support par gravité, dans vos fuseaux et langues | Obligatoire | Politique de support |
| VS-2 | Interlocuteur technique nommé ou customer success pour le projet | Souhaitable | Contrat |
| VS-3 | Politique de divulgation des vulnérabilités et de correctifs, avec délais | Obligatoire | Politique |
| VS-4 | Feuille de route produit pour vos plateformes, partagée sous NDA si nécessaire | Souhaitable | Feuille de route |
| VS-5 | Clients de référence de votre secteur et de votre taille, joignables | Souhaitable | Liste de références |
| VS-6 | Stabilité financière et opérationnelle, liste des sous-traitants et notification des changements | Souhaitable | Informations sur la société |
| VS-7 | Formation et documentation pour les administrateurs | Souhaitable | Documentation |
Les poids doivent refléter votre analyse de risque. Le tableau est un exemple avec des chiffres génériques inventés.
| Catégorie | Poids d'exemple |
|---|---|
| Maîtrise des clés et souveraineté (groupe 3) | 20 % |
| Modèles de chiffrement et intégrations (groupes 2 et 4) | 20 % |
| Performance et disponibilité (groupe 5) | 15 % |
| Audit et politiques d'accès (groupes 7 et 8) | 10 % |
| Cryptographie et préparation PQC (groupe 6) | 5 % |
| Correspondance réglementaire (groupe 9) | 10 % |
| Déploiement et réversibilité (groupe 10) | 10 % |
| Fournisseur, support et prix (groupe 11) | 10 % |
| Total | 100 % |
Échelle de 0 à 5 pour chaque exigence :
| Note | Signification |
|---|---|
| 0 | Non proposé ou pas de réponse |
| 1 | Prévu mais indisponible |
| 2 | Disponible avec développements spécifiques importants ou lacunes |
| 3 | Disponible et documenté, couverture partielle |
| 4 | Disponible, documenté, prouvé en démonstration ou POC |
| 5 | Satisfait pleinement et au-delà, prouvé par un client de référence |
Appliquez d'abord un filtre éliminatoire : toute exigence Obligatoire notée 0 ou 1 disqualifie, ou impose une remédiation écrite avant présélection.
Exemple chiffré (chiffres purement illustratifs). Le fournisseur A obtient en moyenne 4,0 sur la maîtrise des clés, 3,5 sur les intégrations, 3,0 sur la disponibilité, 4,0 sur l'audit, 3,0 sur la cryptographie, 4,0 sur la réglementation, 3,0 sur le déploiement et la sortie, 3,5 sur le fournisseur. Score pondéré : 0,20 x 4,0 + 0,20 x 3,5 + 0,15 x 3,0 + 0,10 x 4,0 + 0,05 x 3,0 + 0,10 x 4,0 + 0,10 x 3,0 + 0,10 x 3,5 = 0,80 + 0,70 + 0,45 + 0,40 + 0,15 + 0,40 + 0,30 + 0,35 = 3,55 sur 5. Comparez-le aux autres fournisseurs notés de la même façon, et au coût sur cinq ans.
Menez le POC sur les deux ou trois plateformes les plus risquées. Définissez les critères de réussite avant de commencer.
| Test | Critère de réussite |
|---|---|
| Déployer le service de clés et connecter la plateforme 1 | Chiffrement et déchiffrement réussis dans le délai convenu ; étapes reproductibles par votre équipe |
| Connecter la plateforme 2 (par exemple une base avec TDE) | Idem, avec surcoût de performance mesuré sous votre seuil |
| Révoquer l'accès | Données inaccessibles dans le délai documenté ; le rétablissement de l'accès les restaure |
| Panne du service de clés | Comportement conforme au fail-closed ou au cache documenté ; reprise sans rechiffrement manuel |
| Bascule | Défaillance planifiée d'un nœud sans opérations en échec au-delà du seuil annoncé |
| Rotation des clés | Rotation terminée sans interruption de service |
| Politique d'accès | Une identité et une application non autorisées sont refusées et journalisées |
| Audit | Les opérations apparaissent dans votre SIEM dans le délai convenu ; un enregistrement altéré est détecté (si la preuve d'altération est exigée) |
| Charge | Débit de pointe soutenu avec la latence convenue et sans erreur |
| Sortie | Données rechiffrées ou réenveloppées sous un autre gestionnaire de clés pendant le POC, sans perte |
[Société] lance un appel d'offres pour une solution de chiffrement des données d'entreprise protégeant les données au repos dans [liste des plateformes : par exemple Microsoft 365, Salesforce, ServiceNow, AWS, Azure, SQL Server, Oracle, Snowflake, Databricks et services d'IA] au moyen de clés cryptographiques maîtrisées par [Société]. La solution doit permettre à [Société] de déterminer qui peut utiliser et révoquer les clés, de documenter le comportement de chaque plateforme lorsque le service de clés est indisponible, de fournir des preuves d'audit adaptées à [réglementations applicables : RGPD, nLPD, DORA, NIS2, FINMA, HIPAA] et d'offrir un chemin de sortie documenté. Les répondants complèteront les tableaux d'exigences de l'annexe B, indiqueront leurs hypothèses pour chaque plateforme et fourniront une preuve pour chaque exigence obligatoire. Ils seront évalués selon le modèle pondéré de l'annexe C ; les fournisseurs présélectionnés participeront à une preuve de concept avec critères de réussite.
Il doit contenir le périmètre et la classification, les modèles de chiffrement par plateforme, la maîtrise des clés et la juridiction, les intégrations, le comportement en cas de panne, la cryptographie, les politiques d'accès, l'audit, la correspondance réglementaire, le déploiement et la sortie, ainsi que le support. Ajoutez une grille de notation et un POC. La checklist ci-dessus fournit tout cela sous forme de tableaux copiables.
Avec le BYOK, vous générez ou importez une clé que le fournisseur détient ensuite et utilise. Avec le HYOK ou la gestion externe des clés, la clé reste dans votre gestionnaire et le fournisseur l'appelle à chaque opération. Exigez que l'éditeur indique le modèle réellement appliqué par plateforme, et lisez le BYOK expliqué.
Pour des données réglementées, le fail-closed est généralement souhaitable : si le service de clés est injoignable ou refuse, les données restent inaccessibles. En contrepartie, votre service de clés devient une infrastructure critique. Demandez haute disponibilité, tests de panne et comportement de cache documenté par plateforme, et tranchez fail-closed ou fail-open par charge de travail.
Pas pour toutes les charges. Le double chiffrement, comme le DKE de Microsoft 365, vise un petit périmètre de contenus très sensibles, car certaines fonctions comme la recherche côté serveur sont limitées sur le contenu protégé. Utilisez la gestion externe des clés pour le parc général et le double chiffrement ou le chiffrement côté client pour les données les plus critiques. Voir le guide de mise en œuvre du DKE.
Comparez-les sur les mêmes exigences : qui peut accéder aux clés, certifications, disponibilité, performance, audit et sortie. N'excluez pas une catégorie par principe, sauf si votre réglementation l'impose. Le cahier des charges KMS détaille les produits de gestion de clés.
Traitez-le comme une exigence de feuille de route et d'agilité cryptographique : quels algorithmes des FIPS 203, 204 et 205 sont pris en charge, quand, et comment change-t-on d'algorithme. Voir le modèle d'appel d'offres post-quantique.
Cela dépend de votre analyse de risque, des données et de votre régulateur. Ce qui compte est de savoir qui peut accéder aux clés et sous quel système juridique. Demandez la juridiction du fournisseur et de l'entité d'hébergement, et lisez souveraineté des données et clés de chiffrement.
Un bon appel d'offres chiffrement teste la maîtrise, pas les fonctionnalités. Demandez qui détient les clés à l'exécution, ce qui se passe quand le service de clés tombe, comment vous révoquez, comment vous le prouvez à un auditeur et comment vous partez. Notez tous les fournisseurs avec les mêmes poids et validez en POC. DuoKey propose une gestion de clés contrôlées par le client sur les plateformes citées ; vous pouvez le comparer aux autres via les pages Thales, Fortanix et Entrust. Retenez DuoKey, comme tout autre fournisseur, sur la seule force des preuves.
É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.
