Em julho de 2023, a Microsoft renomeou o Azure Active Directory para Microsoft Entra ID. Se você trabalha com gestão de identidade corporativa, provavelmente recebeu um e-mail sobre isso, deu de ombros e seguiu com o dia. E fez bem.

Na prática, não mudou nada técnico. Nenhum endpoint quebrou, nenhuma API deixou de funcionar, nenhum script de PowerShell precisou ser reescrito. Os GUIDs continuam os mesmos, o portal é o mesmo (com skin nova) e as licenças mantêm a estrutura que já existia. O que mudou foi o nome, como parte de uma estratégia da Microsoft de unificar tudo que envolve identidade, permissões e governança sob a marca Entra.

Então por que falar sobre isso? Porque o rebranding trouxe junto uma reorganização de como a Microsoft comunica os recursos por nível de licença. E é aí que a coisa fica interessante (e confusa, se ninguém explicar direito).

O que o Microsoft Entra ID realmente faz

Se você pensar no Entra ID como ‘aquele negócio de login do Microsoft 365’, está subestimando a ferramenta. Ele é o serviço de identidade e acesso da Microsoft para a nuvem. Todo mundo que faz login num ambiente Microsoft 365, Azure ou em aplicações SaaS integradas passa pelo Entra ID. Ponto.

Isso inclui autenticação (provar que você é quem diz ser), autorização (definir o que você pode acessar) e, nos planos mais avançados, governança de identidade (quem deveria ter acesso ao quê e por quanto tempo).

Na minha experiência, a maioria das empresas brasileiras de médio porte usa o Entra ID Free que vem junto com qualquer assinatura Microsoft 365. E para por aí. Não configuram acesso condicional, não revisam quem tem acesso administrativo, não monitoram logins suspeitos. É como ter um cofre com fechadura biométrica e deixar a porta encostada.

Recursos por licença: Free, P1 e P2

Essa é a parte que gera mais confusão nas conversas com clientes. O Entra ID tem três camadas de licenciamento, e a diferença entre elas define o nível de controle que você tem sobre identidades e acessos.

Entra ID Free

Vem incluído em qualquer assinatura de Microsoft 365 ou Azure. Oferece o básico: diretório de usuários na nuvem, SSO para aplicações Microsoft, autenticação multifator (MFA) via security defaults e integração com o Active Directory on-premises via Entra Connect.

Para uma empresa pequena com poucos aplicativos SaaS, pode ser suficiente. Mas o Free não tem acesso condicional granular. Você liga o MFA para todo mundo ou não liga. Sem exceções, sem contexto, sem inteligência.

Entra ID P1

Aqui começa o jogo de verdade. O Entra ID P1 inclui acesso condicional, que permite criar políticas baseadas em condições: localização, dispositivo, aplicação, nível de risco do login. Inclui também self-service password reset com writeback para o AD on-premises, grupos dinâmicos e termos de uso.

O P1 já vem incluso no Microsoft 365 Business Premium e no Microsoft 365 E3. Muita empresa que assina E3 não sabe que já tem P1 disponível e nunca configurou uma política de acesso condicional. Isso me causa uma certa frustração, honestamente, porque o recurso está lá, pago, esperando ser usado.

Entra ID P2

O P2 adiciona duas capacidades que fazem diferença real para empresas maiores ou com requisitos de compliance mais rígidos: Identity Protection e Privileged Identity Management (PIM).

O Identity Protection usa machine learning para detectar logins arriscados (por exemplo, login de um IP associado a botnet ou de uma localização impossível, como São Paulo às 10h e Lagos às 10h15). O PIM permite ativar permissões administrativas por tempo limitado, com aprovação e justificativa. Em vez de alguém ser Global Admin 24 horas por dia, a pessoa ativa o papel quando precisa e ele expira automaticamente.

O P2 vem incluso no Microsoft 365 E5 e pode ser adquirido como add-on para E3.

