Compartir a través de

Creación de una SAS de delegación de usuarios

Importante

Para lograr una seguridad óptima, Microsoft recomienda usar el identificador de Entra de Microsoft con identidades administradas para autorizar solicitudes en datos de blobs, colas y tablas, siempre que sea posible. La autorización con el identificador de Entra de Microsoft e identidades administradas proporciona mayor seguridad y facilidad de uso a través de la autorización de clave compartida. Para obtener más información, consulte Autorizar con el identificador de Entra de Microsoft. Para más información sobre las identidades administradas, consulte ¿Qué son las identidades administradas para los recursos de Azure?

En el caso de los recursos hospedados fuera de Azure, como las aplicaciones locales, puede usar identidades administradas a través de Azure Arc. Por ejemplo, las aplicaciones que se ejecutan en servidores habilitados para Azure Arc pueden usar identidades administradas para conectarse a los servicios de Azure. Para más información, consulte Autenticación en recursos de Azure con servidores habilitados para Azure Arc.

Puede proteger un token de firma de acceso compartido (SAS) para acceder a un contenedor, directorio o blob mediante credenciales de Microsoft Entra o una clave de cuenta. Una SAS protegida con credenciales de Microsoft Entra se denomina delegación de usuarios SAS. Como procedimiento recomendado de seguridad, se recomienda usar las credenciales de Microsoft Entra siempre que sea posible, en lugar de la clave de cuenta, que se puede poner en peligro con mayor facilidad. Cuando el diseño de la aplicación requiera firmas de acceso compartido, use las credenciales de Microsoft Entra para crear una SAS de delegación de usuarios para ayudar a garantizar una mejor seguridad.

Todas las SAS están firmadas con una clave. Para crear una SAS de delegación de usuarios, primero debe solicitar una clave de delegación de usuario , que después se usa para firmar la SAS. La clave de delegación de usuarios es análoga a la clave de cuenta que se usa para firmar una SAS de servicio o una SAS de cuenta, salvo que se basa en las credenciales de Microsoft Entra. Para solicitar la clave de delegación de usuarios, llame a la operación obtener clave de delegación de usuario . A continuación, puede usar la clave de delegación de usuarios para crear la SAS.

Se soporta una delegación de usuario SAS para almacenamiento de blobs, almacenamiento de lagos de datos, almacenamiento en cola, almacenamiento en tablas o archivos Azure. Las directivas de acceso almacenadas no se admiten para una SAS de delegación de usuarios.

Cautela

Las firmas de acceso compartido son claves que conceden permisos a los recursos de almacenamiento y debe protegerlas igual que protegería una clave de cuenta. Es importante proteger una SAS del uso malintencionado o no deseado. Use discreción para distribuir una SAS y tener un plan en vigor para revocar una SAS en peligro. Las operaciones que usan firmas de acceso compartido solo deben realizarse a través de una conexión HTTPS y los URI de firma de acceso compartido solo deben distribuirse en una conexión segura, como HTTPS.

Para obtener información sobre el uso de la clave de cuenta para proteger una SAS, consulte Creación de una saS de servicio y creación de una saS de cuenta.

Soporte SAS para delegación de usuarios para acceso con alcance de directorio (solo almacenamiento en blob y almacenamiento en lago de datos)

Una SAS de delegación de usuarios admite el ámbito de directorio (sr=d) cuando la versión de autorización (sv) es 2020-02-10 o posterior y está habilitado un espacio de nombres jerárquico (HNS). La semántica del ámbito de directorio (sr=d) es similar al ámbito de contenedor (sr=c), excepto que el acceso está restringido a un directorio y a los archivos y subdirectorios que contiene. Cuando se especifica sr=d, también se requiere el parámetro de consulta sdd.

El formato de cadena a signo para la versión de autorización 2020-02-10 no cambia.

Soporte SAS para delegación de usuario para un OID de usuario (solo almacenamiento de blob y almacenamiento en lago de datos)

SAS de delegación de usuarios admite un identificador de objeto de usuario (OID) opcional que se lleva en el parámetro saoid o suoid cuando la versión de autorización (sv) es 2020-02-10 o posterior. Los parámetros saoid y suoid corresponden a la entidad de seguridad del usuario final que usa la SAS y proporcionan un modelo de autorización mejorado para cargas de trabajo de clúster de varios usuarios, como Hadoop y Spark.

Los tokens de SAS se pueden restringir a una operación específica del sistema de archivos y al usuario, lo que proporciona un token de acceso menos vulnerable que es más seguro para distribuirse en un clúster de varios usuarios. Un caso de uso de estas características es la integración del controlador ABFS de Hadoop con Apache Ranger.

Para obtener más información sobre los parámetros opcionales saoid y suoid, consulte Especificar un identificador de objeto de usuario firmado.

Autorización de una SAS de delegación de usuarios

Cuando un cliente accede a un recurso de Blob Storage con una SAS de delegación de usuarios, la solicitud a Azure Storage se autoriza con las credenciales de Microsoft Entra que se usaron para crear la SAS. El acceso del cliente al recurso viene determinado por los permisos siguientes:

  • Permisos de control de acceso basado en rol (RBAC) que se conceden a la entidad de seguridad de Microsoft Entra que solicitó la clave de delegación de usuarios.
  • Permisos de la lista de control de acceso (ACL) POSIX que se conceden a la entidad de seguridad que solicitó la clave de delegación de usuarios. Esta comprobación adicional solo se produce cuando los permisos de RBAC no pueden conceder acceso y solo cuando el espacio de nombres jerárquico está habilitado en la cuenta de almacenamiento.
  • Permisos que se conceden explícitamente en el token de SAS.

Este enfoque proporciona un nivel adicional de seguridad y le ayuda a evitar tener que almacenar la clave de acceso de la cuenta con el código de la aplicación. Por estos motivos, la creación de una SAS mediante credenciales de Microsoft Entra es un procedimiento recomendado de seguridad.

Los permisos concedidos a un cliente que posee la SAS son la intersección de los permisos concedidos a la entidad de seguridad que solicitó la clave de delegación de usuarios y los permisos concedidos al recurso en el token de SAS mediante el campo signedPermissions (sp). Si no se concede ningún permiso a la entidad de seguridad a través de ACL de RBAC o POSIX en el token de SAS, ese permiso no se concede al cliente que intenta usar la SAS para acceder al recurso. Al crear una SAS de delegación de usuarios, asegúrese de que los permisos concedidos a través de ACL de RBAC y POSIX y los permisos concedidos a través del token de SAS se alinean con el nivel de acceso que requiere el cliente.

Para crear una SAS de delegación de usuarios, haga lo siguiente:

  1. Use ACL de RBAC o POSIX para conceder los permisos deseados a la entidad de seguridad que solicitará la clave de delegación de usuarios.
  2. Adquiera un token de OAuth 2.0 de Microsoft Entra ID.
  3. Use el token para solicitar la clave de delegación de usuarios llamando a la operación Obtener clave de delegación de usuarios .
  4. Use la clave de delegación de usuarios para construir el token de SAS con los campos adecuados.

Asignación de permisos con RBAC

La entidad de seguridad que solicita la clave de delegación de usuarios debe tener los permisos adecuados para hacerlo. Una entidad de seguridad de Identificador de Entra de Microsoft puede ser un usuario, un grupo, una entidad de servicio o una identidad administrada.

Para solicitar la clave de delegación de usuario, debes asignar a un principal de seguridad la acción Microsoft.Storage/storageAccounts/{serviceType}/generateUserDelegationKey . Los siguientes roles integrados de RBAC incluyen la acción Microsoft.Storage/storageAccounts/{serviceType}/generateUserDelegationKey , ya sea explícita o como parte de una definición comodín:

Dado que la operación Obtener clave de delegación de usuarios actúa en el nivel de la cuenta de almacenamiento, el Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey acción debe tener el ámbito en el nivel de la cuenta de almacenamiento, el grupo de recursos o la suscripción. Si a la entidad de seguridad se le asigna cualquiera de los roles integrados o a un rol personalizado que incluye el Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey acción, en el nivel de la cuenta de almacenamiento, el grupo de recursos o la suscripción, la entidad de seguridad puede solicitar la clave de delegación de usuario.

