Actualizado: A Proteção por Senha do Azure AD ficou geralmente disponível em2 de abril de 2019. O serviço é basicamente o mesmo que apresentei neste post, com as seguintes atualizações:
- O limite de dois mandatários foi suprimido.
- Ao registar o proxy e a floresta do Active Directory, estão agora disponíveis 3 modos de autenticação . Dois deles suportam MFA, pelo que não é necessário ter uma conta de Administrador Global sem MFA.
- O algoritmo de avaliação de palavras-passe proibidas foi actualizado. Consulte "Como são avaliadas as palavras-passe" na documentação da Microsoft. Nota: este algoritmo pode ser alterado em qualquer altura, sem aviso prévio ou actualização da documentação.
- O licenciamento foi simplificado: Todos os utilizadores sincronizados com o Azure AD têm de ter o Azure AD Premium P1 ou P2. Com este requisito satisfeito, todos os utilizadores do Active Directory estão licenciados para este serviço.
- Os clientes da Pré-visualização devem actualizar os agentes; os agentes da Pré-visualização pública deixarão de funcionar a partir de 1 de Julho de 2019.
- As minhas fontes da Microsoft dizem-me que, com um pouco de comunicação prévia, os utilizadores não estão a achar a nova rejeição de palavras-passe comuns com a mensagem padrão "A sua palavra-passe não cumpre os requisitos de complexidade" tão confusa como pensavam.
- Comece a implementar!
A Microsoft forneceu finalmente um serviço que reduz o risco de segurança relacionado com palavras-passe mais crítico nas empresas actualmente: palavras-passe comuns. Deve experimentar esta nova capacidade do Active Directory hoje, para que possa implementá-la assim que estiver disponível.
Esta é uma publicação longa; se não estiver interessado na versão TL;DR (e deve estar), pode saltar directamente para
- A palavra-passe comum como vector de ataque
- Arquitectura
- Fluxo de autenticação em tempo de execução
- Processo de avaliação da palavra-passe
- Vantagens da concepção
- Etapas de implantação
- Controlo
- Licenciamento
- Informações diversas
A palavra-passe comum como vector de ataque
Publiquei neste blogue e falei no Cloud Identity Summit (agora Identiverse) sobre as recomendações da Microsoft e do NIST sobre como configurar o comprimento da palavra-passe, a expiração e outras políticas de palavra-passe à luz da sua investigação e experiência prática. Uma das principais recomendações de ambas as organizações é a utilização de uma lista de palavras-passe proibidas, na qual as palavras-passe mais simples e mais comuns não são permitidas. (E sim, estou aqui para vos dizer que algumas das palavras-passe mais comuns são 'password' e '12345678'. Temo pela raça humana).
De acordo com a Microsoft, os ataques contra palavras-passe comuns utilizando ataques do tipo "password spray" aumentaram drasticamente nos últimos meses. É extremamente difícil defender-se deles com ferramentas de segurança convencionais porque o atacante não ataca uma única conta com várias palavras-passe. Em vez disso, utiliza algumas palavras-passe comuns para atacar várias contas. Cada conta é atacada apenas algumas vezes, e talvez com um longo intervalo entre as tentativas para evitar o accionamento de alertas. A melhor maneira de se proteger contra esses ataques é simplesmente não ter senhas comuns.
A maioria das grandes organizações utiliza uma arquitectura de identidade híbrida em que as palavras-passe são geridas numa floresta do Active Directory no local. E, infelizmente, o Active Directory não tem uma solução pronta a utilizar para banir as palavras-passe comuns. Como resultado, a maioria das organizações não tinha protecção contra palavras-passe comuns.
A Protecção de Palavra-passe do Azure AD é um serviço híbrido em pré-visualização pública que fornece protecção contra palavras-passe comuns para contas organizacionais do Azure AD e contas do Windows Server Active Directory no local. Impede que os utilizadores e administradores alterem ou redefinam as suas palavras-passe para palavras-passe simples e facilmente decifráveis, como "987654321" ou "quertyjkl;" (para os dactilógrafos).
Arquitectura
O Azure AD Password Protection tem um componente Azure, um serviço proxy local, um serviço DC e, finalmente, um filtro de palavra-passe personalizado (Figura 1):
Os objectivos desta arquitectura são: 1) utilizar a GBPL (lista global de palavras-passe proibidas) do Azure para proteger as contas do Azure AD da utilização de palavras-passe comuns; 2) permitir que os administradores do Azure criem uma lista personalizada de palavras-passe proibidas que aumente a GBPL; e 3) proteger as contas do Active Directory de palavras-passe comuns, fornecendo um serviço no local que utiliza a lista consolidada de palavras-passe proibidas.
Azure
O Azure AD tem utilizado uma lista de palavras-passe proibidas gerada internamente há já algum tempo e também impõe a adesão a palavras-passe mínimas mais longas. Se introduzir uma palavra-passe comum, será gentilmente aconselhado a tentar novamente:
O serviço de protecção de palavras-passe (Figura 3) utiliza a inteligência contra ameaças do Azure para uma visão global das palavras-passe proibidas. A lista é compilada a partir de palavras-passe em listas de credenciais divulgadas, além da análise que o sistema de inteligência contra ameaças do Azure efectua sobre os 20 milhões (!) de tentativas de aquisição de contas que detecta diariamentei. Esta lista não contém todas as palavras-passe comuns alguma vez encontradas, apenas as 1000 mais comuns que são activamente utilizadas em ataquesi.
Porque é que o serviço não verifica se existem mais de 1000 palavras-passe comuns? Isto pode ser prático para o Azure, mas não para servidores locais. No processo de avaliação da palavra-passe, a palavra-passe do utilizador é comparada não só com as mais de 1000 palavras-passe proibidas, mas também com potenciais milhares de variações de cada uma. São muitas palavras-passe para comparar. Se a lista de palavras-passe contivesse 1 milhão de palavras-passe, isso poderia significar milhares de milhões de variações de palavras-passeii para os seus DCs verificarem - e estes ficariam paralisados com a carga.
O controlo e a configuração da funcionalidade de protecção por palavra-passe são tratados no bloco Azure Active Directory do portal de gestão, na nova secção Métodos de autenticação. O único item nesta nova secção neste momento - embora esteja certo de que irá aumentar - é a Protecção por palavra-passe (Figura 4).
Para além da lista global de palavras-passe proibidas (GBPL) gerada pelo Azure, a Protecção de Palavra-passe do Azure AD fornece uma vista alargada do inquilino das palavras-passe proibidas a utilizar (TBPL). Por exemplo, uma empresa de serviços financeiros pode querer proibir palavras-passe como "hipoteca" ou "seguro", para além das palavras-passe comuns determinadas globalmente pelo Azure. (Na figura, adicionei empresas de automóveis à lista personalizada.) Esta lista consolidada é a que é utilizada nas instalações.
Note que o serviço está cuidadosamente configurado de modo a que, se instalar componentes no local sem tocar nos controlos do Azure, o serviço de protecção por palavra-passe comece a funcionar imediatamente, em modo de auditoria, utilizando a lista global de palavras-passe proibidas do Azure.
Serviço de proxy
O objectivo do serviço de proxy do Azure AD Password Protection é adquirir a BPL e passá-la aos DCs. Actuando como um serviço de retransmissão sem estado, o proxy permite que os DCs obtenham a BPL do Azure AD sem necessitarem eles próprios de acesso à Internet (um ponto sensível na segurança empresarial). O proxy não pesquisa o próprio Azure AD; simplesmente encaminha os pedidos de BPL do DC para o serviço do Azure e encaminha a BPL resultante para o DC requerente. Isto elimina qualquer necessidade de os próprios DCs terem conectividade com a Internet.
O serviço de proxy pode ser instalado em qualquer servidor associado ao domínio. Nesta pré-visualização, pode ser instalado em um ou dois servidores para fornecer tolerância a falhas; espera-se que este limite seja levantado antes da GA. Tanto o serviço de proxy como a floresta do Active Directory têm de ser registados no Azure AD utilizando o novo módulo AzureADPasswordProtection. (Siga as instruções cuidadosamente.) Uma vez registado, o proxy anuncia-se ao DC com um ponto de ligação do serviço AzureAdPasswordProtectionProxy sob o objecto computador (Figura 5):
Agente DC
O pacote do agente DC contém dois componentes (Figura 6). O primeiro componente é o próprio agente DC, que é executado como AzureADPasswordProtectionDCAgent. O segundo é um filtro de palavra-passe personalizado. Vamos analisá-los na ordem inversa.
Um filtro de palavra-passe do AD é uma DLL personalizada que lhe permite alargar a funcionalidade básica de uma verificação de validade da palavra-passe. O filtro de palavra-passe do cliente do Azure AD Password Protection é o mais simples possível; tudo o que faz é reencaminhar o pedido de palavra-passe para o agente DC e recolher a resposta de aceitação ou recusa do agente.
Como o filtro de palavra-passe é uma parte integrante do sistema de segurança do CD, um efeito secundário é que o CD tem de ser reiniciado sempre que o agente do CD é instalado ou removido.
O agente DC é o coração do serviço no local. Durante as operações de tempo de execução do DC, o agente verifica a validade das alterações da palavra-passe do utilizador em relação à política de palavras-passe. Em segundo plano, garante que o DC tem uma cópia actual da BPL obtida do Azure AD. Se não tiver, obtém uma, processa-a para criar uma política de palavra-passe e, em seguida, armazena-a no SYSVOL em
C:WindowsSYSVOLsysvolPolicies{4A9AB66B-4365-4C2A-996C-58ED9927332D}AzureADPasswordProtection.
A forma como os agentes DC (numa implementação de produção, deve haver um em cada DC) obtêm e distribuem a política de palavra-passe é bastante elegante:
- Um agente DC em cada site do Active Directory acorda aproximadamente uma vez por hora para decidir se a sua cópia local da política de palavra-passe no SYSVOL precisa de ser actualizada.
- Se a política precisar de ser actualizada, ou se ainda não existir uma política, solicitará uma nova BPL encriptada do Azure AD através do proxy, criará uma política de palavra-passe a partir da mesma e guardá-la-á no SYSVOL.
- O SYSVOL replica essa política em todos os DCs do domínio por meio do DFS-R (Figura 7).
No máximo, um DC por site pode solicitar a BPL, mas provavelmente será muito menos - apenas uma vez por hora por domínio. Porquê? Por causa da replicação eficiente da política do DFS-R via SYSVOL. Em uma rede decentemente conectada, uma política atualizada será replicada para todos os DCs antes que outros agentes acordem e, portanto, eles terão uma política atual e não precisarão solicitar uma nova BPL do Azure. Essa arquitetura também garante que os DCs em ambientes bloqueados ainda receberão a política de senha, pois a replicação do SYSVOL é uma parte essencial da funcionalidade do DC.
Fluxo de autenticação em tempo de execução
A avaliação da política de palavra-passe proibida está integrada no processo normal de avaliação de palavras-passe do AD (Figura 8):
- O utilizador tenta definir uma nova palavra-passe e o seu DC local processa o pedido.
- No DC, o pedido é processado pelo filtro de palavra-passe personalizado que passa a palavra-passe para o agente DC.
- O agente DC compara a palavra-passe proposta com a palavra-passe no SYSVOL e aprova-a ou rejeita-a.
- O êxito ou o fracasso é devolvido ao utilizador.
Processo de avaliação da palavra-passe
A palavra-passe proposta pelo utilizador é comparada com uma lista de cerca de 1000 palavras e padrões ("asdf", etc.). Além disso, são efectuadas substituições de caracteres na palavra-passe ($ por s, maiúsculas / minúsculas, etc.). Actualmente, é calculada uma pontuação para cada palavra-passe na seguinte mannerv:
Cada carácter vale um ponto, mas qualquer substring que corresponda a uma palavra/frase/padrão proibido vale apenas um ponto no total. A pontuação mínima permitida é de 5 pontos. Por exemplo, "Primavera" e "2018" são palavras proibidas, pelo que "Primavera2018" vale apenas 2 pontos e não é permitido.
"Spring2018asdfj236" decompõe-se da seguinte forma:
- Mola = 1 ponto
- 2018 = 1 ponto
- asdf = 1 ponto
- f, j, 2, 3, 6 = 1 ponto cada
Total = 8 pontos = APROVADO
Este processo permite algumas palavras ou frases proibidas se existirem outros caracteres aleatórios suficientes na palavra-passe. Note-se que também está sujeito a alterações, à medida que a Microsoft evolui a sua inteligência de ameaças à escala da nuvem em torno de ataques a palavras-passevi.
A política aplicar-se-á a todos os utilizadores na floresta - não existe uma porta traseira para os administradores - e aplica-se a todos os processos de alteração de palavras-passevii. A verificação normal de palavras-passe incorrectas com o emulador PDC não é afectada por esta nova capacidade.
Vantagens da concepção
Esta concepção híbrida tem muitas vantagens:
- O processo de pedido e actualização da BPL foi concebido para ter um impacto extremamente reduzido nas operações do DC. Numa rede bem conectada, apenas um DC por domínio e por hora solicitará a BPL.
- O processo de pedido e actualização funciona com uma vasta gama de topologias de rede. Os DCs não precisam de conectividade com a Internet; apenas o proxy precisa de acesso à Internet. E, se necessário, o proxy só precisa de se ligar a um único DC por domínio através de RPC (e a porta é configurável). A replicação do SYSVOL via DFSR garantirá que a política de senha chegue a todos os DCs do domínio.
- A verificação da palavra-passe passa pelos processos normais do Active Directory e quaisquer alterações à funcionalidade principal do AD são reduzidas ao mínimo. Nenhuma parte da operação sai do DC; por exemplo, uma tentativa de alteração de palavra-passe nunca é bloqueada se o DC tiver de sondar o Azure para obter uma nova BPL. O filtro de palavra-passe real é tão simples quanto possível.
- O software foi concebido de forma "aberta", ou seja, se algum componente não estiver instalado ou não estiver a funcionar (por exemplo, o agente DC está instalado, mas o proxy não está instalado), a palavra-passe será permitida, mas será registado um erro no registo de eventos do DC.
- Esta arquitectura aberta a falhas permite pré-instalar o agente DC num servidor que se pretenda promover a um DC.
- O agente DC executa o mesmo código de verificação de palavra-passe que o serviço Azure.
- Não precisa de o implementar em todos os seus DCs para o testar. De facto, essa é uma boa forma de o implementar de forma incremental.
Etapas de implantação
Os passos de implementação detalhados estão documentados aqui; como este serviço está em pré-visualização, espero que sejam actualizados regularmente. A um nível elevado, os passos são
- Determine em que computador(es) associado(s) ao domínio pretende instalar o serviço proxy e em que DCs pretende testar. O proxy não precisa de ir para o servidor Azure AD Connect ou para um DC; qualquer servidor membro (como um servidor que já aloja conectores Application Proxy) serve. Lembre-se de que não deve utilizar pré-visualizações públicas em servidores de produção, ou pelo menos contra utilizadores de produção; pode promover e isolar um DC no seu próprio site para o testar contra utilizadores específicos.
- Certifique-se de que o serviço de protecção por palavra-passe do Azure AD está configurado para o modo de auditoria (a predefinição) e, opcionalmente, adicione quaisquer palavras-passe personalizadas à BPL do inquilino.
- Obtenha os bits de pré-visualização para o serviço de proxy de política de palavra-passe e o agente DC a partir do centro de transferências.
- Instalar o serviço de proxy de política de palavra-passe.
- No servidor proxy,
a. Registe o serviço de proxy com o Azure AD.
b. Registe a floresta do Active Directory no local com o Azure AD. - Instalar o(s) agente(s) DC.
- Reiniciar os DCs.
Controlo
A partir deste momento, as informações sobre a actividade do serviço de Protecção por Palavra-passe do Azure AD têm de ser recolhidas a partir do servidor proxy e dos registos de eventos do DC. Não há integração com o Azure AD Connect Health neste momento na pré-visualização pública, nem há monitorização do agente proxy a partir do blade do Azure AD no portal proxy.
As IDs de eventos no intervalo 10000 são geradas pelo filtro de palavra-passe, enquanto as IDs no intervalo 30000 provêm do agente DC. Encontrará (ligeiramente) mais informações nas mensagens do agente DC (Figura 9):
O agente DC tem os seus próprios contadores de desempenho no Perfmon em Protecção por palavra-passe do Azure AD (Figura 10):
Também pode utilizar o cmdlet do PowerShell Get-AzureADPasswordProtectionSummaryReport para obter uma vista resumida da actividade de alteração de palavras-passe.
Licenciamento
Que tipo de licença do Azure AD é necessária para esta capacidade? A divisão é feita da seguinte formaviii:
- Contas apenas na nuvem: Protecção por palavra-passe do Azure AD com lista global de palavras-passe proibidas: Grátis
- Protecção por palavra-passe do Azure AD com lista personalizada: Azure AD básico
- Integração do Windows Server AD Protecção de palavras-passe do Azure AD com lista global de palavras-passe proibidas: Todos os utilizadores sincronizados têm de ter licenças Azure AD Premium P1
- Protecção por palavra-passe do Azure AD com lista personalizada (o que estou a descrever neste post): Todos os utilizadores sincronizados têm de ter o Azure AD Premium P1
Mais uma vez, como se trata de uma pré-visualização pública, está sujeita a alterações.
Informações diversas
- Não existe qualquer relação entre as partes locais da Protecção de Palavra-passe do Azure AD e o Azure AD Connect. Assim, não é necessário instalar o proxy em um ou mais servidores do Azure AD Connect (embora eles funcionem muito bem neles).
- Uma vez que não há alterações no lado do cliente, qualquer palavra-passe comum rejeitada apresentará o erro padrão "a palavra-passe não cumpre os requisitos de complexidade" no cliente.
- A pré-visualização pública requer que o Administrador Global no inquilino configure o componente Azure e instale o proxy no local e (claro) o Administrador do Domínio para instalar o software. Mas o MFA não é suportado inicialmente para o registo, pelo que terá de retirar o MFA da conta de Administrador Global que está a utilizar para instalar o proxy. Isto será resolvido antes do GAix.
- Se quiser testar algumas das suas próprias palavras-passe em relação ao que o NIST considera serem palavras-passe comuns, consulte o projecto NIST Bad Passwords no Github. Para além de fornecer um código de exemplo para criar o seu próprio verificador de palavras-passe proibidas do lado do cliente, pode testar as palavras-passe quanto à sua fragilidade.
A Microsoft está a avançar agressivamente para adoptar as suas recomendações e as do NIST para as políticas de palavras-passe. Ao proibir as alterações de palavras-passe comuns no Active Directory, o Azure AD Password Protection fecha uma grande área de risco empresarial causada por ataques de palavras-passe. Recomendo vivamente que avalie este serviço de modo a implementá-lo quando atingir a disponibilidade geral.
A proibição de palavras-passe comuns é apenas uma parte da sua solução de segurança de identidade, como é óbvio. O acesso condicional com controlo MFA às suas aplicações empresariais - tanto baseadas na nuvem como no local - é outra. À medida que as arquitecturas empresariais passam de um modelo de segurança baseado no perímetro para um modelo baseado na identidade, manter os recursos empresariais seguros requer uma abordagem ampla que inclua a segurança da identidade, dos dispositivos e dos dados.
Recursos
ihttps://twitter.com/Alex_A_Simons/status/1009490805369655296
iihttps://twitter.com/Alex_A_Simons/status/1009500870872973312
iiihttps://twitter.com/Alex_A_Simons/status/1009923402998562816
viihttps://techcommunity.microsoft.com/t5/Azure-Active-Directory-AMA/bd-p/AzureActiveDirectoryAMA
ixhttps://twitter.com/Alex_A_Simons/status/1009490805369655296
