Consideraciones de seguridad para las condiciones de asignación de roles de Azure en Azure Blob Storage

2025-05-05

Para proteger completamente los recursos mediante el control de acceso basado en atributos de Azure (Azure ABAC), también debe proteger los atributos usados en las condiciones de asignación de roles de Azure. Por ejemplo, si la condición se basa en una ruta de acceso de archivo, debe tener en cuenta que el acceso podría verse comprometido si la entidad de seguridad tiene un permiso sin restricciones para cambiar el nombre de una ruta de acceso de archivo.

En este artículo se describen las consideraciones de seguridad que debe tener en cuenta en las condiciones de asignación de roles.

Importante

Actualmente, el control de acceso basado en atributos de Azure (Azure ABAC) está disponible con carácter general para controlar el acceso solo a Azure Blob Storage, Azure Data Lake Storage Gen2 y Azure Queues mediante los atributos request, resource, environment y principal en el nivel de rendimiento de las cuentas de almacenamiento premium y estándar. Actualmente, el atributo de recurso de metadatos del contenedor y el atributo de solicitud de inclusión de blobs de lista se encuentran en VERSIÓN PRELIMINAR. Para información completa sobre el estado de las características de ABAC para Azure Storage, consulte Estado de las características de condición en Azure Storage.

Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure para conocer los términos legales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general.

Uso de otros mecanismos de autorización

Las condiciones de asignación de roles solo se evalúan cuando se usa RBAC de Azure para la autorización. Estas condiciones se pueden omitir si permite el acceso mediante métodos de autorización alternativos:

De forma similar, las condiciones no se evalúan cuando se concede acceso mediante listas de control de acceso (ACL) en cuentas de almacenamiento con un espacio de nombres jerárquico (HNS).

Puede impedir la autorización de SAS de nivel de cuenta, clave compartida y SAS de nivel de servicio deshabilitando la autorización de clave compartida para la cuenta de almacenamiento. Dado que SAS de Delegación de Usuarios depende de Azure RBAC, las condiciones de asignación de roles se evalúan al utilizar este método de autorización.

Protección de atributos de almacenamiento usados en condiciones

Ruta del blob

Al utilizar la ruta de acceso del blob como atributo @Resource para una condición, también debe evitar que los usuarios renombren un blob para obtener acceso a un archivo cuando utilicen cuentas con un espacio de nombres jerárquico. Por ejemplo, si desea crear una condición basada en la ruta de acceso del blob, también debe restringir el acceso del usuario a las siguientes acciones:

Acción	Descripción
`Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action`	Esta acción permite a los clientes cambiar el nombre de un archivo mediante path Create API.
`Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action`	Esta acción permite el acceso a diversas operaciones del sistema de archivos y de rutas.

Etiquetas de índice de blobs

Las etiquetas de índice de blobs se usan como atributos de forma libre para las condiciones en el almacenamiento. Si crea alguna condición de acceso mediante estas etiquetas, también debe proteger las propias etiquetas. En concreto, Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write DataAction permite a los usuarios modificar las etiquetas en un objeto de almacenamiento. Puede restringir esta acción para impedir que los usuarios manipule una clave o un valor de etiqueta para obtener acceso a objetos no autorizados.

Además, si se usan etiquetas de índice de blobs en las condiciones, los datos podrían ser vulnerables si dichos datos y las etiquetas de índice asociadas se actualizan en distintas operaciones. Puede usar condiciones @Request en las operaciones de escritura en blobs para requerir que las etiquetas de índice se configuren en la misma operación de actualización. Este enfoque puede ayudar a proteger los datos desde el instante en que se escriben en el almacenamiento.

Etiquetas en blobs copiados

De forma predeterminada, las etiquetas de índice de blobs no se copian de un blob de origen al destino cuando se usa Copy Blob API o cualquiera de sus variantes. Para conservar el ámbito de acceso del blob tras la copia, se deben copiar también las etiquetas.

Etiquetas en instantáneas

Las etiquetas de las instantáneas de blob no se pueden modificar. Por lo tanto, debe actualizar las etiquetas de un blob antes de tomar la instantánea. Si modifica las etiquetas de un blob base, las etiquetas de su instantánea seguirán teniendo su valor anterior.

Si se modifica una etiqueta en un blob base después de tomar una instantánea, el ámbito de acceso puede ser diferente para el blob base y la instantánea.

Etiquetas en versiones de blobs

Las etiquetas de índice de blobs no se copian cuando se crea una versión de blob mediante las API Put Blob, Put Block List o Copy Blob. Puede especificar etiquetas a través del encabezado de estas API.

Las etiquetas se pueden establecer individualmente en un blob base actual y en cada versión del blob. Al modificar etiquetas en un blob base, las etiquetas de las versiones anteriores no se actualizan. Si desea cambiar el ámbito de acceso de un blob y todas sus versiones mediante etiquetas, debe actualizar las etiquetas en cada versión.

Limitaciones de consulta y filtrado de versiones e instantáneas

Cuando se usan etiquetas para consultar y filtrar blobs en un contenedor, solo los blobs base se incluyen en la respuesta. No se incluyen las versiones del blob ni las instantáneas con las claves y los valores solicitados.

Roles y permisos

Si usa condiciones de asignación de roles para roles integrados de Azure, debería revisar detenidamente todos los permisos que el rol concede a un principal.

Asignaciones de roles heredadas

Las asignaciones de roles se pueden configurar para un grupo de administración, una suscripción, un grupo de recursos, una cuenta de almacenamiento o un contenedor, y se heredan en cada nivel en el orden indicado. Azure RBAC tiene un modelo aditivo, por lo que los permisos efectivos son la suma de las asignaciones de roles en cada nivel. Si una entidad de seguridad tiene asignado el mismo permiso mediante varias asignaciones de roles, el acceso de una operación que usa ese permiso se evalúa por separado para cada asignación en cada nivel.

Dado que las condiciones se implementan como condiciones en las asignaciones de roles, cualquier asignación de roles incondicional puede permitir a los usuarios omitir la condición. Supongamos que asigna el rol Colaborador de datos de Storage Blob a un usuario para una cuenta de almacenamiento y en una suscripción, pero agrega una condición solo a la asignación de la cuenta de almacenamiento. El resultado es que el usuario tiene acceso sin restricciones a la cuenta de almacenamiento a través de la asignación de roles en el nivel de suscripción.

Por lo tanto, debe aplicar condiciones de forma coherente para todas las asignaciones de roles en una jerarquía de recursos.

Otras consideraciones

Operaciones de condición que escriben blobs

Muchas de las operaciones de escritura de blobs requieren el permiso Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write o Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action. Los roles integrados, como Propietario de datos de Storage Blob y Colaborador de datos de Storage Blob, conceden ambos permisos a una entidad de seguridad.

Al definir una condición para la asignación de roles, debe usar condiciones idénticas en ambos permisos para garantizar restricciones de acceso consistentes para las operaciones de escritura.

Comportamiento de Copy Blob y Copy Blob from URL

Para las operaciones Copy Blob y Copy Blob From URL, las condiciones que utilizan la ruta del blob como atributo en la acción @Request y sus suboperaciones solo se evalúan para el blob de destino.

En el caso de las condiciones del blob de origen, se evalúan las condiciones @Resource de la acción Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/read.