Réduire la dépendance : clés, standards et plan de sortie

Pourquoi

La métropole qui veut utiliser Signalements a envoyé à Lyneko un questionnaire de sécurité. Deux questions y sont soulignées :

1. « Qui, chez vous ou chez vos sous-traitants, peut techniquement lire les photos transmises par les habitants ? »
2. « Si nous décidons de changer de prestataire dans trois ans, comment récupérons-nous nos données, en combien de temps, et dans quel format ? »

La première porte sur la confidentialité face au prestataire ; la seconde sur la dépendance. Ce sont les deux faces de la souveraineté qu'une équipe technique peut réellement travailler, quel que soit l'hébergeur retenu. Les leçons précédentes ont posé le cadre : les dimensions de la souveraineté (leçon 1), les lois qui permettent à une autorité étrangère d'exiger des données (leçon 2), la qualification qui organise la résistance à ces lois (leçon 3), les textes qui l'imposent à certains clients (leçon 4). Cette leçon traite les leviers techniques.

On les présente souvent comme des solutions miracles : « les données sont chiffrées, et c'est nous qui avons la clé », « tout est en Kubernetes, nous pouvons partir quand nous voulons ». Ces phrases peuvent être vraies, partiellement vraies ou fausses, selon des détails précis ; sans eux, une équipe promet une protection qu'elle ne fournit pas, ou paie une complexité qui ne protège de rien.

Ce qui se passe sans ce travail est banal : une réponse au questionnaire qui affirme « chiffrement de bout en bout » alors que le fournisseur détient les clés ; un plan de réversibilité de deux pages jamais exécuté, qui découvre le jour du départ que les photos sont chiffrées par une clé qu'on ne peut pas emporter ; une application dont l'authentification, la forge et l'intégration continue dépendent toutes d'un même groupe américain, sans que personne l'ait décidé.

Les concepts

Trois questions avant de parler de chiffrement

« Chiffré au repos » ne dit presque rien. Pour savoir ce qu'un chiffrement protège, il faut trois réponses :

• Qui détient la clé ? Le fournisseur, vous, ou un tiers de confiance.
• Où a lieu le déchiffrement ? Dans le service du fournisseur, dans votre application, sur le poste de l'utilisateur.
• Qui contrôle le code qui déchiffre ? Si le fournisseur exécute le logiciel qui reçoit la clé, il peut, techniquement, en faire autre chose.

Tous les chiffrements « au repos » activés par défaut chez les fournisseurs de cloud répondent : le fournisseur, chez le fournisseur, par le code du fournisseur. Ils protègent contre le vol d'un disque dans un centre de données ou sa revente sans effacement. Ils ne protègent pas contre le fournisseur lui-même, ni contre une autorité qui s'adresse à lui.

Le chiffrement d'enveloppe

Tous les services de gestion de clés du marché reposent sur le même schéma, le chiffrement d'enveloppe (envelope encryption). Il sépare deux sortes de clés :

• une clé de données (Data Encryption Key, DEK) chiffre les données elles-mêmes. Elle est générée pour un fichier, un objet ou un lot, et voyage avec lui, chiffrée ;
• une clé de chiffrement de clés (Key Encryption Key, KEK) chiffre les clés de données. Elle ne quitte jamais le service de gestion de clés (KMS, Key Management Service), et on ne peut que lui demander de chiffrer ou de déchiffrer une petite donnée.

    flowchart LR
  subgraph KMS["Service de gestion de clés"]
    KEK["KEK<br/>ne sort jamais"]
  end
  subgraph App["Application"]
    DEK["DEK en clair<br/>en mémoire seulement"]
  end
  P["photo"] -->|"AES-256-GCM avec la DEK"| C["photo chiffrée"]
  DEK -.->|"envoyée au KMS"| KEK
  KEK -.->|"DEK chiffrée"| E["DEK chiffrée<br/>stockée avec la photo"]
  C --- E
  

Pourquoi deux niveaux ? Pour trois raisons pratiques. Le KMS limite la taille de ce qu'il chiffre (64 Kio chez Scaleway, d'après sa documentation) et chaque opération est un appel réseau facturé : on ne lui envoie pas une photo de 3 Mo, on lui envoie 32 octets de clé. La rotation de la KEK ne demande pas de rechiffrer les données : seules les DEK sont réenveloppées. Et la révocation est instantanée : détruire ou désactiver la KEK rend illisibles toutes les DEK, donc toutes les données, où qu'elles soient copiées. C'est l'effacement cryptographique (crypto-shredding), un outil utile pour honorer une demande d'effacement sur des sauvegardes, et un piège mortel quand il est involontaire.

