Restic: Prise en charge des sauvegardes asymétriques

Petit récapitulatif de la discussion précédente :

• Utile pour les sauvegardes de serveurs de messagerie ou les sauvegardes à distance des données de journal dans le cas où un tel serveur est compromis. Des données sensibles qui ont été déchiquetées du serveur peuvent être présentes dans la sauvegarde, et il peut être utile de pouvoir refuser à un attaquant l'accès à ces données historiques. Il a été simultanément discuté du fait qu'il pourrait être utile d'avoir un "serveur de réseau blob" avec un système de capacité qui vous permet de configurer l'accès en ajout uniquement / en lecture seule / en lecture-écriture selon les besoins. La mise en place d'une cryptographie asymétrique éliminerait le besoin d'avoir _encore un_ ensemble de clés symétriques pour émettre des capacités, et simplifierait probablement également la mise en œuvre d'un système de capacités.
• Dans un environnement avec plusieurs machines, _une_ clé de sauvegarde permet d'accéder à plusieurs jeux de données de sauvegarde sans avoir à gérer une multitude de clés symétriques. Si un cryptosystème tel que le Curve25519 de Daniel Bernstein est utilisé, une telle clé peut être dérivée d'une phrase secrète, ce qui signifie que vous pouvez utiliser une phrase secrète principale pour gérer les sauvegardes créées par un nombre (potentiellement important) de domaines de sécurité différents. Bien que quelque chose de similaire puisse bien sûr être réalisé avec des clés symétriques n et un stockage de clé crypté.

@heipei Pour info, vous voudrez peut-être vous abonner à ce numéro

eh bien, le cas d'utilisation le plus évident et le plus urgent est de ne pas faire effacer les sauvegardes par un attaquant qui s'est introduit dans votre système de production (client de sauvegarde) et sait comment utiliser restic à partir de là.

C'est difficilement possible en utilisant simplement la cryptographie asymétrique. Le point ici est que les anciens contenus de sauvegarde (pas nécessairement les métadonnées) ne devraient pas être disponibles pour un attaquant qui s'est introduit dans un serveur.

La confidentialité des données ( write-only ) serait réalisable pour ces scénarios avec la mise en œuvre de la cryptographie asymétrique.

L'intégrité des données est une bête légèrement différente :
Bien que vous puissiez utiliser la cryptographie asymétrique (et un schéma de signature unique) pour prouver qu'un ensemble de données donné n'a pas été modifié, vous ne pouvez pas empêcher sa suppression ou son remplacement complet. C'est un problème qui nécessite un système de stockage qui est append-only (et read-only , pour certaines pièces).
Grâce au contrôle d'accès discrétionnaire relativement simple à implémenter sur *nix avec un backend tel que ssh (en utilisant des commandes comme chmod , chown , chattr +i , chattr +a pour configurer les politiques d'accès). append-only sauvegardes de rsyslog , par exemple), mais cela fait soudainement du serveur de sauvegarde une cible intéressante, et le clonage de données sensibles sur un plus grand nombre d' appareils n'améliore pas exactement les chances de maintenir la confidentialité des données .

La mise en œuvre de la cryptographie asymétrique permettrait aux utilisateurs d'effectuer ce type de sauvegardes sur des systèmes stupides et non fiables, l'une des choses restic propos de

Cela nous intéresse pour les deux cas décrits dans https://github.com/restic/restic/issues/187#issuecomment -101974306. Je m'abonne à ce fil pour garder un œil dessus.

Concernant l'intégrité des données : AFAIK, vous pouvez obtenir append-only comportement PutObject et GetObject , mais en refusant les DeleteObject autorisation.

Concernant la confidentialité des données , je voulais mentionner un scénario d'attaque qui est permis par l'utilisation de la cryptographie symétrique :
Si un attaquant a le contrôle du compte d'utilisateur d'une victime à un moment où la victime utilise restic pour effectuer une sauvegarde, il peut :

• voler la clé restic la victime
• voler les informations d'identification IAM/connexion sftp/...

L'attaquant peut alors effacer immédiatement toute trace de son attaque du système de la victime, ce qui rend la détection moins probable. Puisqu'il a volé la clé restic et les informations d'identification pour le système de stockage distant, la victime lui fournira facilement toutes les données futures (sauvegardées) : notre attaquant n'a qu'à télécharger et déchiffrer de nouvelles sauvegardes du système de stockage distant de temps en temps temps.

