Proteção de palavras-passe Entra ID: listas e a armadilha da expiração

O que é a proteção de palavras-passe Entra ID?

A proteção de palavras-passe Entra ID (Entra ID Password Protection) avalia novas palavras-passe face aos termos proibidos da lista global da Microsoft e, quando configurada, da lista personalizada da organização. A análise operacional envolve três perguntas distintas: os termos específicos da organização estão abrangidos, as alterações locais são efetivamente bloqueadas e a expiração das palavras-passe continua a obrigar a alterações periódicas?

A Microsoft documenta a lista global na cloud como automática e impossível de desativar. A ausência de uma lista personalizada não significa, por isso, que o tenant não tenha proteção de palavras-passe. Significa que a organização não acrescentou o seu próprio vocabulário à proteção de base. A validação ocorre durante alterações e reposições de palavras-passe. Microsoft Learn: conceitos de Password Protection.

Trate esta análise como uma revisão de controlos integrada na auditoria de segurança do Microsoft Entra ID, mais abrangente, que explica como verificar controlos de acesso aplicáveis, funções privilegiadas, confiança em aplicações e identidades externas. Uma política de palavras-passe, por si só, não responde a essas questões mais amplas.

Como funciona: porque a lista global não é suficiente

A Microsoft constrói a sua lista global a partir da telemetria de segurança do Entra. A lista personalizada acrescenta termos locais, como marcas, produtos, localizações da sede e abreviaturas internas. As duas listas funcionam em conjunto; a lista personalizada não substitui a proteção global de base. Microsoft Learn: palavras-passe proibidas personalizadas.

Não presuma que todas as palavras-passe que contêm um termo listado têm de ser rejeitadas. O algoritmo de avaliação normaliza a entrada, verifica variantes e pontua a palavra-passe resultante; uma palavra-passe suficientemente forte pode conter um termo proibido e, ainda assim, ser aceite. Leia o algoritmo de avaliação documentado antes de conceber testes de validação.

Esta distinção altera o que constitui uma lista personalizada útil. Analise o vocabulário da organização em vez de importar uma enorme coleção de palavras-passe completas. Verifique se estão representadas as marcas atuais, os nomes de empresas adquiridas, as famílias de produtos e as abreviaturas com significado local. Associe os casos de teste aos termos configurados para que uma rejeição possa ser investigada, em vez de simplesmente presumida.

O artigo sobre password spraying explica o ataque: um pequeno conjunto de tentativas distribuído por muitas contas. Este guia analisa a configuração que reduz a escolha de palavras-passe previsíveis antes da chegada dessas tentativas. Não trata um resultado relativo à política de palavras-passe como prova de que ocorreu um ataque de spraying.

A armadilha da expiração

As recomendações da Microsoft para políticas de palavras-passe desaconselham a expiração periódica para contas exclusivamente na cloud e recomendam palavras-passe que não expiram. As mesmas orientações salientam a utilização de palavras-passe únicas, o registo de MFA e a proteção de identidade. A remoção da expiração programada deve acompanhar esses controlos; não é motivo para ignorar uma suspeita de comprometimento.

O resultado contraintuitivo é expiração ativada, em vez de expiração desativada. Analise por que existe um requisito de alteração baseado na idade da palavra-passe, a que população de identidades se aplica e se algum requisito vinculativo impede a sua remoção. Mantenha qualquer exceção separada da configuração de base recomendada para a cloud. Não marque uma restrição de negócio documentada como corrigida apenas porque a recomendação predefinida é diferente.

As predefinições não provam o estado do seu tenant

A página da política de palavras-passe do Entra documenta a ausência de expiração como a predefinição atual da idade máxima, mas uma predefinição de 90 dias para tenants criados antes de 2021. Também descreve separadamente a definição individual que impede a expiração da palavra-passe de um utilizador. A idade do tenant e uma flag de utilizador não substituem, portanto, a leitura da política efetiva.

O procedimento de expiração do Microsoft 365 aplica-se a utilizadores exclusivamente na cloud. Exclui expressamente utilizadores híbridos que usam sincronização de hashes de palavras-passe, autenticação pass-through ou federação local. Numa análise híbrida, identifique a autoridade responsável pelas palavras-passe antes de escolher o procedimento de alteração.

Medir a configuração antes de a alterar

1. Registar as definições de Password Protection no portal

Abra Entra ID > Authentication methods > Password protection. Registe Enforce custom list, as entradas da lista, Enable password protection on Windows Server Active Directory e o Mode local. São observações separadas. Um interruptor do Windows Server ativado não indica se os agentes receberam uma política nem se todos os controladores pretendidos estão abrangidos.

A página da Microsoft sobre operações locais indica que Audit aceita palavras-passe que seriam rejeitadas, registando o resultado; Enforced rejeita palavras-passe inseguras. Definir a opção do Windows Server como No interrompe a validação nos agentes DC implementados. Estas definições dizem respeito ao AD DS e não constituem um interruptor que desative a lista global automática na cloud.

2. Ler a exceção de expiração do utilizador na cloud

Com o Microsoft Graph PowerShell instalado e ligado ao tenant pretendido, com pelo menos a função User Administrator, conforme exige o procedimento citado, utilize o comando seguinte, reproduzido sem alterações do procedimento da Microsoft para verificar a expiração:

Get-MgUser -All -Property UserPrincipalName, PasswordPolicies | Select-Object UserPrincipalName, @{N="PasswordNeverExpires";E={$_.PasswordPolicies -contains "DisablePasswordExpiration"}}

