Compartir a través de

Introducción a la administración delegada y los entornos aislados

  • Artículo

Una arquitectura de inquilino único de Microsoft Entra con administración delegada suele ser adecuada para separar entornos. Como se detalla en otras secciones de este artículo, Microsoft proporciona muchas herramientas para hacerlo. Sin embargo, puede haber ocasiones en las que su organización requiera un grado de aislamiento más allá de lo que se puede lograr en un único inquilino.

Antes de analizar arquitecturas específicas, es importante comprender lo siguiente:

  • Funcionamiento de un único inquilino típico.

  • Funcionamiento de las unidades administrativas en Microsoft Entra ID.

  • Las relaciones entre los recursos de Azure y los inquilinos de Microsoft Entra.

  • Requisitos comunes que impulsan el aislamiento.

Inquilino de Microsoft Entra como límite de seguridad

Un inquilino de Microsoft Entra proporciona funcionalidades de administración de identidades y acceso (IAM) a las aplicaciones y recursos que usa la organización.

Una identidad es un objeto de directorio que se puede autenticar y autorizar para el acceso a un recurso. Existen objetos de identidad para identidades humanas e identidades no humanas. Las identidades humanas se conocen como identidades y las identidades no humanas como identidades de carga de trabajo. Las entidades no humanas incluyen objetos de aplicación, entidades de servicio, identidades administradas y dispositivos. La terminología puede variar en el sector, pero una identidad de carga de trabajo suele ser algo que se necesita para que la entidad de software se autentique con algún sistema.

Para distinguir entre las identidades humanas y las no humanas, están apareciendo términos diferentes en el sector de TI para distinguirlos:

  • Identidad: identidad iniciada mediante la descripción de Active Directory (AD) y el objeto de Microsoft Entra que usan los seres humanos para autenticarse. En esta serie de artículos, la identidad hace referencia a objetos que representan a los seres humanos.

  • Identidad de carga de trabajo: en Microsoft Entra ID, las identidades de carga de trabajo son aplicaciones, entidades de servicio e identidades administradas. La identidad de la carga de trabajo se usa para autenticar y acceder a otros servicios y recursos.

Para más información sobre las identidades de carga de trabajo, consulte ¿Qué son las identidades de carga de trabajo?

El inquilino de Microsoft Entra es un límite de seguridad de identidad que está bajo el control de los administradores. Dentro de este límite de seguridad, la administración de suscripciones, grupos de administración y grupos de recursos se puede delegar para segmentar el control administrativo de los recursos de Azure. Aunque no interactúa directamente, estas agrupaciones dependen de las configuraciones de políticas y valores de todo el inquilino. Esas opciones y configuraciones están bajo el control de los administradores globales de Microsoft Entra.

Microsoft Entra ID se usa para otorgar acceso a objetos que representan identidades a aplicaciones y recursos de Azure. En ese sentido, tanto los recursos de Azure como las aplicaciones que confían en Microsoft Entra ID son recursos que se pueden administrar con Microsoft Entra ID. En el diagrama siguiente, el límite del inquilino de Microsoft Entra ID muestra los objetos de identidad de Microsoft Entra ID y las herramientas de configuración. Debajo del directorio se muestran los recursos que usan los objetos de identidad para la administración de identidades y acceso. Siguiendo los procedimientos recomendados, el entorno se configura con un entorno de prueba para probar el funcionamiento adecuado de IAM.

Diagrama que muestra los límites del inquilino de Microsoft Entra.

Acceso a aplicaciones que usan Microsoft Entra ID

A las identidades se les puede conceder acceso a muchos tipos de aplicaciones. Algunos ejemplos son:

  • Servicios de productividad de Microsoft, como Exchange Online, Microsoft Teams y SharePoint Online

  • Servicios de TI de Microsoft, como Azure Sentinel, Microsoft Intune y ATP de Microsoft 365 Defender

  • Herramientas de desarrollador de Microsoft como Azure DevOps y Microsoft Graph API

  • Soluciones SaaS como Salesforce y ServiceNow

  • Aplicaciones locales integradas con capacidades de acceso híbrido como el proxy de aplicación de Microsoft Entra

  • Aplicaciones personalizadas desarrolladas internamente

