Compartir vía


¿Qué es el control de acceso basado en atributos de Azure (Azure ABAC)?

El control de acceso basado en atributos (ABAC) es un sistema de autorización que define el acceso en función de los atributos asociados a las entidades de seguridad, los recursos y el entorno de una solicitud de acceso. Con ABAC, puede conceder a una entidad de seguridad acceso a un recurso en función de los atributos. Azure ABAC hace referencia a la implementación del control de acceso basado en atributos para Azure.

¿Qué son las condiciones de asignación de roles?

El control de acceso basado en roles de Azure (Azure RBAC) es un sistema de autorización que ayuda a administrar quién tiene acceso a los recursos de Azure, qué puede hacer con esos recursos y a qué áreas puede acceder. En la mayoría de los casos, Azure RBAC proporcionará la administración de acceso que necesita mediante definiciones de roles y asignaciones de roles. Pero en algunos casos es posible que quiera proporcionar una administración de acceso más precisa o simplificar la administración de cientos de asignaciones de roles.

Azure ABAC se basa en Azure RBAC con la adición de condiciones de asignación de roles basadas en atributos en el contexto de acciones específicas. Una condición de asignación de roles es una comprobación adicional que puede agregar opcionalmente a la asignación de roles para proporcionar un control de acceso más preciso. Una condición filtra los permisos concedidos como parte de la definición de roles y la asignación de roles. Por ejemplo, puede agregar una condición que requiera que un objeto tenga una etiqueta específica para leer el objeto. No se puede denegar explícitamente el acceso a recursos específicos mediante condiciones.

¿Por qué usar condiciones?

El uso de condiciones de asignación de roles ofrece tres ventajas principales:

  • Proporcionar un control de acceso más preciso: una asignación de roles usa una definición de roles con acciones y acciones de datos para conceder permisos a una entidad de seguridad. Puede escribir condiciones para filtrar esos permisos para un control de acceso más preciso. También puede agregar condiciones a acciones específicas. Por ejemplo, puede conceder a John acceso de lectura a los blobs de la suscripción solo si los blobs tienen la etiqueta Project=Blue.
  • Ayudar a reducir el número de asignaciones de roles: cada suscripción de Azure tiene actualmente un límite de asignación de roles. Hay escenarios que requieren miles de asignaciones de roles. Todas esas asignaciones de roles tendrían que administrarse. En estos escenarios, podría agregar condiciones para usar una cantidad de asignaciones de roles considerablemente menor.
  • Usar atributos que tienen un significado empresarial específico: las condiciones le permiten usar atributos que tienen un significado empresarial específico en el control de acceso. Algunos ejemplos de atributos son el nombre del proyecto, la fase de desarrollo de software y los niveles de clasificación. Los valores de estos atributos de recursos son dinámicos y cambian a medida que los usuarios se mueven entre equipos y proyectos.

Escenarios de ejemplo para condiciones

Hay varios escenarios en los que es posible que desee agregar una condición a la asignación de roles. Estos son algunos ejemplos.

  • Acceso de lectura a blobs con la etiqueta Project=Cascade.
  • Nuevos blobs que deben incluir la etiqueta Project=Cascade.
  • Blobs existentes que deben etiquetarse con al menos una clave de proyecto o clave de programa.
  • Blobs existentes que deben etiquetarse con una clave de proyecto y los valores Cascade, Baker o Skagit.
  • Lectura, escritura o eliminación de blobs en contenedores denominados blobs-example-container.
  • Acceso de lectura a blobs en contenedores denominados blobs-example-container con una ruta de acceso de solo lectura.
  • Acceso de escritura a blobs en contenedores denominados Contosocorp con una ruta de acceso de uploads/contoso.
  • Acceso de lectura a blobs con la etiqueta Program=Alpine y una ruta de acceso de registros.
  • Acceso de lectura a blobs con la etiqueta Project=Baker y el usuario tiene un atributo de coincidencia Project=Baker
  • Acceso de lectura a blobs durante un intervalo de fecha y hora específico.
  • Acceso de escritura a blobs solo a través de un vínculo privado o desde una subred específica.

A fin de obtener más información sobre cómo crear estos ejemplos, vea Ejemplo de condiciones de asignación de roles de Azure para Blob Storage.

¿Dónde se pueden agregar condiciones?

Actualmente, se pueden agregar condiciones a asignaciones de roles integradas o personalizadas que tienen acciones de datos de Blob Storage o Queue Storage. Las condiciones se agregan en el mismo ámbito que la asignación de roles. Al igual que con las asignaciones de roles, debe tener permisos Microsoft.Authorization/roleAssignments/write para agregar una condición.