La cryptographie asymétrique pourrait aider à éviter cela en permettant à la victime de stocker la clé pour restaurer les sauvegardes hors ligne.

Concernant l'intégrité des données : AFAIK, vous pouvez obtenir un comportement d'ajout uniquement sur Amazon S3 en accordant uniquement à vos informations d'identification IAM les autorisations PutObject et GetObject, mais en retenant l'autorisation DeleteObject.

Malheureusement, PutObject vous donne également des privilèges pour écraser un fichier précédemment téléchargé. Alors, peut-être que ce n'est pas l'intégrité totale des données ?

La cryptographie asymétrique permettrait également l'utilisation d'une clé OpenPGP comme Yubikey ou autre.

Aujourd'hui, j'ai réalisé que je ne voulais pas vraiment de prise en charge du chiffrement asymétrique dans restic, mais de prise en charge de NE PAS stocker la clé dans le référentiel. Je comprends qu'utiliser efficacement le cryptage asymétrique signifierait que restic peut télécharger de nouvelles sauvegardes sans avoir la possibilité de lire le référentiel, ce qui est assez délicat.

Donc, pour moi, ce serait bien si je pouvais gérer la clé symétrique sans restic, et qu'elle n'était en aucun cas téléchargée dans le référentiel, quel que soit le KDF complexe utilisé.

Mon cas d'utilisation est en tant qu'administrateur système pour un certain nombre de serveurs.

Les sauvegardes asymétriques sont le seul moyen de protéger les sauvegardes dans le scénario d'une compromission de serveur où un attaquant détruit de manière malveillante (ou un ransomware crypte) toutes les données (y compris les sauvegardes).

Cela nécessite une prise en charge côté serveur via une couche de stockage à ajout uniquement ou un démon de serveur similaire à la façon dont rdiff-backup a l'option --restrict-update-only. Actuellement, je contourne ce problème en utilisant des instantanés en lecture seule du référentiel de sauvegarde sur le serveur de sauvegarde (accessible via sftp).

(Peut-être pertinent): L'ajout uniquement peut être réalisé sous Linux via le drapeau append-only sur un répertoire (qui désactive la dissociation) avec le drapeau immutable sur les fichiers. Les commandes responsables de la définition de ces indicateurs sont respectivement chattr +a /path/to/directory et chattr +i /path/to/directory/myfile01 .

mon cas d'utilisation ici est #533 - sauvegardes sans surveillance. comme indiqué ici, la cryptographie asymétrique n'est que l'un des moyens de le faire, mais cela semble être la première solution évidente au problème.

Dans un scénario où le référentiel se trouve sur un serveur distant, seules les commandes locales sur le référentiel devraient pouvoir oublier/élaguer.

La sauvegarde restic doit se connecter avec une clé unique pour ce système avec des privilèges de restauration/sauvegarde uniquement.

Dans un scénario où le référentiel se trouve sur un serveur distant, seules les commandes locales sur le référentiel devraient pouvoir oublier/élaguer.

Cela devrait être accompli en restreignant l'accès aux fichiers de suppression/modification au niveau du référentiel. Je pense qu'il est hors de portée (et même pas sécurisé) pour restic de gérer ces autorisations. Après tout, quelqu'un pourrait supprimer le dépôt ou même les clés, rendant l'ensemble du dépôt inutile, que cette action soit autorisée ou non par le client restic.

En ce qui concerne la prévention de la destruction des données de sauvegarde par quelqu'un qui pirate le serveur : rest-server a récemment acquis un "mode d'ajout uniquement" avec PR https://github.com/restic/rest-server/pull/28 qui empêche exactement cela.

Mon cas d'utilisation consiste à sauvegarder de nombreux systèmes dans le même référentiel, ce qui permet de bénéficier de la déduplication sur toutes ces machines, mais d'une compromission d'un système (et de son script de sauvegarde) ne permettant pas à l'attaquant de lire les sauvegardes des autres systèmes.

