005 - Permisos en Azure: RBAC, PIM, Managed Identities y Service Principals

¿Por qué importa esto antes de tocar Defender?

Antes de lanzarnos a simular ataques y configurar alertas, hay algo que tenemos que tener claro: quién tiene acceso a qué, y por qué. En Azure, los permisos mal configurados son la puerta trasera favorita de cualquier atacante. Así que vamos a cerrar esa puerta antes de poner las cámaras de seguridad.

Este post no es el más emocionante de la serie — lo admito. Pero es el más importante si no quieres que tu laboratorio (o tu empresa) sea un queso gruyère. Tómatelo como los cimientos: nadie los ve, pero sin ellos el edificio se cae.

La jerarquía de Azure: todo tiene su sitio

Azure organiza los recursos en cuatro niveles anidados, y los permisos se heredan siempre de arriba hacia abajo. Esto es crucial: si le das acceso a alguien en un nivel alto, ese acceso se filtra hacia todo lo que hay por debajo.

Management Group
    └── Suscripción
            └── Resource Group
                    └── Recurso (VM, Storage, Key Vault…)

Management Group es el nivel más alto. Agrupa varias suscripciones bajo unas mismas políticas. Lo usan empresas grandes para decir cosas como "ninguna suscripción puede crear recursos fuera de Europa". Se pueden anidar entre sí.

Suscripción es la unidad de facturación y el límite de control de acceso principal. Todo recurso pertenece a exactamente una suscripción. Aquí es donde viven los quotas y los límites de servicio. Una empresa típica tiene varias: producción, desarrollo, staging…

Resource Group es un contenedor lógico dentro de una suscripción. Agrupa recursos que comparten el mismo ciclo de vida. Si borras el resource group, se va todo lo que hay dentro — ojo con esto. Piensa en él como una carpeta: un resource group por aplicación o por entorno.

Recurso es la unidad mínima: una VM, una base de datos, una Storage Account, un Log Analytics Workspace, etc.

> ⚠️ Regla de oro: los permisos se heredan hacia abajo, nunca hacia arriba. Un acceso en la suscripción llega a todos sus resource groups y recursos. Un acceso en un recurso no sube al resource group que lo contiene.

Azure RBAC: la lógica detrás de los permisos

Azure usa Role-Based Access Control (RBAC). La mecánica es simple: asignas un role (qué puede hacer) a un principal (quién lo hace) en un scope (dónde lo puede hacer).

Los cuatro roles fundamentales que puedes asignar en cualquier nivel:

Además de estos cuatro, Azure tiene cientos de roles especializados por tipo de recurso. Algunos que verás mucho en el contexto de Defender:

• --Log Analytics Reader / Log Analytics Contributor — para consultar o configurar workspaces de logs
• --Storage Blob Data Reader / Storage Blob Data Contributor — ojo, esto es separado de ser Contributor del Storage Account (más sobre esto abajo)
• --Key Vault Secrets User — para leer secretos de un Key Vault sin poder tocar la configuración
• --Security Reader / Security Admin — para trabajar con Defender y Microsoft Sentinel

El truco del plano de control vs. el plano de datos

Aquí hay un matiz que confunde a mucha gente y que es importante entender:

En algunos servicios, gestionar el recurso y acceder a los datos dentro del recurso son cosas distintas con permisos distintos.

Ejemplo concreto: si alguien es Contributor en un Storage Account, puede configurar la cuenta, cambiar sus opciones, ver sus propiedades… pero no puede leer los blobs que hay dentro a menos que también tenga Storage Blob Data Reader. Son dos planos separados — el plano de control (la infraestructura) y el plano de datos (el contenido).

Mismo caso con Key Vault: un Contributor puede gestionar el vault, pero no puede leer los secretos. Para eso necesita Key Vault Secrets User.

Esto es bueno desde el punto de vista de seguridad (puedes dar acceso operacional sin exponer los datos), pero hay que tenerlo en cuenta cuando configures permisos y te preguntes "¿por qué no puede leer esto si es Contributor?".

A quién le asignas los roles: usuarios, grupos e identidades

Los roles no solo se asignan a usuarios humanos. En Azure puedes asignar un rol a tres tipos de principals:

