Backup apenas por pull. Porque é que a produção nunca deve chegar aos seus próprios backups

A maioria dos desenhos de backup é construída para a falha que toda a gente imagina: um disco morto, uma tabela apagada, uma atualização que correu mal. A falha que realmente acaba com empresas é outra. Alguém entra num servidor de produção, encontra as credenciais do backup ali mesmo, e apaga os backups antes de encriptar tudo o resto. Este artigo explica como desenhar backups que sobrevivem a esse dia, com o padrão segundo o qual construímos: o lado do backup faz pull, a produção nunca faz push, e as chaves que criam backups não os conseguem destruir.

O problema do push

O backup mais simples é um cron job no servidor que copia dados para um destino de backup. É fácil de montar, e traz consigo uma falha estrutural. Para fazer push, o servidor de produção precisa de uma rota para o destino de backup e de credenciais que possam escrever nele. Muito frequentemente essas credenciais também podem apagar, sobrescrever ou fazer prune, porque a retenção tem de acontecer em algum lado e o cliente é o sítio óbvio.

Por isso, o servidor que está a proteger guarda as chaves da sua própria proteção. Quem controla esse servidor controla os seus backups. Os operadores de ransomware sabem-no, e a primeira coisa que uma intrusão competente faz é procurar agentes de backup, shares de backup montados e chaves SSH que apontam para hosts de armazenamento.

Montar um share de backup no host de produção é a pior forma disto. Um share em que a produção pode escrever é, do ponto de vista do atacante, apenas mais disco para encriptar.

Inverta a seta

A solução é inverter a direção da confiança. O sistema de backup inicia todas as ligações. Entra na produção, leva o que precisa e sai. A produção não tem caminho de rede para a infraestrutura de backup e não guarda credenciais para ela.

Imponha-o onde não pode ser desfeito a partir de um host comprometido: na firewall entre as duas zonas, não na firewall de host do servidor de backup. O conjunto de regras é curto:

permit ip <management-subnet> host <backup-host>   ! admin access only
deny   ip any host <backup-host>                    ! production and everyone else
permit ip any any                                   ! leave other traffic alone

O próprio host de backup precisa de acesso de saída para a produção nas portas que usa para recolher dados, e de nada de entrada exceto a partir da gestão. Se uma ligação a partir de um host de produção continuar a ter sucesso, o desenho não está em vigor, diga o diagrama o que disser.

É um padrão de data diode no espírito, e corresponde de forma clara aos controlos sobre os quais os auditores perguntam: segregação da infraestrutura de backup, privilégio mínimo e proteção de fronteiras na ISO/IEC 27001, na NIS2 e na NIST SP 800-53.

Privilégio mínimo do lado da produção

Fazer pull continua a significar que o host de backup inicia sessão na produção. Essa sessão tem de ser inútil para tudo exceto fazer um backup. Com SSH isto é simples: dê à chave do host de backup um forced command e a opção restrict no authorized_keys do servidor de produção.

command="rrsync -ro /srv/www",restrict ssh-ed25519 AAAA... backup-files
command="/usr/local/bin/backup-dump",restrict ssh-ed25519 AAAA... backup-db

A primeira chave só consegue ler a raiz web através de rrsync em modo só de leitura. A segunda só consegue correr um wrapper de dump escrito por si, que faz um dump consistente da base de dados (para MySQL ou MariaDB, a partir de uma réplica ou de um nó que não recebe escritas, com --single-transaction ou com uma ferramenta física como o Percona XtraBackup) e o envia para a saída padrão. Nenhuma das chaves dá shell, port forwarding ou agent forwarding. Se o próprio host de backup fosse comprometido, o atacante ganharia acesso de leitura aos dados de um cliente, não o controlo da produção.

Use chaves separadas para trabalhos separados, e chaves separadas para clientes separados. O raio de impacto deve ser um trabalho num cliente.

Torne o repositório append-only

