Azure SC-900: Gobernanza de Acceso — Acceso Condicional, RBAC y PIM
Entrar al edificio de una empresa y entrar a una sala específica dentro de él son dos cosas distintas. Y en una misma sala, se pueden aplicar reglas diferentes según el día de la semana, o según si quien accede es un empleado regular o un pasante. La seguridad moderna en la nube exige un control de acceso así de preciso y detallado. En este artículo se examinan las herramientas fundamentales de gobernanza de acceso en Azure.
Acceso Condicional: Seguridad inteligente según el contexto
Imaginen que un guardia de seguridad no solo verifica el pase de acceso para decidir si alguien puede entrar. También evalúa: "¿Esta persona está entrando por la puerta principal en horario laboral? ¿O está intentando entrar por la puerta trasera a las 3 de la madrugada? ¿El reconocimiento facial coincide? ¿Llegó en el vehículo registrado?" Pondera múltiples condiciones para tomar su decisión.
El Acceso Condicional (Conditional Access) de Microsoft Entra ID cumple exactamente ese rol. En lugar de verificar únicamente si la contraseña es correcta, recopila múltiples señales (Signals) para permitir el acceso, bloquearlo o solicitar autenticación adicional.
Señales (Signals): ¿Qué información se recopila?
Relacionadas con el usuario: ¿Quién intenta iniciar sesión? (¿es administrador o empleado general?) Relacionadas con la ubicación: ¿Desde dónde se está iniciando sesión? (¿desde la oficina en el país, desde el extranjero, desde una ubicación conocida como maliciosa?) Relacionadas con el dispositivo: ¿Qué dispositivo se está usando? (¿un dispositivo gestionado por la empresa o un dispositivo personal?) Relacionadas con la aplicación: ¿A qué aplicación se intenta acceder? (¿un sistema financiero sensible o el correo electrónico general?) Relacionadas con el riesgo: Nivel de riesgo del inicio de sesión detectado por la IA de Microsoft (¿hay un patrón inusual?).
Decisión (Decision): ¿Qué acción se toma?
Basándose en las señales recopiladas, se pueden tomar tres tipos de decisiones:
Permitir: Si las condiciones son normales, se permite el acceso.
Bloquear: Si se considera peligroso, se bloquea completamente el acceso.
Permitir con condiciones: Se permite el acceso con condiciones adicionales, como requerir autenticación MFA, solicitar cambio de contraseña, o permitir acceso solo desde dispositivos que cumplan con las políticas.
Ejemplos de uso real
Escenario 1: Un empleado accede a su correo electrónico desde la oficina en un día laborable en horario normal → Condiciones normales, acceso permitido de inmediato.
Escenario 2: El mismo empleado intenta acceder al portal de administración de Azure a las 2 de la madrugada desde una IP de Nigeria → Señal de riesgo detectada, acceso bloqueado o se requiere MFA.
Escenario 3: Se intenta acceder a archivos de la empresa desde un teléfono personal → El dispositivo no cumple las políticas de la empresa, se permite acceso de solo lectura + MFA.
Roles de Entra ID vs Azure RBAC: Dos sistemas separados
Pensemos en una escuela: el director gestiona el funcionamiento de toda la institución, pero no administra la gestión educativa de la ciudad. El funcionario municipal tramita asuntos administrativos, pero no decide el currículo de la escuela. Los roles son diferentes.
En Azure también existen dos sistemas de roles con propósitos distintos.
Roles de Microsoft Entra ID
Son roles para gestionar Microsoft Entra ID en sí mismo. Determinan quién puede administrar cuentas de usuarios, grupos, licencias, registros de aplicaciones y demás elementos relacionados con la identidad.
Roles representativos: Administrador global (Global Administrator): gestiona todo en Entra ID. El nivel más alto de permisos. Administrador de usuarios (User Administrator): gestiona únicamente usuarios y grupos. Administrador del servicio de asistencia (Helpdesk Administrator): puede realizar solo tareas limitadas, como restablecer contraseñas.
Azure RBAC (Control de acceso basado en roles)
Determina quién puede gestionar los recursos de Azure (VM, almacenamiento, bases de datos, etc.). Es un sistema completamente independiente de los roles de Entra ID.
Roles representativos: Propietario (Owner): puede acceder a todos los recursos y delegar permisos a otras personas. Colaborador (Contributor): puede crear, modificar y eliminar recursos, pero no puede delegar permisos. Lector (Reader): solo puede consultar recursos.
Diferencia importante
Ser Administrador global de Entra ID no otorga automáticamente acceso a todos los recursos de una suscripción de Azure. A la inversa, ser Propietario de una suscripción de Azure no permite gestionar Entra ID. Estos dos sistemas operan de forma independiente.
Azure RBAC se aplica según el ámbito (Scope): Grupo de administración → Suscripción → Grupo de recursos → Recurso individual. Los roles asignados en un ámbito superior se heredan en los ámbitos inferiores.
!Roles de Entra ID vs Azure RBAC
PIM: Permisos elevados solo cuando se necesitan
Imaginen que una empresa de seguridad gestiona llaves. La llave de la caja fuerte solo se toma prestada cuando es necesario abrirla, y se devuelve al terminar el trabajo. Llevar siempre la llave de la caja fuerte encima es peligroso: podría perderse o ser robada.
PIM (Privileged Identity Management, Gestión de identidades con privilegios) aplica este principio a la seguridad de TI.
El problema que resuelve PIM
Problema del método tradicional: A quien necesita permisos de administrador se le crea una cuenta de administrador que mantiene esos permisos las 24 horas. Si esa cuenta es comprometida, el atacante obtiene acceso ilimitado.
Método con PIM: Los permisos se activan de forma temporal solo cuando se necesitan. Normalmente se tienen permisos de usuario estándar, y cuando se necesita realizar una tarea de administración, se envía una solicitud de "activación de permisos".
Funciones clave de PIM
Acceso Just-in-Time: Los permisos se activan solo durante el tiempo necesario. Si se planea una tarea de administración de 2 horas, se otorgan permisos solo por 2 horas.
Flujo de aprobación: Se puede configurar que activar permisos elevados requiera la aprobación de un administrador. Es necesario justificar "por qué se necesitan estos permisos".
Límite de tiempo: Los permisos expiran automáticamente. Incluso si la persona no los revoca manualmente, los permisos desaparecen una vez transcurrido el tiempo establecido.
Notificaciones y auditoría: Se registra y se envían notificaciones sobre quién activó qué permisos, cuándo y en qué momento.
Requisito de MFA: Se requiere MFA para activar permisos, garantizando una capa de seguridad adicional.
Revisiones de acceso: Verificación periódica de los permisos
Piensen en sus suscripciones de servicios. Si no se revisan de vez en cuando pensando "¿sigo usando este servicio?", se continúa pagando por servicios que ya no se utilizan. Lo mismo ocurre con los permisos de acceso en una organización.
Un empleado se ha trasladado de departamento. Los permisos de acceso a los sistemas del departamento anterior no desaparecen automáticamente. Es necesario verificar que la cuenta de un empleado que se fue haya sido completamente desactivada.
Las Revisiones de acceso (Access Reviews) son una herramienta para realizar esta "limpieza de permisos" de forma sistemática.
¿Cómo funciona?
Se establece un calendario de revisión periódica. Por ejemplo: revisar todas las cuentas de administrador cada trimestre.
El revisor (administrador, propietario del recurso o el propio usuario) aprueba o rechaza si cada permiso de acceso sigue siendo necesario.
Automatización: Se puede configurar para que los permisos se eliminen automáticamente según los resultados de la revisión.
¿Quién realiza la revisión?
Administrador revisa: el jefe del equipo revisa los permisos de acceso de los miembros del equipo. Propietario del recurso revisa: el responsable de un sistema revisa el acceso a ese sistema. El propio usuario revisa: se le pregunta al usuario "¿sigue necesitando este acceso?".
Gestión de derechos (Entitlement Management): Acceso simplificado mediante paquetes
Cuando llega un nuevo empleado, ¿a qué sistemas debe acceder? Enviar un correo al equipo de TI, hacer una solicitud por separado, esperar la aprobación... Es complicado. Especialmente si la organización es grande.
La Gestión de derechos (Entitlement Management) simplifica este proceso. Agrupa los permisos de acceso necesarios por rol en "paquetes de acceso" para gestionarlos.
Ejemplo: El paquete "Nuevo empleado de Marketing" = acceso al sitio de SharePoint de Marketing + canal de Teams de Marketing + permiso de lectura del sistema CRM.
Un nuevo empleado del equipo de Marketing solo necesita solicitar ese paquete y recibirá todo el acceso necesario de una vez. Se puede establecer una fecha de vencimiento para que, en el caso de empleados contratados por tiempo determinado, el acceso se elimine automáticamente al terminar el contrato.