Comment choisir un service en nuage pour les sauvegardes

Toute solution qui n'inclut pas le cryptage du côté client avec des clés détenues par le propriétaire ne répondra pas à la première exigence énoncée (protection de la propriété intellectuelle / sécurité) - tout piratage du côté serveur divulgue des données non cryptées. Cela exclut les systèmes de synchronisation en nuage tels que Dropbox, qui possèdent les clés.

Pour éviter d'héberger les importantes clés de chiffrement sur le serveur du site web, qui est également susceptible d'être piraté à un moment donné, voici ce que je ferais :

1. Serveur de sauvegarde interne sur le site du client - dispose de clés de cryptage et de clés SSH pour les deux autres serveurs.
2. Serveur hébergeant le site web - il peut s'agir d'un hôte web.
3. Serveur ou service de sauvegarde en nuage

Étape 1 : Le serveur (1) extrait la sauvegarde de (2), de sorte que la plupart des piratages du serveur du site Web ne compromettent pas les sauvegardes. Le cryptage a lieu à ce stade.

• J'utiliserais rsnapshot par SSH en utilisant une connexion basée sur une clé, car cette méthode a des exigences minimales sur l'hôte web et le serveur de sauvegarde interne - à moins que vous n'ayez une grande base de données à sauvegarder, elle est très efficace en termes de bande passante et stocke plusieurs versions du site, et gère également la purge des anciennes sauvegardes.
• Le cryptage peut être effectué par n'importe quel outil de fichier à fichier tel que GPG, en copiant l'arbre rsnapshot vers un autre arbre - ou vous pouvez utiliser la duplicité pour l'étape 2, en économisant de l'espace disque.
• Le "Pull" du serveur de sauvegarde est important - si le serveur principal (2) possède les mots de passe/clés du serveur de sauvegarde, les pirates peuvent supprimer les sauvegardes et le font parfois après avoir piraté le serveur principal (voir ci-dessous). Les pirates vraiment avancés peuvent installer des binaires SSH avec un cheval de Troie qui pourraient alors compromettre le serveur de sauvegarde, mais cela est moins probable pour la plupart des entreprises.

Étape 2 : le serveur (1) envoie les sauvegardes cryptées au serveur (3) afin de disposer d'une sauvegarde hors site. Si les sauvegardes ont été cryptées à l'étape 1, vous pouvez simplement utiliser un miroir rsync de l'arbre rsnapshot local vers le système distant.

• Duplicité serait une bonne option pour crypter directement et sauvegarder l'arbre rsnapshot non crypté sur le serveur distant. La fonction de duplicité caractéristiques est un peu différent de rsnapshot, utilisant des archives tar cryptées par GPG, mais il fournit un cryptage de sauvegarde sur l'hôte distant et ne nécessite que SSH sur cet hôte (ou il peut utiliser Amazon S3). Duplicité ne supporte pas les liens durs Donc si cela est nécessaire (par exemple pour une sauvegarde complète du serveur), il est préférable qu'un script convertisse l'arbre rsnapshot (qui supporte les liens durs) en un fichier tar (peut-être juste les fichiers qui ont >1 lien dur, qui seront assez petits) afin que duplicity puisse sauvegarder le fichier tar.
• Puisque le serveur distant n'est qu'un hôte SSH, éventuellement avec rsync, il pourrait s'agir d'un hôte web (mais d'un fournisseur d'hébergement différent et dans une autre partie du pays), ou d'un service en nuage qui fournit rsync et/ou SSH - cf. cette réponse sur les sauvegardes rsync vers le nuage pour sa recommandation de bqbackup et rsync.net, bien que je ne sois pas d'accord avec la configuration de sauvegarde mentionnée.
• Vous pouvez utiliser Amazon S3 comme serveur distant avec duplicité, ce qui vous donnerait une très bonne disponibilité, bien que cela puisse coûter plus cher pour les sauvegardes importantes.
• Les autres options pour les sauvegardes cryptées à distance sont les suivantes Boxbackup (pas tout à fait aussi mature, quelques fonctionnalités intéressantes) et Tarsnap (service commercial en nuage basé sur Amazon S3 avec une interface en ligne de commande simple, une bonne déduplication et un cryptage très poussé).
  • JungleDisk peut être une option mais je n'ai pas eu une grande expérience avec eux dans le passé et leur cryptage a quelques problèmes (de l'auteur de Tarsnap).

