Compartir a través de

Administración de identidad y acceso a la zona de aterrizaje

  • Artículo

Después de identificar la arquitectura de identidad, debe administrar la autorización y el acceso a los recursos de las zonas de aterrizaje de aplicaciones y plataformas. Tenga en cuenta los recursos a los que cada entidad de seguridad autenticada tiene y necesita acceso, y cómo mitigar el riesgo de acceso no autorizado a los recursos. Para obtener más información, consulte Diseño de arquitectura de identidades.

Información general

El área de diseño de administración de identidad y acceso proporciona instrucciones para ayudarle a implementar el modelo de acceso empresarial en Azure e implementar y proteger los planos de control. Al incorporar el principio de diseño de la democratización de la suscripción, el equipo de aplicaciones puede administrar sus propias cargas de trabajo dentro de las barreras de protección de directivas que establece el equipo de la plataforma. Este enfoque también sigue el principio de gobernanza controlado por directivas.

El equipo de la plataforma es responsable del aprovisionamiento de nuevas zonas de aterrizaje de aplicaciones o suscripciones. Cuando aprovisionan una zona de aterrizaje para un propietario de la aplicación, el equipo de la plataforma debe configurarla con los controles de acceso adecuados para que el propietario de la aplicación pueda administrar sus propios recursos. El propietario de la aplicación debe poder crear y administrar usuarios y grupos dentro Microsoft Entra ID y asignar roles a esos usuarios y grupos. Después, el propietario de la aplicación puede administrar el acceso a sus propios recursos y delegar el acceso a otros usuarios y grupos según sea necesario. La zona de aterrizaje también debe tener conectividad de red opcional para Active Directory Domain Services (AD DS) o Microsoft Entra Domain Services en la suscripción de la plataforma de identidades de Microsoft, en función de los requisitos de la aplicación.

Use controles de acceso basados en roles (RBAC) de Azure para administrar el acceso administrativo a los recursos de Azure. Considere si los usuarios necesitan permisos en un ámbito reducido, como un administrador para una sola aplicación o un ámbito amplio, como un administrador de red en varias cargas de trabajo de aplicaciones. En cualquier caso, siga el principio de acceso suficiente y asegúrese de que el usuario solo tenga los roles necesarios para sus actividades normales. Use roles personalizados y Microsoft Entra Privileged Identity Management (PIM) cuando sea necesario para aplicar el acceso Just-In-Time (JIT). Aunque el equipo de la plataforma es responsable de la base de administración de identidad y acceso, los equipos de la plataforma y aplicación son consumidores del servicio y deben seguir los mismos principios.

La administración de identidad y acceso es importante para la separación correcta de una zona de aterrizaje de otra y el aislamiento de las cargas de trabajo dentro de una organización. Es un área de diseño crítica para las zonas de aterrizaje de plataformas y aplicaciones.

Si su organización usa un proceso de venta de suscripciones, puede automatizar muchas de las configuraciones de identidad y acceso para las zonas de aterrizaje de la aplicación. Implemente la venta de suscripciones para ayudar a estandarizar la creación de zonas de aterrizaje y para que los equipos de aplicaciones puedan administrar sus propios recursos.

Consideraciones de diseño

Algunas organizaciones comparten servicios entre varias aplicaciones. Por ejemplo, podría haber un servicio de integración centralizado usado por varias aplicaciones independientes. En ese escenario, tenga en cuenta qué servicios se administran de forma centralizada y cuáles se devuelven a los equipos de aplicaciones, y conozca dónde deben aplicarse los límites de seguridad. Proporcionar a los equipos de aplicaciones acceso administrativo al servicio compartido puede resultar útil para la productividad del desarrollador, pero puede proporcionar más acceso de lo necesario.

La administración de recursos de aplicación que no cruzan los límites de seguridad se puede delegar en los equipos de la aplicación. Considere la posibilidad de delegar también otros aspectos necesarios para mantener la seguridad y el cumplimiento. Permitir a los usuarios aprovisionar recursos dentro de un entorno administrado de forma segura ofrece a las organizaciones la oportunidad de aprovechar la naturaleza ágil de la nube y evitar la infracción de cualquier límite crítico de seguridad o gobernanza.

RBAC

Importante