Si al principal de seguridad se le asigna un rol que permite el acceso a datos pero está limitado al nivel de un contenedor, puedes además asignar el rol de Delegador de Almacenamiento (como Delegador de Blob de Almacenamiento) al principal de seguridad a nivel de cuenta de almacenamiento, grupo de recursos o suscripción. El rol de Delegador de Almacenamiento otorga permisos al principal de seguridad para solicitar la clave de delegación de usuario.

Para obtener más información sobre los roles de RBAC para Azure Storage, consulte Autorizar con Microsoft Entra.

Adquisición de un token de OAuth 2.0

Para obtener la clave de delegación de usuarios, primero solicite un token de OAuth 2.0 de Microsoft Entra ID. Proporcione el token con el esquema bearer para autorizar la llamada a la operación Obtener clave de delegación de usuarios. Para obtener más información sobre cómo solicitar un token de OAuth desde el id. de Microsoft Entra, consulte flujos de autenticación y escenarios de aplicación.

Solicitud de la clave de delegación de usuarios

Una llamada a la operación Obtener clave de delegación de usuarios devuelve la clave como un conjunto de valores que se usan como parámetros en el token de SAS de delegación de usuarios. Estos parámetros se describen en la referencia Get User Delegation Key y en la siguiente sección, Construir un SAS de delegación de usuario.

Cuando un cliente solicita una clave de delegación de usuarios mediante un token de OAuth 2.0, Azure Storage devuelve la clave de delegación de usuarios en nombre de la entidad de seguridad. A la SAS creada con la clave de delegación de usuarios se le conceden los permisos que se conceden a la entidad de seguridad.

Una vez que tenga la clave de delegación de usuarios, puede usarla para crear cualquier número de firmas de acceso compartido de delegación de usuarios durante la vigencia de la clave. La clave de delegación de usuarios es independiente del token de OAuth 2.0 que se usa para adquirirlo, por lo que no es necesario renovar el token siempre y cuando la clave siga siendo válida. Puede especificar que la clave es válida durante un período de hasta siete días.

Construcción de una SAS de delegación de usuarios

En la tabla siguiente se resumen los campos que se admiten para un token de SAS de delegación de usuarios. En las secciones posteriores se proporcionan detalles adicionales sobre cómo especificar estos parámetros.

Nombre del campo SAS Parámetro del token de SAS Obligatorio o opcional Compatibilidad con versiones Descripción
signedVersion sv Obligatorio 2018-11-09 y versiones posteriores Indica la versión del servicio que se usa para construir el campo de firma. También especifica la versión del servicio que controla las solicitudes realizadas con esta SAS.
signedResource sr Obligatorio Todo Solo almacenamiento de blobs o archivos de Azure. Especifica qué recursos son accesibles mediante la firma de acceso compartido.
signedStart st Opcional Todo Opcional. Hora en que la firma de acceso compartido es válida, expresada en uno de los formatos ISO 8601 UTC aceptados. Si se omite este valor, la hora UTC actual se usa como hora de inicio. Para obtener más información sobre los formatos UTC aceptados, vea Formato de valores DateTime.
signedExpiry se Obligatorio Todo Hora en que la firma de acceso compartido deja de ser válida, expresada en uno de los formatos ISO 8601 UTC aceptados. Para obtener más información sobre los formatos UTC aceptados, vea Formato de valores DateTime.
signedPermissions sp Obligatorio Todo Indica qué operaciones puede realizar un cliente que posee la SAS en el recurso. Los permisos se pueden combinar.
signedIp sip Opcional 2015-04-05 y versiones posteriores Especifica una dirección IP o un intervalo inclusivo de direcciones IP desde las que se van a aceptar solicitudes. Al especificar un intervalo, tenga en cuenta que el intervalo es inclusivo. Solo se admiten direcciones IPv4.

Por ejemplo, sip=198.51.100.0 o sip=198.51.100.10-198.51.100.20.
signedProtocol spr Opcional 2015-04-05 y versiones posteriores Especifica el protocolo permitido para una solicitud realizada con la SAS. Incluya este campo para requerir que las solicitudes realizadas con el token de SAS usen HTTPS.
signedObjectId skoid Obligatorio 2018-11-09 y versiones posteriores Especifica el identificador de objeto de una entidad de seguridad de Microsoft Entra. Este identificador de objeto corresponde a la entidad de seguridad que solicitó la clave de delegación de usuarios.

Antes de autorizar la operación, Azure Storage comprueba los permisos de RBAC en el identificador de objeto. Si los permisos de RBAC no pueden conceder acceso, Azure Storage comprueba los permisos de ACL POSIX en el identificador de objeto.
signedTenantId sktid Obligatorio 2018-11-09 y versiones posteriores Especifica el inquilino de Microsoft Entra en el que se define una entidad de seguridad.
signedKeyStartTime skt Obligatorio. 2018-11-09 y versiones posteriores La operación obtener clave de delegación de usuario devuelve el valor. Indica el inicio de la vigencia de la clave de delegación de usuarios, expresada en uno de los formatos ISO 8601 UTC aceptados. Para obtener más información sobre los formatos UTC aceptados, vea Formato de valores DateTime.
signedKeyExpiryTime ske Obligatorio 2018-11-09 y versiones posteriores La operación obtener clave de delegación de usuario devuelve el valor. Indica el final de la duración de la clave de delegación de usuarios, expresada en uno de los formatos ISO 8601 UTC aceptados. Para obtener más información sobre los formatos UTC aceptados, vea Formato de valores DateTime.
signedKeyVersion skv Obligatorio 2018-11-09 y versiones posteriores La operación obtener clave de delegación de usuario devuelve el valor. Especifica la versión del servicio de almacenamiento que se usó para obtener la clave de delegación de usuarios. Este campo debe especificar la versión 2018-11-09 o posterior.
signedKeyService sks Obligatorio 2018-11-09 y versiones posteriores Indica el servicio para el que la clave de delegación de usuarios es válida. Actualmente, solo se admite Blob Storage.
signedAuthorizedObjectId saoid Opcional 2020-02-10 y versiones posteriores Solo almacenamiento en blobs. Especifica el identificador de objeto de una entidad de seguridad de Microsoft Entra autorizada por el propietario de la clave de delegación de usuarios para realizar la acción concedida por el token de SAS. Este identificador de objeto corresponde a la entidad de seguridad para el usuario final de la SAS. No se realiza ninguna comprobación de permisos adicional en las listas de control de acceso (ACL) POSIX.
signedUnauthorizedObjectId suoid Opcional 2020-02-10 y versiones posteriores Solo almacenamiento en blobs. Especifica el identificador de objeto de una entidad de seguridad de Microsoft Entra cuando se habilita un espacio de nombres jerárquico. Este identificador de objeto corresponde a la entidad de seguridad para el usuario final de la SAS. Azure Storage realiza una comprobación de ACL POSIX con el identificador de objeto antes de autorizar la operación.
signedCorrelationId scid Opcional 2020-02-10 y versiones posteriores Solo almacenamiento en blobs. Correlacionar los registros de auditoría de almacenamiento con los registros de auditoría que usa la entidad de seguridad que genera y distribuye la SAS.
signedKeyDelegatedUserTenantId skdutid Opcional 05-07-2025 y posteriores El ID de usuario final delegado en Microsoft Entra. Esta es la afirmación "tid" en el token portador de Microsoft Entra. Esto solo es necesario para tokens SAS de delegación de usuario vinculados al usuario. Solo cuando DelegatedUserTid se especifica en UserDelegationKey, este campo es necesario.
signedDelegatedUserObjectId sduoid Opcional 05-07-2025 y posteriores El ID de objeto del usuario final delegado en Microsoft Entra. Esta es la afirmación "oid" en el token portador de Microsoft Entra. Esto solo es necesario para tokens SAS de delegación de usuario vinculados al usuario.
signedRequestHeaders srh Opcional 2026-04-06 y posteriores Solo almacenamiento en blobs. Lista los nombres de cabecera separados por comas que deben estar presentes en la solicitud cuando se utiliza el SAS. Azure Storage valida los valores de cabecera utilizando la forma canónica en la cadena a signar.
signedRequestQueryParameters srq Opcional 2026-04-06 y posteriores Solo almacenamiento en blobs. Lista los nombres de parámetros de consulta separados por comas que deben estar presentes en la solicitud cuando se utiliza el SAS. Azure Storage valida los valores de los parámetros utilizando la forma canónica en la cadena a signo.
signedDirectoryDepth sdd Obligatorio cuando sr=d 2020-02-10 y versiones posteriores Solo almacenamiento en blobs. Indica el número de directorios dentro de la carpeta raíz del directorio especificado en el campo canonicalizedResource de la cadena a signo.
signedEncryptionScope ses Opcional 2020-12-06 y versiones posteriores Solo almacenamiento en blobs. Indica el ámbito de cifrado que se va a usar para cifrar el contenido de la solicitud.
tableName tn Obligatorio 05-07-2025 y posteriores Solo mesa. El nombre de la mesa para compartir.
startPk 2

