Restic: Suporta backups assimétricos

Uma breve recapitulação da discussão anterior:

• Útil para backups de servidores de e-mail ou backups remotos de dados de log, caso esse servidor seja comprometido. Dados confidenciais que foram fragmentados do servidor podem estar presentes no backup e pode ser útil ser capaz de negar a um invasor o acesso a tais dados históricos. Foi discutido simultaneamente que poderia ser útil ter um "servidor de rede blob" com um sistema de capacidade que permite configurar o acesso somente acréscimo / somente leitura / leitura / gravação conforme apropriado. Ter a criptografia assimétrica em vigor eliminaria a necessidade de ter _ainda outro_ conjunto de chaves simétricas para emitir recursos e provavelmente também simplificaria a implementação de um sistema de recursos.
• Em uma configuração com várias máquinas, _uma_ chave de backup pode ser usada para acessar vários conjuntos de dados de backup sem ter que gerenciar uma infinidade de chaves simétricas. Se um criptosistema como o Curve25519 de Daniel Bernstein for usado, essa chave pode ser derivada de uma senha, o que significa que você pode usar uma senha mestra para gerenciar backups criados por um número (potencialmente grande) de domínios de segurança diferentes. Embora algo semelhante possa ser alcançado com n chaves simétricas e um armazenamento de chave criptografada.

@heipei FYI, você pode querer se inscrever nesta edição

bem, o caso de uso mais óbvio e urgente é não ter os backups apagados por um invasor que invadiu seu sistema de produção (cliente de backup) e sabe como usar o restic a partir daí.

Isso dificilmente é possível apenas usando criptografia assimétrica. A questão aqui é que o conteúdo antigo do backup (não necessariamente metadados) não deve estar disponível para um invasor que invadiu um servidor.

A confidencialidade dos dados ( write-only ) seria alcançável para esses cenários com a implementação de criptografia assimétrica.

A integridade dos dados é uma besta ligeiramente diferente:
Embora você possa usar criptografia assimétrica (e um esquema de assinatura única) para provar que um determinado conjunto de dados não foi alterado, você não pode impedir sua remoção ou substituição completa. Esse é um problema que requer um sistema de armazenamento append-only (e read-only , para algumas peças).
Graças ao controle de acesso discricionário que é relativamente simples de implementar em * nix com um back-end como ssh (usando comandos como chmod , chown , chattr +i , chattr +a para configurar as políticas de acesso). append-only backups nem precisam ser criptografados para evitar que invasores os leiam (isso é parte do que rsyslog faz, por exemplo), mas isso repentinamente torna o servidor de backup um alvo interessante, e clonar dados confidenciais em mais dispositivos não aumenta exatamente as chances de manter a confidencialidade dos dados .

Ter a criptografia assimétrica implementada permitiria que as pessoas fizessem esse tipo de backup em sistemas burros e não confiáveis, uma das coisas que restic tem a ver (além da desduplicação aprimorada e todos os outros recursos interessantes). Espero que esta elaboração esclareça um pouco meu ponto.

Isso é do nosso interesse para os dois casos descritos em https://github.com/restic/restic/issues/187#issuecomment -101974306. Estou me inscrevendo neste tópico para ficar de olho nisso.

Com relação à integridade dos dados : AFAIK, você pode obter o comportamento de append-only no Amazon S3 apenas concedendo às suas credenciais IAM as permissões PutObject e GetObject , mas retendo as DeleteObject permissão.

Com relação à confidencialidade dos dados , gostaria de mencionar um cenário de ataque que é permitido pelo uso de criptografia simétrica:
Se um invasor tem controle sobre a conta de usuário de uma vítima em um momento em que a vítima usa restic para fazer um backup, ele pode:

• roubar a chave restic da vítima
• roubar as credenciais IAM da vítima / login sftp / ...

O invasor pode, então, limpar imediatamente qualquer vestígio de seu ataque do sistema da vítima, tornando a detecção menos provável. Uma vez que ele roubou a chave restic e as credenciais do sistema de armazenamento remoto, a vítima irá convenientemente entregar quaisquer dados futuros (com backup) para ela: Nosso invasor só precisa baixar e descriptografar novos backups do sistema de armazenamento remoto de vez em quando Tempo.

A criptografia assimétrica pode ajudar a prevenir isso, permitindo que a vítima armazene a chave para restaurar backups offline.

Com relação à integridade dos dados: AFAIK, você pode obter um comportamento somente anexar no Amazon S3 concedendo às suas credenciais IAM as permissões PutObject e GetObject, mas retendo a permissão DeleteObject.