Estos son algunos de los atributos de Blob Storage que puede usar en sus condiciones.

  • Nombre de cuenta
  • Etiquetas de índice de blobs
  • Ruta del blob
  • Prefijo de blobs
  • Nombre del contenedor
  • Nombre del ámbito de cifrado
  • Es la versión actual
  • Está habilitado un espacio de nombres jerárquico
  • Es un vínculo privado
  • Instantánea
  • UTC ahora (la fecha y hora actuales en hora universal coordinada)
  • Id. de la versión

¿Qué aspecto tiene una condición?

Puede agregar condiciones a asignaciones de roles nuevas o existentes. Este es el rol Lector de datos de blobs de almacenamiento que se ha asignado a un usuario denominado Chandra en un ámbito de grupo de recursos. También se ha agregado una condición que solo permite el acceso de lectura a blobs con la etiqueta Project=Cascade.

Diagrama de asignación de roles con una condición.

Si Chandra intenta leer un blob sin la etiqueta Project=Cascade, no se permitirá el acceso.

Diagrama de acceso no permitido con una condición.

Este es el aspecto de la condición en Azure Portal:

Captura de pantalla del editor de condiciones de Azure Portal que muestra la sección de creación de expresiones con valores para las etiquetas de índice de blob.

Este es el aspecto de la condición en el código:

(
    (
        !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'}
        AND NOT
        SubOperationMatches{'Blob.List'})
    )
    OR
    (
        @Resource[Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags:Project<$key_case_sensitive$>] StringEqualsIgnoreCase 'Cascade'
    )
)

Para más información sobre el formato de las condiciones, consulte Sintaxis y formato de las condiciones de asignación de roles de Azure.

Estado de las características de condición

En la tabla siguiente se muestra el estado de las características de condición:

Característica Status Date
Uso de atributos de entorno en una condición GA Abril de 2024
Agregar condiciones mediante el editor de condiciones en Azure Portal GA Octubre de 2022
Agregar condiciones mediante Azure PowerShell, la CLI de Azure o la API REST Disponibilidad general Octubre de 2022
Usar atributos de recursos y solicitud para combinaciones específicas de recursos de almacenamiento de Azure, tipos de atributos de acceso y niveles de rendimiento de la cuenta de almacenamiento. Para más información, consulte Estado de las características de condición en Azure Storage. Disponibilidad general Octubre de 2022
Uso de atributos de seguridad personalizados en una entidad de seguridad en una condición GA noviembre de 2023

Condiciones y Microsoft Entra PIM

También puede agregar condiciones a las asignaciones de roles que cumplan los requisitos mediante Microsoft Entra Privileged Identity Management (Microsoft Entra PIM) para los recursos de Azure. Con Microsoft Entra PIM, los usuarios finales deben activar una asignación de roles apta para obtener permiso para realizar determinadas acciones. El uso de condiciones en Microsoft Entra PIM permite no solo limitar el acceso de un usuario a un recurso mediante condiciones específicas, sino también usar Microsoft Entra PIM para protegerlo con una configuración de límite de tiempo, un flujo de trabajo de aprobación y un registro de auditoría, entre otros. Para más información, vea Asignación de roles de recursos de Azure en Privileged Identity Management.

Terminología

Para comprender mejor Azure RBAC y Azure ABAC, puede consultar la siguiente lista de términos.

Término Definición
control de acceso basado en atributos (ABAC) Sistema de autorización que define el acceso en función de los atributos asociados a las entidades de seguridad, los recursos y el entorno. Con ABAC, puede conceder a una entidad de seguridad acceso a un recurso en función de los atributos.
Azure ABAC Hace referencia a la implementación del control de acceso basado en atributos para Azure.
condición de asignación de roles Comprobación adicional que puede agregar opcionalmente a la asignación de roles para proporcionar un control de acceso más preciso.
atributo En este contexto, un par clave-valor como Project=Blue, donde Project es la clave de atributo y Blue es el valor del atributo. Los atributos y etiquetas son sinónimos en lo que respecta al control de acceso.
expresión Instrucción en una condición que se evalúa como true o false. Una expresión tiene el formato de <valor> de <operador> de <atributo>.

Límites

Estos son algunos de los límites de las condiciones.

Resource Límite Notas
Número de expresiones por condición al usar el editor visual 5 Puede agregar más de cinco expresiones mediante el editor de código.

Problemas conocidos

Estos son los problemas conocidos de las condiciones:

  • Si usa Microsoft Entra Privileged Identity Management (PIM) y atributos de seguridad personalizados, la Entidad de seguridad no aparece en el origen del atributo al agregar una condición.

Pasos siguientes