Guía de referencia de operaciones de administración de autenticación de Microsoft Entra
En esta sección de la guía de referencia de operaciones de Microsoft Entra se describen las comprobaciones y las acciones que debe realizar para proteger y administrar las credenciales, definir la experiencia de autenticación (AuthN), delegar la asignación, medir el uso y definir directivas de acceso basadas en la posición de seguridad de la empresa.
Nota:
Estas recomendaciones están actualizadas hasta la fecha de publicación, pero pueden cambiar con el tiempo. Las organizaciones deben evaluar continuamente sus prácticas de identidad a medida que los productos y servicios de Microsoft evolucionen.
Procesos operativos clave
Asignación de propietarios a las tareas clave
La administración de Microsoft Entra ID requiere la ejecución continua de tareas y procesos operativos clave que pueden no formar parte de un proyecto de lanzamiento. Aun así, es importante que configures estas tareas con el fin de optimizar tu entorno. Entre las tareas clave y sus propietarios recomendados se incluyen:
| Tarea | Propietario |
|---|---|
| Administrar el ciclo de vida de la configuración de inicio de sesión único (SSO) en Microsoft Entra ID | Equipo de operaciones de la administración de acceso e identidades (IAM) |
| Diseño de directivas de acceso condicional para aplicaciones Microsoft Entra | Equipo de arquitectura de InfoSec |
| Archivar actividad de inicio de sesión en un sistema de administración de eventos e información de seguridad (SIEM) | Equipo de operaciones de InfoSec |
| Archivar eventos de riesgo en un sistema SIEM | Equipo de operaciones de InfoSec |
| Evaluar las propiedades e investigar las alertas de seguridad | Equipo de operaciones de InfoSec |
| Evaluar las propiedades e investigar los eventos de seguridad | Equipo de operaciones de InfoSec |
| Evaluar las propiedades e investigar los usuarios marcados en informes de vulnerabilidades y riesgos desde Microsoft Entra ID Protection | Equipo de operaciones de InfoSec |
Nota:
Microsoft Entra ID Protection requiere licencias de Microsoft Entra ID P2. Para encontrar la licencia adecuada para sus requisitos, consulte Comparación de las características disponibles con carácter general de las ediciones Microsoft Entra ID Gratis y Microsoft Entra ID P1 o P2.
A medida que revise la lista, es posible que tenga que asignar un propietario a las tareas que no tienen uno o ajustar la propiedad de aquellas tareas cuyos propietarios no se ajustan a las recomendaciones anteriores.
Lecturas recomendadas para propietarios
Administración de credenciales
Directivas de contraseña
Administrar contraseñas de forma segura es una de las partes más destacadas de la administración de identidades y acceso y, a menudo, el objetivo más importante de los ataques. Microsoft Entra ID admite varias características que pueden ayudarle a evitar que un ataque tenga éxito.
Use la tabla siguiente para encontrar la solución recomendada para mitigar el problema que debe abordarse:
| Problema | Recomendación |
|---|---|
| No hay ningún mecanismo que le proteja contra contraseñas poco seguras | Habilite el autoservicio de restablecimiento de contraseña (SSPR) y la protección con contraseña de Microsoft Entra ID |
| No hay ningún mecanismo para detectar contraseñas filtradas | Habilite la sincronización de hash de contraseñas (PHS) para obtener más detalles. |
| Se está usando AD FS y no es posible ir a la autenticación administrada | Habilite el bloqueo inteligente de la extranet de AD FS o el bloqueo inteligente de Microsoft Entra |
| La directiva de contraseñas usa reglas basadas en la complejidad, como la longitud, los conjuntos de varios caracteres o la caducidad | Reconsidere usar los procedimientos recomendados de Microsoft,cambie su enfoque a la administración de contraseñas e implemente la protección con contraseñas de Microsoft Entra. |
| Los usuarios no están registrados para usar la autenticación multifactor | Registre toda la información de seguridad del usuario de modo que se pueda usar como mecanismo para comprobar la identidad del usuario junto con su contraseña. |
| No hay ninguna revocación de contraseñas en función del riesgo del usuario | Implemente directivas de riesgo de usuario de Protección de id. de Microsoft Entra para forzar cambios de contraseña en credenciales filtradas mediante SSPR. |
| No hay ningún mecanismo de bloqueo inteligente para proteger la autenticación malintencionada de actores no válidos procedentes de direcciones IP identificadas | Implemente la autenticación administrada mediante la nube con la sincronización de hash de contraseñas o mediante la autenticación de paso a través (PTA). |
Lectura recomendada de directivas de contraseñas
Habilitar el autoservicio de restablecimiento de contraseña y la protección con contraseña
Los usuarios que necesitan cambiar o restablecer sus contraseñas son uno de los principales orígenes de volumen y costo debido a las llamadas que realizan al departamento de soporte técnico. Además del costo, cambiar la contraseña como una herramienta para mitigar el riesgo de un usuario es un paso fundamental para mejorar la posición de seguridad de su organización.
Como mínimo, se recomienda implementar el autoservicio de restablecimiento de contraseña (SSPR) de Microsoft Entra ID y la protección de contraseñas local para realizar lo siguiente:
- Desviar las llamadas del departamento de soporte técnico.
- Reemplazar el uso de contraseñas temporales.
- Reemplazar cualquier solución de autoservicio de administración de contraseñas existente que se base en una solución local.
- Eliminar las contraseñas no seguras de su organización.
Nota:
En el caso de las organizaciones con licencias de Microsoft Entra ID P2, se recomienda implementar SSPR y usarlo como parte de las directivas de acceso condicional basadas en riesgos de Protección de id. de Microsoft Entra.
Administración segura de credenciales
Las contraseñas por sí mismas no son lo suficientemente seguras para evitar que los actores no válidos obtengan acceso a su entorno. Como mínimo, cualquier usuario con una cuenta con privilegios debe estar habilitado para poder realizar la autenticación multifactor. Idealmente, debe habilitar el registro combinado y requerir que todos los usuarios se registren en la autenticación multifactor y SSPR mediante la experiencia de registro combinada. Asimismo, se recomienda adoptar una estrategia para proporcionar resistencia y así reducir el riesgo de bloqueo debido a circunstancias imprevistas.
Resistencia de la autenticación a las interrupciones locales
Además de las ventajas de la simplicidad y la posibilidad de habilitar la detección de credenciales filtradas, la sincronización de hash de contraseñas (PHS) de Microsoft Entra y la autenticación multifactor de Microsoft Entra permiten a los usuarios obtener acceso a las aplicaciones de software como servicio (SaaS) y a Microsoft 365 a pesar de las interrupciones locales debido a ciberataques, como NotPetya. También es posible habilitar PHS mientras esté usando la federación. Si habilita PHS, podrá realizar una reserva de autenticación cuando los servicios de federación no estén disponibles.
Si la organización local no tiene una estrategia de resistencia frente a interrupciones o tiene una que no está integrada con Microsoft Entra ID, debe implementar PHS de Microsoft Entra y definir un plan de recuperación ante desastres que incluya PHS. Si habilita PHS de Microsoft Entra, los usuarios podrán autenticarse en Microsoft Entra ID si su instancia de Active Directory local no está disponible.
Para comprender mejor las opciones de autenticación, consulte Elegir el método de autenticación adecuado para la solución de identidad híbrida de Microsoft Entra.
Uso de credenciales mediante programación
Los scripts de Microsoft Entra ID que utilizan PowerShell o las aplicaciones que usan Microsoft Graph API requieren una autenticación segura. La mala administración de credenciales que ejecutan esos scripts y herramientas aumenta el riesgo de robo de credenciales. Si usa scripts o aplicaciones que se basan en contraseñas codificadas de forma rígida o en mensajes de contraseñas, primero debe revisar las contraseñas de los archivos de configuración o el código fuente y, a continuación, reemplazar esas dependencias y usar las identidades administradas de Azure, la autenticación integrada de Windows o los certificados siempre que sea posible. En cuanto a aplicaciones donde no se puedan aplicar las soluciones anteriores, use Azure Key Vault.
Si ve que hay entidades de servicio con credenciales de contraseña y no está seguro de cómo los scripts o las aplicaciones protegen esas credenciales de contraseña, póngase en contacto con el propietario de la aplicación para comprender mejor los patrones de uso.
Microsoft también le recomienda que se ponga en contacto con los propietarios de las aplicaciones para comprender los patrones de uso, si es que existen entidades de servicio con credenciales de contraseña.
Experiencia de autenticación
Autenticación local
La autenticación federada con la integrada de Windows (IWA) o la autenticación administrada de inicio de sesión único (SSO) de conexión directa con la sincronización de hash de contraseña o la autenticación de paso a través, es la mejor experiencia de usuario cuando use la red corporativa relacionada con los controladores de dominio locales. Gracias a ello, se minimiza la fatiga de la petición de credenciales y reduce el riesgo de que los usuarios caigan en ataques de suplantación de identidad. Si ya usa la autenticación administrada en la nube con PHS o PTA, pero los usuarios todavía tienen que escribir su contraseña al autenticarse de forma local, debe implementar de inmediato el SSO de conexión directa. Por otro lado, si está federado con planes para migrar definitivamente a la autenticación administrada en la nube, debe implementar el SSO de conexión directa como parte del proyecto de migración.
Directivas de acceso de confianza de dispositivos
Al igual que un usuario de su organización, un dispositivo es una identidad principal que desea proteger. Puede usar una identidad de dispositivo para proteger los recursos en cualquier momento y ubicación. La autenticación del dispositivo y tener en cuenta su tipo de confianza mejoran la seguridad y facilidad de uso, ya que:
- Se evita la fricción, por ejemplo, con la autenticación multifactor, cuando el dispositivo es de confianza.
- Se bloquea el acceso desde dispositivos que no son de confianza.
- En el caso de los dispositivos Windows 10, es posible usar el inicio de sesión único en los recursos locales sin problemas.
Puedes llevar a cabo este objetivo mediante la incorporación de identidades de dispositivo, y administrarlas en Microsoft Entra ID mediante uno de los métodos siguientes:
- Las organizaciones pueden usar Microsoft Intune para administrar el dispositivo y aplicar las directivas de cumplimiento, atestar el estado del dispositivo y establecer directivas de acceso condicional en función de si el dispositivo es compatible. Microsoft Intune puede administrar dispositivos iOS, dispositivos de escritorio Mac (a través de la integración JAMF), dispositivos de escritorio de Windows (de modo nativo mediante la administración de dispositivos móviles para Windows 10 y la administración conjunta con Microsoft Configuration Manager) y dispositivos móviles Android.
- La combinación de Microsoft Entra híbrido proporciona la opción de administrar contenido con directivas de grupo o Microsoft Configuration Manager en un entorno con equipos unidos a un dominio de Active Directory. Las organizaciones pueden implementar un entorno administrado a través de PHS o PTA con un SSO de conexión directa. Si llevas tus dispositivos a Microsoft Entra ID, podrás maximizar la productividad de los usuarios a través de SSO en los recursos locales y en la nube, a la vez que protegerás el acceso a los recursos en la nube y locales con la opción de acceso condicional al mismo tiempo.
Si tienes dispositivos Windows unidos a un dominio que no están registrados en la nube, o dispositivos Windows unidos a un dominio que sí están registrados en la nube, pero sin directivas de acceso condicional, debes registrar los dispositivos no registrados y, en cualquier caso, usar la combinación de Microsoft Entra híbrido como control de las directivas de acceso condicional.
Si administras dispositivos con MDM o Microsoft Intune, pero no usas controles de dispositivo en las directivas de acceso condicional, se recomienda usar la opción Requerir que el dispositivo esté marcado como compatible como control en esas directivas.
Lectura recomendada de directivas de acceso de confianza al dispositivo
- Instrucciones: Planificar la implementación de la unión a Microsoft Entra híbrido
- Configuraciones de acceso de dispositivos e identidades
Windows Hello para empresas
En Windows 10, Windows Hello para empresas reemplaza las contraseñas por la autenticación en dos fases segura en equipos. Windows Hello para empresas permite obtener una experiencia de la autenticación multifactor más simplificada para los usuarios y reduce la dependencia de las contraseñas. Si no has empezado a implementar dispositivos con Windows 10 o solo los has implementado parcialmente, se recomienda actualizar a Windows 10 y habilitar Windows Hello para empresas en todos los dispositivos.
Si quieres obtener más información sobre la autenticación sin contraseñas, consulta Un mundo sin contraseñas con Microsoft Entra ID.
Asignación y autenticación de la aplicación
Inicio de sesión único para aplicaciones
Proporcionar un mecanismo estándar de inicio de sesión único para toda la empresa es fundamental para mejorar la experiencia del usuario, reducir el riesgo, generar informes y facilitar el gobierno. Si usas aplicaciones que admiten SSO con Microsoft Entra ID pero actualmente están configuradas para usar cuentas locales, debes volver a configurar esas aplicaciones para poder usar SSO con Microsoft Entra ID. Del mismo modo, si usas cualquier aplicación que admita SSO con Microsoft Entra ID pero usas otro proveedor de identidades, debes volver a configurar esas aplicaciones para usar SSO con Microsoft Entra ID también. En el caso de las aplicaciones que no admiten protocolos de federación, pero que admiten la autenticación basada en formularios, se recomienda que configure la aplicación para usar el almacenamiento de contraseñas con el proxy de aplicación de Microsoft Entra.
Nota:
Si no tienes un mecanismo para detectar aplicaciones no administradas en tu organización, te recomendamos que implementes un proceso de detección mediante un agente de seguridad de aplicación en la nube (CASB), como Microsoft Defender for Cloud Apps.
Por último, si tienes una galería de aplicaciones de Microsoft Entra y usas aplicaciones que admiten SSO con Microsoft Entra ID, es recomendable enumerar la aplicación en la galería de aplicaciones.
Lectura recomendada del inicio de sesión único
Migración de aplicaciones de AD FS a Microsoft Entra ID
La migración de aplicaciones desde AD FS a Microsoft Entra ID habilita funcionalidades adicionales en cuanto a seguridad, capacidad de administración más coherente y una mejor experiencia de colaboración. Si tienes aplicaciones configuradas en AD FS que admiten SSO con Microsoft Entra ID, debes volver a configurar esas aplicaciones para que usen SSO con Microsoft Entra ID. Si tienes aplicaciones configuradas en AD FS con configuraciones poco comunes y que no admiten Microsoft Entra ID, debes ponerte en contacto con los propietarios de la aplicación para saber si la configuración especial es un requisito absoluto de la aplicación. Si no es necesario, debes volver a configurar la aplicación para usar SSO con Microsoft Entra ID.
Nota:
Microsoft Entra Connect Health para AD FS se puede usar para recopilar los detalles de configuración de cada aplicación que se pueda migrar a Microsoft Entra ID.
Asignar usuarios a aplicaciones
La asignación de usuarios a las aplicaciones se realiza mejor cuando se usan grupos, porque permiten una gran flexibilidad y la posibilidad de administrarlos a escala. Las ventajas de usar grupos incluyen los grupos de pertenencia dinámica basados en atributos y de delegación a los propietarios de las aplicaciones. Por lo tanto, si ya usas y administras grupos, es recomendable realizar las siguientes acciones para mejorar la administración a escala:
- Delegar la administración y la gobernanza de grupos a los propietarios de la aplicación.
- Permitir el acceso de autoservicio a la aplicación.
- Definir grupos de pertenencia dinámica si los atributos de usuario pueden determinar de forma coherente el acceso a las aplicaciones.
- Implementar la atestación en los grupos que se usan para obtener acceso a las aplicaciones mediante las revisiones de acceso de Microsoft Entra.
Por otro lado, si encuentras aplicaciones que tienen una asignación a usuarios individuales, asegúrate de implementar la gobernanza en esas aplicaciones.
Lectura recomendada para asignar usuarios a aplicaciones
- Asignación de usuarios y grupos a una aplicación en Microsoft Entra ID
- Delegar permisos de registro de aplicaciones en Microsoft Entra ID
- Reglas de pertenencia dinámica para grupos en Microsoft Entra ID
Directivas de acceso
Ubicaciones con nombre
Gracias a las ubicaciones con nombre en Microsoft Entra ID, puede etiquetar intervalos de direcciones IP de confianza en su organización. Microsoft Entra ID usa ubicaciones con nombre para:
- Prevenir falsos positivos en eventos de riesgo. Si se inicia sesión desde una ubicación de confianza se reduce el riesgo en el inicio de sesión del usuario.
- Configurar el acceso condicional basado en la ubicación.
Según la prioridad, use la tabla siguiente para encontrar la solución recomendada que mejor se adapte a las necesidades de su organización:
| Prioridad | Escenario | Recomendación |
|---|---|---|
| 1 | Si usa PHS o PTA y no se han definido las ubicaciones con nombre | Defina las ubicaciones con nombre para mejorar la detección de eventos de riesgo. |
| 2 | Si está federado y no usa la notificaciones de tipo "insideCorporateNetwork" y si no se han definido las ubicaciones con nombre | Defina las ubicaciones con nombre para mejorar la detección de eventos de riesgo. |
| 3 | Si no usa ubicaciones con nombre en las directivas de acceso condicional y no hay ningún riesgo ni controles de dispositivo en las directivas de acceso condicional | Configure la directiva de acceso condicional para incluir ubicaciones con nombre |
| 4 | Si está federado y usa la notificación de tipo "insideCorporateNetwork" y no se han definido las ubicaciones con nombre | Defina las ubicaciones con nombre para mejorar la detección de eventos de riesgo. |
| 5 | Si usa direcciones IP de confianza con la autenticación multifactor en lugar de ubicaciones con nombre y las marca como de confianza | Defina ubicaciones con nombre y márquelas como de confianza para mejorar la detección de eventos de riesgo. |
Directivas de acceso basadas en riesgos
Microsoft Entra ID puede calcular el riesgo de todos los inicios de sesión y de todos los usuarios. El uso del riesgo como criterio en las directivas de acceso puede proporcionar una experiencia de usuario mejor (por ejemplo, recibirá menos mensajes de autenticación y la seguridad será superior); solo debe preguntar a los usuarios cuando sea necesario y automatizar la respuesta y la corrección.
Si ya posee licencias de Microsoft Entra ID P2 que admiten el uso del riesgo en las directivas de acceso, pero no se usan estas directivas, le recomendamos encarecidamente agregar riesgo a su posición de seguridad.
Lectura recomendada de directivas de acceso basadas en riesgos
- Cómo: configurar la directiva de riesgo de inicio de sesión
- Cómo: configurar la directiva de riesgo de usuario
Directivas de acceso de aplicaciones cliente
La administración de aplicaciones de Microsoft Intune (MAM) ofrece la posibilidad de incorporar controles de protección de datos como el cifrado de almacenamiento, el PIN o la limpieza remota del almacenamiento a aplicaciones móviles cliente compatibles, como Outlook Mobile. Además, se pueden crear directivas de acceso condicional para restringir el acceso a servicios en la nube, como Exchange Online, desde aplicaciones aprobadas o compatibles.
Si los empleados instalan aplicaciones compatibles con MAM, como aplicaciones móviles de Office, para obtener acceso a recursos corporativos como Exchange Online o SharePoint en Microsoft 365, y si también admite la opción BYOD (traiga su propio dispositivo), es recomendable implementar las directivas de MAM de la aplicación para administrar la configuración de la aplicación en dispositivos de su propiedad sin tener que realizar la inscripción de MDM; a continuación, solo debe actualizar las directivas de acceso condicional para permitir el acceso solo desde clientes compatibles con MAM.
Si los empleados instalan aplicaciones compatibles con MAM en recursos corporativos y el acceso está restringido en los dispositivos que administra Intune, debe considerar la posibilidad de implementar directivas MAM de aplicaciones, para así poder administrar la configuración de la aplicación en dispositivos personales. Actualice las directivas de acceso condicional para permitir el acceso solo desde clientes compatibles con MAM.
Implementación del acceso condicional
El acceso condicional es una herramienta esencial para mejorar la posición de seguridad de su organización. Por lo tanto, es importante que siga estos procedimientos recomendados:
- Asegúrese de que todas las aplicaciones SaaS tienen al menos una directiva aplicada.
- Evite combinar el filtro Todas las aplicaciones con el control de bloqueo, para evitar el riesgo de bloqueo.
- Evite usar la opción Todos los usuarios como filtro y agregar sin querer Invitados.
- Migre todas las directivas "heredadas" a Azure Portal
- Recopile todos los criterios de los usuarios, los dispositivos y las aplicaciones.
- Use las directivas de acceso condicional para implementar la autenticación multifactor, en lugar de usar un MFA por usuario.
- Conserve un pequeño conjunto de directivas básicas que se puedan aplicar a varias aplicaciones.
- Defina grupos de excepciones vacíos y agréguelos a las directivas para tener una estrategia de excepción.
- Planear cuentas de emergencia sin controles de la autenticación multifactor
- Garantizar una experiencia coherente entre las aplicaciones cliente de Microsoft 365, por ejemplo, Teams, OneDrive, Outlook, etc.) mediante la implementación del mismo conjunto de controles para servicios como Exchange Online y SharePoint en Microsoft 365
- Recuerde que la asignación a directivas debe implementarse a través de grupos, no de personas.
- Realice revisiones periódicas de los grupos de excepciones que se usan en las directivas para limitar el tiempo que los usuarios no usan la posición de seguridad. Si tiene Microsoft Entra ID P2, puede usar las revisiones de acceso para automatizar el proceso
Lectura recomendada del acceso condicional
- Procedimientos recomendados para el acceso condicional en Microsoft Entra ID
- Configuraciones de acceso de dispositivos e identidades
- Referencia de configuración de acceso condicional de Microsoft Entra
- Directivas de acceso condicional habituales
Área expuesta de acceso
Autenticación heredada
Las credenciales seguras, como la autenticación multifactor, no pueden proteger las aplicaciones que usan protocolos de autenticación heredados, por lo que se convierten en el objetivo de ataque preferido de los actores malintencionados. Bloquear la autenticación heredada es fundamental para mejorar la posición de seguridad de acceso.
La autenticación heredada es un término que hace referencia a los protocolos de autenticación que usan aplicaciones como:
- Clientes de Office antiguos que no usan la autenticación moderna (por ejemplo, un cliente de Office 2010).
- Clientes que usan protocolos de correo como el Protocolo de acceso a mensajes de Internet (IMAP), el Protocolo simple de transferencia de correo (SMTP) o el punto de presencia (POP)
Los atacantes prefieren estos protocolos; de hecho, casi el 100 % de los ataques de difusión de contraseñas usan protocolos de autenticación heredados. Los hackers usan protocolos de autenticación heredados, ya que no admiten el inicio de sesión interactivo, que es necesario para superar otros desafíos de seguridad como la autenticación multifactor y la autenticación de dispositivos.
Si la autenticación heredada se usa ampliamente en su entorno, debe planear la migración de los clientes heredados a clientes que admitan una autenticación moderna lo antes posible. En el mismo token, si tiene algunos usuarios que ya usan la autenticación moderna, pero otros que siguen usando la autenticación heredada, debe realizar los siguientes pasos para bloquear a los clientes de autenticación heredada:
Use los informes de actividad de inicio de sesión para identificar a los usuarios que siguen usando la autenticación heredada y la corrección de planes:
Actualice los clientes con capacidad de autenticación moderna a los usuarios afectados.
Planifique un período de tiempo de transición para realizar un bloqueo según los pasos siguientes.
Identifique las aplicaciones heredadas que tengan una dependencia permanente en la autenticación heredada. Consulte el paso 3 que tiene a continuación.
Deshabilite los protocolos heredados en el origen (por ejemplo, el buzón de correo de Exchange) para los usuarios que no usen la autenticación heredada para así evitar una mayor exposición.
En el caso de las cuentas restantes (idealmente, son las identidades no humanas, como las cuentas de servicio), use el acceso condicional para restringir los protocolos heredados después de la autenticación.
Lectura recomendada de la autenticación heredada
Otorgar consentimientos
En un ataque para otorgar consentimientos ilícito, el atacante crea una aplicación registrada en Microsoft Entra que solicita acceso a ciertos datos, como la información de contacto, el correo electrónico o los documentos. Los usuarios pueden otorgar su consentimiento a aplicaciones malintencionadas a través de ataques de suplantación de identidad (phishing) al acceder a sitios web malintencionados.
A continuación se muestra una lista de aplicaciones con permisos que es posible quiera examinar para los servicios en la nube de Microsoft:
- Aplicaciones con permisos *.ReadWrite delegados o de aplicación
- Aplicaciones con permisos delegados que pueden leer, enviar o administrar el correo electrónico en nombre del usuario
- Aplicaciones a las que se concede el uso de los siguientes permisos:
| Resource | Permiso |
|---|---|
| Exchange Online | EAS.AccessAsUser.All |
| EWS.AccessAsUser.All | |
| Mail.Read | |
| Microsoft Graph API | Mail.Read |
| Mail.Read.Shared | |
| Mail.ReadWrite |
- Aplicaciones a las que se le concede la suplantación completa del usuario que inició sesión. Por ejemplo:
| Resource | Permiso |
|---|---|
| Microsoft Graph API | Directory.AccessAsUser.All |
| API REST de Azure | user_impersonation |
Para evitar este escenario, consulte Detectar y solucionar la concesión de consentimiento ilegal en Office 365 para identificar y corregir cualquier aplicación con concesiones ilícitas o aplicaciones que tengan más concesiones de las necesarias. A continuación, quite el autoservicio por completo y establezca los procedimientos de gobernanza. Por último, programe revisiones periódicas de los permisos de la aplicación y quítelos cuando no sean necesarios.
Lectura recomendada para otorgar consentimientos
Configuración de usuario y de grupo
A continuación, se muestra la configuración de usuario y de grupo que se puede bloquear si no existe una necesidad empresarial explícita:
Configuración de usuario
- Usuarios externos: la colaboración externa puede producirse de forma orgánica en la empresa mediante servicios como Teams, Power BI, SharePoint en Microsoft 365 y Azure Information Protection. Si tiene restricciones explícitas para controlar cualquier colaboración externa que inicie el usuario, es recomendable que habilite usuarios externos mediante la administración de derechos de Microsoft Entra o con una operación controlada como, por ejemplo, a través del departamento de soporte técnico. Si no quiere permitir la colaboración externa orgánica en los servicios, puede impedir totalmente que los miembros inviten a usuarios externos. Como alternativa, también puede permitir o bloquear dominios específicos en invitaciones de usuarios externos.
- Registros de aplicaciones: cuando la característica Registros de aplicaciones está habilitada, los usuarios finales pueden incorporar aplicaciones y conceder acceso a sus datos. Un ejemplo típico de la característica Registro de aplicaciones, son los usuarios que habilitan los complementos de Outlook o los asistentes de voz como Alexa y Siri que se usan para leer los correos electrónicos y el calendario, o para enviar correos electrónicos en su nombre. Si el cliente decide desactivar Registro de aplicaciones, los equipos de InfoSec e IAM deben participar en la administración de excepciones (esto es, registros de aplicaciones que son necesarios según los requisitos empresariales), ya que tendrán que registrar las aplicaciones con una cuenta de administrador, y lo más probable es que necesite diseñar un proceso para poner en marcha esta operación.
- Portal de administración: las organizaciones pueden bloquear la hoja de Microsoft Entra en Azure Portal para que los usuarios que no sean administradores no puedan obtener acceso a la administración de Microsoft Entra en Azure Portal y se confundan debido a ello. Vaya a la configuración de usuario en el portal de administración de Microsoft Entra para restringir el acceso:
Nota:
Los usuarios que no son administradores todavía pueden obtener acceso a las interfaces de administración de Microsoft Entra a través de la línea de comandos u otras interfaces de programación.
Configuración de grupo
Administración de grupos de autoservicio: los usuarios pueden crear grupos de seguridad o grupos de Microsoft 365. Si no hay ninguna iniciativa de autoservicio actual para los grupos en la nube, los clientes pueden decidir desactivarla hasta que estén listos para usar esta funcionalidad.
Lectura recomendada de grupos
- ¿Qué es la colaboración de Microsoft Entra B2B?
- Integración de aplicaciones con Microsoft Entra ID
- Aplicaciones, permisos y consentimiento en Microsoft Entra ID.
- Uso de grupos para administrar el acceso a recursos en Microsoft Entra ID
- Configuración de la administración del acceso a aplicaciones de autoservicio en Microsoft Entra ID
Tráfico desde ubicaciones inesperadas
Los atacantes son de varias partes del mundo. Administre este riesgo mediante el uso de directivas de acceso condicional con la ubicación establecida como condición. La condición de ubicación de una directiva de acceso condicional le permite bloquear el acceso a ubicaciones donde no haya ningún motivo empresarial debido al cual se deba iniciar sesión.
Si está disponible, use una solución de Administración de eventos e información de seguridad (SIEM) para analizar y buscar patrones de acceso entre regiones. Si no usa un producto SIEM o no ingiere información de autenticación de Microsoft Entra ID, se recomienda usar Azure Monitor para identificar patrones de acceso entre regiones.
Uso de acceso
Registros de Microsoft Entra archivados e integrados con planes de respuesta a incidentes
El acceso a la actividad de inicio de sesión, auditorías y las eventos de riesgo de Microsoft Entra ID es fundamental para la solución de problemas, el análisis de uso y las investigaciones forenses. Microsoft Entra ID proporciona acceso a estos orígenes a través de las API de REST que tienen un período de retención limitado. Un sistema de Administración de eventos e información de seguridad (SIEM) o una tecnología de archivo equivalente, es fundamental para el almacenamiento a largo plazo de auditorías y compatibilidad. Para habilitar el almacenamiento a largo plazo de los registros de Microsoft Entra, debe agregarlos a la solución SIEM existente o usar Azure Monitor. Archive los registros que se puedan usar como parte de las investigaciones y los planes de respuesta a incidentes.
Lectura recomendada de registros
- Referencia de API de auditoría de Microsoft Entra
- Referencia de la API de generación de informes de actividad de inicio de sesión de Microsoft Entra
- Obtenga datos mediante la API de informes de Microsoft Entra con certificados
- Microsoft Graph para Microsoft Entra ID Protection
- Referencia de la API de actividad de administración de Office 365
- Uso del paquete de contenido de Power BI de Microsoft Entra ID
Resumen
Existen 12 aspectos en una infraestructura de identidades segura. Esta lista le permitirá administrar y asegurar las credenciales, definir la experiencia de autenticación, delegar la asignación, medir el uso y definir las directivas de acceso basadas en la postura de seguridad de la empresa.
- Asignar propietarios a las tareas principales.
- Implementar soluciones para detectar contraseñas débiles o filtradas, mejore la protección y la administración de contraseñas y proteja aún más el acceso de los usuarios a los recursos.
- Administrar la identidad de los dispositivos para proteger los recursos en cualquier momento y desde cualquier ubicación.
- Implementar la autenticación con contraseña.
- Proporcionar un mecanismo de inicio de sesión único estandarizado en toda la organización.
- Migrar aplicaciones desde AD FS a Microsoft Entra ID para obtener una seguridad mejor y una capacidad de administración más coherente.
- Asignar usuarios a las aplicaciones mediante el uso de grupos para permitir una mayor flexibilidad y capacidad administrativa a escala.
- Configurar directivas de acceso basadas en riesgos.
- Bloquear los protocolos de autenticación heredados.
- Detectar y corrija las opciones ilícitas para otorgar consentimiento.
- Bloquear la configuración de usuario y de grupo.
- Habilitar el almacenamiento a largo plazo de registros de Microsoft Entra para la solución de problemas, el análisis de uso y las investigaciones de análisis forense.
Pasos siguientes
Comience a trabajar con las comprobaciones y las acciones operativas de gobernanza de identidad.