L'échelle de maîtrise des clés

Les offres se rangent sur une échelle. Chaque marche ajoute de la maîtrise, et de la charge.

Quelques précisions vérifiées dans les documentations, au 5 octobre 2026 :

• Scaleway Key Manager accepte depuis peu l'import de matière de clé : la page de documentation correspondante a été publiée le 2 septembre 2026. Une clé créée avec l'origine external et l'algorithme aes_256_gcm reçoit une matière que vous avez générée. Scaleway ne l'utilise pas telle quelle : il la passe dans une fonction de dérivation (HKDF avec SHA-256 et un sel). Seules les clés AES peuvent être importées, pas les clés asymétriques. La documentation précise aussi que les garanties de génération (aléa du noyau, conformité à la recommandation R14 du guide ANSSI-PA-079) ne s'appliquent pas à une matière importée : sa qualité devient votre responsabilité.
• AWS KMS External Key Store (XKS) : la clé reste dans un gestionnaire que vous exploitez, joint par un mandataire que vous fournissez ; AWS chiffre d'abord avec sa propre matière, puis fait chiffrer le résultat par votre gestionnaire. Si vous coupez l'accès, AWS ne peut plus rien déchiffrer. AWS prévient lui-même que, pour la plupart des clients, la charge d'exploitation et le risque sur la disponibilité dépassent le bénéfice.
• Google Cloud EKM : même principe ; l'option Key Access Justifications joint à chaque requête un motif que votre gestionnaire peut refuser. Une clé externe perdue rend les données irrécupérables.
• Microsoft Double Key Encryption concerne les documents et courriels protégés par étiquettes de sensibilité dans Microsoft 365, pas l'infrastructure Azure. Le prix est explicite dans la documentation : pas de coédition, pas de recherche ni d'eDiscovery, pas d'ouverture dans Office pour le web, pas de Copilot sur ces contenus.

La limite que rien ne contourne : le traitement en clair

Le Comité européen de la protection des données (EDPB) a examiné, après l'arrêt Schrems II, quelles mesures techniques pouvaient protéger des données transférées hors de l'Union. Ses recommandations 01/2020 (version 2.0 du 18 juin 2021) contiennent deux cas d'usage qui résument tout ce paragraphe :

• Cas d'usage 1, stockage sans accès aux données en clair (sauvegarde, archivage) : un chiffrement fort, appliqué avant l'envoi, avec des clés qui restent sous le seul contrôle de l'exportateur ou d'un tiers de confiance dans l'Espace économique européen, constitue une mesure efficace.
• Cas d'usage 6, prestataire qui doit accéder aux données en clair pour rendre le service : l'EDPB se dit, « en l'état de l'art », incapable d'envisager une mesure technique efficace. Il ajoute que le chiffrement en transit et au repos, même combinés, ne suffisent pas si l'importateur détient les clés.

Traduit pour Signalements : une base PostgreSQL managée doit lire les données en clair pour exécuter les requêtes. Le chiffrement de ses disques, même avec une clé que vous gérez, ne change rien à ce que l'opérateur de la base pourrait techniquement extraire de sa mémoire, ni à ce qu'une autorité pourrait exiger de lui. Seule la juridiction et l'organisation de l'opérateur (leçons 2 et 3) répondent à ce risque. Le chiffrement côté client, lui, protège réellement les photos, à condition que le service de stockage n'ait jamais besoin de les lire.

Les HSM et leurs certifications

Un module matériel de sécurité (Hardware Security Module, HSM) est un équipement conçu pour générer, garder et utiliser des clés sans jamais les exposer, avec des protections physiques contre l'ouverture. Trois repères permettent d'en juger :

• FIPS 140-3, la norme américaine de validation des modules cryptographiques, gérée par le programme CMVP du NIST, avec quatre niveaux de sécurité. Son prédécesseur FIPS 140-2 n'accepte plus de nouvelles demandes depuis avril 2022, et ses derniers certificats sont passés sur la liste « historique » le 22 septembre 2026 : un certificat 140-2 cité dans une offre est désormais un argument daté.
• Les Critères communs (ISO/IEC 15408), avec un niveau d'assurance de l'évaluation (EAL) et un profil de protection.
• La qualification ANSSI de produits, dont le niveau « renforcé » repose sur une évaluation Critères communs EAL4+. Le HSM Trustway Proteccio d'Eviden est qualifié à ce niveau (décision 2024-1778).

