Backup externo seguro, mesmo no caso de acesso root de hackers

Estou procurando uma maneira de implementar uma maneira mais segura de fazer um backup externo que também proteja meus dados contra a situação em que um hacker mal-intencionado obteve acesso root ao meu servidor. Embora a chance de que isso aconteça seja menor do que outros tipos de riscos, se a segurança do SSH e da senha estiver configurada corretamente e o sistema for mantido atualizado, a quantidade de dano que pode ser permanentemente causado é realmente alta e, portanto, eu gostaria de encontrar uma solução para limitar isso.

Eu já tentei duas maneiras de backups externos:

• uma montagem webdav simples gravável em raiz (e configurada no fstab) na qual os dados de backup são copiados. Problema : não é realmente um backup externo porque a conexão - e além disso o acesso - ao local externo é constantemente deixada aberta como uma pasta no sistema de arquivos. Essa é uma proteção suficiente contra muitos tipos de ataques se a montagem tiver privilégios de acesso limitados (acesso somente leitura como root), mas não protege contra uma pessoa mal-intencionada com acesso root.

• Backup Borg através do SSH com autenticação de chave. Problema : a conexão com esse servidor externo pode ser feita com a chave armazenada no host se o usuário mal-intencionado tiver acesso root ao host.

Como solução, estou pensando nessas possíveis maneiras, mas não sei como e com o que:

• Os backups só podem ser gravados ou anexados ao destino, mas não excluídos.
• O uso de software de backup que lida com os backups externos e não oferece suporte à exclusão em massa dos backups externos do primeiro host.

Soluções que não são realmente interessantes na minha situação:

• Uma tarefa de backup extra no host externo que os transfere para um local que não é acessível pelo primeiro host (devido a limitações técnicas).

Alguém pode dar conselhos sobre como implementar um backup externo adequado para o meu caso?

Atualmente, todas as suas sugestões têm uma coisa em comum: a fonte de backup faz o backup e tem acesso ao destino do backup. Se você monta o local ou usa ferramentas como SSH ou rsync, o sistema de origem de alguma forma tem acesso ao backup. Portanto, um comprometimento no servidor também pode comprometer seus backups.

E se a solução de backup tiver acesso ao servidor? O sistema de backup pode fazer seu trabalho com acesso somente leitura, portanto, qualquer comprometimento no sistema de backup provavelmente não comprometeria o servidor. Além disso, o sistema de backup pode ser dedicado apenas para esse fim, tornando o conteúdo do backup o único vetor de ataque. Isso seria muito improvável e precisaria de um ataque realmente sofisticado.

Para evitar a substituição dos backups com conteúdo adulterado ou danificado, faça backups incrementais que permitam restaurar qualquer estado anterior dentro do período de restauração definido.

Armazenamento Imutável

Uma boa opção é tornar o armazenamento de backup imutável ou, pelo menos, fornecer versões confiáveis, o que oferece imutabilidade efetiva. Para ser claro: imutável significa incapaz de ser alterado ou permanente.

Existem vários serviços que podem fazer isso por você. AWS S3, BackBlaze B2 e eu suspeito que o Azure e o Google ofereçam um serviço semelhante. Você provavelmente poderia configurar um servidor para fazer isso, mas não sei como.

Quando você possui um repositório imutável / controlado por versão, pode restaurar seu backup para qualquer ponto; portanto, se seu host estiver comprometido, você ainda poderá restaurá-lo a qualquer momento.

* AWS S3 **

Estou mais familiarizado com o AWS S3. O S3 fornece armazenamento criptografado e com versão, com um alto nível de durabilidade.

O S3 suporta versão, o que oferece imutabilidade efetiva. Você pode optar por usar as regras do ciclo de vida para excluir a versão antiga dos arquivos após um período que você pode configurar. Você também pode arquivar versões no armazenamento a frio (arquivo a geleira), que custa cerca de US $ 1 / TB / mês.

Você pode usar a classe de armazenamento em camadas inteligente para reduzir custos. Eu escolhi usar uma regra de ciclo de vida para mover todos os dados estáticos para uma classe de acesso pouco frequente, que é durável e moderada (quente), mas não possui escalabilidade ou desempenho do padrão S3.