La sécurité de tous les différents hôtes est importante, il faut donc l'adapter au profil de sécurité du client, c'est-à-dire analyser les menaces, les risques, les vecteurs d'attaque, etc. Ubuntu Server n'est pas un mauvais départ car il bénéficie de fréquentes mises à jour de sécurité depuis 5 ans, mais il faut prêter attention à la sécurité sur tous les serveurs.

Cette configuration fournit deux sauvegardes indépendantes, dont l'une peut être un service de stockage en nuage hautement disponible, fonctionne en mode "pull" de sorte que la plupart des attaques sur le site Web ne peuvent pas détruire les sauvegardes en même temps, et utilise des outils open source éprouvés qui ne nécessitent pas beaucoup d'administration.

• Les sauvegardes indépendantes sont essentielles, car il arrive que les pirates suppriment toutes les sauvegardes en même temps qu'ils piratent le site web - dans le cas le plus récent les pirates ont détruit 4800 sites web, y compris des sauvegardes en piratant l'environnement d'hébergement web plutôt que les sites. Voir aussi cette réponse y celui-ci .
• La restauration est très facile avec rsnapshot - il y a un fichier dans chaque arbre d'instantané pour chaque fichier sauvegardé, donc il suffit de trouver les fichiers avec les outils Linux et de les rsync ou scp pour les remettre sur le site web. Si le serveur de sauvegarde sur site est indisponible pour une raison quelconque, il suffit d'utiliser duplicity pour les restaurer à partir du serveur de sauvegarde en nuage - ou vous pouvez utiliser des outils standard comme GPG, rdiff et tar pour restaurer les sauvegardes.

Puisque cette configuration utilise SSH et rsync standard, il devrait être plus facile de choisir un fournisseur approprié avec les bonnes garanties de temps de fonctionnement, une sécurité forte, etc. Vous n'avez pas besoin de vous engager dans un long contrat, et si le service de sauvegarde connaît une défaillance catastrophique, vous disposez toujours d'une sauvegarde locale et pouvez passer à un autre service de sauvegarde assez facilement.

En matière de logiciels, envisagez duplicité pour les sauvegardes incrémentielles avec cryptage asymétrique et un récepteur muet (non-cloud) comment faire ).

Je dis toujours à mes clients que la meilleure solution de sauvegarde, la moins chère et la plus efficace, est celle que vous construisez vous-même, pour vos propres besoins.

Lorsque je construis un système pour mes clients, j'utilise rsync avec des clés SSH pour gérer l'authentification entre le serveurA et le serveurB, où le serveurA contient les données à sauvegarder. La commande pour archiver et rsync les données est contenue dans un bash script dans un répertoire non accessible au web, appelé par cron toutes les H heures (24 pour quotidien, etc. etc.)

Le serveur de sauvegarde, le serveur B, doit être utilisé UNIQUEMENT pour les sauvegardes. Je conseille toujours à mes clients d'utiliser un mot de passe extrêmement long avec une authentification par clé SSH pour permettre le téléchargement des sauvegardes et la sauvegarde. Parfois, mes clients ont besoin que les sauvegardes soient sauvegardées pendant D jours, alors j'écris quelques scripts pour gérer cela (prendre les données du répertoire de sauvegarde actif, appliquer un horodatage, ajouter à une archive dans un autre répertoire).

Pour les petites entreprises / les professionnels, je recommande Le service de stockage d'Amazon .

• Contrôle des régions (les objets stockés dans une UE ne quittent jamais l'UE).
• Temps de fonctionnement de 99,9%. pour un cycle de facturation donné
• 0,150 $ par Go stocké par mois
• 0,170 $ par Go téléchargé
• Téléchargement gratuit jusqu'à juin 2010, 0,10 $ par Go par la suite.

Et l'assurance plutôt vague que "des mécanismes d'authentification sont fournis pour garantir que les données sont protégées contre tout accès non autorisé".

Bien que bluenovember soit sur la bonne voie avec S3, le système d'Amazon n'est pas vraiment une solution de sauvegarde immédiate, c'est une solution de stockage de données brutes qui nécessite toujours un système frontal pour être utilisé pour la sauvegarde, qu'il s'agisse de quelques appels API ou d'une suite complète de gestion de la sauvegarde. Quelque chose comme JungleDisk Server Edition qui utilise S3 en arrière-plan mais offre une meilleure interface pour une utilisation en tant que solution de sauvegarde, serait probablement meilleure.

En outre, JungleDisk vous offrirait un cryptage intégré, ce que vous devrez ajouter indépendamment de la façon dont vous prévoyez de vous connecter à S3/"le nuage". Ils disposent également d'un logiciel client très intéressant pour Linux.