Los recursos clásicos y los administradores clásicos se retirarán el 31 de agosto de 2024. Quite los coadministradores que no son necesarios y use RBAC de Azure para el control de acceso detallado.

Conozca la diferencia entre los roles de Microsoft Entra ID y los roles RBAC de Azure.

  • Los Roles de Microsoft Entra ID controlan los privilegios administrativos para los servicios de todo el inquilino, como Microsoft Entra ID y otros servicios Microsoft, incluidos Microsoft Teams, Microsoft Exchange Online y Microsoft Intune.

  • Los roles RBAC de Azure controlan los privilegios administrativos en recursos de Azure, como máquinas virtuales, suscripciones y grupos de recursos.

  • Los roles de propietario y administrador de acceso de usuarios RBAC de Azure pueden modificar las asignaciones de roles en los recursos de Azure. De forma predeterminada, el rol de administrador global de Microsoft Entra no tiene permiso para administrar el acceso a los recursos de Azure. Debe habilitarse explícitamente. Para más información, consulte Elevación de los privilegios de acceso para administrar todas las suscripciones y los grupos de administración de Azure.

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.

En el diagrama siguiente se muestra la relación entre los roles de Microsoft Entra ID y los roles RBAC de Azure:

Diagrama que muestra la relación entre los roles de Microsoft Entra ID y de RBAC de Azure.

  • Puede crear grupos asignables a roles y asignar roles de Microsoft Entra a los grupos si establece la propiedad isAssignableToRole en true. Solo se protegen los grupos con este conjunto de propiedades. Los únicos roles que pueden modificar la pertenencia a un grupo son los administradores globales, los administradores de roles con privilegios o el propietario del grupo.

  • Solo algunos roles pueden restablecer la configuración de la contraseña o la autenticación multifactor (MFA) para otro administrador. Esta restricción impide que los administradores no autorizados restablezcan las credenciales de una cuenta con más privilegios para obtener más permisos.

  • Si los roles integrados de Azure no cumplen las necesidades específicas de su organización, puede crear los suyos propios. Al igual que los roles integrados, puede asignar roles personalizados a usuarios, grupos y entidades de servicio en ámbitos de inquilino, grupo de administración, suscripción y grupo de recursos. Intente utilizar los roles integrados de Azure siempre que sea posible y cree roles personalizados solo cuando sea necesario.

  • Al diseñar la estrategia de control de acceso, conozca los límites de servicio para los roles, asignaciones de roles y roles personalizados.

  • Algunos roles RBAC de Azure admiten el control de acceso basado en atributos (ABAC) o las condiciones de asignación de roles. Al usar condiciones, los administradores pueden asignar roles dinámicamente en función de los atributos del recurso. Por ejemplo, puede asignar el rol de colaborador de datos de Storage Blob, pero solo para blobs que tengan una etiqueta de índice específica en lugar de todos los blobs de un contenedor.

  • Puede usar roles basados en RBAC integrados y personalizados con permisos Microsoft.Authorization/roleAssignments/write o Microsoft.Authorization/roleAssignments/delete para crear, eliminar y modificar asignaciones de roles. Cualquier persona que tenga este rol puede decidir a quién dar permisos de escritura, lectura y eliminación en cualquier recurso del grupo de asignación. Los miembros del equipo de la zona de aterrizaje de la plataforma o aplicación deben decidir cómo delegar roles con privilegios a otros usuarios y grupos para darles la autonomía necesaria. Para garantizar el cumplimiento de los principios de acceso con privilegios mínimos, se pueden usar condiciones para delegar a los usuarios.

Recomendaciones de diseño

