Uma das tendências mais comuns relacionadas com a segurança que estou a observar nos clientes é o interesse em adicionar a autenticação multifactor (MFA) às suas soluções novas e existentes. Esta tendência é normalmente motivada por uma necessidade de aumentar a segurança geral ou de satisfazer requisitos regulamentares. Como um serviço híbrido, a MFA do Azure
A AMF e o mercado
A MFA é o factor "o que tem" adicionado ao factor de autenticação "o que sabe" (por exemplo, ID de utilizador / palavra-passe). Embora "o que você tem" tenha sido historicamente um token rígido, como um fob RSA SecureID, ou uma encarnação de software do mesmo, o que realmente impulsionou a popularidade da MFA nos últimos anos é o fato de que a maioria de nós agora tem um dispositivo que pode ser usado como um segundo fator: seu smartphone. Uma empresa chamada PhoneFactor desenvolveu uma solução MFA que reconheceu isso e, além disso, simplificou a implantação ao colocar a parte de telefonia (lidar com as notificações MFA por telefone, texto ou notificação push) em um serviço de nuvem para que os clientes não precisassem mexer com isso. A Microsoft comprou o PhoneFactor em 2012 para incorporar sua tecnologia no Azure, e o produto evoluído é conhecido como Autenticação Multifator do Azure.
Como já referi, as empresas já compreendem as vantagens do MFA. No mercado de consumo, no entanto, apesar de a autenticação multifator estar cada vez mais disponível para aplicações SaaS importantes (por exemplo, Google, Facebook, Twitter, Microsoft e LastPass), receio que a adopção ainda seja muito baixa. Como profissional de identidade, activei o MFA em tantos serviços quanto possível. Não me interpretem mal; odeio a dor extra de verificar o meu telemóvel para ver se há uma mensagem SMS ou um código de autenticação de uma aplicação, tanto quanto qualquer outra pessoa. Mas reconheço que isso pode - e já salvou - as minhas contas da pirataria informática, por isso, lido com isso. E se estiver a ler isto, recomendo vivamente que também active a MFA sempre que possível.
MFA para Office 365 vs. MFA do Azure vs. Servidor MFA
Digamos que está a avaliar o Azure MFA para determinar se este ajudará a segurança da sua empresa. Em primeiro lugar, compreenda que, se pretender todas as capacidades do Azure MFA, tem de adquirir uma subscrição do Azure AD Premium. Um subconjunto de capacidades de MFA está disponível 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ão a considerar uma ampla adopção da MFA precisa da subscrição Premium.(Esta tabela mostra a diferença entre o MFA para Office 365 e o Azure MFA.) Como sempre, existem considerações de licenciamento e preços na sua implementação; se estiver a comprar o Azure MFA autónomo, pode licenciá-lo por autenticação ou por utilizador.
Os recursos completos do Azure MFA incluem o servidor MFA local. (Sim, a marca é confusa.) O Servidor MFA e os seus componentes associados - Portal do Utilizador, Serviço Web de Aplicações Móveis e Adaptador AD FS - é a parte mais visível do produto PhoneFactor original. A interface do usuário (abaixo) é significativamente diferente dos produtos desenvolvidos pela Microsoft, e o modelo de administração também é incomum.
Consola de administração do servidor MFA
Quando é que os seus requisitos seriam satisfeitos apenas com o Azure MFA? Quando é que precisa de implementar o Servidor MFA? Vamos analisar os casos de utilização mais comuns para o Azure MFA e o Servidor MFA:
| 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 |
Pode ver a tendência: na maioria das vezes, precisa do Servidor MFA se quiser proteger os recursos no local. O outro conjunto de casos de utilização do Servidor MFA é quando a autenticação está a ocorrer no AD local porque tem o AD FS com uma confiança federada para o Azure AD. Nestes casos, os pedidos de autenticação apresentados ao Azure AD são redireccionados para o AD FS. E se o AD FS tiver o Adaptador AD FS do Servidor MFA instalado, utilizará o Servidor MFA para efectuar o pedido MFA. (Tenha em atenção que o Servidor MFA não suporta servidores de federação de terceiros; tem de utilizar o AD FS).
Há circunstâncias, como a segurança do acesso ao Office 365, em que pode utilizar apenas a MFA do Azure ou o Servidor MFA. A sua escolha depende de onde pretende a imposição de MFA no fluxo de autenticação. Por exemplo, se precisar de regras de autenticação adicionais para fornecer uma política de permissão / negação / MFA mais granular para os utilizadores do Office 365, deverá colocar a MFA com o AD FS porque o AD FS oferece esse nível adicional de controlo.
No futuro, estou convencido de que o serviço MFA híbrido da Microsoft continuará a fornecer um suporte sólido para proteger os recursos na nuvem e no local, e continuaremos a ver novas capacidades aparecerem. Mas duvido que a arquitectura seja igual à que temos hoje. A componente local tornar-se-á muito mais leve e acabará por ser mínima, limitando-se a transmitir os pedidos de MFA ao Azure MFA.
Não disponho de informações internas que me levem a esta previsão em particular. Mas a tendência clara da Microsoft para a arquitectura de identidade híbrida - Azure AD Application Proxy, Azure RMS e outros em preparação - não é aumentar a pegada local com servidores para permitir capacidades na nuvem. Os clientes disseram à Microsoft, em alto e bom som, que esta arquitectura é um passo atrás para dar um passo em frente. Em vez disso, colocar um conector leve ou grupos de conectores no centro de dados de uma empresa que sejam relativamente fáceis de instalar e que forneçam automaticamente capacidades de equilíbrio de carga e alta disponibilidade é muito mais palatável. Qualquer pessoa que trabalhe com o servidor MFA durante um período de tempo reconhece que é o serviço na nuvem que está a ser melhorado, enquanto o servidor no local está a ser mantido, mas não melhorado. De facto, algumas das suas capacidades estão a ser deslocadas: O AD FS no Windows Server 2016 tem um adaptador Azure MFA incorporado, eliminando a necessidade do Adaptador AD FS do Servidor MFA.
Procure a Autenticação Multifator do Azure para proteger os recursos no local e na nuvem na arquitetura de identidade híbrida da Microsoft. Mas, tal como acontece com qualquer arquitectura no panorama actual das tecnologias de informação em rápida evolução, não espere que tenha o mesmo aspecto daqui a alguns anos.
