Pular para o conteúdo

Checklist: o seu backup resiste a um ransomware?

Marque o que já está assim hoje. No fim aparece uma nota e, para cada item em aberto, o que fazer. Vale para qualquer ferramenta de backup que grave em bucket S3; os atalhos apontam para o Arkame quando ele tem o caminho pronto.

Nada sai do seu navegador: as respostas ficam guardadas só neste aparelho, e você pode limpar quando quiser.

  1. Por quê: Sem versões, um arquivo criptografado sobrescreve o bom, e o backup seguinte copia o estrago.

  2. Por quê: Versionamento sozinho não protege contra quem tem a chave: ela apaga as versões. Object Lock sem retenção padrão também não protege nada.

  3. Por quê: Em Governance, quem tem a permissão certa passa por cima do bloqueio. Em Compliance, ninguém apaga antes do prazo.

  4. Por quê: Ransomware costuma ficar quieto antes de agir. Se a retenção vence antes de você notar, as versões boas já podem ter saído.

  5. Por quê: Bucket público expõe os backups a qualquer um que descubra o endereço.

  6. Por quê: Uma chave da conta inteira, vazada do servidor, abre todos os buckets e todas as configurações.

  7. Por quê: Com Object Lock o Arkame não apaga versão nenhuma; a permissão que sobra só serve a quem roubar a chave.

  8. Por quê: A cópia esquecida da senha é a porta que ninguém vigia.

  9. Por quê: Cópia ao alcance do servidor é criptografada junto; cópia no mesmo prédio vai embora no mesmo incêndio.

  10. Por quê: Backup manual é backup de quando alguém lembrou.

  11. Por quê: Backup que nunca foi restaurado ainda é uma hipótese, e o dia do ataque é o pior dia para descobrir.

  12. Por quê: Copiar os arquivos de um banco em uso costuma gerar uma cópia que não abre.

  13. Por quê: Backup parado em silêncio é descoberto no dia em que se precisa dele.

  14. Por quê: Com a senha de quem administra, o atacante desliga o backup ou apaga o que não estiver travado.

Resultado

0 de 14 itens cumpridos

Em risco

Falta pelo menos um item essencial. Comece por eles: são os que decidem se o backup sobrevive ao ataque.

O que falta

  • O versionamento está ligado no bucket do backup.essencial

    O que fazer: Ligue o versionamento no bucket: Backblaze B2 (já vem ligado), Wasabi, AWS. O agente do Arkame recusa bucket sem versionamento.

  • O Object Lock está ligado, com uma retenção padrão no bucket.essencial

    O que fazer: Na Wasabi, o Object Lock só liga na criação: crie um bucket novo e aponte o plano para ele. Na B2, ligue na criação também, porque a retenção padrão pede isso. Passo a passo: Backblaze B2, Wasabi, AWS.

  • A retenção padrão está em modo Compliance, não Governance.essencial

    O que fazer: Troque o modo da retenção padrão do bucket para Compliance. Na Wasabi, o padrão vem em Governance: veja como trocar.

  • O bucket é privado: nada de acesso público.essencial

    O que fazer: Tire o acesso público nas configurações do bucket no provedor (o que todo bucket precisa).

  • A chave do backup é só dele e só abre esse bucket. Não é a chave mestra nem a conta raiz do provedor.essencial

    O que fazer: Crie uma chave restrita ao bucket (política de acesso), troque no servidor com arkame-agent set-storage-keys --restart (comandos) e revogue a antiga no provedor.

  • O backup fica fora do servidor protegido e fora do prédio.essencial

    O que fazer: Mande o backup para um bucket num provedor de nuvem (compare os custos). Com um MinIO no mesmo prédio, o bucket existe, mas não está fora do site.

  • Alguém restaurou um arquivo do backup no último mês, e ele abriu.essencial

    O que fazer: Restaure um arquivo numa pasta nova e abra o arquivo. No Arkame, em Restaurar, por busca, pastas ou linha do tempo (restauração). Marque na agenda: todo mês.

  • A retenção dura mais do que você levaria para perceber um ataque (30 dias é um bom começo).

    O que fazer: Aumente a retenção padrão do bucket. Lembre que ela também é até onde ninguém pode apagar nada, nem você: pese contra o custo de guardar.

  • Com Object Lock, a chave do agente não tem permissão de apagar versões (onde o provedor deixa escolher).

    O que fazer: Na AWS e na Wasabi, tire s3:DeleteObjectVersion da política (por quê). Atenção: em bucket sem Object Lock, a limpeza da retenção do Arkame precisa dela.

  • A senha da chave não está em planilha, chat, e-mail ou repositório.

    O que fazer: Gere uma chave nova, troque no servidor (comandos), revogue a antiga e apague as cópias. No Arkame, a chave só existe no servidor: o painel nunca a recebe.

  • O backup roda sozinho, com horário, sem depender de alguém lembrar.

    O que fazer: No Arkame, dê um horário ao plano (diário ou a cada algumas horas) em Planos (planos).

  • Bancos de dados entram no backup como dump, não como os arquivos do banco aberto.

    O que fazer: Gere um dump antes do backup: no Arkame, com o comando de antes do backup do plano; no agente em Docker, onde esses comandos não rodam, agende o dump no próprio servidor (cron) numa pasta incluída no plano (detalhes).

  • Um aviso chega quando um backup falha ou um servidor para de responder, e alguém lê esse e-mail.

    O que fazer: No Arkame, confira em Configurações → Organização → Avisos por e-mail que os dois avisos estão ligados. Eles vão para o e-mail de cobrança da conta: garanta que ele chega a quem age.

  • O console do provedor e o painel de backup pedem verificação em duas etapas.

    O que fazer: Ligue a verificação em duas etapas no console do provedor e, no Arkame, em Configurações → Perfil.