Las aplicaciones que usan Microsoft Entra ID requieren que los objetos de directorio se configuren y administren en el inquilino de Microsoft Entra ID de confianza. Los registros de aplicaciones, las entidades de servicio, los grupos y las extensiones de atributo de esquema con algunos ejemplos de objetos de directorio.

Acceso a los recursos de Azure

A los usuarios, grupos y objetos de entidad de servicio (identidades de carga de trabajo) del inquilino de Microsoft Entra se les conceden roles mediante Control de acceso basado en rol (RBAC) de Azure y Control de acceso basado en atributos (ABAC) de Azure.

  • Azure RBAC permite proporcionar acceso basado en el rol determinado por la entidad de seguridad, la definición de roles y el ámbito.

  • Azure ABAC se basa en Azure RBAC con la adición de condiciones de asignación de roles basadas en atributos en el contexto de acciones específicas. Una condición de asignación de roles es otra comprobación que puede agregar opcionalmente a la asignación de roles para proporcionar un control de acceso más preciso.

Se accede a los recursos, grupos de recursos, suscripciones y grupos de administración de Azure mediante estos roles de RBAC asignados. Por ejemplo, en el diagrama siguiente se muestra la distribución de la funcionalidad administrativa en Microsoft Entra ID mediante el control de acceso basado en rol.

Diagrama que muestra la jerarquía de roles de Microsoft Entra.

Los recursos de Azure que admiten identidades administradas permiten que los recursos se autentiquen, se les otorgue acceso y se les asigne roles a otros recursos dentro del límite del inquilino de Microsoft Entra.

Las aplicaciones que usan Microsoft Entra ID para el inicio de sesión también pueden usar recursos de Azure como proceso o almacenamiento como parte de su implementación. Por ejemplo, una aplicación personalizada que se ejecuta en Azure y confía en Microsoft Entra ID para la autenticación, tiene objetos de directorio y recursos de Azure.

Por último, todos los recursos de Azure del inquilino de Microsoft Entra afectan a los límites y cuotas de Azure para todo el inquilino.

Acceso a objetos de directorio

Como se describe en el diagrama anterior, las identidades, los recursos y sus relaciones se representan en un inquilino de Microsoft Entra como objetos de directorio. Usuarios, grupos, entidades de servicio y registros de aplicaciones son algunos ejemplos de objetos de directorio.

Tener un conjunto de objetos de directorio en el límite del inquilino de Microsoft Entra genera las siguientes funcionalidades:

  • Visibilidad. Las identidades pueden detectar o enumerar recursos, usuarios, grupos, informes de uso de acceso y registros de auditoría en función de sus permisos. Por ejemplo, un miembro del directorio puede detectar usuarios en el directorio según los permisos de usuario predeterminados de Microsoft Entra ID.

  • Las aplicaciones pueden afectar a objetos. Las aplicaciones pueden manipular objetos de directorio a través de Microsoft Graph como parte de su lógica de negocios. Entre los ejemplos típicos se incluyen los atributos de usuario de lectura y configuración, la actualización del calendario del usuario, el envío de correos electrónicos en nombre del usuario, etc. El consentimiento es necesario para permitir que las aplicaciones afecten al inquilino. Los administradores pueden dar su consentimiento a todos los usuarios. Para obtener más información, consulte Permisos y consentimiento en la Plataforma de identidad de Microsoft.

Nota:

Tenga cuidado al usar permisos de aplicación. Por ejemplo, con Exchange Online, debe definir el ámbito de los permisos de aplicación a buzones y permisos específicos.

  • Limitación y límites de servicio. El comportamiento del entorno de ejecución de un recurso podría desencadenar la limitación con el fin de evitar el uso excesivo o la degradación del servicio. La limitación puede producirse en el nivel de aplicación, inquilino o servicio completo. Suele producirse cuando una aplicación tiene un gran número de solicitudes dentro o entre inquilinos. Del mismo modo, hay límites y restricciones de servicio de Microsoft Entra que podrían afectar al comportamiento del entorno de ejecución de las aplicaciones.

Unidades administrativas para la administración de roles