Comparativo rápido

Recurso	Free	P1	P2
SSO para apps SaaS	Sim	Sim	Sim
MFA (security defaults)	Sim	Sim	Sim
Acesso condicional	Não	Sim	Sim
Self-service password reset	Limitado	Completo	Completo
Identity Protection	Não	Não	Sim
PIM	Não	Não	Sim
Incluso em	Todos os M365	Business Premium, E3	E5

Se você está avaliando qual plano faz sentido, vale entender primeiro as diferenças entre Microsoft 365 Business e Enterprise antes de decidir.

Acesso condicional: o coração da gestão de identidade moderna

Se eu tivesse que escolher um único recurso do Entra ID P1 para justificar o investimento, seria o acesso condicional. Sem ele, sua política de segurança de identidade se resume a ‘todo mundo usa MFA’ ou ‘ninguém usa’. Não existe meio-termo.

Com acesso condicional, você cria regras do tipo: se a condição X for verdadeira, então exija a ação Y. Isso parece simples, mas a combinação de condições permite políticas muito refinadas.

Exemplos reais de políticas que fazem sentido

Bloquear login fora do país. Se sua empresa opera só no Brasil, por que aceitar autenticação vindo da Romênia? Uma política de acesso condicional pode bloquear qualquer login originado fora de localizações confiáveis. É uma das primeiras políticas que recomendo ativar. Reduz drasticamente ataques de credential stuffing que vêm de fora.

Exigir MFA em dispositivo não gerenciado. O colaborador quer acessar o SharePoint do notebook pessoal em casa? Pode. Mas vai precisar passar pelo MFA. Se estiver no dispositivo corporativo gerenciado pelo Microsoft Intune, o acesso pode ser direto. Isso equilibra segurança e experiência do usuário sem criar aquela fricção que faz o pessoal reclamar no Teams.

Bloquear protocolos legados. IMAP, POP3, SMTP autenticado. Esses protocolos não suportam MFA e são a porta de entrada favorita de atacantes que conseguem senhas em vazamentos. Uma política de acesso condicional pode bloquear a autenticação via protocolos legados. É simples, mas muita empresa não faz porque tem aquela impressora antiga que manda e-mail por SMTP ou aquele ERP de 2015 que só fala POP3.

E aqui está o trade-off real: bloquear protocolos legados é a coisa certa a fazer, mas exige um levantamento prévio de quais sistemas ainda dependem deles. Sem esse levantamento, você vai quebrar algo. Garantido.

SSO com aplicações SaaS: menos senha, menos risco

O single sign-on (SSO) do Entra ID permite que o usuário faça login uma vez e acesse dezenas de aplicações sem digitar senha novamente. A galeria de aplicações do Entra ID tem milhares de integrações pré-configuradas: Salesforce, ServiceNow, Zoom, Slack, Dropbox Business, SAP e por aí vai.

O ganho não é só conveniência. Cada senha que o usuário não precisa criar é uma senha que ele não vai reutilizar, anotar num post-it ou digitar num site de phishing. Com SSO, a autenticação fica centralizada no Entra ID, e as políticas de acesso condicional se aplicam a todas as apps conectadas.

Para empresas que usam muitas ferramentas SaaS (e qual empresa de médio porte hoje não usa?), configurar SSO via Entra ID é uma das coisas com melhor relação esforço/resultado em segurança. A configuração inicial dá trabalho, especialmente com apps que usam SAML em vez de OIDC, mas depois que está funcionando, a gestão de acesso fica centralizada.

Uma dica: documente quais apps estão integradas via SSO e quais ainda usam login local. Essa lista é ouro para a equipe de segurança e para quando vier uma auditoria de conformidade com a LGPD (Lei 13.709/2018).

Erros comuns ao ativar políticas de acesso condicional

Esse é o ponto do artigo que mais me diverte (e entristece) escrever, porque já vi todos esses erros acontecerem. Alguns mais de uma vez.

