Usuarios, grupos y asignaciones de roles

Azure Role-Based Access Control (RBAC) es el sistema de autorización que controla quién puede hacer qué en los recursos de Azure. En lugar de asignar permisos directamente a personas, se asignan roles a entidades de seguridad (usuarios, grupos, entidades de servicio o identidades administradas) en un ámbito específico. Esta separación mantiene los permisos administrables a medida que crece la organización.

Cada asignación de RBAC incluye tres componentes. Una entidad de seguridad es quien obtiene el acceso (un usuario, grupo o identidad administrada). Una definición de rol especifica qué acciones están permitidas (por ejemplo, leer máquinas virtuales o escribir en el almacenamiento). Un ámbito indica dónde se aplica el acceso, de más amplio a más específico: grupo de administración, suscripción, grupo de recursos o recurso individual. El acceso se hereda hacia abajo en la jerarquía de ámbitos.

Azure proporciona cientos de roles integrados. Los cuatro más utilizados en todos los tipos de recursos son: Owner: acceso completo, incluida la capacidad de asignar roles a otras personas; Contributor: acceso completo para crear y administrar recursos, pero sin capacidad para conceder acceso a otras personas; Reader: acceso de solo lectura; y User Access Administrator: puede administrar asignaciones de roles sin contribuir directamente a los recursos.

Una asignación de rol concede a la entidad de seguridad especificada los permisos definidos en la definición de rol dentro del ámbito especificado. Las asignaciones de roles se propagan a todos los ámbitos secundarios: asignar Contributor en el nivel del grupo de recursos concede acceso de Contributor a todos los recursos de ese grupo. Asignarlo en el nivel de suscripción concede acceso de Contributor en todos los grupos de recursos de esa suscripción.

El principio de privilegio mínimo establece que cada identidad debe tener únicamente los permisos mínimos necesarios para realizar su trabajo. En Azure RBAC, esto significa preferir Reader a Contributor cuando no se necesita escritura, preferir el ámbito del grupo de recursos al de la suscripción y utilizar, siempre que sea posible, roles específicos del recurso (por ejemplo, Storage Blob Data Contributor) en lugar del amplio rol Contributor.

Cuando ningún rol integrado coincide exactamente con sus requisitos, puede crear un rol personalizado. Una definición de rol personalizado especifica un conjunto de Actions (operaciones del plano de control permitidas), NotActions (excluidas del conjunto permitido), DataActions (operaciones del plano de datos en recursos, como leer el contenido de blobs) y AssignableScopes (suscripciones o grupos de administración donde se puede asignar el rol).

Asignar roles a grupos en lugar de a usuarios individuales es una práctica recomendada. Cuando se incorpora un nuevo desarrollador al equipo DevTeam, se le añade al grupo de seguridad DevTeam en Entra ID y hereda automáticamente todas las asignaciones de roles del grupo, sin realizar cambios en Azure RBAC. Este único punto de administración evita asignaciones individuales dispersas que resultan difíciles de auditar o revocar al retirar a una persona de la organización.

Una entidad de servicio es una identidad que utilizan las aplicaciones, los scripts y las herramientas de automatización para autenticarse en Azure y acceder a los recursos. A diferencia de una identidad de usuario, las entidades de servicio no pueden iniciar sesión de forma interactiva. Se crean a partir de App Registrations en Entra ID y, después, se les asignan roles de RBAC en el ámbito adecuado; por ejemplo, se puede conceder a una canalización de CI/CD acceso de Contributor a un único grupo de recursos para implementar infraestructura.

Las asignaciones de denegación bloquean acciones específicas para las entidades de seguridad, incluso si una asignación de rol normalmente las permitiera. A diferencia de las asignaciones de roles, los administradores no pueden crear directamente las asignaciones de denegación: Azure Blueprints o las aplicaciones administradas las adjuntan para impedir que los usuarios modifiquen recursos protegidos. Una asignación de denegación tiene prioridad sobre cualquier asignación de rol coincidente.

Privileged Identity Management (PIM) es una característica de Entra ID P2 que proporciona acceso privilegiado justo a tiempo. En lugar de asignar permanentemente un rol de Owner o Global Administrator, se hace que los usuarios sean aptos para ese rol. Cuando lo necesitan, activan la asignación durante un periodo limitado (por ejemplo, de 1 a 8 horas), con la posibilidad de requerir un flujo de aprobación y una justificación. Esto reduce considerablemente la superficie de ataque permanente de las cuentas con privilegios excesivos.

Las Access Reviews (Entra ID P2) son revisiones automatizadas periódicas que solicitan a los propietarios de recursos o responsables que confirmen si los miembros de su equipo aún necesitan sus asignaciones de roles actuales. Los revisores aprueban o deniegan la continuidad del acceso directamente desde la interfaz de revisión. Esto detecta permisos obsoletos derivados de cambios de rol, finalización de proyectos o bajas de empleados, un requisito clave para los programas de cumplimiento normativo.

Compruebe sus conocimientos sobre los conceptos de Microsoft Azure Fundamentals (AZ-900) de esta lección.

En esta lección ha aprendido que Azure RBAC asigna roles a entidades de seguridad dentro de un ámbito específico, que el principio de privilegio mínimo consiste en conceder únicamente los permisos mínimos necesarios y que PIM proporciona la activación justo a tiempo de roles con privilegios elevados en lugar de una asignación permanente. A continuación, trataremos la autenticación multifactor y el acceso condicional en Entra ID.