Entra ID, antiguamente llamado Azure AD, es el servicio de identidad y acceso en la nube de Microsoft que se integra con la plataforma Azure y con otros servicios como Office 365, Dynamics 365 o Microsoft 365. Entra ID permite a las organizaciones gestionar sus usuarios, grupos, roles, aplicaciones y recursos de forma centralizada y segura. Sin embargo, como cualquier sistema, Entra ID puede ser vulnerable a ataques de ciberdelincuentes que busquen comprometer la identidad, el acceso o los datos de las organizaciones. Por eso, es importante realizar pruebas de penetración periódicas en Entra ID para evaluar su nivel de seguridad y detectar posibles debilidades o brechas.
En este artículo vamos a explicar algunas diferencias entre Entra ID y el Directorio Activo tradicional (AD On Premise) y entre Azure y Entra ID. Al final del blog esperamos que tengas una visión más clara sobre qué es Entra ID y su estructura.¿Qué es Azure y qué es Entra ID?
Antes de entrar en términos y la estructura de Entra ID, vamos a repasar brevemente qué es Azure y qué es Entra ID, ya que a veces se confunden o se usan indistintamente sobre todo por su antiguo nombre Azure AD.
Azure es la plataforma cloud de Microsoft que ofrece más de 200 servicios para crear, implementar y administrar aplicaciones y soluciones en un entorno global, escalable y flexible. Algunos ejemplos de servicios de Azure son: máquinas virtuales, bases de datos, almacenamiento, redes, inteligencia artificial, análisis, seguridad, etc.
¿Qué diferencias hay entre Entra ID y AD On Premise?
Otra fuente de confusión suele ser la diferencia entre Entra ID y el Directorio Activo tradicional (AD On Premise), que es el servicio de directorio que se usa en los entornos locales para gestionar los dominios, usuarios, grupos, políticas y recursos dentro de una red corporativa.
Aunque ambos servicios compartían el nombre Directorio Activo y algunas funcionalidades básicas, hay varias diferencias importantes entre ellos:
- Arquitectura: AD On Premise se basa en una arquitectura jerárquica donde los dominios se organizan en árboles y bosques. Cada dominio tiene uno o varios controladores de Dominio que almacenan la información del directorio y gestionan las solicitudes de autenticación y autorización. Entra ID se basa en una arquitectura plana donde cada organización tiene un dominio (tenant) en la nube. Cada tenant tiene una base de datos distribuida que almacena la información del directorio y se sincroniza con los servicios globales de Entra ID.
- Protocolos: AD On Premise usa protocolos como LDAP, Kerberos o NTLM para comunicarse con los clientes y los servidores dentro de la red corporativa. Entra ID usa protocolos como OAuth 2.0, OpenID Connect o SAML para comunicarse con los clientes y los servidores en la nube o en Internet.
- Sincronización: AD On Premise requiere una sincronización manual o programada entre los controladores de Dominio para mantener la consistencia del directorio. Entra ID se sincroniza automáticamente con los servicios globales de Entra ID y con otros servicios de Microsoft. Además, Entra ID permite una sincronización opcional con AD On Premise mediante herramientas como Entra ID Connect o Entra ID Domain Services.
- Subscripciones: AD On Premise no tiene subscripciones, sino que se basa en las licencias de Windows Server y de los clientes. Entra ID tiene distintos niveles de subscripciones que ofrecen diferentes funcionalidades y capacidades. Los niveles son: gratuito, básico, premium P1 y premium P2. Algunas de las diferencias entre los niveles son: el número de objetos que se pueden crear en el directorio (roles, grupos dinámicos, alertas, etc), el tipo de autenticación multifactor que se puede usar, las opciones de protección de identidad que se pueden aplicar, etc.
¿Cómo es la estructura de Entra ID?
Una vez que hemos visto qué es Entra ID y cómo se diferencia de AD On Premise, vamos a ver cómo es la estructura de Entra ID y qué elementos la componen.
La estructura de Entra ID se puede dividir en cuatro niveles:
- Entra ID tenant: Es el nivel más alto y representa el dominio en la nube de una organización. Cada tenant tiene un identificador único (tenant ID) y un nombre (tenant name). Un tenant puede tener una o varias subscripciones asociadas.
- Management group: Es un nivel opcional que permite agrupar varias subscripciones bajo una misma entidad administrativa. Un management group puede tener una o varias políticas asignadas que se aplican a todas las subscripciones que contiene.
- Subscription: Es el nivel donde se asignan los recursos y los servicios de Azure que se usan en una organización. Cada subscription tiene un identificador único (subscription ID) y un nombre (subscription name). Una subscription puede tener uno o varios grupos de recursos asociados.
- Resource group: Es el nivel donde se agrupan los recursos y los servicios de Azure que comparten un mismo ciclo de vida o una misma finalidad. Cada resource group tiene un identificador único (resource group ID) y un nombre (resource group name). Un resource group puede tener uno o varios recursos asociados.
- Resource: Es el nivel más bajo y representa cada uno de los servicios o elementos que se usan en Azure, como máquinas virtuales, bases de datos, redes, etc. Cada resource tiene un identificador único (resource ID) y un nombre (resource name).
Además de estos niveles, hay otros dos conceptos importantes que hay que conocer en la estructura de Entra ID:
- App registration: Es el proceso por el cual se registra una aplicación en Entra ID para que pueda usar el servicio de identidad y acceso en la nube. Una app registration tiene un identificador único (application ID) y un nombre (application name). Una app registration puede tener uno o varios secretos asociados que le permiten autenticarse con Entra ID.
- Enterprise application: Es el proceso por el cual se configura una aplicación en Entra ID para que pueda interactuar con otros servicios o recursos en la nube o en Internet, es la instancia o representación de la aplicación en tu tenant. Una enterprise application tiene un identificador único (enterprise application ID) y un nombre (enterprise application name). Una enterprise application puede tener uno o varios permisos asociados que le permiten acceder a otros servicios o recursos, aunque puede pedir varios permisos se pueden definir los permisos que realmente le quieres permitir. La identidad de acceso que corresponde a una aplicación empresarial sería el Service Principal.
Podemos entender las aplicaciones empresariales como la parte de la cuenta de servicio. La relación entre una App registration, que es una aplicación, i un Service Principal, que es una aplicación empresarial, es que el Service Principal es la parte de cuenta de servicio de una App registration. Por ejemplo, si tenemos una aplicación multi-tenant habría solo una App registration en el home del tenant, y habría una aplicación empresarial en cada tenant. Y a esta aplicación empresarial le podemos asignar Roles de Azure. Por ejemplo, una aplicación empresarial podría tener derecho de propiedad en una máquina virtual o derechos de contribución en una cuenta de almacenamiento.
- Identidades Gestionadas: Supongamos que tenemos una aplicación que se ejecuta en una máquina virtual. Y que los datos de esta aplicación se almacenan en una base de datos SQL externa. Entonces esta aplicación debe tener una cuenta para recuperar y almacenar sus datos de la base de datos. Una Identidad Gestionada es un tipo de Aplicación Empresarial (por lo tanto, un Servicio Principal) dentro de Azure AD, que está vinculada a un recurso Azure (por ejemplo, la máquina virtual). A continuación, se puede iniciar sesión en el recurso Azure (VM) como esta aplicación empresarial sin almacenar ninguna credencial en el recurso Azure (VM). Con esta cuenta, puede autenticarse en otros recursos Azure (por ejemplo, la base de datos SQL) que admitan la autenticación de Azure AD. Una ventaja adicional es que puedes utilizar asignaciones de roles dentro de Azure AD y Azure RBAC para asignar permisos a la Aplicación Empresarial.
La idea de las identidades gestionadas es asistir a los desarrolladores al tratar con secretos. Si tenemos una aplicación que requiere guardar secretos como credenciales de usuario, etc. Una identidad gestionada permite que la aplicación acceda a un key vault que puede guardar secretos de manera segura. De manera que nos soluciona el problema de tratar con secretos, el key vault gestionará eso en vez del desarrollador. Eso también implica que, si se compromete la app, el atacante podrá pedir un access token para el key vault y podrá extraer los secretos.
Conclusión
En este post, hemos visto qué es Entra ID, así como las diferencias respecto a Azure y AD on premise. También se ha visto la arquitectura de Entra ID y algunos conceptos interesantes sobre este tipo de plataformas. En el próximo artículo veremos técnicas enfocadas al pentesting en Entra ID.
Hasta la próxima.
Autor: Roger Martín - OSCP
Dpto. de Auditoría
