Compartir a través de

Protección de Microsoft 365 contra ataques locales

  • Artículo

Muchos clientes conectan sus redes corporativas privadas a Microsoft 365 para beneficiar a sus usuarios, dispositivos y aplicaciones. Sin embargo, estas redes privadas pueden verse en peligro de muchas formas bien documentadas. Microsoft 365 actúa como una especie de sistema nervioso para muchas organizaciones. Es fundamental protegerlo de la infraestructura local en peligro.

En este artículo se muestra cómo configurar los sistemas para proteger el entorno en la nube de Microsoft 365 frente a riesgos locales, incluidos los elementos siguientes:

  • Valores de configuración del inquilino de Microsoft Entre
  • Cómo los inquilinos de Microsoft Entra pueden conectarse de forma segura a los sistemas locales
  • Las concesiones necesarias para que los sistemas funcionen de formas que protejan los sistemas en la nube frente a los peligros locales.

Microsoft recomienda encarecidamente implementar esta guía.

Orígenes de amenazas en los entornos locales

El entorno en la nube de Microsoft 365 se beneficia de una amplia infraestructura de supervisión y seguridad. Microsoft 365 usa el aprendizaje automático y la inteligencia humana para buscar en todo el tráfico mundial. Puede detectar rápidamente ataques y le permite reconfigurarlo casi en tiempo real.

Las implementaciones híbridas pueden conectar la infraestructura local a Microsoft 365. En estas implementaciones, muchas organizaciones delegan la confianza en componentes locales para tomar decisiones críticas de administración del estado de los objetos de directorio y autenticación. Si el entorno local está en peligro, estas relaciones de confianza se convierten en la oportunidad para que un atacante ponga en peligro el entorno de Microsoft 365.

Los dos vectores de amenaza principales son las relaciones de confianza de federación y la sincronización de cuentas. Ambos vectores pueden conceder a un atacante acceso administrativo a la nube.

  • Las relaciones de confianza federadas, como la autenticación del Lenguaje de marcado de aserción de seguridad (SAML), se usan para autenticarse en Microsoft 365 a través de la infraestructura de identidad local. Si un certificado de firma de tokens de SAML está en peligro, la federación permitiría a cualquier usuario que tenga ese certificado suplantar a cualquier usuario en la nube.

    Se recomienda deshabilitar las relaciones de confianza de federación para la autenticación en Microsoft 365 cuando sea posible.

  • La sincronización de cuentas se puede usar para modificar los usuarios con privilegios, incluidas sus credenciales, o los grupos que tienen privilegios administrativos en Microsoft 365.

    Se recomienda garantizar que los objetos sincronizados no tengan privilegios más allá de un usuario de Microsoft 365. Puede controlar los privilegios directamente o a través de la inclusión en roles o grupos de confianza. Asegúrese de que estos objetos no tienen ninguna asignación directa o anidada en grupos o roles en la nube de confianza.

Protección de Microsoft 365 contra vulnerabilidades locales

Para abordar las amenazas descritas anteriormente, se recomienda cumplir los principios que se ilustran en el diagrama siguiente:

Arquitectura de referencia para la protección de Microsoft 365, tal y como se describe en la siguiente lista.

  1. Aísle por completo las cuentas de administrador de Microsoft 365. Deben cumplir los siguientes requisitos:

    • Dominado en Microsoft Entra ID.
    • Deben autenticarse mediante la autenticación multifactor.
    • Protegido por el acceso condicional de Microsoft Entra.
    • Debe accederse a ellas solo mediante las estaciones de trabajo administradas de Azure.

    Estas cuentas de administrador son cuentas de uso restringido. Ninguna cuenta local debe tener privilegios administrativos en Microsoft 365.

    Para obtener más información, consulte Acerca de los roles de administrador. Consulte también Roles para Microsoft 365 en Microsoft Entra ID.

  2. Administre dispositivos desde Microsoft 365. Use la administración de dispositivos móviles (MDM) basados en la nube y unidos a Microsoft Entra para eliminar dependencias en la infraestructura de administración de dispositivos local. Estas dependencias pueden comprometer los controles de seguridad y los dispositivos.

  3. Asegúrese de que ninguna cuenta local tenga privilegios elevados para Microsoft 365. Algunas cuentas tienen acceso a aplicaciones locales que requieren autenticación NTLM, LDAP o Kerberos. Estas cuentas deben estar en la infraestructura de identidad local de la organización. Asegúrese de que estas cuentas, incluidas las cuentas de servicio, no estén incluidas en grupos ni roles en la nube con privilegios. Asegúrese también de que los cambios en estas cuentas no afecten a la integridad de su entorno de nube. El software local con privilegios no debe ser capaz de afectar a los roles ni a las cuentas con privilegios de Microsoft 365.

  4. Use la autenticación en la nube de Microsoft Entra para eliminar las dependencias de las credenciales locales. Utilice siempre una autenticación sólida, como Windows Hello, FIDO, Microsoft Authenticator o la autenticación multifactor de Microsoft Entra.

