HSM cloud ou on-premise pour les clés critiques

Un HSM (Hardware Security Module) cloud retire la maintenance matérielle et la haute disponibilité du périmètre d’exploitation. En échange, la protection des clés critiques dépend de la disponibilité, de l’intégrité et du modèle d’accès réel du fournisseur cloud. Ce compromis ne se résout pas avec une slide sur la responsabilité partagée.

→ Lire l’explication complète de la marmotte

Le compromis HSM cloud contre HSM on-premise

Le HSM cloud convient aux clés utilisées par des applications déjà exécutées dans le cloud : chiffrement de données, signature de jetons, chiffrement de sauvegardes, clés de chiffrement de volume ou de base de données. Le gain est réel : le fournisseur remplace les cartes défaillantes, gère la redondance inter-zone, surveille le matériel et expose une interface de programmation applicative, ou API (Application Programming Interface), accessible aux charges de travail.

Le prix est moins confortable. L’organisation ne contrôle plus le châssis, le micrologiciel déployé, les procédures d’intervention matérielle ni l’hyperviseur qui entoure le service. Selon l’architecture du fournisseur, l’opérateur peut disposer de mécanismes techniques permettant une récupération, une restauration ou une administration exceptionnelle des clés. Une promesse contractuelle de non-accès n’est pas une propriété cryptographique.

Un HSM on-premise conserve ces responsabilités, avec les pannes, les mises à jour de micrologiciel et les cérémonies de sauvegarde qui vont avec. Il permet aussi de définir une frontière d’administration indépendante du fournisseur d’hébergement. Cette indépendance vaut cher lorsqu’une clé racine signe d’autres clés, lorsqu’un compromis permettrait d’usurper toute une identité numérique, ou lorsqu’une autorité de certification, ou AC (Authority Certificate), racine doit rester hors ligne.

La position à retenir est directe : utiliser un service cloud pour les clés de production dont le périmètre de confiance inclut déjà le fournisseur cloud. Conserver un HSM on-premise, idéalement hors ligne pour les racines de confiance, dès que le fournisseur ne doit pas pouvoir techniquement participer à la compromission de la clé. La souveraineté ne naît pas d’une région libellée « Europe » dans une console d’administration.

Un KMS (Key Management Service) matériel managé et un HSM cloud dédié ne sont pas interchangeables. Le premier expose généralement des primitives haut niveau, comme chiffrer, déchiffrer ou signer. Le second peut fournir des partitions dédiées et des interfaces comme PKCS#11 (Public-Key Cryptography Standards numéro 11). Le fonctionnement de PKCS#11 devient alors déterminant : une compatibilité d’interface ne garantit ni portabilité opérationnelle, ni mêmes mécanismes d’audit.

Pré requis de plateforme et frontière de confiance

Avant de créer une première clé, il faut disposer d’identités de charge de travail distinctes. Une application, un pipeline de déploiement et un administrateur humain ne doivent pas partager le même principal d’accès. Dans un fournisseur cloud, cette séparation repose souvent sur un IAM (Identity and Access Management), c’est-à-dire le système qui associe des identités à des autorisations. Une clé utilisable par un rôle applicatif et modifiable par ce même rôle est déjà un incident en attente de calendrier.

L’horloge des systèmes appelants doit être synchronisée, généralement par NTP (Network Time Protocol), car les journaux d’audit, les jetons d’identité temporaires et les mécanismes de signature dépendent du temps. Prévoir aussi une journalisation centralisée, immuable ou à rétention verrouillée, des alertes sur les échecs d’autorisation et une sortie réseau contrôlée vers les points d’accès du service. Un appel de chiffrement qui contourne le proxy attendu constitue un signal d’architecture, pas une curiosité réseau.

Les dépendances doivent être explicites : version 2 de l’interface en ligne de commande du fournisseur pour les automatisations, bibliothèque PKCS#11 homologuée par le fournisseur pour un HSM dédié, bibliothèques cryptographiques maintenues côté application et protocole TLS (Transport Layer Security) version 1.2 au minimum pour les appels réseau. Éviter les images de conteneurs qui embarquent un pilote PKCS#11 non mis à jour depuis l’époque où l’on faisait encore confiance aux certificats expirés parce que « ça passe en recette ».

Une hiérarchie de clés reste nécessaire. Une DEK (Data Encryption Key) chiffre les données, tandis qu’une KEK (Key Encryption Key) protège une DEK emballée, ou wrapped. Le KMS peut stocker la KEK et exécuter les opérations de déballage. Cette séparation limite l’exposition et rend la rotation praticable. La distinction entre KEK et DEK évite surtout de confondre une clé de service avec une clé de données.

Responsabilité partagée et accès effectif aux clés

