O Que É Segurança de Identidade Azure?
Segurança de identidade Azure é o conjunto de controles que protege contas do Microsoft Entra ID, funções privilegiadas, métodos de autenticação, acesso a aplicativos e sessões administrativas em todo o Microsoft 365, Azure e aplicativos SaaS conectados. É a porta de entrada do tenant. Se a camada de identidade for fraca, um invasor pode nem precisar de uma exploração de servidor; uma senha roubada, um fluxo de autenticação vulnerável a phishing, uma exceção fraca ou uma sessão privilegiada podem ser suficientes.
O MFA é parte da resposta, mas o MFA isoladamente não é uma estratégia completa de segurança de identidade do Azure. Um tenant também precisa de cobertura de Conditional Access, métodos de autenticação fortes para funções privilegiadas, resposta baseada em risco, controles de acesso de emergência, governança de aplicativos e validação de que as políticas realmente se aplicam a logins reais.
As duas falhas básicas que aparecem repetidamente são simples:
- contas privilegiadas sem autenticação forte aplicada
- Security Defaults desativado sem cobertura equivalente de Conditional Access
Essas falhas criam uma lacuna entre o que os administradores acreditam estar protegido e o que o Microsoft Entra ID realmente aplica.
Security Defaults vs. Conditional Access
Security Defaults são as proteções básicas integradas da Microsoft para organizações que precisam de um ponto de partida simples. A documentação da Microsoft descreve o Security Defaults como adequado para organizações que querem melhorar a segurança, mas não sabem por onde começar, e para organizações que usam o nível gratuito do Microsoft Entra ID.
O Security Defaults exige que todos os usuários se registrem para autenticação multifator, exige que os administradores realizem MFA em cada login, solicita MFA a outros usuários quando a Microsoft julga necessário, bloqueia protocolos de autenticação legados, bloqueia o fluxo de código de dispositivo e exige MFA para atividades privilegiadas, como acesso ao portal do Azure, ao centro de administração do Microsoft Entra, ao Azure PowerShell e ao Azure CLI. Ele é intencionalmente simples e não personalizável: a opção está ativada ou desativada, sem escopo e sem exceções.
Conditional Access é o mecanismo de políticas mais flexível. Organizações com licenciamento Microsoft Entra ID P1 ou P2 e requisitos mais complexos geralmente precisam do Conditional Access para direcionamento de aplicativos, estado do dispositivo, localizações, condições de risco, níveis de autenticação, controles de sessão e exceções com escopo definido.
O estado perigoso é a lacuna de transição: o Security Defaults está desativado, mas o Conditional Access ainda não fornece uma proteção equivalente ou mais forte. A orientação da Microsoft para migrar do Security Defaults diz que as organizações devem habilitar imediatamente políticas de Conditional Access para proteger a organização após desativar o Security Defaults. A Microsoft agora fornece políticas de Conditional Access gerenciadas pela Microsoft para cobrir essa transição: Bloquear autenticação legada, Exigir autenticação multifator para o gerenciamento do Azure, Exigir autenticação multifator para administradores e Exigir autenticação multifator para todos os usuários. Observe o estado padrão delas. A Microsoft as cria em Somente relatório, que avalia e registra, mas não aplica nada, e as habilita em no máximo 30 dias caso permaneçam nesse estado. Até essa mudança, uma lista de políticas que parece estar coberta não está aplicando nada — a mesma armadilha descrita em Conditional Access em modo somente relatório e exclusões obsoletas.
Por Que o MFA Sozinho Não É Suficiente
O MFA melhora a resistência ao comprometimento baseado apenas em senha, mas nem todos os métodos de MFA oferecem o mesmo nível de proteção. Um tenant ainda pode estar exposto se:
- administradores forem excluídos das políticas de Conditional Access do tenant por causa de solução de problemas emergenciais
- o Conditional Access se aplicar apenas a aplicativos selecionados, enquanto os portais de administração permanecem acessíveis
- usuários privilegiados usarem métodos vulneráveis a phishing quando métodos mais fortes são viáveis
- contas break-glass existirem, mas não forem monitoradas em cada login
- autenticação legada ou clientes mais antigos permanecerem disponíveis para alguns fluxos de trabalho
- o registro e a recuperação de métodos de autenticação forem fracamente controlados
- sessões e tokens de atualização permanecerem válidos após um evento de risco
Uma dessas lacunas já foi fechada no nível da plataforma, e isso muda a forma como o problema das exceções deve ser interpretado. A Microsoft agora aplica MFA nos logins do Azure independentemente da configuração do tenant: desde outubro de 2024 para o portal do Azure, o centro de administração do Microsoft Entra e o centro de administração do Microsoft Intune; desde fevereiro de 2025 para o centro de administração do Microsoft 365; e desde 1º de outubro de 2025 para o Azure CLI, o Azure PowerShell, o aplicativo móvel do Azure, ferramentas de IaC e os endpoints REST do Azure Resource Manager em operações de criação, atualização e exclusão. Essa aplicação substitui a intenção do tenant: a Microsoft afirma que exceções e exclusões do Conditional Access não se aplicam mais a ela, e que ela cobre todas as contas de usuário, incluindo as contas break-glass. Ela não se estende ao Microsoft Graph, que continua governado pelas suas próprias políticas, e a Microsoft atualmente não a aplica no Azure para o Governo dos EUA ou outras nuvens soberanas. O MFA em nível de plataforma eleva o piso mínimo em uma pequena lista de superfícies administrativas. Ele não fornece ao tenant cobertura de Conditional Access, força de método, nem condições de dispositivo e risco.
Os níveis de autenticação do Microsoft Entra existem porque a força do método importa. Um nível de autenticação do Conditional Access pode exigir combinações específicas de métodos, incluindo opções resistentes a phishing, como chaves de segurança passkey/FIDO2 ou autenticação baseada em certificado, quando implantada e suportada.
A Cadeia de Ataque
Etapa 1 - Encontrar o Caminho de Identidade Fraco
Um invasor procura contas que possam se autenticar sem controles fortes: contas de administrador sem MFA, contas excluídas do Conditional Access, contas obsoletas, contas de emergência não monitoradas ou aplicativos com permissões amplas.
Etapa 2 - Obter uma Credencial ou Sessão Válida
O acesso inicial pode vir de reutilização de senha, phishing de credenciais, roubo de token, abuso do help desk ou um dispositivo comprometido. A técnica exata varia, mas a pergunta de controle de identidade é a mesma: o tenant exige um método de autenticação mais forte, um dispositivo em conformidade, um login de baixo risco ou um caminho de administração aprovado antes de conceder o acesso?
Etapa 3 - Alcançar uma Superfície Administrativa
Se a conta puder acessar o portal do Azure, o centro de administração do Microsoft Entra, os portais de administração do Microsoft 365, o Microsoft Graph ou o PowerShell sem os controles previstos, o tenant tem uma lacuna na política efetiva.
Etapa 4 - Preservar o Acesso
Uma vez dentro, o invasor pode tentar adicionar um método de autenticação, criar um novo usuário, atribuir uma função, registrar um aplicativo, adicionar uma credencial a uma entidade de serviço ou enfraquecer uma política de Conditional Access. Essas ações devem ser tratadas como eventos de auditoria de alto sinal para identidades privilegiadas.
Detecção
Sinais de Login e de Política
Revise os logs de login do Microsoft Entra e os resultados do Conditional Access em busca de:
- logins privilegiados bem-sucedidos em que o MFA não foi exigido, mas deveria ter sido
- logins em que o método de autenticação não atende ao nível de força esperado
- acesso administrativo a partir de dispositivos não gerenciados ou locais inesperados
- logins de risco médio ou alto que foram concluídos com sucesso
- falhas repetidas seguidas de sucesso em uma conta de administrador
- logins de contas de emergência
- uso de cliente ou protocolo legado onde deveria estar bloqueado
Sinais do Log de Auditoria
Monitore alterações no tenant que possam enfraquecer os controles de identidade:
| Área de Alteração | Por Que Importa |
|---|---|
| Atualização de política de Conditional Access | Pode remover requisitos de MFA, dispositivo, risco ou aplicativo |
| Atualização de exclusão de Conditional Access | Pode criar um caminho de desvio silencioso |
| Alteração de método de autenticação | Pode viabilizar a recuperação de conta ou persistência |
| Atribuição de função | Pode transformar uma conta em controle do tenant |
| Alteração de credencial de aplicativo | Pode criar persistência duradoura baseada em aplicativo |
| Alteração do Security Defaults | Pode remover a proteção básica, se não for substituída |
Ressalvas Sobre a Detecção
Não alerte apenas com base na existência de MFA. Alerte com base nos resultados efetivos. A pergunta não é "o tenant tem uma política de MFA?". A pergunta é "esse login para esse recurso, feito por essa identidade, atendeu ao controle exigido?". Os resultados do Conditional Access, os detalhes de autenticação, o nível de risco, a função do usuário, o aplicativo, o dispositivo e a localização — tudo isso importa.
Remediação
A base segura é o Security Defaults para tenants simples ou um design completo de Conditional Access para tenants mais complexos. Deixar ambos ausentes é a falha evitável.
1. Reative o Security Defaults ou Substitua-o Imediatamente
Se o tenant não tiver um design maduro de Conditional Access, ative o Security Defaults. Se a organização usar Conditional Access, documente a linha de base substituta antes de desativar o Security Defaults e teste-a em cenários reais de login.
No mínimo, o design substituto deve cobrir usuários privilegiados, gerenciamento do Azure, superfícies de administração do Microsoft 365, logins de risco e exposição à autenticação legada.
2. Exija Autenticação Forte para Funções Privilegiadas
Para usuários privilegiados comuns, exija MFA e considere métodos mais fortes para as funções mais sensíveis. Use os níveis de autenticação do Conditional Access para exigir métodos resistentes a phishing onde o ambiente suportar.
Populações comuns de funções de alto valor incluem:
- Administrador Global
- Administrador de Função Privilegiada
- Administrador de Conditional Access
- Administrador de Segurança
- Administrador de Aplicativo
- Administrador de Aplicativo em Nuvem
- Administrador do Exchange e Administrador do SharePoint em tenants fortemente baseados no Microsoft 365
3. Gerencie Contas de Acesso de Emergência Separadamente
Contas de emergência são necessárias para a resiliência. A Microsoft recomenda duas ou mais contas de acesso de emergência somente na nuvem, no domínio *.onmicrosoft.com, nem federadas nem sincronizadas do ambiente local. Essas contas não devem ser usadas como identidades administrativas do dia a dia, e o design de controle delas deve evitar dependências que possam falhar durante a emergência que elas foram criadas para resolver.
A autenticação resistente a phishing nessas contas não é mais opcional. A aplicação obrigatória de MFA também vale para contas break-glass, então uma conta de emergência protegida apenas por senha agora é um bloqueio à espera de acontecer. A orientação atual da Microsoft é registrar um de dois métodos sem senha que atendam ao requisito obrigatório de MFA — uma passkey (FIDO2), que a Microsoft recomenda, ou autenticação baseada em certificado, quando já existe uma PKI — e manter esse método diferente do usado pelas contas de administrador normais. Exclua essas contas das políticas de Conditional Access que bloqueiam ou restringem o login (políticas em modo somente relatório não precisam de exclusão), armazene as credenciais em locais seguros separados, mantenha a atribuição de Administrador Global permanentemente ativa em vez de elegível no PIM, alerte a cada login e valide as contas pelo menos a cada 90 dias. Se uma conta de emergência fizer login, a equipe de segurança deve saber.
4. Remova Exceções Desnecessárias
Revise todos os usuários, grupos, localizações, aplicativos e condições de dispositivo excluídos no Conditional Access. Exceções criadas durante a solução de problemas frequentemente se tornam permanentes. Cada exceção deve ter um responsável, um motivo, uma data de expiração ou uma periodicidade de revisão, e monitoramento compensatório.
5. Combine a Segurança de Identidade com a Resposta a Riscos
O Security Defaults e o MFA não substituem a resposta baseada em risco em tenants maiores. Use os sinais de risco do Microsoft Entra ID Protection por meio das condições de risco do Conditional Access para exigir autenticação em etapas (step-up), reautenticação, correção de risco ou bloqueio quando um risco for detectado. A recomendação atual da Microsoft é exigir correção de risco quando o risco do usuário for alto, e MFA mais frequência de login definida como Sempre quando o risco de login for médio ou alto. Crie essas regras como políticas de Conditional Access, e não no painel do ID Protection: as políticas de risco legadas configuradas dentro do Microsoft Entra ID Protection serão descontinuadas em 1º de outubro de 2026, portanto os tenants que ainda as utilizam precisam recriar os equivalentes no Conditional Access e desativar as antigas.
Validação Após Alterações de Política
Valide o caminho efetivo da política em vez de confiar em capturas de tela de configuração:
- teste o login de um usuário privilegiado no portal do Azure e confirme que o controle esperado é exigido
- teste o login de um usuário privilegiado no Microsoft Graph ou no PowerShell, quando relevante
- confirme que a mesma conta não está excluída por meio de outro grupo, localização, aplicativo ou condição de dispositivo
- revise os logs de login para confirmar o resultado do Conditional Access e os detalhes do método de autenticação
- valide o alerta de conta de emergência revisando o caminho do alerta, em vez de presumir que ele existe
- revise os logins de risco e confirme que as políticas baseadas em risco seriam aplicadas
- confirme que a autenticação legada está bloqueada onde o Security Defaults ou o Conditional Access deveriam bloqueá-la
- verifique se os requisitos de nível de autenticação são atendidos apenas pelos métodos pretendidos
Um controle que existe, mas não se aplica aos logins que os invasores podem usar, não é um controle de segurança de identidade.
Como a EtcSec Detecta Isso
A EtcSec audita os controles de identidade do Azure em cada varredura de tenant. As três verificações abaixo são todas em nível de tenant: elas estabelecem se o controle existe, o que é o pré-requisito para a pergunta por login que este artigo aborda.
MFA_NOT_ENFORCED_ADMINS sinaliza um tenant em que nenhuma política de Conditional Access habilitada direciona funções de diretório com um controle de concessão de MFA.
AZ_SECURITY_DEFAULTS_DISABLED sinaliza um tenant cuja opção de Security Defaults está desativada. Saber se uma linha de base equivalente de Conditional Access a substituiu é a revisão separada que este artigo descreve.
CA_NO_MFA_REQUIREMENT sinaliza um tenant em que nenhuma política de Conditional Access habilitada exige MFA em seus controles de concessão.
A pergunta relevante não é se um tenant tem políticas no papel. É se os logins privilegiados realmente enfrentam os controles previstos e se as sessões de risco acionam uma resposta.
Controles Relacionados
Este controle deve ser revisado junto com Azure Identity Protection: Bloqueando Credenciais Vazadas, Acesso Privilegiado no Azure: Excesso de Administradores Globais, Fortalecimento do Tenant Azure: Corrigindo Configurações Padrão Inseguras, Contas de Convidado no Azure: A Superfície de Ataque Esquecida do Seu Tenant e Registros de Aplicativo no Azure: Apps com Privilégios Excessivos no Tenant. Uma postura fraca de MFA se torna muito pior quando o mesmo tenant também tem privilégio administrativo permanente, acesso amplo de convidados, aplicativos de risco ou resposta fraca baseada em risco.
Referências Principais
- Configurar o Security Defaults para o Microsoft Entra ID
- Visão geral do Conditional Access do Microsoft Entra
- Planeje a autenticação multifator obrigatória do Microsoft Entra
- Políticas de Conditional Access gerenciadas pela Microsoft
- Como funcionam os níveis de autenticação no Conditional Access
- Níveis de autenticação personalizados do Conditional Access
- Gerenciar contas de acesso de emergência no Microsoft Entra ID
- Configurar e habilitar as políticas de risco do Microsoft Entra ID Protection
Explore as paginas de identidade que sustentam este tema