Las unidades administrativas restringen los permisos de un rol a cualquier parte de la organización que defina. Por ejemplo, podría usar unidades administrativas para delegar el rol Administrador del departamento de soporte técnico a los especialistas de soporte técnico regionales, para que solo puedan administrar los usuarios de la región en cuestión. Una unidad administrativa es un recurso de Microsoft Entra que puede ser un contenedor para otros recursos de Microsoft Entra. Una unidad administrativa solo puede contener:

  • Usuarios

  • Grupos

  • Dispositivos

En el diagrama siguiente, las unidades administrativas se usan para segmentar aún más el inquilino de Microsoft Entra en función de la estructura empresarial o organizativa. Esto resulta útil cuando diferentes unidades de negocio o grupos tienen personal de soporte técnico de TI dedicado. Las unidades administrativas se pueden usar para proporcionar permisos con privilegios limitados a una unidad administrativa designada.

Diagrama que muestra unidades administrativas de Microsoft Entra.

Para más información sobre las unidades administrativas, consulte Unidades administrativas en Microsoft Entra ID .

Motivos comunes para el aislamiento de recursos

A veces, un grupo de recursos debe aislarse de otros recursos por motivos de seguridad u otros motivos, como que los recursos tienen requisitos de acceso únicos. Este es un buen caso de uso para usar unidades administrativas. Debe determinar qué usuarios y entidades de seguridad deben tener acceso a los recursos y en qué roles. Los motivos para aislar los recursos pueden ser:

  • Los equipos de desarrolladores necesitan la flexibilidad para iterar de forma segura durante el ciclo de vida de desarrollo de software de las aplicaciones. Pero el desarrollo y las pruebas de aplicaciones que escriben en Microsoft Entra ID pueden afectar potencialmente al inquilino de Microsoft Entra mediante operaciones de escritura. Algunos ejemplos de esto son:

    • Nuevas aplicaciones que pueden cambiar el contenido de Office 365, como sitios de SharePoint, OneDrive, MS Teams, etc.

    • Aplicaciones personalizadas que pueden cambiar los datos de los usuarios con MS Graph o API similares a escala (por ejemplo, aplicaciones a las que se concede Directory.ReadWrite.All)

    • Scripts de DevOps que actualizan grandes conjuntos de objetos como parte de un ciclo de vida de implementación.

    • Los desarrolladores de aplicaciones integradas de Microsoft Entra necesitan la capacidad de crear objetos de usuario para pruebas. Esos objetos de usuario no deben tener acceso a los recursos de producción.

  • Recursos y aplicaciones de Azure que no son de producción que pueden afectar a otros recursos. Por ejemplo, es posible que una nueva versión beta de una aplicación SaaS deba aislarse de la instancia de producción de los objetos de usuario de producción y de la aplicación

  • Recursos secretos que deben protegerse de la detección, enumeración o adquisición de los administradores existentes por motivos normativos o críticos para la empresa.

Configuración en un inquilino

Las opciones de configuración de Microsoft Entra ID pueden afectar a cualquier recurso del inquilino de Microsoft Entra a través de acciones de administración dirigidas o para todo el inquilino. Entre los ejemplos de configuración para todo el inquilino se incluye:

  • Identidades externas: los administradores identifican y controlan las identidades externas que se pueden aprovisionar en el inquilino.

    • Si se permiten identidades externas en el inquilino.

    • Desde qué dominios se pueden agregar identidades externas.

    • Si los usuarios pueden invitar a usuarios de otros inquilinos.

  • Ubicaciones con nombre: los administradores pueden crear ubicaciones con nombre, que se pueden usar para

    • Bloquear los inicios de sesión desde ubicaciones concretas.

    • Desencadenar directivas de acceso condicional, como MFA.

    • Requisitos de seguridad de Bypass

  • Opciones de autoservicio. Los administradores establecen opciones de autoservicio, como el autoservicio de restablecimiento de contraseña, y crean grupos de Microsoft 365 en el nivel de inquilino.