Trancar o próprio admin fora do ambiente

O cenário clássico. O administrador cria uma política de acesso condicional que exige MFA para todos os usuários, inclui o grupo ‘Todos’, publica a política, e percebe que ele mesmo está no grupo ‘Todos’. Se o MFA dele não estava configurado, ou se a política bloqueia o acesso da localização onde ele está, parabéns: ele acabou de se trancar para fora do próprio tenant.

Já vi isso acontecer numa sexta-feira às 17h. Não é uma história bonita.

Não ter conta de emergência (break glass account)

A Microsoft recomenda (e eu recomendo com mais ênfase ainda) que toda organização tenha pelo menos duas contas de acesso de emergência. Essas contas ficam excluídas de todas as políticas de acesso condicional, usam senhas longas e complexas armazenadas em local seguro (cofre físico, não no OneNote do admin), e existem exclusivamente para o cenário de ‘tudo deu errado’.

Não ter conta de emergência é como não ter chave reserva do escritório. Funciona até o dia que não funciona.

Ativar políticas sem período de report-only

O acesso condicional tem um modo chamado ‘report-only’ que simula a política sem aplicá-la de verdade. Ele mostra no log de sign-in o que teria acontecido se a política estivesse ativa. É um dry run.

Pular esse passo e ir direto para a política ativa é imprudente. Você não sabe quantos usuários seriam afetados, quantos dispositivos não são gerenciados, quantos sistemas usam protocolos legados. O report-only existe justamente para isso. Use por pelo menos uma ou duas semanas antes de ativar qualquer política nova.

Criar políticas demais sem documentação

Outro padrão que vejo muito: o admin cria quinze políticas de acesso condicional ao longo de seis meses, cada uma com uma lógica diferente, sem documentação, sem padrão de nomenclatura. Quando sai da empresa, o próximo administrador herda um emaranhado de regras que ninguém entende e ninguém quer mexer. Aí fica assim para sempre.

Nomeie suas políticas com um padrão claro (por exemplo: CA001 – Bloquear login fora do BR, CA002 – Exigir MFA dispositivo pessoal). Documente a lógica de cada uma. Parece burocracia, mas vai salvar seu sucessor.

Identity Protection e PIM: quando o P2 se paga

Para a maioria das empresas com até 500 usuários, o P1 resolve. Mas existem cenários em que o P2 se justifica.

O Identity Protection analisa sinais de risco em tempo real e atribui um nível de risco a cada login e a cada usuário. Login de IP anônimo? Risco médio. Credenciais encontradas em vazamento na dark web? Risco alto. Com isso, você pode criar políticas de acesso condicional baseadas em risco: se o risco for alto, bloquear; se for médio, exigir MFA e troca de senha.

O PIM resolve um problema que incomoda qualquer DPO ou auditor: contas com privilégios administrativos permanentes. Em muitas empresas, existem cinco, dez, às vezes vinte Global Admins. Gente que recebeu o papel em 2019, num momento de urgência, e nunca perdeu. Com PIM, esses papéis ficam ‘elegíveis’ em vez de permanentes. O administrador precisa ativar o papel quando necessário, com justificativa e tempo de expiração.

Para quem está preocupado com cibersegurança corporativa, o PIM endereça um dos vetores de ataque mais explorados: contas privilegiadas comprometidas.

Qual licença escolher: P1 ou P2?

Depende do tamanho da empresa, do apetite de risco e do que o compliance exige. Mas posso dar uma orientação prática.

Se você tem Microsoft 365 Business Premium ou E3, já tem P1. Use. Configure acesso condicional, bloqueie protocolos legados, exija MFA condicional. Isso sozinho já melhora muito a postura de segurança.

Se você tem Microsoft 365 E5, já tem P2. Configure Identity Protection e PIM. Se não configurar, está pagando por algo que não usa (e no E5, esse custo não é pequeno).

