Backup dentro do tenant não é backup

Dois anos de e-mail somem em menos de quarenta minutos quando um administrador com permissão elevada comete um erro grave ou age de má fé. Já vi isso acontecer. A empresa tinha retenção ativada no Microsoft 365, política configurada, tudo documentado. E ainda assim perdeu dados porque a cópia vivia no mesmo ambiente que foi comprometido.

Essa confusão é cara e é comum. Muitas empresas operam hoje achando que estão protegidas porque ativaram alguma política de retenção dentro do tenant da Microsoft ou do Google. Não estão. Estão com a ilusão da proteção, que é pior do que saber que não tem nada, porque elimina a urgência de resolver.

O objetivo deste artigo é desfazer essa confusão com precisão técnica. Vou definir o que separa retenção de backup, por que a diferença importa na prática e qual critério objetivo você pode usar agora para avaliar se a sua empresa está realmente protegida.

Retenção e backup: definições que não podem ser confundidas

Retenção, no contexto do Microsoft 365 e do Google Workspace, é uma política administrativa que impede a exclusão permanente de dados por um período configurável. Ela existe dentro do próprio tenant, controlada pelas mesmas credenciais que gerenciam o restante do ambiente. Se o administrador global tiver permissão para alterar ou remover essa política, a retenção pode ser desfeita antes que os dados sejam necessários.

Backup, por definição técnica e operacional, é a existência de uma cópia dos dados em um ambiente com controle independente do ambiente de origem. Independente aqui significa credencial diferente, superfície de ataque diferente e, idealmente, imutabilidade garantida por arquitetura. Nenhuma ação executada no ambiente principal deve ser capaz de destruir ou alterar essa cópia.

A distinção não é sutil. É estrutural. Uma é uma configuração dentro da mesma casa. A outra é uma segunda casa com outra fechadura.

Backup não é um botão que alguém liga. É uma decisão arquitetural sobre onde a cópia mora e quem pode tocá-la.

O problema da chave, do cofre e dos documentos na mesma sala

Existe um princípio básico de segurança da informação chamado separação de controles. Ele diz que quem pode criar dados não deve ser a mesma entidade que controla exclusivamente o mecanismo de recuperação desses dados. Quando a retenção vive dentro do tenant, esse princípio é violado por design.

Pense na analogia concreta: a chave do cofre, o cofre e os documentos estão na mesma sala. Se um agente com acesso a essa sala, seja um funcionário insatisfeito, uma credencial comprometida por phishing ou um ransomware com privilégio elevado, agir sobre esse ambiente, as três coisas desaparecem juntas. A retenção não protege contra quem tem permissão para desativá-la.

Os vetores de risco que a retenção não cobre

Na prática, os cenários que destroem dados protegidos apenas por retenção interna incluem:

1. Administrador global com credencial comprometida por ataque de phishing que eleva privilégios e desativa políticas antes de executar exclusão em massa.
2. Funcionário com acesso administrativo que, ao ser desligado, age de má fé antes de ter o acesso revogado.
3. Configuração incorreta de política de retenção que nunca protegeu o que se acreditava proteger, descoberta somente no momento da recuperação.
4. Ataque de ransomware que, ao obter privilégio de administrador global, usa as próprias APIs do tenant para purgar dados antes de criptografar.
5. Exclusão acidental em cascata por automação ou script com escopo maior do que o pretendido.

Em todos esses cenários, a retenção interna não oferece garantia real porque está acessível pelo mesmo vetor que gerou o incidente.

O critério objetivo para avaliar se você tem backup de verdade

Há uma pergunta que resume tudo. Ela é direta e a resposta não admite ambiguidade:

A sua cópia de segurança pode ser apagada, alterada ou desativada por alguém que tenha acesso administrativo ao ambiente principal?

Se a resposta for sim, você não tem backup. Tem retenção com a aparência de backup.

Backup real passa em três critérios objetivos:

• Separação de credencial: a cópia é acessada com autenticação independente do tenant de origem. Comprometer o tenant não compromete o acesso à cópia.
• Separação de superfície: a cópia reside fora do ambiente de origem, em infraestrutura que não compartilha plano de controle com o Microsoft 365 ou o Google Workspace.
• Imutabilidade por arquitetura: durante o período de retenção definido, nenhuma operação executável pelo administrador do ambiente de origem pode modificar ou excluir a cópia. Isso não é uma configuração opcional. É uma propriedade do sistema.

O terceiro critério é o mais negligenciado. Muitas soluções de backup em nuvem oferecem imutabilidade como funcionalidade configurável, o que significa que ela pode ser desconfigurada. Imutabilidade por arquitetura significa que o design do sistema não oferece mecanismo de remoção antecipada, independentemente de quem está operando.

Como o AHSU 360 endereça esse problema

O AHSU 360, que é a sigla para AntiHacking System UNODATA, foi desenhado com separação de tenant como requisito não negociável. A cópia dos dados de Microsoft 365 e Google Workspace dos nossos clientes vive fora do ambiente de origem, sob credencial própria, com imutabilidade implementada no nível da arquitetura de armazenamento.

Isso não é uma feature. É a premissa. O sistema não existe sem essa separação porque o produto foi construído a partir da tese de que retenção dentro do tenant é um risco operacional disfarçado de proteção.

Na prática, o que isso significa para o cliente: se o tenant for completamente comprometido, se o administrador global perder o acesso, se uma política interna for removida por erro ou por ataque, a cópia no AHSU 360 permanece intacta e recuperável. O vetor de ataque que destruiu o ambiente de origem não tem alcance sobre ela.

A diferença entre esse modelo e a retenção nativa não é técnica no sentido abstrato. É operacional no sentido mais concreto: é a diferença entre restaurar em uma hora e passar horas explicando para a diretoria por que dois anos de e-mail e documentos desapareceram sem possibilidade de recuperação.

Perguntas frequentes

A retenção nativa do Microsoft 365 serve para alguma coisa?

Sim, mas para um propósito diferente do backup. Retenção nativa atende requisitos de compliance e auditoria, impedindo que usuários excluam dados antes do prazo legal. Ela não substitui backup porque vive sob o mesmo controle administrativo do ambiente e pode ser alterada por quem tem privilégio suficiente. Use retenção para compliance e backup externo para recuperação de desastres.

Qual é o risco concreto de depender só da retenção interna?

O risco principal é a perda total em cenários onde o ambiente administrativo é comprometido. Um ataque com credencial elevada, um erro de script com escopo amplo ou uma ação mal-intencionada de administrador podem desativar a retenção e excluir dados antes que haja tempo de reagir. Sem cópia fora do tenant, não há recuperação possível.

O que significa imutabilidade por arquitetura, na prática?

Significa que o sistema de backup não oferece nenhum mecanismo para remover ou alterar a cópia durante o período de retenção definido, independentemente de quem está operando. Diferente de imutabilidade configurável, que pode ser desligada por um administrador, imutabilidade por arquitetura é uma propriedade estrutural: o design não prevê o caminho para a exclusão antecipada.

Como avaliar se o backup da minha empresa passa nos critérios corretos?

Faça três perguntas ao seu fornecedor ou equipe de TI: a cópia usa credencial separada do tenant de origem, a cópia reside em infraestrutura fora do plano de controle do Microsoft 365 ou Google Workspace, e a imutabilidade é garantida por arquitetura ou apenas por configuração. Se qualquer uma das respostas for negativa ou evasiva, você está operando com risco não coberto.