La fonctionnalité que je recherche est d'avoir des clés de "sauvegarde" qui permettront à un système d'écrire (sauvegarde) et de lire (restaurer) mais ne peut faire aucun administrateur, (comme élaguer, ajouter des clés ou même voir l'existence d'autres clés, (utilisateurs) ou instantanés non associés à $backup_key ). (Bien qu'une attaque par canal latéral puisse être possible en comparant les temps de sauvegarde, cela m'importe peu s'ils peuvent déterminer l'existence de données, seulement qu'ils ne peuvent pas ransomware mes données et ne peuvent pas voir les autres utilisateurs.) Je m'attendrais à ce que le titulaire d'une clé de sauvegarde (seulement) pour pouvoir faire avancer sa ou ses propres phrases secrètes. Donc, contrairement à la demande

Avec cette fonctionnalité #ResticKillsRansomware

En général, les sauvegardes orientées pull (par opposition à celles orientées push) résolvent les ransomwares, n'est-ce pas ? :)

Peut-être, mais cela donne alors un accès à distance et ajoute un autre vecteur d'attaque. Comment je l'ai conçu, mon serveur de sauvegarde sert à préserver les données et ne devrait jamais avoir accès à mon environnement de production. Délimitation claire des domaines fonctionnels.

Je suppose que Restic n'est pas la solution alors, car il est conçu pour fonctionner directement sur les dépôts de sauvegarde.

Peut-être que vous pourriez faire quelque chose avec une sorte de serveur intermédiaire. Demandez à vos machines de production de télécharger des archives tar sur un serveur, puis demandez à un autre système de télécharger les archives, de les extraire et de sauvegarder le contenu localement. Chaque côté n'a accès qu'au serveur intermédiaire. Ce serait assez simple à faire sans aucune modification de Restic. Ce serait probablement aussi plus sûr et plus robuste, car tout bogue dans un mode Restic de réception uniquement pourrait rendre les sauvegardes vulnérables aux clients de sauvegarde compromis.

La fonctionnalité que je recherche est d'avoir des clés de "sauvegarde" qui permettront à un système d'écrire (sauvegarde) et de lire (restaurer) mais ne peut faire aucun administrateur, (comme élaguer, ajouter des clés ou même voir l'existence d'autres clés, (utilisateurs) ou instantanés non associés à $backup_key ). (Bien qu'une attaque par canal latéral puisse être possible en comparant les temps de sauvegarde, cela m'importe peu s'ils peuvent déterminer l'existence de données, seulement qu'ils ne peuvent pas ransomware mes données et ne peuvent pas voir les autres utilisateurs.) Je m'attendrais à ce que le titulaire d'une clé de sauvegarde (seulement) pour pouvoir faire avancer sa ou ses propres phrases secrètes. Donc, contrairement à la demande de michbsd, je pourrais administrer à partir d'une machine non locale avec une clé privilégiée. (Ayant utilisé SELinux pendant des années, je suis maintenant un fan de la granularité de MAC) Merci d'avoir lu. (Désolé si cela doit avoir son propre problème.) Avec cette fonctionnalité #ResticKillsRansomware

Bien que ce ne soit peut-être pas exactement ce que vous demandez, vous pouvez jeter un œil à rest-server . Il dispose d'un mode d'ajout uniquement qui empêche la suppression et la modification des sauvegardes existantes.

Bien que ce ne soit peut-être pas exactement ce que vous demandez, vous pouvez jeter un œil à rest-server. Il dispose d'un mode d'ajout uniquement qui empêche la suppression et la modification des sauvegardes existantes.

Je ne savais même pas que ça existait. RÉ:

Je vois deux choses structurelles (et des modèles d'attaquant légèrement différents) que j'aimerais vider ici.

Pour le moment, restic interagit (principalement) avec le stockage « dumb » (local, s3, b2, gcs, azure, tout sauf le serveur REST avec --append-only ). Il peut enregistrer, répertorier, obtenir et supprimer des données dans un backend. Ceci est requis pour une sauvegarde, les informations d'identification nécessaires pour accéder au backend doivent donc être présentes. Du côté positif, restic peut utiliser presque n'importe quel stockage, il y a très peu de restrictions. En revanche, une fois que les attaquants ont accès à un serveur, ils peuvent facilement extraire les informations d'identification pour accéder au backend et le mot de passe restic, ce qui leur donne toutes les possibilités : décrypter les données historiques du référentiel, modifier les données, supprimer l'intégralité du référentiel.

Lorsque nous ajoutons une cryptographie asymétrique, la seule différence pour les attaquants dans une telle situation est qu'ils ne peuvent pas déchiffrer les données historiques du référentiel. Tout le reste, en particulier la suppression de toutes les données, est toujours possible. Donc, "il suffit d'ajouter une crypto asymétrique" n'est pas toute l'histoire.

L'autre idée est de ne pas accéder directement au stockage « muet », mais indirectement via une implémentation de serveur personnalisée. Nous avons joué avec cette idée et ajouté l'option --append-only pour le serveur REST , qui peut être considéré comme un "adaptateur" pour accéder au stockage "muet" sur le disque dur local. J'ai plusieurs idées sur la façon d'améliorer cette idée, pas nécessairement avec le serveur REST.

Par exemple, j'aimerais définir un protocole pour un backend qui est parlé sur une paire de descripteurs de fichiers, par exemple stdin/stdout. Nous pouvons ensuite implémenter cela dans un programme exécuté via SSH sur une machine distante, tout comme nous le faisons pour le backend sftp. L'implémentation du serveur peut alors décider où stocker les données (local, s3, b2, peu importe) et quelles restrictions s'appliquent (par exemple "ajouter uniquement des anciennes lectures ou ajouter de nouvelles données", sans pouvoir supprimer quoi que ce soit d'autre que peut-être verrouiller les fichiers. Le serveur pourrait par exemple être démarré via un ForceCommand lors de la connexion via SSH avec un compte utilisateur particulier ou une clé SSH.

Avoir un stockage "non muet" seul n'aidera pas les attaquants à lire les données du référentiel (du moins pas sans changer le format du référentiel), mais empêchera la suppression de toutes les données du référentiel.

Donc, en conclusion, pour se défendre au mieux contre les attaquants prenant le contrôle d'un serveur qui utilise restic pour les sauvegardes, je pense que nous aurions besoin d'implémenter les deux (stockage non muet et crypto asymétrique). C'est un objectif à long terme :)

Je vais copier ce texte dans le premier commentaire de ce numéro afin qu'il soit plus facile à trouver.

oui, en réfléchissant plus loin, je suis d'accord que la crypto asym n'est pas si utile pour se défendre contre les prises de contrôle - c'est plus utile pour les sauvegardes sans surveillance (#533).

avoir un protocole de communication natif pourrait être utile, mais je ne sais pas ce que vous en retirez par rapport au serveur REST actuel - pourriez-vous développer cela? attic/borg est allé de cette façon: il existe un protocole "propriétaire" client-serveur (comme dans, spécifique à borg) et il est possible d'implémenter certaines restrictions pour les clients. et oui, cela repose sur ForceCommand et les drapeaux restreints "borg serve"... il y a quelques notes pertinentes dans la documentation borg à ce sujet et les inconvénients dont vous devez être conscient.

et bien sûr, le moyen le plus naturel de protéger les sauvegardes d'un client compromis est tout simplement de ne pas autoriser le client à effectuer les sauvegardes lui-même, mais à la place de demander au serveur d' extraire les fichiers des sauvegardes, "à la manière de bacula" ("Cela vient dans le nuit et aspire l'essence de vos ordinateurs", pour ceux qui se souviennent de cette phrase accrocheuse). il ne semble pas non plus y avoir de moyen bien documenté ou élégant de le faire dans borg, la FAQ pointe vers https://github.com/borgbackup/borg/issues/900 comme une discussion sur le sujet. ici c'est suivi dans #299, qui n'avait pas encore été mentionné ici.

pour faire court, je garderais l'accent sur la prise en charge de la cryptographie asymétrique simple : faciliter le stockage de clés hors site et les sauvegardes automatisées. il existe d'autres moyens de sécuriser les clients compromis, et je pense que le support pull est le plus intéressant. en fait, dans mes solutions de sauvegarde optimales, tous les clients envoient leurs sauvegardes vers un serveur central, puis un serveur hors site tirant du serveur de sauvegarde principal. Par ici:

1. le serveur de sauvegarde n'a pas besoin d'un accès root sur toutes les machines
2. pourtant le compromis d'une machine est toujours récupérable, même s'ils sont capables de jouer avec les sauvegardes

Je trouve en fait étrange que ce problème se soit transformé en "je veux me protéger contre la prise de contrôle par le client" - peut-être confondons-nous la solution avec le problème ici. :)

Salut,

Il semble que ce problème ne concerne pas seulement la sauvegarde cryptographique asymétrique, mais davantage les différents vecteurs d'attaque.
Je n'ai pas lu le code, j'ai donc vraiment une question naïve, mais mon cas d'utilisation consiste principalement à pouvoir sauvegarder des données sans divulguer la clé secrète (en utilisant la clé publique d'une clé privée hors ligne du propriétaire de la sauvegarde). Pour ce cas d'utilisation, est-ce facile à mettre en œuvre ?

Ma compréhension sur le sujet est qu'à l'heure actuelle, tous les blobs sont cryptés avec la même clé, et cela fonctionne très bien.
Si nous utilisions la crypto asym de la manière dont fonctionne OpenPGP, chaque instantané généré générerait une clé symétrique chiffrée avec la clé publique et l'ajouterait dans le référentiel. Mais je suppose que le problème est que pour pouvoir découvrir ce qu'il faut dédupliquer et ce qu'il faut sauvegarder, vous devriez d'abord pouvoir lire les informations, vous aurez donc également besoin de la clé privée. Est-ce correct?
Si tel est le cas, une preuve de connaissance zéro pourrait-elle aider dans ce sens ?

@dolanor s'il vous plaît n'ajoutez pas de nouveaux cas d'utilisation ou de questions à ce problème, utilisez le forum pour les questions. De plus, il est beaucoup trop tôt pour parler des détails de la mise en œuvre.

J'ai mis à jour le résumé dans le premier post. Le backend rclone a été ajouté entre-temps, il peut être utilisé comme "adaptateur" comme décrit ci-dessus, et accessible par exemple via SSH.

En revanche, une fois que les attaquants ont accès à un serveur, ils peuvent facilement extraire les informations d'identification pour accéder au backend et le mot de passe restic

J'espère qu'il s'agit d'une faute de frappe : vous utilisez le fichier de clé crypté ici, non ? Espérons qu'un attaquant accédant au serveur n'ait pas accès au mot de passe en clair. Le pire qu'ils puissent faire est d'essayer de forcer ou de deviner le "mot de passe utilisateur" qui est utilisé pour déchiffrer les clés de chiffrement et d'authentification principales du référentiel.

Si cela est correct, je vous recommande fortement de modifier à nouveau le résumé pour le clarifier, car il semble certainement mauvais lorsqu'il est indiqué de cette façon. :)

Espérons qu'un attaquant accédant au serveur n'ait pas accès au mot de passe en clair. Le pire qu'ils puissent faire est d'essayer de forcer ou de deviner le "mot de passe utilisateur" qui est utilisé pour déchiffrer les clés de chiffrement et d'authentification principales du référentiel.

Je suppose que cela dépend du scénario exact : si vous entrez manuellement le mot de passe, c'est bien. Si vous effectuez des sauvegardes automatiques planifiées, en revanche, le "mot de passe utilisateur" devra être stocké quelque part sur le serveur.

Et, bien sûr, un attaquant peut remplacer le binaire Restic par un autre qui divulgue le mot de passe saisi et attendre que vous le saisissiez. Vous ne pouvez pas faire confiance à un système compromis.

le "mot de passe utilisateur" devra être stocké quelque part sur le serveur.

par « serveur », voulez-vous dire « la machine sur laquelle nous exécutons restic sur laquelle nous sauvegardons les données » ou « la machine qui reçoit/stocke les données de la sauvegarde » ?

c'est plutôt ambigu, et la source de mon inquiétude : cela ne me dérange pas que le client de sauvegarde (la machine que nous sauvegardons qui exécute restic) ait le mot de passe en clair : l'ensemble de données est là de toute façon donc si c'est compromis, les données sont compromis de toute façon. mais j'espère bien que le serveur de sauvegarde

par « serveur », voulez-vous dire « la machine sur laquelle nous exécutons restic sur laquelle nous sauvegardons les données » ou « la machine qui reçoit/stocke les données de la sauvegarde » ?

La machine sur laquelle nous opérons reste limitée sur laquelle nous sauvegardons les données.

Je vois votre point, vous avez raison, c'est ambigu. Ma compréhension de tout ce que je sais sur le modèle de Restic est la même que la vôtre, j'en suis assez certain, mais je ne peux pas vous donner la confirmation définitive que vous souhaitez.

Le résumé mentionne l'option --append-only pour le serveur REST. Cela devrait peut-être rester la seule méthode officiellement recommandée de sauvegarde par ajout uniquement, mais il pourrait être utile de documenter les fichiers dans restic qui doivent être accessibles en écriture pour un fonctionnement normal afin de déterminer comment configurer d'autres approches.

Je pense que restic backup fonctionnerait bien si data , index , keys et snapshots autorisaient la création de fichiers mais pas la modification ou la suppression ( et config était également protégé). Cependant, je pense que locks devrait autoriser la suppression afin que le référentiel ne soit pas verrouillé de manière permanente. De plus, certaines implémentations d'ajout uniquement (comme l'attribut pour les systèmes de fichiers ext4 et xfs) ne sont pas récursives, donc les 256 sous-répertoires à deux caractères de data devraient d'abord être pré-générés, puis l'attribut devrait être être fixé sur eux.

