Chiffrement des données
confiées à un éditeur tiers

1. Précision préalable, car l’argument circule encore : le niveau de certification ne distingue plus les deux offres. Les HSM mutualisés d’AWS KMS sont désormais validés FIPS 140-3 Security Level 3^[1], au même niveau que les boîtiers CloudHSM^[2]. Ce qui distingue réellement les offres, c’est la réponse à une question : qui détient le matériau de clé, et qui peut couper l’accès ? Avec KMS standard, le matériau vit dans des HSM multi-locataires opérés par AWS — protégé logiquement, mais hors de notre périmètre physique. Avec le Custom Key Store adossé à CloudHSM, le matériau est généré et stocké, non extractible, dans un cluster mono-locataire déployé dans notre compte et notre VPC — selon les termes mêmes d’AWS, un cluster « que vous possédez et gérez »^[3] — tout en conservant l’API KMS standard, donc la compatibilité avec les applications et les services managés. C’est cette combinaison — interface managée, racine de confiance dédiée — qui fonde l’architecture proposée.

2. Quel que soit l’emplacement de la clé maître, la mécanique est identique^[4]. La clé maître (KMS key) ne sort jamais du HSM et ne chiffre jamais les données métier : elle ne chiffre que des clés. L’appel GenerateDataKey^[5] produit une clé de données (AES-256) restituée simultanément sous deux formes : en clair (Plaintext), utilisée immédiatement pour chiffrer localement puis effacée de la mémoire ; et chiffrée par la clé maître (CiphertextBlob), conservée accolée aux données. La distinction de vocabulaire évite toute confusion en comité :

3. À la lecture, l’application renvoie le blob à kms:Decrypt. Propriété structurante : le blob est auto-descriptif — il embarque les métadonnées identifiant la clé maître qui l’a scellé, si bien que KMS route automatiquement l’opération vers la bonne clé sans que l’appelant la désigne^[6]. Après contrôle des droits, le HSM déchiffre le blob, la clé de données redescend, le déchiffrement des données s’exécute localement. Deux conséquences décisives pour notre cas : KMS — et donc ni AWS KMS ni notre compte de gestion des clés — ne voit jamais les données métier de l’éditeur ; il ne manipule que les clés de données et leurs enveloppes ; et révoquer l’accès à la seule clé maître interdit instantanément tout nouveau déchiffrement des blobs — donc de tout le patrimoine chiffré, où qu’il soit stocké.

4. Le cluster CloudHSM (au minimum deux HSM actifs dans deux zones de disponibilité, exigence d’AWS pour créer des clés^[7]) et le Custom Key Store sont déployés dans notre compte AWS, en eu-west-x, région où l’éditeur opère. La justification est une contrainte technique dure : si un appel applicatif peut viser l’endpoint KMS d’une autre région, les services AWS régionaux utilisés par l’éditeur — S3 SSE-KMS, Glue, Redshift — exigent une clé située dans leur région d’exécution ; les plateformes intégrées consommant KMS dans ce périmètre, notamment la plateforme analytique tierce dont l’usage a été indiqué a posteriori par l’éditeur, doivent être qualifiées dans cette même région. Et il n’existe pas de contournement par clé multi-région : les clés multi-région ne sont pas supportées en custom key store^[8]. Le positionnement régional du boîtier est donc la seule option compatible avec l’intégration native KMS. À noter pour la conformité : le matériau résidera physiquement en région intra-UE — point à faire valider au regard des politiques internes de localisation des secrets.