Infelizmente PutObject também lhe dá privilégios para sobrescrever um arquivo carregado anteriormente. Então, talvez não seja a integridade total dos dados?

A criptografia assimétrica permitiria também o uso de uma chave OpenPGP como yubikey ou algo assim.

Hoje percebi que não quero suporte para criptografia assimétrica no restic, mas suporte para NÃO armazenar a chave no repositório. Eu entendo que usar criptografia assimétrica de forma eficiente significaria que o restic pode fazer upload de novos backups sem a capacidade de ler o repositório, o que é bastante complicado.

Então, para mim, estaria tudo bem se eu pudesse lidar com a chave simétrica sem restic, e ela não foi carregada de nenhuma forma para o repositório, não importa qual KDF complexo é usado.

Meu caso de uso é como administrador de sistema para vários servidores.

Os backups assimétricos são a única maneira de proteger os backups no cenário de comprometimento do servidor, em que um invasor destrói (ou criptografa ransomware) todos os dados (incluindo os backups) de forma maliciosa.

Isso precisa de suporte do lado do servidor por meio de uma camada de armazenamento somente acréscimo ou de um daemon de servidor semelhante ao modo como o rdiff-backup tem a opção --restrict-update-only. Atualmente, eu trabalho em torno disso usando instantâneos somente leitura do repositório de backup no servidor de backup (acessado via sftp).

(Talvez relevante): Somente acréscimo pode ser obtido no Linux por meio do sinalizador append-only em um diretório (que desativa a desvinculação) junto com o sinalizador immutable nos arquivos. Os comandos responsáveis ​​por definir essas sinalizações são chattr +a /path/to/directory e chattr +i /path/to/directory/myfile01 , respectivamente.

meu caso de uso aqui é # 533 - backups autônomos. como afirmado lá, a criptografia assimétrica é apenas uma das maneiras de fazer isso, mas parece ser a primeira solução óbvia para o problema.

Em um cenário em que o repo está em um servidor remoto - apenas os comandos locais no repo devem ser capazes de esquecer / remover.

O backup restic deve se conectar com uma chave exclusiva para esse sistema, com privilégios de restauração / backup apenas.

Em um cenário em que o repo está em um servidor remoto - apenas os comandos locais no repo devem ser capazes de esquecer / remover.

Isso deve ser feito restringindo o acesso para excluir / modificar arquivos no nível do repo. Acho que está fora do escopo (e nem mesmo é seguro) para que o restic gerencie essas permissões. Afinal, alguém poderia excluir o repo ou mesmo as chaves, tornando todo o repo inútil, independentemente de essa ação ser permitida pelo cliente restic.

Em relação à prevenção de dados de backup de serem destruídos por alguém que hackeou o servidor: o rest-server ganhou recentemente um "modo apenas anexar" com PR https://github.com/restic/rest-server/pull/28 que impede exatamente isso.

Meu caso de uso é ter muitos sistemas fazendo backup no mesmo repositório, obtendo a vantagem da desduplicação em todas essas máquinas, mas o comprometimento de um sistema (e seu script de backup) não permitindo que o invasor leia os backups dos outros sistemas.

O recurso que procuro é ter chaves de "backup" que permitirão a um sistema gravar (fazer backup) e ler (restaurar), mas não pode fazer nenhum administrador, (como podar, adicionar chaves ou mesmo ver a existência de outros chaves (usuários) ou instantâneos não associados a $ backup_key). (Embora um ataque de canal lateral possa ser possível comparando os tempos de backup, não importa para mim se eles podem determinar a existência de dados, apenas que eles não podem ransomware meus dados e não podem visualizar outros usuários.) Eu esperaria o detentor de uma chave (apenas) de backup para poder lançar sua (s) própria (s) frase (s) senha (s) para frente. Portanto, ao contrário da solicitação

Com este recurso #ResticKillsRansomware

Em geral, os backups orientados por pull (em oposição aos orientados por push) resolvem o ransomware, certo? :)

Possivelmente, mas isso dá acesso remoto e adiciona outro vetor de ataque. Como eu projetei meu servidor de backup é para preservar dados e nunca deve ter acesso ao meu ambiente de produção. Demarcação clara de domínios funcionais.

Acho que o Restic não é a solução, pois ele foi projetado para operar diretamente em repositórios de backup.