startRk 2		 spk

srk		 Opcional 05-07-2025 y posteriores Solo almacenamiento en mesa.

Opcional, pero startPk debe acompañar startRka . Las claves mínimas de partición y fila accesibles con esta firma de acceso compartida. Los valores clave son inclusivos. Si se omiten, no hay un límite inferior en las entidades de la tabla al que se pueda acceder.
endPk 2

endRk 2		 epk

erk		 Opcional 05-07-2025 y posteriores Solo almacenamiento en mesa.

Opcional, pero endPk debe acompañar endRka . Las claves de partición y fila máximas accesibles con esta firma de acceso compartida. Los valores clave son inclusivos. Si se omiten, no hay un límite superior en las entidades de la tabla al que se pueda acceder.
signature sig Obligatorio Todo La firma es un código de autenticación de mensajes basado en hash (HMAC) que se calcula en la cadena a signo y la clave mediante el algoritmo SHA256 y, a continuación, se codifica mediante la codificación Base64.
encabezado de respuesta Cache-Control rscc Opcional 2013-08-15 y versiones posteriores Solo almacenamiento de blobs o archivos de Azure. Azure Storage establece el encabezado de respuesta Cache-Control en el valor especificado en el token de SAS.
encabezado de respuesta Content-Disposition rscd Opcional 2013-08-15 y versiones posteriores Solo almacenamiento de blobs o archivos de Azure. Azure Storage establece el encabezado de respuesta Content-Disposition en el valor especificado en el token de SAS.
encabezado de respuesta Content-Encoding rsce Opcional 2013-08-15 y versiones posteriores Solo almacenamiento de blobs o archivos de Azure. Azure Storage establece el encabezado de respuesta Content-Encoding en el valor especificado en el token de SAS.
encabezado de respuesta Content-Language rscl Opcional 2013-08-15 y versiones posteriores Solo almacenamiento de blobs o archivos de Azure. Azure Storage establece el encabezado de respuesta Content-Language en el valor especificado en el token de SAS.
encabezado de respuesta Content-Type rsct Opcional 2013-08-15 y versiones posteriores Solo almacenamiento de blobs o archivos de Azure. Azure Storage establece el encabezado de respuesta Content-Type en el valor especificado en el token de SAS.

Especificar el campo versión firmada

El campo signedVersion obligatorio (sv) especifica la versión del servicio para la firma de acceso compartido. Este valor indica la versión del servicio que se usa para construir el campo signature y especifica la versión del servicio que controla una solicitud realizada con esta firma de acceso compartido. El valor del campo sv debe ser la versión 2018-11-09 o posterior.

Especifica el campo de recurso firmado (solo almacenamiento de blobs)

El campo signedResource obligatorio (sr) especifica qué recursos son accesibles a través de la firma de acceso compartido. En la tabla siguiente se describe cómo hacer referencia a un recurso de blob, contenedor o directorio en el token de SAS:

Recurso Valor del parámetro Versiones admitidas Descripción
Masa amorfa b Todo Concede acceso al contenido y los metadatos del blob.
Versión del blob Bv 2018-11-09 y versiones posteriores Concede acceso al contenido y los metadatos de la versión del blob, pero no al blob base.
Instantánea de blob Bs 2018-11-09 y versiones posteriores Concede acceso al contenido y los metadatos de la instantánea de blob, pero no al blob base.
Contenedor c Todo Concede acceso al contenido y los metadatos de cualquier blob del contenedor y a la lista de blobs del contenedor.
Directorio d 2020-02-10 y versiones posteriores Concede acceso al contenido y los metadatos de cualquier blob del directorio y a la lista de blobs del directorio, en una cuenta de almacenamiento con un espacio de nombres jerárquico habilitado. Si se especifica un directorio para el campo signedResource, también se requiere el parámetro signedDirectoryDepth (sdd). Un directorio siempre está dentro de un contenedor.

Especifica el campo de recurso firmado (solo Azure Files)

El campo signedResource obligatorio (sr) especifica qué recursos son accesibles a través de la firma de acceso compartido. La siguiente tabla describe cómo referirse a un archivo o recurso compartido en el URI.

Nombre del campo Parámetro de consulta Descripción
signedResource sr Obligatorio.

Especifica f si el recurso compartido es un archivo. Hacerlo otorga acceso al contenido y metadatos del archivo.

Especifica s si el recurso compartido es un share. Hacerlo otorga acceso al contenido y metadatos de cualquier archivo en el share, así como a la lista de directorios y archivos del share.

Especificar parámetros de consulta para sobrescribir los encabezados de respuesta (solo Blob Storage y Azure Files)

Para definir valores para determinados encabezados de respuesta que se van a devolver cuando se usa la firma de acceso compartido en una solicitud, puede especificar encabezados de respuesta en parámetros de consulta. Esta función está soportada desde la versión 2013-08-15 para Blob Storage y la versión 2015-02-21 para Azure Files. Las firmas de acceso compartido que usan esta función deben incluir el sv parámetro establecido en 2013-08-15 o posterior para Blob Storage, o para 2015-02-21 o posterior para Azure Files.

Las cabeceras de respuesta y los parámetros correspondientes de consulta se enumeran en la siguiente tabla:

Nombre del encabezado de respuesta Parámetro de consulta SAS correspondiente
Cache-Control rscc
Content-Disposition rscd
Content-Encoding rsce
Content-Language rscl
Content-Type rsct

Por ejemplo, si especificas el rsct=binary parámetro de consulta en una firma de acceso compartido creada con la versión 2013-08-15 o posterior, la Content-Type cabecera de respuesta se establece en binary. Este valor anula el Content-Type valor de cabecera almacenado para el blob en una petición que solo usa esta firma de acceso compartido.

Si creas una firma de acceso compartido que especifica encabezados de respuesta como parámetros de consulta, debes incluirlos en la cadena de señales que se usa para construir la cadena de firma. Para más información, consulta la sección Especificar la firma más adelante en este artículo. Para ejemplos adicionales, véase ejemplos de SAS de servicio.

Especificar la duración de la validez de la firma

Los campos signedStart (st) y signedExpiry (se) indican los tiempos de inicio y expiración de la SAS. Se requiere el campo signedExpiry. El campo signedStart es opcional. Si se omite, la hora UTC actual se usa como hora de inicio.

Para una SAS de delegación de usuarios, los tiempos de inicio y expiración de la SAS deben estar dentro del intervalo definido para la clave de delegación de usuarios. Si un cliente intenta usar una SAS después de que la clave de delegación de usuarios haya expirado, la SAS producirá un error de autorización, independientemente de si la propia SAS sigue siendo válida.

Para obtener más información sobre los formatos UTC aceptados, vea Formato de valores DateTime.

Especificar el nombre de la tabla (solo almacenamiento de tabla)

El tableName campo especifica el nombre de la tabla a compartir.

Nombre del campo Parámetro de consulta Descripción
tableName tn Obligatorio. El nombre de la mesa para compartir.

Especificar permisos

Los permisos especificados para el campo signedPermissions (sp) en el token de SAS indican qué operaciones puede realizar un cliente que posee la SAS en el recurso.

Los permisos se pueden combinar para permitir que un cliente realice varias operaciones con la misma SAS. Al construir la SAS, debe incluir permisos en el orden siguiente:

racwdxltmeop