Usuarios individuales — funciona, pero es la peor opción para gestionar a escala. Cada vez que alguien entra o sale del equipo tienes que ir recurso por recurso. Un horror.

Grupos de Entra ID — la opción correcta. Creas un grupo (equipo-secops-prod, por ejemplo), le asignas los roles necesarios, y luego gestionas quién está en el grupo. Cuando alguien entra al equipo, lo añades al grupo y hereda todos los permisos. Cuando se va, lo sacas y pierde todo de golpe. Limpio, auditable y escalable.

Service Principals y Managed Identities — para aplicaciones y servicios automatizados que necesitan acceder a recursos Azure sin ser humanos. Más sobre esto en la siguiente sección.

> 💡 Buena práctica: nunca asignes roles directamente a usuarios individuales en entornos de producción. Usa siempre grupos. Tu yo del futuro te lo agradecerá cuando tengas que auditar accesos.

PIM: los permisos que se activan cuando los necesitas

Hasta aquí, los permisos son permanentes: si tienes el rol, lo tienes siempre. Pero hay un problema claro con esto: si alguien necesita ser Owner de producción para hacer una tarea puntual, ¿tiene que tener ese rol asignado los 365 días del año?

Para eso existe Privileged Identity Management (PIM), un servicio de Azure (requiere licencia Entra ID P2) que introduce el concepto de just-in-time access: tienes el privilegio disponible, pero no activo. Lo activas cuando lo necesitas, y se desactiva solo al cabo de un tiempo.

PIM introduce dos tipos de asignación:

Active Assignments

Son los permisos tradicionales — siempre activos, 24/7. El usuario tiene el rol y puede ejercerlo en cualquier momento sin hacer nada. Equivalen al RBAC clásico.

Úsalos para roles de bajo privilegio que alguien necesita constantemente: un Reader sobre un workspace de monitorización, por ejemplo.

Eligible Assignments

El usuario tiene el rol asignado, pero no está activo. Para poder ejercerlo tiene que activarlo explícitamente a través del portal de PIM. Esa activación:

• --Dura un tiempo limitado (configurable, por ejemplo 1 u 8 horas)
• --Puede requerir una justificación escrita ("voy a hacer el despliegue de la release 2.4, necesito acceso a producción")
• --Puede requerir aprobación de un manager o responsable de seguridad
• --Puede requerir MFA en el momento de la activación
• --Queda registrada en el audit log con timestamp, justificación y quién aprobó

Úsalos para roles de alto privilegio: Owner en producción, Global Administrator en Entra ID, Security Admin en Defender. La regla aquí es clara: ningún Global Admin debería tener ese rol como Active assignment permanente.

> ⚠️ Limitación importante: las Managed Identities y Service Principals no pueden usar eligible assignments. PIM está diseñado para personas que interactúan con el portal de activación. Las identidades de aplicaciones siempre tienen active assignments, así que sé más cuidadoso con los roles que les asignas.

Managed Identities y Service Principals: las identidades para aplicaciones

Cuando una aplicación o servicio necesita acceder a recursos de Azure (leer un secreto de Key Vault, escribir en un Storage, llamar a la API de Defender…), necesita identificarse. No puedes darle las credenciales de un usuario humano — eso sería un desastre en todos los sentidos.

Para esto existen dos mecanismos:

Service Principal

Cuando registras una aplicación en Entra ID se crean dos objetos:

• --App Registration — la definición global de la aplicación. Existe a nivel de tenant.
• --Service Principal — la instancia de esa aplicación en un tenant concreto. Es el objeto sobre el que asignas roles RBAC.

Para autenticarse, el Service Principal usa credenciales que tú gestionas: un client secret (básicamente una contraseña con fecha de expiración) o un certificado. El problema es que alguien tiene que crear esas credenciales, guardarlas de forma segura, rotarlas cuando expiran y asegurarse de que no acaban en un .env commiteado en GitHub. Todo ese ciclo de vida es tu responsabilidad — y es una fuente habitual de problemas de seguridad.

Managed Identity

Es la respuesta de Microsoft al problema de "¿quién custodia las credenciales?". La idea es simple: Azure gestiona las credenciales por ti, y tú nunca las ves.