Recomendaciones de seguridad específicas

En las secciones siguientes se proporciona una guía sobre cómo implementar los principios descritos anteriormente.

Aislamiento de identidades con privilegios

En Microsoft Entra ID, los usuarios que tienen roles privilegiados, como administradores, son la raíz de confianza para construir y administrar el resto del entorno. Implemente las siguientes prácticas para minimizar los efectos de un riesgo.

  • Utilice cuentas solo en la nube para Microsoft Entra ID y roles con privilegios de Microsoft 365.

    Para cada rol con privilegios elevados, debe hacer lo siguiente:

    • Revise los usuarios que tienen onPremisesImmutableId y onPremisesSyncEnabled establecidos. Consulte Microsoft Graph API tipo de recurso de usuario.
    • Cree cuentas de usuario solo en la nube para esas personas y quite su identidad híbrida de roles con privilegios.

  • Implemente dispositivos de acceso con privilegios para obtener acceso privilegiado para administrar Microsoft 365 y Microsoft Entra ID. Consulte Roles y perfiles de dispositivos.

    Implemente Microsoft Entra Privileged Identity Management (PIM) para obtener acceso justo a tiempo a todas las cuentas humanas que tienen roles privilegiados. Exija una autenticación sólida para activar los roles. Consulte Qué es Microsoft Entra Privileged Identity Management.

  • Proporcione roles administrativos que permitan el privilegio mínimo necesario para realizar las tareas requeridas. Consulte Roles con privilegios mínimos por tarea en Microsoft Entra ID.

  • Para habilitar una rica experiencia de asignación de roles que incluya delegación y múltiples roles al mismo tiempo, considere usar grupos de seguridad de Microsoft Entra o Grupos de Microsoft 365. En su conjunto, estos grupos se denominan grupos de nube.

    Además, habilite el control de acceso basado en roles. Consulte Asignar roles de Microsoft Entra a grupos. Puede usar unidades administrativas para restringir el ámbito de los roles a una parte de la organización. Consulte Unidades administrativas en Microsoft Entra ID.

  • Implemente cuentas de acceso de emergencia. No use almacenes de contraseñas locales para almacenar las credenciales. Consulte Administrar cuentas de acceso de emergencia en Microsoft Entra ID.

Para obtener más información, consulte Protección del acceso con privilegios. Consulte también Procedimientos de acceso seguro para administradores en Microsoft Entra ID.

Uso de la autenticación en la nube

Las credenciales son un vector de ataque principal. Implemente los siguientes procedimientos para mejorar la seguridad de las credenciales:

Limitaciones y compromisos

La administración de contraseñas de cuentas híbrida requiere componentes híbridos, como agentes de protección de contraseñas y agentes de escritura diferida de contraseñas Si la infraestructura local está en peligro, los atacantes pueden controlar los equipos en los que residen estos agentes. Esta vulnerabilidad no pondrá en peligro la infraestructura en la nube. Sin embargo, las cuentas en la nube no protegerán estos componentes frente al riesgo local.

Las cuentas locales sincronizadas desde Active Directory se marcan para que no expiren nunca en Microsoft Entra ID. Esta configuración se suele mitigar mediante la configuración local de contraseñas de Active Directory. Si su instancia de Active Directory está en peligro y la sincronización está deshabilitada, establezca la opción EnforceCloudPasswordPolicyForPasswordSyncedUsers para forzar los cambios de contraseña.

