Configuración de confianza cero para organizaciones de defensa multiinquilino
En este artículo se muestra a las organizaciones multiinquilino cómo aplicar configuraciones en Microsoft Entra ID y cumplir los requisitos comunes de confianza cero de defensa. Sigue estas recomendaciones para establecer la arquitectura de identidad multiinquilino adecuada e implementar la confianza cero en tu entorno.
Figura 1: Ejemplo de arquitectura de defensa multiinquilino con configuraciones de confianza cero.
Determinar la arquitectura de la identidad
Los inquilinos de Microsoft Entra son la base de la arquitectura de identidad. Un inquilino es un límite de identidad en Microsoft Entra ID. Una organización con un inquilino de Microsoft Entra tiene una arquitectura de un inquilino único. Las organizaciones que usan más de un inquilino de Microsoft Entra tienen una arquitectura multiinquilino.
Ventajas de un único inquilino. Un único inquilino es más fácil de administrar y reducir los costos a través de la eficiencia operativa. Permite configurar más fácilmente un entorno de confianza cero. Un único inquilino evita fragmentar la experiencia del usuario con varias credenciales de inicio de sesión. También ayuda a evitar soluciones siloed que necesita integrar más adelante. Debe esforzarse para tener sus datos, Microsoft 365 y los servicios en la nube de Azure en un único inquilino. Si ya tiene varios inquilinos de Microsoft Entra, debe considerar la posibilidad de consolidar el entorno para usar un solo inquilino. Puede consolidar los inquilinos a través de la transferencia de suscripciones de Azure de los inquilinos secundarios al inquilino principal. Para más información, veaTransferencia de una suscripción de Azure a otro directorio de Microsoft Entra.
Casos de uso multiinquilino. Hay motivos para que una organización de defensa use una arquitectura multiinquilino. Es posible que las organizaciones de defensa grandes y complejas necesiten varios inquilinos de Microsoft Entra para la seguridad, el cumplimiento y la colaboración (vea la tabla 1).
Tabla 1. Motivos para tener o crear varios inquilinos.
| Motivo | Ejemplo |
|---|---|
| La privacidad o la seguridad requieren una separación más profunda de los datos | La organización de una Oficina del Inspector General debe ser independiente. |
| Delegación y segmentación de la administración | Una organización no tiene capacidad para gestionar otra organización. |
| Soberanía y/o propiedad de los datos | Una organización no tiene la autoridad legal para administrar los datos de otra organización. |
| Red y organización de TI | No es posible ni favorable colapsar múltiples arquitecturas de TI de grandes empresas corporativas en una única arquitectura empresarial. |
| Supervisión de SOC y respuesta a incidentes | SOC necesita un inquilino independiente para administrar sus roles y responsabilidades. |
Si necesita varios inquilinos de Microsoft Entra, debe usar Id. externa de Microsoft Entra (B2B) y Azure Lighthouse. Estas características ayudan a admitir entornos de defensa de multiinquilino. Para más información, consulte Modelos de inquilinos para una solución de multi-inquilino.
Identificación de los tipos de inquilino
Las organizaciones de defensa multiinquilino pueden categorizar las instancias de Microsoft Entra que usan como primarias o secundarias. Cada organización debe identificar y designar un inquilino como inquilino principal. Todos los demás inquilinos son secundarios. En la figura 1 se muestra una organización de defensa con un inquilino principal y n inquilinos secundarios (se muestran dos inquilinos secundarios).
Identifique el inquilino principal. La mayoría de las organizaciones de defensa crean el inquilino principal cuando se registran en Microsoft 365. El inquilino principal contiene (1) todas las identidades de usuario y las licencias de Microsoft 365, (2) dispositivos y (3) aplicaciones (consulte la figura 1). Las organizaciones de defensa suelen usar Microsoft Entra Connect para sincronizar las identidades de Active Directory en el entorno local con el inquilino principal de Microsoft Entra.
Algunas organizaciones de defensa consumen Microsoft 365 en un inquilino compartido de propiedad y operado por una agencia externa. Esta agencia actúa como proveedor de servicios compartidos para Microsoft 365. Es posible que la organización no administre ni controle el inquilino compartido, pero contiene las identidades de Microsoft Entra con licencia que probablemente utilicen los usuarios para Office 365 y otras aplicaciones. En este escenario, el inquilino del proveedor de servicios compartidos es el inquilino principal.
Identifique todos los inquilinos secundarios (si es multiinquilino). Todos los demás inquilinos que administra la organización son inquilinos secundarios. Es posible que tenga inquilinos secundarios si ha migrado aplicaciones a la nube antes de mantener una zona de aterrizaje de Azure a la escala empresarial. Normalmente, se usan inquilinos secundarios para administrar (4) cargas de trabajo de Azure con usuarios externos (invitados B2B) o (5) cuentas solo en la nube (consulte la figura 1).
Use el árbol de decisión. La manera más fácil de encontrar el inquilino principal consiste en considerar las licencias de identidad que tiene en Microsoft Entra ID.
El inquilino con las licencias de Microsoft 365 es el inquilino principal (consulte la figura 2). Es posible que el inquilino principal no sea el primer inquilino creado por tu organización, pero debe ser el inquilino principal con todos los usuarios y licencias de Microsoft 365.
Si en la organización no se usa Microsoft 365, cualquier inquilino de Microsoft Entra con licencias de Enterprise Mobility + Security (EMS) es el inquilino principal. Este inquilino es donde ha agregado y comprobado el nombre de dominio de la organización. El inquilino suele usar la identidad híbrida o se integra con un sistema de recursos humanos (HR) (consulte la figura 2).
Ilustración 2. Un árbol de decisión para determinar el inquilino principal y el inquilino secundario de Microsoft Entra.
Para establecer Microsoft Entra ID como plataforma de confianza cero, necesita un inquilino poblado con las identidades de usuario y con licencia para directivas de acceso basadas en usuarios y dispositivos. Las licencias de Microsoft 365 agrupan estas funcionalidades de confianza cero con Office 365. Si no usa Microsoft 365, considere la posibilidad de Enterprise Mobility + Security E5 para establecer un proveedor de identidades basado en la nube para una confianza cero. Para obtener más información, consulte Elegir su autoridad de identidad.
Configuración de confianza cero
Al administrar identidades en Microsoft Entra ID, debe tener en cuenta las siguientes recomendaciones para cada tipo de inquilino. Hay recomendaciones generales para todos los tipos de inquilino que debe adoptar primero. Después de implementar esas recomendaciones generales, busque las recomendaciones para el tipo de inquilino específico (principal o secundario) y, a continuación, aplique esas recomendaciones.
Para obtener más información sobre cómo proteger los inquilinos de Microsoft Entra con confianza cero, consulte Plan de modernización rápida de confianza cero y Plan de modernización rápida de seguridad.
Todos los inquilinos
Debe implementar las siguientes recomendaciones en todos los inquilinos de Microsoft Entra.
Establecer cuentas y procedimientos de acceso de emergencia. Cree dos o más cuentas de acceso de emergencia para evitar que se bloquee el inquilino de Microsoft Entra. Debe asignar el rol de Administrador Global a estas cuentas. Las cuentas deben ser sólo en la nube. Las cuentas solo en la nube usan el dominio *.onmicrosoft.com . Para obtener más información, consulteAdministración de cuentas de acceso de emergencia en Azure AD.
Importante
Microsoft recomienda usar roles con el menor número de permisos. Esto ayuda a mejorar la seguridad de su organización. El administrador global es un rol con privilegios elevados que debe limitarse a escenarios de emergencia cuando no se puede usar un rol existente.
Proteja Microsoft Entra ID de ataques locales. Siga los procedimientos recomendados descritos en Protección del acceso con privilegios. Asigne permisos de Microsoft Entra únicamente a cuentas de usuario en la nube con credenciales resistentes a la suplantación de identidad, como la clave de paso de hardware o la autenticación basada en certificados. No use identidades federadas con fines administrativos. Para más información, consulte laProtección de Microsoft 365 contra ataques locales.
Usa Privileged Identity Management. Use Privileged Identity Management (PIM) de Microsoft Entra a fin de administrar las asignaciones de roles para Microsoft Entra y los roles de Azure. También debe utilizar PIM para administrar la pertenencia a grupos elegibles para grupos de seguridad privilegiados. Establecer revisiones de acceso periódicas para administradores elegibles y usuarios externos (invitados B2B).
Habilite la autenticación basada en la nube para todos los usuarios. Los métodos de autenticación basados en la nube son más seguros que la autenticación federada. Ofrecen una mejor experiencia de inicio de sesión único cuando se combinan con dispositivos unidos a Microsoft Entra. La autenticación federada expone Microsoft Entra ID a riesgos de Active Directory local.
La autenticación basada en certificados de Microsoft Entra (CBA) hace innecesaria la federación de dominios de Microsoft Entra. La autenticación de Microsoft Entra admite los siguientesmétodos de autenticación sin contraseña:
- Llaves de acceso (Clave de seguridad FIDO2)
- Autenticación basada en certificado
- Microsoft Authenticator
- Windows Hello para empresas
Establecer políticas de acceso condicional de línea de base. La línea base de acceso condicional varía según la organización y los requisitos. Establezca un conjunto básico de directivas de acceso condicional para todos los inquilinos de Microsoft Entra. Usa las condiciones de identidad, dispositivo, aplicación y riesgo dentro del conjunto de directivas. Excluya las cuentas de acceso de emergencia de las directivas de acceso condicional.
Protección de id. de Microsoft Entra ayuda a las organizaciones a detectar, investigar y corregir los riesgos relacionados con las identidades. Para proteger los inicios de sesión y los usuarios de riesgo, cree directivas de acceso condicional con condiciones de riesgo. Use directivas independientes para usuarios de riesgo e inicios de sesión de riesgo. Aumente los controles aplicados con nivel de riesgo para cada tipo de riesgo. Para equilibrar la productividad del usuario con seguridad, evite usar el control Bloquear en directivas basadas en riesgos.
Nota:
Los usuarios pueden corregir automáticamente los riesgos de inicio de sesión con MFA. Para permitir que los usuarios corrijan automáticamente el riesgo de inicio de sesión, configure MFA o control de concesión de seguridad de autenticación en una directiva de acceso condicional basada en riesgos de inicio de sesión.
Los usuarios pueden corregir automáticamente los riesgos del usuario cambiando sus contraseñas. Para permitir que los usuarios corrijan automáticamente el riesgo del usuario, configure una directiva de acceso condicional basada en riesgos de usuario con el control de concesión Requerir cambio de contraseña.
Precaución
Los usuarios sin contraseña que solo inician sesión con métodos sin contraseña, como la autenticación basada en certificados, la llave de acceso o la Windows Hello para empresas, podrían bloquearse mediante el control de concesión Requerir cambio de contraseña si no pueden restablecer su contraseña en Microsoft Entra ID.
Diseñe directivas de acceso condicional para su organización mediante la lista de comprobación de la directiva de acceso condicional de muestra (consulte la tabla 2). Use el modo de solo informe para probar las directivas de acceso condicional antes de implementarlas en la producción.
Tabla 2: Lista de comprobación de la directiva de acceso condicional de muestra.
| Nombre de la directiva | Usuarios | Aplicaciones | Condiciones | Conceder control |
|---|---|---|---|---|
| MFA para todos los usuarios | Todos los usuarios | Todas las aplicaciones | None | - MFA resistente a la suplantación de identidad |
| Requerir dispositivos administrados | Todos los usuarios | Todas las aplicaciones | Ninguno | - Exigencia de un dispositivo híbrido unido a Microsoft Entra o compatible |
| Protección de inicios de sesión de riesgo medio | Todos los usuarios | Todas las aplicaciones | Riesgo de inicio de sesión medio | - MFA resistente a la suplantación de identidad - Requerir dispositivo compatible - Frecuencia de inicio de sesión: 1 hora (ajuste según la tolerancia al riesgo de su organización) |
| Protección de inicios de sesión de alto riesgo | Todos los usuarios | Todas las aplicaciones | Alto riesgo de inicio de sesión | - MFA resistente a la suplantación de identidad - Requerir dispositivo compatible - Frecuencia de inicio de sesión: cada vez |
| Protección de usuarios de alto riesgo | Todos los usuarios | Todas las aplicaciones | Riesgo de usuario alto | - MFA resistente a la suplantación de identidad - Requerir dispositivo compatible - Frecuencia de inicio de sesión: cada vez |
| Protección de la administración de Microsoft Entra | Roles de Microsoft Entra | Todas las aplicaciones | None | - MFA resistente a la suplantación de identidad - Require de estación de trabajo con acceso privilegiado (PAW) conforme mediante filtros de dispositivo |
| Administración segura en la nube | Todos los usuarios | Administración de Azure Google Cloud Platform Amazon Web Services |
None | - MFA resistente a la suplantación de identidad - Require de estación de trabajo con acceso privilegiado (PAW) conforme mediante filtros de dispositivo |
La directiva de muestra establecida en la tabla 2 es para organizaciones sin contraseña en las que todos los usuarios solo utilizan MFA resistente a la suplantación de identidad desde dispositivos administrados. Los usuarios con privilegios utilizan estaciones de trabajo de acceso con privilegios (PAW) administradas por Intune. En lugar de requerir un cambio de contraseña para los usuarios de alto riesgo, la directiva de usuario de riesgo aplica la seguridad de autenticación y los controles de frecuencia de inicio de sesión. Estos controles ofrecen algunas protecciones, pero no corrigen el nivel de riesgo del usuario en Protección de id. de Microsoft Entra. El equipo de operaciones de seguridad debe investigar y corregir a los usuarios de alto riesgo.
Para obtener más información sobre la implementación del acceso condicional, consulte Planificar una implementación de acceso condicional.
Utilice identidades de inquilino principales para acceder a todas las aplicaciones. Los usuarios deben poder acceder a las aplicaciones utilizando su identidad en el inquilino principal. Debe registrar aplicaciones en el inquilino principal. Establezca una directiva para registrar aplicaciones con el inquilino principal, independientemente de la ubicación de hospedaje de la infraestructura de aplicaciones.
En el caso de las aplicaciones heredadas que no admiten protocolos de autenticación modernos, use el servicio de proxy de aplicación de Microsoft Entra en el inquilino principal. El proxy de aplicación de Microsoft Entra aporta características de confianza cero de Microsoft Entra a las aplicaciones heredadas existentes sin cambios en el código.
Cuando un proveedor de servicios compartidos o una agencia externa controla el inquilino principal, deben delegar los permisos de registro de aplicaciones. Si el proveedor de servicios no ofrece esta delegación, debe registrar las aplicaciones con el inquilino secundario que controla la organización en su lugar. Sin embargo, los usuarios deben seguir accediendo a estas aplicaciones sin crear una nueva identidad en el inquilino secundario. Para esta configuración, asigne acceso de usuario mediante identidades externas (invitados B2B) para los usuarios del inquilino principal. Para más información, consulte Aplicaciones seguras con confianza cero.
Use Microsoft Entra ID para administrar otros entornos en la nube. Microsoft Entra ID no es solo una plataforma de identidad para Azure y Microsoft 365. Use Microsoft Entra ID para acceder a otros entornos en la nube. Estos entornos incluyen productos populares de software como servicio (SaaS) y plataformas en la nube como Amazon Web Services (AWS) y Google Cloud Platform (GCP). Para más información, vea Galería de aplicaciones de Microsoft Entra.
Utilizar una arquitectura de informática en la nube segura (SCCA). Cada organización de defensa debe implementar una arquitectura de zona de aterrizaje compatible a la SCCA. La zona de aterrizaje debe estar en las suscripciones Azure adjuntas al inquilino principal.
Segmente la administración de recursos de Azure en un único inquilino. Debes usar roles de Azure para el aislamiento de recursos y administración de las suscripciones dentro de una zona de aterrizaje de Azure a escala empresarial. Considere la posibilidad de transferir las suscripciones de los inquilinos secundarios al inquilino principal.
Use Administración de permisos de Microsoft Entra. Administración de permisos de Microsoft Entra es la solución de administración de derechos de infraestructura en la nube (CIEM) de Microsoft. Debe usar Administración de permisos de Microsoft Entra para ver los permisos asignados a todas las identidades. También debe usarlo para realizar un seguimiento de los permisos en el entorno multi-nube de la organización.
Use Gobierno de id. de Microsoft Entra. Utilice Gobierno de id. de Microsoft Entra para automatizar el ciclo de vida de la asignación de acceso para usuarios e invitados. Realice revisiones de acceso para quitar el acceso al entorno en la nube para los usuarios que ya no lo necesiten.
Protección de identidades de carga de trabajo. Utilice las características de Id. de carga de trabajo de Microsoft Entra para administrar y aplicar directivas adaptativas de confianza cero para identidades de aplicación (entidades de servicios) en Microsoft Entra ID.
Habilite Defender for Cloud para su empresa. UtiliceDefender for Cloud para su entorno multi-nube. Asegúrese de activar las características de seguridad mejoradas para supervisar los recursos de Azure y corregir el riesgo de configuración. La protección de Defender for Cloud se extiende más allá de Azure para ayudarle a proteger entornos híbridos y multicloud.
Implemente Sentinel y conecte todas las fuentes de datos disponibles. Agrega los datos de señales de seguridad en un SIEM como Microsoft Sentinel. Implemente Sentinel y conecte todos los orígenes de datos de señales de seguridad configurando conectores de datos.
Inquilinos principales
Debería aplicar las siguientes recomendaciones únicamente en el inquilino principal.
Los usuarios finales solo tienen una identidad en Entra ID. Sincronice instancias locales de Active Directory Domain Services con el inquilino principal de Microsoft Entra. La sincronización rellena Microsoft Entra ID con usuarios, grupos y dispositivos para la organización. Los invitados B2B externos pueden existir en inquilinos secundarios, pero los usuarios sólo necesitan recordar un nombre de usuario para todas las aplicaciones y servicios. La experiencia del usuario y los resultados de confianza cero son mejores cuando se utilizan las identidades del inquilino principal para el inicio de sesión en Windows y el acceso a las aplicaciones.
Unir y administrar dispositivos con el inquilino principal. El inquilino principal de Microsoft Entra contiene todos los usuarios y dispositivos de la organización. Dispositivos Windows unidos a Microsoft Entra (o unión híbrida a Microsoft Entra) al inquilino principal y administración con Microsoft Intune. Utilice la política de Intune para implementar Microsoft Defender para punto de conexión y habilitar la capacidad de detección y respuesta ampliada (XDR).
Delegar permisos de registro de aplicaciones. Las aplicaciones empresariales, incluido el código de aplicación que se ejecuta en cualquier suscripción de Azure, usan el inquilino principal de Microsoft Entra ID para la identidad del usuario. Haga que los desarrolladores puedan optar al rol de desarrollador de aplicaciones de Microsoft Entra o a un rol de registro de aplicaciones personalizadas mediante Privileged Identity Management. Esta configuración permite a los desarrolladores que crean aplicaciones en inquilinos secundarios registrarlas en el inquilino principal para obtener identidades.
Adjunte servicios de plataforma como servicio (PaaS) que necesiten la identidad del usuario final. Algunos servicios PaaS, como Azure Files y Azure Virtual Desktop , dependen de la configuración de identidades híbridas o derechos de licencia. Debe implementar estos servicios en las suscripciones de Azure en el inquilino principal.
Inquilinos secundarios
Debería implementar las siguientes recomendaciones únicamente en el inquilino secundario.
Adquiera licencias necesarias para la administración de Microsoft Entra. Necesita licencias para activar las características de seguridad avanzadas en los inquilinos secundarios. Tenga en cuenta las licencias que necesita para usuarios, cargas de trabajo y dispositivos.
Identidades de usuarios. Debe tener licencias de Microsoft Entra ID Premium P2 para administradores de inquilinos y cuentas de acceso de emergencia. Si usa un modelo de administración de identidad externa (invitado B2B), debe asignar al menos una licencia de Microsoft Entra ID Premium P2 a un usuario local del inquilino. Esta configuración le permite habilitar características premium, como el acceso condicional y identity Protection. Para obtener más información, consulta Consideraciones comunes para la administración de usuarios multiinquilino.
Identidades de cargas de trabajo. Debe usar identidades de carga de trabajo Premium para proteger las identidades de carga de trabajo con acceso a los recursos del inquilino principal, como la API de MS Graph.
Administración de dispositivos. Es posible que necesites para administrar dispositivos con Microsoft Intune en el inquilino secundario. Si es así, debe adquirir licencias de Enterprise Mobility and Security (EMS).
Configurar políticas de acceso entre inquilinos (XTAP). La configuración de acceso entre inquilinos de la Id. externa de Microsoft Entra (Microsoft Entra colaboración B2B) permite que un inquilino secundario confíe en determinadas notificaciones del inquilino principal de origen. Agregue el inquilino principal de Microsoft Entra como organización y actualice la configuración de confianza de entrada para incluir lo siguiente:
- Autenticación multifactor (MFA) de los inquilinos de Microsoft Entra
- Dispositivos de confianza
- Dispositivos híbridos unidos a Microsoft Entra de confianza
- Opcional: Canjear invitaciones automáticamente con el inquilino
Administre el inquilino secundario con identidades del inquilino principal. Reduzca la sobrecarga administrativa y los costes utilizando usuarios externos (invitados B2B) del inquilino principal para gestionar el inquilino secundario y los recursos de Azure. Asigne roles de Microsoft Entra que cumplan elrol de Microsoft Entra con privilegios mínimos por tarea mediante Privileged Identity Management de Microsoft Entra. Utilice el acceso iniciado por el usuario final o la sincronización entre inquilinos para reducir la sobrecarga de gestión al incorporar identidades externas en el inquilino secundario.
Use Azure Lighthouse para facilitar el acceso de Sentinel desde el inquilino principal. Azure Lighthouse ofrece otra manera de administrar Azure entre inquilinos. Azure Lighthouse usa plantillas de Azure Resource Manager (ARM) para asignar roles de Azure a identidades en un inquilino externo. Este enfoque no usa objetos de usuario invitado B2B. Cuando un administrador inicia sesión en el portal para administrar Azure, ve todos los recursos en todos los inquilinos. Esta vista consolidada incluye suscripciones con permisos asignados por Azure Lighthouse. Dado que no hay ningún objeto invitado B2B, el administrador no necesita cambiar de directorio. Use Azure Lighthouse para facilitar la administración de Microsoft Sentinel entre inquilinos.