Cuando habilitas una Managed Identity en un recurso de Azure (una VM, una Function App, un Container App…), Azure crea automáticamente un Service Principal en Entra ID vinculado a ese recurso, y rota las credenciales internamente de forma continua. Tu código obtiene tokens llamando al endpoint local de metadatos sin necesitar ningún secreto en ningún sitio.

Hay dos sabores:

System-assigned — la creas directamente sobre un recurso concreto. Está atada al ciclo de vida de ese recurso: si borras la VM, la identidad desaparece. Un recurso, una identidad.

User-assigned — la creas como un recurso independiente y luego la asignas a uno o varios recursos. Sobrevive al recurso al que está asignada. Ideal cuando varias apps necesitan los mismos permisos, o cuando quieres preconfigurar la identidad antes de crear el recurso.

¿Cuándo usar cada una?

La regla es sencilla: Managed Identity siempre que el recurso esté dentro de Azure. Cero secretos que gestionar, cero riesgo de filtración, código más limpio.

Permisos prácticos para un analista de seguridad

Ahora que tienes claro cómo funciona el modelo de permisos, vamos a lo concreto: ¿qué roles necesitas tú como analista de seguridad en el día a día?

La respuesta depende de qué necesitas hacer. Algunos permisos los necesitas siempre activos para trabajar con fluidez; otros son tan potentes que no deberían estar activos nunca salvo cuando vayas a usarlos.

Antes de entrar en las tablas, una aclaración importante: los roles que verás a continuación vienen de dos sistemas distintos. Los roles RBAC de Azure (como Security Reader o Log Analytics Reader) se asignan sobre recursos de Azure — suscripciones, resource groups, workspaces. Los roles de Entra ID (como Security Operator o User Administrator) se asignan a nivel de tenant y controlan acciones sobre identidades, dispositivos y servicios de Microsoft 365. Ambos pueden gestionarse con PIM, pero viven en sitios diferentes del portal.

Roles activos (Active Assignments) — los del día a día

Estos son los roles que necesitas siempre encendidos para hacer tu trabajo sin fricciones:

Roles RBAC de Azure:

Roles de Entra ID (se asignan a nivel de tenant, no tienen scope de resource group):

Con esta combinación puedes investigar alertas, escribir queries en Sentinel, correlacionar eventos y revisar la configuración de recursos e identidades — el grueso del trabajo diario — sin tener ningún permiso de escritura en ningún sitio.

> 💡 Por qué Log Analytics Reader y Microsoft Sentinel Reader van al Resource Group y no a la suscripción: Sentinel vive dentro de un workspace de Log Analytics, que a su vez vive en un resource group. Asignar estos roles a nivel de suscripción daría acceso a todos los workspaces de la suscripción, incluyendo los de otros equipos. El principio de mínimo privilegio dice: scope al resource group donde está tu workspace y nada más.

Roles elegibles (Eligible via PIM) — los de las acciones críticas

Estos son los roles que no deberían estar activos nunca de forma permanente, pero que necesitas poder activar cuando la situación lo requiere. Actívalos, justifícalos, úsalos y deja que expiren.

Roles RBAC de Azure:

Roles de Entra ID (nivel de tenant):

> ⚠️ Una nota sobre Privileged Authentication Administrator: este rol puede modificar los métodos de autenticación de un Global Administrator. Eso lo convierte en una vía de escalada de privilegios si cae en las manos equivocadas. Trátalo con el mismo nivel de cautela que a Global Administrator y configúralo en PIM con aprobación obligatoria de un segundo responsable, no solo justificación escrita.

Ejemplo de flujo real: recibes una alerta de credenciales comprometidas. Con tus roles activos investigas el incidente en Sentinel, revisas el historial de sign-ins del usuario y confirmas el compromiso. Activas User Administrator en PIM con la justificación ("revocación de sesiones y reset de contraseña, cuenta [email protected], incidente INC-2024-0847"), revocas todas las sesiones, reseteas la contraseña y deshabilitas la cuenta. Si el usuario tenía MFA registrado en un dispositivo que también está comprometido, activas adicionalmente Privileged Authentication Administrator con aprobación del responsable de seguridad para limpiar sus métodos de autenticación. Todo queda en el audit log con timestamps y aprobaciones.

Permisos para Logic Apps