Aprovisionamiento del acceso de usuarios desde la nube

El aprovisionamiento se refiere a la creación de cuentas de usuario y grupos en aplicaciones o proveedores de identidades.

El diagrama de la arquitectura de aprovisionamiento muestra la interacción de Microsoft Entra ID con RR. HH en la nube, Microsoft Entra B 2 B, el aprovisionamiento de aplicaciones de Azure y las licencias basadas en grupos.

Se recomiendan los siguientes métodos de aprovisionamiento:

  • Aprovisiona desde aplicaciones de RR. HH. en la nube a Microsoft Entra ID. Este aprovisionamiento permite aislar un riesgo local. Este aislamiento no interrumpe el ciclo joiner-mover-leaver de las aplicaciones de RR. HH. en la nube a Microsoft Entra ID.

  • Aplicaciones en la nube. Siempre que sea posible, implementa el aprovisionamiento de aplicaciones de Microsoft Entra en lugar de soluciones de aprovisionamiento locales. Este método protege algunas de las aplicaciones de software como servicio (SaaS) frente a los perfiles de hackers malintencionados en vulneraciones locales. Para obtener más información, consulta Qué es el aprovisionamiento de aplicaciones en Microsoft Entra ID.

  • Identidades externas. Utiliza la colaboración B2B de Microsoft Entra para reducir la dependencia de las cuentas locales para la colaboración externa con socios, clientes y proveedores. Evalúa detenidamente cualquier federación directa con otros proveedores de identidades. Para obtener más información, consulta Información general sobre la colaboración B2B.

    Se recomienda limitar las cuentas de invitado de B2B de las siguientes maneras:

    • Limitar el acceso de invitado a los grupos de exploración y otras propiedades del directorio. Usa la configuración de colaboración externa para restringir la capacidad de los invitados de leer los grupos de los que no son miembros.
    • Bloquear el acceso a Azure Portal. Puedes hacer excepciones raras, pero necesarias. Crea una directiva de acceso condicional que incluya a todos los usuarios invitados y externos. Luego implementa una directiva para bloquear el acceso. Consulta Acceso condicional.

  • Bosques desconectados. Utiliza el aprovisionamiento en la nube de Microsoft Entra para conectarse a bosques desconectados. Este enfoque elimina la necesidad de establecer una conexión o relaciones de confianza entre los bosques, lo que puede ampliar el efecto de una vulneración local. Para obtener más información, consulta Qué es la sincronización en la nube de Microsoft Entra Connect.

Limitaciones y concesiones

Cuando se usan para aprovisionar cuentas híbridas, Microsoft Entra en los sistemas de RR. HH. en la nube se basa en la sincronización local para completar el flujo de datos de Active Directory a Microsoft Entra. Si se interrumpe la sincronización, los nuevos registros de empleados no estarán disponibles en Microsoft Entra.

Uso de los grupos en la nube para la colaboración y el acceso

Los grupos en la nube permiten desacoplar la colaboración y el acceso de la infraestructura local.

  • Colaboración. Usa Grupos de Microsoft 365 y Microsoft Teams para la colaboración moderna. Retira las listas de distribución locales y actualiza las listas de distribución a grupos de Microsoft 365 en Outlook.
  • Acceso. Usa Microsoft Entra grupos de seguridad o Grupos de Microsoft 365 para autorizar el acceso a las aplicaciones en Microsoft Entra ID.
  • Licencias de Office 365. Usa las licencias basadas en grupos para aprovisionar en Office 365 usando grupos solo en la nube. Este método desacopla el control de la pertenencia a grupos de la infraestructura local.

Los propietarios de los grupos que se usan para el acceso deben considerarse identidades con privilegios para evitar la toma del control de la pertenencia a partir de un riesgo local. Una toma de control incluiría la manipulación directa de la pertenencia a grupos local o la manipulación de atributos locales que pueden afectar a los grupos de pertenencia dinámica en Microsoft 365.