Certains backends comme S3 ne prennent pas en charge l'ajout uniquement, mais prennent en charge la gestion des versions d'objets, ce qui pourrait produire le même effet. Cependant, cela nécessite une vérification minutieuse du modèle de contrôle d'accès. Par exemple, B2 a des règles de cycle de vie qui permettent la gestion des versions d'objets, mais la clé API nécessaire à la sauvegarde sur B2 a la capacité de modifier les règles de cycle de vie (B2 n'a pas encore vraiment de système d'autorisation).

A part : il me manque peut-être quelque chose, mais si le chiffrement asymétrique ne fait que protéger les données historiques d'un attaquant qui a compromis le client, cela semble être une faible priorité. Ce serait bien de l'avoir, mais dans la plupart des cas, les données actuelles sont plus précieuses que les versions précédentes (bien que parfois quelque chose de précieux soit accidentellement sauvegardé, supprimé, mais pas purgé).

@willsALMANJ bonnes observations. Pour S3 je me demande si les versions d'objection pourraient être enregistrées pour permettre de récupérer une vue cohérente des blobs nécessaires pour restaurer un instantané donné (bien que vous puissiez les valider en fonction de leur contenu, donc pas super important).

Re : votre dernier paragraphe :

• Le principal avantage du chiffrement asymétrique, outre le scénario de "déchiffrement des éléments historiques" que vous avez mentionné, est de pouvoir stocker des sauvegardes de plusieurs machines indépendantes dans le même référentiel de sauvegarde sans avoir à provisionner des clés individuelles (ce qui nécessite de stocker la clé de sauvegarde quelque part chaque fois que vous installer une nouvelle machine cliente). Si vous utilisez une clé partagée, vous obtenez le scénario de menace ennuyeux où client1 peut lire les données de client2, ce qui n'est pas idéal.