La implementación de algunas configuraciones para todo el inquilino se puede limitar, siempre que no se invaliden mediante directivas globales. Por ejemplo:

  • Si el inquilino está configurado para permitir identidades externas, un administrador de recursos puede impedir que esas identidades accedan a un recurso.

  • Si el inquilino está configurado para permitir el registro de dispositivos personales, un administrador de recursos puede impedir que esos dispositivos accedan a recursos específicos.

  • Si se configuran ubicaciones con nombre, un administrador de recursos puede configurar directivas que permitan o impidan el acceso desde esas ubicaciones.

Motivos comunes para el aislamiento de configuración

Las configuraciones, controladas por los administradores, afectan a los recursos. Aunque algunas configuraciones de todo el inquilino se pueden limitar con directivas para que no se apliquen o se apliquen parcialmente a un recurso específico, otras no. Si un recurso tiene necesidades de configuración únicas, aíslelo en un inquilino independiente. Algunos ejemplos de escenarios de aislamiento de configuración son:

  • Recursos que tienen requisitos que entran en conflicto con las posturas de colaboración o seguridad existentes en todo el inquilino. (por ejemplo, los tipos de autenticación permitidos, las directivas de administración de dispositivos, la capacidad de autoservicio, la corrección de identidades para identidades externas, etc.).

  • Requisitos de cumplimiento que abarcan la certificación a todo el entorno, incluidos todos los recursos y el propio inquilino de Microsoft Entra, especialmente cuando esos requisitos entran en conflicto con otros recursos de la organización o deben excluirlos.

  • Requisitos de acceso de usuarios externos que entran en conflicto con las directivas de recursos confidenciales o de producción.

  • Organizaciones que abarcan varios países o regiones, y empresas hospedadas en un único inquilino de Microsoft Entra. Por ejemplo, qué configuración y licencias se usan en diferentes países o regiones, o subsidiarias comerciales.

Administración en un inquilino

Las identidades con roles con privilegios en el inquilino de Microsoft Entra tienen la visibilidad y los permisos para ejecutar las tareas de configuración descritas en las secciones anteriores. La administración incluye la administración de objetos de identidad, como usuarios, grupos y dispositivos, y la implementación con ámbito de las configuraciones de todo el inquilino para la autenticación, la autorización, etc.

Administración de objetos de directorio

Los administradores administran cómo pueden acceder a los recursos los objetos de identidad y en qué circunstancias. También pueden deshabilitar, eliminar o modificar objetos de directorio en función de sus privilegios. Los objetos de identidad incluyen:

  • Identidades organizativas, como las siguientes, que se representan mediante objetos de usuario:

    • Administradores

    • Usuarios de organización

    • Desarrolladores de la organización

    • Cuentas de servicio

    • Usuarios de prueba

  • Identidades externas que representan a los usuarios de fuera de la organización, como:

    • Asociados o proveedores que se aprovisionan con cuentas locales en el entorno de la organización

    • Asociados o proveedores que se aprovisionan a través de la colaboración B2B de Azure

  • Grupos que se representan mediante objetos como:

  • Dispositivos que se representan mediante objetos como:

    • Dispositivos unidos a Microsoft Entra híbrido (equipos locales sincronizados desde Active Directory local)

    • Dispositivos unidos a Microsoft Entra

    • Los dispositivos móviles registrados de Microsoft Entra que usan los empleados para acceder a sus aplicaciones de área de trabajo.

    • Dispositivos registrados de nivel inferior de Microsoft Entra (heredados). Por ejemplo, Windows 2012 R2.

  • Identidades de cargas de trabajo

    • Identidades administradas

    • Entidades de servicio

    • APLICACIONES

En un entorno híbrido, las identidades se sincronizan normalmente desde el entorno de Active Directory local mediante Microsoft Entra Connect.

Administración de servicios de identidad

Los administradores con permisos adecuados también pueden administrar cómo se implementan las directivas de todo el inquilino en el nivel de grupos de recursos, grupos de seguridad o aplicaciones. Al considerar la administración de recursos, tenga en cuenta lo siguiente. Cada uno puede ser una razón para mantener los recursos juntos o para aislarlos.

  • Un administrador global puede tomar el control de cualquier suscripción de Azure vinculada al inquilino.

  • Una identidad asignada a un rol de administrador de autenticación puede requerir que quienes no son administradores se vuelvan a registrar para la autenticación de MFA o FIDO.

  • Un administrador de acceso condicional puede crear directivas de acceso condicional que requieran que los usuarios inicien sesión en aplicaciones específicas para hacerlo solo desde dispositivos propiedad de la organización. También pueden establecer el ámbito de las configuraciones. Por ejemplo, incluso si se permiten identidades externas en el inquilino, pueden excluir esas identidades de acceder a un recurso.

  • Un administrador de aplicaciones en la nube puede dar su consentimiento a los permisos de aplicación en nombre de todos los usuarios.