Administración de dispositivos desde la nube

Usa Microsoft Entra funcionalidades para administrar dispositivos de forma segura.

Implementa estaciones de trabajo Windows 10 unidas a Microsoft Entra con directivas de administración de dispositivos móviles. Habilita Windows Autopilot para una experiencia de aprovisionamiento totalmente automatizada. Consulta Planificar la implementación de unión a Microsoft Entra y Windows Autopilot.

  • Usa estaciones de trabajo de Windows 10.
    • Deja de usar máquinas que ejecuten Windows 8.1 y versiones anteriores.
    • No implementes equipos que tengan sistemas operativos de servidor como estaciones de trabajo.
  • Usa Microsoft Intune como origen de la autoridad de todas las cargas de trabajo de administración de dispositivos. Consulte Microsoft Intune.
  • Implemente dispositivos de acceso con privilegios. Para obtener más información, consulte Roles y perfiles de dispositivo.

Cargas de trabajo, aplicaciones y recursos

  • Sistemas locales de inicio de sesión único (SSO)

    Deje de usar toda infraestructura local de administración de acceso web y federación. Configure las aplicaciones para que usen el identificador de Microsoft Entra.

  • Aplicaciones SaaS y de línea de negocio (LOB) que admiten protocolos de autenticación modernos

    Use el identificador de Microsoft Entra para el inicio de sesión único. Cuantas más aplicaciones configure para usar Microsoft Entra ID para la autenticación, menor será el riesgo de que se vea comprometido el sistema local. Para obtener más información, consulte Qué es el inicio de sesión único en Microsoft Entra ID.

  • Aplicaciones heredadas

    Puede habilitar la autenticación, la autorización y el acceso remoto a las aplicaciones heredadas que no admitan la autenticación moderna. Utilice el proxy de aplicación Microsoft Entra. O bien, habilítelas a través de una solución de controlador de entrega de aplicaciones o de red mediante integraciones de asociados de acceso híbrido seguro. Consulte Proteger aplicaciones heredadas con Microsoft Entra ID.

    Elija un proveedor de VPN que admita la autenticación moderna. Integre su autenticación con Microsoft Entra ID. En un compromiso local, puede usar Microsoft Entra ID para deshabilitar o bloquear el acceso deshabilitando la VPN.

  • Servidores de cargas de trabajo y aplicaciones

    Las aplicaciones o los recursos que necesitaban servidores se pueden migrar a la infraestructura como servicio (IaaS) de Azure. Utilice Microsoft Entra Domain Services para desacoplar la confianza y la dependencia en instancias locales de Active Directory. Para lograr este desacoplamiento, asegúrese de que las redes virtuales utilizadas para Microsoft Entra Domain Services no tengan una conexión a redes corporativas. Consulte Microsoft Entra Domain Services.

    Use niveles de credenciales. Los servidores de aplicaciones se suelen considerar recursos de nivel 1. Para obtener más información, consulte Modelo de acceso empresarial.

Directivas de acceso condicional

Use el acceso condicional de Microsoft Entra para interpretar las señales y usarlas para tomar decisiones de autenticación. Para obtener más información, consulte Planeamiento de la implementación del acceso condicional.

Supervisión

Después de haber configurado el entorno para proteger Microsoft 365 de un riesgo local, supervise proactivamente el entorno. Para obtener más información, consulte ¿Qué es la supervisión de Microsoft Entra?

Escenarios que supervisar