Algunos ejemplos de opciones de permisos válidas para un contenedor incluyen rw, rd, rl, wd, wly rl. Algunos ejemplos de valores no válidos incluyen wr, dr, lry dw. No se permite especificar una designación de permiso más de una vez.

Una SAS de delegación de usuarios no puede conceder acceso a determinadas operaciones:

  • No se pueden crear, eliminar ni listar contenedores, colas ni tablas.
  • Los metadatos y propiedades del contenedor no se pueden leer ni escribir.
  • Las colas no se pueden borrar y sus metadatos no pueden escribirse.
  • Los contenedores no se pueden conceder.

Para construir una SAS que conceda acceso a estas operaciones, use una SAS de cuenta. Para obtener más información, consulte Creación de una saS de cuenta.

Permisos para un directorio, contenedor o blob

Los permisos que se admiten para cada tipo de recurso se describen en la tabla siguiente:

Permiso Símbolo de URI Recurso Compatibilidad con versiones Operaciones permitidas
Leer r Contenedor
Directorio
Masa amorfa		 Todo Lea el contenido, la lista de bloques, las propiedades y los metadatos de cualquier blob del contenedor o directorio. Use un blob como origen de una operación de copia.
Agregar un Contenedor
Directorio
Masa amorfa		 Todo Agregue un bloque a un blob en anexos.
Crear c Contenedor
Directorio
Masa amorfa		 Todo Escriba un nuevo blob, una instantánea de un blob o copie un blob en un nuevo blob.
Escribir w Contenedor
Directorio
Masa amorfa		 Todo Cree o escriba contenido, propiedades, metadatos o lista de bloqueados. Instantánea o concesión del blob. Cambie el tamaño del blob (solo blob en páginas). Use el blob como destino de una operación de copia.
Borrar d Contenedor
Directorio
Masa amorfa		 Todo Elimine un blob. Para la versión 2017-07-29 y posteriores, el permiso Delete también permite interrumpir una concesión en un blob. Para obtener más información, consulte la operación de concesión de blobs de .
Eliminar versión x Contenedor
Masa amorfa		 2019-12-12 y versiones posteriores Elimine una versión de blob.
Eliminación permanente y Masa amorfa 2020-02-10 y versiones posteriores Elimine permanentemente una instantánea de blob o una versión.
Lista l Contenedor
Directorio		 Todo Enumerar blobs de forma no recursiva.
Etiquetas t Masa amorfa 2019-12-12 y versiones posteriores Lee o escribe las etiquetas en un blob.
Mover m Contenedor
Directorio
Masa amorfa		 2020-02-10 y versiones posteriores Mueva un blob o un directorio y su contenido a una nueva ubicación. Esta operación puede restringirse opcionalmente al propietario del blob secundario, directorio o directorio primario si el parámetro saoid se incluye en el token de SAS y el bit pegajoso se establece en el directorio primario.
Ejecutar e Contenedor
Directorio
Masa amorfa		 2020-02-10 y versiones posteriores Obtenga las propiedades del sistema y, si el espacio de nombres jerárquico está habilitado para la cuenta de almacenamiento, obtenga la ACL POSIX de un blob. Si el espacio de nombres jerárquico está habilitado y el autor de la llamada es el propietario de un blob, este permiso concede la capacidad de establecer el grupo propietario, los permisos POSIX y la ACL POSIX del blob. No permite que el autor de la llamada lea los metadatos definidos por el usuario.
Propiedad o Contenedor
Directorio
Masa amorfa		 2020-02-10 y versiones posteriores Cuando el espacio de nombres jerárquico está habilitado, este permiso permite al autor de la llamada establecer el propietario o el grupo propietario, o actuar como propietario cuando el autor de la llamada cambia el nombre o elimina un directorio o un blob dentro de un directorio que tiene el bit pegado establecido.
Permisos p Contenedor
Directorio
Masa amorfa		 2020-02-10 y versiones posteriores Cuando el espacio de nombres jerárquico está habilitado, este permiso permite al autor de la llamada establecer permisos y ACL POSIX en directorios y blobs.
Establecer directiva de inmutabilidad Yo Contenedor
Masa amorfa		 2020-06-12 y versiones posteriores Establezca o elimine la directiva de inmutabilidad o suspensión legal en un blob.

Permisos para un archivo

Permiso Símbolo de URI Operaciones permitidas
Leer r Lee el contenido, las propiedades, los metadatos. Usa el archivo como fuente de una operación de copia.
Escribir w Crea un archivo nuevo o copia un archivo a un archivo nuevo.
Crear o escribir contenido, propiedades, metadatos. Redimensiona el archivo. Usa el archivo como destino de una operación de copia.
Borrar d Elimine el archivo.

Permisos para una participación

Permiso Símbolo de URI Operaciones permitidas
Leer r Lee el contenido, las propiedades o los metadatos de cualquier archivo en el compartido. Utiliza cualquier archivo del recurso compartido como fuente de una operación de copia.
Escribir w Crea un nuevo archivo en el share, o copia un archivo a un archivo nuevo dentro del share.
Para cualquier archivo en el share, crea o escribe contenido, propiedades o metadatos. Redimensiona el archivo. Usa el archivo como destino de una operación de copia. Nota: No puedes conceder permisos para leer o escribir propiedades de compartición o metadatos usando un SAS de servicio. Utiliza un SAS de cuenta en su lugar.
Borrar d Elimina cualquier archivo del share. Nota: No puedes conceder permisos para eliminar un recurso compartido usando un SAS de servicio. Utiliza un SAS de cuenta en su lugar.
Lista l Lista archivos y directorios en el share.

Permisos para una cola

Permiso Símbolo de URI Operaciones permitidas
Leer r Metadatos y propiedades de lectura, incluido el recuento de mensajes. Echa un vistazo a los mensajes.
Agregar un Añade mensajes a la cola.
Update u Actualizar los mensajes en la cola. Nota: Usa el permiso de Proceso con Actualizar para que primero puedas recibir el mensaje de que quieres actualizar.
Proceso p Obtén y elimina mensajes de la cola.

Permisos para una tabla

Permiso Símbolo de URI Operaciones permitidas
Query r Consigue entidades y consulta entidades.
Agregar un Añadir entidades. Nota: Se requieren permisos de Añadir y Actualizar para las operaciones de upsert.
Update u Actualizar entidades. Nota: Se requieren permisos de Añadir y Actualizar para las operaciones de upsert.
Borrar d Elimina las entidades.

Especificar una dirección IP o un intervalo IP

El campo opcional signedIp (sip) especifica una dirección IP pública o un intervalo de direcciones IP públicas desde las que aceptar solicitudes. Si la dirección IP desde la que se origina la solicitud no coincide con la dirección IP o el intervalo de direcciones especificado en el token de SAS, la solicitud no está autorizada. Solo se admiten direcciones IPv4.

Al especificar un intervalo de direcciones IP, el intervalo es inclusivo. Por ejemplo, especificar sip=198.51.100.0 o sip=198.51.100.10-198.51.100.20 en la SAS restringe la solicitud a esas direcciones IP.

En la tabla siguiente se describe si se debe incluir el campo signedIp en un token de SAS para un escenario determinado, en función del entorno de cliente y la ubicación de la cuenta de almacenamiento.

Entorno de cliente Ubicación de la cuenta de almacenamiento Recomendación
Cliente que se ejecuta en Azure En la misma región que el cliente Una SAS que se proporciona al cliente en este escenario no debe incluir una dirección IP de salida para el campo signedIp. Se producen errores en las solicitudes que realice desde dentro de la misma región mediante una SAS con una dirección IP de salida especificada.

En su lugar, use una red virtual de Azure para administrar las restricciones de seguridad de red. Las solicitudes a Azure Storage desde la misma región siempre tienen lugar en una dirección IP privada. Para más información, consulte Configuración de firewalls y redes virtuales de Azure Storage.
Cliente que se ejecuta en Azure En otra región del cliente Una SAS que se proporciona al cliente en este escenario podría incluir una dirección IP pública o un intervalo de direcciones para el campo signedIp. Las solicitudes que realice con la SAS deben originarse en la dirección IP o el intervalo de direcciones especificados.
Cliente que se ejecuta de forma local o en un entorno de nube diferente En cualquier región de Azure Una SAS que se proporciona al cliente en este escenario podría incluir una dirección IP pública o un intervalo de direcciones para el campo signedIp. Las solicitudes que realice con la SAS deben originarse en la dirección IP o el intervalo de direcciones especificados.

