Compartir vía


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 control de acceso basado en rol se ha ampliado para admitir acciones tanto del plano de control como del plano de datos

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.

Pasos siguientes