5. L’éditeur accède aux clés du périmètre via un rôle IAM dédié créé dans son compte, autorisé selon le mécanisme inter-comptes à double détente^[9] : la key policy de chaque clé concernée autorise l’ARN de ce rôle précis, et la policy IAM du rôle cible les ARN des clés concernées. Choix de doctrine assumé : l’identifiant cible proposé est l’alias ARN complet pour tout consommateur de clé configuré côté éditeur — application, service AWS managé, plateforme éditeur ou solution tierce intégrée — dès lors qu’il le supporte comme référence stable et durable. Ce choix répond à la contrainte exprimée par l’éditeur, qui indique ne pas supporter le changement d’ARN de clé après configuration. Le canal applicatif direct utilise donc exclusivement l’alias ARN complètement qualifié (arn:aws:kms:eu-west-x:<nous>:alias/donneur-data), jamais le nom d’alias nu^[10]. Ce choix ne résout pas magiquement la contrainte de l’éditeur : il la place sous preuve de POC. Le POC doit vérifier si le composant réévalue l’alias ARN après repointage, le résout en key ARN figé, permet une reconfiguration ultérieure, ou impose une migration, une recréation de ressource ou une recopie native des données. Les cas S3 SSE-KMS inter-comptes^[11], grants KMS des services AWS intégrés^[12][13] et plateforme analytique tierce^[17] sont donc des points de preuve prioritaires, non des hypothèses déjà acquises. Lorsqu’un composant impose ou persiste un key ARN non modifiable, l’intégration n’est retenue que si cette procédure de migration, recréation ou recopie native est validée par POC ; à défaut, l’exception doit être formellement acceptée et documentée. Les permissions runtime se limitent au chiffrement et au déchiffrement courant : GenerateDataKey, Encrypt, Decrypt, DescribeKey. CreateGrant est réservé aux canaux qui en ont besoin, sous condition kms:GrantIsForAWSResource: true ; ReEncrypt* relève uniquement du rôle de rotation/compromission. Les conditions sont différenciées par canal^[14] : EncryptionContext sur le canal applicatif direct ; kms:ViaService, kms:CallerAccount et principaux documentés pour les composants intégrés. Le cloisonnement se fait au niveau des KMS keys — une KMS key et un alias dédiés par service, plateforme ou canal majeur lorsque révocation, audit, rotation ou responsabilité diffèrent — et non au niveau des data keys, qui restent éphémères par objet, lot ou fenêtre de cache contrôlée. Cette séparation rend viable le choix de l’alias par défaut : une rotation, une révocation ou une exception sur un consommateur ne doit pas affecter inutilement les autres.

6. La rotation automatique du matériau n’est pas disponible pour les clés d’un custom key store^[15]. La procédure retenue est la rotation manuelle documentée par AWS^[16] : création d’une nouvelle clé (v2) dans le même key store, puis UpdateAlias — opération atomique — pour repointer l’alias. La transparence de cette rotation dépend du consommateur. Sur le canal applicatif direct, elle est totale en écriture : l’alias ARN est résolu à chaque appel, tout nouveau GenerateDataKey produit des enveloppes scellées par v2 sans qu’aucune configuration de l’éditeur ne change. Pour tout consommateur configuré côté éditeur — service AWS managé, plateforme éditeur ou solution tierce intégrée^[17] —, la rotation ne peut être considérée comme maîtrisée qu’après POC dédié. Ce POC doit établir si l’alias ARN est réévalué après repointage, si le key ARN est modifiable après configuration, ou si une procédure de migration, de recréation ou de recopie native permet de basculer vers v2. Branche explicite à acter : si le POC sur la plateforme analytique tierce ou S3 échoue sur la réévaluation de l’alias et sur la modification du key ARN, la rotation par alias n’est pas disponible pour ce périmètre ; le plan B devient alors migration, recréation, recopie native validée par POC, ou exception de gouvernance formellement acceptée. En l’absence de POC concluant, aucun engagement ne doit être pris sur la fréquence de rotation ; l’usage d’un key ARN figé doit être traité comme une dépendance durable à une génération de clé.

