28 de maio de 2026 · 8 min de leitura · … visitas
A lacuna dos 30 dias: nuvem não é backup de e-mail
Microsoft 365 e Google Workspace apagam dados definitivamente após 30 dias. Entenda por que nuvem não é backup e o que sua empresa precisa fazer agora.
Tem uma pergunta que eu faço a todo gestor de TI que senta comigo. Se um funcionário apagar a caixa inteira hoje e sair amanhã, você recupera o quê? A resposta é quase sempre a mesma: “tá no Microsoft 365, tá seguro”. Não está.
Essa não é uma crítica à Microsoft nem ao Google. É uma questão de arquitetura que a maioria das empresas simplesmente não leu. O 365 e o Workspace foram desenhados para colaboração e continuidade de serviço, não para retenção arquivística. A lixeira do tenant, o espaço onde itens apagados ficam temporariamente disponíveis, tem validade de aproximadamente 30 dias. Depois disso, some. Sem aviso, sem recuperação, sem apelação.
Na UNODATA, rodamos correio para mais de 1.400 empresas no Brasil. Eu vi esse roteiro se repetir vezes demais: a empresa achava que tinha backup porque tinha nuvem. Quando o problema apareceu, a primeira ligação foi para o suporte da plataforma. A segunda foi para mim. E nessa segunda ligação, a conversa começa sempre com a mesma frase: “mas a gente achava que estava protegido”.
Este artigo existe para que você não precise fazer essa ligação.
O que a lixeira do tenant realmente é
Para entender a lacuna, é preciso entender o que Microsoft e Google oferecem por padrão. As duas plataformas têm mecanismos de recuperação de itens excluídos que funcionam em duas camadas.
A primeira camada é a lixeira do usuário. O item apagado fica disponível por 14 dias, a depender da configuração. A segunda camada é o que a Microsoft chama de “Itens Recuperáveis” e o Google chama de “Lixeira do Vault”, onde o item permanece por mais alguns dias antes de ser expurgado definitivamente. O prazo total gira em torno de 30 dias, podendo chegar a 93 dias em cenários com políticas de retenção pagas ativadas no Microsoft Purview, mas isso não é o padrão e exige licença adicional.
O ponto central é: nesses modelos, a retenção é controlada dentro do próprio tenant. O administrador do tenant, o gestor de TI, o próprio usuário com permissão elevada, qualquer um deles pode apagar e também pode acelerar o expurgo. Isso cria um problema estrutural:
Backup é uma cópia que vive fora do alcance de quem apaga, que não pode ser sobrescrita e que você consegue restaurar de forma autônoma. O que a nuvem oferece por padrão não é isso.
Se o mesmo ambiente que armazena o e-mail também controla a janela de retenção, você não tem backup. Você tem cortesia de curto prazo.
Os três momentos em que a lacuna aparece
Ninguém descobre essa limitação num dia tranquilo. A descoberta acontece em três cenários, e todos eles têm custo alto.
Ransomware com exfiltração. O ataque moderno não se limita a criptografar arquivos. Ele apaga cópias locais, move itens para lixeira e, passados os 30 dias, os dados somem antes que a empresa perceba o que aconteceu. Se o backup estava no mesmo tenant que foi comprometido, a recuperação é parcial na melhor hipótese.
Processo trabalhista ou litígio regulatório. A auditoria pede o histórico de comunicações de um colaborador dos últimos dois anos. A janela de retenção padrão do 365 ou do Workspace não cobre dois anos. O dado não existe mais. A empresa não tem como provar o que foi dito, acordado ou decidido por e-mail.
Saída de colaborador com má-fé. O funcionário apaga a caixa antes de sair. Trinta dias depois, outro colaborador precisa de um contrato, de uma proposta, de uma thread com o cliente. Sumiu. A nuvem não tem o que restaurar porque o prazo já passou.
Estes três cenários têm uma característica em comum: o problema é descoberto quando a janela de recuperação já fechou.
O que diferencia backup real de retenção temporária
A confusão entre nuvem e backup não é ingenuidade. É consequência de marketing bem feito. “Seus dados estão na nuvem” virou sinônimo popular de “seus dados estão seguros”. Mas segurança operacional e proteção contra perda de dados são coisas distintas.
Backup de e-mail corporativo, quando feito de forma adequada, deve atender a quatro critérios objetivos:
- Cópia independente do tenant original. O backup precisa existir num ambiente que não pode ser afetado por uma ação dentro do 365 ou do Workspace. Se o tenant for comprometido ou o e-mail for apagado, a cópia não pode estar sujeita ao mesmo acesso.
- Imutabilidade por período definido. A cópia não pode ser sobrescrita ou apagada pelo mesmo usuário que gerou ou excluiu o item original. Políticas de retenção imutável (WORM, write once read many) garantem que o dado existe exatamente como estava no momento do backup.
- Prazo de retenção compatível com o risco jurídico. Dependendo do setor, a legislação brasileira exige retenção de comunicações por dois, cinco ou até dez anos. O prazo de retenção do backup precisa ser definido por política, não pelo padrão da plataforma.
- Restauração autônoma e verificável. O backup que nunca foi testado não é backup, é suposição. A empresa precisa conseguir restaurar uma caixa específica, de uma data específica, sem depender de ticket aberto na plataforma de origem.
O AHSU 360 (AntiHacking System UNODATA, solução de proteção de ambientes de e-mail corporativo que desenvolvemos na UNODATA) foi desenhado exatamente para cobrir esses quatro critérios em ambientes que já usam 365 ou Workspace como plataforma de e-mail. A ideia não é substituir a plataforma. É adicionar a camada que ela não entrega por padrão.
Por que o prazo de retenção precisa ser uma decisão de negócio, não de TI
A definição de por quanto tempo guardar um e-mail não é uma configuração técnica. É uma decisão que envolve jurídico, compliance, RH e a direção da empresa. A TI executa. Mas a política precisa vir de cima.
Na prática, o que eu vejo é o contrário. O gestor de TI escolhe o plano que cabe no orçamento, ativa as opções padrão e assume que está coberto. O jurídico nunca foi consultado sobre prazo de retenção de e-mails. O RH não sabe que a caixa de um ex-funcionário some depois de 30 dias se não houver política ativa. E a diretoria só descobre quando o problema já aconteceu.
Definir prazo de retenção de e-mail é uma decisão de gestão de risco. Deveria estar na mesma reunião que seguro, compliance fiscal e política de privacidade.
Como revisar sua situação hoje
Se você ainda não tem clareza sobre o que acontece com seus e-mails corporativos após 30 dias, o caminho é direto. Não precisa de projeto longo nem de consultoria cara para começar.
Faça estas quatro perguntas ao seu gestor de TI ou ao fornecedor de e-mail:
- Onde está a cópia de backup dos e-mails corporativos, separada do tenant do 365 ou do Workspace?
- Qual é o prazo de retenção atual e quem definiu esse prazo?
- Quando foi o último teste de restauração de uma caixa completa?
- Se um administrador apagar uma caixa hoje, em quanto tempo o backup seria a única forma de recuperar os dados?
Se qualquer uma dessas respostas for “não sei”, “nunca testamos” ou “está no padrão da plataforma”, você tem trabalho a fazer antes que o problema apareça.
A boa notícia é que esse é um dos poucos problemas de segurança da informação que tem solução conhecida, custo previsível e implementação relativamente rápida. O pior cenário é descobrir a lacuna depois do ransomware ou depois da intimação judicial.
Na UNODATA, quando a conversa começa com “preciso recuperar e-mails de dois anos atrás”, quase sempre já é tarde. Quando a conversa começa com “quero entender meu risco atual”, ainda dá para resolver antes.
Qual é o prazo real de retenção dos seus e-mails corporativos hoje? Se você não sabe responder de cabeça, talvez essa seja a conversa mais importante que você faça essa semana.
Perguntas frequentes
O Microsoft 365 não faz backup automático dos e-mails?
Não no sentido técnico correto do termo. O 365 mantém itens excluídos na lixeira do tenant por até 30 dias no plano padrão, podendo estender com licenças adicionais do Microsoft Purview. Mas essa retenção vive dentro do mesmo ambiente que pode ser comprometido ou administrado pelo mesmo usuário que apagou o dado. Backup de verdade exige cópia imutável e independente do tenant original.
Qual é o prazo mínimo de retenção de e-mails que uma empresa brasileira deve manter?
Depende do setor e do tipo de comunicação. A CLT e o Código Civil estabelecem prazos prescricionais de dois a cinco anos para ações trabalhistas e contratuais. Setores regulados como financeiro e saúde têm exigências específicas que podem chegar a dez anos. A definição precisa ser feita com o jurídico da empresa, não pelo padrão da plataforma de e-mail.
O que é imutabilidade de backup e por que ela importa?
Imutabilidade significa que a cópia gravada não pode ser alterada ou apagada pelo período definido, nem mesmo por um administrador. Tecnicamente, isso é implementado com políticas WORM (write once read many, ou seja, grava uma vez e lê muitas vezes). Sem imutabilidade, um atacante com acesso administrativo pode apagar o backup junto com os dados originais, tornando a recuperação impossível.
Como o AHSU 360 resolve a lacuna dos 30 dias?
O AHSU 360 é a solução de proteção de ambientes de e-mail corporativo da UNODATA. Ele cria uma cópia independente dos e-mails fora do tenant do 365 ou do Workspace, com retenção imutável por prazo configurável conforme a política da empresa. A restauração é autônoma, sem dependência do suporte da plataforma de origem, e pode ser verificada por testes periódicos documentados.
esse texto te ajudou?
continuar lendo
Outros artigos pra você
backup · seguranca-da-informacao · microsoft-365 · gestao-de-ti · ahsu-360