Le client contrôle généralement les politiques d’autorisation, les identités appelantes, la désactivation d’une clé, ses alias, ses métadonnées et le choix des données à chiffrer. Il reste responsable des autorisations trop larges, des jetons temporaires volés, des sauvegardes chiffrées avec une clé détruite et des applications qui déchiffrent trop de données en mémoire.

Le fournisseur contrôle le matériel, les correctifs physiques, la disponibilité, l’isolation entre locataires et, selon le produit, la réplication des clés. Cette responsabilité couvre aussi les comptes opérateurs, les procédures de récupération et les mécanismes d’assistance. Une clé marquée « non exportable » ne signifie pas automatiquement qu’aucun mécanisme privilégié du fournisseur ne peut en produire une copie protégée ou exécuter une opération en son nom.

La question décisive est donc : qui peut déclencher une opération cryptographique, qui peut changer la politique qui l’autorise, et qui peut restaurer l’état nécessaire à cette opération ? Pour une clé gérée par un KMS, une réponse acceptable exige que le fournisseur ne puisse pas appeler l’API cliente sans passer par une identité et une politique auditées. Pour une clé contrôlée par le client dans un HSM dédié, il faut aussi vérifier qui possède les secrets d’administration de partition, les clés de sauvegarde et les droits de réinitialisation.

Les clés les plus critiques ne doivent jamais dépendre d’un seul plan de contrôle. Une autorité racine hors ligne nécessite un HSM on-premise isolé, des cérémonies à plusieurs détenteurs et une sauvegarde chiffrée conservée séparément. Un fournisseur cloud indisponible ne doit pas pouvoir empêcher la révocation, le renouvellement ou la signature de la chaîne de confiance. L’air gap, une séparation physique sans chemin réseau opérationnel, reste pénible à exploiter. C’est précisément son métier.

Vérifier l’isolation annoncée par le fournisseur

La certification d’un module selon FIPS (Federal Information Processing Standards) 140-2 ou 140-3 évalue une implémentation dans un périmètre donné. Elle ne prouve ni la configuration effective du tenant, ni l’absence d’accès opérateur, ni la qualité des politiques IAM. Une certification est une pièce de dossier, pas un sort de protection lancé sur la console.

Vérifier le modèle documentaire du service : clés mutualisées ou partitions dédiées, génération dans le service ou import possible, sauvegarde contrôlée par le client ou par le fournisseur, réplication automatique, procédures de destruction, régions de traitement et sous-traitants. Chercher explicitement les conditions de récupération exceptionnelle, d’assistance support et de réponse aux demandes légales. Les formulations vagues sont rarement des détails de style.

Tester ensuite les garanties exploitables :

refuser une opération de déchiffrement depuis une identité non attendue ;
vérifier qu’une modification de politique produit un journal horodaté et exporté ;
désactiver une clé de test et mesurer les dépendances applicatives réelles ;
supprimer une autorisation temporaire puis confirmer qu’aucune session persistante ne conserve l’accès ;
exiger une preuve d’effacement ou un mécanisme de destruction cryptographique lors de la fin de vie.

La haute disponibilité annoncée ne remplace pas un plan de continuité. Un service de clés indisponible bloque souvent le démarrage d’une application, le montage d’un volume ou le traitement d’un message. Prévoir des délais de cache de clés de données, des comportements de refus explicites et une procédure de bascule documentée. Mettre une clé maîtresse dans un service distant puis découvrir qu’une panne DNS bloque toute l’activité relève de la magie moderne, dans son versant le moins poétique.

Exemple d’appel à un KMS matériel managé

L’exemple suivant crée une clé symétrique dans AWS (Amazon Web Services) KMS, lui affecte un alias, puis chiffre un petit fichier. Il nécessite AWS CLI version 2, des identifiants ayant les droits kms:CreateKey, kms:CreateAlias et kms:Encrypt, ainsi qu’une région configurée.

# Créer une clé symétrique : la matière de clé ne sort pas via cette commande.
KEY_ID="$(aws kms create-key \
  --description "DEK de test protegee par KMS" \
  --query 'KeyMetadata.KeyId' \
  --output text)"

# Donner un nom stable à la clé pour éviter de disperser des identifiants opaques.
aws kms create-alias \
  --alias-name alias/tortuetech-demo \
  --target-key-id "$KEY_ID"

# Chiffrer un fichier local. Le contexte lie le résultat à un usage applicatif précis.
printf 'secret de demonstration\n' > secret.txt
aws kms encrypt \
  --key-id alias/tortuetech-demo \
  --plaintext fileb://secret.txt \
  --encryption-context service=paiement,environnement=test \
  --output text \
  --query CiphertextBlob > secret.b64