-All solicita todos os utilizadores; -Property obtém explicitamente as propriedades utilizadas pela expressão. Interprete o resultado no sentido correto: PasswordNeverExpires=True significa que a flag que desativa a expiração está presente. False significa que essa flag não foi encontrada; por si só, não estabelece uma idade máxima finita para as palavras-passe do domínio.

Combine este inventário com Microsoft 365 admin center > Settings > Org Settings > Security and Privacy > Password expiration policy para a população na cloud a que se aplica. Registe o âmbito dos domínios e quaisquer exceções individuais. O procedimento alerta que os novos domínios geridos, ou os domínios convertidos a partir de federação, precisam que a política da organização seja reaplicada para atualizar todos os domínios. Microsoft Learn: política de expiração.

Não é apresentada aqui qualquer saída de um tenant: o comando é uma medição documentada, não uma afirmação de que determinado ambiente passou a verificação.

Deteção: verificar a aplicação da política no ambiente local

Utilize o canal Admin do agente DC em Applications and Services Logs > Microsoft > AzureADPasswordProtection > DCAgent > Admin. A referência de monitorização da Microsoft distingue estes resultados:

O evento 30019 é uma notificação do estado da política, não um resultado emitido em cada alteração ou reposição de palavra-passe. Indica que a política recebida desativou o processamento: as palavras-passe seguintes são consideradas conformes sem validação, e não são registados mais eventos até a política mudar.

Os pares de eventos associados partilham uma CorrelationId. Analise o evento que contém o motivo juntamente com o resultado e conserve a identidade do controlador e o carimbo temporal. Não conte o par como dois pedidos rejeitados independentes.

Para obter um resumo relativo a um controlador específico, a Microsoft apresenta este comando num servidor proxy de Password Protection:

Get-AzureADPasswordProtectionSummaryReport -DomainController bplrootdc2

Este é o nome de controlador usado no exemplo da Microsoft, não um ambiente aqui observado. Substitua-o pelo controlador em análise. O relatório lê os registos Admin dos agentes através de PowerShell remoto; a ausência de acesso ou de agentes limita a evidência. Não interprete um relatório vazio como um teste bem-sucedido de aplicação da política.

Estes eventos descrevem a validação de palavras-passe, não ataques de início de sessão. Correlacione um incidente separadamente através da telemetria de início de sessão; uma rejeição pela lista personalizada, por si só, não identifica a pessoa que tenta um ataque de password spraying.

Correção: termos personalizados, aplicação no AD DS e expiração (Remediation)

1. Ativar e validar a lista personalizada

Siga o tutorial da lista personalizada com pelo menos a função Authentication Policy Administrator e licenciamento Entra ID P1 ou P2. Defina Enforce custom list como Yes, introduza um termo por linha e guarde. Os termos devem ter entre 4 e 16 caracteres; a lista suporta até 1.000 termos. As atualizações podem demorar várias horas.

Utilize uma conta de teste sem privilégios de administrador e cumpra os pré-requisitos documentados de SSPR. Teste uma variante fraca de um termo configurado após a propagação. Registe a aceitação ou rejeição sem conservar a palavra-passe. Se um teste for inesperadamente aceite, analise a aplicação da política, a propagação e o algoritmo de avaliação antes de declarar a lista ineficaz.

2. Concluir a implementação local

Siga o guia de implementação da Microsoft: instale e registe o serviço proxy e a floresta, implemente os agentes DC e tenha em conta o reinício necessário para carregar o filtro de palavras-passe. Os controladores com capacidade de escrita são os pontos de validação; os RODCs encaminham as operações de palavras-passe e não precisam de um agente DC.

Audit é o modo inicial documentado. Utilize esse período para testar os processos de alteração de palavras-passe e a promoção/despromoção de controladores de domínio, passando depois a Enforced após resolver os problemas operacionais. Confirme que a opção do Windows Server está em Yes e guarde a alteração seguindo o procedimento operacional. Repita um teste controlado com uma palavra-passe fraca e analise os respetivos eventos de rejeição correlacionados.

O guia de implementação também explica o funcionamento com políticas em cache quando os proxies estão indisponíveis. Verifique a atualidade da política, além da presença dos agentes: um serviço em execução e uma captura de ecrã do portal são elementos de prova diferentes.

3. Remover a expiração periódica na cloud quando aplicável

Para utilizadores exclusivamente na cloud, analise a opção recomendada de não expiração no painel de expiração do Microsoft 365. Para a exceção de um utilizador individual, a Microsoft documenta este comando em Definir uma palavra-passe para nunca expirar:

Update-MgUser -UserId <user ID> -PasswordPolicies DisablePasswordExpiration

O marcador foi copiado da documentação; substitua-o pelo ID do utilizador pretendido. Analise os valores existentes da política de palavras-passe antes de uma atualização direcionada. Evite transformar o exemplo numa alteração de todo o tenant sem análise prévia e volte a executar o inventário de apenas leitura depois.

Para identidades híbridas, esclareça separadamente a política do lado AD e o modelo de sincronização. O procedimento da cloud não certifica uma alteração da idade máxima no ambiente local. Preserve as alterações de palavras-passe desencadeadas por comprometimento e os controlos de MFA e de risco de identidade recomendados pela Microsoft.

Como o EtcSec deteta esta situação

As implementações dos detetores do etc-collector analisadas para este artigo avaliam três sinais de configuração:

Utilize estes resultados para iniciar as verificações manuais correspondentes. A ausência de um resultado não substitui as medições no portal, o inventário Graph e a validação controlada no AD DS descritos acima. Conclua cada correção com evidência do percurso real de alteração de palavras-passe que está a ser protegido.