Motivos comunes para el aislamiento administrativo

¿Quién debe tener la capacidad de administrar el entorno y sus recursos? Hay ocasiones en las que los administradores de un entorno no deben tener acceso a otro entorno. Algunos ejemplos son:

  • Separación de responsabilidades administrativas en todo el inquilino para mitigar aún más el riesgo de errores operativos y de seguridad que afectan a los recursos críticos.

  • Normativas que restringen a quién puede administrar el entorno en función de condiciones como la ciudadanía, la residencia, el nivel de autorización, etc. que no se puede alojar con personal.

Consideraciones operativas y de seguridad

Dada la interdependencia entre un inquilino de Microsoft Entra y sus recursos, es fundamental comprender la seguridad y los riesgos operativos de exposición o error. Si está trabajando en un entorno federado con cuentas sincronizadas, una vulneración local puede dar lugar a una vulneración en Microsoft Entra ID.

  • Compromiso de identidad: dentro del límite de un inquilino, se puede asignar cualquier identidad a cualquier rol, dado que el que proporciona acceso tiene privilegios suficientes. Aunque el impacto de las identidades sin privilegios vulnerables está en gran medida contenido, los administradores vulnerables pueden tener amplias implicaciones. Por ejemplo, si una cuenta de administrador global de Microsoft Entra está en riesgo, los recursos de Azure pueden estar en peligro. Para mitigar el riesgo de vulneración de identidad o actores no autorizados, implemente administración por niveles y asegúrese de seguir principios de privilegios mínimos para roles de administrador de Microsoft Entra. De forma similar, asegúrese de crear directivas de acceso condicional que excluyan específicamente las cuentas de prueba y las entidades de servicio de prueba para que no accedan a los recursos fuera de las aplicaciones de prueba. Para obtener más información sobre la estrategia de acceso con privilegios, consulte Acceso con privilegios: Estrategia.

  • Vulnerabilidad del entorno federado

  • Riesgo de los recursos de confianza: las identidades humanas no son la única consideración de seguridad. Cualquier componente en peligro del inquilino de Microsoft Entra puede afectar a los recursos de confianza en función del nivel de permisos en el nivel de inquilino y recurso. El impacto de un componente en peligro de un recurso de confianza de Microsoft Entra ID viene determinado por los privilegios del recurso. Los recursos que están profundamente integrados con el directorio para realizar operaciones de escritura pueden tener un impacto profundo en todo el inquilino. Las siguientes instrucciones de confianza cero pueden ayudar a limitar el impacto de la vulnerabilidad.

  • Desarrollo de aplicaciones: las fases tempranas del ciclo de vida de desarrollo para las aplicaciones con privilegios de escritura en Microsoft Entra ID, donde hay errores que pueden escribir cambios en los objetos de Microsoft Entra accidentalmente, presentan un riesgo. Siga los procedimientos recomendados de la plataforma de identidad de Microsoft durante el desarrollo para mitigar estos riesgos.

  • Error operativo: un incidente de seguridad puede producirse no solo debido a actores no autorizados, sino también a un error operativo por parte de los administradores de inquilinos o los propietarios de recursos. Estos riesgos se producen en cualquier arquitectura. Mitigue estos riesgos con separación de tareas, administración por niveles, siguiendo principios de privilegios mínimos y siguiendo procedimientos recomendados antes de intentar mitigarlos mediante un inquilino independiente.

La incorporación de principios de confianza cero en la estrategia de diseño de Microsoft Entra ID puede ayudar a guiar el diseño para mitigar estas consideraciones. Para más información, consulte Adoptar una seguridad proactiva con Confianza cero.

Pasos siguientes