Cumplimiento de los requisitos de autenticación multifactor del memorándum 22-09
Obtenga información sobre el uso de Microsoft Entra ID como sistema de administración de identidades centralizado al implementar principios de Confianza cero. Véase, Oficina de Administración y Presupuesto (OMB) M 22-09 memorando para los jefes de departamentos y agencias ejecutivos.
Los requisitos de memorando son que los empleados usen identidades administradas por la empresa para acceder a las aplicaciones y que la autenticación multifactor proteja a los empleados frente a ataques en línea sofisticados, como la suplantación de identidad (phishing). Este método de ataque intenta obtener y poner en peligro las credenciales, con vínculos a sitios de autenticación.
La autenticación multifactor impide el acceso no autorizado a cuentas y datos. Los requisitos de memorando citan la autenticación multifactor con métodos resistentes a la suplantación de identidad: procesos de autenticación diseñados para detectar y evitar la divulgación de secretos de autenticación, y las salidas a sitios web o aplicaciones enmascarados como sistemas legítimos. Por lo tanto, se establece qué métodos de autenticación multifactor se consideran como resistentes a la suplantación de identidad (phishing).
Métodos resistentes a la suplantación de identidad (phishing)
Algunas agencias federales han implementado credenciales modernas, como claves de seguridad FIDO2 o Windows Hello para empresas. Muchas están evaluando la autenticación de Microsoft Entra con certificados.
Más información:
- Llaves de seguridad FIDO2
- Windows Hello para empresas
- Introducción a la autenticación basada en certificados de Microsoft Entra
Algunas agencias están modernizando sus credenciales de autenticación. Hay varias opciones para cumplir los requisitos de una autenticación multifactor resistente a la suplantación de identidad con Microsoft Entra ID. Microsoft recomienda adoptar el método de autenticación multifactor resistente a la suplantación de identidad (phishing) que coincida con las funcionalidades de la agencia. Tenga en cuenta qué se puede hacer actualmente para la autenticación multifactor de resistencia a la suplantación de identidad (phishing) para mejorar la posición de ciberseguridad general. Implemente credenciales modernas. Sin embargo, si un enfoque moderno no es el camino más rápido, dé un primer paso hacia los enfoques modernos.
Enfoques modernos
- Las claves de seguridad FIDO2 son, según la Agencia de Seguridad de Infraestructura Ciberseguridad (CISA), el estándar más alto de la autenticación multifactor
- Consulte Opciones de autenticación sin contraseña de Microsoft Entra, claves de seguridad FIDO2
- Vaya a cisa.gov para leer el artículo "More than a Password" (Más de una contraseña)
- Autenticación de certificados de Microsoft Entra sin dependencia en un proveedor de identidades federado.
- Esta solución incluye implementaciones de tarjetas inteligentes: tarjeta de acceso común (CAC), verificación de identidad personal (PIV), así como las credenciales de PIV derivadas para dispositivos móviles o claves de seguridad
- Consulte Introducción a la autenticación basada en certificados de Microsoft Entra
- Windows Hello para empresas tiene autenticación multifactor resistente a la suplantación de identidad (phishing)
Protección contra suplantación de identidad externa
Las directivas de acceso condicional y Microsoft Authenticator imponen el uso de dispositivos administrados: dispositivos unidos a Microsoft Entra híbrido o dispositivos marcados como compatibles. Instale Microsoft Authenticator en dispositivos que acceden a aplicaciones protegidas por Microsoft Entra ID.
Obtener más información: Métodos de autenticación en Microsoft Entra ID: aplicación Microsoft Authenticator
Importante
Para cumplir el requisito de resistencia a la suplantación de identidad (phishing): administre solo los dispositivos que acceden a la aplicación protegida. Los usuarios con permiso para usar Microsoft Authenticator están en el ámbito de la directiva de acceso condicional que requiere dispositivos administrados para el acceso. Una directiva de acceso condicional bloquea el acceso a la aplicación en la nube de inscripción de Microsoft Intune. Los usuarios que puedan usar Microsoft Authenticator deben estar en el ámbito de esta directiva de acceso condicional. Use los mismos grupos para permitir la autenticación de Microsoft Authenticator en directivas de acceso condicional para asegurarse de que los usuarios habilitados para el método de autenticación estén en el ámbito de ambas directivas. Esta directiva de acceso condicional protege el vector más importante en las amenazas de suplantación de identidad de actores externos malintencionados. También impide que un actor malintencionado haga phishing en Microsoft Authenticator para guardar una credencial o unir un dispositivo e inscribirlo en Intune, con el objetivo de marcarlo como compatible.
Más información:
- Planear la implementación de la unión a Microsoft Entra híbrido, o
- Cómo planear la implementación de la combinación de Microsoft Entra
- Ver también Directiva de acceso condicional común: requerir un dispositivo compatible, un dispositivo unido a Microsoft Entra híbrido o autenticación multifactor para todos los usuarios
Nota:
Microsoft Authenticator no es resistente a la suplantación de identidad (phishing). Configure la directiva de acceso condicional para requerir que los dispositivos administrados obtengan protección frente a amenazas de suplantación de identidad externa.
Heredado
Proveedor de identidades federado (IdP), como Servicios de federación de Active Directory (AD FS) (AD FS) configurados con métodos resistentes a suplantación de identidad. Aunque las agencias logran resistencia a la suplantación de identidad con el proveedor de identidades federado, esto supone un coste, complejidad y riesgo añadidos. Microsoft fomenta las ventajas de seguridad de Microsoft Entra ID, un proveedor de identidades, para eliminar el riesgo asociado de un proveedor de identidades federado
Más información:
- Protección de Microsoft 365 contra ataques locales
- Implementación de servicios de federación de AD en Azure
- Configurar AD FS para la autenticación de certificado de usuario
Consideraciones sobre métodos resistentes a la suplantación de identidad
Las funcionalidades actuales del dispositivo, los roles de usuario y otros requisitos pueden obligar a usar métodos multifactor. Por ejemplo, las claves de seguridad FIDO2 con compatibilidad con USB-C requieren dispositivos con puertos USB-C. Tenga en cuenta la siguiente información al evaluar la autenticación multifactor resistente a la suplantación de identidad (phishing):
- Tipos de dispositivos y funcionalidades que puede admitir: quioscos, portátiles, teléfonos móviles, lectores biométricos, USB, Bluetooth y dispositivos de comunicación en proximidad
- Roles de usuario de organización: trabajadores de primera línea, trabajadores remotos con y sin hardware propiedad de la empresa, administradores con estaciones de trabajo de acceso con privilegios y usuarios invitados de negocio a negocio
- Logística: distribución, configuración y registro de métodos de autenticación multifactor, como claves de seguridad FIDO 2, tarjetas inteligentes, equipos gubernamentales o dispositivos Windows con chips TPM
- Validación de estándares federales de procesamiento de información (FIPS) 140 en un nivel de garantía de autenticador: algunas claves de seguridad FIDO son FIPS 140 validadas en niveles para AAL3 establecido por NIST SP 800-63B
Consideraciones de implementación para la autenticación multifactor resistente a la suplantación de identidad
Vea las secciones siguientes donde se describe la compatibilidad con la implementación de métodos resistentes a la suplantación de identidad (phishing) para inicios de sesión de aplicaciones y dispositivos virtuales.
Escenarios de inicio de sesión de aplicaciones de varios clientes
En la tabla siguiente se detalla la disponibilidad de escenarios de la autenticación multifactor resistentes a la suplantación de identidad (phishing) en función del tipo de dispositivo que se usa para iniciar sesión en las aplicaciones:
Dispositivo | AD FS como un proveedor de identidades federado con autenticación de certificados | Autenticación de certificados de Microsoft Entra | Llaves de seguridad FIDO2 | Windows Hello para empresas | Microsoft Authenticator con directivas de acceso condicional que aplican dispositivos híbridos de Microsoft Entra unidos o compatibles |
---|---|---|---|---|---|
Dispositivo Windows | |||||
Dispositivo móvil iOS | No aplicable | No aplicable | |||
Dispositivo móvil Android | No aplicable | No aplicable | |||
Dispositivo de MacOS | Edge, Chrome | No aplicable |
Para más información, consulte Compatibilidad del explorador con la autenticación sin contraseña de FIDO2
Escenarios de inicio de sesión de dispositivos virtuales que requieren integración
Para aplicar la autenticación multifactor resistente a la suplantación de identidad (phishing), es posible que sea necesario realizar una integración. Exija la autenticación multifactor para los usuarios que acceden a aplicaciones y dispositivos. Para los cinco tipos de autenticación multifactor resistentes a la suplantación de identidad (phishing), use las mismas características para acceder a los tipos de dispositivo siguientes:
Sistema de destino | Acciones de integración |
---|---|
Máquina virtual Linux de Azure | Habilitación de la máquina virtual Linux para el inicio de sesión de Microsoft Entra |
Azure Windows VM | Habilitación de la máquina virtual Windows para el inicio de sesión de Microsoft Entra |
Azure Virtual Desktop | Habilitar el Azure Virtual Desktop para la información de inicio de sesión de Microsoft Entra |
Máquinas virtuales hospedadas locales o en otras nubes | Habilite Azure Arc en la máquina virtual y, a continuación, habilite la información de inicio de sesión de Microsoft Entra. Actualmente en versión preliminar privada para Linux. La compatibilidad con las máquinas virtuales de Windows hospedadas en estos entornos está en nuestra hoja de ruta. |
Soluciones de escritorio virtual que no son de Microsoft | Integración de una solución de escritorio virtual de terceros como una aplicación en Microsoft Entra ID |
Aplicación de la autenticación multifactor resistente a la suplantación de identidad (phishing)
Use el acceso condicional para aplicar la autenticación multifactor para los usuarios del inquilino. Con la adición de directivas de acceso entre inquilinos, puede aplicarla a usuarios externos.
Obtenga más información: Información general: Acceso entre inquilinos con Microsoft Entra External ID
Aplicación entre agencias
Use la colaboración de Microsoft Entra B2B para cumplir los requisitos que facilitan la integración:
- Limitar a qué otros inquilinos de Microsoft pueden acceder los usuarios
- Permitir el acceso a los usuarios que no tiene que administrar en su inquilino, pero aplique la autenticación multifactor y otros requisitos de acceso
Más información: Introducción a la colaboración B2B
Aplique la autenticación multifactor para asociados y usuarios externos que acceden a los recursos de la organización. Esto es habitual en escenarios de colaboración entre agencias. Configure con las directivas de acceso entre inquilinos de Microsoft Entra la autenticación multifactor para los usuarios externos que acceden a aplicaciones y recursos.
Configure las opciones de confianza en las directivas de acceso entre inquilinos para confiar en el método de autenticación multifactor que usa el inquilino de usuario invitado. Evite que los usuarios registren un método de autenticación multifactor con el inquilino. Habilite estas directivas por organización. Puede determinar los métodos de autenticación multifactor en el inquilino principal del usuario y decidir si cumplen los requisitos de resistencia a la suplantación de identidad (phishing).
Directivas de contraseña
El memorando requiere que las organizaciones cambien las directivas de contraseñas no efectivas, como contraseñas complejas que se rotan con frecuencia. Dentro de esto, se incluye la eliminación del requisito de caracteres y números especiales, así como directivas de rotación de contraseñas basadas en el tiempo. En vez de ello, puede considerar las opciones siguientes:
- La protección de contraseñas para aplicar una lista común de contraseñas débiles que Microsoft mantiene
- Además, incluya contraseñas prohibidas personalizadas
- Consulte Eliminación de contraseñas incorrectas mediante la protección de contraseñas de Microsoft Entra
- Autoservicio de restablecimiento de contraseña para permitir que los usuarios restablezcan las contraseñas, por ejemplo, después de la recuperación de una cuenta
- Microsoft Entra ID Protection para alertas sobre credenciales en peligro
- ¿Qué es el riesgo?
Aunque el memorando no es específico sobre qué directivas usar con contraseñas, considere el estándar de NIST 800-63B.
Vea la publicación especial 800-63B de NIST, Directrices de identidad digital.
Pasos siguientes
- Cumplimiento de los requisitos de identidad del memorándum 22-09 con Microsoft Entra ID
- Enterprise de administración de identidades de todo el sistema
- Cumplimiento de los requisitos de autorización del Memorándum 22-09
- Otras áreas de Confianza cero abordadas en el Memorándum 22-09
- Protección de la identidad con Confianza cero