Si la solicitud pasa a través de un proxy o puerta de enlace, proporcione la dirección IP de salida pública de ese proxy o puerta de enlace para el campo signedIp.

Especificar el protocolo HTTP

El campo opcional signedProtocol (spr) especifica el protocolo permitido para las solicitudes realizadas con la SAS. Los valores posibles son HTTPS y HTTP (https,http) o HTTPS solo (https). El valor predeterminado es https,http.

Nota

No es posible especificar HTTP para el campo spr.

Especificar rangos de acceso a tablas

Los startPkcampos , startRk, endPk, y endRk definen un rango de entidades de tabla asociadas a una firma de acceso compartida. Las consultas de tabla solo devolven resultados dentro del rango, y los intentos de usar la firma de acceso compartida para añadir, actualizar o eliminar entidades fuera de ese rango fallarán.

Si startPk es igual a endPk, la firma de acceso compartido autoriza el acceso a entidades en una sola partición de la tabla.

Si startPk es endPk igual a , startRkendRkla firma de acceso compartido solo puede acceder a una entidad en una partición.

Para entender cómo estos campos limitan el acceso a entidades en una tabla, consulte la siguiente tabla:

Campos actuales Alcance de la restricción
startPk PartitionKey >= startPk
endPk PartitionKey <= endPk
startPk, startRk (clave >startPkde partición) || (partitionKey == startPk && rowKey >= startRk)
endPk, endRk (clave <endPkde partición) || (partitionKey == endPk && rowKey <= endRk)

Especificar el identificador de objeto firmado

El campo signedObjectId (skoid) es necesario para una SAS de delegación de usuarios. La operación Obtener clave de delegación de usuarios devuelve este valor como parte de la respuesta. El identificador de objeto firmado es un valor GUID que sirve el identificador inmutable para una entidad de seguridad en la plataforma de identidad de Microsoft.

Especificación del identificador de inquilino firmado

El campo signedTenantId (sktid) es necesario para una SAS de delegación de usuarios. La operación Obtener clave de delegación de usuarios devuelve este valor como parte de la respuesta. El identificador de inquilino firmado es un valor GUID que representa el inquilino de Microsoft Entra en el que se define una entidad de seguridad.

Especificar la hora de inicio de la clave firmada

El campo signedKeyStartTime obligatorio (skt) indica el inicio de la vigencia de la clave de delegación de usuarios en formato de fecha ISO. La operación Obtener clave de delegación de usuarios devuelve este valor como parte de la respuesta.

Especificar la hora de expiración de la clave firmada

El campo signedKeyExpiryTime (ske) es necesario para una SAS de delegación de usuarios en formato de fecha ISO. La operación Obtener clave de delegación de usuarios devuelve este valor como parte de la respuesta. El tiempo de expiración de la clave firmada indica el final de la duración de la clave de delegación de usuarios. El valor de la hora de expiración puede ser un máximo de siete días a partir de la hora de inicio de la SAS.

Especificación del servicio de claves firmadas

El campo signedKeyService (sks) es necesario para una SAS de delegación de usuarios. La operación Obtener clave de delegación de usuarios devuelve este valor como parte de la respuesta. El campo servicio de clave firmada indica el servicio para el que la clave de delegación de usuarios es válida. El valor del campo de servicio de clave firmada para Blob Storage es b.

Especificar la versión de la clave firmada

El campo signedkeyversion (skv) es necesario para una SAS de delegación de usuarios. La operación Obtener clave de delegación de usuarios devuelve este valor como parte de la respuesta. El campo signedkeyversion especifica la versión del servicio de almacenamiento que se usa para obtener la clave de delegación de usuarios. Este campo debe especificar la versión 2018-11-09 o posterior.

Especificar un identificador de objeto de usuario firmado para una entidad de seguridad

Los campos opcionales signedAuthorizedObjectId (saoid) y signedUnauthorizedObjectId (suoid) permiten la integración con Apache Hadoop y Apache Ranger para cargas de trabajo de Azure Data Lake Storage. Use uno de estos campos en el token de SAS para especificar el identificador de objeto de una entidad de seguridad:

  • El campo saoid especifica el identificador de objeto de una entidad de seguridad de Microsoft Entra autorizada por el propietario de la clave de delegación de usuarios para realizar la acción concedida por el token de SAS. Azure Storage valida el token de SAS y garantiza que el propietario de la clave de delegación de usuarios tenga los permisos necesarios antes de que Azure Storage conceda acceso. No se realiza ninguna comprobación de permisos adicional en las ACL POSIX.
  • El campo suoid especifica el identificador de objeto de una entidad de seguridad de Microsoft Entra cuando se habilita un espacio de nombres jerárquico para una cuenta de almacenamiento. El campo suoid solo es válido para las cuentas que tienen un espacio de nombres jerárquico. Cuando el campo suoid se incluye en el token de SAS, Azure Storage realiza una comprobación de ACL POSIX con el identificador de objeto antes de autorizar la operación. Si esta comprobación de ACL no se realiza correctamente, se produce un error en la operación. Se debe habilitar un espacio de nombres jerárquico para la cuenta de almacenamiento si el campo suoid se incluye en el token de SAS. De lo contrario, se producirá un error en la comprobación de permisos con un error de autorización.

El identificador de objeto de la entidad de seguridad que solicita la clave de delegación de usuarios se captura en el campo skoid requerido. Para especificar un identificador de objeto en el token de SAS con el campo saoid o suoid, La entidad de seguridad identificada en el campo skoid debe tener asignado un rol de RBAC que incluya Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action o Microsoft.Storage/storageAccounts/blobServices/containers/blobs/manageOwnership/action. Para más información sobre estas acciones, consulte operaciones del proveedor de recursos de Azure.

Al especificar el identificador de objeto en el campo saoid o suoid, también se restringen las operaciones relacionadas con la propiedad del directorio o del blob de las maneras siguientes:

  • Si una operación crea un directorio o un blob, Azure Storage establece el propietario del directorio o blob en el valor especificado por el identificador de objeto. Si no se especifica el identificador de objeto, Azure Storage establece el propietario del directorio o blob en el valor especificado por el parámetro skoid.
  • Si el bit pegajoso se establece en el directorio primario y la operación elimina o cambia el nombre de un directorio o blob, el identificador de objeto del propietario del directorio primario o el propietario del recurso debe coincidir con el valor especificado por el identificador de objeto.
  • Si una operación establece el propietario de un directorio o blob y se especifica el encabezado x-ms-owner, el valor especificado por el identificador de objeto debe coincidir con el valor especificado por el encabezado x-ms-owner.
  • Si una operación establece el grupo para un directorio o blob y se especifica el encabezado x-ms-group, el valor especificado por el identificador de objeto debe ser miembro del grupo especificado por el encabezado x-ms-group.
  • Si una operación establece los permisos o la ACL para un directorio o blob, también debe cumplirse una de las dos condiciones siguientes:
    • El valor especificado para el identificador de objeto debe ser el propietario del directorio o blob.
    • El valor del campo signedPermissions (sp) debe incluir el permiso Ownership (o) además del permiso Permissions (p).

El identificador de objeto especificado en el campo saoid o suoid se incluye en los registros de diagnóstico al realizar solicitudes mediante el token de SAS.

El campo saoid o suoid solo se admite si el campo signedVersion (sv) está establecido en la versión 2020-02-10 o posterior. Solo se puede incluir uno de estos campos en el token de SAS.

Especificar un identificador de correlación

El campo signedCorrelationId (scid) especifica un identificador de correlación que se puede usar para correlacionar los registros de auditoría de almacenamiento con los registros de auditoría que usa la entidad de seguridad que genera y distribuye la SAS. Por ejemplo, un servicio de autorización de confianza normalmente tiene una identidad administrada que autentica y autoriza a los usuarios, genera una SAS, agrega una entrada al registro de auditoría local y devuelve la SAS a un usuario, que luego puede usar la SAS para acceder a los recursos de Azure Storage. Al incluir un identificador de correlación en el registro de auditoría local y en el registro de auditoría de almacenamiento, se permite que estos eventos se correlacionan más adelante. El valor es un GUID sin llaves y con caracteres en minúsculas.