Un KMS de fournisseur n'est pas forcément un HSM. AWS indique que la matière de ses clés KMS est générée et utilisée dans des HSM validés FIPS 140-3 niveau 3. La documentation de Scaleway Key Manager consultée le 5 octobre 2026 décrit ses mécanismes (AES-256-GCM, dérivation HKDF, générateur aléatoire du noyau Linux alimenté notamment par RDSEED et RDRAND, conformité revendiquée au guide ANSSI-PA-079) mais ne mentionne pas de HSM. Ce n'est pas un défaut en soi ; c'est une question à poser par écrit si votre client l'exige.

L'informatique confidentielle

Le Confidential Computing Consortium, projet de la Linux Foundation, définit l'informatique confidentielle (confidential computing) comme la protection des données en cours d'utilisation, par un calcul exécuté dans un environnement d'exécution de confiance (Trusted Execution Environment, TEE) matériel et attesté. Concrètement :

• la mémoire de la machine virtuelle est chiffrée par le processeur avec une clé que l'hyperviseur ne connaît pas (AMD SEV-SNP, apparu avec les EPYC de troisième génération en 2021 ; Intel TDX sur les Xeon récents ; les GPU NVIDIA H100 étendent le principe au calcul accéléré) ;
• l'attestation permet à un tiers de vérifier, par une preuve signée par le processeur, quel code tourne dans l'environnement avant de lui confier une clé.

C'est la seule famille de techniques qui s'attaque au cas d'usage 6 de l'EDPB, et l'EDPB lui-même écrivait en 2021 ne pas exclure qu'un progrès technique y parvienne. En l'état, trois réserves s'imposent. La confiance se déplace vers le fabricant du processeur, dont les clés de signature fondent l'attestation (AMD, Intel et NVIDIA sont américains). Les attaques par canaux auxiliaires sur ces environnements sont un domaine de recherche actif. Et l'offre est inégale : les grands clouds américains proposent des machines virtuelles confidentielles ; l'index de la documentation de Scaleway, consulté le 5 octobre 2026, ne contient aucune page sur ce sujet. Considérez l'informatique confidentielle comme une mesure complémentaire prometteuse, pas comme une réponse réglementaire acquise.

Les standards ouverts rendent la sortie possible

La seconde question de la métropole porte sur la dépendance. La règle est simple à énoncer : chaque brique doit avoir au moins un équivalent ailleurs, et un format d'export que cet équivalent sait lire. Pour Signalements :

Deux nuances. L'API S3 est une interface de fait, définie par Amazon et imitée par tous : une extension propre à un fournisseur (une option de chiffrement, une politique particulière) peut ne pas exister ailleurs. Et une infrastructure décrite en Terraform n'est pas « portable » : la syntaxe l'est, les ressources (scaleway_instance_server, aws_instance) ne le sont pas. Le code donne un inventaire précis et une base de travail, pas un bouton de migration.

La licence compte autant que le standard. Le 10 août 2023, HashiCorp a fait passer Terraform de la licence libre MPL 2.0 à la Business Source License ; la communauté a répondu par une bifurcation, OpenTofu, confiée à la Linux Foundation en septembre 2023, dont la version 1.6.0 est sortie le 10 janvier 2024. Les équipes qui ne dépendaient que d'un logiciel libre ont pu choisir ; celles qui dépendaient d'un service hébergé par l'éditeur n'avaient pas de bifurcation possible. C'est la vraie protection du logiciel libre : non pas la gratuité, mais l'existence d'une suite si l'éditeur change les règles.

Multi-cloud : un outil, pas une vertu

« Nous serons multi-cloud » revient dans beaucoup de stratégies. Distinguez trois choses :

