Planificación de una implementación de autenticación sin contraseña y resistente a la suplantación de identidad en Microsoft Entra ID
Al implementar y poner en marcha la autenticación sin contraseña y resistente a la suplantación de identidad (phishing) en su entorno, se recomienda un enfoque basado en roles de usuario. Hay métodos sin contraseña resistentes a la suplantación de identidad (phishing) que son más eficaces que otros para determinados usuarios. Esta guía de implementación le ayuda a ver qué tipos de métodos y planes de implementación tienen sentido para los distintos roles de usuario de su entorno. El enfoque de implementación sin contraseña resistente a la suplantación de identidad (phishing) suele tener 6 pasos, que fluyen aproximadamente en orden, pero no tienen que completarse el 100 % antes de pasar a otros pasos:
Determinación de los roles de usuario
Determine los roles de usuario pertinentes para su organización. Este paso es fundamental para el proyecto porque diferentes roles tienen necesidades diferentes. Microsoft recomienda tener en cuenta y evaluar al menos 4 roles de usuario genéricos en su organización.
| Rol de usuario | Descripción |
|---|---|
| Trabajadores de la información | |
| Personal de primera línea | |
| Profesionales de TI/trabajadores de DevOps | |
| Trabajadores altamente regulados |
Microsoft recomienda implementar ampliamente la autenticación sin contraseña resistente a la suplantación de identidad (phishing) en toda la organización. Tradicionalmente, los trabajadores de la información son los roles de usuario con los que es más fácil empezar. No retrase el lanzamiento de credenciales seguras para los trabajadores de la información mientras resuelve problemas que afectan a los profesionales de TI. Tome el enfoque de "no dejar que lo perfecto sea enemigo de lo bueno" e implemente credenciales seguras tanto como sea posible. A medida que más usuarios inician sesión con credenciales sin contraseña resistentes a la suplantación de identidad(phishing), se reduce la superficie expuesta a ataques de su entorno.
Microsoft recomienda definir sus roles y, a continuación, colocar cada rol en un grupo de identificadores de Microsoft Entra específicamente para ese rol de usuario. Estos grupos se usan en pasos posteriores para implementar credenciales para distintos tipos de usuarios y cuando empiece a aplicar el uso de credenciales sin contraseña resistentes a la suplantación de identidad (phishing).
Planificación de la preparación de los dispositivos
Los dispositivos son un aspecto esencial de cualquier implementación correcta de la autenticación sin contraseña y resistente a la suplantación de identidad, ya que uno de los objetivos de las credenciales sin contraseña resistentes a la suplantación de identidad es proteger las credenciales con el hardware de los dispositivos modernos. En primer lugar, familiarícese con la compatibilidad de FIDO2 con Microsoft Entra ID.
Asegúrese de que los dispositivos están preparados para la protección sin contraseña resistente a la suplantación de identidad mediante la aplicación de revisiones a las versiones compatibles más recientes de cada sistema operativo. Microsoft recomienda que los dispositivos ejecuten como mínimo estas versiones:
- Windows 10 22H2 (Windows Hello para empresas)
- Windows 11 22H2 (para obtener la mejor experiencia del usuario al usar claves de paso)
- macOS 13 Ventura
- iOS 17
- Android 14
Estas versiones proporcionan la mejor compatibilidad con características integradas de forma nativa, como claves de paso, Windows Hello para empresas y credenciales de plataforma macOS. Los sistemas operativos más antiguos pueden requerir autenticadores externos, como las claves de seguridad FIDO2, para admitir la autenticación sin contraseña resistente a la suplantación de identidad (phishing).
Registro de usuarios para credenciales resistentes a la suplantación de identidad (phishing)
El registro y el arranque de credenciales son las primeras actividades principales orientadas al usuario final en el proyecto de implementación de la autenticación sin contraseña resistente a la suplantación de identidad. En esta sección se describe el lanzamiento de credenciales portátiles y locales.
| Credenciales | Descripción | Ventajas |
|---|---|---|
| Portátiles | Se pueden usar en diferentes dispositivos. Puede usar credenciales portátiles para iniciar sesión en otro dispositivo o para registrar credenciales en otros dispositivos. | Es el tipo de credencial más importante para registrarse para la mayoría de los usuarios, ya que se pueden usar en todos los dispositivos y proporcionar autenticación resistente a la suplantación de identidad en muchos escenarios. |
| Locales | Puede usar credenciales locales para autenticarse en un dispositivo sin necesidad de confiar en hardware externo, como usar el reconocimiento biométrico de Windows Hello para empresas para iniciar sesión en una aplicación del navegador Microsoft Edge en el mismo equipo. | Tienen dos ventajas principales sobre las credenciales portátiles: |
- Para usuarios nuevos, el proceso de registro y arranque lleva a un usuario sin credenciales de empresa existentes y comprueba su identidad. Los inicia en sus primeras credenciales portátiles y usa esas credenciales portátiles para iniciar otras credenciales locales en cada uno de sus dispositivos informáticos. Después del registro, el administrador puede aplicar la autenticación resistente a la suplantación de identidad (phishing) para los usuarios de Microsoft Entra ID.
- En el caso de usuarios existentes, esta fase permite a los usuarios registrarse para obtener contraseñas resistentes a la suplantación de identidad sin contraseña directamente en sus dispositivos existentes o mediante credenciales de MFA existentes para crear credenciales sin contraseña resistentes a la suplantación de identidad. El objetivo final es el mismo que para los usuarios nuevos: la mayoría de los usuarios deben tener al menos unas credenciales portátiles y, a continuación, las credenciales locales en cada dispositivo informático. Si es un administrador que implementa una autentación sin contraseña resistente a la suplantación de identidad para usuarios existentes, es posible que pueda ir directamente a la sección Paso 2 de incorporación: Arranque de credenciales portátiles.
Antes de empezar, Microsoft recomienda habilitar la clave de acceso y otras credenciales para los usuarios empresariales en el inquilino. Si los usuarios están motivados para registrarse automáticamente para obtener credenciales seguras, es beneficioso permitirlo. Como mínimo, debe habilitar la directiva Passkey (FIDO2) para que los usuarios puedan registrarse para las claves de acceso y las claves de seguridad si lo prefieren.
Esta sección se centra en las fases 1 a 3:
Los usuarios deben tener al menos dos métodos de autenticación registrados. Con otro método registrado, el usuario tiene un método de respaldo disponible si sucede algo con su método principal, como cuando se pierde o se roba un dispositivo. Por ejemplo, es recomendable que los usuarios tengan claves de acceso registradas tanto en su teléfono como localmente en su estación de trabajo en Windows Hello para empresas.
Nota:
Siempre se recomienda que los usuarios tengan al menos dos métodos de autenticación registrados. Esto garantiza que el usuario tenga un método de respaldo disponible si algo sucede con su método principal, como en casos de pérdida o robo de dispositivos. Por ejemplo, es recomendable que los usuarios tengan claves de acceso registradas tanto en su teléfono como localmente en su estación de trabajo en Windows Hello para empresas.
Nota:
Esta guía está adaptada para la compatibilidad existente actualmente con las claves de acceso en Microsoft Entra ID, que incluye claves de acceso enlazadas al dispositivo en Microsoft Authenticator y claves de acceso enlazadas al dispositivo en claves de seguridad físicas. Microsoft Entra ID planea agregar compatibilidad con las claves de acceso sincronizadas. Para obtener más información, consulte Versión preliminar pública: expansión de la compatibilidad con claves de acceso en Microsoft Entra ID. Esta guía se actualizará para incluir una guía de clave de acceso sincronizada una vez disponible. Por ejemplo, muchas organizaciones pueden beneficiarse de confiar en la sincronización de la fase 3 del diagrama anterior en lugar de arrancar credenciales completamente nuevas.
Paso 1 de incorporación: Verificación de identidad
Para los usuarios remotos que no han demostrado su identidad, la incorporación empresarial es un desafío importante. Sin una comprobación de identidad adecuada, una organización no puede estar completamente segura de que está incorporando a la persona que pretende. Id. verificada por Microsoft Entra puede proporcionar una comprobación de identidad de alta seguridad. Las organizaciones pueden trabajar con un asociado de comprobación de identidad (IDV) para comprobar las identidades de los nuevos usuarios remotos en el proceso de incorporación. Después de procesar el identificador emitido por el gobierno de un usuario, el IDV puede proporcionar una Id. verificada que confirme la identidad del usuario. El nuevo usuario presenta esta Id. verificada de confirmación de identidad a la organización contratante para establecer la confianza y confirmar que la organización está incorporando a la persona adecuada. Las organizaciones pueden agregar Comprobación facial con Id. verificada por Microsoft Entra, que agrega una capa de coincidencia facial a la comprobación, lo que garantiza que el usuario de confianza está presentando la Id. verificada que confirma la identidad en ese momento.
Tras verificar su identidad mediante el proceso de comprobación, los recién contratados reciben un pase de acceso temporal (TAP) que pueden utilizar para obtener su primera credencial portátil.
Consulte las siguientes guías para habilitar la incorporación de la Id. verificada por Microsoft Entra y la emisión de TAP:
- Incorporación de nuevos empleados remotos mediante la comprobación de identificadores
- Uso de Face Check con Id. verificada por Microsoft Entra para desbloquear comprobaciones con alta garantía a gran escala
- Habilitación de la directiva del pase de acceso temporal
Consulte los vínculos siguientes para obtener detalles de licencia para la Id. verificada por Microsoft Entra:
- Precios de Face Check con el identificador comprobado de Microsoft Entra
- Planes y precios de Microsoft Entra
Algunas organizaciones pueden elegir otros métodos que Id. verificada por Microsoft Entra para incorporar usuarios y emitirles sus primeras credenciales. Microsoft recomienda que esas organizaciones sigan usando TAP u otra manera de permitir que un usuario se incorpore sin contraseña. Por ejemplo, puede aprovisionar claves de seguridad FIDO2 mediante Microsoft Graph API.
Paso 2 de incorporación: Arranque de unas credenciales portátiles
Para iniciar a usuarios existentes en las credenciales sin contraseña resistentes a la suplantación de identidad (phishing), primero determine si los usuarios están registrados para MFA tradicional. Los usuarios con métodos de MFA tradicionales registrados pueden dirigirse a directivas de registro sin contraseña resistentes a la suplantación de identidad (phishing). Pueden usar su MFA tradicional para registrarse para sus primeras credenciales portátiles resistentes a la suplantación de identidad y, a continuación, pasar a registrarse para las credenciales locales según sea necesario.
Para los nuevos usuarios o usuarios sin MFA, siga un proceso para emitir a los usuarios un pase de acceso temporal (TAP). Puede emitir un TAP de la misma manera que proporciona a los nuevos usuarios sus primeras credenciales o mediante integraciones de Id. verificada por Microsoft Entra. Una vez que los usuarios tengan un TAP, están listos para arrancar sus primeras credenciales resistentes a la suplantación de identidad (phishing).
Es importante que las primeras credenciales sin contraseña del usuario sean credenciales portátiles que se puedan usar para autenticarse en otros dispositivos informáticos. Por ejemplo, las claves de acceso se pueden usar para autenticarse localmente en un teléfono iOS, pero también se pueden usar para autenticarse en un equipo Windows mediante un flujo de autenticación entre dispositivos. Esta funcionalidad entre dispositivos permite que esa clave de acceso portátil se use para arrancar Windows Hello para empresas en el equipo Windows.
También es importante que cada dispositivo en el que el usuario funcione regularmente tiene una credencial disponible localmente para proporcionar al usuario la experiencia de usuario más fluida posible. Las credenciales disponibles localmente reducen el tiempo necesario para autenticarse porque los usuarios no necesitan usar varios dispositivos y hay menos pasos. El uso de TAP del paso 1 para registrar una credencial portátil que puede arrancar estas otras credenciales permite al usuario usar credenciales resistentes a la suplantación de identidad de forma nativa en los muchos dispositivos que pueden poseer.
En la tabla siguiente se enumeran las recomendaciones para diferentes personas:
| Rol de usuario | Credencial portátil recomendada | Credenciales portátiles alternativas |
|---|---|---|
| Trabajador de la información | Clave de paso (aplicación Authenticator) | Tarjeta inteligente, clave de seguridad |
| Trabajador de primera línea | Clave de seguridad | Clave de paso (aplicación Authenticator), tarjeta inteligente |
| Profesional de TI/trabajador de DevOps | Clave de paso (aplicación Authenticator) | Tarjeta inteligente, clave de seguridad |
| Trabajador altamente regulado | Certificado (tarjeta inteligente) | Clave de acceso (aplicación Authenticator), clave de seguridad |
Use las instrucciones siguientes para habilitar las credenciales portátiles recomendadas y alternativas para los roles de usuario pertinentes para su organización:
| Método | Guía |
|---|---|
| Claves de paso | |
| Claves de seguridad | |
| Tarjeta inteligente y autenticación basada en certificados (CBA) |
Paso 3 de incorporación: Arranque de credenciales locales en dispositivos informáticos
Después de que los usuarios hayan registrado una credencial portátil, están listos para arrancar otras credenciales en cada dispositivo informático que usan regularmente en una relación 1:1, lo que beneficia su experiencia de usuario diaria. Este tipo de credenciales es común para trabajadores de la información y profesionales de TI, pero no para los trabajadores de primera línea que comparten dispositivos. Los usuarios que solo comparten dispositivos solo deben usar credenciales portátiles.
Su organización debe determinar qué tipo de credencial se prefiere para cada persona de usuario en esta fase. Microsoft recomienda:
| Rol de usuario | Credencial local recomendada: Windows | Credencial local recomendada: macOS | Credencial local recomendada: iOS | Credencial local recomendada: Android | Credencial local recomendada: Linux |
|---|---|---|---|---|---|
| Trabajador de la información | Windows Hello para empresas | Clave de enclave seguro de inicio de sesión único (SSO) de plataforma | Clave de paso (aplicación Authenticator) | Clave de paso (aplicación Authenticator) | N/A (use credenciales portátiles en su lugar) |
| Trabajador de primera línea | N/A (use credenciales portátiles en su lugar) | N/A (use credenciales portátiles en su lugar) | N/A (use credenciales portátiles en su lugar) | N/A (use credenciales portátiles en su lugar) | N/A (use credenciales portátiles en su lugar) |
| Profesional de TI/trabajador de DevOps | Windows Hello para empresas | Clave de enclave seguro del inicio de sesión único de la plataforma | Clave de paso (aplicación Authenticator) | Clave de paso (aplicación Authenticator) | N/A (use credenciales portátiles en su lugar) |
| Trabajador altamente regulado | Windows Hello para empresas o CBA | Clave de enclave seguro del inicio de sesión único de la plataforma o CBA | Clave de paso (aplicación Authenticator) o CBA | Clave de paso (aplicación Authenticator) o CBA | N/A (use tarjeta inteligente en su lugar) |
Use las instrucciones siguientes para habilitar las credenciales locales recomendadas en su entorno para los roles de usuario pertinentes para su organización:
| Método | Guía |
|---|---|
| Windows Hello para empresas | |
| Clave de enclave seguro del inicio de sesión único de la plataforma | |
| Claves de paso |
Consideraciones específicas del rol
Cada rol tiene sus propios desafíos y consideraciones que suelen surgir durante las implementaciones de autenticación sin contraseña y resistente a la suplantación de identidad (phishing). A medida que identifique qué roles necesita adaptar, debe tener en cuenta estas consideraciones en la planificación del proyecto de implementación. Los vínculos siguientes tienen instrucciones específicas para cada rol:
- Trabajadores de la información
- Personal de primera línea
- Profesionales de TI/trabajadores de DevOps
- Trabajadores altamente regulados
Impulsar el uso de credenciales resistentes a la suplantación de identidad (phishing)
En este paso se explica cómo facilitar a los usuarios la adopción de credenciales resistentes a la suplantación de identidad (phishing). Debe probar la estrategia de implementación, planear el lanzamiento y comunicar el plan a los usuarios finales. Puede crear informes y supervisar el progreso antes de aplicar credenciales resistentes a la suplantación de identidad en toda la organización.
Estrategia de implementación de prueba
Microsoft recomienda probar la estrategia de implementación creada en el paso anterior con un conjunto de usuarios piloto y de prueba. Esta fase debe incluir los siguientes pasos:
- Cree una lista de usuarios de prueba y usuarios pioneros. Estos usuarios deben representar los distintos roles de usuario y no solo los administradores de TI.
- Cree un grupo de Microsoft Entra ID y agregue los usuarios de prueba al grupo.
- Habilite las directivas de métodos de autenticación en Microsoft Entra ID y de cree un ámbito del grupo de pruebas para los métodos que habilite.
- Mida el lanzamiento de registro para los usuarios piloto mediante el informe Actividad de ñps métodos de autenticación.
- Cree directivas de acceso condicional para aplicar las credenciales sin contraseña resistentes a la suplantación de identidad (phishing) en cada tipo de sistema operativo y configure como destino el grupo piloto.
- Mida el éxito de la aplicación mediante Azure Monitor y Workbooks.
- Recopile comentarios de los usuarios sobre el éxito del lanzamiento.
Planificación de la estrategia de implementación
Microsoft recomienda impulsar el uso en función de los roles de usuario más listos para la implementación. Normalmente, esto significa implementar para los usuarios en este orden, pero esto puede cambiar en función de la organización:
- Trabajadores de la información
- Personal de primera línea
- Profesionales de TI/trabajadores de DevOps
- Trabajadores altamente regulados
Use las secciones siguientes para crear comunicaciones de usuario final para cada grupo de roles, ámbito e implementación de la característica de registro de claves de acceso, así como informes de usuarios y supervisión para realizar un seguimiento del progreso del lanzamiento.
Planificación de las comunicaciones con el usuario final
Microsoft proporciona plantillas de comunicación para los usuarios finales. El material de lanzamiento de la autenticación incluye pósteres personalizables y plantillas de correo electrónico para informar a los usuarios sobre la implementación de autenticación sin contraseña resistente a la suplantación de identidad. Use las siguientes plantillas para comunicarse a los usuarios para que comprendan la implementación sin contraseña resistente a la suplantación de identidad (phishing):
- Inicio de sesión sin contraseña con Microsoft Authenticator
- Registro del método de comprobación de restablecimiento de contraseña para una cuenta profesional o educativa
- Restablecimiento de la contraseña profesional o educativa con la información de seguridad
- Configuración de una clave de seguridad como su método de comprobación
- Inicio de sesión en sus cuentas mediante la aplicación Microsoft Authenticator
- Inicio de sesión en su cuenta profesional o educativa mediante el método de verificación en dos pasos
- Inicio de sesión de cuenta profesional o educativa bloqueado por restricciones de inquilino
Las comunicaciones deben repetirse varias veces para ayudar a detectar tantos usuarios como sea posible. Por ejemplo, su organización puede optar por comunicar las distintas fases y escalas de tiempo con un patrón similar al siguiente:
- 60 días fuera del cumplimiento: indique el valor de los métodos de autenticación resistentes a la suplantación de identidad (phishing) y anime a los usuarios a inscribirse de forma proactiva.
- 45 días de espera del cumplimiento: repetir el mensaje
- 30 días de espera de la aplicación: mensaje de que en 30 días comenzará la aplicación resistente a la suplantación de identidad (phishing), anime a los usuarios a inscribirse de forma proactiva.
- 15 días de espera desde el cumplimiento: repetir el mensaje, informarlos de cómo ponerse en contacto con el departamento de soporte técnico
- 7 días de espera desde el cumplimiento: repetir el mensaje, informarlos de cómo ponerse en contacto con el departamento de soporte técnico
- 1 día fuera del cumplimiento: informarles de la aplicación se producirá en 24 horas, infórmelos de cómo ponerse en contacto con el departamento de soporte técnico.
Microsoft recomienda comunicarse a los usuarios a través de otros canales más allá del correo electrónico. Otras opciones pueden incluir mensajes de Microsoft Teams, pósteres de sala de descanso y programas de campeones en los que los empleados seleccionados están capacitados para defender el programa a sus compañeros.
Creación de informes y supervisión
Los informes de Microsoft Entra ID (como Actividad de métodos de autenticación y Detalles del evento de inicio de sesión para la autenticación multifactor de Microsoft Entra) proporcionan información técnica y empresarial que puede ayudarle a medir e impulsar la adopción.
En el panel de Actividad de los métodos de autenticación, puede ver el registro y el uso.
- Registro muestra el número de usuarios que pueden realizar la autenticación sin contraseña resistente a la suplantación de identidad, así como otros métodos de autenticación. Puede ver gráficos que muestran qué métodos de autenticación registraron los usuarios y el registro reciente de cada método.
- Uso muestra qué métodos de autenticación se usaron para el inicio de sesión.
Los propietarios de aplicaciones empresariales y técnicas deben ser propietarios y recibir informes en función de los requisitos de la organización.
- Realice un seguimiento de la implementación de credenciales sin contraseña resistentes a la suplantación de identidad con informes de actividad de registro de métodos de autenticación.
- Realice un seguimiento de la adopción de credenciales sin contraseña resistentes a la suplantación de identidad (phishing) con los métodos de autenticación que inician sesión en los informes de actividad e inician sesión.
- Use el informe de actividad de inicio de sesión para realizar un seguimiento de los métodos de autenticación usados para iniciar sesión en las distintas aplicaciones. Seleccione la fila de usuario; Seleccione Detalles de autenticación para ver el método de autenticación y su actividad de inicio de sesión correspondiente.
Microsoft Entra ID agrega entradas a los registros de auditoría cuando se producen estas condiciones:
- Un administrador cambia los métodos de autenticación.
- Un usuario realiza cualquier tipo de cambio en sus credenciales dentro de Microsoft Entra ID.
Microsoft Entra ID conserva la mayoría de los datos de auditoría durante 30 días. Se recomienda una retención más larga para la auditoría, el análisis de tendencias y otras necesidades empresariales.
Acceda a los datos de auditoría en el Centro de administración o API de Microsoft Entra y descargue en los sistemas de análisis. Si necesita una retención más larga, exporte y consuma los registros en una herramienta SIEM como Microsoft Sentinel, Splunk o Sumo Logic.
Supervisión del volumen de vales del departamento de soporte técnico
El departamento de soporte técnico de TI puede proporcionar una señal inestimable sobre el progreso de la implementación, por lo que Microsoft recomienda realizar un seguimiento del volumen de vales del departamento de soporte técnico al ejecutar una implementación sin contraseña resistente a la suplantación de identidad (phishing).
A medida que aumenta el volumen de incidencias del departamento de soporte técnico, debe ralentizar el ritmo de las implementaciones, las comunicaciones de usuario y las acciones de cumplimiento. A medida que el volumen de vales disminuye, puede hacer una copia de seguridad de estas actividades. El uso de este enfoque requiere que mantenga la flexibilidad en el plan de lanzamiento.
Por ejemplo, podría ejecutar las implementaciones y, a continuación, aplicar las aplicaciones en oleadas que tienen intervalos de fechas en lugar de fechas específicas:
- 1 de junio al 15: Implementación y campañas de registro de cohortes de onda 1
- 16 de junio a 30: Implementación y campañas de registro de cohortes de onda 2
- 1 de julio a 15: Implementación y campañas de registro de cohortes de onda 3
- 16 de julio-31: Aplicación de cohortes de onda 1 habilitada
- 1 de agosto a 15: Aplicación de cohortes de onda 2 habilitada
- 16 de agosto-31: Aplicación de cohortes de onda 3 habilitada
A medida que ejecute estas distintas fases, es posible que tenga que ralentizarse en función del volumen de vales del departamento de soporte técnico abiertos y, a continuación, reanudar cuando el volumen haya disminuido. Para ejecutar esta estrategia, Microsoft recomienda crear un grupo de seguridad de id. de Microsoft Entra para cada oleada y agregar cada grupo a las directivas de uno en uno. Este enfoque ayuda a evitar sobrecargar a los equipos de soporte técnico.
Aplicación de métodos resistentes a la suplantación de identidad (phishing) para el inicio de sesión
Esta sección se centra en la fase 4.
La fase final de una implementación sin contraseña resistente a la suplantación de identidad (phishing) exige el uso de credenciales resistentes a la suplantación de identidad (phishing). El mecanismo principal para hacerlo en Microsoft Entra ID es los puntos fuertes de autenticación de acceso condicional. Microsoft recomienda abordar el cumplimiento de cada rol en función de una metodología de emparejamiento de usuarios o dispositivos. Por ejemplo, un lanzamiento de cumplimiento podría seguir este patrón:
- Trabajadores de la información en Windows e iOS
- Trabajadores de la información en macOS y Android
- Profesionales de TI en iOS y Android
- FLW en iOS y Android
- FLW en Windows y macOS
- Profesionales de TI en Windows y macOS
Microsoft recomienda crear un informe de todos los pares de usuario o dispositivo mediante el uso de datos de inicio de sesión del inquilino. Puede usar herramientas de consulta como Azure Monitor y Workbooks. Como mínimo, intente identificar todos los pares de usuario o dispositivo que coincidan con estas categorías.
Para cada usuario, cree una lista de los sistemas operativos que usan regularmente para trabajar. Asigne la lista a la preparación para el cumplimiento del inicio de sesión resistente a la suplantación de identidad (phishing) para ese par de usuarios o dispositivos.
| Tipo de SO | Listo para el cumplimiento | No listo para el cumplimiento |
|---|---|---|
| Windows | 10+ | Windows Server 8.1 y versiones anteriores |
| iOS | 17+ | 16 y versiones anteriores |
| Android | 14+ | 13 y versiones anteriores |
| macOS | 13 y versiones posteriores (Ventura) | 12 y versiones anteriores |
| VDI | Depende1 | Depende1 |
| Otros | Depende1 | Depende1 |
1Para cada par de usuarios o dispositivos en los que la versión del dispositivo no está lista inmediatamente para la aplicación, determine cómo abordar la necesidad de aplicar la resistencia a la suplantación de identidad (phishing). Tenga en cuenta las siguientes opciones para sistemas operativos más antiguos, infraestructura de escritorio virtual (VDI) y otros sistemas operativos, como Linux:
- Exigir la resistencia a la suplantación de identidad mediante hardware externo: claves de seguridad FIDO2
- Exigir la resistencia a la suplantación de identidad mediante hardware externo: tarjetas inteligentes
- Exigir la resistencia a la suplantación de identidad mediante credenciales remotas, como claves de acceso en el flujo de autenticación entre dispositivos
- Exigir la resistencia a la suplantación de identidad mediante credenciales remotas dentro de túneles RDP (especialmente para VDI)
La tarea clave consiste en medir a través de los datos que los usuarios y los roles están listos para la aplicación en determinadas plataformas. Comience las acciones de cumplimiento en pares de usuarios o dispositivos que estén listos para aplicar para "detener el sangrado" y reducir la cantidad de autenticación phishable que se produce en su entorno.
A continuación, pase a otros escenarios en los que los pares de usuarios o dispositivos requieren esfuerzos de preparación. Recorra la lista de pares de usuarios o dispositivos hasta que aplique la autenticación resistente a la suplantación de identidad en todo el panel.
Cree un conjunto de grupos de identificadores de Entra de Microsoft para implementar la aplicación gradualmente. Vuelva a usar los grupos del paso anterior si usó el enfoque de lanzamiento basado en oleadas.
Dirigirse a cada grupo con una directiva de acceso condicional específica. Este enfoque le ayuda a implementar los controles de cumplimiento gradualmente por el par de usuarios o dispositivos.
| Directiva | Nombre de grupo destinado a la directiva | Directiva: condición de plataforma de dispositivos | Directiva: concesión de control |
|---|---|---|---|
| 1 | Usuarios listos para la suplantación de identidad de Windows resistentes a la suplantación de identidad (phishing) | Windows | Exigir la seguridad de autenticación: MFA resistente a la suplantación de identidad |
| 2 | Usuarios listos para la suplantación de identidad de macOS resistentes a la suplantación de identidad (phishing) | macOS | Exigir la seguridad de autenticación: MFA resistente a la suplantación de identidad |
| 3 | Usuarios listos para la suplantación de identidad de iOS sin contraseña | iOS | Exigir la seguridad de autenticación: MFA resistente a la suplantación de identidad |
| 4 | Usuarios listos para contraseñas resistentes a la suplantación de identidad de Android | Android | Exigir la seguridad de autenticación: MFA resistente a la suplantación de identidad |
| 5 | Otros usuarios listos para contraseñas resistentes a la suplantación de identidad (phishing) | Cualquiera excepto Windows, macOS, iOS o Android | Exigir la seguridad de autenticación: MFA resistente a la suplantación de identidad |
Agregue cada usuario a cada grupo a medida que determine si su dispositivo y sistema operativo están listos o no tienen un dispositivo de ese tipo. Al final del lanzamiento, cada usuario debe estar en uno de los grupos.
Responder al riesgo de usuarios sin contraseña
Protección de id. de Microsoft Entra ayuda a las organizaciones a detectar, investigar y corregir los riesgos relacionados con las identidades. Protección de id. de Microsoft Entra proporciona detecciones importantes y útiles para los usuarios incluso después de cambiar a usar credenciales sin contraseña resistentes a la suplantación de identidad (phishing). Por ejemplo, algunas detecciones pertinentes para los usuarios resistentes a la suplantación de identidad incluyen:
- Actividad desde una dirección IP anónima
- Vulneración de identidad de usuario confirmada por el administrador
- Token anómalo
- Dirección IP malintencionada
- Inteligencia contra amenazas de Microsoft Entra
- Explorador sospechoso
- Atacante en el medio
- Posible intento de acceso al token de actualización principal (PRT)
- Y otros: Detecciones de riesgo asignadas a riskEventType
Microsoft recomienda que Protección de id. de Microsoft Entra los clientes realicen las siguientes acciones para proteger mejor sus usuarios sin contraseña resistentes a la suplantación de identidad:
- Revise la guía de implementación de Protección de id. de Microsoft Entra: Planear una implementación de protección de identificadores
- Configuración de los registros de riesgo para exportar a un SIEM
- Investigar y actuar sobre cualquier riesgo de usuario medio
- Configuración de una directiva de acceso condicional para bloquear usuarios de alto riesgo
Después de implementar Protección de id. de Microsoft Entra, considere la posibilidad de usar la protección de tokens de acceso condicional. A medida que los usuarios inician sesión con credenciales sin contraseña resistentes a la suplantación de identidad (phishing), los ataques y las detecciones siguen evolucionando. Por ejemplo, cuando las credenciales de usuario ya no se pueden suplantar fácilmente, los atacantes pueden pasar a intentar filtrar tokens de dispositivos de usuario. La protección de tokens ayuda a mitigar este riesgo mediante el enlace de tokens al hardware del dispositivo al que se emitió.