Este campo es compatible con la versión 2020-02-10 y posteriores.

Especificar el usuario delegado

El campo opcional sduoid garantiza que solo el usuario especificado pueda acceder a los recursos con el token SAS.

El sduoid campo especifica el ID de objeto para un principio de seguridad Microsoft Entra que pertenece al usuario final previsto. Cuando se especifica, el llamante también debe enviar una ficha de portador; Su afirmación OID debe coincidir con Sduoid. Además, el usuario final debería estar en el mismo tenant de Entra que la cuenta de almacenamiento.

El campo opcional skdutid solo es necesario cuando el tenant Microsoft Entra del usuario especificado sduoid es diferente del inquilino de la cuenta de almacenamiento. Antes de usar este campo, también debes proporcionar DelegatedUserTid al llamar a la API Get User Delegation Key .

El skdutid campo representa el ID de inquilino (tid) del principal de seguridad de Microsoft Entra que usará el token SAS. Cuándo skduti se incluye:

  • El llamante debe presentar una ficha portadora cuya reclamación tid coincida con el valor de skdutid.
  • El valor DelegatedUserTid en la UserDelegationKey devuelto también debe coincidir skdutidcon .

Estas comprobaciones aseguran que el token SAS solo sea utilizable por identidades del tenant correcto de Microsoft Entra, manteniendo un fuerte aislamiento a nivel de tenant para el acceso delegado.

Especificar la profundidad del directorio

Si el campo signedResource especifica un directorio (sr=d), también debe especificar el campo signedDirectoryDepth (sdd) para indicar el número de subdirectorios en el directorio raíz. El valor del campo sdd debe ser un entero no negativo.

Por ejemplo, el directorio raíz https://{account}.blob.core.windows.net/{container}/ tiene una profundidad de 0. Cada subdirectorio del directorio raíz agrega a la profundidad en 1. El directorio https://{account}.blob.core.windows.net/{container}/d1/d2 tiene una profundidad de 2.

Este campo es compatible con la versión 2020-02-10 y posteriores.

Especificar cabeceras de solicitud con signo y parámetros de consulta

Importante

Los srh parámetros de consulta y srq están disponibles cuando el signedVersion campo (sv) se establece en 2026-04-06 o posterior. Estos parámetros permiten requerir cabeceras específicas y parámetros de consulta en cualquier solicitud que utilice el SAS. Azure Storage valida los valores suministrados contra cadenas canónicas que ahora forman parte de la cadena a signo.

Utiliza srh (signedRequestHeaders) para enumerar los encabezados que deben estar presentes en la solicitud. Proporciona los nombres de los encabezados como una lista separada por comas. Cada encabezado nombrado en srh debe aparecer en la solicitud, y los valores canonizados deben coincidir con los que se incluyeron cuando se creó el SAS. Se rechazan nombres de cabecera duplicados o vacíos.

Utiliza srq (signedRequestQueryParameters) para enumerar los parámetros de consulta que deben estar presentes en la solicitud. Proporciona los nombres de los parámetros como una lista separada por comas. Cada parámetro nombrado en srq debe aparecer en el URI de la solicitud, y Azure Storage valida los pares de nombre y valor canonizados cuando se evalúa el token SAS.

Cuando srh se especifique o srq o se especifique, rellena los campos canonizados que se añaden a la cadena de signos en la versión de autorización 2026-04-06 y posteriores:

Generar encabezados canonicalizedSignedRequestHeaders

  • Recoge los encabezados listados en srh el mismo orden en que aparecen en srh.
  • Normaliza cada encabezado a headerName:headerValue y termina cada par con una nueva línea (\n).
  • Si la petición contiene varios valores para el mismo encabezado, únete los valores con comas en el orden recibido antes de añadir la nueva línea. Los nombres de cabecera solo deben aparecer una vez.
  • No incluyas nombres de cabecera vacíos. Las solicitudes que omiten cualquier encabezado listado fallan la autorización.

Generar parámetros de consultaConsultaSignadosSignadosCanonicalizados

  • Recoge los parámetros de consulta listados en srq el mismo orden en que aparecen en srq.
  • Normalizar cada parámetro a parameterName=parameterValue y prefijar cada par con una nueva línea (\n).
  • Si la solicitud proporciona varios valores para un parámetro, únete los valores con comas en el orden recibido antes de prefijar cada nueva línea.
  • Los nombres de los parámetros no deben estar vacíos. Si el nombre de un parámetro contiene una coma, codifica la coma en el URI de la solicitud (por ejemplo, %2C) pero usa el nombre no codificado en la cadena canonizada.

Estas cadenas canónicas se insertan en la cadena a signo para que solo las solicitudes que recreen los mismos valores de cabecera y parámetro de consulta tengan éxito. Si srh o srq se omite, la cadena canónica asociada se trata como una cadena vacía.

Ejemplo: caso de uso básico de SAS dinámico

El siguiente fragmento SAS requiere un encabezado personalizado y un parámetro de consulta:

sp=rw&sv=2026-04-06&sr=b&srh=foo,bar&srq=operation,identifier&operation=update&identifier=abcd&sig=<signature>

Headers:
foo:123
bar:456

Cuando el cliente emite una solicitud, las partes dinámicas que se añaden a la cadena a signo deben verse así (sin las comillas dobles)

canonicalizedSignedRequestHeaders = "foo:123\nbar:456\n"
canonicalizedSignedRequestQueryParameters = "\noperation=update\nidentifier=abcd"

Cualquier solicitud que omita los encabezados de los encabezados srh o srq parámetros de consulta, o que utilice un valor diferente para estos, fallará la autorización porque las cadenas canónicas ya no coincidirán con la firma.

Ejemplo: Casos límite con valores repetidos y nombres codificados

Consideremos un SAS que impone dos cabeceras y un parámetro de consulta cuyo nombre contiene una coma:

sp=r&sv=2026-04-06&sr=b&srh=foo,bar&srq=day%2Cid&sig=<signature>

Si el cliente envía los siguientes metadatos de la solicitud:

foo:123
bar:456
foo:789

...?day%2Cid=mon123&...

Entonces, las cadenas canónicas que deben incorporarse en la evaluación de la firma son:

canonicalizedSignedRequestHeaders = foo:123,789\nbar:456
canonicalizedSignedRequestQueryParameters = \nday,id=mon123

Nótese que los valores de cabecera se unen con comas en el orden de recibimiento, mientras que el parámetro de consulta mantiene su nombre no codificado (day,id) dentro de la cadena canonizada aunque la URL de la solicitud codifique la coma %2C.

Especificar parámetros de consulta para invalidar los encabezados de respuesta

Para definir valores para determinados encabezados de respuesta que se van a devolver cuando se usa la firma de acceso compartido en una solicitud, puede especificar encabezados de respuesta en parámetros de consulta. Los encabezados de respuesta y los parámetros de consulta correspondientes son los siguientes:

Nombre del encabezado de respuesta Parámetro de consulta SAS correspondiente
Cache-Control rscc
Content-Disposition rscd
Content-Encoding rsce
Content-Language rscl
Content-Type rsct

Por ejemplo, si especifica el parámetro de consulta rsct=binary en un token de SAS, el encabezado de respuesta de Content-Type se establece en binary. Este valor invalida el valor de encabezado Content-Type almacenado para el blob para una solicitud con esta firma de acceso compartido únicamente.

Si crea una firma de acceso compartido que especifica encabezados de respuesta como parámetros de consulta, debe incluir esos encabezados de respuesta en la cadena a signo que se usa para construir la cadena de firma. Para obtener más información, vea la sección "Especificar la firma".

Especificar el ámbito de cifrado

El campo () especifica un ámbito de cifrado que la aplicación cliente usa al cargar blobs mediante el token de SAS a través de la operación put blob . El campo signed encryption scope se admite cuando el campo versión firmada (sv) del token de SAS es la versión 2020-12-06 o posterior. Si el campo versión firmada especifica una versión anterior a la versión admitida, el servicio devuelve el código de respuesta de error 403 (Prohibido).