Las Logic Apps son el motor de los playbooks de automatización en Microsoft Sentinel. Para trabajar con ellas necesitas permisos en dos capas: los permisos de la infraestructura (la Logic App como recurso) y los permisos de las conexiones que usa internamente.

Para crear y editar Logic Apps:

Logic App Contributor es suficiente para la mayoría del trabajo: crear la Logic App, modificar su flujo, ejecutarla manualmente y revisar su historial de ejecuciones.

Para ver Logic Apps sin modificarlas:

El detalle importante: las conexiones (API Connections)

Cuando una Logic App llama a Microsoft Sentinel, Teams, o Exchange, no usa tus credenciales — usa una API Connection, que es un recurso separado en el Resource Group. Si creas una nueva Logic App con conexiones a Sentinel, necesitas ser quien autoriza esas conexiones (o tener permisos para editar las existentes).

Para autorizar una conexión de Sentinel, la cuenta que lo hace necesita tener al menos Microsoft Sentinel Contributor en el workspace correspondiente en ese momento. Una vez autorizada, la Logic App usa la conexión de forma autónoma.

> 💡 Recomendación práctica: en producción, las Logic Apps deberían usar una Managed Identity en lugar de conexiones autorizadas por un usuario. Si la Logic App tiene una system-assigned Managed Identity y le asignas Microsoft Sentinel Responder en el workspace, opera de forma autónoma sin depender de las credenciales de nadie. Cuando el analista que creó la conexión original se va de la empresa, el playbook sigue funcionando.

Poniendo en práctica: grupos, permisos y workspaces

Suficiente teoría. Vamos a montar esto de verdad. En esta sección crearemos los grupos de Entra ID, asignaremos los permisos que hemos descrito, y prepararemos los resource groups donde vivirán todas las herramientas que usaremos en los próximos posts.

El orden importa, así que te lo dejo claro desde el principio:

• --Desde la cuenta Owner/Global Admin → creamos el grupo de seguridad → le asignamos roles a nivel de suscripción

• --Desde la cuenta SecOps (ya con permisos heredados del grupo) → creamos los tres resource groups

• --Asignamos los permisos específicos por resource group al grupo de seguridad

• --Creamos los dos grupos restantes (automatización y usuarios)

Paso 1: Crear el grupo de seguridad y asignar permisos a nivel de suscripción

Empezamos desde la cuenta de Owner o Global Admin. Lo primero es crear el grupo que contendrá a los analistas de seguridad.

Vamos a Azure → Entra ID → Groups → New Group y lo configuramos así:

• --Group Type: Security — el objetivo del grupo es conceder permisos a las cuentas que formen parte de él
• --Microsoft Entra roles can be assigned to the group: Yes — queremos poder asignar roles de Entra ID directamente al grupo
• --Members: añadimos el usuario de SecOps

Una vez creado el grupo, le asignamos los roles necesarios a nivel de suscripción. Para ello vamos a Azure → Subscriptions → [nuestra suscripción] → Access Control (IAM) → Add role assignment.

Empezamos con Reader, que nos permitirá ver los resource groups existentes:

• --Assignment type: Active — necesitamos visibilidad constante sobre los recursos
• --Assignment duration: Permanent

Con este rol ya podremos ver todos los recursos de la suscripción.

Para Contributor, al ser un rol de altos privilegios, lo encontrarás en la pestaña Privileged administrator roles:

> ⚠️ En producción, Contributor debería ser siempre un Eligible assignment gestionado por PIM. Como esto es un entorno de laboratorio, lo asigno como activo y permanente para no estar aprobando mis propias peticiones. En tu empresa, no hagas esto.

Además de Reader y Contributor, asignamos los siguientes roles como Active assignments al mismo grupo:

• --Security Reader
• --Microsoft Sentinel Contributor
• --Log Analytics Contributor
• --Microsoft Sentinel Playbook Operator
• --Microsoft Sentinel Responder

Para los roles de Entra ID, el proceso es diferente — no se asignan desde IAM de la suscripción, sino desde el propio grupo. Vamos a Azure → Entra ID → Groups → All Groups → [nuestro grupo] → Assigned roles → Add assignments:

Estos los configuramos como Eligible assignments (en producción):

• --User Administrator
• --Cloud Device Administrator
• --Privileged Authentication Administrator
• --Teams Administrator

