Quelle couche de sauvegarde doit gérer les clés de chiffrement : le client, le référentiel ou la cible hors site ?
Pour la plupart des sauvegardes de serveurs domestiques, l’application ou le client de sauvegarde devrait contrôler le chiffrement nécessaire pour lire la sauvegarde, tandis que le chiffrement du fournisseur de stockage hors site devrait être considéré comme une couche supplémentaire. Cela empêche qu’une compromission du cloud ou du stockage distant expose automatiquement le contenu des sauvegardes, tout en conservant un format de sauvegarde capable d’effectuer efficacement la déduplication, la vérification et la restauration des données.
La distinction importante n’est pas simplement celle entre « chiffrement côté client » et « chiffrement côté serveur ». Vous devez décider quel domaine de défaillance détient le secret de déchiffrement. Si la seule clé existe sur le serveur source, une source hors service ou chiffrée par un rançongiciel peut rendre la récupération impossible. Si la cible hors site détient la seule clé réellement utile, l’opérateur de la cible ou un compte cible compromis peut rester dans le périmètre de confiance. La meilleure conception sépare les données de sauvegarde, les identifiants du dépôt et les clés de récupération.
Le chiffrement peut être placé à trois endroits différents
L’expression « sauvegarde chiffrée » recouvre plusieurs architectures. Les fichiers source peuvent être chiffrés avant d’être pris en charge par l’outil de sauvegarde. L’outil de sauvegarde peut chiffrer le format de son dépôt avant d’envoyer les objets vers un stockage local ou distant. Ou bien le système de stockage de destination peut recevoir les données et les chiffrer au repos à l’aide de sa propre couche de gestion des clés.
| Couche | Qui effectue le chiffrement ? | Qui doit détenir un secret de récupération ? | Atout principal | Faiblesse principale |
|---|---|---|---|---|
| Pré-chiffrement côté client | Application source ou outil de chiffrement | Propriétaire de la clé côté client/utilisateur | Séparation forte du dépôt de sauvegarde et du fournisseur | Peut réduire la déduplication optimisée pour les sauvegardes, la visibilité des métadonnées et la simplicité des restaurations granulaires |
| Chiffrement du dépôt de sauvegarde | Logiciel de sauvegarde avant le stockage | Détenteur de la clé ou de la phrase secrète du dépôt | Meilleur équilibre entre confidentialité et fonctionnalités de sauvegarde | La perte de la clé ou de la phrase secrète peut rendre tout le dépôt illisible |
| Chiffrement de la cible hors site | Service cloud/NAS/de stockage | Clé de la cible gérée par le fournisseur, le KMS ou le client | Protection simple des données au repos | La cible reste dans le périmètre de confiance du déchiffrement |
Le chiffrement au niveau du dépôt est généralement le meilleur choix par défaut
Les outils de sauvegarde modernes sont conçus pour chiffrer les données dans le cadre du format du dépôt. La documentation sur le chiffrement de Restic considère le chiffrement comme une fonctionnalité essentielle du dépôt et prend en charge plusieurs clés d’accès ou mots de passe. Kopia décrit de façon similaire ses dépôts comme ajoutant le chiffrement et la déduplication à des systèmes de stockage tels que les systèmes de fichiers, S3 et les stockages d’objets cloud.
Borg rend le modèle de confiance particulièrement explicite. Sa documentation de sécurité part du principe que l’environnement client est fiable et que le dépôt peut être hostile. Borg chiffre les données localement afin qu’un dépôt distant ne reçoive ni les fichiers en clair ni la clé de sauvegarde non chiffrée.
Ce modèle est particulièrement intéressant pour un NAS domestique, car l’application de sauvegarde peut toujours voir les fichiers d’origine lors de la création de la sauvegarde. Elle peut effectuer le découpage en blocs, la déduplication, la compression, la gestion des métadonnées des instantanés, la vérification et les restaurations sélectives avant ou pendant le chiffrement. La cible de stockage reçoit des objets de dépôt chiffrés plutôt que des fichiers ordinaires lisibles.
Ne confondez pas la clé du dépôt avec l’identifiant de stockage
Une clé d’accès à un compartiment cloud, une clé privée SFTP, un mot de passe NAS distant et une clé de déchiffrement de sauvegarde sont des secrets différents, même si un script d’automatisation a besoin de chacun d’eux. L’identifiant de stockage répond à la question « ce client peut-il lire ou écrire les objets du dépôt ? » La clé du dépôt répond à la question « ces objets peuvent-ils être déchiffrés pour produire les données de sauvegarde ? »
Les séparer est important lors d’un incident. Un attaquant qui vole un identifiant de compartiment autorisé en écriture ne devrait pas obtenir automatiquement le secret de déchiffrement du dépôt. À l’inverse, la possession de la phrase secrète de sauvegarde ne devrait pas nécessairement accorder l’accès administratif au compte de stockage hors site.
Le guide de ZimaSpace sur la vérification de chaque clé requise pour une restauration chiffrée constitue un complément utile, car il cartographie séparément l’accès au dépôt, le chiffrement des sauvegardes, le stockage de destination, les secrets des conteneurs et les secrets au niveau des applications en tant que dépendances distinctes de récupération.
Le chiffrement côté client est idéal pour les données sensibles ciblées
Chiffrer les fichiers avant que l’application de sauvegarde ne les lise peut être pertinent lorsqu’un jeu de données précis doit rester opaque, même pour les outils de sauvegarde habituels ou les administrateurs. Cela peut concerner une petite archive juridique, une base de données de mots de passe exportée, un ensemble de clés privées ou un conteneur chiffré contrôlé par le client.
Le compromis est qu’un chiffrement effectué trop tôt peut masquer une structure dont le système de sauvegarde aurait autrement tiré parti. Si chaque fichier modifié devient une sortie chiffrée complètement différente, la compression et la déduplication peuvent devenir moins efficaces. La navigation granulaire dans les fichiers peut également se transformer en restauration en deux étapes : récupérer d’abord l’objet chiffré, puis le déverrouiller avec un autre outil.
Pour cette raison, le préchiffrement de l’ensemble des données est généralement une architecture de sauvegarde domestique par défaut moins solide que l’utilisation d’un outil de sauvegarde doté d’un chiffrement natif et authentifié des dépôts. Utilisez-le lorsque vous avez délibérément besoin d’une seconde limite de confiance autour d’un sous-ensemble de données.
Le chiffrement côté serveur hors site protège le stockage, pas l’intégralité du modèle de confiance des sauvegardes
Les stockages d’objets cloud chiffrent généralement les données au repos. Amazon S3, par exemple, applique par défaut un chiffrement côté serveur et prend en charge les clés KMS gérées par AWS ou par le client. Sa documentation SSE-KMS explique comment S3 effectue le chiffrement à destination, tandis qu’AWS KMS contrôle les clés et les autorisations.
Backblaze B2 prend également en charge le chiffrement SSE-B2 géré par le fournisseur et le chiffrement SSE-C géré par le client. Sa documentation sur le chiffrement côté serveur précise que le chiffrement SSE protège les données des fichiers au repos et que la perte d’une clé SSE-C gérée par le client rend les données irrécupérables.
Le chiffrement côté serveur est précieux. Il contribue à protéger les supports physiques et l’infrastructure de stockage, et les politiques KMS gérées par le client peuvent instaurer des contrôles organisationnels solides. Mais si le service cible peut déchiffrer les données dès qu’une requête de stockage autorisée est reçue, il se trouve toujours à l’intérieur de la limite de confidentialité. Cela diffère du téléversement d’un dépôt Borg, restic ou Kopia déjà chiffré avant d’atteindre le fournisseur.
Utiliza el cifrado externo como defensa en profundidad
La respuesta práctica suele ser «ambos». Deja que la aplicación de copia de seguridad cifre el contenido del repositorio antes de subirlo y mantén activado el cifrado normal del destino en reposo como otra medida de protección. Las dos capas protegen frente a eventos distintos.
| Fallo o amenaza | Cifrado del repositorio | Cifrado del lado del servidor del destino |
|---|---|---|
| Exposición del disco o medio en la nube | Protege el contenido | Protege el contenido |
| El proveedor de almacenamiento puede leer los objetos autorizados | Puede mantener al proveedor fuera del límite de confianza del texto sin formato | Por lo general, no por sí sola |
| Credencial del bucket robada | Los datos pueden seguir siendo ilegibles sin la clave del repositorio | Las lecturas autorizadas aún pueden activar el descifrado |
| Pérdida de la frase de contraseña o clave de la copia de seguridad | Puede hacer que el repositorio sea irrecuperable | No recupera la clave del repositorio |
| Pérdida de la clave de almacenamiento gestionada por el proveedor | La capa del repositorio no puede solucionar la indisponibilidad de los datos de destino | Se aplica la política de recuperación del proveedor/KMS |
La clave debe sobrevivir a la máquina que protege
La regla más importante sobre la ubicación de las claves es sencilla: no guardes la única copia de recuperación del secreto de cifrado en el servidor del que se realiza la copia de seguridad. La guía actual de inicialización de repositorios de Borg recomienda explícitamente guardar una copia de seguridad de la clave de Borg fuera tanto del repositorio como del sistema que crea las copias de seguridad.
La misma lógica se aplica a las contraseñas de restic, las contraseñas de repositorio de Kopia, las claves age, el material de recuperación de LUKS, la administración de KMS en la nube y las claves maestras de las aplicaciones. Un repositorio cifrado a la perfección no sirve de nada si el único secreto de descifrado desaparece junto con la unidad de arranque averiada.
En un hogar o laboratorio pequeño, conserva al menos una copia de recuperación sin conexión o en un sistema de credenciales independiente que no dependa de que el NAS esté operativo. Después, prueba una restauración en un equipo limpio. Una contraseña escrita que nunca se haya utilizado para abrir el repositorio demuestra que existe documentación, no que la recuperación sea posible.
¿Qué capa debería gestionar la clave en los diseños habituales de servidores domésticos?
NAS doméstico con copia de seguridad en almacenamiento de objetos
Utiliza el cifrado nativo del repositorio en restic, Borg, Kopia o una herramienta de copia de seguridad comparable antes de que los datos salgan del NAS. Guarda la clave o la frase de contraseña del repositorio fuera del NAS. Mantén activado el cifrado del bucket como defensa en profundidad. Así, el destino en la nube no será el único control de confidencialidad.
NAS domestico con copia de seguridad en el servidor remoto de un amigo
Privilégiez un chiffrement côté client ou du dépôt dont la clé permettant d’obtenir les données en clair ne réside pas sur le serveur de votre ami. L’hôte distant peut stocker des objets de dépôt opaques et appliquer des autorisations d’écriture limitées. Cela est particulièrement utile, car le contrôle physique et administratif de la machine distante appartient à un autre domaine de défaillance.
Disque de sauvegarde local stocké dans la même maison
Le chiffrement du dépôt protège malgré tout la confidentialité en cas de perte ou de vol du disque. Le chiffrement intégral du disque de sauvegarde peut constituer une seconde couche utile, mais ne laissez pas la clé de déverrouillage du disque devenir l’unique moyen d’accéder au dépôt de sauvegarde.
Sauvegarde cloud gérée avec fonctionnalités de récupération par le fournisseur
Le chiffrement géré par le fournisseur peut être pertinent lorsque la simplicité et la récupération assistée par le fournisseur sont plus importantes que le fait de maintenir le fournisseur en dehors de la frontière de confiance des données en clair. Comprenez qu’il s’agit d’une décision de sécurité différente de celle d’un chiffrement côté client de type « à connaissance nulle ».
Ne stockez pas tous les secrets de sauvegarde dans un seul fichier d’automatisation
Une tâche de sauvegarde sans surveillance a besoin d’identifiants, mais la commodité peut fragiliser vos frontières de sécurité. Les recommandations de restic pour l’automatisation avertissent que le mode de transmission des mots de passe peut exposer les identifiants et préconisent de protéger soigneusement les fichiers de mots de passe.
Sur un serveur domestique, séparez au minimum ces rôles lorsque cela est possible :
- Un identifiant aux privilèges strictement limités permettant d’accéder à la destination des sauvegardes.
- Le mot de passe ou la clé de déchiffrement du dépôt.
- Une copie hors ligne du mot de passe ou de la clé de récupération.
- Les identifiants administrateur permettant de supprimer des politiques de rétention, des compartiments ou des comptes distants.
Cette distinction est plus importante que le choix de stocker un secret donné dans un fichier, une variable d’environnement, un gestionnaire de mots de passe, un jeton matériel ou un KMS. L’architecture doit empêcher qu’un seul identifiant d’automatisation volé puisse simultanément lire les données en clair, supprimer le dépôt et détruire l’unique clé de récupération.
Le chiffrement ne remplace ni l’immuabilité ni les tests de restauration
La confidentialité, l’intégrité, la résistance à la suppression et la récupérabilité sont des objectifs distincts. Un dépôt chiffré peut tout de même être supprimé. Un compartiment immuable peut tout de même contenir des sauvegardes dont la clé de déchiffrement a été perdue. Une tâche de sauvegarde terminée avec succès peut tout de même échouer lors de la restauration.
La comparaison de ZimaSpace entre un serveur de sauvegarde distant et le stockage objet cloud pour les sauvegardes de machines virtuelles aboutit à la même conclusion opérationnelle : le libellé de la cible compte moins que le fait d’avoir testé une véritable récupération.
Matrice de décision
| Priorité | Détenteur des clés privilégié |
|---|---|
| Empêcher l’administrateur du cloud ou du site distant d’accéder aux données en clair | Client ou référentiel de sauvegarde chiffré |
| Préserver la déduplication et les restaurations adaptées aux sauvegardes | Chiffrement natif du référentiel |
| Complexité opérationnelle minimale | Chiffrement de la cible géré par le fournisseur, avec une limite de confiance plus large |
| Défense en profondeur robuste | Chiffrement du référentiel + chiffrement côté serveur de la cible |
| Protéger séparément un très petit sous-ensemble ultra-sensible | Pré-chiffrement côté client + sauvegarde normale dans le référentiel |
| Reprise après sinistre à la suite de la perte de la source | Tout modèle disposant d’une copie de récupération indépendante et testée de la clé |
Verdict final
Pour la plupart des systèmes de sauvegarde auto-hébergés, laissez au client de sauvegarde ou au format du référentiel la responsabilité de la limite de chiffrement du contenu, et laissez la cible hors site chiffrer à nouveau les données au repos. Cela préserve les fonctionnalités de sauvegarde telles que la déduplication et la vérification, tout en réduisant la confiance à accorder au système de stockage distant pour l’accès aux données en clair.
Le plan de gestion des clés n’est complet que lorsque le secret de déchiffrement survit à la perte du serveur source, de la cible de stockage et du poste de travail habituel de l’administrateur. Testez cette hypothèse depuis une machine vierge avant de considérer la sauvegarde comme récupérable.
FAQ
Le chiffrement côté serveur du cloud suffit-il pour les sauvegardes domestiques ?
Il protège les données au repos, mais il maintient généralement le service de stockage dans la limite de confiance du déchiffrement. Utilisez également le chiffrement natif de la sauvegarde lorsque vous ne voulez pas que le fournisseur ou un identifiant de stockage volé suffise à accéder aux données en clair.
La clé du référentiel doit-elle être stockée dans le référentiel ?
Certains formats de sauvegarde stockent un objet de clé chiffré dans le référentiel, mais la récupération dépend toujours d’un autre secret, tel qu’une phrase secrète robuste. Conservez le matériel de récupération indépendant en dehors du référentiel et du système source.
Le chiffrement des fichiers avant la sauvegarde améliore-t-il la sécurité ?
Cela peut créer une limite de confiance supplémentaire pour les sous-ensembles sensibles, mais chiffrer tout le contenu avant que l’outil de sauvegarde ne le traite peut réduire la déduplication, la compression, la visibilité des métadonnées et la simplicité de restauration.
Quel est le test de gestion des clés le plus important ?
Restaurer depuis une machine vierge après avoir supposé que le NAS d’origine est totalement indisponible. Si vous ne pouvez pas retrouver tous les identifiants et déchiffrer des données représentatives, le plan de gestion des clés est incomplet.
Produits recommandés
Comparaisons de produits
Plus à lire
Home Assistant peut-il remplacer openHAB pour contrôler tous les appareils de la maison ?
Home Assistant ne peut remplacer openHAB que lorsque chaque appareil et automatisation essentiels a réussi un test parallèle de migration et de restauration.
Mini-PC vs serveur monocarte vs NAS pour Home Assistant
Choisissez un ordinateur monocarte pour un appareil compact et économe, un mini-PC pour davantage de flexibilité et de marge de puissance, ou un NAS...
Comment choisir entre un serveur Home Assistant dédié et un hébergeur d’applications partagé
Choisissez un hébergement dédié pour une isolation des pannes plus simple ; choisissez un hébergement mutualisé lorsque l’isolation, les fenêtres de maintenance et la...