Si el ámbito de cifrado predeterminado se establece para el contenedor o el sistema de archivos, el campo ses respeta la directiva de cifrado de contenedor. Si hay un error de coincidencia entre el parámetro de consulta ses y x-ms-default-encryption-scope encabezado, y el encabezado x-ms-deny-encryption-scope-override se establece en true, el servicio devuelve el código de respuesta de error 403 (Prohibido).

Si el encabezado x-ms-encryption-scope y el parámetro de consulta ses se proporcionan en la solicitud PUT y hay un error de coincidencia, el servicio devuelve el código de respuesta de error 400 (solicitud incorrecta).

Especificar la firma

El campo signature (sig) se usa para autorizar una solicitud realizada por un cliente con la firma de acceso compartido. La cadena a signo es una cadena única que se construye a partir de los campos que se deben comprobar para autorizar la solicitud. La firma es un HMAC que se calcula a través de la cadena a signo y la clave mediante el algoritmo SHA256 y, a continuación, se codifica mediante la codificación Base64.

Para construir la cadena de firma de una SAS de delegación de usuarios, cree la cadena para firmar a partir de los campos que componen la solicitud, codifique la cadena como UTF-8 y, a continuación, calcule la firma mediante el algoritmo HMAC-SHA256. Los campos que se incluyen en la cadena a signo deben estar descodificados por url.

Los campos necesarios en la cadena a inicio de sesión dependen de la versión del servicio que se usa para la autorización (sv campo). En las secciones siguientes se describe la configuración de cadena a signo para las versiones que admiten la SAS de delegación de usuarios.

Versión 2026-04-06 y posteriores (Almacenamiento en blob y almacenamiento en lago de datos)

La versión de autorización 2026-04-06 introduce las cadenas canónicas para srh y srq. Pobla estos valores tal y como se describe en la sección Especificar cabeceras de solicitud con signo y parámetros de consulta . Usa cuerdas vacías cuando srh se omiten o srq se omiten.

StringToSign =  signedPermissions + "\n" +
                signedStart + "\n" +
                signedExpiry + "\n" +
                canonicalizedResource + "\n" +
                signedKeyObjectId + "\n" +
                signedKeyTenantId + "\n" +
                signedKeyStart + "\n" +
                signedKeyExpiry  + "\n" +
                signedKeyService + "\n" +
                signedKeyVersion + "\n" +
                signedAuthorizedUserObjectId + "\n" +
                signedUnauthorizedUserObjectId + "\n" +
                signedCorrelationId + "\n" +
                "\n" +
                "\n" +
                signedIP + "\n" +
                signedProtocol + "\n" +
                signedVersion + "\n" +
                signedResource + "\n" +
                signedSnapshotTime + "\n" +
                signedEncryptionScope + "\n" +
                canonicalizedSignedRequestHeaders + "\n" +
                canonicalizedSignedRequestQueryParameters + "\n" +
                rscc + "\n" +
                rscd + "\n" +
                rsce + "\n" +
                rscl + "\n" +
                rsct

Versión 2025-07-05 y posteriores

La cadena de señales para Blob Storage con autorización versión 2025-07-05 y posteriores tiene el siguiente formato:

StringToSign =  signedPermissions + "\n" +
                signedStart + "\n" +
                signedExpiry + "\n" +
                canonicalizedResource + "\n" +
                signedKeyObjectId + "\n" +
                signedKeyTenantId + "\n" +
                signedKeyStart + "\n" +
                signedKeyExpiry  + "\n" +
                signedKeyService + "\n" +
                signedKeyVersion + "\n" +
                signedAuthorizedUserObjectId + "\n" +
                signedUnauthorizedUserObjectId + "\n" +
                signedCorrelationId + "\n" +
                signedKeyDelegatedUserTenantId + "\n" +
                signedDelegatedUserObjectId + "\n" +
                signedIP + "\n" +
                signedProtocol + "\n" +
                signedVersion + "\n" +
                signedResource + "\n" +
                signedSnapshotTime + "\n" +
                signedEncryptionScope + "\n" +
                rscc + "\n" +
                rscd + "\n" +
                rsce + "\n" +
                rscl + "\n" +
                rsct

La cadena de signos para Almacenamiento de Tablas con la versión de autorización 2025-07-05 y posteriores tiene el siguiente formato:

StringToSign =  signedPermissions + "\n" +
                signedStart + "\n" +
                signedExpiry + "\n" +
                canonicalizedResource + "\n" +
                signedKeyObjectId + "\n" +
                signedKeyTenantId + "\n" +
                signedKeyStart + "\n" +
                signedKeyExpiry  + "\n" +
                signedKeyService + "\n" +
                signedKeyVersion + "\n" +
                signedKeyDelegatedUserTenantId + "\n" +
                signedDelegatedUserObjectId + "\n" +
                signedIP + "\n" +
                signedProtocol + "\n" +
                signedVersion + "\n" +
                startingPartitionKey + "\n"  
                startingRowKey + "\n"  
                endingPartitionKey + "\n"  
                endingRowKey

La cadena de señales para Almacenamiento en Cola con autorización versión 2025-07-05 y posteriores tiene el siguiente formato:

StringToSign =  signedPermissions + "\n" +
                signedStart + "\n" +
                signedExpiry + "\n" +
                canonicalizedResource + "\n" +
                signedKeyObjectId + "\n" +
                signedKeyTenantId + "\n" +
                signedKeyStart + "\n" +
                signedKeyExpiry  + "\n" +
                signedKeyService + "\n" +
                signedKeyVersion + "\n" +
                signedKeyDelegatedUserTenantId + "\n" +
                signedDelegatedUserObjectId + "\n" +
                signedIP + "\n" +
                signedProtocol + "\n" +
                signedVersion

La cadena para firmar Azure Files con la versión de autorización 2025-07-05 y posteriores tiene el siguiente formato:

StringToSign =  signedPermissions + "\n" +
                signedStart + "\n" +
                signedExpiry + "\n" +
                canonicalizedResource + "\n" +
                signedKeyObjectId + "\n" +
                signedKeyTenantId + "\n" +
                signedKeyStart + "\n" +
                signedKeyExpiry  + "\n" +
                signedKeyService + "\n" +
                signedKeyVersion + "\n" +
                signedKeyDelegatedUserTenantId + "\n" +
                signedDelegatedUserObjectId + "\n" +
                signedIP + "\n" +
                signedProtocol + "\n" +
                signedVersion + "\n" +
                rscc + "\n" +
                rscd + "\n" +
                rsce + "\n" +
                rscl + "\n" +
                rsct

Versión 2020-12-06 y posteriores

La cadena a firmar para la versión de autorización 2020-12-06 y posteriores tiene el formato siguiente:

StringToSign =  signedPermissions + "\n" +
                signedStart + "\n" +
                signedExpiry + "\n" +
                canonicalizedResource + "\n" +
                signedKeyObjectId + "\n" +
                signedKeyTenantId + "\n" +
                signedKeyStart + "\n" +
                signedKeyExpiry  + "\n" +
                signedKeyService + "\n" +
                signedKeyVersion + "\n" +
                signedAuthorizedUserObjectId + "\n" +
                signedUnauthorizedUserObjectId + "\n" +
                signedCorrelationId + "\n" +
                signedIP + "\n" +
                signedProtocol + "\n" +
                signedVersion + "\n" +
                signedResource + "\n" +
                signedSnapshotTime + "\n" +
                signedEncryptionScope + "\n" +
                rscc + "\n" +
                rscd + "\n" +
                rsce + "\n" +
                rscl + "\n" +
                rsct

Versión 2020-02-10

La cadena a firmar para la versión de autorización 2020-02-10 tiene el siguiente formato:

StringToSign =  signedPermissions + "\n" +
                signedStart + "\n" +
                signedExpiry + "\n" +
                canonicalizedResource + "\n" +
                signedKeyObjectId + "\n" +
                signedKeyTenantId + "\n" +
                signedKeyStart + "\n" +
                signedKeyExpiry  + "\n" +
                signedKeyService + "\n" +
                signedKeyVersion + "\n" +
                signedAuthorizedUserObjectId + "\n" +
                signedUnauthorizedUserObjectId + "\n" +
                signedCorrelationId + "\n" +
                signedIP + "\n" +
                signedProtocol + "\n" +
                signedVersion + "\n" +
                signedResource + "\n" +
                signedSnapshotTime + "\n" +
                rscc + "\n" +
                rscd + "\n" +
                rsce + "\n" +
                rscl + "\n" +
                rsct

