Protection des données classifiées dans les bases de données HSM

Solutions architecturales pour sécuriser les données sensibles en base

Les données sensibles comme les numéros de cartes de paiement (PAN) et les informations personnelles (PII) exigent une protection renforcée contre les fuites via les sauvegardes de bases de données et l'accès administrateur. Les principaux défis incluent le stockage de données chiffrées tout en permettant les recherches, la gestion sécurisée des clés, et la réduction des risques d'incident. L'analyse montre une distinction claire : PCI DSS pour les PAN et des réglementations comme la 152-FZ/RGPD pour les PII, en raison de leurs exigences différentes, telles que la suppression complète des données sur demande.

Un numéro de carte n'est pas un secret absolu : les 6-8 premiers chiffres correspondent au BIN de la banque, le dernier est un chèque de contrôle, ne laissant que 7-9 chiffres à forcer par brute force (10 à 1000 millions de combinaisons par BIN). Stocker des hachages PAN salés en base est vulnérable aux attaques GPU si le sel est exposé.

Chiffrement des données et options HSM

Un HSM (Hardware Security Module) est un appareil dédié au stockage sécurisé des clés et à l'exécution d'opérations cryptographiques. Les HSM matériels protègent physiquement les clés contre l'extraction ; les versions logicielles reposent sur des contrôles d'accès.

Les HSM logiciels utilisent le partage de secret de Shamir : la clé maître est divisée en N parts, dont K sur N sont nécessaires pour la reconstituer (K < N). Exemple : 5 parts, 3 pour activer. C'est un compromis — cela transfère le risque à votre organisation mais réduit les coûts.

Options pour rechercher des données chiffrées :

• TDE (Transparent Data Encryption) : Chiffre les fichiers sur disque, mais les données sont en clair en mémoire. Protège contre le vol de disques, pas contre les DBA.
• Hachage salé : Stocke le hachage du PAN + sel issu du HSM, indexé par hachage. Le sel reste hors de la base pour bloquer le brute-forcing.
• Chiffrement déterministe : Sans IV, le même texte clair donne toujours le même chiffré. Permet l'indexation mais risqué si les clés fuient.

Meilleure approche : la base contient le PAN chiffré, le crypto-hachage et l'ID de clé (pour rotation). Recherche par hachage ; les services ne voient que des hachages. PCI DSS limite les hachages dans l'environnement des données du porteur de carte — utilisez des jetons dans un stockage séparé.

Gestion des clés : Vault et ses limites

Des outils comme HashiCorp Vault, Azure Key Vault et AWS Secrets Manager gèrent bien les secrets mais peinent avec les clés cryptographiques. Ils protègent contre :

• Les secrets commités dans git.
• Les fuites de variables d'environnement.
• Les lectures non autorisées.

Ils ne protègent pas contre :

• Les admins Vault.
• Les admins serveurs (dumps mémoire).
• Les propriétaires de certificats mTLS.

Renforcez avec mTLS sur clés matérielles, limites de taux et audit. Vault n'est pas un HSM. Azure Key Vault Premium exploite les HSM des datacenters Microsoft avec clés non exportables et opérations API.

Secrets Kubernetes : risques de la conteneurisation

Les Secrets Kubernetes sont encodés en base64 dans etcd (non chiffrés). L'accès au serveur API expose tous les secrets. Les conteneurs sont vulnérables à :

• La lecture du FS conteneur par root hôte.
• nsenter dans les processus.
• Dumps mémoire.
• Sniffing du trafic réseau.

Inacceptable pour les services crypto. Des atténuations comme gVisor, Kata Containers ou Confidential Computing aident mais ajoutent de la complexité.

Solutions cloud et responsabilité partagée

Les clouds comme AWS et Azure sont certifiés PCI DSS pour l'infrastructure (datacenters, chiffrement disque), mais vous gérez les clés et accès. Le trafic cloud transite par des réseaux virtuels — les admins fournisseurs pourraient espionner. Recommandation : service crypto dédié avec isolation physique (câblage séparé) ; en cloud, HSM isolés.

Architecture consensuelle

• Service crypto dédié hors conteneurs, interfaces minimales.
• Clés non extractibles en HSM (matériel/logiciel/cloud).
• Schéma de Shamir sans HSM matériel.
• Crypto-hachage pour recherches, sel du HSM.
• Gestion séparée PAN/PII.
• Audit complet.
• Rotation des clés.

Points clés :

• Gardez sels/clés hors base — utilisez HSM.
• Recherchez via crypto-hachages ou jetons ; évitez le chiffrement déterministe.
• Compromis organisationnels (Shamir) pour économiser.
• Vault pour secrets, HSM pour clés.
• Séparez PCI DSS et PII par réglementations.

— Editorial Team