Talvez você possa fazer algo com uma espécie de servidor intermediário. Faça com que suas máquinas de produção carreguem tarballs para um servidor, depois faça com que outro sistema baixe os tarballs, extraia-os e faça backup do conteúdo localmente. Cada lado tem acesso apenas ao servidor intermediário. Isso seria bastante simples de fazer, sem qualquer modificação no Restic. Provavelmente seria mais seguro e mais robusto também, já que qualquer bug em um modo Restic somente de recebimento poderia tornar os backups vulneráveis ​​a clientes de backup comprometidos.

O recurso que procuro é ter chaves de "backup" que permitirão a um sistema gravar (fazer backup) e ler (restaurar), mas não pode fazer nenhum administrador, (como podar, adicionar chaves ou mesmo ver a existência de outros chaves (usuários) ou instantâneos não associados a $ backup_key). (Embora um ataque de canal lateral possa ser possível comparando os tempos de backup, não importa para mim se eles podem determinar a existência de dados, apenas que eles não podem ransomware meus dados e não podem visualizar outros usuários.) Eu esperaria o detentor de uma chave (apenas) de backup para poder lançar sua (s) própria (s) frase (s) senha (s) para frente. Portanto, ao contrário da solicitação de michbsd, eu seria capaz de administrar de uma máquina não local com uma chave privilegiada. (Uso o SELinux há anos, agora sou um fã da granularidade do MAC) Obrigado pela leitura. (Desculpe se isso deve ter seu próprio problema.) Com este recurso #ResticKillsRansomware

Embora isso possa não ser exatamente o que você está pedindo, dê uma olhada no rest-server . Ele tem um modo apenas de acréscimo que evita a exclusão e modificação de backups existentes.

Embora isso possa não ser exatamente o que você está pedindo, dê uma olhada no rest-server. Ele tem um modo apenas de acréscimo que evita a exclusão e modificação de backups existentes.

Eu nem sabia que existia. D:

Vejo duas coisas estruturais (e modelos de invasor ligeiramente diferentes) que gostaria de despejar aqui.

No momento, o restic (principalmente) interage com o armazenamento "burro" (local, s3, b2, gcs, azure, tudo exceto para o servidor REST com --append-only ). Ele pode salvar, listar, obter e excluir dados em um backend. Isso é necessário para um backup, portanto, as credenciais necessárias para acessar o back-end precisam estar presentes. Por outro lado, o restic pode usar quase qualquer armazenamento, existem muito poucas restrições. Por outro lado, uma vez que os invasores ganham acesso a um servidor, eles podem facilmente extrair as credenciais para acessar o back-end e a senha restic, dando a eles todas as possibilidades: descriptografar dados históricos do repositório, modificar dados, excluir todo o repositório.

Quando adicionamos criptografia assimétrica, a única diferença para invasores em tal situação é que eles não podem descriptografar dados históricos do repositório. Todo o resto, especialmente a exclusão de todos os dados, ainda é possível. Portanto, "basta adicionar criptografia assimétrica" ​​não é toda a história.

A outra ideia é não acessar o armazenamento "burro" diretamente, mas indiretamente por meio de uma implementação de servidor customizada. Brincamos com essa ideia e adicionamos a opção --append-only para o servidor REST , que pode ser visto como um "adaptador" para acessar o armazenamento "burro" no disco rígido local. Tenho várias ideias sobre como melhorar essa ideia, não necessariamente com o servidor REST.

Por exemplo, eu gostaria de definir um protocolo para um back-end que é falado sobre um par de descritores de arquivo, por exemplo, stdin / stdout. Podemos então implementar isso em um programa que é executado em SSH em uma máquina remota, assim como fazemos para o backend sftp. A implementação do servidor pode então decidir onde armazenar os dados (local, s3, b2, qualquer que seja) e quais restrições se aplicam (por exemplo, "apenas adicionar dados antigos ou novos", sem a capacidade de excluir nada além de talvez bloquear arquivos. O servidor poderia, por exemplo, ser iniciado por meio de ForceCommand no login via SSH com uma conta de usuário específica ou chave SSH.

Ter armazenamento "não burro" sozinho não ajudará contra invasores que leiam dados do repositório (pelo menos não sem alterar o formato do repo), mas impedirá a exclusão de todos os dados do repositório.

Portanto, para concluir, para nos defendermos melhor contra invasores que assumam um servidor que usa o Restic para backups, acho que precisaríamos implementar ambos (armazenamento não burro e criptografia assimétrica). Essa é uma meta de longo prazo :)

