Dois jeitos de perder tudo: por que backup de e-mail precisa ser imutável

Dois incidentes me marcaram na prática de gestão de TI. Em nenhum dos dois a empresa percebeu o problema no momento em que ele aconteceu. Os dois vieram à tona semanas depois, quando alguém precisou de um e-mail específico e a busca não retornou nada. Nenhuma mensagem. Nenhum anexo. Nenhum histórico.

O primeiro caso envolveu ransomware (software malicioso que criptografa dados e exige resgate para liberá-los). O segundo envolveu um desligamento de funcionário. Cenários completamente diferentes na superfície. Causa raiz idêntica no fundo: o backup estava no alcance de quem causou o dano.

Escrevo este artigo porque vejo empresas de médio porte repetindo o mesmo erro com frequência previsível. E porque construímos o AHSU 360, AntiHacking System UNODATA, exatamente para resolver essa lacuna com critérios técnicos que merecem ser explicados com clareza, não apenas vendidos como feature de catálogo.

O vetor que todo gestor conhece e subestima: ransomware

Um ataque de ransomware bem-executado segue uma sequência que raramente é improvisada. O invasor entra no ambiente, faz reconhecimento interno, identifica onde estão os dados críticos e, antes de ativar a criptografia, localiza e destrói ou corrompe as cópias de segurança acessíveis a partir daquele mesmo ambiente. Só então criptografa o alvo principal.

Isso significa que, se o backup do seu e-mail corporativo vive dentro do mesmo tenant (o ambiente gerenciado pelo provedor de nuvem onde sua empresa opera) que foi comprometido, ele já foi eliminado quando você recebe o aviso de sequestro. Você não tem o dado original. Não tem a cópia. Tem o pedido de resgate.

O detalhe que mais custa caro nas empresas que atendo: muitos gestores confundem o mecanismo de retenção do provedor com backup real. O provedor retém mensagens deletadas por 14, 30 ou 90 dias dependendo do plano contratado. Isso é retenção de lixeira, não backup isolado. Se o atacante tiver credencial administrativa válida, ele apaga as mensagens, esvazia a lixeira e aguarda o período de retenção expirar. Ou aciona a exclusão permanente direto. O prazo que parecia ser sua rede de segurança vira o prazo que falta para o dado sumir definitivamente.

O vetor que poucos documentam: o funcionário que sai

O segundo caminho de perda é mais silencioso e, por isso, mais negligenciado em política de segurança. O funcionário em processo de desligamento, seja voluntário ou involuntário, acessa a própria caixa de e-mail antes de perder o acesso. Apaga mensagens seletivamente. Esvazia a lixeira. Em alguns casos, encaminha dados para contas pessoais antes de limpar o rastro.

O que acontece depois depende inteiramente de como a empresa configurou o offboarding (processo de encerramento de acesso após desligamento). Se a caixa for desativada sem preservação, o conteúdo restante entra no ciclo de retenção padrão do tenant e some no prazo estabelecido pelo plano. Quando o time jurídico precisa do histórico de negociação daquele contrato que está em litígio, a resposta do provedor é: o prazo de retenção expirou.

Eu já acompanhei esse cenário em empresas que têm políticas de segurança bem redigidas no papel. O problema não estava na política. Estava na execução: ninguém tinha configurado preservação automática de caixas de usuários desligados em repositório fora do tenant.

A cópia que deveria te proteger precisa ser fisicamente inalcançável por quem causou o dano, seja um invasor externo ou um usuário interno com credencial válida.

As três características que definem um backup de e-mail que funciona de verdade

Depois de ver os dois cenários acontecerem mais de uma vez, cheguei a uma definição operacional simples. Backup de e-mail corporativo só cumpre função de proteção real quando reúne três características simultaneamente. Falta uma, a proteção tem brecha.

Fora do tenant

O backup precisa viver em infraestrutura completamente separada do ambiente operacional da empresa. Não é uma pasta diferente no mesmo servidor. Não é outra conta dentro do mesmo provedor de nuvem com acesso federado ao tenant principal. É uma separação real, onde uma credencial comprometida no ambiente de produção não concede nenhum caminho de acesso ao ambiente de backup.

Essa separação não é paranoia. É o mesmo princípio que faz um cofre físico ser guardado fora do escritório que ele protege.

Imutável

Imutabilidade significa que os dados gravados não podem ser alterados, sobrescritos ou deletados dentro de um período definido, independentemente de quem solicite a operação. Nem o administrador do sistema. Nem o suporte do provedor. Nem um script automatizado disparado por um invasor.

A imutabilidade é implementada via políticas de retenção com bloqueio (WORM, Write Once Read Many, ou seja, gravar uma vez e ler muitas vezes), onde o registro só pode ser lido ou copiado, nunca modificado na origem.

Sob controle da empresa

