Una de las tendencias más habituales en materia de seguridad que observo entre los clientes es el interés por incorporar la autenticación multifactorial (MFA) tanto a sus soluciones nuevas como a las ya existentes. Esta tendencia suele estar motivada por la necesidad de aumentar la seguridad general o de cumplir con los requisitos normativos. Como servicio híbrido, Azure MFA
El AMF y el mercado
La autenticación multifactorial (MFA) es el factor «lo que tienes» que se suma al factor de autenticación «lo que sabes» (por ejemplo, nombre de usuario y contraseña). Aunque «lo que tienes» ha sido históricamente un token físico, como un dispositivo RSA SecureID, o una versión de software del mismo, lo que realmente ha impulsado la popularidad de la MFA en los últimos años es el hecho de que la mayoría de nosotros disponemos ahora de un dispositivo que puede utilizarse como segundo factor: el smartphone. Una empresa llamada PhoneFactor desarrolló una solución de MFA que tuvo en cuenta este hecho y, además, simplificó su implementación al trasladar la parte de telefonía (que gestiona las notificaciones de MFA por teléfono, SMS o notificaciones push) a un servicio en la nube, de modo que los clientes no tuvieran que preocuparse por ello. Microsoft adquirió PhoneFactor en 2012 para incorporar su tecnología a Azure, y el producto resultante se conoce como Autenticación multifactor de Azure.
Como ya he dicho, las empresas ya comprenden las ventajas de la autenticación multifactorial (MFA). Sin embargo, en el mercado de consumo, aunque la MFA está cada vez más disponible para aplicaciones SaaS destacadas (por ejemplo, Google, Facebook, Twitter, Microsoft y LastPass), me temo que su adopción sigue siendo muy baja. Como profesional especializado en identidad, he activado la MFA en tantos servicios como he podido. No me malinterpretes; odio tanto como cualquiera la molestia adicional de tener que mirar el móvil para ver si hay un SMS o un código de autenticación de una aplicación. Pero reconozco que puede salvar —y de hecho ha salvado— mis cuentas del hackeo, así que lo acepto. Y si estás leyendo esto, te recomiendo encarecidamente que también actives la MFA siempre que sea posible.
MFA para Office 365 vs. Azure MFA vs. Servidor MFA
Supongamos que estás evaluando Azure MFA para determinar si contribuirá a la seguridad de tu empresa. En primer lugar, debes tener en cuenta que, si deseas disponer de todas las funciones de Azure MFA, debes adquirir una suscripción a Azure AD Premium. Sin Azure AD Premium se dispone de un subconjunto de funciones de MFA (por ejemplo, la MFA básica para usuarios y administradores de Office 365, o la MFA para administradores de Azure AD), pero la mayoría de las empresas que se plantean una adopción generalizada de la MFA necesitan la suscripción Premium. (Esta tabla muestra la diferencia entre la autenticación multifactor para Office 365 y Azure MFA.) Como siempre, hay que tener en cuenta aspectos relacionados con las licencias y los precios a la hora de implementar la solución; si adquieres Azure MFA de forma independiente, puedes obtener la licencia por autenticación o por usuario.
Las funcionalidades completas de Azure MFA incluyen el servidor MFA local. (Sí, la denominación puede resultar confusa.) El servidor MFA y sus componentes asociados —el portal de usuario, el servicio web de la aplicación móvil y el adaptador AD FS— constituyen la parte más visible del producto original de PhoneFactor. La interfaz de usuario (a continuación) difiere considerablemente de la de los productos desarrollados por Microsoft, y el modelo de administración también es poco habitual.
Consola de administración del servidor MFA
¿En qué casos se cumplirían tus requisitos solo con Azure MFA? ¿Cuándo necesitarías implementar MFA Server? Veamos los casos de uso más habituales tanto de Azure MFA como de MFA Server:
| Recurso protegido |
Azure MFA |
Servidor MFA |
| Azure AD AuthN |
|
|
| Azure AD AuthN (nativo) |
X |
|
| Oficina 365 |
X |
X (si AD FS) |
| Aplicaciones SaaS integradas en Azure AD (por aplicación) |
X |
|
| Aplicaciones locales publicadas en Azure AD a través de Azure App Proxy |
X |
|
| Autenticación local |
|
|
| Azure AD AuthN (a través de AD FS) |
X |
|
| Acceso VPN a corpnet |
X |
|
| Escritorio remoto a corpnet |
X |
|
| Aplicaciones IIS |
X |
|
| Inicio de sesión SaaS iniciado por el SP a través de AD FS |
X |
Se puede observar la tendencia: en la mayoría de los casos, se necesita MFA Server si se quieren proteger recursos locales. El otro conjunto de casos de uso de MFA Server se da cuando la autenticación se realiza frente a tu AD local porque tienes AD FS con una relación de confianza federada con Azure AD. En estos casos, las solicitudes de autenticación enviadas a Azure AD se redirigen a AD FS. Y si AD FS tiene instalado el adaptador de AD FS de MFA Server, utilizará MFA Server para realizar la solicitud de autenticación multifactor. (Ten en cuenta que MFA Server no es compatible con servidores de federación de terceros; debes utilizar AD FS.)
Hay circunstancias, como la protección del acceso a Office 365, en las que se puede utilizar Azure MFA por sí solo o MFA Server. La elección depende de en qué punto del flujo de autenticación se quiera aplicar la autenticación multifactorial (MFA). Por ejemplo, si necesitas reglas de autenticación adicionales para establecer una política más detallada de «permitir/denegar/MFA» para los usuarios de Office 365, te interesará implementar la MFA con AD FS, ya que AD FS ofrece ese nivel adicional de control.
De cara al futuro, estoy convencido de que el servicio híbrido de autenticación multifactorial (MFA) de Microsoft seguirá ofreciendo un sólido respaldo para proteger tanto los recursos en la nube como los locales, y seguiremos viendo cómo surgen nuevas funcionalidades. Sin embargo, dudo que la arquitectura sea igual a la que conocemos hoy en día. El componente local se aligerará considerablemente y, con el tiempo, será muy básico, limitándose simplemente a retransmitir las solicitudes de MFA a Azure MFA.
No dispongo de información privilegiada que me lleve a esta predicción en concreto. Pero la clara tendencia de Microsoft hacia una arquitectura de identidad híbrida —Azure AD Application Proxy, Azure RMS y otras soluciones en desarrollo— no consiste en aumentar la presencia local con servidores para habilitar capacidades en la nube. Los clientes le han dicho a Microsoft, alto y claro, que esta arquitectura supone un paso atrás para dar un paso adelante. En cambio, resulta mucho más aceptable incorporar al centro de datos de una empresa un conector ligero —o un conjunto de conectores— que sea relativamente fácil de instalar y que proporcione automáticamente capacidades de equilibrio de carga y alta disponibilidad. Cualquiera que haya trabajado con MFA Server durante un tiempo reconoce que es el servicio en la nube el que se está mejorando, mientras que el servidor local se mantiene, pero no se mejora. De hecho, algunas de sus capacidades se están trasladando: AD FS en Windows Server 2016 cuenta con un adaptador de Azure MFA integrado, lo que elimina la necesidad del adaptador de AD FS de MFA Server.
Recurre a la autenticación multifactor de Azure para proteger tanto los recursos locales como los de la nube en la arquitectura de identidad híbrida de Microsoft. Pero, al igual que ocurre con cualquier arquitectura en el panorama actual de las tecnologías de la información, que evoluciona rápidamente, no esperes que siga siendo igual dentro de unos años.

