Qualquer solução que não inclua criptografia no lado do cliente com chaves mantidas pelo proprietário não atenderá ao primeiro requisito declarado (proteção / segurança IP) - qualquer invasão no lado do servidor divulga dados não criptografados. Isso exclui sistemas de sincronização em nuvem, como o Dropbox, que possui as chaves.
Para evitar a hospedagem das chaves de criptografia importantes no servidor do site, que provavelmente também serão invadidas em algum momento, eis o que eu faria:
- Servidor de backup interno no site do cliente - possui chaves de criptografia e chaves SSH para os outros dois servidores
- Servidor que hospeda o site - pode ser um host
- Servidor ou serviço de backup em nuvem
Etapa 1: o servidor (1) obtém o backup de (2), para que a maioria dos hacks do servidor do site não comprometa os backups. A criptografia ocorre neste momento.
- Eu usaria o rsnapshot sobre SSH usando login baseado em chave, pois isso tem requisitos mínimos no host da web e no servidor de backup interno - a menos que você tenha um banco de dados grande para fazer backup, ele é muito eficiente na largura de banda e armazena várias versões do site, e também lida com a remoção de backups antigos.
- A criptografia pode ser feita por qualquer ferramenta de arquivo para arquivo, como GPG, copiando a árvore rsnapshot para outra árvore - ou você pode usar a duplicidade na etapa 2, economizando espaço em disco.
- O "pull" do servidor de backup é importante - se o servidor principal (2) tiver as senhas / chaves do servidor de backup, os hackers poderão e algumas vezes excluirão os backups após invadir o servidor principal (veja abaixo). Os hacks realmente avançados podem instalar binários SSH trojanados que podem comprometer o servidor de backup, mas isso é menos provável para a maioria das empresas.
Etapa 2: o servidor (1) envia os backups criptografados para (3) para que haja um backup externo. Se os backups foram criptografados na etapa 1, você pode usar apenas um espelho rsync da árvore rsnapshot local no sistema remoto.
- A duplicidade seria uma boa opção para criptografar e fazer backup diretamente da árvore rsnapshot não criptografada no servidor remoto. Os recursos do Duplicity são um pouco diferentes do rsnapshot, usando arquivos tar criptografados por GPG, mas fornece criptografia de backup no host remoto e requer apenas SSH nesse host (ou pode usar o Amazon S3). A duplicidade não suporta links físicos , portanto, se isso for necessário (por exemplo, para um backup completo do servidor), é melhor que um script converta a árvore rsnapshot (que suporta links físicos) em um arquivo tar (talvez apenas os arquivos que possuem> 1 link físico, que será bem pequeno) para que a duplicidade possa fazer backup do arquivo tar.
- Como o servidor remoto é apenas um host SSH, possivelmente com rsync, pode ser um host da web (mas de um provedor de hospedagem diferente e em uma parte diferente do país) ou um serviço em nuvem que fornece rsync e / ou SSH - consulte esta resposta em backups rsync na nuvem por sua recomendação de bqbackup e rsync.net, embora eu não concorde com a configuração de backup mencionada.
- Você pode usar o Amazon S3 como servidor remoto com duplicidade, o que forneceria uma disponibilidade realmente boa, embora talvez custasse mais para backups grandes.
- Outras opções para backups criptografados remotos são Boxbackup (não tão maduro, alguns recursos interessantes) e Tarsnap (serviço de nuvem comercial baseado no Amazon S3 com interface de linha de comando simples, boa desduplicação e criptografia completa).
A segurança de todos os vários hosts é importante, portanto, isso deve ser ajustado para atender ao perfil de segurança do cliente, ou seja, analisar ameaças, riscos, vetores de ataque etc. O Ubuntu Server não é um começo ruim, pois possui atualizações de segurança frequentes para 5 anos, mas é necessária atenção à segurança em todos os servidores.
Essa configuração fornece dois backups independentes, um dos quais pode ser um serviço de armazenamento em nuvem altamente disponível, opera no modo pull, para que a maioria dos ataques no site não possa destruir os backups ao mesmo tempo, e usa ferramentas de código aberto comprovadas que não o fazem requer muita administração.
- Os backups independentes são críticos, porque os hackers às vezes excluem todos os backups ao mesmo tempo que invadiram o site - no caso mais recente, os hackers destruíram 4800 sites, incluindo backups invadindo o ambiente de hospedagem da Web, e não os sites. Veja também esta resposta e esta .
- A restauração é muito fácil com o rsnapshot - há um arquivo em cada árvore de instantâneo para cada arquivo copiado em backup, então encontre os arquivos com as ferramentas do Linux e rsync ou scp-os de volta ao site. Se o servidor de backup no local não estiver disponível por algum motivo, basta usar a duplicidade para restaurá-lo a partir do servidor de backup na nuvem - ou você pode usar ferramentas padrão como GPG, rdiff e tar para restaurar os backups.
Como essa configuração usa SSH e rsync padrão, deve ser mais fácil escolher um provedor adequado com garantias de tempo de atividade, segurança forte etc. Você não precisa se comprometer com um contrato longo e se o serviço de backup for catastrófico falha, você ainda tem um backup local e pode alternar para outro serviço de backup com bastante facilidade.