Se você tem E3 e precisa de P2, avalie o add-on Entra ID P2 ou o add-on Microsoft Entra ID Governance, dependendo da necessidade. Faça a conta. Para uma empresa com 300 usuários, o custo do add-on P2 pode ser menor que o custo de uma única conta de admin comprometida.

Como saber se minha empresa precisa de acesso condicional?

Se sua empresa tem mais de 50 usuários no Microsoft 365 e pelo menos um dos cenários abaixo se aplica, a resposta é sim:

• Colaboradores acessam e-mail e arquivos de dispositivos pessoais
• Existem usuários que trabalham de casa ou de locais variados
• A empresa usa mais de três aplicações SaaS com login separado
• Há contas com privilégio de administrador ativas 24/7
• A empresa precisa comprovar controles de acesso para auditoria ou LGPD

Se marcou dois ou mais itens, acesso condicional não é luxo. É uma camada de controle que deveria estar ativa desde ontem.

Entra ID e a LGPD: onde isso se conecta

A LGPD (Lei 13.709/2018) exige que o controlador adote medidas técnicas e administrativas aptas a proteger dados pessoais de acessos não autorizados. O acesso condicional do Entra ID é exatamente uma medida técnica de controle de acesso.

Em caso de incidente, poder demonstrar que a empresa tinha políticas ativas de acesso condicional, MFA obrigatório e gestão de privilégios pesa a favor na avaliação da ANPD. Não é uma bala de prata, mas é uma evidência concreta de diligência.

Para DPOs que precisam documentar controles: as políticas de acesso condicional ficam registradas no portal do Entra ID, os logs de sign-in mostram quais políticas foram aplicadas em cada autenticação, e o Identity Protection gera relatórios de risco. Tudo exportável.

O caminho para configurar com segurança

Ativar acesso condicional não é difícil. Ativar sem causar problemas, sim. A sequência que recomendo:

1. Crie pelo menos duas contas de emergência (break glass) e exclua-as de todas as políticas
2. Faça um inventário dos aplicativos conectados ao Entra ID e dos protocolos de autenticação em uso
3. Comece com políticas em modo report-only por duas semanas no mínimo
4. Analise os logs para identificar usuários e dispositivos que seriam impactados
5. Ative as políticas de forma gradual, começando pelas menos restritivas
6. Documente cada política com nome padronizado e descrição da lógica

Se isso parece muita coisa para o time interno, é porque às vezes é. A Omega Brasil configura Entra ID e acesso condicional com políticas testadas em modo report-only antes de ir para produção. Se você quer começar pelo pé certo, vale solicitar um assessment de identidade junto à equipe de Microsoft 365 para empresas da Omega.

Erros que custam caro (e que dá para evitar)

Vou fechar com algo que não aparece em documentação técnica mas aparece na vida real de quem administra ambientes Microsoft 365.

Primeiro: não trate o Entra ID como ‘coisa do time de infra’. Gestão de identidade é segurança. Envolva o time de segurança, o DPO e, dependendo do porte, o CISO. Políticas de acesso condicional afetam todos os usuários e todos os aplicativos.

Segundo: faça revisões trimestrais de quem tem acesso administrativo. Eu já perdi a conta de quantas empresas encontro com ex-funcionários ainda com papel de Global Admin. É assustador.

Terceiro: não ignore os alertas do Identity Protection se você tem P2. O sistema gera alertas de login arriscado. Se ninguém olha, é o mesmo que não ter. Configure pelo menos um e-mail de notificação para o time de segurança.

E por último: se a sua empresa está crescendo e a gestão de identidade está ficando complexa, considere conversar com quem faz isso no dia a dia. A Omega Brasil atua com implementação e gestão de ambientes Microsoft há mais de 20 anos e pode ajudar desde o assessment inicial até a operação contínua. Para saber mais, entre em contato e solicite um orçamento de TI corporativa.