Uso de roles para controlar el acceso a los recursos
Roles integrados de recursos de Azure (uso de PowerShell)
Azure proporciona varios roles integrados para cubrir los escenarios de seguridad más comunes. Para entender cómo funcionan los roles, vamos a examinar tres roles que son válidos en cualquier tipo de recurso:
- Propietario: tiene acceso total a todos los recursos, incluido el derecho a delegar este acceso a otros.
- Colaborador: puede crear y administrar todos los tipos de recursos de Azure, pero no puede conceder acceso a otros.
- Lector: puede ver los recursos existentes de Azure.
Definiciones de roles
Cada rol es un conjunto de propiedades definido en un archivo de notación de objetos JavaScript (JSON). Esta definición de roles incluye un nombre, un identificador y una descripción. También incluye los permisos que pueden concederse (Actions), los que no (NotActions) y el ámbito del rol (por ejemplo, acceso de lectura).
Por ejemplo, el rol Propietario incluye todas las acciones, lo que se indica mediante un asterisco (*); no se deniega ninguna acción, y se incluyen todos los ámbitos, lo cual se señala mediante una barra diagonal (/).
Esta información se puede obtener mediante el cmdlet Get-AzRoleDefinition Owner de PowerShell.
Get-AzRoleDefinition Owner
Este código debe generar la siguiente salida:
Name : Owner
Id : 8e3af657-a8ff-443c-a75c-2fe8c4bcb635
IsCustom : False
Description : Lets you manage everything, including access to resources.
Actions : {*}
NotActions : {}
DataActions : {}
NotDataActions : {}
AssignableScopes : {/}
Pruebe lo mismo con los roles Colaborador y Lector para ver las acciones permitidas y denegadas.
Examen de los roles integrados
Ahora, vamos a explorar algunos otros roles integrados.
Abra Azure Portal.
En la página principal de Azure, seleccione Grupos de recursos en el menú de la izquierda.
Seleccione un grupo de recursos. Aparece el panel de su grupo de recursos.
En el panel del menú de la izquierda, seleccione Control de acceso (IAM). El panel Control de acceso (IAM) aparece para su grupo de recursos.
En la barra de menús interior, seleccione la pestaña Roles, como se muestra a continuación, para ver la lista de roles disponibles.
¿Qué es una definición de roles?
Una definición de roles es una colección de permisos. Una definición de rol enumera las operaciones que puede realizar el rol, como leer, escribir y eliminar. También puede enumerar las operaciones que no se pueden realizar u operaciones relacionadas con datos subyacentes.
Como se ha descrito anteriormente, una definición de roles tiene la siguiente estructura:
| Nombre | Descripción |
|---|---|
Id |
Identificador único del rol, asignado por Azure. |
IsCustom |
True si se trata de un rol personalizado, False si es un rol integrado. |
Description |
Descripción del rol que se puede leer. |
Actions [] |
Permisos permitidos; * indica todos. |
NotActions [] |
Permisos denegados. |
DataActions [] |
Permisos específicos permitidos según se aplican a los datos, por ejemplo, Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read |
NotDataActions [] |
Permisos específicos denegados según se aplican a los datos. |
AssignableScopes [] |
Ámbitos en los que se aplica este rol; / indica global, pero puede llegar a un árbol jerárquico. |
Esta estructura se representa como JSON cuando se usa en el control de acceso basado en rol (RBAC) o desde la API subyacente. Por ejemplo, esta es la definición de roles Colaborador en formato JSON.
{
"Name": "Contributor",
"Id": "b24988ac-6180-42a0-ab88-20f7382dd24c",
"IsCustom": false,
"Description": "Lets you manage everything except access to resources.",
"Actions": [
"*"
],
"NotActions": [
"Microsoft.Authorization/*/Delete",
"Microsoft.Authorization/*/Write",
"Microsoft.Authorization/elevateAccess/Action"
],
"DataActions": [],
"NotDataActions": [],
"AssignableScopes": [
"/"
]
}
Actions y NotActions
Las propiedades Actions y NotActions se pueden personalizar para conceder y denegar exactamente los permisos que se necesitan. Estas propiedades siempre se presentan con el siguiente formato: {Company}.{ProviderName}/{resourceType}/{action}.
Por ejemplo, estas son las acciones de los tres roles que examinamos antes:
| Rol integrado | Actions | NotActions |
|---|---|---|
| Propietario (se permiten todas las acciones) | * |
- |
| Colaborador (se permiten todas las acciones, excepto escribir o eliminar asignaciones de roles) | * |
Microsoft.Authorization/*/Delete, Microsoft.Authorization/*/Write, Microsoft.Authorization/elevateAccess/Action |
| Lector (se permiten todas las acciones de lectura) | */read |
- |
La operación de carácter comodín (*) en Actions indica que la entidad de seguridad asignada a este rol puede realizar todas las acciones; o en otras palabras, este rol puede administrar todo, incluidas las acciones definidas en el futuro, a medida que Azure agrega nuevos tipos de recursos. Con el rol Lector, solo se permite la acción read.
Las operaciones en NotActions se quitan de Actions. Con el rol Colaborador, NotActions quita la capacidad de este rol para administrar y asignar el acceso a los recursos.
DataActions y NotDataActions
Las operaciones de datos se especifican en las propiedades DataActions y NotDataActions. Puede especificar operaciones de datos de forma independiente de las operaciones de administración. Con ello, se evita que las asignaciones de roles actuales con caracteres comodín (*) tengan acceso a los datos de repente. A continuación se indican algunas operaciones 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
Solo puede agregar operaciones de datos a las propiedades DataActions y NotDataActions. Los proveedores de recursos identifican qué operaciones son operaciones de datos, estableciendo para ello la propiedad isDataAction en true. Los roles que no tienen operaciones de datos pueden omitir estas propiedades de la definición de roles.
Estas acciones funcionan exactamente como sus equivalentes de administración. Puede especificar las acciones que quiere permitir (o *, si son todas) y, después, proporcionar una lista de acciones específicas para quitarlas de la colección NotDataActions. Aquí mostramos algunos ejemplos; puede encontrar la lista completa de acciones y acciones de datos en la documentación del proveedor de recursos:
| Operación de datos | Descripción |
|---|---|
Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete |
Elimina datos de blob. |
Microsoft.Compute/virtualMachines/login/action |
Inicia sesión en una máquina virtual como un usuario normal. |
Microsoft.EventHub/namespaces/messages/send/action |
Envía mensajes a un centro de eventos. |
Microsoft.Storage/storageAccounts/fileServices/fileshares/files/read |
Devuelve un archivo o una carpeta, o bien una lista de archivos o carpetas. |
Microsoft.Storage/storageAccounts/queueServices/queues/messages/read |
Lee un mensaje de una cola. |
Ámbitos asignables
La definición de las propiedades Actions y NotActions no basta para implementar un rol por completo. También hay que especificar debidamente el ámbito del rol.
La propiedad AssignableScopes del rol especifica los ámbitos (suscripciones, grupos de recursos o recursos) dentro de los que dicho rol está disponible para su asignación. Puede permitir que el rol personalizado esté disponible para su asignación solamente en las suscripciones o los grupos de recursos que lo necesiten, evitando así saturar la experiencia de usuario con el resto de suscripciones o grupos de recursos.
Estos son algunos ejemplos:
| To | Ámbito que usar |
|---|---|
| Restringir a una suscripción | "/subscriptions/{sub-id}" |
| Restringir a un grupo de recursos específico de una suscripción específica | "/subscriptions/{sub-id}/resourceGroups/{rg-name}" |
| Restringir a un recurso específico | "/subscriptions/{sub-id}/resourceGroups/{rg-name}/{resource-name}" |
| Poner un rol disponible para su asignación en dos suscripciones | "/subscriptions/{sub-id}", "/subscriptions/{sub-id}" |
Crear roles
Microsoft Entra ID incluye roles integrados que probablemente cubran el 99 % de lo que todo el mundo quiere hacer. Si es posible, es preferible usar un rol integrado. pero puede crear roles personalizados si así lo precisa.
Nota:
La creación de roles personalizados requiere Microsoft Entra ID P1 o P2; no puede crear roles personalizados en el nivel gratis.
Puede crear un nuevo rol mediante varios mecanismos:
Azure Portal: Puede usar Azure Portal para crear un rol personalizado: seleccione Microsoft Entra ID>Roles y administradores>Nuevo rol personalizado.
Azure PowerShell: puede usar el cmdlet
New-AzRoleDefinitionpara definir un rol nuevo.Azure Graph API: se puede usar una llamada de REST a Graph API para crear un rol mediante programación.
La sección Resumen de este módulo incluye un vínculo a la documentación de los tres enfoques.