Y con esto, la cuenta de SecOps hereda todos los permisos necesarios a través del grupo. A partir de aquí, ya no necesitamos la cuenta de Global Admin para nada en este flujo.

Paso 2: Crear los resource groups desde la cuenta SecOps

Ahora sí, cambiamos a la cuenta de SecOps. Gracias a los permisos heredados del grupo de seguridad, ya puede ver, crear y editar resource groups en esta suscripción.

Vamos a Azure → Resource Groups → Create y creamos tres:

Para cada uno seleccionamos la suscripción correcta, le ponemos nombre, y elegimos la región más cercana a donde estéis (por rendimiento).

Una vez creados, deberíais ver algo así:

Paso 3: Asignar permisos específicos por resource group

Con los RGs creados, asignamos al grupo de seguridad los permisos específicos sobre cada uno. Esto es lo que nos permite aplicar el principio de mínimo privilegio: en vez de dar Contributor sobre toda la suscripción, damos solo los permisos necesarios sobre los resource groups que el analista tiene que gestionar.

Para ello vamos a cada Resource Group → Access Control (IAM) → Add role assignment y repetimos el proceso que ya conocemos.

Paso 4: Crear los grupos de automatización y usuarios

Ya tenemos el grupo de seguridad montado. Ahora creamos los otros dos.

Grupo de automatización

Este grupo contendrá las managed identities de las Logic Apps que crearemos en posts futuros. Necesita permisos para ejecutar acciones de respuesta, no para leer configuración general.

Vamos a Azure → Entra ID → Groups → New Group con esta configuración:

• --Group Type: Security
• --Group Name: automation
• --Description: This group handles all the accounts and permissions associated to automation
• --Microsoft Entra roles can be assigned to the group: Sí

Al activar esa opción aparece una sección de roles. Asignamos:

• --Security Operator
• --Security Reader

> Si aparece un aviso indicando que crear un grupo con asignación de roles de Entra ID es una acción irreversible, acéptalo. Es el comportamiento esperado — Microsoft te advierte porque estos grupos tienen más privilegios que los grupos normales y no pueden convertirse en grupos sin esa capacidad una vez creados.

A medida que vayamos necesitando permisos adicionales para las automatizaciones, los iremos añadiendo a este grupo sin tocar nada más.

Grupo de usuarios

El más sencillo de los tres. Por ahora no necesita ningún permiso especial — simplemente agrupa a los usuarios "víctima" que usaremos en las simulaciones de ataque.

Lo creamos igual que el anterior, sin asignar ningún rol, y añadimos el usuario víctima como miembro:

---

Con esto tenemos los tres grupos creados, los permisos asignados y los resource groups listos. La estructura de identidades y acceso del laboratorio ya está en pie. En el siguiente paso conectaremos las fuentes de datos y montaremos Sentinel sobre el workspace de logs.

Resumen: la hoja de ruta de los permisos

Antes de configurar cualquier cosa en Defender, asegúrate de que tienes claro esto:

• --Asigna siempre al nivel más bajo posible — principio de mínimo privilegio. No des acceso a la suscripción si con el resource group es suficiente.

• --Usa grupos, nunca usuarios individuales en producción.

• --Roles de alto privilegio = eligible en PIM, no active permanentes.

• --Para aplicaciones dentro de Azure = Managed Identity. Para aplicaciones fuera = Service Principal con certificado.

• --Recuerda el plano de datos — ser Contributor no significa poder leer los datos. Key Vault y Storage tienen sus propios roles de datos.

¿Qué viene ahora?

Con el modelo de permisos claro y los roles de analista bien definidos, ya tenemos todo lo necesario para ponernos manos a la obra. En el próximo post vamos a configurar las diferentes herramientas de Defender XDR — Defender for Endpoint, Defender for Identity, Defender for Cloud Apps y Defender for Office 365 — para empezar a tener visibilidad real sobre lo que ocurre en el entorno. Conectaremos las fuentes de datos, ajustaremos los conectores en Sentinel y dejaremos el stack listo para monitorizar.

Si tienes dudas sobre algún concepto de este post, no te cortes — el botón de correo está ahí arriba a la derecha.

¡Que vaya MUY bien!