7. En lecture, la continuité repose sur le caractère auto-descriptif du blob (§2) : un blob scellé par v1 route vers v1, indépendamment de l’alias. Trois conséquences de gouvernance à acter : (1) v1 reste active tant qu’un blob applicatif ou une dépendance de consommateur v1 existe — la désactiver ou la supprimer rendrait l’historique illisible ; (2) il n’y a aucun re-chiffrement automatique — les enveloppes applicatives ou dépendances de consommateurs v1 restent jusqu’à re-chiffrement explicite par canal : kms:ReEncrypt sur les blobs applicatifs, ou mécanisme natif du service, de la plateforme ou de la solution intégrée ; le runbook de compromission précise les deux chemins ; (3) les droits Decrypt de l’éditeur doivent couvrir explicitement les ARN des générations successives — une policy conditionnée au seul alias perdrait l’accès à v1 au moment du repointage.

8. Garanties. Le matériau de clé est généré par KMS et stocké, non extractible, dans notre cluster dédié mono-locataire ; il y est détenu par l’utilisateur cryptographique kmsuser, que KMS pilote^[18] : nous ne manipulons jamais les bits du matériau, mais nous contrôlons le contenant — cluster, HSM, sauvegardes, connectivité — et la révocation opérationnelle. Celle-ci a trois étages : retrait du rôle des key policies concernées, désactivation de la ou des clés concernées, ou déconnexion du key store, qui coupe physiquement KMS du cluster — l’éditeur conserve alors ses cartons, il ne peut plus les ouvrir. La révocation coupe tout nouveau déchiffrement ; les données déjà déchiffrées et les clés de données encore en cache relèvent des TTL, purges mémoire et contrôles applicatifs imposés contractuellement (cf. n° 9). Chaque opération inter-comptes est journalisée dans CloudTrail^[19], avec rôle appelant, horodatage et contexte, dans notre compte comme dans le sien.

9. Risques assumés et supervision. Le kill switch est aussi notre risque opérationnel : key store déconnecté ou cluster indisponible = tous les Decrypt de l’éditeur échouent^[20] — d’où l’exigence des deux HSM multi-AZ^[21] et un socle de supervision à constituer dès la mise en service : état de connexion (ConnectionState) du key store, HSM actifs et sauvegardes du cluster, alertes CloudTrail sur DisableKey, DisconnectCustomKeyStore, ScheduleKeyDeletion, PutKeyPolicy et CreateGrant, test périodique de restauration, procédure break-glass à deux personnes. Côté performance, les clés d’un même key store partagent un quota non ajustable de 1 800 opérations/s, le throttling étant imputé au compte appelant ; AWS recommande le cache de clés de données (Encryption SDK)^[22] — autorisé sur arbitrage performance/confinement uniquement : le cache élargit le rayon d’impact d’une fuite de clé (cf. annexe B, S1), donc TTL, volume maximal et nombre maximal d’objets par data key sont documentés et imposés contractuellement, la règle par défaut restant « une data key par objet » pour les données les plus sensibles.

10. Coûts. Le cluster minimal (2 HSM facturés à l’heure^[23]) représente un ordre de grandeur de 2 100 à 2 900 $/mois selon le type de HSM, plus le tarif standard KMS. Ce surcout n’achète pas « plus de chiffrement » — la cryptographie est identique — mais la propriété du contenant, la révocabilité unilatérale et l’opposabilité de l’audit. C’est une prime d’assurance de gouvernance, à arbitrer en regard du risque traité.

12. Chaque ligne fixe, pour un consommateur de clé donné, l’identifiant cible, les permissions KMS à accorder aux rôles/principaux autorisés, les conditions de key policy applicables, le comportement de rotation attendu et la branche de repli en cas de key ARN figé. Cette matrice — et non une policy générique — doit servir de référence d’implémentation, de revue sécurité et de cadrage des POC.

13. Principe directeur : l’architecture sépare trois objets de valeur très inégale — les données, leurs clés de données, et la clé maître. Identifier ce qui est réellement compromis détermine l’action, et l’erreur classique consiste à re-chiffrer les enveloppes quand c’est le contenu qui a fui. Le matériau de la clé maître étant non extractible du HSM, sa « compromission » ne peut être qu’une compromission d’usage (identifiants, rôle, policy) — jamais des bits eux-mêmes.