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. Mesmo que a chance de isso acontecer seja menor do que outros tipos de riscos se o SSH e a segurança da senha estiverem configurados corretamente e o sistema for mantido devidamente atualizado, a quantidade de danos que podem ser causados permanentemente é muito alta e, portanto, eu gostaria de encontrar uma solução para limitar isso.
Eu já tentei duas formas de backups externos:
uma montagem webdav gravável pela raiz simples (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 deixado aberto como uma pasta no sistema de arquivos. Isso é proteção suficiente contra muitos tipos de ataques se a montagem tiver privilégios de acesso limitados (acesso somente root de leitura), mas não protege contra uma pessoa mal-intencionada com acesso root.
Backup Borg através de 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 formas, mas não sei como e com o quê:
- 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:
- Um trabalho 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?
Todas as suas sugestões atualmente têm uma coisa em comum: a origem do 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 propósito, 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 sobrescrever os 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 seu armazenamento de backup imutável ou, pelo menos, fornecer um controle de versão confiável que ofereça imutabilidade eficaz. 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 suspeito que o Azure e o Google oferecem um serviço semelhante. Você provavelmente poderia configurar um servidor para fazer isso, mas não sei como.
Quando você tem um repositório imutável / controlado por versão, você pode restaurar seu backup para qualquer ponto, portanto, se seu host estiver comprometido, você ainda poderá restaurar como em qualquer momento.
*AWS S3**
Estou mais familiarizado com o AWS S3. O S3 fornece armazenamento criptografado com versão, com alto nível de durabilidade.
O S3 oferece suporte ao controle de versão, o que oferece imutabilidade efetiva. Você pode optar por usar regras de ciclo de vida para excluir a versão antiga dos arquivos após um período de tempo que você pode configurar. Você também pode arquivar versões no armazenamento frio (arquivo frio glaciar), que custa cerca de US$ 1/TB/mês.
Você pode usar a classe de armazenamento em camadas inteligente para reduzir custos. Eu escolho usar uma regra de ciclo de vida para mover todos os dados estáticos para a classe de acesso pouco frequente, que é durável e com desempenho moderado (quente), mas não tem a escalabilidade ou desempenho do padrão S3.
O S3 usa usuários e políticas do IAM (gerenciamento de acesso de identidade, ou seja, gerenciamento de usuários). Isso lhe dá 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 multifator para excluir arquivos ou até mesmo fornecer um bloqueio de objeto para que os arquivos não possam ser excluídos.
Software sugerido
Eu crio backups incrementais usando Restic . O Restic carrega os novos arquivos para seu local de armazenamento. Acredito (mas posso estar incorreto) que ele cria novos arquivos, mas no funcionamento geral não atualiza ou 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 para 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 autenticação multifator necessária para excluir arquivos do S3.
Você pode ter outro usuário do IAM, executado, digamos, no seu PC, que faz a limpeza periódica do arquivo, descartando versões de acordo com a política que você definiu.
O Borg Backup suporta repositórios remotos somente anexados . Qualquer comprometimento do servidor que está sendo submetido a backup pode resultar apenas na criação de novos backups, não na substituição apenas dos antigos.
O problema fundamental é que, se você pode acessar remotamente seus backups , o hacker também pode .
Limitações técnicas são feitas para serem superadas.
As unidades de fita fornecem proteção segura e externa 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 dar à sua conta root permissões PUT para seu bucket, mas não permissões DELETE. Dessa forma, você pode usar um modelo push e o invasor não poderá excluir o backup.
Existem outras medidas de segurança que você pode tomar com a AWS, como exigir que o MFA execute DELETEs no bucket, mas permitir PUTs e GETs sem MFA. Dessa forma, você pode fazer backup de seus dados e recuperá-los para restaurar seus serviços sem usar seu dispositivo MFA, o que pode ser útil em algum caso extremo (e provavelmente muito obscuro para mencionar) em que acessar o dispositivo MFA pode comprometê-lo.
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.
Você pode usar o comando option em suas chaves_autorizadas. Você corrige o comando permitido em remote.
como adicionar comandos em ssh authorized_keys
Mesmo que um invasor recupere o login root, 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 em sua extremidade, para que a eliminação do lado do servidor não resulte em eliminação externa.