Versiones anteriores a 2020-02-10

La cadena a firmar para las versiones de autorización anteriores a 2020-02-10 tiene el siguiente formato:

StringToSign =  signedPermissions + "\n" +  
                signedStart + "\n" +  
                signedExpiry + "\n" +  
                canonicalizedResource + "\n" +  
                signedKeyObjectId + "\n" +
                signedKeyTenantId + "\n" +
                signedKeyStart + "\n" +
                signedKeyExpiry  + "\n" +
                signedKeyService + "\n" +
                signedKeyVersion + "\n" +
                signedAuthorizedUserObjectId + "\n" +
                signedUnauthorizedUserObjectId + "\n" +
                signedCorrelationId + "\n" +
                signedIP + "\n" +  
                signedProtocol + "\n" +  
                signedVersion + "\n" +  
                signedResource + "\n" +
                rscc + "\n" +
                rscd + "\n" +  
                rsce + "\n" +  
                rscl + "\n" +  
                rsct

Recurso canónico

La parte canonicalizedResource de la cadena es una ruta de acceso canónica al recurso firmado. Debe incluir el punto de conexión de Blob Storage (o blobdfs) y el nombre del recurso, y debe estar descodificado por URL. Una ruta de acceso de blob debe incluir su contenedor. Una ruta de acceso de directorio debe incluir el número de subdirectorios que corresponden al parámetro sdd.

La cadena de recurso canónica de un contenedor debe omitir la barra diagonal final (/) para una SAS que proporcione acceso a ese contenedor.

En los ejemplos siguientes se muestra cómo construir la parte canonicalizedResource de la cadena, en función del tipo de recurso.

Ejemplo de contenedor (Azure Blob Storage)
URL = https://myaccount.blob.core.windows.net/music  
canonicalizedResource = "/blob/myaccount/music"
Ejemplo de blob (Azure Blob Storage)
URL = https://myaccount.blob.core.windows.net/music/intro.mp3  
canonicalizedResource = "/blob/myaccount/music/intro.mp3"
Ejemplo de contenedor (Azure Data Lake Storage)
URL = https://myaccount.dfs.core.windows.net/music  
canonicalizedResource = "/blob/myaccount/music"
Ejemplo de directorio (Azure Data Lake Storage)
URL = https://myaccount.dfs.core.windows.net/music/instruments/guitar/  
canonicalizedResource = "/blob/myaccount/music/instruments/guitar/"
Ejemplo de blob (Azure Data Lake Storage)
URL = https://myaccount.dfs.core.windows.net/music/intro.mp3  
canonicalizedResource = "/blob/myaccount/music/intro.mp3"
Recursos compartidos de archivos

Para la versión 2025-07-05 y posteriores:

URL = https://myaccount.file.core.windows.net/music
canonicalizedResource = "/file/myaccount/music"
Archivos

Para la versión 2025-07-05 y posteriores:

URL = https://myaccount.file.core.windows.net/music/intro.mp3
canonicalizedResource = "/file/myaccount/music/intro.mp3"
Queues

Para la versión 2025-07-05 y posteriores:

URL = https://myaccount.queue.core.windows.net/thumbnails  
canonicalizedResource = "/queue/myaccount/thumbnails"
Tables

Si el recurso firmado es una tabla, asegúrese de que el nombre de la tabla esté en minúscula en el formato canonizado.

Para la versión 2025-07-05 y posteriores:

URL = https://myaccount.table.core.windows.net/Employees(PartitionKey='Jeff',RowKey='Price')  
canonicalizedResource = "/table/myaccount/employees"

Campos opcionales

Si un campo es opcional y no se proporciona como parte del token de SAS, especifique una cadena vacía para el campo. Asegúrese de incluir el carácter de nueva línea (\n) después de la cadena vacía.

Ejemplo de SAS de delegación de usuarios

En el ejemplo siguiente se muestra un URI de blob con un token saS de delegación de usuarios anexado a él. El token de SAS de delegación de usuarios proporciona permisos de lectura y escritura en el blob.

https://myaccount.blob.core.windows.net/sascontainer/blob1.txt?sp=rw&st=2023-05-24T01:13:55Z&se=2023-05-24T09:13:55Z&skoid=<object-id>&sktid=<tenant-id>&skt=2023-05-24T01:13:55Z&ske=2023-05-24T09:13:55Z&sks=b&skv=2022-11-02&sip=198.51.100.10-198.51.100.20&spr=https&sv=2022-11-02&sr=b&sig=<signature>

Cada parte del URI se describe en la tabla siguiente:

Nombre Parte de SAS Descripción
URI de recursos https://myaccount.blob.core.windows.net/sascontainer/blob1.txt Dirección del blob. Se recomienda encarecidamente usar HTTPS.
Delimitador ? Delimitador que precede a la cadena de consulta. El delimitador no forma parte del token de SAS.
Permisos sp=rw Los permisos concedidos por la SAS incluyen Lectura (r) y Escritura (w).
Hora de comienzo st=2023-05-24T01:13:55Z Especificado en hora UTC. Si desea que la SAS sea válida inmediatamente, omita la hora de inicio.
Hora de expiración se=2023-05-24T09:13:55Z Especificado en hora UTC.
Id. de objeto skoid=<object-id> Una entidad de seguridad de Microsoft Entra.
Id. de inquilino sktid=<tenant-id> Inquilino de Microsoft Entra donde se registra la entidad de seguridad.
Hora de inicio de la clave skt=2023-05-24T01:13:55Z Inicio de la vigencia de la clave de delegación de usuarios.
Hora de expiración de la clave ske=2023-05-24T09:13:55Z Fin de la vigencia de la clave de delegación de usuarios.
Servicio de claves sks=b Solo se admite Blob service para el valor del servicio.
Versión de clave skv=2022-11-02 La versión del servicio de almacenamiento que se usó para obtener la clave de delegación de usuarios.
Intervalo IP sip=198.51.100.10-198.51.100.20 Intervalo de direcciones IP desde las que se aceptará una solicitud.
Protocolo spr=https Solo se permiten las solicitudes que usan HTTPS.
Versión de Blob Service sv=2022-11-02 Para la versión 2012-02-12 y posteriores de Azure Storage, este parámetro indica la versión que se va a usar.
Recurso sr=b El recurso es un blob.
Firma sig=<signature> Se usa para autorizar el acceso al blob. La firma es un HMAC que se calcula a través de una cadena a signo y una clave mediante el algoritmo SHA256 y, a continuación, se codifica mediante la codificación Base64.

Revocar una SAS de delegación de usuarios

Si cree que una SAS se ha puesto en peligro, debe revocarla. Puede revocar una SAS de delegación de usuarios mediante la revocación de la clave de delegación de usuarios o cambiando o quitando asignaciones de roles RBAC y ACL POSIX para la entidad de seguridad que se usa para crear la SAS.

Importante

Azure Storage almacena en caché tanto la clave de delegación de usuarios como las asignaciones de roles de RBAC, por lo que puede haber un retraso entre cuando se inicia el proceso de revocación y cuando una SAS de delegación de usuarios existente no es válida.

Revocar la clave de delegación de usuarios

Puede revocar la clave de delegación de usuarios llamando a la operación Revocar claves de delegación de usuario. Al revocar la clave de delegación de usuarios, las firmas de acceso compartido que dependen de esa clave no sean válidas. A continuación, puede volver a llamar a la operación Obtener clave de delegación de usuarios y usar la clave para crear nuevas firmas de acceso compartido. Esta es la forma más rápida de revocar una SAS de delegación de usuarios.

Cambiar o quitar asignaciones de roles o ACL

Puede cambiar o quitar la asignación de roles RBAC y las ACL POSIX para la entidad de seguridad que se usa para crear la SAS. Cuando un cliente usa la SAS para acceder a un recurso, Azure Storage comprueba que la entidad de seguridad cuyas credenciales se usaron para proteger la SAS tiene los permisos necesarios para el recurso.

Consulte también

  • Last updated on