Le contexte de chiffrement doit être fourni identiquement au déchiffrement. Il n’est pas secret, mais il est authentifié : modifier service ou environnement fait échouer l’opération. Ne pas y placer de données personnelles ou de secret applicatif, car les journaux peuvent l’exposer.

Cet appel prouve uniquement que l’API fonctionne et que la politique autorise l’action. Il ne démontre pas l’isolation matérielle, la résilience régionale ou l’absence d’accès opérateur. Les tests qui prétendent certifier cela avec trois lignes de script méritent le même respect qu’un parachute validé par présentation PowerPoint.

Surface d’attaque, rotation et reprise

Le premier risque est le vol d’identité : une charge de travail compromise appelle légitimement l’API de déchiffrement. Un HSM ne détecte pas qu’un jeton IAM a été obtenu par un attaquant. Réduire les droits à une clé et à une opération, conditionner l’accès à l’identité de charge, au réseau et au contexte de chiffrement, puis alerter sur les volumes ou horaires anormaux.

Le second risque est administratif : une identité capable de modifier une politique de clé peut s’accorder le déchiffrement. Séparer l’administration des politiques, l’exploitation applicative et la lecture des journaux. Appliquer une approbation multiple pour la suppression, la désactivation et les changements de délégation. La rotation automatique ne corrige pas une politique qui autorise déjà le mauvais principal.

La rotation doit distinguer la rotation de la KEK de celle des DEK. Changer une KEK peut permettre de conserver les DEK existantes emballées sous une nouvelle version. Changer une DEK impose généralement de rechiffrer les données ou de maintenir plusieurs versions lisibles. La page sur la rotation des clés détaille cette dette de compatibilité, souvent oubliée jusqu’au premier incident.

Sauvegarder les métadonnées, politiques, identifiants de clés, journaux d’audit et procédures de restauration. Pour un HSM on-premise, sauvegarder aussi les objets de domaine et les clés de sauvegarde selon le mécanisme constructeur. Pour un KMS cloud, vérifier qu’une suppression programmée n’est pas annulable indéfiniment et qu’une région entière indisponible ne rend pas les données définitivement illisibles. Une sauvegarde sans la capacité de déchiffrement est une archive artistique.

🐝 Ce qui arrive si on s’en passe

Sans arbitrage explicite entre HSM cloud et HSM on-premise, les clés finissent créées au fil des besoins dans le plan de contrôle le plus accessible : une clé racine et une clé de chiffrement de sauvegarde partagent alors le même périmètre de confiance, sans inventaire distinguant ce qui peut dépendre d’un tiers de ce qui ne le peut pas. Il devient impossible de répondre, lors d’un audit ou d’un incident, à la question de savoir qui pouvait techniquement déclencher une signature. La matière de clé étant non exportable, aucune migration vers un autre module n’est possible : le changement de fournisseur impose un rechiffrement complet ou une réémission de la chaîne. Une demande légale adressée à l’opérateur, ou une simple fermeture de compte, s’applique alors indistinctement à l’ensemble des clés, y compris celles censées rester hors de sa portée.

🦫 Explication de la marmotte 🍫

Un module matériel de sécurité conserve des clés secrètes utilisées pour chiffrer des données ou signer des documents. Une application demande au service de faire une opération, mais elle ne reçoit normalement pas la clé secrète en clair. Dans le cloud, le fournisseur héberge ce matériel, le remplace en cas de panne et fait fonctionner plusieurs copies pour éviter une interruption. L’organisation crée des règles qui disent quelles applications et quelles personnes peuvent demander une opération.

Le résultat dépend donc de deux protections. La première est la protection physique et logicielle du matériel par le fournisseur. La seconde est la protection des comptes autorisés à demander le chiffrement ou le déchiffrement. Si un pirate vole le compte d’une application autorisée, le service peut accepter ses demandes même sans lui donner la clé. Si le service du fournisseur est indisponible, une application peut ne plus pouvoir lire ses données.

Avec un matériel installé dans les locaux de l’organisation, celle-ci garde davantage de contrôle sur les accès physiques, les sauvegardes et les règles d’administration. Elle doit aussi réparer les pannes, remplacer le matériel et préparer la reprise. Ce choix reste nécessaire pour une clé qui ne doit jamais dépendre techniquement d’un fournisseur externe, notamment la clé principale d’une autorité qui délivre des certificats.

Pages voisines

La citent

HSM cloud ou on-premise pour les clés critiques

Elle cite

HSM cloud ou on-premise pour les clés critiques

HSM cloud ou on-premise pour les clés critiques

Le compromis HSM cloud contre HSM on-premise

Pré requis de plateforme et frontière de confiance

Responsabilité partagée et accès effectif aux clés

Vérifier l’isolation annoncée par le fournisseur

Exemple d’appel à un KMS matériel managé

Surface d’attaque, rotation et reprise

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines