Toute solution qui n'inclut pas le chiffrement côté client avec des clés détenues par le propriétaire ne répondra pas à la première exigence énoncée (protection / sécurité IP) - tout piratage côté serveur révèle des données non chiffrées. Cela exclut les systèmes de synchronisation dans le cloud tels que Dropbox qui possèdent les clés.
Pour éviter d'héberger les clés de cryptage très importantes sur le serveur du site Web, qui est également susceptible d'être piraté à un moment donné, voici ce que je ferais:
- Serveur de sauvegarde interne sur le site du client - possède des clés de chiffrement et des clés SSH pour les deux autres serveurs
- Serveur hébergeant le site Web - pourrait être un hébergeur
- Serveur ou service de sauvegarde cloud
Étape 1: le serveur (1) extrait la sauvegarde de (2), de sorte que la plupart des hacks du serveur du site Web ne compromettent pas les sauvegardes. Le cryptage a lieu à ce stade.
- J'utiliserais rsnapshot sur SSH en utilisant une connexion basée sur des clés, car cela 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 bande passante et stocke plusieurs versions du site, et gère également la purge des anciennes sauvegardes.
- Le chiffrement peut être effectué par n'importe quel outil de fichier à fichier tel que GPG, en copiant l'arborescence rsnapshot dans une autre arborescence - ou vous pouvez utiliser la duplicité pour l'étape 2, économiser de l'espace disque.
- "Extraire" du serveur de sauvegarde est important - si le serveur principal (2) possède les mots de passe / clés pour le serveur de sauvegarde, les pirates peuvent et parfois supprimeront les sauvegardes après avoir piraté le serveur principal (voir ci-dessous). Des hacks vraiment avancés peuvent installer des binaires SSH troyens qui pourraient alors compromettre le serveur de sauvegarde, mais c'est moins probable pour la plupart des entreprises.
Étape 2: le serveur (1) pousse les sauvegardes chiffrées vers (3) pour qu'il y ait une sauvegarde hors site. Si les sauvegardes ont été chiffrées à l'étape 1, vous pouvez simplement utiliser un miroir rsync de l'arborescence rsnapshot locale sur le système distant.
- La duplicité serait une bonne option pour crypter et sauvegarder directement l'arborescence rsnapshot non cryptée sur le serveur distant. Les fonctionnalités de Duplicity sont un peu différentes de rsnapshot, utilisant des archives tar chiffrées par GPG, mais il fournit un chiffrement de sauvegarde sur l'hôte distant et ne nécessite que SSH sur cet hôte (ou il peut utiliser Amazon S3). Duplicity ne prend pas en charge 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'arborescence rsnapshot (qui prend en charge les liens durs) en un fichier tar (peut-être juste les fichiers qui ont> 1 lien dur, qui sera assez petit) pour que la duplicité puisse sauvegarder le fichier tar.
- Étant donné que le serveur distant n'est qu'un hôte SSH, éventuellement avec rsync, il peut 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 cloud qui fournit rsync et / ou SSH - voir cette réponse sur les sauvegardes rsync sur le cloud 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é, mais cela coûterait peut-être plus cher pour les sauvegardes volumineuses.
- D'autres options pour les sauvegardes chiffrées à distance sont Boxbackup (pas aussi mature, quelques fonctionnalités intéressantes) et Tarsnap (service cloud commercial basé sur Amazon S3 avec une interface de ligne de commande simple, une bonne déduplication et un chiffrement très complet).
La sécurité de tous les différents hôtes est importante, elle doit donc être ajustée pour répondre 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 a des mises à jour de sécurité fréquentes pour 5 ans, mais une attention particulière à la sécurité est requise sur tous les serveurs.
Cette configuration fournit 2 sauvegardes indépendantes, dont l'une peut être un service de stockage cloud 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 le font pas. nécessitent beaucoup d'administration.
- Les sauvegardes indépendantes sont essentielles, car les pirates suppriment parfois toutes les sauvegardes en même temps que le piratage du site Web - dans le cas le plus récent, les pirates ont détruit 4800 sites Web, y compris les sauvegardes en piratant l'environnement d'hébergement Web plutôt que les sites. Voir aussi cette réponse et celle-ci .
- La restauration est très facile avec rsnapshot - il y a un fichier dans chaque arborescence de snapshots pour chaque fichier sauvegardé, alors il suffit de trouver les fichiers avec les outils Linux et rsync ou de les recopier sur le site Web. Si le serveur de sauvegarde sur site n'est pas disponible pour une raison quelconque, utilisez simplement la duplicité pour les restaurer à partir du serveur de sauvegarde cloud - ou vous pouvez utiliser des outils standard tels que GPG, rdiff et tar pour restaurer les sauvegardes.
Étant donné que cette configuration utilise SSH et rsync standard, il devrait être plus facile de choisir un fournisseur approprié avec les bonnes garanties de disponibilité, une sécurité renforcée, etc. Vous n'avez pas besoin de vous connecter à un contrat long et si le service de sauvegarde a une catastrophe En cas d'échec, vous disposez toujours d'une sauvegarde locale et pouvez basculer vers un autre service de sauvegarde assez facilement.