O S3 usa usuários e políticas do IAM (gerenciamento de acesso à identidade, ou seja, gerenciamento de usuários). Isso fornece um controle muito granular do que seu software de backup pode fazer com seu armazenamento. Você pode conceder ao usuário de backup permissão para uploads, mas negar a atualização e a exclusão. Você também pode exigir autenticação multifatorial para excluir arquivos ou até mesmo fornecer um bloqueio de objeto para que os arquivos não possam ser excluídos.

Software sugerido

Crio backups incrementais usando o Restic . O Restic carrega os novos arquivos no seu local de armazenamento. Acredito (mas posso estar incorreto) que ele cria novos arquivos, mas, em geral, não atualiza nem exclui nenhum arquivo.

Borg é outra opção. Eu costumava usar o Borg, mas descobri que, com meus backups de tamanho moderado de centenas de MB, ele efetivamente carregava todos os meus dados todos os dias do EC2 para o S3. Para mim, isso não é incremental, então parei de usá-lo. Encontrei documentação sobre isso, mas não tenho o link.

Existem dezenas de softwares que podem ser carregados no armazenamento em nuvem.

Armazenamento Protegido

Com algum software de backup, você pode tentar dar ao usuário do IAM permissão para gravar novos arquivos, mas não atualizar os arquivos existentes. É fácil fazer essa restrição com o AWS IAM, mas conforme o comentário abaixo, o Restic não funcionará com essas permissões. Você também pode ter a autenticação multifator necessária para excluir arquivos do S3.

Você pode ter outro usuário do IAM, executado a partir do seu PC, que faz a limpeza periódica do arquivo morto, descartando versões de acordo com a política que você definir.

O Borg Backup suporta repositórios remotos somente anexados . Qualquer comprometimento do backup do servidor pode resultar apenas na criação de novos backups, não substituindo apenas os antigos.

Soluções que não são realmente interessantes na minha situação:

Uma tarefa de backup extra no host externo que os transfere para um local que não é acessível pelo primeiro host.

O problema fundamental é que, se você pode acessar remotamente seus backups , o hacker também pode .

(Devido a limitações técnicas)

Limitações técnicas são feitas para serem superadas.

Alguém pode dar conselhos sobre como implementar um backup externo adequado para o meu caso?

As unidades de fita fornecem proteção externa segura contra todos os tipos de desastres - incluindo hackers - há quase 70 anos.

Você pode usar serviços de armazenamento como o AWS S3 (ou provavelmente o equivalente do Google ou do Azure), onde você pode conceder permissões PUT à sua conta raiz ao seu bucket, mas não as permissões DELETE. Dessa forma, você pode usar um modelo de envio e o invasor não poderá excluir o backup.

Existem outras medidas de segurança que você pode adotar com a AWS, como exigir que o MFA execute DELETEs no bucket, mas permita PUTs e GETs sem o MFA. Dessa forma, você pode fazer backup dos dados e recuperá-los para restaurar seus serviços sem usar o dispositivo MFA, o que pode ser útil em casos extremos (e provavelmente muito obscuros para mencionar) em que o acesso ao dispositivo MFA pode comprometer.

Além disso, um comentário fora do escopo que você pode achar interessante / útil, existem várias maneiras de configurar o S3 e serviços semelhantes para failover automático, caso a fonte de dados principal esteja offline.

Backup Borg através do SSH com autenticação de chave. Problema: a conexão com esse servidor externo pode ser feita com a chave armazenada no host se o usuário mal-intencionado tiver acesso root ao host.

Você pode usar o comando option em suas teclas_estabelecidas. Você corrige o comando permitido no controle remoto.

como adicionar comandos no ssh allowed_keys

Mesmo se um invasor recuperar a raiz de login, ele não poderá fazer nada além do comando definido.

Uma técnica que você pode configurar é usar a sincronização entre o servidor e um servidor de backup remoto e permitir que o servidor de backup remoto faça instantâneos ou qualquer outra coisa para que o apagamento do lado do servidor não resulte em apagamento externo.