Copiarei este texto para o primeiro comentário desta edição para que seja mais fácil de localizar.

sim, refletindo mais sobre isso, concordo que asym crypto não é tão útil para se defender contra takeovers - é mais útil para backups autônomos (# 533).

Ter um protocolo de comunicação nativo pode ser útil, mas não tenho certeza do que você ganha com isso em relação ao servidor REST atual - você poderia expandir isso? attic / borg foi assim: existe um protocolo "proprietário" cliente-para-servidor (como em, específico do borg) e é possível implementar algumas restrições para os clientes. e sim, isso depende do ForceCommand e dos sinalizadores restritos "borg serve" ... há algumas notas relevantes na documentação do borg sobre isso e as desvantagens que você deve conhecer.

e, claro, a maneira mais natural de proteger backups de um cliente comprometido é simplesmente não permitir que o cliente execute os backups por si mesmo, mas em vez disso, fazer com que o servidor extraia os arquivos dos backups, "estilo bacula" ("Ele vem no noite e suga a essência dos seus computadores ", para quem se lembra dessa frase contagiante). também não parece haver uma maneira bem documentada ou elegante de fazer isso no borg, o FAQ aponta para https://github.com/borgbackup/borg/issues/900 como uma discussão sobre o tópico. aqui, isso é rastreado em # 299, que não foi mencionado aqui ainda.

encurtando a história, eu manteria o foco do suporte à criptografia assimétrica simples: facilitar o armazenamento externo de chaves e backups automatizados. Existem outras maneiras de proteger clientes comprometidos e acho que o suporte pull é o mais interessante. de fato, em minhas soluções de backup ideais, eu tenho todos os clientes empurrando seus backups para um servidor central, em seguida, um servidor externo puxando do principal servidor de backup. Por aqui:

1. o servidor de backup não precisa de acesso root em todas as máquinas
2. no entanto, o comprometimento de uma máquina ainda é recuperável, mesmo se eles forem capazes de bagunçar os backups

Na verdade, acho estranho que esse problema tenha se transformado em "Quero me proteger contra o controle do cliente" - talvez estejamos confundindo a solução com o problema aqui. :)

Oi,

Parece que esse problema não é apenas sobre backup criptográfico assimétrico, mas mais sobre diferentes vetores de ataque.
Eu não li o código, então eu realmente tenho uma pergunta ingênua, mas meu caso de uso é principalmente sobre poder fazer backup de dados sem revelar a chave secreta (usando a chave pública de uma chave privada offline do proprietário do backup). Para esse caso de uso, é fácil de implementar?

Minha compreensão sobre o assunto é que agora todos os blobs estão criptografados com a mesma chave e funciona muito bem.
Se usássemos a criptografia assimétrica da maneira como o OpenPGP funciona, cada instantâneo feito geraria uma chave simétrica criptografada com a chave pública e a adicionaria ao repositório. Mas acho que o problema é que, para ser capaz de descobrir o que desduplicar e o que fazer backup, você deve ser capaz de ler as informações primeiro, portanto, você também precisaria da chave privada. Isso está certo?
Se for esse o caso, alguma prova de conhecimento zero poderia ajudar nesse sentido?

@dolanor , não adicione novos casos de uso ou perguntas a este problema, use o fórum para perguntas. Além disso, é muito cedo para falar sobre os detalhes de implementação.

Eu atualizei o resumo no primeiro post. O back-end rclone foi adicionado entretanto, ele pode ser usado como um "adaptador" conforme descrito acima e acessado, por exemplo, via SSH.

Por outro lado, uma vez que os invasores obtêm acesso a um servidor, eles podem facilmente extrair as credenciais para acessar o back-end e a senha restic

Espero que seja um erro de digitação: vocês, homens, o material do arquivo de chave criptografado aqui, não? Esperançosamente, um invasor que obtém acesso ao servidor não tem acesso à senha em texto simples. O pior que eles podem fazer é tentar aplicar força bruta ou adivinhar a "senha do usuário" que é usada para descriptografar as chaves mestras de criptografia e autenticação para o repositório.

Se isso estiver correto, eu recomendo que você altere o resumo novamente para esclarecer, porque com certeza parece ruim quando declarado dessa forma. :)

Esperançosamente, um invasor que obtém acesso ao servidor não tem acesso à senha em texto simples. O pior que eles podem fazer é tentar aplicar força bruta ou adivinhar a "senha do usuário" que é usada para descriptografar as chaves mestras de criptografia e autenticação para o repositório.