Recomendaciones generales

  • Aplique la autenticación multifactor (MFA) de Microsoft Entra para los usuarios que tengan derechos en el entorno de Azure, incluida la suscripción de plataforma, la suscripción de la aplicación y el inquilino de Microsoft Entra ID. Muchos marcos de cumplimiento requieren la aplicación de MFA. MFA ayuda a reducir el riesgo de robo de credenciales y acceso no autorizado. Para evitar el acceso no autorizado a información confidencial, asegúrese de incluir usuarios con roles de lector en directivas de MFA.

  • Use directivas de acceso condicional de Microsoft Entra para los usuarios que tengan derechos sobre el entorno de Azure. El acceso condicional es otra característica que ayuda a proteger un entorno de Azure controlado frente a accesos no autorizados. Los administradores de aplicaciones y plataformas deben tener directivas de acceso condicional que reflejen el perfil de riesgo de su rol. Por ejemplo, puede que tenga requisitos para llevar a cabo actividades administrativas solo desde ubicaciones o estaciones de trabajo específicas. O bien, la tolerancia al riesgo de inicio de sesión para los usuarios con acceso administrativo a los recursos de Azure podría ser menor que para los usuarios estándar de Microsoft Entra ID.

  • Habilite Microsoft Defender for Identity para ayudar a proteger las identidades y credenciales de los usuarios. Defender for Identity forma parte de Microsoft Defender XDR. Puede usar Defender for Identity para identificar actividades de usuario sospechosas y obtener escalas de tiempo de incidentes. También puede usarlo con el acceso condicional para denegar intentos de autenticación de alto riesgo. Implemente sensores de Defender for Identity en controladores de dominio locales y controladores de dominio en la suscripción de identidad de Azure.

  • Use Microsoft Sentinel para proporcionar funcionalidades de investigación e inteligencia sobre amenazas. Sentinel utiliza registros de Azure Monitor Logs, Microsoft Entra ID, Microsoft 365 y otros servicios para proporcionar detección, investigación y respuesta proactivas ante amenazas.

  • Separe el acceso administrativo del acceso cotidiano no administrativo, como la navegación web y el acceso al email. La web y el email son vectores de ataque habituales. Cuando una cuenta de usuario se ve comprometida, es menos probable que se produzca una infracción de seguridad si la cuenta no se utiliza para el acceso administrativo.

    • Utilice cuentas separadas y exclusivas de la nube para los roles con privilegios. No utilice la misma cuenta para el uso diario y para la administración con privilegios. Los roles de Microsoft Entra ID y RBAC de Azure con privilegios de marcan como CON PRIVILEGIOS en Azure Portal y en la documentación.

    • Para los roles de funciones de trabajo sin privilegios que pueden administrar recursos de aplicaciones de Azure, considere si necesita cuentas administrativas separadas o si va a utilizar Microsoft Entra PIM para controlar el acceso administrativo. PIM garantiza que la cuenta tenga los permisos necesarios solo cuando sea necesario y que los permisos se quiten cuando se complete la tarea (también conocido como acceso Just-In-Time.

  • Para que las asignaciones de roles sean más fáciles de administrar, no asigne roles directamente a los usuarios. En su lugar, asigne roles a grupos para ayudar a minimizar el número de asignaciones de roles, que tiene un límite para cada suscripción.

    • Utilice Microsoft Entra PIM para que los grupos apliquen controles de acceso administrativo Just-In-Time a los usuarios con privilegios. Considere la posibilidad de controlar la pertenencia a grupos con la administración de derechos. Puede usar la característica de administración de derechos para agregar flujos de trabajo de aprobación y auditoría a las operaciones de pertenencia a grupos y ayudar a garantizar que los miembros del grupo administrativo no se agreguen o quiten innecesariamente.

    • Cuando conceda acceso a los recursos, utilice grupos que sean solo de Microsoft Entra para los recursos de plano de control de Azure. Tanto los usuarios y grupos solo de Entra como los sincronizados desde el entorno local mediante Microsoft Entra Connect se pueden agregar a un grupo solo de Entra. Agregue grupos locales al grupo que solo sea de Microsoft Entra, si ya existe un sistema de administración de grupos. El uso de grupos solo de Entra ayuda a proteger el plano de control en la nube frente a la modificación no autorizada de los servicios de directorio locales. Tenga en cuenta que solo Microsoft Entra hace referencia a solo en la nube.

  • Cree cuentas de acceso de emergencia para evitar que se le bloquee accidentalmente de su organización de Microsoft Entra ID. Las cuentas de acceso de emergencia tienen privilegios elevados y solo se asignan a usuarios específicos. Almacene las credenciales de las cuentas de forma segura, supervise su uso y pruébelas periódicamente para asegurarse de que puede usarlas si se produce un desastre.

    Para obtener más información, consulte Prácticas de acceso seguro para administradores en Microsoft Entra ID.

Recomendaciones de Microsoft Entra ID

  • Integre Microsoft Entra ID con Azure Monitor para que pueda analizar la actividad de inicio de sesión y la pista de auditoría de los cambios dentro del inquilino. Establezca una configuración de diagnóstico para enviar registros de inicio de sesión y de auditoría al área de trabajo central de Azure Monitor Logs de la plataforma en la suscripción de administración.

  • Use la característica de administración de derechos de Microsoft Entra ID Governance para crear paquetes de acceso que controlen la pertenencia a grupos a través de procesos de aprobación automática y revisiones de acceso periódicas para los miembros del grupo con privilegios.

  • Use los roles integrados de Microsoft Entra para administrar la siguiente configuración de identidad desde un nivel de inquilino:

    Role Descripción Nota:
    Administrador global Administra todos los aspectos de Microsoft Entra ID y los servicios Microsoft que usan identidades de Microsoft Entra. No asigne más de cinco personas a este rol.
    Administrador de identidades híbridas Administra el aprovisionamiento en la nube de Active Directory a Microsoft Entra ID y también administra Microsoft Entra Connect, la autenticación transferida de Microsoft Entra, la sincronización de hash de contraseña de Microsoft Entra, el inicio de sesión único (SSO) sin problemas de Microsoft Entra y la configuración de federación.
    Administrador de seguridad Lee información e informes de seguridad y administra configuraciones en Microsoft Entra ID y Microsoft 365.
    Administrador de aplicaciones Crea y administra todos los aspectos de los registros de aplicaciones y de las aplicaciones empresariales. No puede conceder el consentimiento administrativo a todo el inquilino.

  • No asigne un rol con más privilegios a una tarea que pueda hacer un rol con menos privilegios. Por ejemplo, para administrar usuarios, asigne el rol de administrador de usuarios no el rol de administrador global. Para obtener más información, consulte Permisos de roles integrados de Microsoft Entra.

  • Use unidades administrativas para restringir un conjunto de administradores para que solo puedan administrar objetos específicos en el inquilino. Puede usar unidades administrativas para delegar la administración de un subconjunto del directorio. Por ejemplo, puede delegar la administración de un departamento de servicio en una única unidad de negocio dentro de una organización más amplia.

    Las unidades administrativas también pueden ayudar a eliminar la necesidad de separar los inquilinos de Microsoft Entra ID como límite de seguridad, donde los equipos independientes administran la plataforma de Microsoft 365 y la plataforma de Azure en la misma organización. Por ejemplo, puede usar unidades administrativas para delegar la administración de entidades de seguridad de aplicaciones de Azure al equipo de aplicaciones sin conceder privilegios en todo el inquilino de Microsoft Entra ID.

  • Use unidades administrativas de administración restringida para proporcionar mayor protección. Impida que cualquier persona que no sea un conjunto específico de administradores que usted designe modifique objetos específicos. Por ejemplo, sus directivas de separación de funciones pueden requerir que utilice esta característica para evitar que cualquier persona modifique una cuenta de usuario específica, incluso los usuarios con el rol de administrador de usuarios. Esta restricción es útil para las cuentas de servicio que utilizan las aplicaciones y que ni siquiera los administradores deberían modificar. También puede evitar la escalada de privilegios, por ejemplo, si alguien modifica una cuenta de usuario o grupo que tiene privilegios de administración de plataforma o zona de aterrizaje.

Recomendaciones de Azure RBAC

  • Para simplificar la administración y reducir el riesgo de errores de configuración, estandarice los roles y la asignación de roles en todas las zonas de aterrizaje de las aplicaciones. Por ejemplo, si tiene un rol que delega a los usuarios la administración de máquinas virtuales, utilice el mismo rol en todas las zonas de aterrizaje de aplicaciones. Este enfoque también simplifica el proceso de mover recursos entre zonas de aterrizaje.

  • Use RBAC de Azure para administrar el acceso del plano de datos a los recursos, si es posible. Algunos ejemplos de puntos de conexión del plano de datos son Azure Key Vault, una cuenta de almacenamiento o una base de datos SQL.

  • Asegúrese de que las áreas de trabajo de Azure Monitor Logs estén con el modelo de permisos adecuado. Cuando utilice un espacio de trabajo centralizado de Azure Monitor Logs, utilice permisos de recursos para garantizar que los equipos de aplicaciones tengan acceso a sus propios registros, pero no a los registros de otros equipos.

Roles integrados

  • Considere si los roles integrados se adaptan a sus necesidades. En muchos casos, puede asignar varios roles integrados a un grupo de seguridad para proporcionar el acceso adecuado a un usuario. Sin embargo, a veces no es posible utilizar roles integrados y, al mismo tiempo, cumplir con el acceso con privilegios mínimos, ya que los roles pueden incluir permisos que superan los requisitos de los usuarios. Para un control más pormenorizado, considere la posibilidad de crear un rol personalizado que refleje los permisos específicos necesarios para llevar a cabo una función de trabajo. Para más información, consulte Proporcionar autorización basada en roles.

  • Muchos roles integrados de Azure proporcionan asignaciones de roles predefinidas en el nivel de plataforma y recurso. Al combinar varias asignaciones de roles, tenga en cuenta los efectos generales.

  • El acelerador de zonas de aterrizaje de Azure incluye varios roles personalizados para funciones administrativas comunes. Puede usar estos roles junto con los roles integrados de Azure. En la tabla siguiente se describen los roles administrativos personalizados o las áreas del acelerador de zonas de aterrizaje de Azure:

    Rol administrativo o área Descripción Acciones NotActions
    Propietario de la plataforma de Azure (como, por ejemplo, el rol de propietario integrado) Administración de los grupo de administración y de los ciclos de vida de las suscripciones *
    Propietario de la suscripción Rol delegado para el propietario de la suscripción * Microsoft.Authorization/*/write, Microsoft.Network/vpnGateways/*,
    Microsoft.Network/expressRouteCircuits/*,
    Microsoft.Network/routeTables/write,
    Microsoft.Network/vpnSites/*
    Propietario de la aplicación (DevOps, operaciones de aplicaciones) Rol de colaborador para la aplicación o el equipo de operaciones en el ámbito de la suscripción * Microsoft.Authorization/*/write, Microsoft.Network/publicIPAddresses/write,
    Microsoft.Network/virtualNetworks/write,
    Microsoft.KeyVault/locations/deletedVaults/purge/action
    Administración de redes (NetOps) Administración de la conectividad global en toda la plataforma, como redes virtuales, enrutamientos definidos por el usuario, grupos de seguridad de red, dispositivos virtuales de red, VPN, Azure ExpressRoute y otros */read,
    Microsoft.Network/*,
    Microsoft.Resources/deployments/*,
    Microsoft.Support/*
    Operaciones de seguridad (SecOps) Rol de administrador de seguridad que cuenta con una vista horizontal en todo el espacio de Azure y la directiva de depuración de Key Vault */read,
    */register/action,
    Microsoft.KeyVault/locations/deletedVaults/purge/action,
    Microsoft.PolicyInsights/*,
    Microsoft.Authorization/policyAssignments/*,
    Microsoft.Authorization/policyDefinitions/*,
    Microsoft.Authorization/policyExemptions/*,
    Microsoft.Authorization/policySetDefinitions/*,
    Microsoft.Insights/alertRules/*,
    Microsoft.Resources/deployments/*,
    Microsoft.Security/*,
    Microsoft.Support/*

    Dichos roles pueden necesitar derechos adicionales en función del modelo de responsabilidad. Por ejemplo, en algunas organizaciones, es posible que un rol de NetOps solo necesite administrar y configurar la conectividad global. En otras organizaciones que necesitan un enfoque más centralizado, puede enriquecer el rol de NetOps con más acciones permitidas, como la creación de un emparejamiento entre los concentradores y sus radios.

Asignaciones de roles y grupos

  • Cuando el equipo de la plataforma aprovisiona una zona de aterrizaje de aplicación, debe asegurarse de que se creen todos los objetos de administración de identidad y acceso necesarios, como los grupos de seguridad, las asignaciones de roles estándar y las identidades administradas asignadas por el usuario.

  • Cree asignaciones de roles de zona de aterrizaje en el ámbito de la suscripción o del grupo de recursos. Las asignaciones de Azure Policy se producen en el ámbito del grupo de administración, por lo que debe aprovisionar asignaciones de roles de zona de aterrizaje en un ámbito inferior. Utilice este enfoque para garantizar que los administradores de zonas de aterrizaje tengan plena autonomía sobre sus recursos, pero no puedan modificar las asignaciones de Azure Policy que rigen su zona de aterrizaje.

  • Cada zona de aterrizaje de la aplicación debe tener sus propios grupos y asignaciones de roles. No cree grupos genéricos y los asigne a varias zonas de aterrizaje. Este enfoque puede dar lugar a errores de configuración e infracciones de seguridad, y es difícil de gestionar a gran escala. Si un usuario necesita acceder a varias zonas de aterrizaje, asígnelo a los grupos adecuados en cada zona de aterrizaje. Use ID Governance para administrar su pertenencia a grupos.

  • Asigne roles a grupos, no a usuarios. Este enfoque ayuda a garantizar que los usuarios tengan los permisos correctos cuando se unan a su organización o salgan de ella. También ayuda a garantizar que los usuarios tengan los permisos correctos cuando se mueven entre equipos. Por ejemplo, si un usuario pasa del equipo de red al equipo de seguridad, debe quitarlos del grupo de red y agregarlos al grupo de seguridad. Si asigna un rol directamente a un usuario, conservan el rol después de pasar a otro equipo. Use ID Governance para administrar la pertenencia a grupos en lugar de agregar y quitar manualmente miembros del grupo.

  • Mantenga configuraciones de seguridad independientes para distintos entornos de la misma aplicación, como desarrollo/pruebas y producción. Cree grupos y asignaciones de funciones independientes para cada entorno. No comparta identidades administradas ni entidades de servicio entre entornos. Trate cada entorno como una zona de aterrizaje independiente. Este enfoque ayuda a garantizar el aislamiento entre desarrollo/pruebas y producción, y normaliza el proceso de mover implementaciones de aplicaciones entre entornos. Si la misma persona necesita acceder a varias zonas de aterrizaje, debe asignarlas a los grupos adecuados en cada zona de aterrizaje.

  • Considere si los administradores de la plataforma necesitan permisos en las zonas de aterrizaje de las aplicaciones. Si es así, utilice Microsoft Entra PIM para controlar el acceso a esos recursos y asigne los permisos con menos privilegios necesarios. Por ejemplo, un administrador de la plataforma podría necesitar acceder a una zona de aterrizaje de una aplicación específica para solucionar un problema, pero no debería tener acceso rutinario a los datos o al código de la aplicación. En este caso, el administrador de la plataforma puede solicitar acceso a la aplicación. Un administrador de roles con privilegios aprueba la solicitud y al administrador de la plataforma se le conceden los permisos necesarios para el período de tiempo especificado. Este enfoque ayuda a aplicar la separación de funciones y protege las zonas de aterrizaje de las aplicaciones de una configuración errónea accidental o malintencionada.

  • Al delegar la responsabilidad administrativa a otros usuarios, como los equipos de aplicaciones, considere si necesitan el conjunto completo de privilegios o solo un subconjunto. Siga el principio de usar privilegios mínimos (PoLP). Por ejemplo, puede asignar el rol de administrador de acceso de usuario o el rol de administrador RBAC a un usuario que necesite gestionar el acceso a los recursos de Azure, pero no gestionar los recursos en sí. Para restringir las identidades, los tipos de identidad y los roles que los usuarios pueden delegar y asignar asignaciones de RBAC de Azure, use asignaciones de roles delegadas con condiciones. Los equipos de la aplicación pueden usan condiciones para administrar sus propias entidades de seguridad según las restricciones que establezca el equipo de la plataforma. Las asignaciones de roles con más privilegios requieren una escalada al equipo de la plataforma. Tenga en cuenta los siguientes factores al usar condiciones para delegar roles de RBAC:

    • Revise las asignaciones de roles actuales de los roles con privilegios integrados y personalizados y valore si debe agregar las condiciones correspondientes a esas asignaciones existentes. Por ejemplo, puede agregar condiciones a los roles personalizados Propietario de la suscripción y Propietario de la aplicación que ofrece el acelerador de zona de aterrizaje de Azure. Estas condiciones pueden restringir los tipos de entidad a los que puedan asignar roles o limitar roles específicos que pueden asignar.

    • Tenga en cuenta el PoLP al agregar condiciones a las asignaciones de roles. Por ejemplo, limite los delegados para asignar solo roles a grupos o permitir que los delegados asignen todos los roles excepto los roles de administrador con privilegios, como Propietario, Administrador de acceso de usuario y Administrador de RBAC.

    • Cree sus propias condiciones si las plantillas de condiciones disponibles no cumplen sus requisitos ni directivas.

      Captura de pantalla de las plantillas de condiciones para la delegación restringida de RBAC.

    • Revise las limitaciones conocidas de delegación de la administración de acceso de Azure a otros usuarios.

  • En la tabla siguiente se muestra una estructura de asignación de roles de ejemplo para un entorno de zona de aterrizaje de Azure. Proporciona un equilibrio entre la seguridad y la facilidad de administración. Puede adaptar la estructura para adaptarla a los requisitos de su organización. Puede asignar la misma persona a varios grupos, en función de su rol dentro de la organización. Pero debe aplicar las asignaciones de RBAC a un grupo específico dentro de una zona de aterrizaje específica.

    Resource Usuario Asignación de roles Destino de asignación Descripción del ámbito en Azure Policy
    Zonas de aterrizaje de la aplicación X Propietarios de la aplicación X Propietario de la aplicación (personalizado, incluido en el acelerador de zona de aterrizaje de Azure) Grupo de seguridad de la Application X Admins Suscripciones de producción y desarrollo/pruebas de la aplicación X
    Zonas de aterrizaje de la aplicación X Propietarios de la aplicación X Administrador de acceso a aplicaciones (personalizado, con condiciones de asignación de roles para administrar el acceso a su propia aplicación) Grupo de seguridad de la Application X Admins Suscripciones de producción y desarrollo/pruebas de la aplicación X
    Zonas de aterrizaje de la aplicación X Administrador de datos de la aplicación X Administrador de datos (personalizado, con permisos en los recursos de datos necesarios) Grupo de seguridad de la Application X Data Team Suscripciones de producción y desarrollo/pruebas de la aplicación X
    Zonas de aterrizaje de la aplicación Y Propietarios de la aplicación Y Propietario de la aplicación (personalizado, incluido en el acelerador de zona de aterrizaje de Azure) Grupo de seguridad de la Application Y Admins Suscripciones de producción y desarrollo/pruebas de la aplicación Y
    Zonas de aterrizaje de la aplicación Y Equipo de pruebas de la aplicación Y Colaborador de prueba (personalizado, con permisos necesarios para las pruebas de aplicaciones) Grupo de seguridad de la Application Y Test Team Suscripción de desarrollo/pruebas de la aplicación Y
    Espacio aislado Equipo de desarrollo de la aplicación Z Propietario (integrado) Grupo de seguridad de la Application Z developers Grupos de recursos de la aplicación Z en la suscripción de espacio aislado
    Recursos de la plataforma Equipo de administración de plataformas Colaborador (integrado) Platform AdminsGrupo de PIM Grupo de administración de la Platform
    Zonas de aterrizaje de la plataforma Equipo de administración de plataformas Lector (integrado) Grupo de seguridad de la Platform Team Grupo de administración de nivel superior organizativo
    Todo el inquilino Equipo de seguridad Operaciones de seguridad (personalizadas, incluidas en el acelerador de zonas de aterrizaje de Azure) Grupo de seguridad de la Security Ops Grupo de administración de nivel superior organizativo
    Todo el inquilino Equipo de seguridad Administrador de acceso condicional (integrado, con acciones protegidas habilitadas) Grupo de seguridad de la Security administrators Inquilino de Microsoft Entra ID
    Todo el inquilino Equipo de red Operaciones de red (personalizadas, incluidas en el acelerador de zonas de aterrizaje de Azure) Grupo de seguridad de la Network Ops Todas las suscripciones
    Todo el inquilino Equipo de FinOps Lector de facturación (integrado) Grupo de seguridad de la FinOps Team Grupo de administración de nivel superior organizativo

  • Para las asignaciones de Azure Policy que tienen el efecto DeployIfNotExists, se necesita una identidad administrada para subsanar los recursos que no cumplen las condiciones. Si usa una identidad administrada asignada por el sistema como parte del proceso de asignación de Azure Policy, Azure concede automáticamente los permisos necesarios. Si usa una identidad administrada asignada por el usuario, los permisos se deben conceder manualmente. Las asignaciones de roles de identidad administrada deben seguir el PoLP y habilitar solo los permisos necesarios para llevar a cabo la corrección de directivas en el ámbito de destino. Las identidades administradas de corrección de directivas no admiten definiciones de roles personalizadas. Aplique asignaciones de roles directamente a identidades administradas y no a grupos.

Recomendaciones de Microsoft Entra PIM

  • Use Microsoft Entra PIM para cumplir con el modelo de Confianza cero y el acceso con menos privilegios. Correlacione los roles de la organización a los niveles mínimos de acceso necesarios. En Microsoft Entra PIM, puede usar herramientas nativas de Azure, ampliar las herramientas y los procesos existentes o usar las herramientas existentes y nativas según sea necesario.

  • Use las revisiones de acceso Microsoft Entra PIM para validar periódicamente los derechos de recursos. Las revisiones de acceso forman parte de muchos marcos de cumplimiento, por lo que muchas organizaciones ya tienen un proceso de revisión de acceso.

  • Use identidades con privilegios para runbooks de automatización que requieran permisos de acceso elevados o para canalizaciones de implementación con privilegios. Puede usar las mismas herramientas y directivas para controlar los flujos de trabajo automatizados que acceden a los límites de seguridad críticos que se usan para controlar a los usuarios con privilegios equivalentes. Las canalizaciones de automatización e implementación para los equipos de aplicaciones deben tener asignaciones de roles que impidan que un propietario de la aplicación escale sus propios privilegios.

  • Controle los roles RBAC de Azure con privilegios elevados, como propietario o administradores de acceso de usuario asignados a miembros del equipo de la zona de aterrizaje de la plataforma o de la aplicación en una suscripción o grupo de administración. Use Microsoft Entra PIM para grupos para configurar roles RBAC de Azure para que requieran el mismo proceso de elevación que los roles de Microsoft Entra ID.

    Por ejemplo, un usuario puede necesitar habitualmente un acceso administrativo limitado a los recursos de una zona de aterrizaje de aplicaciones. En ocasiones, podrían necesitar el rol de propietario. Puede crear dos grupos de seguridad: administradores de aplicaciones y propietarios de aplicaciones. Asigne los roles con menos privilegios al grupo de administradores de aplicaciones y asigne el rol de propietario al rol de propietarios de aplicaciones. Use grupos de PIM para que el usuario pueda solicitar el rol de propietario cuando sea necesario. En el resto de ocasiones, el usuario solo tendrá los permisos necesarios para llevar a cabo sus actividades habituales.

  • Use acciones protegidas con Microsoft Entra PIM para agregar capas adicionales de protección. En Microsoft Entra ID, las acciones protegidas son permisos a los que se asignan directivas de acceso condicional. Cuando un usuario intenta realizar una acción protegida, primero debe satisfacer las directivas de acceso condicional asignadas a los permisos necesarios. Por ejemplo, para permitir que los administradores actualicen la configuración de acceso entre inquilinos, puede requerir que primero cumplan la directiva de MFA resistente a suplantación de identidad (phishing).

Administración de identidades y acceso en el acelerador de la zona de aterrizaje de Azure

La administración de identidad y acceso es una característica principal de la implementación del acelerador de la zona de aterrizaje de Azure. La implementación incluye una suscripción dedicada a la identidad, donde las organizaciones pueden implementar controladores de dominio de AD DS u otros servicios de identidad, como servidores de Microsoft Entra Connect, que son necesarios para su entorno. No todas las organizaciones requieren servicios en la suscripción. Por ejemplo, algunas organizaciones pueden tener aplicaciones que ya están totalmente integradas con Microsoft Entra ID.

La suscripción de identidad tiene una red virtual emparejada con la red virtual del concentrador en la suscripción de la plataforma. Con esta configuración, el equipo de la plataforma puede administrar la suscripción de identidad y los propietarios de aplicaciones tienen acceso a los servicios de identidad según sea necesario. Debe proteger la suscripción de identidad y la red virtual para proteger los servicios de identidad frente al acceso no autorizado.

La implementación del acelerador de zonas de aterrizaje de Azure también incluye opciones para:

  • Asignar directivas recomendadas para regular la identidad y los controladores de dominio.
  • Crear una red virtual y conectarse al centro a través del emparejamiento de red virtual.

Pasos siguientes

Administración de identidad y acceso de aplicaciones