Gestión de Identidades y accesos para Azure Landing Zones.

Desde Microsoft se ha actualizado una guía actualizada para la administración de identidades y acceso (IAM) en Azure Landing Zones. ALZ, por sus siglas en Ingles, es una parte central del marco de adopción de la nube para Azure. Está alineado con las ocho áreas de diseño de CAF , siendo la Gestión de Identidades y Accesos una de ellas. Puedes consultar la guía actualizada en: aka.ms/ALZ/IAM

Esta nueva guía actualizada lleva a IAM al centro de una implementación sólida de ALZ, que está diseñado para respaldar una estrategia de Zero Trust y se centra en el principio de privilegio mínimo para garantizar que cada administrador y usuario tenga el acceso que necesita, cuando lo necesita, a los recursos que necesita y nada más. Ningún administrador o equipo debería tener superpoderes sobre todo. El principio de privilegio mínimo protege a las personas y las cargas de trabajo, y es un factor clave para limitar el daño que puede causar un atacante o un cambio fallido.

Fundamentalmente, separamos la gestión de identidades y accesos de cada entorno y cada carga de trabajo y evitamos permisos globales o credenciales reutilizadas.

La guía actualizada incluye tres secciones/documentos:

• La identidad híbrida con Active Directory y Microsoft Entra ID consiste en comprender diferentes opciones de identidad, cómo integrar servicios de directorio locales con Microsoft Entra ID y seleccionar los protocolos y servicios adecuados para sus requisitos de autenticación y autorización.
• La identidad y el acceso a ALZ explica cómo usar RBAC (Role Bases Access Control por sus siglas en ingles) para las ALZ de plataformas y aplicaciones. Se debería automatizar tanto como sea posible y separar roles y responsabilidades entre cargas de trabajo. Utilizar el control de acceso basado en roles para garantizar que los propietarios y administradores de aplicaciones puedan gestionar sus cargas de trabajo con una mínima intervención del equipo de la plataforma, delegando tanta responsabilidad como sea posible sin introducir riesgos adicionales.
• La identidad y el acceso a la aplicación controlan cómo los componentes de la aplicación se autentican entre sí. Hay que evitar almacenar credenciales donde podrían ser descubiertas y minimizar el movimiento lateral posible en caso de que un recurso se vea comprometido.

Hay dos componentes principales:

• Microsoft Entra ID (anteriormente Azure Active Directory). Este es el servicio de directorio central alojado en la nube que proporciona autenticación y autorización para los servicios de Azure, ya sea en el plano de control o dentro de las aplicaciones. Incluye funciones administrativas para todo el tenant, como administrador global, así como servicios como gestión de identidades privilegiadas (PIM), protección de identidad y acceso condicional.

• La suscripción a la plataforma Identity aloja servicios de identidad como controladores de dominio de Active Directory o dominios administrados por Microsoft Entra Domain Services. No todas las organizaciones implementan servicios aquí, si operas completamente en la nube, es posible que no necesite servicios de IAM híbridos o heredados.

En ambos casos, el control administrativo sobre un servicio de identidad se considera una función privilegiada que debe protegerse estrechamente.

También es importante entender la diferencia existente entre los roles de Microsoft Entra ID y los roles de Azure RBAC. Si alguna vez te han asignado un rol de Administrador global Entra ID y te has sorprendido al saber que aún no puedes ver ni administrar los recursos de Azure, es porque son dos ámbitos de control de acceso separados, con roles RBAC separados. Un administrador global puede adquirir permisos de recursos de Azure, pero no los tiene automáticamente. Vamos a verlo de una forma gráfica

Los roles de Entra ID otorgan permisos para administrar recursos en todo el tenant, como usuarios, grupos y aplicaciones. Los roles de Azure RBAC otorgan permisos para realizar acciones en recursos dentro de un ámbito específico, como una suscripción, un grupo de administración, un grupo de recursos o un recurso.

Ambos roles son relevantes para las ALZ y los administradores de aplicaciones, pero de diferentes maneras. Los propietarios de aplicaciones necesitan la capacidad de administrar grupos y entidades principales de identidad de aplicaciones, así como también administrar roles de Azure RBAC en recursos dentro de su zona de aterrizaje. Esto crea un dilema, ya que otorgar permisos a los propietarios de aplicaciones individuales sobre todo el inquilino de Entra ID choca con el principio de acceso con privilegios mínimos. Esta guía actualizada que nos ofrece Microsoft recomendaciones sobre cómo administrar esto, como reducir la necesidad de principales de servicio y usar unidades administrativas de Entra ID y paquetes de acceso para delegar la administración de grupos.

Identidad híbrida con Active Directory y Microsoft Entra ID

Muchas organizaciones todavía utilizan Active Directory como su servicio de identidad principal y lo sincronizan con Microsoft Entra ID. Para estas organizaciones, implementar servicios de dominio en una suscripción de plataforma segura e independiente significa que los propietarios de aplicaciones pueden consumir los servicios de identidad necesarios (por ejemplo, máquinas virtuales unidas a un dominio) sin ser responsables de administrarlos.