A segunda metade do desenho é o que acontece do lado do backup. Com o BorgBackup, o archiver com deduplicação, compressão e encriptação, um repositório pode ser acedido em modo append-only: novos archives podem ser escritos, mas os dados existentes não podem ser apagados nem reescritos através desse caminho de acesso.

Quando o próprio Borg tem de correr na origem (por exemplo, porque uma raiz web tem milhões de ficheiros pequenos e quer que a deduplicação aconteça antes de os dados atravessarem a rede), pode continuar a manter o hub no comando. O hub abre a sessão SSH para o host de produção e fornece um túnel reverso de volta para si próprio, e a conta na outra ponta desse túnel está bloqueada no hub:

command="borg serve --append-only --restrict-to-repository /srv/backup/tenants/<customer>/borg",restrict ssh-ed25519 AAAA... customer-node

O host de produção nunca inicia nada. Só fala de volta através do túnel que o hub abriu, e só para o seu próprio repositório, em modo append-only.

A retenção torna-se então um trabalho separado e local no hub:

borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6 /srv/backup/tenants/<customer>/borg
borg compact /srv/backup/tenants/<customer>/borg

Corra-o como um trabalho privilegiado no próprio host de backup, nunca através do caminho que a produção consegue ver. Um atacante que encripta o servidor de um cliente pode, na pior das hipóteses, escrever mais archives. Não consegue remover os antigos.

Um repositório, uma chave, um cliente

Numa plataforma de backup com vários clientes, dê a cada cliente o seu próprio repositório e a sua própria passphrase, com a encriptação ativada no momento em que o repositório é criado:

borg init --encryption=repokey-blake2 /srv/backup/tenants/<customer>/borg

O isolamento passa então a valer na camada criptográfica, não apenas nas permissões de ficheiros: os dados de um cliente não podem ser lidos com a chave de outro cliente, nem mesmo por alguém com shell no hub. A deduplicação continua a funcionar bem dentro de um cliente, e entre os nós web quase idênticos de um mesmo cliente o segundo nó não custa quase nada.

Prove-o, não confie

Um job de backup verde diz-lhe que o job correu. Não lhe diz que todas as máquinas que importam foram cobertas, nem que os dados regressam. Três hábitos fecham essa lacuna.

1. Verifique a cobertura contra o inventário em produção. Liste o que está a correr, liste o que tem um backup fresco em disco, e compare. Qualquer coisa a correr sem um ponto de restauro recente é um achado.
2. Vigie a frescura, não o estado. Alarme sobre as «horas desde o último archive bom» por cliente, para que um job que deixa silenciosamente de correr seja notado depressa.
3. Restaure com regularidade. Extraia ficheiros, restaure uma base de dados numa instância descartável e verifique-a, regularmente. O Borg torna isto barato:

borg list /srv/backup/tenants/<customer>/borg
borg extract --dry-run /srv/backup/tenants/<customer>/borg::<archive>
borg check --verify-data /srv/backup/tenants/<customer>/borg

Os restores também seguem a regra do pull. O host de backup, ou um engenheiro, entrega os dados restaurados à produção. À produção nunca é dado acesso ao repositório, nem sequer «só para o restore».

O que verificar na sua própria plataforma

• Algum servidor de produção consegue abrir uma ligação para o armazenamento dos seus backups? Experimente.
• Alguma credencial num servidor de produção permite apagar ou fazer prune dos backups?
• Há algum share de backup montado, com escrita, em algum host de produção?
• As chaves de backup estão restritas a um único comando, ou dão shell?
• Cada cliente ou sistema está no seu próprio repositório encriptado com a sua própria chave?
• Quando foi a última vez que restaurou algo, e verificou o resultado?

Se alguma resposta o deixar desconfortável, comece pela regra da firewall. É o controlo mais barato desta lista e remove primeiro o caminho mais perigoso.

Se quiser um segundo par de olhos sobre o desenho dos seus backups, os nossos engenheiros terão todo o gosto em ajudar. Fale com um engenheiro

Related

Relacionados: Managed backup com Veeam e Borg, pull-only · Disaster recovery e réplicas num segundo site