Durante anos, empresas investiram pesado em backup de servidor, banco de dados, máquina virtual e até do próprio Microsoft 365. E, ao mesmo tempo, quase ninguém fazia a mesma pergunta sobre a peça que sustenta tudo isso por baixo: quem faz backup da identidade? Se um usuário, um grupo, uma aplicação ou uma política de acesso fosse excluído por engano — ou apagado de propósito por um atacante tentando manter persistência dentro do ambiente —, a recuperação dependia de script, exportação manual ou, no pior caso, reconstruir aquilo tudo do zero. Em março de 2026, a Microsoft começou a mudar esse cenário com o lançamento em preview do Microsoft Entra Backup and Recovery, e o recurso já está em disponibilidade geral. Este artigo explica o que ele protege de fato, como funciona na prática, e — igualmente importante — o que ele ainda não cobre, para que nenhuma empresa saia deste texto achando que instalou uma rede de segurança completa quando, na realidade, ganhou uma peça importante de um quebra-cabeça maior.
O que é o Microsoft Entra Backup and Recovery
É uma solução nativa, incorporada ao próprio Microsoft Entra, que permite restaurar objetos críticos do diretório para um estado anterior conhecido depois de uma alteração acidental ou de um incidente de segurança. Antes desse recurso, as opções disponíveis eram todas paliativas: exportação manual de configuração, script em PowerShell rodando por conta própria, ferramenta de terceiro tentando cobrir a lacuna, ou simplesmente documentação torcendo para que alguém lembrasse de atualizá-la. Nenhuma dessas alternativas oferecia o que faltava de verdade — um mecanismo de recuperação de estado, nativo, dentro da própria plataforma que gerencia a identidade.
Um detalhe que muda o cálculo de adoção para a maioria das empresas: o recurso já está incluído nas licenças Microsoft Entra ID P1 e P2, sem módulo adicional para comprar. Quem já paga por essas licenças — o que já é comum em empresas de médio porte com alguma maturidade de segurança — ganha a capacidade sem custo extra, só precisa ativar e configurar o acesso adequado.
Por que identidade virou o ativo mais crítico da empresa
A maioria dos ataques modernos não começa com malware — começa com credencial roubada, token de sessão comprometido, uma autorização OAuth concedida sem revisão, ou uma conta privilegiada capturada. O perímetro que a segurança corporativa protegia há dez anos, baseado em firewall e rede física, deu lugar a um perímetro baseado em identidade. E quando a identidade falha, a empresa inteira para junto: sem o Entra funcionando, ninguém autentica, o Microsoft 365 fica inacessível, aplicações SaaS conectadas via login único param de responder, e as próprias políticas de segurança que deveriam proteger o ambiente deixam de operar. Não é uma camada entre várias — é a camada da qual todas as outras dependem para funcionar.
Essa centralidade explica por que atacantes sofisticados, ao invés de simplesmente roubar dado e sair, cada vez mais optam por modificar políticas de Conditional Access como técnica de persistência — desabilitando uma regra ou adicionando uma exclusão silenciosa que mantém acesso mesmo depois que a credencial original é trocada. Esse padrão específico já tem classificação formal no framework MITRE ATT&CK (técnica T1556.009) e foi documentado em campanhas de grupos como Scattered Spider e Storm-0501. Um recurso de backup que permite comparar o estado atual com um estado anterior conhecido é, nesse contexto, tanto ferramenta de recuperação de erro operacional quanto ferramenta de investigação de incidente de segurança real.
O que o recurso protege
Segundo a documentação oficial da Microsoft, os objetos suportados incluem usuários, grupos, aplicações corporativas (app registrations, Enterprise Applications e service principals), políticas de Conditional Access, localizações nomeadas, política de método de autenticação e política de autorização — com propriedades selecionadas para cada tipo de objeto. A solução também cobre Agent ID, a identidade usada por agentes de IA corporativos, já que tecnicamente esses agentes são compostos por objetos de usuário e service principal.
Vale um esclarecimento técnico importante que muda a forma de usar essa proteção na prática: a recuperação é em nível de propriedade, não uma reversão completa de estado de todo o objeto. Para um grupo, por exemplo, é possível recuperar nome de exibição, descrição e se está habilitado para segurança ou para e-mail — mas mudanças de propriedade (quem é dono do grupo) e regras de associação dinâmica ficam explicitamente fora do escopo dessa recuperação específica. Antes de contar com o recurso num cenário real de recuperação, vale revisar exatamente quais propriedades são cobertas para cada tipo de objeto envolvido.
Como funciona na prática
Backups automáticos, uma vez por dia
O serviço realiza backup automático dos objetos suportados uma vez por dia, sem que nenhum administrador precise configurar ou agendar nada manualmente — está ativo por padrão para tenants elegíveis.
Sete dias de retenção — um aumento em relação ao preview
Na disponibilidade geral, a Microsoft mantém sete dias de histórico de backup para os objetos suportados — um aumento em relação aos cinco dias oferecidos durante a fase de preview, ajustado com base no feedback recebido dos primeiros usuários. Separadamente, para usuários, grupos do Microsoft 365, grupos de segurança na nuvem, registros de aplicativo e service principals excluídos, o mecanismo de soft-delete mantém a possibilidade de recuperação por até 30 dias — um prazo mais longo, mas que cobre especificamente exclusão, não qualquer tipo de alteração indevida de atributo.
Armazenamento que nem administrador global consegue apagar
Nenhum usuário ou aplicação conectada ao tenant — mesmo com o privilégio administrativo mais alto disponível — consegue desligar, excluir ou modificar os backups gerados pelo serviço. Essa é uma escolha de arquitetura deliberada: se um atacante conseguir comprometer uma conta de Administrador Global, ele ainda não consegue apagar o histórico que permitiria a uma equipe de resposta a incidente entender o que ele fez.
Armazenamento na mesma geografia do tenant
Os dados de backup residem na mesma localização geográfica definida na criação do tenant — relevante para empresas com exigência de residência de dado sob a LGPD ou outras regulações de proteção de dado que consideram onde a informação fisicamente reside.
Dois papéis de acesso com privilégio mínimo
A Microsoft introduziu dois papéis específicos para esse recurso, aplicando o princípio de menor privilégio à própria ferramenta de backup: Microsoft Entra Backup Reader, que permite visualizar backups, comparações e histórico de recuperação, sem poder executar nenhuma ação; e Microsoft Entra Backup Administrator, que soma a isso a capacidade de gerar relatórios de diferença e efetivamente disparar uma restauração. Administradores Globais já têm essas permissões por padrão, mas atribuir os papéis específicos a quem realmente precisa evita conceder privilégio administrativo total só para dar acesso a essa funcionalidade.
Difference Report: a funcionalidade que mais muda o dia a dia
Se há uma funcionalidade que resume o valor prático do recurso, é o Difference Report — um relatório que compara o estado atual do tenant com o estado registrado num backup específico, apontando exatamente o que mudou: objetos removidos, objetos alterados, mudanças de atributo, mudanças de permissão. Antes disso existir, responder “o que exatamente mudou entre ontem e hoje neste ambiente?” exigia investigação manual, cruzando log de auditoria com memória de quem lembrava de ter mexido em algo.
As aplicações práticas vão além de recuperação de desastre: auditoria de mudança, troubleshooting do tipo “por que ninguém mais consegue acessar esse sistema desde ontem”, gestão de mudança em geral, e resposta a incidente de segurança, onde entender rapidamente o escopo exato do que um atacante alterou é o que determina se a contenção é rápida ou se a investigação se arrasta por dias.
Um ponto prático que vale nomear: para tenants grandes e ativos, revisar milhares de objetos alterados diretamente na interface do portal, durante um incidente real sob pressão, não é um fluxo de trabalho particularmente ágil — o relatório de diferença ainda não tem capacidade de exportação, o que pode se tornar uma limitação real dependendo do volume de mudança envolvido no ambiente.
O que ainda não está coberto — e por que isso importa tanto quanto o que está
Um recurso de segurança mal compreendido é, muitas vezes, mais perigoso do que a ausência dele — porque cria falsa sensação de proteção completa. Vale conhecer as limitações reais antes de contar com essa ferramenta num cenário crítico:
- Senha não é incluída no backup — depois de restaurar um usuário ou método de autenticação, pode ser necessário definir nova senha e reconfigurar autenticação manualmente
- Objetos com exclusão definitiva (hard delete) não são recuperáveis — apenas objetos com soft-delete ou atributo modificado entram no escopo de recuperação
- Objeto sincronizado do Active Directory local (hybrid) tem cobertura parcial — mudanças aparecem no relatório de diferença, mas ficam automaticamente excluídas da recuperação, a menos que o objeto seja convertido para ser gerenciado na nuvem, movendo a fonte de autoridade para o Entra ID. Objetos que continuam gerenciados via AD DS local precisam de uma solução de backup separada nessa camada
- Alguns atributos e configurações específicas podem não ser capturados — atributos de segurança customizados, detalhes de método de autenticação e configurações de confiança gerenciadas externamente estão entre os que exigem atenção adicional
- Modelo de execução de restauração única por vez — em tenants grandes com muita mudança acumulada, uma restauração ampla pode levar de horas a dias para concluir, o que precisa entrar no planejamento de qualquer cenário real de recuperação de desastre
A conclusão prática de analistas que já testaram o recurso a fundo é consistente: é um controle de recuperação de último recurso, com limites conhecidos — não substitui prevenção, detecção contínua nem monitoramento de mudança de configuração. Reduz drasticamente o pior cenário, mas não elimina a necessidade de todas as outras camadas de segurança que já deveriam estar em prática.
Cenários onde o recurso vira essencial
Uma política de Conditional Access removida por engano, historicamente, gerava um dos piores tipos de incidente para lidar: silencioso, sem alerta óbvio, descoberto só quando usuários começam a reportar problema de acesso. A investigação manual consumia horas, e a reconstrução da política do zero raramente reproduzia exatamente a configuração original. Hoje, com o Difference Report, é possível comparar o estado atual com o backup anterior, identificar exatamente o que mudou, e restaurar a configuração específica — minutos de trabalho, não horas de reconstrução às cegas.
O mesmo vale para erro administrativo comum (alguém desabilita a política errada durante uma limpeza de ambiente), mudança indevida feita por um terceiro com acesso temporário mal revogado, e — o cenário mais sério — comprometimento de conta privilegiada, onde o recurso ajuda a organização a voltar para um estado operacional conhecido depois que a contenção do incidente já foi feita por outras camadas de segurança.
Backup de identidade dentro da estratégia Zero Trust
Zero Trust não é um produto — é um conjunto de princípios (verificar explicitamente, menor privilégio, presumir violação) aplicado de forma consistente à arquitetura de segurança. O backup de identidade se encaixa diretamente nesse terceiro princípio: presumir violação significa não apenas tentar impedir o incidente, mas também estar preparado para voltar a operar depois que ele acontecer. Com o Backup and Recovery nativo, resiliência de identidade deixa de ser um item que ficava fora do escopo de IAM, Zero Trust, Disaster Recovery e continuidade de negócio, e passa a ser parte integrada dessas quatro disciplinas ao mesmo tempo — porque a identidade, afinal, é o que todas elas protegem no centro.
Como isso se compara a soluções de terceiros
A vantagem mais evidente do recurso nativo é justamente ser nativo: integrado ao portal que os administradores já usam, automático por padrão, sem necessidade de configuração adicional, e gerenciado diretamente pela Microsoft — sem depender de mais um fornecedor, mais um contrato, mais uma equipe aprendendo uma ferramenta separada.
Ainda assim, isso não elimina a necessidade de avaliar backup para as outras cargas de trabalho do ambiente. O recurso protege objetos de identidade — não substitui uma estratégia dedicada de backup para Exchange Online, SharePoint, OneDrive e Teams, que continuam exigindo proteção específica. Um erro comum de interpretação é achar que “backup do Microsoft 365” agora está resolvido de ponta a ponta — não está. É a camada de identidade que ganhou proteção nativa; o restante do ecossistema segue com as mesmas necessidades de antes.
Oportunidade para quem gerencia segurança de identidade como serviço
Esse lançamento cria uma abertura natural para três frentes de trabalho consultivo: um Identity Risk Assessment, avaliando a maturidade real da identidade corporativa antes mesmo de discutir qual tecnologia usar; um Microsoft Security Assessment mais amplo, cobrindo Entra, Defender, Intune e Purview de forma integrada, já que nenhuma dessas peças funciona isoladamente bem; e serviços gerenciados de identidade contínuos — governança, revisão periódica, monitoramento e hardening — que garantem que o recurso de backup, uma vez ativado, continue configurado corretamente ao longo do tempo, não apenas no dia em que foi ligado.
Roteiro recomendado para empresas
- Diagnóstico de identidade — entender a maturidade atual de configuração do Entra antes de qualquer decisão
- Mapeamento de privilégio — quem tem acesso administrativo, e se esse acesso está de fato justificado
- Revisão de Conditional Access — políticas existentes, cobertura real e pontos cegos
- Validação do Backup and Recovery — confirmar que está ativo, com os papéis de acesso corretos atribuídos, e testar um cenário de restauração antes de precisar dele de verdade
- Plano formal de resiliência de identidade — documentando processo, responsável e critério de decisão para quando um incidente real exigir ação rápida
Para fechar
O Microsoft Entra Backup and Recovery marca uma mudança real na forma como a Microsoft trata identidade: deixa de ser vista apenas como mecanismo de autenticação e passa a ter uma camada nativa de resiliência operacional, no mesmo padrão que já existia há anos para servidor e banco de dado. Para empresas que dependem de Microsoft 365, Entra ID e um número crescente de aplicações SaaS conectadas via login único, essa novidade reduz o impacto de erro humano, falha operacional e incidente de segurança — sem, no entanto, eliminar a necessidade de todas as outras camadas de proteção que uma estratégia de segurança de identidade madura ainda exige.
A InfoB, como parceira certificada Microsoft, ajuda empresas a avaliar a maturidade da própria identidade, ativar e configurar corretamente o Backup and Recovery, e construir a estratégia mais ampla de resiliência que esse recurso, sozinho, não cobre por completo.
Perguntas frequentes
O que é o Microsoft Entra Backup and Recovery?
Uma solução nativa do Microsoft Entra que faz backup automático diário de objetos críticos do diretório — usuários, grupos, aplicações, políticas de Conditional Access — e permite restaurá-los a um estado anterior após alteração acidental ou comprometimento. Já em disponibilidade geral, incluído nas licenças Entra ID P1 e P2, sem custo adicional.
Quantos dias de histórico o backup guarda?
Sete dias para os backups regulares — número que subiu de 5 para 7 entre o preview (março de 2026) e a disponibilidade geral. Separadamente, o soft-delete mantém usuários, grupos e aplicações excluídos recuperáveis por até 30 dias.
O recurso recupera senhas?
Não. Senha não entra no backup. Depois de restaurar um usuário ou método de autenticação, pode ser necessário definir nova senha e reconfigurar a autenticação manualmente.
Ele substitui outras soluções de backup do Microsoft 365?
Não. Protege exclusivamente objetos de identidade do Entra. Exchange Online, SharePoint, OneDrive e Teams continuam exigindo estratégia de proteção separada e específica.