Siempre que sea posible, recomendamos utilizar Microsoft Entra ID para proporcionar administración de identidad y acceso a las aplicaciones. Entra ID admite protocolos más nuevos y seguros, así como funciones de seguridad como autenticación multifactor (MFA) y acceso condicional para validar continuamente la postura de seguridad de usuarios y administradores. Si aún necesita protocolos como Kerberos, LDAP y NTLMv2, considere si debe extender un dominio existente a Azure o comenzar de nuevo con un dominio administrado mediante Microsoft Entra Domain Services .

Es necesario que se revise continuamente el estado de su entorno; con el tiempo, es posible que pueda migrar más aplicaciones a Microsoft Entra ID y dejar de utilizar servicios como Active Directory Federation Services (AD FS) o utilizar Azure Application Proxy y Global Secure Access para superponer aplicaciones heredadas con controles de seguridad modernos.

Identidad y acceso a las ALZ

La democratización de las suscripciones  permite a los equipos de aplicaciones gestionar sus propias cargas de trabajo dentro de las barreras políticas establecidas por los equipos de la plataforma. La gestión de identidades y accesos sustenta la separación de las ALZ y el aislamiento de las cargas de trabajo dentro de una organización. Como tal, es un facilitador de la escala y la seguridad que la nube puede proporcionar.

No debería haber identidades compartidas entre entornos. Si una aplicación tiene suscripciones de desarrollo, prueba y producción, cada una debe tener sus propios grupos de seguridad, asignaciones de roles e identidades administradas o entidades principales de servicio. Esto evita el movimiento lateral de un entorno de desarrollo menos seguro a un entorno de producción, además de evitar la interrupción del servicio si un cambio en un entorno de desarrollo elimina una identidad principal que se estaba utilizando en otro lugar. Asigne siempre roles a grupos en lugar de a individuos, y utilice la gestión de derechos para gestionar la membresía del grupo. Si una persona necesita acceso a varios entornos, agréguela a varios grupos en lugar de utilizar una única asignación de funciones de usuario o grupo.

En algunos casos, los roles integrados no están lo suficientemente restringidos como para cumplir con el principio de privilegio mínimo. Por ejemplo, el rol de Colaborador puede modificar cualquier cosa aparte de las asignaciones de roles, lo que podría resultar excesivo. Se pueden implementar algunas restricciones mediante Azure Policy, pero a veces una definición de rol personalizada es la mejor opción para brindar a los usuarios el acceso que necesitan. El acelerador de ALZ incluye un conjunto de roles personalizados y la guía actualizada brinda ejemplos de cuándo se pueden usar y cuándo podrían ser necesarios otros nuevos. Esto variará de una organización a otra, ya que la separación de roles y responsabilidades depende en gran medida de la estructura organizacional y de los equipos involucrados.

Siempre que sea necesario asignar acceso o privilegios administrativos, piense siempre: “¿existe alguna forma más restrictiva de hacerlo y seguir permitiendo que las personas hagan lo que necesitan?” Por ejemplo, cuando los propietarios de aplicaciones necesitan acceso para administrar usuarios dentro de Microsoft Entra ID, puede usar unidades administrativas para asegurarse de que tengan los derechos para administrar los principios de seguridad relacionados con su carga de trabajo, sin proporcionar derechos generales de administración de Entra ID.

Identidad y acceso a la aplicación

Esta nueva sección trata sobre cómo administrar el acceso entre componentes de una aplicación, como por ejemplo, un front-end web que accede al almacenamiento o una base de datos SQL back-end. La guía Menciona brevemente la autenticación de usuarios en las aplicaciones, pero eso está documentado de manera más completa en otra parte .

Recomendamos utilizar identidades administradas siempre que sea posible. Las identidades administradas evitan almacenar credenciales en las aplicaciones. Puede usar MI con la mayoría de los servicios de Azure que admiten la autenticación de Microsoft Entra ID y la lista siempre está creciendo. Si utiliza canalizaciones de CI/CD, también puede utilizar la federación de identidades de carga de trabajo y OIDC para otorgar a sus canalizaciones el acceso necesario para aprovisionar y configurar recursos, sin almacenar credenciales de SPN que podrían caducar o verse comprometidas.

Al igual que con los controles de acceso a las ALZ, las identidades administradas no deben compartirse entre entornos. Por ejemplo, un servidor de aplicaciones de desarrollo no debería tener la capacidad de acceder a una base de datos SQL de producción. Las identidades administradas deben crearse y destruirse mediante programación como parte del ciclo de vida de su entorno, lo que reduce el riesgo y la complejidad a largo plazo, ya que no es necesario realizar cambios ni solucionar problemas de acceso al implementar de un entorno a otro.

En resumen

La sección actualizada de ALZ Identity and Access Management de CAF acerca el área de diseño al concepto de Azure Landing Zones y ofrece orientación actualizada. En última instancia, el objetivo de esta nueva guia, no es otro que permitir a los clientes de Azure crear entornos más seguros con menos fricción entre equipos y procesos.