Uma das tendências mais comuns relacionadas com a segurança que tenho observado junto dos clientes é o interesse em adicionar a autenticação multifator (MFA) tanto às suas soluções novas como às já existentes. Esta tendência é normalmente motivada pela necessidade de aumentar a segurança global ou de cumprir requisitos regulamentares. Como serviço híbrido, o Azure MFA
A AMF e o mercado
A autenticação multifator (MFA) consiste no fator «o que se possui», adicionado ao fator de autenticação «o que se sabe» (por exemplo, nome de utilizador/palavra-passe). Embora «o que se tem» tenha sido, historicamente, um token físico, como um dispositivo RSA SecureID, ou uma versão de software do mesmo, o que realmente impulsionou a popularidade da MFA nos últimos anos foi o facto de a maioria de nós ter agora um dispositivo que pode ser utilizado como segundo fator: o smartphone. Uma empresa chamada PhoneFactor desenvolveu uma solução de MFA que reconheceu esta realidade e, além disso, simplificou a implementação ao colocar a parte de telefonia (que gere as notificações de MFA por telefone, SMS ou notificação push) num serviço na nuvem, para que os clientes não tivessem de se preocupar com isso. A Microsoft adquiriu a PhoneFactor em 2012 para incorporar a sua tecnologia no Azure, e o produto resultante é conhecido como Autenticação Multifator do Azure.
Como já disse, as empresas já compreendem as vantagens da MFA. No mercado de consumo, no entanto, apesar de a MFA estar cada vez mais disponível para aplicações SaaS de destaque (por exemplo, Google, Facebook, Twitter, Microsoft e LastPass), receio que a sua adoção ainda seja muito baixa. Como profissional da área da identidade, ativei a MFA no maior número possível de serviços. Não me interpretem mal; detesto o incómodo adicional de ter de verificar o meu telemóvel à procura de uma mensagem SMS ou de um código de autenticação de uma aplicação, tal como qualquer outra pessoa. Mas reconheço que isso pode — e já — salvou as minhas contas de ataques de pirataria informática, por isso, aguento-o. E se estiveres a ler isto, recomendo vivamente que também atives a MFA sempre que possível.
MFA para Office 365 vs. MFA do Azure vs. Servidor MFA
Suponhamos que esteja a avaliar o Azure MFA para determinar se este irá contribuir para a segurança da sua empresa. Em primeiro lugar, é importante compreender que, se pretender todas as funcionalidades do Azure MFA, terá de adquirir uma subscrição do Azure AD Premium. Está disponível um subconjunto de funcionalidades de MFA sem o Azure AD Premium (por exemplo, MFA básico para utilizadores e administradores do Office 365, ou MFA para administradores do Azure AD), mas a maioria das empresas que está a considerar uma adoção alargada da MFA necessita da subscrição Premium. (Esta tabela mostra a diferença entre a MFA para o Office 365 e o Azure MFA.) Como sempre, há considerações relativas ao licenciamento e aos preços na sua implementação; se estiver a adquirir o Azure MFA de forma independente, pode licenciá-lo por autenticação ou por utilizador.
As funcionalidades completas do Azure MFA incluem o servidor MFA local. (Sim, a nomenclatura é confusa.) O servidor MFA e os seus componentes associados — Portal do Utilizador, Serviço Web da Aplicação Móvel e Adaptador AD FS — constituem a parte mais visível do produto PhoneFactor original. A interface de utilizador (abaixo) é significativamente diferente da dos produtos desenvolvidos pela Microsoft, e o modelo de administração também é invulgar.
Consola de administração do servidor MFA
Em que situações é que os seus requisitos seriam satisfeitos apenas com o Azure MFA? Em que situações é que seria necessário implementar o MFA Server? Vejamos os casos de utilização mais comuns tanto para o Azure MFA como para o MFA Server:
| Recurso protegido |
Azure MFA |
Servidor MFA |
| Azure AD AuthN |
|
|
| Azure AD AuthN (nativo) |
X |
|
| Office 365 |
X |
X (se AD FS) |
| Aplicações SaaS integradas no Azure AD (por aplicação) |
X |
|
| Aplicações no local publicadas no Azure AD através do Proxy de Aplicações do Azure |
X |
|
| AuthN no local |
|
|
| Azure AD AuthN (através de AD FS) |
X |
|
| Acesso VPN à corpnet |
X |
|
| Ambiente de trabalho remoto para a corpnet |
X |
|
| Aplicações IIS |
X |
|
| Início de sessão SaaS iniciado pelo SP através do AD FS |
X |
É possível perceber a tendência: na maioria das vezes, é necessário o MFA Server para proteger recursos locais. O outro conjunto de casos de utilização do MFA Server ocorre quando a autenticação é efetuada no AD local, porque se dispõe do AD FS com uma relação de confiança federada com o Azure AD. Nestes casos, os pedidos de autenticação apresentados ao Azure AD são redirecionados para o AD FS. E se o AD FS tiver instalado o adaptador AD FS do MFA Server, utilizará o MFA Server para executar o pedido de MFA. (Note que o MFA Server não suporta servidores de federação de terceiros; deve utilizar o AD FS.)
Existem circunstâncias, como a garantia do acesso ao Office 365, em que é possível utilizar apenas o Azure MFA ou o MFA Server. A escolha depende do ponto do fluxo de autenticação em que se pretende aplicar a MFA. Por exemplo, se forem necessárias regras de autenticação adicionais para definir uma política mais granular de autorização/recusa/MFA para os utilizadores do Office 365, convém implementar a MFA com o AD FS, uma vez que este oferece esse nível adicional de controlo.
No futuro, estou convencido de que o serviço híbrido de MFA da Microsoft continuará a oferecer um apoio sólido para proteger tanto os recursos na nuvem como os locais, e continuaremos a ver surgir novas funcionalidades. Mas duvido que a arquitetura venha a ser igual à que vemos hoje. O componente local tornar-se-á muito mais leve e, a longo prazo, será bastante reduzido, limitando-se a reencaminhar os pedidos de MFA para o Azure MFA.
Não disponho de informação privilegiada que me leve a esta previsão específica. Mas a tendência clara da Microsoft para uma arquitetura de identidade híbrida – o Azure AD Application Proxy, o Azure RMS e outros projetos em desenvolvimento – não visa aumentar a presença local com servidores para habilitar funcionalidades na nuvem. Os clientes têm dito à Microsoft, de forma clara e inequívoca, que esta arquitetura representa um passo atrás para dar um passo em frente. Em vez disso, é muito mais aceitável colocar um conector leve ou grupos de conectores no centro de dados de uma empresa, que sejam relativamente fáceis de instalar e forneçam automaticamente capacidades de equilíbrio de carga e alta disponibilidade. Qualquer pessoa que trabalhe com o MFA Server há algum tempo reconhece que é o serviço na nuvem que está a ser melhorado, enquanto o servidor local é mantido, mas não melhorado. De facto, algumas das suas funcionalidades estão a ser transferidas: o AD FS no Windows Server 2016 possui um adaptador Azure MFA integrado, eliminando a necessidade do adaptador MFA Server AD FS.
Recorra à Autenticação Multifator do Azure para proteger tanto os recursos locais como os recursos na nuvem na arquitetura de identidade híbrida da Microsoft. No entanto, tal como acontece com qualquer arquitetura no panorama atual das tecnologias da informação, em rápida evolução, não espere que ela se mantenha igual daqui a alguns anos.