O terceiro ponto é o que mais gera atrito na negociação com provedores, e é exatamente por isso que precisa ser explicitado em contrato. Você precisa conseguir restaurar seus dados sem depender de um ticket de suporte que entra em fila, sem depender de um período de retenção que o provedor define unilateralmente, e sem pagar taxa de egress (custo de saída de dados da nuvem do provedor) para acessar o que é seu.

A pergunta operacional é direta: se hoje você precisasse restaurar todos os e-mails de um usuário desligado há seis meses, quanto tempo levaria e quem detém o controle desse processo?

O que o AHSU 360 resolve e por que construímos assim

O AHSU 360, AntiHacking System UNODATA, nasceu dessa observação de campo. Não de uma especificação técnica criada em laboratório, mas de casos reais onde empresas descobriram a lacuna da forma mais cara possível: depois que o dado sumiu.

O produto de correio que desenvolvemos tem esses três critérios no centro da arquitetura:

• Backup fora do tenant: o repositório de segurança é independente do ambiente operacional do cliente, sem caminho de acesso federado que um invasor possa atravessar.
• Imutabilidade por política: os e-mails arquivados ficam em retenção bloqueada pelo período contratado, sem que nenhuma credencial administrativa consiga executar exclusão antes do fim do prazo.
• Restauração sob controle do cliente: o processo de recuperação não depende de aprovação ou fila do nosso suporte. O cliente acessa, filtra e exporta o que precisa, no tempo que precisa.

Não listo nomes de componentes internos de infraestrutura aqui por uma razão simples: o que importa para o gestor não é saber qual tecnologia está por baixo, mas saber que as três garantias acima estão implementadas e auditáveis.

O que eu posso dizer com clareza é que o design foi feito para que as perguntas operacionais tenham resposta concreta:

1. Se o tenant for comprometido por ransomware, o backup está seguro?
2. Se um funcionário apagar a própria caixa antes do desligamento, o histórico está preservado?
3. Se o jurídico precisar de um e-mail de dois anos atrás amanhã de manhã, quanto tempo leva a restauração?

As três respostas precisam ser sim, sim e minutos. Se qualquer uma das três for diferente disso, a configuração atual tem brecha.

Fechar o ciclo antes que o incidente o feche por você

A pergunta que sempre faço em conversa com gestores de TI é simples: se hoje você fosse atacado, sua cópia de segurança está fora do alcance do invasor? Não no papel da política. Na prática, na configuração atual do ambiente.

A maioria hesita na resposta. Não por falta de intenção, mas porque nunca testou a restauração. Nunca mapeou os caminhos de acesso federado entre o tenant de produção e o repositório de backup. Nunca fez o exercício de simular o desligamento de um usuário-chave e verificar o que sobrou.

A regra que aprendi na prática é incômoda: você não sabe se o backup funciona até precisar dele de verdade. E quando precisa de verdade, não é hora de descobrir que ele estava no alcance de quem causou o problema.

Perguntas frequentes

O que diferencia a retenção de lixeira do provedor de um backup real de e-mail?

A retenção de lixeira é um mecanismo interno do tenant que mantém mensagens deletadas por um período configurável, geralmente 14 a 90 dias. Um backup real vive fora do tenant, em repositório separado e imutável, inacessível por credenciais do ambiente de produção. Se um invasor ou um administrador mal-intencionado tiver acesso ao tenant, a retenção de lixeira pode ser esvaziada. O backup externo e imutável não pode.

Quanto tempo uma empresa tem para recuperar e-mails de um funcionário desligado sem backup externo?

Depende do plano e do provedor, mas o prazo padrão de retenção de caixas inativas em provedores de nuvem varia de 30 a 180 dias após o desligamento da conta. Depois disso, os dados são excluídos permanentemente. Sem backup externo com imutabilidade, qualquer necessidade jurídica ou auditoria que surja após esse prazo não tem como ser atendida.

O que é WORM no contexto de backup de e-mail corporativo?

WORM é a sigla para Write Once Read Many, que em português significa gravar uma vez e ler muitas vezes. É uma política de armazenamento que impede qualquer alteração, sobrescrita ou exclusão dos dados gravados durante o período de retenção definido. No contexto de backup de e-mail, garante que nem o administrador do sistema consegue apagar o arquivo antes do prazo expirar, o que é fundamental contra ransomware e contra deleção intencional por usuário interno.

Como testar se o backup de e-mail da minha empresa realmente funciona?

O teste mínimo envolve três etapas: escolher um usuário de teste, deletar permanentemente algumas mensagens do ambiente de produção, e executar a restauração a partir do backup externo sem abrir ticket de suporte. Se a restauração depender de aprovação do provedor, se levar mais de uma hora, ou se os dados não estiverem disponíveis, a configuração tem lacuna. Esse exercício deveria ser feito ao menos uma vez por ano e documentado como parte da política de continuidade de negócios.