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

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 admite una SAS de delegación de usuarios para Azure Blob Storage y Azure Data Lake Storage. Las directivas de acceso almacenadas no se admiten para una SAS de delegación de usuarios.

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.

Compatibilidad de SAS de delegación de usuarios con acceso con ámbito de directorio

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.

Compatibilidad de SAS de delegación de usuarios con un OID de usuario

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 usuarios, debe asignar a una entidad de seguridad la acción Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey. Los siguientes roles RBAC integrados incluyen la acción Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey, ya sea explícitamente o como parte de una definición de carácter comodín:

• colaborador de
• colaborador de la cuenta de almacenamiento de
• colaborador de datos de Blob storage
• propietario de datos de blobs de almacenamiento de
• lector de datos de Blob storage de
• delegator de blobs de Storage

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 a la entidad de seguridad se le asigna un rol que permite el acceso a los datos, pero se limita al nivel de un contenedor, también puede asignar el rol delegador de blobs de almacenamiento a la entidad de seguridad en el nivel de la cuenta de almacenamiento, el grupo de recursos o la suscripción. El rol delegator de blobs de almacenamiento concede a la entidad de seguridad permisos para solicitar la clave de delegación de usuarios.

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 de Obtener clave de delegación de usuarios y, en la sección siguiente, "Construir una SAS de delegación de usuarios".

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.

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.

Especificar el campo de recurso firmado

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:

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 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:

• Los contenedores no se pueden crear, eliminar ni enumerar.
• Los metadatos y propiedades del contenedor no se pueden leer ni escribir.
• 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.

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

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.

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.

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 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 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:

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 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 y el nombre del recurso, y debe descodificar la dirección 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"  

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:

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.

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

• Delegar acceso con una firma de acceso compartido
• Crear una saS de servicio
• Crear una saS de cuenta
• códigos de error de SAS