Acho que depende do cenário exato: se você está inserindo a senha manualmente, certo. Se você estiver fazendo backups automáticos agendados, por outro lado, a "senha do usuário" deverá ser armazenada em algum lugar do servidor.

E, é claro, um invasor pode trocar o binário Restic por um que vaza a senha inserida e esperar que você a insira. Você não pode confiar em um sistema comprometido.

a "senha do usuário" deverá ser armazenada em algum lugar do servidor.

por "servidor" você quer dizer "a máquina em que estamos executando o restic na qual salvamos os dados" ou "a máquina que recebe / armazena os dados do backup"?

é um tanto ambíguo, e a fonte da minha preocupação: não me importo com o cliente de backup (a máquina da qual estamos fazendo backup que está executando o Restic) tendo a senha em texto simples: todo o conjunto de dados está lá de qualquer maneira, se estiver comprometido, os dados estão comprometido de qualquer maneira. mas espero que o servidor de backup não tenha acesso ao texto não criptografado!

por "servidor" você quer dizer "a máquina em que estamos executando o restic na qual salvamos os dados" ou "a máquina que recebe / armazena os dados do backup"?

A máquina em que estamos rodando está na qual salvamos os dados.

Eu entendo seu ponto, você está certo, é ambíguo. Meu entendimento de tudo que sei sobre o modelo da Restic é o mesmo que o seu, tenho certeza disso, mas não posso dar a você a confirmação definitiva que você deseja.

O resumo menciona a opção --append-only para o servidor REST. Talvez esse deva permanecer como o único método oficialmente recomendado de backup somente com acréscimos, mas pode ser bom documentar quais arquivos em repouso precisam ser graváveis ​​para operação normal para ajudar a descobrir como configurar outras abordagens.

Acredito que restic backup funcionaria bem se data , index , keys e snapshots permitissem a criação de arquivos, mas não a modificação ou exclusão ( e config também foi protegido). No entanto, acho que locks precisaria permitir a exclusão para que o repositório não seja bloqueado permanentemente. Além disso, algumas implementações append-only (como o atributo para sistemas de arquivos ext4 e xfs) não são recursivas, então os 256 subdiretórios de dois caracteres de data precisariam ser pré-gerados primeiro e, em seguida, o atributo precisaria ser definido neles.

Alguns back-ends, como o S3, não oferecem suporte apenas para acréscimos, mas oferecem suporte para controle de versão de objeto, o que pode ter o mesmo efeito. No entanto, isso requer uma verificação cuidadosa do modelo de controle de acesso. Por exemplo, B2 tem regras de ciclo de vida que permitem o controle de versão de objetos, mas a chave API necessária para fazer backup em B2 tem a capacidade de modificar as regras de ciclo de vida (B2 realmente não tem muito sistema de permissão ainda).

Aparte: posso estar faltando alguma coisa, mas se a criptografia assimétrica for apenas proteger os dados históricos de um invasor que comprometeu o cliente, isso parece ser de baixa prioridade. Seria bom ter, mas na maioria dos casos os dados atuais são mais valiosos do que as versões anteriores (embora às vezes algo valioso seja acidentalmente copiado, excluído, mas não eliminado).

@willsALMANJ boas observações. Para o S3, eu me pergunto se as versões de objeções poderiam ser gravadas para permitir a obtenção de uma visão coerente dos blobs necessários para restaurar um determinado instantâneo (embora você possa validá-los com base em seus conteúdos, então não é super importante).

Re: seu último parágrafo:

• O principal benefício da criptografia assimétrica, além do cenário de "descriptografar coisas históricas" que você mencionou, é ser capaz de armazenar backups de várias máquinas independentes no mesmo repositório de backup sem ter que provisionar chaves individuais (o que requer o armazenamento da chave de backup em algum lugar cada vez que você instalar uma nova máquina cliente). Se você usar uma chave compartilhada, terá o cenário de ameaça irritante em que o cliente1 pode ler os dados do cliente2, o que não é o ideal.

@ fd0 Acho que tenho um esquema decente para criptografia assimétrica usando endereçamento HMAC com segredos compartilhados derivados. Além disso, algumas ideias sobre a coleta de lixo do lado do servidor sem vazamento de dados. Não tenho certeza se você está interessado, mas se estiver, gostaria de falar sobre isso.

Não sei se perdi algo aqui, mas estou executando o Restic com êxito com esta configuração de política no armazenamento S3. Isso não impede que um invasor leia os dados, mas evita que ele os exclua.

