Backups “somente push”?

Question

Eu tenho um servidor que envia seus backups para algum espaço de backup online. Um intruso (no servidor que envia para o espaço de backup) pode acessar o espaço de backup e mexer com os backups, porque as credenciais estão no servidor. Gostaria de corrigir esse problema sem configurar um servidor de backup.

Alguém se preocupa com esse problema ou é mesmo um problema?

Existe um nome para este problema e quais são as soluções possíveis?

    

Answer 1

O problema que você está referenciando é realmente um problema de proteger / proteger seus backups depois de criá-los.

1. A abordagem padrão para esse problema é usar alguma forma de mídia removível que seja retirada regularmente.

   • Normalmente, com a mídia de fita LTO, você terá todas as suas fitas de backup giradas fora do site regularmente, de modo que as únicas fitas de backup existentes no site sejam ativamente ativadas na biblioteca de fitas para registrar dados de backup. .
   • Eu também já vi isso feito com unidades flash USB e unidades removíveis, ocasionalmente. Essa abordagem protege seus backups contra ações mal-intencionadas e desastres físicos.
     
     
2. Uma abordagem ligeiramente diferente dessa abordagem é usar mídia de gravação única, para que os backups não possam ser excluídos depois que forem feitos.
   • CDs / DVDs ou mídia WORM LTO, geralmente. Normalmente, essa abordagem é um pouco mais limitada em escopo, porque pode ser cara e exigir muito esforço rapidamente.
     • Por exemplo, em um ambiente de alta segurança em que trabalhei, tínhamos scripts para copiar os logs do servidor para um servidor de backup de forma contínua e depois gravá-los em um DVD todas as noites, como um mecanismo para preservar o informações neles. No caso de algo dar errado ou sermos hackeados, acabar com os logs no servidor em questão não faria muito bem.

Com a proliferação de sistemas de backup de disco para disco nos dias de hoje, nenhuma opção está sempre disponível ou viável, mas há muitas maneiras de conseguir a mesma coisa. Eles basicamente se enquadram em duas categorias.

1. Uma categoria, mencionada nos comentários , é o uso de criptografia de chave pública para permissões de leitura e gravação separadas em um nível criptográfico.
   • Um desses serviços é tarsnap . Como chaves diferentes são usadas para ler e gravar dados, você pode armazenar cada chave em um local diferente, para que um invasor que comprometa seus backups não possa lê-las.
   • O Tarsnap está longe de ser o único fornecedor desse serviço e você pode até mesmo implementar sua própria solução com ferramentas criptográficas de chave pública amplamente disponíveis. Presumivelmente, no entanto, eles ainda seriam capazes de "mexer com" os backups (destruí-los ou corrompê-los).
   • Isso é mais útil em situações de conformidade ou situações em que a privacidade de dados é importante e a preocupação é que um invasor consiga obter as informações (leia seus backups), mas não protege contra um invasor que destrua ou corrompa essas informações. backups.
     
     
2. A outra categoria é segmentar as permissões, para que o servidor de backup não tenha as permissões necessárias para alterar ou substituir dados.
   • A maneira mais óbvia de fazer isso é apenas dar permissões de leitura e gravação de servidor / serviço de backup em nível de sistema de arquivos, mas não modificar ou excluir permissões.
   • Você pode conseguir a mesma coisa separando o servidor de backup do servidor que hospeda os backups, para que comprometer os backups reais envolva mais do que comprometer o servidor usado para criar seus backups.
     • Essa é a abordagem que estou usando agora, por $ [corporate_overlord]. Os backups são replicados externamente (sistema disco-a-disco), mas o nó principal de backup e o nó externo são acessados usando contas diferentes, portanto, comprometer um nó não permite que o outro seja comprometido. Cada nó pode ler os dados do outro, mas cada nó só pode modificar / excluir seus próprios dados.
       
       
3. As duas abordagens podem até ser combinadas, para o verdadeiramente paranóico / melhor dos dois mundos.

Por fim, mesmo se você estiver usando um cenário de disco para disco, não há motivos para não implementar uma solução que efetivamente coloque seus backups offline. Você poderia configurar um sistema para colocar automaticamente o servidor / disco que armazena seus backups offline após os backups serem concluídos, e colocá-los de volta on-line apenas quando os próximos backups estiverem programados ou, menos drasticamente, remontar o volume que armazena seus backups como lidos -só. Parece mais trabalho do que configurar permissões como acima, mas é possível.

    

Answer 2

As pessoas obviamente se preocupam com esse problema, é por isso que existem serviços como tarsnap . Isso usa chaves separadas de leitura e gravação.

Para executar um backup, você só precisa ter a chave de gravação disponível.

Você pode manter a chave de leitura com segurança longe do sistema que está sendo armazenado em backup e disponibilizá-la somente quando precisar recuperar arquivos.

Os backups são criptografados usando as chaves antes de serem enviados para o serviço de backup.

    

Answer 3

Meu entendimento é que um servidor svnserve padrão (um que lida com o protocolo "svn: //" ou "svn + ssh: //" para um repositório de controle de versão do subversion) permite que as pessoas confirmem novas versões em um repositório, mas torna praticamente impossível "perder" versões previamente confirmadas no repositório.

(Seu espaço de backup online pode já ter configurado tal servidor para você).

    

Answer 4

A maneira como lidamos com isso é usar o amazon S3, que permite que novos objetos sejam gravados, mas não removidos pelas credenciais no servidor, e então use o versoning no bucket, mesmo que o intruso armazene backups inválidos no antigo (bom) ainda estão lá.

Funcionou muito bem até agora.