Depuis quelques temps, nous sommes à la recherche d’un système de sauvegarde particulier. Nous avons testé une multitude de solution, allant de rsync à duplicity en passant par des projets alphas sur github et autres. Cependant, aucun ne comprend l’ensemble des spécificités que nous recherchons.
Comme nous ne sommes pas arrivés à trouver par nous même, autant élargir le scope de vision et lancer une chasse à l’homme numérique. Nos besoins sont très spécifiques et nous avons l’impression que ce type de gestionnaire n’existe pas.
Voici les grands pré-requis :
Pour établir le contexte, nous avons deux machines. La première sera appelée « serveur » et la seconde sera appelée « stockage ». Le serveur possède l’ensemble des données que nous devons sauvegarder, le stockage n’aura que des fichiers sauvegardés.
- Les sauvegardes sont chiffrées: les fichiers qui transiteront entre le serveur et le stockage ne seront que des données chiffrées. Ils seront stockés sur le stockage sous forme de containers ou fichiers chiffrés.
- Aucune connaissance de la « méthode » de chiffrement ou déchiffrement: Les logiciels ou scripts côté serveur n’auront aucune connaissance de mot de passe de chiffrement ou de la clé de déchiffrement: le logiciel de gestion des sauvegardes utilisera essentiellement la ou les clefs publiques (cryptographie asymétrique) qui serviront aux chiffrages des différentes sauvegardes.
- Déchiffrement à l’aide d’une clef privée protégée par mot de passe: La seule méthode pour ouvrir le ou les fichiers de sauvegardes sera à l’aide de la clef privée « serveur » qui ne sera ni sur le serveur ni sur le stockage et elle sera protégée par mot de passe elle-même en cas de fuite.
- Aucun fichier ou archive temporaire: Certains logiciels de sauvegardes effectuent des fichiers stockés sur le serveur le temps de la récupération. Dans ce cas de figure, il faut donc prévoir une quantité de place grandissant au nombre de données à sauvegarder. Si vous avez 200 Go de données à sauvegarder, il faudra pratiquement 200 Go de place libre en plus (sans compter les fichiers annexes)
- Sauvegarde en flux tendu: Comme sur le principe de rsync, la sauvegarde s’effectuera en transfert direct (lien avec le point précédent, cela permet de n’avoir aucun fichier ni d’archive temporaire).
- Delta de données: Si un fichier est modifié ou ajouté sur le serveur, la sauvegarde à transiter au final ne doit pas comprendre l’ensemble des données du serveur mais seulement le fichier modifié ou ajouté. (sauvegarde incrémentale ou différentielle)
- Aucun accès à la machine et aux données du serveur: Beaucoup de solutions de sauvegarde proposant une sauvegarde en flux tendu sans fichier temporaire mais demandant un accès à l’ensemble du système (par exemple via ssh). La seule vision que devrait avoir le stockage sur le serveur sera les fichiers chiffrés.
- Aucun accès en cas de piratage depuis le stockage: Si le stockage est piraté, il n’est pas possible d’accéder aux données du serveur: Que ce soit dans les fichiers de sauvegardes (chiffrés) ou en remontant vers le serveur (aucune vision des données, hormis les éléments chiffrés).
- Aucun accès en cas de piratage depuis le serveur: Si le serveur est piraté, il n’est pas possible d’accéder aux données des fichiers de sauvegardes ou pouvoir remonter vers le stockage. Certains se diront « mais à quoi cela sert-il si la personne a accès aux données du serveur ?« . Tout simplement si des fichiers ont été supprimés sur le serveur, il n’est pas possible de récupérer en forçant les fichiers de sauvegardes. Seules les personnes possédant la clef de déchiffrement pourront récupérer ces fichiers supprimés ou modifiés.
Il y a d’autres critères pour l’instant optionnels (dans un premier temps):
- Compression des données (via LZMA, GZ, …)
- Canal sécurisé entre le serveur et le stockage (via SSL, TLS, …)
- Sauvegardes temporelles: Avoir plusieurs versions d’un même fichier dans le temps.
Nous avons déjà expérimenté et développé une multitude de petites solutions (ou scripts-liens) qui nous permettent d’avoir plus ou moins cette solution, mais elle reste très bancale et souvent perfectible.
Si vous avez connaissance d’un gestionnaire permettant d’effectuer l’ensemble des ces actions, n’hésitez pas à nous contacter.
Une solution serait de faire un rsync via SSH d’une arborescence chiffrée avec encfs et son option –reverse.
Pour la sauvegarde: encfs donne une représentation chiffrée de données qui sont en clair, à partir d’une clé qui peut être protégée comme on le souhaite. C’est cette représentation chiffrée qui est envoyée sur le serveur via rsync: transfert chiffré, delta sync, versioning avec hard links pour économiser de l’espace, etc.
Pour restaurer, il suffit de monter l’arborescence chiffrée localement, par exemple via sshfs, puis de la déchiffrer avec encfs en fournissant la clé en question.
Bonjour A1,
Merci pour ta contribution,
encfs était une solution que nous avons envisagé, mais cela suppose :
1. Un accès SSH (mais on peut faire un binding http(s), ce que nous avons fait dans une version de test)
2. Que chaque répertoire que nous allons sauvegardé doit être backporté dans un encfs, envisageable dans un premier temps, impossible sur le long terme et dans des contextes particuliers
On va dire que encfs est dans le pôle de tête de ceux testés mais manque encore des fonctionnalités recherchées.
Je me demande si j’ai bien compris ^^
1/ Je ne saisis pas ce qui nécessite d’être accessible par SSH dans le cas spécifique d’un passage par encfs (outre le serveur de stockage évidemment, ou la machine à sauvegarder, suivant qui initie quoi), ni d’ailleurs en quoi c’est un problème ? SSH est sécure et propose même un multiplexage intéressant avec sslh par exemple.
2/ Il n’y a pas de « backport » à faire: encfs –reverse ne donne qu’une représentation chiffrée des données qui sont stockée en clair. C’est donc très léger, ne consomme aucun disque, c’est opérationnel instantanément, et ça fonctionne très bien (je l’utilise presque au quotidien depuis de longues années, également pour faire des sauvegardes).
Au passage, les 2 derniers points cités dans le post me semblent mutuellement exclusifs: il est nécessaire que le serveur ait accès à la machine, ou vice versa, ne serait-ce que pour déclencher les sauvegardes et/ou transférer ses dernières. Un attaquant pourra de toute façon utiliser ces canaux-là s’ils sont mal sécurisés.
D’autres solutions existent mais sont plus expérimentales, et ce n’est pas précisément le genre de chose que l’on peut souhaiter mettre en production, singulièrement pour des sauvegardes: des snapshots différentiels au niveau du système de fichier (avec ZFS ou Btrfs par exemple), chiffrés par GPG par une clé publique (la clé privé correspondante n’est sur aucune des machines), et envoyé par SSH. Moyennant de l’espace disque, un peu de scripting et de la patience, il est possible de faire peu ou prou la même chose avec rsync, d’ailleurs.
Au final, c’est une première étape importante d’établir une liste des souhaits. Pour entamer une réflexion collective, il faut aussi préciser le modèle de menace – afin de pouvoir prioritiser les souhaits – et un peu plus d’infos sur l’architecture actuelle et les ressources 🙂
A.
Salut A1,
1/ Le souci du SSH est d’avoir un accès SSH sur la machine « serveur ». C’est un pré-requis que nous voulons éviter (ni même un chroot ssh) pour éviter qu’une personne qui soit sur « storage » puisse remonter sur « serveur ». Ceci dit, avec encfs rien n’empêche de « binder » la partie chiffrer vers ftp ou https.
2/ Tu as raison, c’est pour cela que encfs était dans le top des solutions possibles, il a été recalé pour de multiples raisons (dont notamment l’utilisation d’un cryptographie symétrique et l’obligation d’avoir la clef en clair si on veut automatiser cela, que ce soit en automount ou mount via script. Après, si le mount est down, rien n’empêche de venir se connecter une fois de temps à autres pour remonter la partition à la mano). Pour l’instant, encfs est l’une des seuls solutions plus ou moins viables pour la partie « chiffrement / accessibilité »
> Au passage, les 2 derniers points cités dans le post me semblent mutuellement exclusifs
On savait que ce point allait faire tiquer car trop généraliste. Le « ne pas avoir accès à » ne veut pas dire ne pas avoir accès à certains services, nous voulions parler d’un accès type SSH.
> D’autres solutions existent mais sont plus expérimentales, et ce n’est pas précisément le genre de chose que l’on peut souhaiter mettre en production, singulièrement pour des sauvegardes: des snapshots différentiels au niveau du système de fichier (avec ZFS ou Btrfs par exemple), chiffrés par GPG par une clé publique (la clé privé correspondante n’est sur aucune des machines), et envoyé par SSH. Moyennant de l’espace disque, un peu de scripting et de la patience, il est possible de faire peu ou prou la même chose avec rsync, d’ailleurs.
C’est plus ou moins des solutions que nous avons mis en place (plusieurs versions en fait, à base de rsync, wget, curl, index metadatas pour les changements, de gros scripts bien baveux, des accès spécifiques pour accéder aux backups, une version utilisant duplicity, etc…). En fait, à chaque fois que nous tirions une feature dans un sens, nous perdions une autre dans l’autre.
> Au final, c’est une première étape importante d’établir une liste des souhaits. Pour entamer une réflexion collective, il faut aussi préciser le modèle de menace – afin de pouvoir prioritiser les souhaits – et un peu plus d’infos sur l’architecture actuelle et les ressources 🙂
C’est pour cela que nous lançons cette étude avant d’éventuellement passer à une solution plus radicale: un développement spécifique 🙂
Merci encore pour ta contribution
UPDATE:
On vient de me susurrer à l’oreille que ecryptfs permettrait -peut-être- de faire cela avec clefs asymétriques.
UPDATE 2:
ecryptfs n’a pas de mode « reverse ». Impossible d’avoir ce mode sauf en bidouillant à mort. 🙁
OK, je comprends mieux.
Puisqu’il faudra de toute façon que quelque chose écoute sur le serveur ou sur la machine de sauvegarde, autant exposer un SSH bien protégé et bien connu plutôt qu’un autre service plus exotique et moins sécure, voire pire: développé spécifiquement. Dans ce dernier cas, la confidentialité sera à conquérir, la disponibilité à éprouver, l’intégrité à tester, et la restauration à prier: ça me semble la plus grosse erreur à faire, surtout pour quelque chose d’aussi essentiel que des sauvegardes.
Surtout qu’il est possible de protéger SSH en obligeant une authentification par clé uniquement et une écoute sur un port non standard, voire de supprimer tout accès au shell et de limiter tout accès à un couple utilisateur/adresse IP, éventuellement après un port-knocking, le tout surveillé par fail2ban. Il est même possible d’associer la clé éventuelle à une action spécifique via un authorized_key ad hoc. Ça se décline à l’infini et les guides sont légions.
Si vous tenez absolument au delta sync, le plus simple de très loin me semble être un ZFS ou Btrfs send/receive avec SSH pour l’envoi et GPG pour le chiffrement. Toute autre solution rajoute une ou des couches de complexité et/ou de lenteur qui, le jour J, risquent de ne pas marcher. Le risque de trop vouloir pousser le curseur de la confidentialité est de se retrouver en indisponibilité, alors que c’est précisément la disponibilité l’objectif d’une sauvegarde. Alternativement, si vous pouvez/acceptez de faire une croix sur le delta sync, un bête tar avec GPG fait très bien l’affaire.
A.
> plutôt qu’un autre service plus exotique et moins sécure
C’est pour cela que nous avons et voulons écarter cette solution le plus possible.
Faire un service supplémentaire, c’est finalement réinventer une roue (très) probablement moins sécure.
> Surtout qu’il est possible de protéger SSH en obligeant une authentification par clé uniquement et une écoute sur un port non standard, voire de supprimer tout accès au shell et de limiter tout accès à un couple utilisateur/adresse IP, éventuellement après un port-knocking, le tout surveillé par fail2ban. Il est même possible d’associer la clé éventuelle à une action spécifique via un authorized_key ad hoc. Ça se décline à l’infini et les guides sont légions.
Le souci, c’est que tout ceci donne un accès à la machine (sauf pour la suppression du shell) à la machine via « stockage ».
Même en rajoutant une clef, changement de port, filtrage ip, etc…, une personne mal-intentionnée sur « stockage » pourra remonter le chemin. Le seul moyen serait d’avoir une sorte de pseudo-programme à la place du shell qui ne donne que ce qu’on veut bien donner ou … un chroot-ssh.
> Alternativement, si vous pouvez/acceptez de faire une croix sur le delta sync, un bête tar avec GPG fait très bien l’affaire.
C’était une éventualité durant la phase de prototype (ou de bidouillage avec les outils actuels).
mais malheureusement, après plusieurs essais, impossible de faire l’impasse sur ce delta-sync 🙁
Pour ZFS/BRTFS, c’est une possibilité, mais bloqué par le fait que ce soit un FS :-\
Impossible de faire cela en production sans tout casser (ou alors y’a une solution sympathique)
Un jour, je vais arriver à cliquer sur « répondre »…
> pseudo-programme à la place du shell qui ne donne que ce qu’on veut bien donner
C’est ce que je voulais dire par un « authorized_keys ad hoc », cf. par exemple http://cybermashup.com/2013/05/14/restrict-ssh-logins-to-a-single-command/
Si vous avez la trouille de mettre un SSH sur vot’ serveur, peut-être qu’il vaut mieux laisser d’autres personnes plus qualifié faire son administration, non ? 😀
Plus sérieusement: 1/ le backup fait partie de la sécu, 2/ la sécu ne s’improvise pas, 3/ on doit choisir entre le beurre et l’argent du beurre, 4/ il faut donc prioritiser, 5/ prendre la meilleure décision, 6/ tant que faire se peut mitiger ses effets de bords, 7/ l’implémenter, 8/ surveiller, 9/ reprendre à 2/, suivant les priorités qui peuvent changer, ainsi que les menaces, ainsi que les technos, ainsi que les personnes, etc.
A, taquin
> Si vous avez la trouille de mettre un SSH sur vot’ serveur, peut-être qu’il vaut mieux laisser d’autres personnes plus qualifié faire son administration, non ? ?
Heu, on va commencer à mal le prendre (ou alors c’est du second degrés) :-\
Ce n’est pas parce que Lea-linux s’adresse aux débutants que ceux qui sont aux commandes (CM, rédacteur, direction) le sont forcément.
Si nous recherchons une solution à ce sujet, c’est justement car quasiment aucun logiciel de sauvegardes ne possède l’ensemble du spectre sécuritaire que nous voulons. Certains s’en rapproche, d’autres carrément pas mais sont potentiellement une brique pouvant faire affaire.
Personne n’empêchera un hack sur un hôte (serveur ou autres) qui permettra de remonter potentiellement sur une autre machine et ainsi de suite. Nous considérons chaque hôte, chaque service, chaque ouverture, chaque fichier temporaire comme une faille potentielle.
Notre priorité est la sécurité des données avant tout
Aucune ambiguïté: c’était 100% second degré 🙂
Pour avoir pas mal creusé la question par le passé, mon analyse était que si le logiciel idéal n’existait pas, c’était parce que les souhaits étaient incompatibles entre eux: il est tout simplement impossible de pousser au maximum les différents critères de sécurité, car ils sont tous interdépendants et imposent des compromis 🙂
Bonne chance dans cette recherche, ça vaudra la peine de faire un billet une fois une décision prise 🙂
A.
Merci pour tes retours 🙂
Nous reviendrons après une période d’étude et de réflexion 🙂
Par exemple, le couplage deltas/crypto asymétrique est pour moi impossible : pour transmettre seulement ce qui a changé, autant faut-il savoir ce qui a changé. Et pour savoir ce qui a changé, il faut bien savoir ce qui est sur le serveur, d’où l’incompatibilité (pour moi) sans passer par comme c’était suggéré, des implémentations au niveau du FS.
Try BorgBackup 😉
https://borgbackup.readthedocs.org/en/stable/
Bonjour Ana,
Merci pour votre retour.
BorgBackup fait partie de la liste « testé », mais recalé car il nécessite de l’espace libre (beaucoup) pour opérer ses archives.
« Before you start creating backups, please make sure that there is always a good amount of free space on the filesystem that has your backup repository (and also on ~/.cache). It is hard to tell how much, maybe 1-5%. »
Je vous conseille Crashplan. Rempli l’ensemble de vos critères y compris optionnels.
C’est gratuit sauf si vous sauvegardez dans le cloud Code42 (c’est l’éditeur).
Par contre la version gratuit ne tourne que toute les 24H. Pour du temps réel il faut payer.
Je l’utilise depuis 5 ans et les restaurations ont toujours fonctionné.
Bonjour Thomas,
Merci pour votre retour. Effectivement, en regardant rapidement le site et la page Wikipedia, il semble que ce projet respecte assez bien les périmètres recherchés (crypto, transfert, etc…). Une question vu que vous l’utilisez, comment s’effectue les sauvegardes ?
Je suppose que c’est un programme au sein du serveur qui effectue le backup puis transfert vers un serveur distant ? (vu que l’éditeur à un Cloud).
Dans les grandes lignes c’est une sauvegarde par block. Tous les fichiers sont découpés en block et donc cela permet : la dé-duplication, la sauvegardes des très gros fichiers, la sauvegardes intelligentes de gros fichiers qui changent peu.
Pas de fichier temporaire.
Tout est paramétrable (fréquences, versions, …) simplement et automatique.
Par exemple faire la sauvegarde initiale sur un disque externe, la copier sur la machine destination => resynchro automatique pour ne transférer que le delta. Pratique pour les sauvegardes hors site avec une petit connexion Internet. Multi-destination possible.
Comme je dis souvent c’est le soft de sauvegarde que tout développeur rêverait d’avoir crée : simple et puissant.
Quelques écrans sur http://faitesdessauvegardes.fr/crashplan.htm
Pour préciser toutes les machines qui exécutent crashplan peuvent être une cible de sauvegarde. Le port TCP est paramétrable.
1 machine = sauvegarde sur un disque local ou dans le cloud crashplan (payant)
2 machines = sauvegarde 1 2 plus disque local plus cloud
etc…
A tester sans modération, très simple. Et pour couronner le tout un très bon service client (in english).
Bonjour à tous,
J’ai exactement rechercher un outil avec les besoins que vous. Je suis tombé sur rclone, solution très interessante et qui fonctionne avec la plupart des solutions de stockage cloud du marcher:
http://rclone.org/
Seul bémol la vitesse, mais après la première sauvegarde complète c’est de l’incrémental.
Bonnes fêtes