Sauvegardes cloud : chiffrement client-side ou provider-side — ce que la nLPD change

Un opérateur cloud peut lire vos sauvegardes — et ce n'est pas hypothétique

Lorsqu'un provider cloud chiffre vos backups avec ses propres clés (server-side encryption, SSE), il détient techniquement la capacité de déchiffrer vos données à tout moment — sur injonction judiciaire américaine (CLOUD Act, 2018), sur décision interne, ou à la suite d'une compromission de son infrastructure de gestion de clés. Pour une PME suisse traitant des données personnelles au sens de la nLPD, cette situation crée une exposition légale et opérationnelle que la loi ne permet plus d'ignorer depuis le 01.09.2023.

Cadre légal suisse : ce que la nLPD impose réellement aux sauvegardes

Données personnelles dans les backups : une réalité souvent sous-estimée

Un backup complet d'un poste de travail ou d'un serveur applicatif contient quasi systématiquement des données personnelles : fichiers RH, exports comptables, bases CRM, journaux d'accès avec adresses IP. Dès lors, la nLPD s'applique pleinement. Son article 8 impose des mesures techniques et organisationnelles appropriées (privacy by design, privacy by default) ; son article 5 définit le sous-traitant (« sous-traitant » = processeur) comme tenu de respecter les mêmes garanties que le responsable du traitement.

Confier un backup non chiffré côté client à un provider basé aux États-Unis, au Royaume-Uni ou en Irlande constitue un transfert de données vers un État tiers. Même si ce pays figure sur la liste des États reconnus adéquats par le PFPDT, le responsable du traitement doit documenter les garanties contractuelles (clauses contractuelles types, BCR) et s'assurer que le niveau de protection est effectivement maintenu — ce qu'une clé de chiffrement détenue par le provider ne garantit pas.

Obligation de notification en cas d'incident

L'article 24 nLPD impose de notifier le PFPDT dans les meilleurs délais si une violation de données présente un risque élevé pour les personnes concernées. Une fuite de backups non chiffrés côté client correspond presque toujours à un risque élevé (données sensibles en clair, volume important). Le délai de facto observé dans la pratique est de 72 heures, aligné sur l'article 33 RGPD — même si la nLPD ne fixe pas de délai précis en heures. La procédure de signalement est disponible directement auprès du PFPDT.

Sanctions : CHF 250 000 maximum, mais surtout la réputation

La nLPD prévoit des amendes jusqu'à CHF 250 000 à l'encontre des personnes physiques responsables (pas de l'entité juridique directement). Plus concrètement pour une PME, la perte de confiance d'un client institutionnel ou d'un partenaire bancaire — qui exige désormais des attestations de sécurité dans ses appels d'offres — représente un risque financier bien supérieur à l'amende elle-même.

Architecture : client-side vs provider-side — différences techniques qui comptent

Provider-side encryption (SSE) : confort, confiance aveugle

Le modèle SSE (Server-Side Encryption) est celui activé par défaut chez la quasi-totalité des providers cloud (AWS S3 SSE-S3, Azure Storage Service Encryption, Google Cloud Storage CMEK optionnel). Le provider génère et stocke les clés dans son propre KMS (Key Management Service). Avantages : zéro surcharge opérationnelle, intégration native, pas de gestion de clés côté client. Inconvénients critiques :

• Le provider peut déchiffrer à tout moment — injonction légale, administrateur interne malveillant, compromission KMS.
• En cas de fuite du KMS du provider (ex. : incident LastPass 2022, même logique), toutes les clés et donc tous les backups sont compromis simultanément.
• Aucune séparation des rôles entre stockage et accès cryptographique.

Certains providers proposent BYOK (Bring Your Own Key) : vous fournissez une clé maître, le provider chiffre avec. C'est mieux, mais le provider détient toujours temporairement la clé en mémoire lors des opérations de chiffrement/déchiffrement. Ce n'est pas du client-side encryption.

Client-side encryption (CSE) : la seule garantie réelle de confidentialité

En CSE, le chiffrement est appliqué sur l'endpoint ou le serveur source avant que la donnée quitte le périmètre de l'organisation. Le provider ne reçoit que du ciphertext opaque — il ne peut pas en extraire de contenu, même sur injonction, même en cas de compromission de son infrastructure. Les clés ne transitent jamais vers le provider.

Algorithmes recommandés en 2024 : AES-256-GCM pour le chiffrement symétrique des données, RSA-4096 ou ECDH P-384 pour l'échange/enveloppe de clé. Pour les organisations alignées sur les CIS Benchmarks, le niveau IG2 (Implementation Group 2, typique d'une PME de 50-250 endpoints) impose explicitement le chiffrement des données sauvegardées au repos (CIS Control 11.3).