{
  "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/*"
    }
  ]
}

Os comandos prune / forget são executados a partir de um dispositivo confiável com permissões de gravação. Eu também crio duas chaves em cada repositório restic. Um para o servidor e outro para o dispositivo confiável, de modo que o dispositivo confiável possa bloquear um invasor (mas o invasor não pode, pois não pode excluir nas chaves / *).

Edit: Desculpe, esquecido que isso já foi discutido. Não queria sequestrar este tópico.
PutObject é realmente capaz de sobrescrever objetos, portanto, esta não é uma solução para proteger backups .

@freswa Eu não sou um especialista S3, então não tenho certeza se isso está correto, mas o ponto que foi levantado acima nesta discussão é que a permissão PutObject pode ser usada para sobrescrever seus dados, que é tão ruim quanto como excluí-lo. Em minha postagem acima, observei que você poderia contornar esse problema usando o controle de versão de objeto (não conceda ao sistema de backup acesso para excluir versões).

@andrewchambers Estou um pouco sobrecarregado com outras coisas, vamos falar sobre suas idéias assim que começarmos a realmente implementar isso! Sim, estou interessado;)

Portanto, esse problema é sobre (eventualmente) implementar backups assimétricos, não acessar a configuração para o armazenamento de back-end. Obrigado! :)

@ fd0 Espero que isso explique o que eu quis dizer https://packnback.github.io/blog/dedup_and_encryption/

@andrewchambers : Caso você ainda não tenha encontrado o problema de somente gravação (que você mencionou em seu site), é https://github.com/ncw/rclone/issues/2499.

@andrewchambers obrigado por escrevê-lo, estou muito interessado em como é a implementação real. A postagem do blog deixou algumas partes interessantes em aberto :)

Eu gosto do fato de que haverá outro competidor no espaço dos programas de backup de software grátis, dar aos usuários mais opções é sempre bom!

Portanto, um paralelo interessante pode ser feito com os dois mecanismos de criptografia do repositório git.

Por um lado, você tem git-crypt : ele usa filtros git

Por outro lado, você tem git-remote-gcrypt : que usa o protocolo git remote helpers para criptografar tudo que é enviado ao servidor. Mas isso é muito ineficiente, porque todo o repositório é criptografado novamente em cada execução, devido à forma como os controles remotos especiais funcionam.

Agora, esses são desafios de implementação específicos do git, mas acho que eles mapeiam bem os problemas que você pode encontrar aqui. Talvez eu esteja totalmente fora do meu alcance aqui e esse paralelo seja irrelevante, mas achei que pode ser de interesse aqui ...

Como um aparte, há um meio-termo que pode atualmente ser implementado (provavelmente) com bastante facilidade: permitir que as chaves sejam armazenadas fora do repositório.

Um dos vetores de ataque que está sendo abordado é que o invasor obtém uma senha de chave e, em seguida (uma vez que as chaves são armazenadas no repositório), ele pode descriptografar uma chave com facilidade.

E se permitirmos a especificação de um diretório de chave separado, onde os arquivos de chave são armazenados? Este diretório pode ser armazenado localmente em cada máquina que precisa fazer backups e pode ser feito o backup em um provedor de nuvem diferente, ou até mesmo um código QR (~ 500 bytes é muito pequeno para ser codificado por QR) para armazenamento off-line frio em um cofre, por exemplo.

Se as chaves criptografadas nunca tocam um provedor de nuvem, o vetor de ataque desaparece completamente. As chaves teriam que ser comprometidas nas instalações físicas ou exfiltradas com malware, por exemplo.

Isso _ já pode ser feito no Restic_ se uma cópia local do repositório for mantida - apenas exclua o diretório de chaves da sincronização com o remoto não confiável ao executar o rclone. Isso _não_ pode ser feito se não houver uma cópia local e o restic interagir diretamente com o controle remoto não confiável.

Acho que devemos aplicar o princípio da responsabilidade única e dividir as coisas em 2 tarefas:

1. Mantenha os dados protegidos contra descriptografia.
2. Mantenha os dados protegidos contra ação de exclusão não autorizada.

Eles são 2 aspectos diferentes da segurança de dados. Tecnicamente, eles não precisam depender uns dos outros.

Para (1), obviamente podemos "simplesmente adicionar suporte à criptografia assimétrica". Para (2), acredito que haja muitas soluções possíveis (por exemplo, conforme mencionado acima, configuração S3 somente para anexos).