• Pouvoir partir (portabilité) : standards, exports, plan de sortie testé. Utile pour presque tout le monde, et peu coûteux si on le prévoit dès le départ.
• Répartir des applications différentes chez des fournisseurs différents, chacune au bon endroit. Raisonnable, et fréquent par accident (le site chez l'un, la messagerie chez un autre).
• Faire tourner une même application sur plusieurs fournisseurs en même temps. Très coûteux : on se limite au plus petit dénominateur commun des services, on double l'outillage, les compétences et les frais de transfert entre fournisseurs. Justifié seulement par une exigence de continuité forte ou une interdiction de dépendance unique écrite dans un texte ou un contrat.

Pour Signalements, la portabilité suffit. Le reste serait un coût sans bénéfice proportionné.

Les dépendances qu'on ne voit pas : la chaîne de livraison

L'inventaire de dépendances s'arrête souvent à l'hébergement de production. Or l'application se construit, se déploie et s'administre avec d'autres services. Pour Signalements, au 5 octobre 2026 :

Aucune de ces dépendances n'est une faute : ce sont des choix raisonnables pour une petite équipe. Mais la métropole a demandé « qui peut lire », et le fournisseur d'identité qui donne accès à l'outil de déploiement, ou le service de CI qui détient la clé du registre, en font partie. Le cours GitOps avec Argo CD a montré comment cette connexion Google est configurée ; ici, on la nomme dans l'inventaire.

Le plan de sortie

Un plan de sortie (ou plan de réversibilité) est le document qui permet de quitter un fournisseur dans un délai et à un coût connus. Il contient au minimum :

1. l'inventaire des données et des configurations, avec leurs volumes ;
2. pour chaque élément, le format d'export et la commande ou la procédure ;
3. les clés : comment déchiffrer ou réenvelopper ce qui est chiffré par une clé qui ne partira pas ;
4. la cible de repli (au moins une, nommée) ;
5. les durées et les coûts estimés, y compris les frais de sortie et la période de double fonctionnement ;
6. les rôles et le déclencheur ;
7. la date et le résultat du dernier test.

Le cours Le cloud : les fondamentaux a présenté le règlement européen sur les données (Data Act), qui impose aux fournisseurs des délais de transition et la fin des frais de changement de fournisseur à partir du 12 janvier 2027. Le règlement rend le départ moins cher ; il ne le rend pas possible si vous n'avez pas préparé ce qui vous revient.

En pratique

Chiffrer les photos de Signalements en enveloppe avec Key Manager

Les photos des habitants sont stockées dans le bucket signalements-pj-<suffixe> (cours cloud, leçon 5). Le fournisseur les chiffre au repos avec ses propres clés. On va les chiffrer avant l'envoi, avec une DEK par photo, enveloppée par une KEK de Key Manager. Le service de stockage objet ne verra plus jamais de photo en clair.

Les commandes de cette section ont été vérifiées avec l'aide de scw 2.62.0 et la documentation de Key Manager ; elles appellent l'API de Scaleway et ne sont pas suivies de leur sortie, qui contient des identifiants propres à votre compte.

1. Créer la KEK.

$ KEK_ID=$(scw keymanager key create name=sig-photos \
    usage.symmetric-encryption=aes_256_gcm \
    description="KEK des photos de Signalements" region=fr-par -o json | jq -r .id)

• usage.symmetric-encryption=aes_256_gcm : une clé symétrique, seul usage possible pour envelopper des DEK.
• Par défaut, la clé est protégée contre la suppression (le paramètre unprotected de l'API vaut false) : il faudra un scw keymanager key unprotect explicite avant de pouvoir la supprimer. Gardez ce réglage.
• Une suppression, même voulue, n'est pas immédiate : la clé passe sept jours en attente, pendant lesquels on peut la récupérer.

2. Obtenir une DEK.

$ scw keymanager key generate-data-key "$KEK_ID" algorithm=aes_256_gcm region=fr-par -o json > dek.json

La réponse contient, d'après la documentation de Scaleway et la structure DataKey de son SDK, les champs key_id, algorithm, ciphertext (la DEK enveloppée, en base64), plaintext (la DEK en clair, en base64) et created_at. Le fichier dek.json contient donc une clé en clair : il n'existe ici que pour l'explication. En production, l'application garde plaintext en mémoire le temps de chiffrer, et ne stocke que ciphertext. L'option without-plaintext=true demande une DEK uniquement enveloppée, utile pour en préparer à l'avance.

3. Chiffrer avec la DEK, localement. Key Manager ne chiffre pas les données : il ne traite que des entrées de 64 Kio au plus, et sa documentation le réserve aux DEK. Le chiffrement de la photo se fait dans l'application. Un premier réflexe serait openssl enc ; il échoue avec le mode recommandé :

$ openssl enc -aes-256-gcm -K "$(openssl rand -hex 32)" -iv "$(openssl rand -hex 12)" \
    -in photo-4812.jpg -out photo-4812.bin
enc: AEAD ciphers not supported
enc: Use -help for summary.

La commande enc d'OpenSSL 3.0 ne prend pas en charge les modes authentifiés comme GCM. L'exemple de la documentation de Scaleway se rabat sur AES-256-CBC avec un vecteur d'initialisation nul et sans sel, en prévenant qu'OpenSSL n'est pas recommandé en production. Ne reprenez pas cet exemple tel quel : CBC n'authentifie pas les données (une photo modifiée se déchiffrerait sans erreur) et un vecteur fixe n'est acceptable que si chaque DEK ne sert qu'une fois. La documentation recommande la bibliothèque Tink, pour laquelle Scaleway publie des intégrations Go et Python.

Pour voir le mécanisme sans dépendre d'un compte, voici une démonstration locale avec la bibliothèque Python cryptography. Un fichier kek.bin de 32 octets aléatoires y joue le rôle de Key Manager :

#!/usr/bin/env python3
"""Chiffrement d'enveloppe de démonstration : une clé de données (DEK) par fichier,
protégée par une clé de chiffrement de clés (KEK) locale qui joue le rôle de Key Manager.
Usage : enveloppe.py chiffrer FICHIER | enveloppe.py dechiffrer FICHIER.env"""
import json, os, sys, base64
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

b64 = lambda b: base64.b64encode(b).decode()
kek = AESGCM(open("kek.bin", "rb").read())

def chiffrer(chemin):
    dek = AESGCM.generate_key(bit_length=256)          # 1. une DEK neuve par fichier
    n1, n2 = os.urandom(12), os.urandom(12)
    nom = os.path.basename(chemin).encode()             # donnée associée : le nom du fichier
    donnees = AESGCM(dek).encrypt(n1, open(chemin, "rb").read(), nom)   # 2. chiffrer le contenu
    dek_chiffree = kek.encrypt(n2, dek, b"signalements/photos")          # 3. envelopper la DEK
    entete = {"dek": b64(n2 + dek_chiffree), "nonce": b64(n1), "nom": nom.decode()}
    with open(chemin + ".env", "wb") as f:
        f.write(json.dumps(entete).encode() + b"\n" + donnees)
    del dek                                             # 4. oublier la DEK en clair

def dechiffrer(chemin):
    entete, donnees = open(chemin, "rb").read().split(b"\n", 1)
    entete = json.loads(entete)
    brut = base64.b64decode(entete["dek"])
    dek = kek.decrypt(brut[:12], brut[12:], b"signalements/photos")
    clair = AESGCM(dek).decrypt(base64.b64decode(entete["nonce"]), donnees, entete["nom"].encode())
    sys.stdout.buffer.write(clair)

{"chiffrer": chiffrer, "dechiffrer": dechiffrer}[sys.argv[1]](sys.argv[2])

Exécution sur un fichier de 200 000 octets :

$ openssl rand -out kek.bin 32
$ python3 enveloppe.py chiffrer photo-4812.jpg
$ ls -l photo-4812.jpg photo-4812.jpg.env | awk '{print $5, $9}'
200000 photo-4812.jpg
200162 photo-4812.jpg.env
$ head -1 photo-4812.jpg.env
{"dek": "Sj+xBOWl7M5Mgn6q6W7Nrsjqr91uDTNYQn7T1zIXFQTEGrhRDc+9TImXfSi0cYN8hoyaR6Y2M3yZAc47", "nonce": "8HU9wJ8NWRwbkZFs", "nom": "photo-4812.jpg"}
$ python3 enveloppe.py dechiffrer photo-4812.jpg.env | cmp - photo-4812.jpg && echo identique
identique

Le fichier chiffré ne pèse que 162 octets de plus : l'en-tête JSON (la DEK enveloppée avec son nonce et son étiquette d'authentification, le nonce des données, le nom) et l'étiquette de 16 octets de GCM. Remplaçons maintenant la KEK, comme si elle avait été détruite :

$ openssl rand -out kek.bin 32
$ python3 enveloppe.py dechiffrer photo-4812.jpg.env > /dev/null
...
cryptography.exceptions.InvalidTag

C'est l'effacement cryptographique : la photo chiffrée existe toujours, mais plus personne ne peut la lire. Deux détails du script comptent. Le nom du fichier est passé en donnée associée : un attaquant qui échangerait deux fichiers chiffrés provoquerait une erreur d'authentification au lieu d'afficher la mauvaise photo. Et le contexte signalements/photos attaché à l'enveloppe empêche de réutiliser une DEK enveloppée pour un autre usage.

Avec Key Manager, les étapes 1 et 3 du script deviennent un appel à generate-data-key ; le déchiffrement de la DEK devient :

$ scw keymanager key decrypt "$KEK_ID" ciphertext="$DEK_ENVELOPPEE" region=fr-par -o json | jq -r .plaintext

et la photo chiffrée part dans le bucket comme n'importe quel objet. Le stockage objet ne voit que des octets illisibles ; Key Manager ne voit que des clés de 32 octets ; seule l'application, qui appelle les deux, voit les photos.

4. Tourner la KEK.

$ scw keymanager key rotate "$KEK_ID" region=fr-par

La rotation crée une nouvelle version de la KEK ; les DEK enveloppées par les versions précédentes restent déchiffrables, et la documentation précise que l'opération Decrypt renvoie alors, en plus, la DEK réenveloppée par la version la plus récente : l'application peut la réécrire au passage. Les photos, elles, ne sont pas touchées.

Variante : importer sa propre matière de clé

Si le client exige de garder une copie de la clé hors de Scaleway (pour pouvoir déchiffrer ses archives après un départ, ou parce que sa politique l'impose), on crée une clé d'origine externe et on lui fournit la matière :

$ KEK_EXT=$(scw keymanager key create name=sig-photos-byok \
    usage.symmetric-encryption=aes_256_gcm origin=external region=fr-par -o json | jq -r .id)
$ umask 077
$ openssl rand -out matiere.bin 32
$ openssl rand -out sel.bin 32
$ jq -n --arg m "$(base64 -w0 matiere.bin)" --arg s "$(base64 -w0 sel.bin)" \
    '{key_material: $m, salt: $s}' > import.json
$ SCW_SECRET_KEY=$(scw config get secret-key)
$ curl -s -X POST \
    "https://api.scaleway.com/key-manager/v1alpha1/regions/fr-par/keys/$KEK_EXT/import-key-material" \
    -H "X-Auth-Token: $SCW_SECRET_KEY" -H 'Content-Type: application/json' --data @import.json
$ shred -u import.json && unset SCW_SECRET_KEY

• La clé est créée dans l'état pending_key_material et ne sert à rien tant que la matière n'est pas importée.
• La matière et le sel sont 32 octets aléatoires chacun, transmis en base64 dans le corps JSON, comme le montre la documentation de Scaleway ; umask 077 rend les fichiers lisibles par vous seul. matiere.bin et sel.bin sont à conserver dans votre propre coffre (un HSM, un coffre hors ligne), puis à effacer du poste. Sans cette copie, l'import n'apporte rien de plus qu'une clé générée par Scaleway.
• Un nouvel import sur la même clé crée une nouvelle rotation ; supprimer la matière d'une rotation rend illisible tout ce qu'elle a chiffré.

Mesurez ce que vous avez obtenu. La matière a transité par l'API et vit désormais aussi chez Scaleway : vous avez gagné la portabilité et la maîtrise de la génération, pas l'inaccessibilité pour le fournisseur. Et parce que Scaleway dérive sa clé de votre matière par HKDF, la copie que vous gardez ne vous permet pas, seule, de déchiffrer hors de Key Manager des DEK enveloppées par lui : pour une vraie portabilité des données, le plan de sortie doit prévoir de réenvelopper les DEK avec une clé de la cible avant de partir (voir le plan ci-dessous).

Le plan de sortie de Signalements

Voici le plan rédigé par l'équipe pour la métropole. Les volumes sont ceux de l'exemple ; les durées sont calculées, pas mesurées, d'où le test prévu en fin de plan.

Inventaire et procédures.

Durées. Le poste dominant est le transfert des photos : 480 Go à un débit soutenu de 500 Mbit/s, c'est 480 × 8 / 0,5 ≈ 7 700 secondes, soit environ deux heures et dix minutes en théorie ; prévoyez une journée, avec les reprises et la vérification des sommes de contrôle. Le réenveloppement des DEK coûte deux opérations de clé par photo (un decrypt, un chiffrement chez la cible) : pour 400 000 photos, 800 000 opérations, que la limite de débit des deux API, et non le calcul, fixera. La base se restaure en moins d'une heure. Avec la bascule DNS et une période de double fonctionnement d'une semaine, le plan annonce dix jours ouvrés.

Cible de repli. Un autre hébergeur offrant PostgreSQL managé, un stockage compatible S3 et un registre OCI dans l'Union européenne. Elle est nommée dans le plan, pas ici : le choix dépend de l'analyse de la leçon 6.

Clés. Point bloquant si on l'oublie : tant que les DEK sont enveloppées par Key Manager, les photos exportées sont illisibles hors de Scaleway. Le réenveloppement se fait avant la fermeture du compte, et la KEK n'est supprimée qu'après la vérification d'un échantillon de photos chez la cible. Inversement, une fois le départ terminé, la suppression de la KEK sert de preuve d'effacement des copies restées chez l'ancien fournisseur (sauvegardes comprises).

Test. Une fois par an, l'équipe restaure dans un projet de la cible la sauvegarde de la base et un échantillon de 1 000 photos, réenveloppe leurs DEK, lance l'application, et mesure les durées. Le résultat (date, durées, écarts) est ajouté au plan. Un plan jamais testé n'est qu'une liste d'intentions.

Sous le capot

Ce que fait Key Manager à chaque appel. D'après sa documentation, Key Manager chiffre avec AES-256-GCM, un mode qui chiffre et authentifie : chaque chiffrement tire un vecteur d'initialisation unique de 96 bits, et toute modification du texte chiffré est détectée au déchiffrement. Les versions de clé sont dérivées par HKDF (RFC 5869) avec SHA-256 à partir de 256 bits d'aléa. Les entrées sont limitées à 64 Kio, ce qui, d'après Scaleway, réduit le risque de sur-utilisation d'une clé et suit les recommandations R1, R4 et R12 du guide de sélection d'algorithmes de l'ANSSI. Les versions de clé ne sortent jamais du service : le seul moyen de déchiffrer est l'appel Decrypt. Chaque appel est donc authentifié, autorisé et journalisable : c'est ce qui transforme une clé en point de contrôle.

Pourquoi GCM et pas CBC. CBC chiffre sans authentifier : un attaquant qui modifie le texte chiffré obtient un texte déchiffré altéré, sans erreur, et des attaques par oracle de remplissage ont exploité ce défaut pendant des années. GCM ajoute une étiquette d'authentification de 128 bits. Son point faible est inverse : réutiliser un nonce avec la même clé détruit la confidentialité et l'authenticité. D'où la règle « une DEK par objet, un nonce aléatoire par chiffrement », que respecte le script.

Pourquoi un cache de DEK affaiblit la révocation. Appeler le KMS pour chaque photo affichée coûte du temps et de l'argent ; les applications gardent donc des DEK déchiffrées en mémoire quelques minutes. Pendant ce temps, désactiver la KEK n'a pas d'effet sur elles. AWS le documente pour ses propres services. Fixez une durée de cache courte et connue, et mentionnez-la dans la réponse au client.

Pièges courants

Stocker la DEK en clair « pour simplifier ». Le fichier dek.json de la pratique, oublié dans un dépôt ou un volume, annule tout le dispositif. La documentation de Scaleway le répète : ne jamais stocker la DEK en clair.

Supprimer la KEK trop tôt. Une rotation de personnel, un nettoyage de projet, un script de démontage : la KEK disparaît, et avec elle toutes les photos, sauvegardes comprises. La protection contre la suppression, activée par défaut, et le délai de sept jours sont là pour ce cas ; ne les retirez pas, et séparez les droits de suppression des clés des droits d'exploitation courante.

Confondre BYOK et HYOK. Importer sa clé ne la rend pas inaccessible au fournisseur : elle vit dans son KMS. Écrire « clés hors de portée du prestataire » dans une réponse à un client, avec du BYOK, est inexact.

Croire que le chiffrement des disques règle la question juridique. Le cas d'usage 6 de l'EDPB est clair : un service qui traite les données en clair reste exposé, quelle que soit la clé des disques. La réponse est juridique et organisationnelle (leçons 2 et 3).

Le plan de sortie qui oublie les clés. Exporter 480 Go de photos chiffrées dont les DEK sont enveloppées par une clé qu'on ne peut pas emporter, c'est exporter 480 Go de bruit.

Les sauvegardes et instantanés hors inventaire. Le cours cloud l'a montré : les sauvegardes d'une base managée survivent à sa suppression, les instantanés de volumes aussi. Un plan de sortie qui ne les liste pas laisse des copies derrière lui, facturées et lisibles.

Sécurité

• Qui peut appeler Decrypt peut lire les données. La politique IAM de la KEK est la vraie politique d'accès aux photos. Donnez ce droit à l'identité de l'application seule, dans le projet de production, et à personne d'autre au quotidien ; mettez la clé dans un projet dédié si l'organisation le permet, pour séparer ceux qui administrent l'application de ceux qui administrent les clés.
• Journalisez l'usage des clés. Un pic d'appels Decrypt hors des heures habituelles est un signal d'exfiltration. Vérifiez quels produits votre journal d'audit couvre réellement (le cours cloud, leçon 7, a montré que celui de Scaleway ne couvre pas tous les produits).
• L'effacement cryptographique est un outil de conformité. Une DEK par photo permet d'effacer une seule photo de toutes les sauvegardes en détruisant sa DEK, ce qui aide à honorer une demande d'effacement au titre du RGPD sans réécrire les sauvegardes.
• Les dépendances de la chaîne de livraison sont des chemins d'accès. Un compte GitHub compromis peut pousser une image malveillante qu'Argo CD déploiera ; un compte Google compromis ouvre l'interface de déploiement. Les réduire est aussi une mesure de sécurité, pas seulement de souveraineté.

En production

• Utilisez Tink, pas un script maison. La bibliothèque gère l'enveloppe, les formats et les nonces ; Scaleway publie des intégrations tink-go-scwkms et tink-py-scwkms.
• Les coûts sont faibles mais pas nuls. Au 5 octobre 2026, la FAQ de Key Manager indique 0,06 € par version de clé et par mois, et 0,03 € les 10 000 opérations. Afficher 50 000 photos par jour, sans cache, coûte 50 000 opérations Decrypt, soit 0,15 € par jour. Le cache, borné, réduit ce coût et la latence.
• Proportionnez. Le chiffrement côté client des photos est justifié pour des données personnelles d'habitants si le client l'exige ou si l'analyse de risques le désigne ; pour un journal technique sans donnée personnelle, le chiffrement par défaut suffit. La leçon 6 donne la méthode pour trancher.
• Le plan de sortie vit avec l'application. Chaque nouveau service ajouté (une file de messages, un moteur de recherche managé) ajoute une ligne à l'inventaire et une question : quel export, quelle cible ? Faites de cette question un point de la revue d'architecture.

Exercices

1. Situer une offre (niveau 300). Un prestataire répond à un appel d'offres : « Vos données sont chiffrées en AES-256 avec des clés gérées par vous dans notre KMS. Elles sont donc inaccessibles à nos équipes et à toute autorité. » Analysez chaque affirmation et proposez une formulation exacte.

2. Enveloppe et rotation (niveau 300). Avec le script enveloppe.py, chiffrez trois fichiers. Écrivez ensuite un second script reenvelopper.py qui, à partir d'une ancienne KEK (kek-ancienne.bin) et d'une nouvelle (kek.bin), réécrit l'en-tête de chaque fichier sans toucher aux données chiffrées. Vérifiez que les fichiers se déchiffrent avec la nouvelle KEK seulement, et que leur partie chiffrée n'a pas changé.

3. Chiffrer un plan de sortie (niveau 300). Votre base fait 80 Gio, votre bucket 2,5 To, et vous disposez d'un débit soutenu de 1 Gbit/s vers la cible. Estimez la durée du transfert, puis listez trois raisons pour lesquelles la durée réelle sera plus longue.

Récapitulatif

• Un chiffrement se juge à trois réponses : qui détient la clé, où a lieu le déchiffrement, qui contrôle le code qui déchiffre.
• Le chiffrement d'enveloppe sépare la DEK, qui chiffre les données et voyage avec elles, de la KEK, qui reste dans le KMS et ne chiffre que des clés. Rotation légère, révocation instantanée, et effacement cryptographique.
• L'échelle de maîtrise : chiffrement par défaut, clé gérée par le client, BYOK (matière importée, que le fournisseur détient aussi), HYOK (clé externe appelée à chaque opération), chiffrement côté client.
• Aucun chiffrement ne protège une donnée que le service doit traiter en clair (cas d'usage 6 de l'EDPB) ; là, seules la juridiction et l'organisation de l'opérateur répondent. L'informatique confidentielle s'attaque à ce cas, avec ses réserves.
• HSM : FIPS 140-3 (140-2 est historique depuis le 22 septembre 2026), Critères communs, qualification ANSSI. Un KMS n'est pas forcément un HSM : demandez-le.
• Les standards ouverts et le logiciel libre rendent la sortie possible ; la licence compte autant que l'interface. Le multi-cloud actif est rarement proportionné.
• La chaîne de livraison (forge, CI, registre, SSO) fait partie des dépendances.
• Un plan de sortie chiffre volumes, durées et coûts, traite les clés, nomme une cible, et se teste.

Pour aller plus loin

• Les recommandations 01/2020 de l'EDPB, annexe 2 : les sept cas d'usage, qui servent de grille à toute analyse de transfert.
• La page External key stores de la documentation d'AWS KMS, remarquablement honnête sur les coûts du HYOK.
• A Technical Analysis of Confidential Computing, du Confidential Computing Consortium, pour les modèles de menace des TEE.
• Le guide de sélection d'algorithmes cryptographiques de l'ANSSI (ANSSI-PA-079), court et directement applicable.
• Le cours Cryptographie appliquée, pour les modes de chiffrement, et le cours Gestion des secrets, pour les coffres et la rotation.
• La leçon suivante, qui assemble tout le cours dans une méthode de décision.