ANSSI — Analyse de risque chiffrement: actions RGPD art. 32 et CSSF 22/806

Le 27 mai 2026, l’ANSSI a publié une nouvelle « Analyse de risque — chiffrement et cryptographie » destinée aux décideurs non spécialistes, avec des recommandations concrètes. Voici comment traduire ces exigences en une architecture de chiffrement “at‑rest” et “in‑transit” conforme au RGPD (art. 32) et à la circulaire CSSF 22/806 sur le cloud. (ANSSI, IT Social)

Les faits

Le 27 mai 2026, l’ANSSI a publié une analyse de risque sur le chiffrement qui cible explicitement les organisations utilisatrices de solutions cryptographiques sans être expertes du sujet. Le document structure les décisions à prendre (choix d’algorithmes, tailles de clés, gouvernance des clés, contraintes opérationnelles) et ouvre un chantier prioritaire : préparer la transition post‑quantique de manière maîtrisée, sans « big‑bang » et en conservant une interopérabilité avec les systèmes actuels. L’agence y rappelle les critères d’évaluation pour prioriser les risques et les mesures, en annexes opérationnelles. Source officielle : ANSSI, 27/05/2026. Couverture presse : IT Social, 02/06/2026.

Dans la même trajectoire, l’ANSSI avait déjà publié début 2026 un guide spécifique sur l’évolution de TLS 1.3 vers le post‑quantique, confirmant que la bascule sera progressive (approches hybrides) et que le pilotage devra être documenté. (DataGuidance, 02/02/2026)

Le cadre légal qui s’applique

RGPD — article 32 (sécurité du traitement) : les responsables et sous‑traitants doivent mettre en œuvre des « mesures techniques et organisationnelles appropriées » incluant, le cas échéant, le chiffrement. L’exigence est risk‑based : état de l’art, coûts, nature des traitements et risques pour les personnes. Voir l’article 32 RGPD et la référence CNPD : CNPD — Chapitre IV, art. 32.

CSSF — Circulaire 22/806 (externalisation et cloud) : elle exige une gestion des risques et des contrôles proportionnés pour l’outsourcing TIC, notamment en cloud, avec des exigences de protection des données en transit et au repos, de gouvernance des clés, de localisation, et de supervision continue. Texte officiel : CSSF 22/806.

En synthèse : l’ANSSI fournit le référentiel technique à jour, l’article 32 RGPD impose le niveau de sécurité (dont le chiffrement), et la CSSF précise les attendus opérationnels en environnement externalisé/cloud.

La solution technique à déployer

Objectif : documenter et déployer une architecture de chiffrement cohérente, alignée avec l’ANSSI, le RGPD art. 32 et la CSSF 22/806, couvrant données at‑rest, in‑transit et le cycle de vie des clés.

• Chiffrement in‑transit : généraliser TLS 1.3 avec suites robustes, PFS activée, et préparation à l’hybride post‑quantique côté terminaux exposés (fronts web, API, VPN), conformément aux orientations ANSSI. Cartographier les flux critiques (interop B2B, mainframe, IoT) et planifier les mises à niveau protocolaires. (ANSSI via DataGuidance)
• Chiffrement at‑rest : combiner envelope encryption (clés de données DEK par objet/table, chiffrées par une KMS‑KEK) et des HSM certifiés pour l’ancrage de confiance. Appliquer le chiffrement natif des SGBD, des volumes virtuels et des stockages objet, avec séparation des rôles (secops ≠ DBA ≠ cloud admin). Référence CSSF 22/806 pour l’externalisation cloud. (CSSF 22/806)
• Gouvernance des clés (KMS) : politique de classes de clés, tailles, durées de vie, rotation, révocation, sauvegardes chiffrées et journalisation inviolable des usages (forensics). Restreindre l’export des clés, appliquer le « least privilege » aux APIs KMS.
• Segmentation des périmètres de confiance : isolez le plan de contrôle crypto (KMS/HSM) du plan de données, avec contrôles réseau et IAM dédiés (comptes de service restreints, mTLS entre services).
• Inventaire et preuves : CMDB des données et des flux chiffrés, attestation de configuration (TLS scanners, baselines KMS), et tests de restauration/lisibilité des archives chiffrées.
• Feuille de route post‑quantique : recenser les dépendances cryptographiques, choisir des mécanismes hybrides quand disponibles, et préparer des pilotes (par ex. terminaux TLS en PQC hybride) avec critères de repli. Aligné ANSSI. (ANSSI 27/05/2026)

