Fortalecimento do Tenant Azure: Security Defaults

O Que É o Fortalecimento do Tenant Azure?

A Microsoft agora ativa o Security Defaults automaticamente para novos tenants do Microsoft 365 e Azure — com um período de carência de 24 horas antes da aplicação, e somente se o tenant ainda não tiver políticas de Conditional Access ou MFA legado por usuário em vigor. Na prática, muitos tenants de produção ainda operam sem uma linha de base de segurança real: o Security Defaults é desativado no momento em que um administrador começa a criar Conditional Access personalizado e a política substituta nunca é concluída, os protocolos de autenticação legados permanecem acessíveis, os convites de convidados ficam abertos a qualquer usuário, e nenhuma política de Conditional Access bloqueia as lacunas deixadas para trás.

O fortalecimento do tenant (tenant hardening) é o processo de revisar e corrigir sistematicamente essas configurações padrão. Não é um trabalho glamoroso, mas é fundamental: todo outro controle de segurança do Azure — Conditional Access, PIM, Identity Protection — depende de a configuração do tenant estar correta.

Este artigo aborda as verificações de configuração de tenant Azure mais críticas e como validá-las e corrigi-las.

Como Funciona

A configuração do tenant Azure é gerenciada em múltiplos locais:

• Entra ID > Propriedades — configurações em todo o tenant, incluindo o Security Defaults
• Entra ID > Identidades Externas — configurações de convidados e colaboração B2B
• Entra ID > Métodos de Autenticação — quais métodos de MFA são permitidos
• Exchange Online Admin Center — configurações de autenticação legada para protocolos de e-mail
• Microsoft 365 Admin Center — configurações de segurança em nível de serviço

Configurações incorretas em qualquer um desses locais podem criar uma superfície de ataque que contorna todos os outros controles. Uma política de Conditional Access perfeitamente configurada é irrelevante se a autenticação legada ainda estiver habilitada no nível do Exchange.

A Cadeia de Ataque

Explorando Security Defaults Desativado

Quando o Security Defaults está desativado e nenhuma política de Conditional Access preenche a lacuna:

# Password spray contra o M365 sem linha de base de MFA
o365spray --spray -U users.txt -P passwords.txt --domain corp.com

# Bypass de autenticação legada — acesso IMAP ignora o Conditional Access
curl -u [email protected]:Password1 imaps://outlook.office365.com/INBOX

Explorando Configurações B2B Abertas

# Com qualquer conta de membro — convida uma identidade externa controlada pelo atacante
New-MgInvitation -InvitedUserEmailAddress "[email protected]" `
    -InviteRedirectUrl "https://myapps.microsoft.com" `
    -SendInvitationMessage $false

Checklist de Auditoria de Configuração

1. Status do Security Defaults

Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgPolicyIdentitySecurityDefaultEnforcementPolicy | Select-Object IsEnabled
# Deve ser True (se não houver políticas de CA em vigor)

2. Status da Autenticação Legada

# Verifica as políticas de autenticação legada do Exchange Online
Connect-ExchangeOnline
Get-AuthenticationPolicy | Select-Object Name, AllowBasicAuth*
# Todos os valores AllowBasicAuth* devem ser False

3. Configurações de Convite de Convidados

# Verifica quem pode convidar convidados
Get-MgPolicyAuthorizationPolicy | Select-Object AllowInvitesFrom
# Valores válidos: none, adminsAndGuestInviters, adminsGuestInvitersAndAllMembers, everyone
# Deve ser: none ou adminsAndGuestInviters

4. Política de Métodos de Autenticação

# Lista os métodos de autenticação habilitados
Get-MgPolicyAuthenticationMethodPolicy | Select-Object -ExpandProperty AuthenticationMethodConfigurations |
    Where-Object {$_.State -eq "enabled"} | Select-Object Id, State
# Verifique se o SMS não é o único método de MFA (suscetível a phishing) — prefira o Authenticator App ou FIDO2

5. Configurações de Acesso entre Tenants

# Verifica se a colaboração B2B de entrada está aberta a todas as organizações externas
Get-MgPolicyCrossTenantAccessPolicyDefault | Select-Object -ExpandProperty B2BCollaborationInbound |
    Select-Object -ExpandProperty UsersAndGroups
# AccessType não deve ser "allowed" para o destino "AllUsers" sem restrições adicionais

Detecção

Microsoft 365 Secure Score

O Microsoft 365 Secure Score fornece uma avaliação automatizada da configuração do tenant em relação à linha de base recomendada pela Microsoft. Verifique-o em security.microsoft.com > Secure Score.

