Sauvegarde hors site sécurisée, même dans le cas d'un accès root pirate
Je cherche un moyen de mettre en œuvre un moyen plus sûr de faire une sauvegarde hors site qui protégera également mes données contre la situation où un pirate malveillant a obtenu un accès root à mon serveur. Même si le risque que cela se produise est plus faible que d'autres types de risques si la sécurité SSH et par mot de passe est correctement configurée et que le système est correctement mis à jour, le montant des dommages qui peuvent être causés de manière permanente est vraiment élevé et, par conséquent, je J'aimerais trouver une solution pour limiter cela.
J'ai déjà essayé deux méthodes de sauvegarde hors site:
un simple montage webdav accessible en écriture (et configuré dans fstab) sur lequel les données sauvegardées sont copiées. Problème: pas vraiment une sauvegarde hors site car la connexion - et en plus l'accès - à l'emplacement hors site est constamment laissée ouverte en tant que dossier dans le système de fichiers. C'est une protection suffisante contre de nombreux types d'attaques si le montage a des privilèges d'accès limités (accès en lecture seule), mais ne protège pas contre une personne malveillante avec un accès root.
Sauvegarde Borg via SSH avec authentification par clé. Problème: la connexion à ce serveur hors site peut être effectuée avec la clé stockée sur l'hôte si l'utilisateur malveillant a un accès root à l'hôte.
En tant que solution, je pense à ces moyens potentiels, mais je ne sais pas comment et avec quoi:
- Les sauvegardes peuvent uniquement être écrites ou ajoutées à la destination mais pas supprimées.
- L'utilisation d'un logiciel de sauvegarde qui gère les sauvegardes hors site et ne prend pas en charge la suppression en masse des sauvegardes hors site du premier hôte.
Des solutions qui ne sont pas vraiment intéressantes dans ma situation:
- Un travail de sauvegarde supplémentaire sur l'hôte hors site qui les transfère vers un emplacement qui n'est pas accessible par le premier hôte (en raison de limitations techniques).
Quelqu'un peut-il donner des conseils sur la façon de mettre en œuvre une sauvegarde hors site appropriée pour mon cas?
Toutes vos suggestions ont actuellement un point commun: la source de sauvegarde effectue la sauvegarde et a accès à la destination de sauvegarde. Que vous montiez l'emplacement ou utilisiez des outils comme SSH ou rsync, le système source a en quelque sorte accès à la sauvegarde. Par conséquent, un compromis sur le serveur peut également compromettre vos sauvegardes.
Et si la solution de sauvegarde a accès au serveur à la place? Le système de sauvegarde peut faire son travail avec un accès en lecture seule, donc tout compromis sur le système de sauvegarde ne serait pas '' t probablement compromettre le serveur. De plus, le système de sauvegarde pourrait être dédié uniquement à cette fin, faisant du contenu de la sauvegarde le seul vecteur d'attaque. Ce serait très peu probable et nécessiterait une attaque vraiment sophistiquée.
Pour éviter d'écraser les sauvegardes avec du contenu falsifié ou endommagé, effectuez des sauvegardes incrémentielles qui vous permettent de restaurer tout état précédent pendant la période de restauration définie.
Stockage immuable
Une bonne option consiste à rendre votre stockage de sauvegarde immuable, ou au moins à fournir un versionnage fiable qui vous donne effectivement une immuabilité. Pour être clair: immuable signifie non modifiable ou permanent.
Il existe plusieurs services qui peuvent le faire pour vous. AWS S3, BackBlaze B2 et je soupçonne qu'Azure et Google proposent tous deux un service similaire. Vous pourriez probablement configurer un serveur pour ce faire, mais je ne sais pas comment.
Lorsque vous avez un référentiel immuable/contrôlé par version, vous pouvez restaurer votre sauvegarde à tout moment, donc si votre hôte est compromis, vous pouvez toujours restaurer comme à tout moment.
* AWS S3 **
Je connais le mieux AWS S3. S3 fournit un stockage chiffré et versionné, avec un haut niveau de durabilité.
S3 prend en charge la gestion des versions, ce qui vous donne une immuabilité efficace. Vous pouvez choisir d'utiliser des règles de cycle de vie pour supprimer l'ancienne version des fichiers après une période de temps que vous pouvez configurer. Vous pouvez également archiver des versions dans une chambre froide (glacier cold archive), ce qui coûte environ 1 $/To/mois.
Vous pouvez utiliser la classe de hiérarchisation du stockage intelligent pour réduire les coûts. J'ai choisi d'utiliser une règle de cycle de vie pour déplacer toutes les données statiques vers une classe d'accès peu fréquente, qui est une performance durable et modérée (chaude) mais n'a pas l'évolutivité ou les performances de la norme S3.
S3 utilise les utilisateurs et les politiques IAM (gestion des accès aux identités, c'est-à-dire la gestion des utilisateurs). Cela vous donne un contrôle très granulaire de ce que votre logiciel de sauvegarde peut faire avec votre stockage. Vous pouvez autoriser l'utilisateur de sauvegarde à télécharger, mais refuser la mise à jour et la suppression. Vous pouvez également exiger une authentification multifacteur pour supprimer des fichiers, ou même fournir un verrouillage d'objet afin que les fichiers ne puissent pas être supprimés.
Logiciel suggéré
Je crée des sauvegardes incrémentielles en utilisant Restic . Restic télécharge les nouveaux fichiers sur votre emplacement de stockage. Je crois (mais je peux me tromper) qu'il crée de nouveaux fichiers, mais en général, il ne met à jour ni ne supprime aucun fichier.
Borg est une autre option. J'avais l'habitude d'utiliser Borg, mais j'ai trouvé qu'avec mes sauvegardes de taille moyenne de centaines de Mo, il téléchargeait efficacement toutes mes données chaque jour d'EC2 vers S3. Pour moi, ce n'est pas incrémentiel, j'ai donc cessé de l'utiliser. J'ai trouvé de la documentation à ce sujet, mais je n'ai pas le lien.
Il existe des dizaines de logiciels pouvant être téléchargés sur le stockage cloud.
Stockage protégé
Avec certains logiciels de sauvegarde, vous pouvez essayer d'accorder à l'utilisateur IAM la permission d'écrire de nouveaux fichiers mais pas de mettre à jour les fichiers existants. Il est facile de faire cette restriction avec AWS IAM, mais selon le commentaire ci-dessous, Restic ne fonctionnera pas avec ces autorisations. Vous pouvez également avoir une authentification multifacteur requise pour supprimer des fichiers de S3.
Vous pouvez avoir un autre utilisateur IAM, exécuté par exemple sur votre PC, qui effectue le nettoyage périodique de l'archive, en éliminant les versions conformément à la stratégie que vous définissez.
Borg Backup prend en charge référentiels distants uniquement ajoutés . Tout compromis sur le serveur en cours de sauvegarde ne peut entraîner que la création de nouvelles sauvegardes, et non le remplacement des anciennes uniquement.
Des solutions qui ne sont pas vraiment intéressantes dans ma situation:
Un travail de sauvegarde supplémentaire sur l'hôte hors site qui les transfère vers un emplacement qui n'est pas accessible par le premier hôte.
Le problème fondamental est que si vous pouvez accéder à distance à vos sauvegardes il en va de même pour le pirate.
(En raison de limitations techniques)
Les limites techniques sont faites pour être surmontées.
Quelqu'un peut-il donner des conseils sur la façon de mettre en œuvre une sauvegarde hors site appropriée pour mon cas?
Les lecteurs de bande offrent une protection sécurisée hors site contre toutes sortes de catastrophes - y compris les pirates - depuis près de 70 ans.
Sauvegarde Borg via SSH avec authentification par clé. Problème: la connexion à ce serveur hors site peut être effectuée avec la clé stockée sur l'hôte si l'utilisateur malveillant a un accès root à l'hôte.
Vous pouvez utiliser la commande d'option dans vos clés autorisées. Vous corrigez la commande autorisée dans la télécommande.
comment ajouter des commandes dans ssh authorized_keys
Même si un attaquant récupère la racine de connexion, il ne pourra rien faire d'autre que la commande définie.
Vous pouvez utiliser des services de stockage comme AWS S3 (ou probablement l'équivalent de Google ou d'Azure) où vous pouvez donner à votre compte racine des autorisations PUT sur votre compartiment, mais pas des autorisations DELETE. De cette façon, vous pouvez utiliser un modèle Push et l'attaquant ne pourra pas supprimer la sauvegarde.
Il existe d'autres mesures de sécurité que vous pouvez prendre avec AWS, comme exiger que MFA exécute DELETE sur le compartiment, mais autorise les PUT et GET sans MFA. De cette façon, vous pouvez à la fois sauvegarder vos données et les récupérer pour restaurer vos services sans utiliser votre appareil MFA, ce qui pourrait être utile dans certains cas extrêmes (et probablement trop obscurs pour être mentionnés) où l'accès à l'appareil MFA pourrait le compromettre.
En outre, un commentaire hors de portée que vous pourriez trouver intéressant/utile, il existe plusieurs façons de configurer S3 et des services similaires pour le basculement automatique dans le cas où la source de données principale est hors ligne.
Une technique que vous pouvez configurer consiste à utiliser la synchronisation entre votre serveur et un serveur de sauvegarde distant et à laisser le serveur de sauvegarde distant effectuer des instantanés ou quoi que ce soit de son côté afin que le côté serveur d'effacement n'entraîne pas d'effacement hors site.