El control de acceso basado en roles (Azure RBAC) ayuda a administrar quién tiene acceso a los recursos de Azure, qué pueden hacer con esos recursos y a qué áreas puede acceder.
Azure RBAC es un sistema de autorización basado en Azure Resource Manager que proporciona administración de acceso específico a los recursos de Azure.
Estos son algunos ejemplos de lo que puede hacer con Azure RBAC:
Para controlar el acceso a los recursos que usan Azure RBAC hay que utilizar las asignaciones de roles de Azure. Este es un concepto clave que es necesario entender: se trata de cómo se aplican los permisos. Una asignación de roles consta de tres elementos: entidad de seguridad, definición de rol y ámbito.
Una entidad de seguridad es un objeto que representa a un usuario, un grupo, una entidad de servicio o una identidad administrada que solicita acceso a recursos de Azure. Puede asignar un rol a cualquiera de estas entidades de seguridad.
Una definición de roles es una recopilación de permisos. Suele denominarse un rol. Una definición de roles enumera las acciones que se pueden realizar; por ejemplo, de lectura, escritura y eliminación. Los roles pueden ser generales, como propietarios, o específicos, como lectores de máquina virtual.
Azure incluye varios roles integrados que puede usar. Por ejemplo, el rol Colaborador de máquina virtual permite al usuario crear y administrar máquinas virtuales. Si los roles integrados no satisfacen las necesidades específicas de la organización, puede crear roles personalizados de Azure propios.
Azure tiene acciones de datos que le permiten conceder acceso a los datos de un objeto. Por ejemplo, si un usuario tiene acceso para leer datos de una cuenta de almacenamiento, puede leer los blobs o mensajes en esa cuenta de almacenamiento.
Ámbito es el conjunto de recursos al que se aplica el acceso. Cuando se asigna un rol, es posible limitar aún más las acciones permitidas si se define un ámbito. Esto resulta útil si desea convertir a alguien en Colaborador del sitio web, pero solo para un grupo de recursos.
En Azure, puede especificar un ámbito en cuatro niveles: grupo de administración, suscripción, grupo de recursos o recurso. Los ámbitos se estructuran en una relación de elementos primarios y secundarios. Puede asignar roles en cualquiera de estos niveles de ámbito.
Una asignación de roles es el proceso de asociar una definición de roles a un usuario, grupo, entidad de servicio o identidad administrada en un ámbito determinado con el fin de conceder acceso. El acceso se concede mediante la creación de una asignación de roles y se revoca al quitar una asignación de roles.
El diagrama siguiente muestra un ejemplo de una asignación de roles. En este ejemplo, al grupo de marketing se le asignó el rol Colaborador del grupo de recursos de ventas farmacéuticas. Esto significa que los usuarios del grupo de marketing pueden crear o administrar cualquier recurso de Azure del grupo de recursos de ventas farmacéuticas. Los usuarios de marketing no tienen acceso a los recursos fuera del grupo de recursos de ventas farmacéuticas, a menos que sean parte de otra asignación de roles.
Para asignar los distintos roles se pueden usar Azure Portal, la CLI de Azure, Azure PowerShell, los SDK de Azure o las API REST.
Estas asignaciones de roles son transitivas para los grupos, lo que significa que, si un usuario es miembro de un grupo y ese grupo es miembro de otro grupo que tiene una asignación de roles, el usuario tendrá los permisos de la asignación de roles.
Por tanto, ¿qué ocurre si tiene varias asignaciones de roles que se superponen? Azure RBAC es un modelo de suma, por lo que los permisos efectivos son la suma de sus asignaciones de rol. Considere el ejemplo siguiente, donde a un usuario se le concede el rol Colaborador en el ámbito de la suscripción y el rol Lector en un grupo de recursos. La suma de los permisos de Colaborador y los de Lector es realmente el rol Colaborador de la suscripción. Por consiguiente, en este caso, la asignación del rol Lector no tiene ningún impacto.
Anteriormente, Azure RBAC era un modelo solo de permiso sin denegación, pero ahora Azure RBAC admite asignaciones de denegación de manera limitada. De forma similar a una asignación de roles, una asignación de denegación asocia un conjunto de acciones de denegación a un usuario, grupo, entidad de servicio o identidad administrada en un ámbito determinado con el fin de denegar el acceso. Una asignación de roles define un conjunto de acciones que están permitidas, mientras que una asignación de denegación define un conjunto de acciones no permitidas. En otras palabras, denegar asignaciones impide que los usuarios realicen acciones especificadas, incluso si una asignación de roles les concede acceso. Las asignaciones de denegación tienen prioridad sobre las asignaciones de roles.
Estos son los pasos en líneas generales que Azure RBAC para determinar si tiene acceso a un recurso. Estos pasos se aplican a Azure Resource Manager o a servicios de plano de datos integrados con Azure RBAC. Esto resulta útil para saber si está intentando solucionar un problema de acceso.
Actions que tienen un carácter comodín (*), los permisos efectivos se calculan restando NotActions del valor de Actions permitido. Igualmente, se realiza la misma resta con cualquier acción de datos.Actions - NotActions = Effective management permissionsDataActions - NotDataActions = Effective data permissionsEl siguiente diagrama es un resumen de la lógica de evaluación.
Las definiciones de roles, las asignaciones de roles y las asignaciones de denegación se almacenan globalmente para garantizar que tenga acceso a los recursos independientemente de la región en la que creó el recurso.
Cuando se elimina una asignación de roles o cualquier otro dato de RBAC de Azure, los datos se eliminan de manera global. Las entidades de seguridad que tenían acceso a un recurso a través de los datos de RBAC de Azure perderán su acceso.
Los datos de RBAC de Azure son globales para garantizar que los clientes puedan acceder a tiempo a los recursos, independientemente de dónde accedan. RBAC de Azure se aplica mediante Azure Resource Manager, que tiene un punto de conexión global, y las solicitudes se enrutan a la región más cercana en pos de la velocidad y la resistencia. Por lo tanto, se debe aplicar RBAC de Azure en todas las regiones y los datos se replican en todas las regiones.
Considere el ejemplo siguiente. Arina crea una máquina virtual en Asia Pacífico. Bob, que es miembro del equipo de Arina, trabaja en los Estados Unidos. Bob tiene que acceder a la máquina virtual que se creó en Asia Pacífico. Para conceder a Bob acceso a tiempo a la máquina virtual, Azure debe replicar globalmente la asignación de roles que concede a Bob acceso a la máquina virtual desde cualquier lugar donde se encuentre.
