Toutes les solutions de sauvegarde annoncent du chiffrement. C'est devenu une case à cocher, au même titre que « conforme RGPD ». Or derrière le même mot se cachent des modèles qui ne protègent pas contre les mêmes menaces.
La question utile n'est pas « est-ce chiffré ? » mais « qui détient la clé, et où le déchiffrement est-il possible ? »
Trois modèles, trois périmètres
Chiffrement en transit
Les données circulent en TLS entre la machine sauvegardée et le serveur. C'est le minimum absolu, et personne n'y déroge plus.
Protège contre : l'écoute réseau. Ne protège pas contre : tout ce qui arrive une fois les données arrivées.
Chiffrement au repos, côté serveur
Les données sont chiffrées sur le disque du serveur de sauvegarde. La clé est détenue par le serveur, qui chiffre en écriture et déchiffre en lecture.
Protège contre : le vol physique d'un disque, la mise au rebut d'un matériel, un accès direct au stockage. Ne protège pas contre : quiconque obtient un accès au serveur — puisque le serveur, lui, a la clé. C'est aussi vrai pour un administrateur légitime que pour un attaquant.
C'est le modèle le plus répandu, et il est souvent présenté simplement comme « chiffrement AES-256 », ce qui est exact mais incomplet.
Chiffrement à la source
Les données sont chiffrées sur la machine sauvegardée, avant de partir, avec une clé qui ne quitte jamais cette machine. Le serveur ne reçoit et ne stocke que des blocs inintelligibles.
Protège contre : le vol de disque, la compromission du serveur, la curiosité d'un hébergeur, celle d'un prestataire, celle de l'éditeur. Ne protège pas contre : une compromission de la machine elle-même, où les données sont de toute façon en clair.
La vérification d'intégrité sans la clé
Une objection technique légitime : si le serveur ne peut pas déchiffrer, comment vérifie-t-il que les données ne s'altèrent pas avec le temps ?
La réponse tient à l'endroit où l'on calcule les empreintes. Si chaque bloc porte ses propres empreintes, avant et après compression, le serveur peut relire un bloc, recalculer son empreinte, la comparer à celle enregistrée, et conclure que le bloc est intact — sans jamais savoir ce qu'il contient.
C'est ce qui permet de concilier deux exigences qu'on croit souvent incompatibles : la confidentialité absolue vis-à-vis de l'hébergeur, et le contrôle d'intégrité côté serveur.
Ce que ça change en cas de violation de données
C'est ici que le modèle a des conséquences très concrètes, et pas seulement techniques.
Le RGPD impose de notifier une violation à l'autorité de contrôle sous 72 heures (article 33), et d'informer les personnes concernées lorsque la violation est susceptible d'engendrer un risque élevé pour leurs droits et libertés (article 34).
L'article 34 prévoit explicitement que cette communication aux personnes n'est pas nécessaire si le responsable de traitement a mis en œuvre des mesures rendant les données incompréhensibles à toute personne non autorisée — le chiffrement étant cité comme exemple.
Traduction pratique : si un serveur de sauvegarde est compromis et que les données étaient chiffrées à la source, la clé n'ayant jamais transité ni résidé sur ce serveur, le risque pour les personnes est considérablement réduit. Cela pèse directement sur l'obligation de notifier chaque personne concernée — et sur la nature de la conversation que vous aurez avec votre client.
Avec un chiffrement au repos côté serveur, l'attaquant qui a compromis le serveur a aussi la clé. L'argument ne tient plus.
Ceci décrit un principe, pas une dispense automatique. L'analyse d'une violation reste à mener au cas par cas, avec votre conseil ou votre DPO.
La contrepartie, qu'il faut assumer
Un chiffrement dont la clé reste chez le client a une conséquence non négociable : si la clé est perdue, les données le sont aussi. Personne ne peut la régénérer. Ni l'éditeur, ni l'hébergeur, ni vous.
Ce n'est pas un défaut : c'est exactement la même propriété, vue de l'autre côté. Une solution capable de vous redonner accès à vos données sans votre clé est, par construction, capable d'y accéder sans vous.
Il faut donc traiter la conservation de la clé de récupération comme une tâche d'exploitation à part entière :
- Conservée ailleurs que sur la machine sauvegardée. Une clé stockée sur le serveur qu'elle protège ne protège rien.
- Dans un coffre-fort de mots de passe, avec un accès tracé et au moins deux personnes habilitées.
- Vérifiée : une clé qu'on n'a jamais essayée est une hypothèse. Un test de restauration la valide au passage.
- Documentée dans la procédure de reprise, pas dans la mémoire de celui qui a installé.
Pour un prestataire qui gère plusieurs dizaines de clients, cela vaut d'être organisé avant le premier déploiement, pas après le cinquantième.
Les questions à poser à un éditeur
Quatre suffisent à situer n'importe quelle solution :
- Où le chiffrement a-t-il lieu ? Sur la machine sauvegardée, ou sur le serveur ?
- La clé transite-t-elle sur le réseau ? Si oui, elle est sortie du périmètre de confiance.
- Le serveur peut-il vérifier l'intégrité sans déchiffrer ? La réponse révèle la conception réelle.
- Que se passe-t-il si je perds la clé ? Si l'éditeur peut vous dépanner, c'est qu'il peut lire vos données.
La quatrième est la plus révélatrice, et la moins souvent posée.
Chez BeBackup, le chiffrement AES-256 a lieu sur le poste, la clé ne transite jamais, et le serveur ne détient que son empreinte. Voir la page sécurité ou demander une démo.