Descripción de las definiciones de roles de Azure
Tanto si quiere comprender el funcionamiento de un rol de Azure como si va a crear su propio rol de Azure personalizado, le resultará útil entender cómo se definen los roles. En este artículo se describen los detalles de las definiciones de roles y se proporcionan algunos ejemplos.
Definición de roles
Una definición de roles es una recopilación de permisos. A veces, se denomina rol simplemente. Una definición de roles enumera las acciones que se pueden realizar; por ejemplo, de lectura, escritura y eliminación. También puede enumerar las acciones excluidas de las acciones permitidas o las acciones relacionadas con datos subyacentes.
A continuación se muestra un ejemplo de las propiedades de una definición de roles cuando se muestran mediante Azure PowerShell:
Name
Id
IsCustom
Description
Actions []
NotActions []
DataActions []
NotDataActions []
AssignableScopes []
Condition
ConditionVersion
A continuación se muestra un ejemplo de las propiedades de una definición de roles cuando se muestra mediante la CLI de Azure o la API de REST:
roleName
name
id
roleType
type
description
actions []
notActions []
dataActions []
notDataActions []
assignableScopes []
condition
conditionVersion
createdOn
updatedOn
createdBy
updatedBy
En la tabla siguiente se describe el significado de las propiedades de roles.
Propiedad | Descripción |
---|---|
Name roleName |
Nombre para mostrar del rol. |
Id name |
Identificador único del rol. Los roles integrados tienen el mismo id. de rol en todas las nubes. |
id |
Identificador único completo del rol. Incluso si se cambia el nombre de un rol, su identificador no cambia. Usar el identificador de rol en los scripts es un procedimiento recomendado. |
IsCustom roleType |
Indica si este rol es personalizado. Se establece en true o CustomRole para los roles personalizados. Se establece en false o BuiltInRole para los roles integrados. |
type |
Tipo de objeto. Establézcalo en Microsoft.Authorization/roleDefinitions . |
Description description |
Descripción del rol. |
Actions actions |
Matriz de cadenas que especifica las acciones del plano de control que el rol permite realizar. |
NotActions notActions |
Matriz de cadenas que especifica las acciones del plano de control que se excluyen de las Actions permitidas. |
DataActions dataActions |
Matriz de cadenas que especifica las acciones del plano de datos que el rol permite realizar en los datos dentro de ese objeto. |
NotDataActions notDataActions |
Matriz de cadenas que especifica las acciones del plano de datos que se excluyen de la propiedad DataActions permitida. |
AssignableScopes assignableScopes |
Matriz de cadenas que especifica los ámbitos en los que el rol está disponible para la asignación. |
Condition condition |
Para los roles integrados, la instrucción condition se basa en una o varias acciones en la definición de roles. |
ConditionVersion conditionVersion |
Número de versión de condición. El valor predeterminado es 2.0 y es la única versión admitida. |
createdOn |
Se creó el rol de fecha y hora. |
updatedOn |
El rol de fecha y hora se actualizó por última vez. |
createdBy |
En el caso de los roles personalizados, la entidad de seguridad que creó el rol. |
updatedBy |
En el caso de los roles personalizados, la entidad de seguridad que actualizó el rol. |
Formato de acciones
Las acciones se especifican con cadenas que tienen el siguiente formato:
{Company}.{ProviderName}/{resourceType}/{action}
La parte {action}
de una cadena de acción especifica el tipo de acciones que puede realizar en un tipo de recurso. Por ejemplo, verá las siguientes subcadenas en {action}
:
Subcadena de acción | Descripción |
---|---|
* |
El carácter comodín concede acceso a todas las operaciones que coinciden con la cadena. |
read |
Permite acciones de lectura (GET). |
write |
Permite acciones de escritura (PUT o PATCH). |
action |
Permite acciones personalizadas, como reiniciar máquinas virtuales (POST). |
delete |
Permite acciones de eliminación (DELETE). |
Ejemplo de definición de roles
Esta es la definición del rol Colaborador como se muestra en Azure PowerShell y la CLI de Azure. Las acciones del carácter comodín (*
) en Actions
indican que la entidad de seguridad asignada a este rol puede realizar todas las acciones o, en otras palabras, administrar todo el contenido. Esto incluye las acciones que se definan en el futuro, a medida que Azure vaya agregando nuevos tipos de recursos. Las operaciones de NotActions
se restan de Actions
. En el caso del rol Colaborador, NotActions
le quita la capacidad para administrar el acceso a los recursos, así como de administrar las asignaciones de Azure Blueprints.
Rol Colaborador como se muestra en Azure PowerShell:
{
"Name": "Contributor",
"Id": "b24988ac-6180-42a0-ab88-20f7382dd24c",
"IsCustom": false,
"Description": "Grants full access to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries.",
"Actions": [
"*"
],
"NotActions": [
"Microsoft.Authorization/*/Delete",
"Microsoft.Authorization/*/Write",
"Microsoft.Authorization/elevateAccess/Action",
"Microsoft.Blueprint/blueprintAssignments/write",
"Microsoft.Blueprint/blueprintAssignments/delete",
"Microsoft.Compute/galleries/share/action",
"Microsoft.Purview/consents/write",
"Microsoft.Purview/consents/delete"
],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
"/"
],
"Condition": null,
"ConditionVersion": null
}
Rol Colaborador tal como se muestra en la CLI de Azure:
[
{
"assignableScopes": [
"/"
],
"createdBy": null,
"createdOn": "2015-02-02T21:55:09.880642+00:00",
"description": "Grants full access to manage all resources, but does not allow you to assign roles in Azure RBAC, manage assignments in Azure Blueprints, or share image galleries.",
"id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c",
"name": "b24988ac-6180-42a0-ab88-20f7382dd24c",
"permissions": [
{
"actions": [
"*"
],
"condition": null,
"conditionVersion": null,
"dataActions": [],
"notActions": [
"Microsoft.Authorization/*/Delete",
"Microsoft.Authorization/*/Write",
"Microsoft.Authorization/elevateAccess/Action",
"Microsoft.Blueprint/blueprintAssignments/write",
"Microsoft.Blueprint/blueprintAssignments/delete",
"Microsoft.Compute/galleries/share/action",
"Microsoft.Purview/consents/write",
"Microsoft.Purview/consents/delete"
],
"notDataActions": []
}
],
"roleName": "Contributor",
"roleType": "BuiltInRole",
"type": "Microsoft.Authorization/roleDefinitions",
"updatedBy": null,
"updatedOn": "2023-07-10T15:10:53.947865+00:00"
}
]
Acciones de control y datos
El control de acceso basado en rol para las acciones del plano de datos se especifica en las propiedades Actions
y NotActions
de una definición de rol. Estos son algunos ejemplos de acciones del plano de control en Azure:
- Administrar el acceso a una cuenta de almacenamiento
- Crear, actualizar o eliminar un contenedor de blobs
- Eliminar un grupo de recursos y todos sus recursos
El acceso del plano de control no se hereda al plano de datos, dado que el método de autenticación de contenedor se establece en Cuenta de usuario de Microsoft Entra, no en clave de acceso. Esta separación impide que los roles con caracteres comodín (*
) tengan acceso no restringido a los datos. Por ejemplo, si un usuario tiene el rol Lector en una suscripción, podrá ver la cuenta de almacenamiento, pero, de forma predeterminada, no podrá ver los datos subyacentes.
Anteriormente, el control de acceso basado en rol no se usaba para acciones de datos. La autorización para las acciones de datos variaba de un proveedor de recursos a otro. El mismo modelo de autorización de control de acceso basado en rol que se usa para las acciones del plano de control se ha ampliado a las acciones del plano de datos.
Para admitir las acciones del plano de datos, se han agregado nuevas propiedades de datos a la definición de roles. Las acciones del plano de datos se especifican en las propiedades DataActions
y NotDataActions
. Al agregar estas propiedades de datos, se mantiene la separación entre el plano de control y el plano de datos. Con ello, se evita que las asignaciones de roles actuales con caracteres comodín (*
) tengan acceso a los datos de repente. Estas son algunas acciones del plano de datos que se pueden especificar en DataActions
y NotDataActions
:
- Leer una lista de blobs en un contenedor
- Escribir un blob de almacenamiento en un contenedor
- Eliminar un mensaje de una cola
Esta es la definición del rol Lector de datos de blobs de almacenamiento, que incluye operaciones en las propiedades Actions
y DataActions
. Esta función permite leer el contenedor de blobs y también los datos de blob subyacentes.
Rol Lector de datos de Storage Blob tal como se muestra en Azure PowerShell:
{
"Name": "Storage Blob Data Reader",
"Id": "2a2b9908-6ea1-4ae2-8e65-a410df84e7d1",
"IsCustom": false,
"Description": "Allows for read access to Azure Storage blob containers and data",
"Actions": [
"Microsoft.Storage/storageAccounts/blobServices/containers/read",
"Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey/action"
],
"NotActions": [],
"DataActions": [
"Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
],
"NotDataActions": [],
"AssignableScopes": [
"/"
],
"Condition": null,
"ConditionVersion": null
}
Rol Lector de datos de Storage Blob tal como se muestra en la CLI de Azure:
[
{
"assignableScopes": [
"/"
],
"createdBy": null,
"createdOn": "2017-12-21T00:01:24.797231+00:00",
"description": "Allows for read access to Azure Storage blob containers and data",
"id": "/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleDefinitions/2a2b9908-6ea1-4ae2-8e65-a410df84e7d1",
"name": "2a2b9908-6ea1-4ae2-8e65-a410df84e7d1",
"permissions": [
{
"actions": [
"Microsoft.Storage/storageAccounts/blobServices/containers/read",
"Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey/action"
],
"condition": null,
"conditionVersion": null,
"dataActions": [
"Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read"
],
"notActions": [],
"notDataActions": []
}
],
"roleName": "Storage Blob Data Reader",
"roleType": "BuiltInRole",
"type": "Microsoft.Authorization/roleDefinitions",
"updatedBy": null,
"updatedOn": "2021-11-11T20:13:55.297507+00:00"
}
]
Solo se pueden agregar acciones del plano de datos a las propiedades DataActions
y NotDataActions
. Los proveedores de recursos identifican qué acciones son acciones de datos, para lo que establecen la propiedad isDataAction
en true
. Para ver una lista de las acciones en las que isDataAction
es true
, consulte Operaciones del proveedor de recursos de Azure. Los roles que no tienen acciones de datos no necesitan las propiedades DataActions
y NotDataActions
en la definición de roles.
Azure Resource Manager controla la autorización de todas las llamadas API del plano de control. Un proveedor de recursos o Azure Resource Manager controlan la autorización de las llamadas API del plano de datos.
Ejemplo de acciones de datos
Para conocer mejor el funcionamiento de las acciones del plano de control y del plano de datos, veamos un ejemplo concreto. A Alice se le ha asignado el rol Propietario en el ámbito de la suscripción. A Bob se le ha asignado el rol Colaborador de datos de blobs de almacenamiento en un ámbito de la cuenta de almacenamiento. En el siguiente diagrama se muestra este ejemplo.
El rol Propietario de Alice y el rol Colaborador de datos de blobs de almacenamiento de Bob tienen las siguientes acciones:
Propietario
Acciones
*
Colaborador de datos de blobs de almacenamiento
Acciones
Microsoft.Storage/storageAccounts/blobServices/containers/delete
Microsoft.Storage/storageAccounts/blobServices/containers/read
Microsoft.Storage/storageAccounts/blobServices/containers/write
Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey/action
DataActions
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action
Puesto que Alice tiene una acción de carácter comodín (*
) en un ámbito de suscripción, sus permisos se heredan para poder realizar todas las acciones del plano de control. Alice puede leer, escribir y eliminar contenedores. Sin embargo, Alice no puede realizar acciones del plano de datos sin pasos adicionales. Por ejemplo, de forma predeterminada, Alice no puede leer los blobs de un contenedor. Para leer los blobs, Alice tendría que recuperar las claves de acceso de almacenamiento y usarlas para acceder a los blobs.
Los permisos de Bob se limitan a solo los valores de Actions
y DataActions
especificados en el rol Colaborador de datos de blobs de almacenamiento. Según su rol, Bob puede realizar acciones tanto del plano de control como del plano de datos Por ejemplo, Bob puede leer, escribir y eliminar contenedores de la cuenta de almacenamiento especificada y también puede leer, escribir y eliminar los blobs.
Para más información acerca de la seguridad de los planos de control y de datos para el almacenamiento, consulte la guía de seguridad de Azure Storage.
¿Qué herramientas admiten el uso de roles de Azure en las acciones de datos?
Para visualizar y trabajar con acciones de datos, debe tener las versiones correctas de las herramientas o de los SDK:
Herramienta | Versión |
---|---|
Azure PowerShell | 1.1.0 o posterior |
CLI de Azure | 2.0.30 o posterior |
Azure para .NET | 2.8.0-versión preliminar o posterior |
Azure SDK para Go | 15.0.0 o posterior |
Azure para Java | 1.9.0 o posterior |
Azure para Python | 0.40.0 o posterior |
SDK de Azure para Ruby | 0.17.1 o posterior |
Para ver y usar las acciones de datos en la API REST, el valor del parámetro api-version debe ser la siguiente versión, o las versiones posteriores:
- 2018-07-01
Acciones
El permiso Actions
especifica las acciones del plano de control que el rol permite realizar. Se trata de una colección de cadenas que identifican acciones protegibles de proveedores de recursos de Azure. Estos son algunos ejemplos de acciones del plano de control que se pueden usar en Actions
.
Cadena de acción | Descripción |
---|---|
*/read |
Concede acceso a las acciones de lectura a todos los tipos de recursos de todos los proveedores de recursos de Azure. |
Microsoft.Compute/* |
Concede acceso a todas las acciones a todos los tipos de recursos del proveedor de recursos Microsoft.Compute. |
Microsoft.Network/*/read |
Concede acceso a las acciones de lectura a todos los tipos de recursos del proveedor de recursos Microsoft.Network. |
Microsoft.Compute/virtualMachines/* |
Concede acceso a todas las acciones de las máquinas virtuales y a sus tipos de recursos secundarios. |
microsoft.web/sites/restart/Action |
Concede acceso para reiniciar una aplicación web. |
NotActions
El permiso NotActions
especifica las acciones del plano de control que se restan o excluyen de la Actions
permitida que tienen un carácter comodín (*
). Use el permiso NotActions
si el conjunto de acciones que quiere permitir se define más fácilmente mediante la resta de los Actions
que tienen un carácter comodín (*
). El acceso concedido por un rol (permisos vigentes) se calcula restando las acciones de NotActions
de las de Actions
.
Actions - NotActions = Effective control plane permissions
En la tabla siguiente se muestran dos ejemplos de los permisos del plano de control efectivos para una acción con carácter comodín de Microsoft.CostManagement:
Acciones | NotActions | Permisos del plano de control efectivos |
---|---|---|
Microsoft.CostManagement/exports/* |
none | Microsoft.CostManagement/exports/action Microsoft.CostManagement/exports/read Microsoft.CostManagement/exports/write Microsoft.CostManagement/exports/delete Microsoft.CostManagement/exports/run/action |
Microsoft.CostManagement/exports/* |
Microsoft.CostManagement/exports/delete |
Microsoft.CostManagement/exports/action Microsoft.CostManagement/exports/read Microsoft.CostManagement/exports/write Microsoft.CostManagement/exports/run/action |
Nota:
Si un usuario tiene asignado un rol que excluye una acción en NotActions
y se le asigna un segundo rol que sí que concede acceso a esa acción, el usuario puede realizar dicha acción. NotActions
no es una regla de denegación, es simplemente una manera cómoda de crear un conjunto de acciones permitidas cuando es necesario excluir acciones específicas.
Diferencias entre NotActions y asignaciones de denegación
NotActions
y las asignaciones de denegación no son iguales y tienen diferentes fines. NotActions
son una manera práctica de restar acciones específicas de una acción con un carácter comodín (*
).
Las asignaciones de denegación impiden que los usuarios realicen acciones concretas, aunque una asignación de roles les conceda acceso. Para más información, consulte Descripción de las asignaciones de denegación de Azure.
DataActions
El permiso DataActions
especifica las acciones del plano de datos que el rol permite realizar en los datos dentro de ese objeto. Por ejemplo, si un usuario tiene acceso para leer datos de blobs de una cuenta de almacenamiento, puede leer los blobs en esa cuenta de almacenamiento. A continuación, se incluyen algunos ejemplos de acciones de datos que se pueden usar en DataActions
.
Cadena de acción de datos | Descripción |
---|---|
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read |
Devuelve un blob o una lista de blobs. |
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write |
Devuelve el resultado de la escritura de un blob. |
Microsoft.Storage/storageAccounts/queueServices/queues/messages/read |
Devuelve un mensaje. |
Microsoft.Storage/storageAccounts/queueServices/queues/messages/* |
Devuelve un mensaje o el resultado de la escritura o eliminación de un mensaje. |
NotDataActions
El permiso NotDataActions
especifica las operaciones de datos que se restan o excluyen de la DataActions
permitida que tienen un carácter comodín (*
). Use el permiso NotDataActions
si el conjunto de acciones que quiere permitir se define más fácilmente mediante la resta de los DataActions
que tienen un carácter comodín (*
). El acceso concedido por un rol (permisos vigentes) se calcula restando las acciones de NotDataActions
de las de DataActions
. Cada proveedor de recursos proporciona su conjunto respectivo de API para completar las acciones de datos.
DataActions - NotDataActions = Effective data plane permissions
En la tabla siguiente se muestran dos ejemplos de los permisos del plano de datos efectivos para una acción con carácter comodín de Microsoft.Storage:
DataActions | NotDataActions | Permisos del plano de datos de efectivos |
---|---|---|
Microsoft.Storage/storageAccounts/queueServices/queues/messages/* |
none | Microsoft.Storage/storageAccounts/queueServices/queues/messages/read Microsoft.Storage/storageAccounts/queueServices/queues/messages/write Microsoft.Storage/storageAccounts/queueServices/queues/messages/delete Microsoft.Storage/storageAccounts/queueServices/queues/messages/add/action Microsoft.Storage/storageAccounts/queueServices/queues/messages/process/action |
Microsoft.Storage/storageAccounts/queueServices/queues/messages/* |
Microsoft.Storage/storageAccounts/queueServices/queues/messages/delete |
Microsoft.Storage/storageAccounts/queueServices/queues/messages/read Microsoft.Storage/storageAccounts/queueServices/queues/messages/write Microsoft.Storage/storageAccounts/queueServices/queues/messages/add/action Microsoft.Storage/storageAccounts/queueServices/queues/messages/process/action |
Nota:
Si un usuario tiene asignado un rol que excluye una acción de datos en NotDataActions
y se le asigna un segundo rol que sí que concede acceso a esa operación de datos, el usuario puede realizar dicha acción de datos. NotDataActions
no es una regla de denegación, es simplemente una manera cómoda de crear un conjunto de acciones de datos permitidas cuando es necesario excluir acciones de datos específicas.
Ámbitos asignables
La propiedad AssignableScopes
especifica los ámbitos (raíz, grupo de administración, suscripciones o grupos de recursos) en los que se puede asignar una definición de rol. Puede hacer que un rol personalizado esté disponible para su asignación solo en el grupo de administración, las suscripciones o los grupos de recursos que lo necesiten. Hay que usar al menos un grupo de administración, una suscripción o un grupo de recursos.
Por ejemplo, si AssignableScopes
se establece en una suscripción, significa que el rol personalizado está disponible para la asignación en el ámbito de la suscripción especificada, el ámbito de cualquier grupo de recursos de la suscripción o el ámbito de cualquier recurso de la suscripción.
Los roles integrados tienen AssignableScopes
establecido en el ámbito raíz ("/"
). El ámbito raíz indica que el rol está disponible para la asignación en todos los ámbitos.
Ejemplos de ámbitos asignables válidos son:
Rol disponible para su asignación | Ejemplo |
---|---|
Una suscripción | "/subscriptions/{subscriptionId1}" |
Dos suscripciones | "/subscriptions/{subscriptionId1}", "/subscriptions/{subscriptionId2}" |
Grupo de recursos de red | "/subscriptions/{subscriptionId1}/resourceGroups/Network" |
Un grupo de administración | "/providers/Microsoft.Management/managementGroups/{groupId1}" |
Grupo de administración y suscripción | "/providers/Microsoft.Management/managementGroups/{groupId1}", "/subscriptions/{subscriptionId1}", |
Todos los ámbitos (se aplica solo a los roles integrados) | "/" |
Solo se puede definir un grupo de administración en AssignableScopes
de un rol personalizado.
Aunque es posible crear un rol personalizado con una instancia de recurso en AssignableScopes
mediante la línea de comandos, no se recomienda. Cada inquilino admite un máximo de 5.000 roles personalizados. El uso de esta estrategia podría agotar potencialmente los roles personalizados disponibles. En última instancia, la asignación de roles personalizada determina el nivel de acceso (ámbito + permisos de rol + entidad de seguridad) y no los AssignableScopes
enumerados en el rol personalizado. Por lo tanto, cree los roles personalizados con los AssignableScopes
del grupo de administración, la suscripción o el grupo de recursos, pero asigne los roles personalizados con un ámbito estrecho, como el recurso o el grupo de recursos.
Para más información sobre AssignableScopes
para los roles personalizados, consulte Roles personalizados de Azure.
Definición de roles de administrador con privilegios
Los roles de administrador con privilegios son roles que conceden acceso de administrador con privilegios, como la capacidad de administrar recursos de Azure o asignar roles a otros usuarios. Si un rol integrado o personalizado incluye cualquiera de las acciones siguientes, se considera con privilegios. Para obtener más información, consulte Enumerar o administrar asignaciones de roles de administrador con privilegios.
Cadena de acción | Descripción |
---|---|
* |
Crear y administrar recursos de todos los tipos. |
*/delete |
Elimine los recursos de todos los tipos. |
*/write |
Escribir recursos de todos los tipos. |
Microsoft.Authorization/denyAssignments/delete |
Elimina una asignación de denegación en el ámbito especificado. |
Microsoft.Authorization/denyAssignments/write |
Crea una asignación de denegación en el ámbito especificado. |
Microsoft.Authorization/roleAssignments/delete |
Elimine una asignación de roles en el ámbito especificado. |
Microsoft.Authorization/roleAssignments/write |
Crea una asignación de roles en el ámbito especificado. |
Microsoft.Authorization/roleDefinitions/delete |
Elimina la definición de roles personalizada especificada. |
Microsoft.Authorization/roleDefinitions/write |
Crea o actualiza una definición de roles personalizada con permisos especificados y ámbitos asignables. |