A Microsoft limita cada ação recomendada a 10 pontos ou menos, e pontua muitas delas como uma porcentagem da configuração do seu tenant, em vez de um valor fixo — não há um valor de pontos universal fixo por ação. Exemplos práticos da própria orientação de pontuação da Microsoft: exigir MFA para funções administrativas vale 10 pontos, garantir que todos os usuários possam concluir o MFA vale 9 pontos, e bloquear a autenticação legada via Conditional Access vale 7 pontos. Restringir os convites de convidados e habilitar o Privileged Identity Management também aumentam sua pontuação — consulte a própria lista de recomendações do Secure Score para os valores exatos no seu tenant.

Logs de Auditoria do Entra ID

// Detecta a desativação do Security Defaults
AuditLogs
| where OperationName == "Update security defaults"
| mv-expand props = TargetResources.modifiedProperties
| where tostring(props.newValue) has "false"

Remediação

Ative o Security Defaults (Se Não Houver Conditional Access)

Entra ID > Propriedades > Gerenciar Security Defaults > Ativado = Sim

Desative a Autenticação Legada Globalmente

# Cria uma política de autenticação bloqueando toda a autenticação básica
New-AuthenticationPolicy -Name "Block Basic Auth"
Set-AuthenticationPolicy -Identity "Block Basic Auth" `
    -AllowBasicAuthImap $false -AllowBasicAuthPop $false `
    -AllowBasicAuthSmtp $false -AllowBasicAuthWebServices $false `
    -AllowBasicAuthRpc $false -AllowBasicAuthMapi $false

# Aplica a todos os usuários
Get-User -ResultSize Unlimited | Set-User -AuthenticationPolicy "Block Basic Auth"

Restrinja os Convites de Convidados

Entra ID > Identidades Externas > Configurações de colaboração externa:
Configurações de convite de convidados = "Somente usuários atribuídos a funções de administrador específicas podem convidar"

Ative Métodos de MFA Resistentes a Phishing

Entra ID > Métodos de autenticação > Chaves de segurança FIDO2 = Ativado (para todos ou administradores)
Entra ID > Métodos de autenticação > Microsoft Authenticator = Ativado
Entra ID > Métodos de autenticação > SMS = Desativado (suscetível a phishing, substitua pelo Authenticator)

Como a EtcSec Detecta Isso

A EtcSec audita a configuração completa do seu tenant Azure em cada varredura, verificando todas as configurações que afetam a linha de base de segurança.

AZ_SECURITY_DEFAULTS_DISABLED sinaliza tenants em que o Security Defaults está desativado — uma lacuna fundamental na linha de base que remove proteções em todo o tenant, como a aplicação básica de MFA.

CA_NO_LEGACY_AUTH_BLOCK sinaliza a ausência de uma política de Conditional Access que bloqueie os protocolos de autenticação legados, deixando aberto um bypass de MFA para qualquer atacante com uma senha roubada.

GUEST_INVITATION_UNRESTRICTED sinaliza tenants em que a política de convite de convidados permite que qualquer usuário convide convidados externos, em vez de restringir os convites a administradores ou funções específicas.

Prioridades de Revisão

O Fortalecimento do Tenant Azure: Corrigindo os Padrões Inseguros que Vêm de Fábrica deve ser tratado como uma exposição real dentro do seu tenant Entra ID e Azure, não como uma configuração isolada única. Comece definindo o perímetro da revisão: quais administradores, convidados, service principals, registros de aplicativo, exclusões de política e contas break-glass são afetados, quais fluxos de trabalho de negócio dependem deles, quais privilégios eles expõem, e quais exceções de emergência foram adicionadas ao longo do tempo. Essa etapa de escopo evita uma remediação superficial, porque o sintoma técnico costuma ser menor do que o raio de impacto operacional. Ao documentar o caminho completo da configuração até o privilégio, a equipe pode priorizar mudanças que reduzem o risco rapidamente sem quebrar o acesso de produção. Isso também cria uma linha de base defensável para validação posterior e oferece à liderança uma explicação clara de por que o problema importa agora.

Controles Adjacentes a Revisar

Quando atacantes alcançam seu tenant Entra ID e Azure, raramente param no primeiro ponto fraco. Em torno do Fortalecimento do Tenant Azure: Corrigindo os Padrões Inseguros que Vêm de Fábrica, eles normalmente testam se o caminho exposto pode ser encadeado com autenticação legada, governança fraca de convidados, consentimento amplo de aplicativos, contas de emergência obsoletas e funções que nunca foram revisadas. Isso significa que os defensores devem revisar não apenas a fraqueza principal, mas toda dependência próxima que transforma acesso em persistência ou escalonamento de privilégios. Confirme quais identidades, funções, permissões e pressupostos de confiança podem ser reutilizados por um operador motivado. Se uma correção fecha apenas um objeto enquanto deixa intocados os caminhos de privilégio adjacentes, o risco efetivo praticamente não muda. Uma revisão disciplinada das oportunidades de encadeamento é o que transforma este tema em um exercício prático de fortalecimento, em vez de uma verificação pontual.

Evidências e Telemetria a Coletar

Uma resposta sólida ao Fortalecimento do Tenant Azure: Corrigindo os Padrões Inseguros que Vêm de Fábrica precisa de evidências que possam ser revisadas tanto pelas equipes de engenharia quanto pelas de detecção. Colete logs de login, logs de auditoria, alterações de atribuição de função, eventos de consentimento, alterações de credenciais de aplicativo e sinais de login arriscado, compare as alterações recentes com janelas de manutenção conhecidas e isole contas ou sistemas que mudaram de comportamento sem um motivo de negócio claro. Use essas evidências para responder a três perguntas: quando o caminho arriscado surgiu, quem ainda pode usá-lo, e se existe exposição semelhante em outro lugar no seu tenant Entra ID e Azure. Uma boa revisão de telemetria também ajuda a separar a dívida técnica herdada do uso indevido ativo. Essa distinção importa, porque o plano de remediação para uma configuração incorreta obsoleta é diferente do plano para um caminho que já mostra atividade semelhante à de um atacante ou exceções de política repetidas.

Fraquezas Adjacentes que Vale a Pena Revisar

Poucos ambientes contêm apenas o Fortalecimento do Tenant Azure: Corrigindo os Padrões Inseguros que Vêm de Fábrica isoladamente. Na prática, o mesmo tenant ou segmento de diretório costuma conter autenticação legada, governança fraca de convidados, consentimento amplo de aplicativos, contas de emergência obsoletas e funções que nunca foram revisadas, e essas fraquezas vizinhas decidem se o problema é apenas um ruído ou verdadeiramente crítico. Revise proprietários compartilhados, permissões herdadas, exceções duplicadas e atalhos administrativos de longa duração. Verifique se a mesma equipe aprovou padrões de risco semelhantes em vários locais, porque decisões repetidas geralmente apontam para uma lacuna de processo, e não para um único bug técnico. Essa revisão mais ampla evita uma limpeza parcial e oferece uma chance melhor de remover todo o caminho de ataque. Também melhora a prontidão para auditoria, porque o estado final é mais fácil de explicar e mais fácil de monitorar ao longo do tempo.

Ordem de Remediação Que Reduz o Risco Rapidamente

Para o Fortalecimento do Tenant Azure: Corrigindo os Padrões Inseguros que Vêm de Fábrica, a remediação deve seguir uma ordem que reduza a exposição antes de buscar a perfeição. Primeiro, remova os caminhos de expansão de privilégio mais fáceis, depois bloqueie as identidades ou objetos de maior valor, e só depois disso corrija as lacunas de higiene secundárias. Use Conditional Access, PIM, privilégio mínimo, revisões de acesso, verificações de propriedade de aplicativos, fluxos de aprovação e MFA forte como o conjunto de controles que define o estado-alvo. Cada mudança deve ter um responsável, uma nota de rollback e uma etapa de validação. Isso evita que projetos longos travem depois da primeira correção técnica. Se um redesenho completo não for possível imediatamente, documente controles temporários que reduzam o potencial de abuso hoje e agende o trabalho estrutural dentro da próxima revisão operacional semanal e da revisão mensal de fortalecimento. O ponto importante é a redução mensurável do risco, não a conformidade cosmética.

Validação Após Cada Alteração

Depois de alterar qualquer configuração relacionada ao Fortalecimento do Tenant Azure: Corrigindo os Padrões Inseguros que Vêm de Fábrica, valide o resultado tanto do ponto de vista administrativo quanto do ponto de vista do caminho de ataque. Confirme que os usuários e sistemas pretendidos ainda funcionam, e então prove que o caminho perigoso não concede mais a mesma vantagem. Execute novamente a coleta de evidências sobre logs de login, logs de auditoria, alterações de atribuição de função, eventos de consentimento, alterações de credenciais de aplicativo e sinais de login arriscado, revise os registros de aprovação e verifique se objetos vizinhos ainda preservam alguma solução alternativa. A validação também deve incluir uma declaração escrita simples dos critérios de sucesso, para que a equipe saiba o que significa o encerramento. Em equipes maduras, essa etapa é o que evita regressões: a correção só é aceita quando o caminho arriscado está fechado, o serviço de negócio continua funcionando, e o estado resultante corresponde ao alvo de fortalecimento que você realmente deseja.

Fortalecimento do Tenant Azure: Validação Antes da Aprovação Final

Uma revisão sólida do Fortalecimento do Tenant Azure deve terminar com evidências de produção, não com a suposição de que o caminho arriscado desapareceu. Antes de encerrar o achado, reverifique as atribuições de função, o escopo da política, as permissões de aplicativo ou as configurações de convidados, as evidências de login, auditoria ou risco do tenant real, e o caminho de exceção que poderia recriar silenciosamente a exposição. Confirme que o estado mais seguro se aplica ao escopo que realmente importa: a OU de produção, a atribuição de função efetiva, o caminho do aplicativo, ou o caminho de confiança e delegação que um atacante realmente exploraria. Registre o responsável técnico, a dependência de negócio e a condição de rollback, para que a próxima revisão possa determinar se o estado mais seguro foi mantido.

Use um checklist curto de aprovação final:

• verifique se o estado arriscado desapareceu do ponto de vista do atacante, não apenas em uma captura de tela do administrador
• mantenha uma exportação ou amostra de log de antes/depois que comprove que o escopo afetado mudou
• documente o responsável e a decisão de exceção, caso o controle não pudesse ser totalmente aplicado

Para exposições adjacentes, cruze o resultado com Conformidade AD e Azure: NIS2, ISO 27001, CIS, Falhas acesso condicional Entra ID: quais erros deixam uma exposicao real, Gerenciamento de Acesso Privilegiado no Azure: Riscos sem PIM, e Comparacao ferramenta auditoria AD: como comparar PingCastle, Purple Knight e workflows de auditoria repetíveis. A mesma lacuna de controle costuma reaparecer em caminhos de identidade próximos, lacunas de log ou permissões delegadas, motivo pelo qual a etapa final de validação importa tanto quanto o achado inicial.

Fortalecimento do Tenant Azure: Evidências a Manter para o Próximo Ciclo de Revisão

O próximo revisor não deveria precisar reconstruir o caso de memória. Mantenha as evidências que originalmente justificaram o achado, a prova de que a mudança foi aplicada, e a nota que explica por que o estado final é aceitável. Para este tema, as evidências mais úteis geralmente combinam a exportação do tenant ou a captura de tela que mostra o escopo afetado, as evidências de login, auditoria ou política que comprovam que o controle agora se aplica, e a nota de responsável, aprovação e exceção para o estado final. Esse pacote compacto torna as revisões trimestrais ou pós-mudança muito mais rápidas e ajuda a explicar se o problema foi removido, reduzido ou formalmente aceito.

Se uma mudança posterior de administrador, política ou aplicativo reabrir o caminho, essa evidência histórica também facilita provar o que sofreu desvio (drift). É isso que transforma o Fortalecimento do Tenant Azure de uma verificação pontual em um processo de garantia repetível.

Leitura Relacionada

Revise este tema junto com Falhas acesso condicional Entra ID: quais erros deixam uma exposicao real, Gerenciamento de Acesso Privilegiado no Azure: Riscos sem PIM, Contas de Convidado Azure: Riscos do Tenant, Registros de Aplicativo Azure: Apps com Privilegios Excessivos, e Azure Identity Protection: Bloqueando Credenciais Vazadas. Esses posts adjacentes mostram como as mesmas fraquezas de identidade costumam se encadear em uma avaliação real, em vez de aparecerem como achados isolados.

• Falhas acesso condicional Entra ID: quais erros deixam uma exposicao real
• Gerenciamento de Acesso Privilegiado no Azure: Riscos sem PIM
• Contas de Convidado Azure: Riscos do Tenant
• Registros de Aplicativo Azure: Apps com Privilegios Excessivos
• Azure Identity Protection: Bloqueando Credenciais Vazadas

Usar essas referências mantém a discussão de remediação focada no caminho de ataque completo, em vez de uma única lacuna de controle.

Valide a Linha de Base de Fortalecimento ao Longo do Tempo

As configurações padrão devem ser tratadas como um ponto de partida, não como o resultado final do fortalecimento. Depois de aplicar padrões de tenant mais seguros, confirme quais equipes ainda dependem de exceções amplas, se novos aplicativos ou usuários podem contornar os controles pretendidos, e como o desvio (drift) é monitorado ao longo do tempo. Um tenant fortalecido permanece resiliente somente quando a responsabilidade, a cadência de revisão e o tratamento de exceções são tão disciplinados quanto a implementação inicial.