Gestion des clés de chiffrement : le vrai problème opérationnel

Le CSE déplace le risque vers la gestion des clés. Une clé perdue = backup irrécupérable. Les approches pratiques pour une PME de 20-100 postes :

• HSM software (ex. HashiCorp Vault auto-hébergé) : adapté à un MSP ou une équipe IT interne structurée. Requiert un opérateur dédié et une procédure de backup de la clé racine (Shamir Secret Sharing, minimum 3 sur 5 fragments).
• HSM physique : coût d'entrée CHF 3 000–8 000 par unité. Justifié pour les organisations sous supervision FINMA ou traitant des données de santé.
• Clé dérivée avec KDF (PBKDF2, Argon2) depuis un secret maître stocké hors-ligne (coffre physique + copie notariale) : solution minimaliste mais fonctionnelle pour une PME sans équipe sécurité dédiée.
• Séquestre de clé chez un tiers de confiance suisse (avocat, fiduciaire mandatée) : exigé dans certains contrats d'assurance cyber.

Menaces concrètes sur les sauvegardes cloud en 2024

Ransomware ciblant les backups cloud

Les groupes ransomware actuels (LockBit 3.0, BlackCat/ALPHV, Akira) ciblent systématiquement les sauvegardes avant de déclencher le chiffrement principal. Si les credentials d'accès au bucket S3 ou au stockage Azure sont compromis (via un agent MDR contourné, un token volé dans un fichier de config, ou un accès API sans MFA), l'attaquant peut supprimer ou corrompre les backups cloud avant que l'alerte ne soit levée. Le NCSC Suisse documente régulièrement ce vecteur dans ses rapports semestriels sur les cybermenaces.

Le CSE ne protège pas contre la suppression du bucket, mais il garantit que même un backup exfiltré avant suppression ne peut pas être monétisé (pas de double extorsion possible sur du ciphertext sans clé). C'est un levier de négociation nul pour l'attaquant.

Insider threat chez le provider

Les grands providers publient des rapports de transparence (transparency reports) indiquant le nombre de demandes gouvernementales reçues — rarement le nombre d'accès internes non sollicités. En SSE, un administrateur cloud disposant des droits KMS peut accéder à vos données sans trace dans vos logs. En CSE, cette surface d'attaque est nulle.

Supply chain du client de sauvegarde

Les agents de sauvegarde installés sur les endpoints (Veeam Agent, Acronis Cyber Protect, Duplicati) constituent eux-mêmes une surface d'attaque. En 2023, plusieurs CVE critiques ont affecté Veeam Backup & Replication (CVE-2023-27532, CVSS 7.5 ; CVE-2023-38213, CVSS 9.8). Un agent compromis peut exfiltrer les clés de chiffrement si celles-ci sont stockées en mémoire ou dans un fichier de configuration local non protégé. La politique de rotation des clés (au minimum annuelle, idéalement par cycle de backup) et le stockage des clés dans un secret store séparé de l'agent sont non négociables.

Cas pratique : fiduciaire vaudoise, 45 postes Windows 11, migration backup vers cloud

Contexte : fiduciaire basée à Lausanne, 45 employés, 12 clients PME actifs avec accès à leurs données comptables (bilans, LPP, données salariales). Parc 100 % Windows 11 23H2, Active Directory on-premise, stockage actuel sur NAS Synology avec snapshot quotidien. Budget IT annuel : CHF 85 000 dont CHF 12 000 alloués à la modernisation des sauvegardes.

Problème identifié lors d'un audit interne (02.2024) : les snapshots NAS ne sont pas répliqués hors site. En cas d'incendie ou de ransomware chiffrant le NAS, RTO estimé à 5-7 jours (reconstruction manuelle). La direction décide de migrer vers un backup cloud avec rétention 90 jours.

Procédure déployée — étape par étape :