Supervise los siguientes escenarios clave, además de los escenarios específicos de su organización. Por ejemplo, debe supervisar de forma proactiva el acceso a sus aplicaciones y recursos críticos para la empresa.

  • Actividad sospechosa

    Supervise todos los eventos de riesgo de Microsoft Entra para detectar actividades sospechosas. Consulte Instrucciones: Investigación de riesgos. Microsoft Entra ID Protection está integrado de forma nativa con Microsoft Defender for Identity.

    Defina ubicaciones con nombre de red para evitar detecciones ruidosas en las señales basadas en la ubicación. Consulte Uso de la condición de ubicación en una directiva de acceso condicional.

  • Alertas de análisis de comportamiento de usuarios y entidades (UEBA)

    Use UEBA para obtener conclusiones sobre la detección de anomalías. Microsoft Defender for Cloud proporciona UEBA en la nube. Consulte Investigación de usuarios de riesgo.

    Puede integrar UEBA local desde la protección contra amenazas avanzada (ATP) de Azure. Las aplicaciones de Microsoft Defender for Cloud leen señales de Microsoft Entra ID Protection. Consulte conexión al bosque de Active Directory.

  • Actividad de las cuentas de acceso de emergencia

    Supervise todo acceso que use cuentas de acceso de emergencia. Consulte Administrar cuentas de acceso de emergencia en Microsoft Entra ID. Cree alertas para iniciar investigaciones. Esta supervisión debe incluir las acciones siguientes:

    • Inicios de sesión
    • Administración de credenciales
    • Todas las actualizaciones de pertenencias a grupos
    • Asignaciones de aplicaciones

  • Actividad de roles con privilegios

    Configure y revise las alertas de seguridad generadas por Microsoft Entra Privileged Identity Management (PIM). Supervise la asignación directa de roles con privilegios fuera de PIM mediante la generación de alertas cada vez que se asigne un usuario directamente. Consulte Alertas de seguridad.

  • Configuraciones para todo el inquilino de Microsoft Entra

    cualquier cambio en las configuraciones de todo el inquilino debe generar alertas en el sistema. Entre estos cambios se incluyen los siguientes:

    • Dominios personalizados actualizados
    • Microsoft Entra B2B cambia a las listas permitidas y bloqueadas
    • Microsoft Entra B2B cambia los proveedores de identidad permitidos, como proveedores de identidad SAML a través de federación directa o inicios de sesión sociales
    • Cambios en la directiva de riesgo o de acceso condicional

  • Objetos de aplicación y de entidad de servicio

    • Nuevas aplicaciones o entidades de servicio que pueden requerir directivas de acceso condicional
    • Credenciales agregadas a las entidades de servicio
    • Actividad de consentimiento de la aplicación

  • Roles personalizados

    • Actualizaciones en las definiciones de roles personalizados
    • Roles personalizados recién creados

Administración de registros

Defina una estrategia, un diseño y una implementación de almacenamiento y retención de registros para facilitar un conjunto de herramientas coherente. Por ejemplo, podría considerar sistemas de administración de eventos e información de seguridad (SIEM), como Microsoft Sentinel, consultas comunes y cuadernos de estrategias forenses y de investigación.

  • Registros de Microsoft Entra. Ingiera los registros y las señales generados de forma coherente siguiendo los procedimientos recomendados de configuración, como la ingesta de diagnóstico, de retención de registros y de SIEM.

    La estrategia de registro debe incluir los siguientes registros de Microsoft Entra:

    • Actividad de inicio de sesión
    • Registros de auditoría
    • Eventos de riesgo

    Microsoft Entra ID proporciona la integración de Azure Monitor para los registros de auditoría y el registro de actividad de inicio de sesión. Consulte Microsoft Entra registros de actividad en Azure Monitor.

    Use Microsoft Graph API para ingerir los eventos de riesgo. Consulte Uso de las API de protección de identidades de Microsoft Graph.

    Puede transmitir registros de Microsoft Entra a registros de Azure Monitor. Consulte Integración de los registros de Microsoft Entra con los registros de Azure Monitor.

  • Registros de seguridad del sistema operativo de la infraestructura híbrida. Todos los registros del sistema operativo de infraestructura de identidad híbrida deben archivarse y supervisarse detenidamente como un sistema de nivel 0, dadas las consecuencias en el área expuesta. Incluya los siguientes elementos:

    • Agentes de Application Proxy

    • Agentes de escritura diferida de contraseñas

    • Máquinas de puertas de enlace de protección de contraseñas

    • Servidores de directivas de red (NPS) que tienen la extensión RADIUS de autenticación multifactor de Microsoft Entra

    • Microsoft Entra Connect

      Debe implementar Microsoft Entra Connect Health para supervisar la sincronización de identidades. Consulte Qué es Microsoft Entra Connect.

Pasos siguientes