Um dos maiores desafios da adoção de serviços em nuvem é estender as políticas de identidade do ambiente local para a nuvem. Num ambiente do Active Directory (AD), pode ser tentador recorrer aos Serviços de Federação do Active Directory (ADFS), que há muito são a resposta para fornecer capacidades de início de sessão único para permitir que os utilizadores se autentiquem e acedam a aplicações que, de outra forma, não estariam disponíveis para eles utilizando apenas o Active Directory, como o Azure e o Microsoft 365.
No entanto, como os agentes de ameaças continuam a visar ambientes de nuvem, é justo examinar se o ADFS é a melhor solução para organizações que adotam ambientes híbridos. Embora o ADFS não seja inerentemente inseguro, a complexidade de sua implementação adequada o deixa suscetível a invasores. Tal como foi demonstrado no ataque à cadeia de fornecimento da SolarWinds, uma vulnerabilidade no ambiente local pode, em última análise, levar ao comprometimento do inquilino do Azure AD. Para além de ser outro conjunto de servidores físicos para gerir, os servidores ADFS também expandem a superfície de ataque que as empresas necessitam de proteger.
Até mesmo a Microsoft recomendou que as organizações considerassem migrar para longe do ADFS, observando em uma postagem de blog de janeiro : "Se pretender alargar a MFA e o Acesso Condicional a aplicações locais antigas, incluindo aplicações baseadas em cabeçalhos, utilize o Proxy de Aplicação do Azure AD ou uma solução integrada de um dos nossos parceiros de acesso híbrido seguro. Com as nossas ferramentas de migração, pode modernizar a autenticação de todas as aplicações e retirar a sua implementação do ADFS. Isto ajudará a evitar ataques que são particularmente difíceis de detetar em sistemas de identidade no local."
Leitura relacionada
Um mundo sem ADFS
Para ajudar as organizações a ligarem todas as suas aplicações ao Azure AD, a Microsoft introduziu a PHS (Password Hash Synchronization) e a PTA (Pass-through Authentication). Usando a Sincronização de Hash de Senha, os administradores do Active Directory podem sincronizar um hash da senha do AD local de um usuário para o Azure AD. De facto, isto permite aos utilizadores tirar partido de serviços como o Microsoft 365 utilizando a mesma palavra-passe que utilizariam para a sua conta do AD local.
O segundo método de autenticação gerida para o Azure AD é a Autenticação Pass-through, que valida as palavras-passe dos utilizadores em relação ao Active Directory local da organização. Utiliza agentes de autenticação no ambiente local. Estes agentes ouvem os pedidos de validação de palavra-passe enviados pelo Azure AD e não necessitam que quaisquer portas de entrada sejam expostas à Internet para funcionarem. As palavras-passe não têm de estar presentes no Azure AD sob qualquer forma, eliminando um potencial vector de ataque. Além disso, podem ser aplicadas às contas políticas locais, como a expiração da conta ou restrições de horas de início de sessão. Como pré-requisito para que a Autenticação Pass-through funcione, os utilizadores têm de ser aprovisionados no Azure AD a partir do Active Directory local utilizando o Azure AD Connect.
Embora ainda existam casos de utilização em que possa fazer sentido manter uma implementação do ADFS - como a utilização do ADFS para autenticação de certificados de utilizador - para muitas organizações, o argumento para abandonar o ADFS é forte. Ao utilizar o PHS e o PTA, as organizações podem reduzir o número de palavras-passe que os utilizadores têm de memorizar. No entanto, esse é apenas um dos benefícios que podem advir da migração. A implantação do ADFS é complexa e requer hardware físico que precisa ser mantido. Se um servidor ADFS não for actualizado com os patches mais recentes, fica vulnerável a ataques. O PHS, por outro lado, é mantido pela Microsoft e a sua utilização reduz a infra-estrutura que as organizações necessitam de proteger.
Se estiver no início da sua jornada híbrida, o ADFS não deve ser a sua primeira opção para ligar a autenticação entre as cargas de trabalho no local e online. No entanto, se tiver implementado o ADFS, está a considerar uma migração, que continua a proporcionar uma segurança melhorada em relação ao ADFS.
No entanto, alterar os métodos de autenticação não é uma tarefa trivial e requer planeamento e testes significativos. Qualquer migração para fora do ADFS deve ocorrer em fases para permitir testes suficientes e potencial tempo de inactividade. No mínimo, as organizações devem estar a executar o Azure AD Connect 1.1.819.0 para executar com êxito os passos para migrar para a sincronização de hash de palavra-passe. O método para mudar para PHS depende de como o ADFS foi configurado originalmente. Se o ADFS foi configurado por meio do Azure AD Connect, então o assistente do Azure AD Connect deve ser usado. Nessa situação, o Azure AD Connect executa automaticamente o cmdlet Set-MsolDomainAuthentication e desfere automaticamente todos os domínios federados verificados no locatário do Azure AD.
Se uma organização não configurou originalmente o ADFS usando o Azure AD Connect, ela poderá usar o Azure AD Connect com o PowerShell para migrar para o PHS. No entanto, o administrador do AD ainda tem de alterar o método de início de sessão do utilizador através do assistente do Azure AD Connect. O assistente do AD Connect não executará automaticamente o cmdlet Set-MsolDomainAuthentication, deixando o administrador com controlo total sobre que domínios são convertidos e por que ordem.
Apoio a iniciativas de computação em nuvem
Para empresas com ambientes híbridos, ligar todas as aplicações ao Azure AD reduz a complexidade e oferece uma oportunidade para diminuir a superfície de ataque. Como benefício secundário, também tem o potencial de melhorar a experiência do utilizador através da implementação do início de sessão único, bem como de controlos de segurança de conta rigorosos. À medida que as organizações adoptam abordagens de identidade híbrida para suportar as suas iniciativas na nuvem, devem dedicar algum tempo a examinar se o ADFS se adequa melhor às suas necessidades.