1. Inventaire des données (DSI + juriste, semaine 1) : cartographie des flux de données personnelles dans les backups. Résultat : 3 catégories — données salariales (sensibles nLPD art. 5c), données comptables clients (confidentielles contractuellement), données opérationnelles internes. Aucune donnée de santé ni biométrique.
2. Choix du provider et de la région (DSI, semaine 1-2) : stockage retenu dans une région UE (Frankfurt) chez un provider disposant d'un DPA (Data Processing Agreement) conforme nLPD/RGPD. Rejet d'un provider US sans MCCs (Model Contract Clauses) valides.
3. Architecture de chiffrement (DSI + RSSI externe, semaine 2-3) : déploiement de Duplicati (open source, CSE natif AES-256) sur chaque poste et sur le NAS. Passphrase maître dérivée via PBKDF2-SHA256 (600 000 itérations), stockée dans un coffre KeePass chiffré séparé, copie papier en coffre physique notarial à Lausanne. Aucune passphrase stockée dans l'agent de backup ou dans un fichier en clair.
4. Test de restauration (DSI, semaine 4) : restauration complète d'un poste de test depuis le bucket cloud. RTO mesuré : 4h20 pour 180 Go. Objectif RTO contractuel client : 8h. Validé.
5. Documentation ROPA (juriste + DSI, semaine 5) : mise à jour du registre des activités de traitement (ROPA) avec le nouveau sous-traitant, les garanties contractuelles, la localisation des données, et la description du mécanisme de chiffrement. Requis par nLPD art. 12.
6. Politique de rotation des clés (RSSI externe, semaine 5) : rotation annuelle planifiée (01.03.YYYY), procédure documentée, responsable nommé. Test de restauration obligatoire après chaque rotation.
7. Formation équipe IT (DSI, semaine 6) : 2h de formation sur la procédure de récupération de clé (où est le coffre, qui a accès, escalade si perte). Procédure écrite versée dans le wiki interne.

Coût total du déploiement : CHF 4 200 (journées DSI + RSSI externe) + CHF 1 800/an (stockage cloud 2 To, rétention 90 jours, versioning activé) + CHF 0 (Duplicati open source). Total première année : CHF 6 000, soit 50 % du budget alloué. Le delta a été réinvesti dans un test d'intrusion ciblé sur l'infrastructure de backup (résultat : 0 finding critique).

Récapitulatif opérationnel

1. Cartographier avant de chiffrer : identifier quelles catégories de données personnelles (nLPD art. 5) se retrouvent dans vos backups. Sans cartographie, impossible de calibrer le niveau de protection requis.
2. Exiger le CSE par défaut : si votre outil de sauvegarde ne supporte pas le chiffrement client-side natif (AES-256-GCM minimum), changez d'outil. SSE seul ne protège pas contre l'accès provider.
3. Stocker les clés séparément de l'agent : jamais dans un fichier de config sur le même endpoint. Secret store dédié, accès restreint, audit log activé.
4. Tester la restauration trimestriellement : un backup jamais restauré est un backup non vérifié. Documentez le RTO réel, pas l'estimation marketing du provider.
5. Activer le versioning + Object Lock (WORM) côté stockage : contre la suppression par un ransomware ou un insider. Object Lock en mode Compliance (pas Governance) empêche même les admins de supprimer avant l'expiration de la rétention.
6. MFA obligatoire sur le compte cloud de stockage : les credentials d'accès au bucket sont aussi critiques que les clés de chiffrement. Phishing ou credential stuffing sur ce compte = suppression possible de tous vos backups.
7. Planifier la notification PFPDT : si un backup est compromis ou exfiltré, la procédure de notification doit être rédigée à froid, pas dans l'urgence d'un incident. Désignez le responsable, rédigez le template, testez-le lors d'un exercice de crise.
8. Vérifier la conformité du DPA avec votre provider : transfert vers un pays tiers sans garanties adéquates = violation nLPD indépendamment du chiffrement. Le chiffrement CSE réduit le risque mais ne remplace pas un DPA valide.
9. Documenter dans le ROPA : sous-traitant, localisation, mécanisme de chiffrement, base légale du transfert. Requis, contrôlable par le PFPDT sur demande.
10. Rotation des clés annuelle minimum : avec test de restauration post-rotation systématique. Une clé non rotée depuis plus de 3 ans sur un backup contenant des données RH est un risque résiduel non acceptable.

SynGuard accompagne les PME romandes dans la mise en conformité de leur gestion d'endpoints et de leurs politiques de sauvegarde, sans remplacer l'analyse juridique d'un spécialiste nLPD.

Sources

• Loi fédérale sur la protection des données (nLPD) — fedlex.admin.ch — Texte consolidé de la nLPD en vigueur depuis le 01.09.2023, articles 5, 8, 12, 24.
• Préposé fédéral à la protection des données et à la transparence (PFPDT) — Autorité de contrôle nLPD, procédures de notification et recommandations techniques.
• Centre national pour la cybersécurité (NCSC) — Rapports semestriels sur les cybermenaces, recommandations pour PME suisses, alertes ransomware.
• CIS Benchmarks — Center for Internet Security — CIS Controls v8, contrôle 11 (Data Recovery), niveaux IG1 à IG3 pour la gestion des sauvegardes.
• NIST Cybersecurity Framework (CSF 2.0) — Fonction Recover (RC), catégories de planification et test des sauvegardes dans un contexte PME.