@fd0 Je pense avoir un schéma décent pour le cryptage asymétrique utilisant l'adressage HMAC avec des secrets partagés dérivés. Aussi quelques idées sur la récupération de place côté serveur sans fuite de données, je ne sais pas si cela vous intéresse, mais si cela vous intéresse, je serais intéressé d'en parler.

Je ne sais pas si quelque chose me manque ici, mais j'exécute restic avec succès avec ce paramètre de stratégie sur le stockage S3. Cela n'empêche pas un attaquant de lire les données, mais cela l'empêche de les supprimer.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:GetBucketLocation"
      ],
      "Resource": "arn:aws:s3:::kvasir"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::backup/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::backup/locks/*"
    }
  ]
}

Les commandes d'élagage/oubli sont ensuite exécutées à partir d'un périphérique de confiance disposant d'autorisations d'écriture. Je crée également deux clés dans chaque référentiel restic. Un pour le serveur et un pour l'appareil de confiance, afin que l'appareil de confiance puisse verrouiller un attaquant (mais l'attaquant ne peut pas car il ne peut pas supprimer dans les clés/*).

Edit: Désolé, j'ai oublié que cela a déjà été discuté. Je ne voulais pas détourner ce fil.
PutObject est en fait capable d'écraser l'objet, ce n'est donc pas une solution pour protéger les sauvegardes .

@freswa Je ne suis pas un expert S3, donc je ne suis pas sûr que ce soit correct, mais le point qui a été fait ci-dessus dans cette discussion est que l'autorisation PutObject peut être utilisée pour écraser vos données, ce qui est tout aussi mauvais comme en le supprimant. Dans mon article ci-dessus, j'ai noté que vous pouviez contourner ce problème en utilisant la gestion des versions d'objets (ne donnez pas au système de sauvegarde l'accès pour supprimer des versions).

@andrewchambers Je suis un peu submergé par d'autres choses, parlons de vos idées une fois que nous aurons réellement mis en œuvre cela ! Oui ça m'intéresse ;)

Ainsi, ce problème concerne (éventuellement) la mise en œuvre de sauvegardes asymétriques, et non la configuration d'accès pour le stockage principal. Merci! :)

@fd0 Espérons que cela explique ce que je voulais dire https://packnback.github.io/blog/dedup_and_encryption/

@andrewchambers : Juste au cas où vous n'auriez pas encore rencontré le problème d'écriture seule (que vous avez mentionné sur votre site), c'est https://github.com/ncw/rclone/issues/2499.

@andrewchambers merci de l'avoir écrit, je suis très intéressé à savoir à quoi ressemble la mise en œuvre réelle. Le billet de blog a laissé quelques éléments intéressants ouverts :)

J'aime le fait qu'il y aura un autre concurrent dans l'espace des programmes de sauvegarde de logiciels gratuits, donner aux utilisateurs plus d'options est toujours génial !

Un parallèle intéressant peut donc être fait avec les deux mécanismes de chiffrement du dépôt git.

D'un côté, vous avez git-crypt : il utilise des filtres git

De l'autre côté vous avez git-remote-gcrypt : qui utilise le protocole git remote helpers pour crypter tout ce qui est envoyé sur le serveur. Mais c'est très inefficace, car l'ensemble du référentiel est recrypté à chaque exécution, en raison du fonctionnement des télécommandes spéciales.

Maintenant, ce sont des défis d'implémentation spécifiques à git, mais je pense qu'ils correspondent bien aux problèmes que vous pourriez rencontrer ici. Peut-être que je suis totalement dépassé ici et que ce parallèle n'est pas pertinent, mais j'ai pensé que cela pourrait être intéressant ici...

Soit dit en passant, il existe un moyen terme qui pourrait actuellement être mis en œuvre (probablement) assez facilement : autoriser le stockage des clés en dehors du référentiel.

L'un des vecteurs d'attaque abordés est que l'attaquant met la main sur un mot de passe de clé, puis (étant donné que les clés sont stockées dans le référentiel), il peut facilement déchiffrer une clé.

Et si nous permettions la spécification d'un répertoire de clés séparé, où les fichiers de clés sont stockés ? Ce répertoire pourrait être stocké localement sur chaque machine qui a besoin d'effectuer des sauvegardes, et il pourrait lui-même être sauvegardé sur un autre fournisseur de cloud, ou même un code QR (environ 500 octets est beaucoup plus petit pour être encodé en QR) pour le stockage hors ligne à froid dans un coffre-fort par exemple.

Si les clés chiffrées ne touchent jamais un fournisseur de cloud, le vecteur d'attaque disparaît complètement. Les clés devraient être compromises depuis les locaux physiques ou exfiltrées avec des logiciels malveillants, par exemple.

Cela _peut déjà être fait sur Restic_ si une copie locale du référentiel est conservée - excluez simplement le répertoire des clés de la synchronisation avec la télécommande non fiable lors de l'exécution de rclone. Cela _ne peut pas_ être fait s'il n'y a pas de copie locale et que restic interagit directement avec la télécommande non fiable.

Je pense qu'il faut appliquer le principe de responsabilité unique et décomposer les choses en 2 tâches :

1. Protégez les données du déchiffrement.
2. Protégez les données des actions de suppression non autorisées.

Ce sont 2 aspects différents de la sécurité des données. Techniquement, ils n'ont pas besoin de s'appuyer les uns sur les autres.

Pour (1), nous pouvons évidemment "ajouter simplement un support de chiffrement asymétrique". Pour (2), je pense qu'il existe de nombreuses solutions possibles (par exemple, comme mentionné ci-dessus, la configuration S3 en ajout uniquement).