Références standards : ISO/IEC 27001 Annexe A (contrôles A.8.24 « cryptographie », A.5.15 « contrôles d’accès », A.8.9 « gestion des secrets »), NIST CSF 2.0 (PR.DS‑1/2, PR.PS‑3), et bonnes pratiques ENISA sur la protection des données au repos/en transit (chiffrement, gestion des clés, résilience). (ENISA, 2025 — guidance technique)

Comment Luxgap déploie cela

• Notre gouvernance ISO 27001 : cadrage « crypto policy » (algorithmes, tailles, usages), registre des actifs cryptographiques, et preuve de conformité (revues de config TLS, états KMS/HSM, rapports d’accès). Nos Lead Implementers orchestrent risque → contrôle → preuve, requis par l’art. 32 RGPD et la CSSF 22/806.
• Nos consultants DPO externalisés et CISO externalisés : traduction juridique → technique : traçabilité des choix « état de l’art », DPIA quand nécessaire, clauses d’externalisation (accès aux clés, localisation, assistance incidentelle), et vérification du right‑to‑audit cloud.
• Notre SOC managed : supervision des composants crypto (KMS/HSM), détection d’abus de clés/tokens, contrôles de configuration TLS, et preuves horodatées utiles en cas d’incident (art. 33 RGPD, reporting réglementaire sectoriel).

Concrètement : nous commençons par un crypto discovery (où, quoi, comment), puis une matrice de décisions alignée ANSSI (risques/contraintes/interop), et un lot technique priorisé : durcissement TLS, baselines KMS, séparation des rôles, puis pilotes post‑quantiques ciblés.

Cas concret au Luxembourg ou en UE

Exemple réaliste : une société de gestion luxembourgeoise (soumise à la CSSF 22/806) exploite un data lake analytique en cloud et des APIs avec des partenaires EU. En 6 semaines :

1. Cartographie des flux et jeux de données sensibles, exigence « crypto everywhere » documentée au titre de l’art. 32 RGPD.
2. Passage uniforme en TLS 1.3 côté API, désactivation des suites faibles, mTLS entre micro‑services internes.
3. Mise en place d’envelope encryption avec KMS managé et ancrage HSM, rotation automatique des KEK, key usage logs surveillés par le SOC.
4. Contrats d’externalisation mis à jour (accès aux clés, journaux, assistance à la notification), alignés CSSF 22/806.
5. Pilotage PQC hybride sur les terminaux exposés (front API partenaires) avec critères d’acceptation et repli.

Résultat : conformité démontrable (dossiers de preuves, registres de config), réduction de surface d’attaque (secrets, clés, chemins réseau), et trajectoire post‑quantique crédible sans rupture de service.

Premiers pas concrets

• Cette semaine, lancez un scan TLS externe/interne : inventaire des hôtes, versions, suites. Priorisez les correctifs vers TLS 1.3.
• Établissez une politique crypto simple (algorithmes, tailles, rôles, rotations, journaux), en vous appuyant sur l’analyse ANSSI.
• Activez l’envelope encryption pour vos stockages sensibles (bases, objets, volumes) avec KMS et journaux d’usage centralisés.
• Séparez plans de contrôle/données : IAM dédié au KMS/HSM, comptes de service limités, mTLS entre services critiques.
• Désignez un référent post‑quantique : cartographiez dépendances crypto, ciblez 1‑2 pilotes hybrides (par ex. terminaux TLS exposés) et définissez vos critères d’évaluation.

Sources officielles

• ANSSI — Analyse de risque « chiffrement et cryptographie » (27 mai 2026)
• CSSF — Circulaire 22/806 (externalisation/Cloud)
• CNPD — RGPD, Chapitre IV (incl. article 32 Sécurité du traitement)
• DataGuidance — ANSSI: guide de transition TLS 1.3 post‑quantique (02/02/2026)
• IT Social — ANSSI : lancer la transition post‑quantique (02/06/2026)
• ENISA — Technical implementation guidance on cybersecurity risk management measures (2025)