Compartir a través de

Autorización con clave compartida

  • Artículo

Todas las solicitudes realizadas en un servicio de almacenamiento deben estar autorizadas, a menos que la solicitud sea para un recurso de blob o contenedor que esté disponible para el acceso público o firmado. Una opción para autorizar una solicitud es mediante la clave compartida, que se describe en este artículo.

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.

En escenarios en los que se usan firmas de acceso compartido (SAS), Microsoft recomienda usar una SAS de delegación de usuarios. Una SAS de delegación de usuarios está protegida con credenciales de Microsoft Entra en lugar de la clave de cuenta. Para obtener información sobre las firmas de acceso compartido, consulte Creación de una SAS de delegación de usuarios.

Los servicios Blob, Queue, Table y File admiten los siguientes esquemas de autorización de clave compartida para la versión 2009-09-19 y posteriores (para Blob, Queue y Table service) y la versión 2014-02-14 y posteriores (para el servicio file):

  • Clave compartida para blobs, colas y servicios de archivos. Use el esquema de autorización de clave compartida para realizar solicitudes en los servicios Blob, Queue y File. La autorización de clave compartida en la versión 2009-09-19 y versiones posteriores admite una cadena de firma aumentada para mejorar la seguridad y requiere que actualice el servicio para autorizar mediante esta firma aumentada.

  • Clave compartida para Table Service. Use el esquema de autorización de clave compartida para realizar solicitudes en Table service mediante la API REST. La autorización de clave compartida para Table service en la versión 2009-09-19 y versiones posteriores usa la misma cadena de firma que en versiones anteriores de Table service.

  • Clave compartida Lite. Use el esquema de autorización Shared Key Lite para realizar solicitudes en los servicios Blob, Queue, Table y File. Shared Key Lite no es compatible con blobs en páginas Premium.

    Para la versión 2009-09-19 y posteriores de los servicios Blob y Queue, la autorización shared Key Lite admite el uso de una cadena de firma idéntica a la que se admitía con la clave compartida en versiones anteriores de los servicios Blob y Queue. Por lo tanto, puede usar Shared Key Lite para realizar solicitudes en los servicios Blob y Queue sin actualizar la cadena de firma.

Una solicitud autorizada requiere dos encabezados: el encabezado Date o x-ms-date y el encabezado Authorization. En las secciones siguientes se describe cómo construir estos encabezados.

Importante

Azure Storage admite HTTP y HTTPS, pero se recomienda encarecidamente usar HTTPS.

Nota

Un contenedor o un blob se pueden poner a disposición para el acceso público estableciendo los permisos de un contenedor. Para más información, consulte Administración del acceso a los recursos de Azure Storage. Un contenedor, blob, cola o tabla puede estar disponible para el acceso firmado a través de una firma de acceso compartido; Una firma de acceso compartido se autoriza a través de un mecanismo diferente. Consulte Delegación del acceso con una firma de acceso compartido para obtener más información.

Especificar el encabezado Date

Todas las solicitudes autorizadas deben incluir la marca de tiempo hora universal coordinada (UTC) para la solicitud. Puede especificar la marca de tiempo en el encabezado x-ms-date o en el encabezado http/HTTPS estándar Date. Si se especifican ambos encabezados en la solicitud, el valor de x-ms-date se usa como hora de creación de la solicitud.

Los servicios de almacenamiento garantizan que una solicitud no tenga más de 15 minutos durante el tiempo que llegue al servicio. Esto protege contra determinados ataques de seguridad, incluidos los ataques de reproducción. Cuando se produce un error en esta comprobación, el servidor devuelve el código de respuesta 403 (Prohibido).

Nota

El encabezado x-ms-date se proporciona porque algunas bibliotecas de cliente HTTP y servidores proxy establecen automáticamente el encabezado Date y no ofrecen al desarrollador la oportunidad de leer su valor para incluirlo en la solicitud autorizada. Si establece x-ms-date, construya la firma con un valor vacío para el encabezado Date.

Especificación del encabezado authorization

Una solicitud autorizada debe incluir el encabezado Authorization. Si no se incluye este encabezado, la solicitud es anónima y solo se realiza correctamente en un contenedor o blob marcado para el acceso público, o en un contenedor, blob, cola o tabla para el que se ha proporcionado una firma de acceso compartido para el acceso delegado.

Para autorizar una solicitud, debe firmar la solicitud con la clave de la cuenta que realiza la solicitud y pasar esa firma como parte de la solicitud.

El formato del encabezado Authorization es el siguiente:

Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"

donde SharedKey o SharedKeyLite es el nombre del esquema de autorización, AccountName es el nombre de la cuenta que solicita el recurso y Signature es un código de autenticación de mensajes basado en hash (HMAC) construido a partir de la solicitud y calculado mediante el algoritmo SHA256 y, a continuación, codificado mediante la codificación Base64.

Nota

Es posible solicitar un recurso que resida debajo de una cuenta diferente, si ese recurso es accesible públicamente.

En las secciones siguientes se describe cómo construir el encabezado Authorization.

Construcción de la cadena de firma

La forma de construir la cadena de firma depende del servicio y la versión en los que esté autorizando y en qué esquema de autorización está usando. Al construir la cadena de firma, tenga en cuenta lo siguiente:

  • La parte VERB de la cadena es el verbo HTTP, como GET o PUT, y debe estar en mayúsculas.

  • Para la autorización de clave compartida para los servicios Blob, Queue y File, cada encabezado incluido en la cadena de firma solo puede aparecer una vez. Si se duplica algún encabezado, el servicio devuelve el código de estado 400 (solicitud incorrecta).

  • Los valores de todos los encabezados HTTP estándar deben incluirse en la cadena en el orden que se muestra en el formato de firma, sin los nombres de encabezado. Estos encabezados pueden estar vacíos si no se especifican como parte de la solicitud; en ese caso, solo se requiere el carácter de nueva línea.

  • Si se especifica el encabezado x-ms-date, puede omitir el encabezado Date, independientemente de si se especifica en la solicitud y simplemente especificar una línea vacía para la parte Date de la cadena de firma. En este caso, siga las instrucciones de la sección Construcción de la cadena de encabezados canónicos para agregar el encabezado x-ms-date.

    Es aceptable especificar tanto x-ms-date como Date; en este caso, el servicio usa el valor de x-ms-date.

  • Si no se especifica el encabezado x-ms-date, especifique el encabezado Date en la cadena de firma, sin incluir el nombre del encabezado.

  • Todos los caracteres de nueva línea (\n) que se muestran son necesarios dentro de la cadena de firma.

  • La cadena de firma incluye encabezados canónicos y cadenas de recursos canónicas. La canónicación de estas cadenas las coloca en un formato estándar reconocido por Azure Storage. Para obtener información detallada sobre cómo construir las cadenas de CanonicalizedHeaders y CanonicalizedResource que forman parte de la cadena de firma, consulte las secciones adecuadas más adelante en este tema.

Blob, Queue y File Services (autorización de clave compartida)

Para codificar la cadena de firma de clave compartida para una solicitud en la versión 2009-09-19 y posteriores de Blob o Queue Service, y la versión 2014-02-14 y posteriores del servicio File, use el siguiente formato:

StringToSign = VERB + "\n" +  
               Content-Encoding + "\n" +  
               Content-Language + "\n" +  
               Content-Length + "\n" +  
               Content-MD5 + "\n" +  
               Content-Type + "\n" +  
               Date + "\n" +  
               If-Modified-Since + "\n" +  
               If-Match + "\n" +  
               If-None-Match + "\n" +  
               If-Unmodified-Since + "\n" +  
               Range + "\n" +  
               CanonicalizedHeaders +   
               CanonicalizedResource;

Importante

En la versión actual, el campo Content-Length debe ser una cadena vacía si la longitud de contenido de la solicitud es cero. En la versión 2014-02-14 y anteriores, la longitud del contenido se incluyó incluso si es cero. Consulte a continuación para obtener más información sobre el comportamiento anterior.

En el ejemplo siguiente se muestra una cadena de firma para una operación de Get Blob. Cuando no hay ningún valor de encabezado, solo se especifica el carácter de nueva línea.

GET\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n/myaccount/mycontainer\ncomp:metadata\nrestype:container\ntimeout:20

Al dividir esta línea a línea, se muestra cada parte de la misma cadena:

GET\n /*HTTP Verb*/  
\n    /*Content-Encoding*/  
\n    /*Content-Language*/  
\n    /*Content-Length (empty string when zero)*/  
\n    /*Content-MD5*/  
\n    /*Content-Type*/  
\n    /*Date*/  
\n    /*If-Modified-Since */  
\n    /*If-Match*/  
\n    /*If-None-Match*/  
\n    /*If-Unmodified-Since*/  
\n    /*Range*/  
x-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n    /*CanonicalizedHeaders*/  
/myaccount /mycontainer\ncomp:metadata\nrestype:container\ntimeout:20    /*CanonicalizedResource*/

A continuación, codifique esta cadena mediante el algoritmo HMAC-SHA256 sobre la cadena de firma codificada con UTF-8, construya el encabezado Authorization y agregue el encabezado a la solicitud. En el ejemplo siguiente se muestra el encabezado Authorization para la misma operación:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Para usar la autorización de clave compartida con la versión 2009-09-19 y posteriores de los servicios blob y queue, debe actualizar el código para usar esta cadena de firma aumentada.

Si prefiere migrar el código a la versión 2009-09-19 o posterior de los servicios Blob y Queue con los mínimos cambios posibles, puede modificar los encabezados de Authorization existentes para usar Shared Key Lite en lugar de Clave compartida. El formato de firma requerido por Shared Key Lite es idéntico al requerido para la clave compartida por versiones de los servicios Blob y Queue anteriores a 2009-09-19.

Importante

Si accede a la ubicación secundaria en una cuenta de almacenamiento para la que está habilitada la replicación geográfica de acceso de lectura (RA-GRS), no incluya la designación -secondary en el encabezado de autorización. Con fines de autorización, el nombre de la cuenta siempre es el nombre de la ubicación principal, incluso para el acceso secundario.

Encabezado Content-Length en la versión 2014-02-14 y anteriores

Al usar la versión 2014-02-14 o anterior, si Content-Length es cero, establezca la parte de Content-Length del StringToSign en 0. Normalmente, sería una cadena vacía.

Por ejemplo, para la siguiente solicitud, el valor del encabezado Content-Length se incluye en el StringToSign incluso cuando es cero.

PUT http://myaccount/mycontainer?restype=container&timeout=30 HTTP/1.1  
x-ms-version: 2014-02-14  
x-ms-date: Fri, 26 Jun 2015 23:39:12 GMT  
Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=  
Content-Length: 0

El StringToSign se construye de la siguiente manera:

Version 2014-02-14 and earlier:
PUT\n\n\n\n0\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2014-02-14\n/myaccount/mycontainer\nrestype:container\ntimeout:30

Mientras que en versiones posteriores a 2014-02-14, el StringToSign debe contener una cadena vacía para Content-Length:

Version 2015-02-21 and later:
PUT\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Fri, 26 Jun 2015 23:39:12 GMT\nx-ms-version:2015-02-21\n/myaccount/mycontainer\nrestype:container\ntimeout:30

Table service (autorización de clave compartida)

Debe usar la autorización de clave compartida para autorizar una solicitud realizada en Table service si el servicio usa la API REST para realizar la solicitud. El formato de la cadena de firma para clave compartida en Table service es el mismo para todas las versiones.

La cadena de firma de clave compartida para una solicitud en Table service difiere ligeramente de la de una solicitud en Blob o Queue Service, en que no incluye la parte CanonicalizedHeaders de la cadena. Además, el encabezado Date en este caso nunca está vacío aunque la solicitud establezca el encabezado x-ms-date. Si la solicitud establece x-ms-date, ese valor también se usa para el valor del encabezado Date.

Para codificar la cadena de firma de una solicitud en Table service realizada mediante la API REST, use el siguiente formato:

StringToSign = VERB + "\n" +
               Content-MD5 + "\n" +
               Content-Type + "\n" +  
               Date + "\n" +  
               CanonicalizedResource;

Nota

A partir de la versión 2009-09-19, Table service requiere que todas las llamadas REST incluyan los encabezados DataServiceVersion y MaxDataServiceVersion. Consulte Configuración de los encabezados de versión del servicio de datos de OData para obtener más información.

Servicios de blobs, colas y archivos (autorización de Shared Key Lite)

Puede usar la autorización de Shared Key Lite para autorizar una solicitud realizada en la versión 2009-09-19 y posteriores de los servicios Blob y Queue, y la versión 2014-02-14 y posteriores de los servicios file. Shared Key Lite no es compatible con blobs en páginas Premium.

La cadena de firma de Shared Key Lite es idéntica a la cadena de firma necesaria para la autorización de clave compartida en versiones de los servicios Blob y Queue anteriores a 2009-09-19. Por lo tanto, si desea migrar el código con el menor número de cambios a la versión 2009-09-19 de los servicios Blob y Queue, puede modificar el código para usar Shared Key Lite, sin cambiar la propia cadena de firma. Con Shared Key Lite, no obtendrá la funcionalidad de seguridad mejorada que proporciona el uso de la clave compartida con la versión 2009-09-19 y posteriores.

Para codificar la cadena de firma de una solicitud en Blob o Queue Service, use el siguiente formato:

StringToSign = VERB + "\n" +  
               Content-MD5 + "\n" +  
               Content-Type + "\n" +  
               Date + "\n" +  
               CanonicalizedHeaders +   
               CanonicalizedResource;

En el ejemplo siguiente se muestra una cadena de firma para una operación put blob . Tenga en cuenta que la línea de encabezado Content-MD5 está vacía. Los encabezados que se muestran en la cadena son pares nombre-valor que especifican valores de metadatos personalizados para el nuevo blob.

PUT\n\ntext/plain; charset=UTF-8\n\nx-ms-date:Sun, 20 Sep 2009 20:36:40 GMT\nx-ms-meta-m1:v1\nx-ms-meta-m2:v2\n/testaccount1/mycontainer/hello.txt

A continuación, codifique esta cadena mediante el algoritmo HMAC-SHA256 sobre la cadena de firma codificada con UTF-8, construya el encabezado Authorization y agregue el encabezado a la solicitud. En el ejemplo siguiente se muestra el encabezado Authorization para la misma operación:

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Table service (autorización de Shared Key Lite)

Puede usar la autorización de Shared Key Lite para autorizar una solicitud realizada en cualquier versión de Table service.

Para codificar la cadena de firma de una solicitud en Table service mediante Shared Key Lite, use el siguiente formato:

StringToSign = Date + "\n"
               CanonicalizedResource

En el ejemplo siguiente se muestra una cadena de firma para una operación de Create Table.

Sun, 11 Oct 2009 19:52:39 GMT\n/testaccount1/Tables

A continuación, codifique esta cadena mediante el algoritmo HMAC-SHA256, construya el encabezado Authorization y agregue el encabezado a la solicitud. En el ejemplo siguiente se muestra el encabezado Authorization para la misma operación:

Authorization: SharedKeyLite testaccount1:uay+rilMVayH/SVI8X+a3fL8k/NxCnIePdyZSkqvydM=

Construcción de la cadena de encabezados canónicos

Para construir la parte CanonicalizedHeaders de la cadena de firma, siga estos pasos:

  1. Recupere todos los encabezados del recurso que comienzan por x-ms-, incluido el encabezado x-ms-date.

  2. Convierta cada nombre de encabezado HTTP en minúsculas.

  3. Ordene los encabezados lexicográficamente por nombre de encabezado, en orden ascendente. Cada encabezado solo puede aparecer una vez en la cadena.

    Nota

    ordenación lexicográfica podría no coincidir siempre con la ordenación alfabética convencional.

  4. Reemplace cualquier espacio en blanco lineal en el valor del encabezado por un solo espacio.

El espacio en blanco lineal incluye retorno de carro/avance de línea (CRLF), espacios y pestañas. Consulte RFC 2616, sección 4.2 para obtener más información. No reemplace ningún espacio en blanco dentro de una cadena entre comillas.

  1. Recorte cualquier espacio en blanco alrededor de los dos puntos del encabezado.

  2. Por último, anexe un carácter de nueva línea a cada encabezado canónico de la lista resultante. Construya la cadena CanonicalizedHeaders mediante la concatenación de todos los encabezados de esta lista en una sola cadena.

A continuación se muestra un ejemplo de una cadena de encabezados canónicos:

x-ms-date:Sat, 21 Feb 2015 00:48:38 GMT\nx-ms-version:2014-02-14\n

Nota

Antes de la versión del servicio 2016-05-31, los encabezados con valores vacíos se omitían de la cadena de firma. Ahora se representan en CanonicalizedHeaders siguiendo inmediatamente el carácter de dos puntos con la terminación de nueva línea.

Construcción de la cadena de recursos canónica

La CanonicalizedResource parte de la cadena de firma representa el recurso de servicios de almacenamiento dirigido por la solicitud. Cualquier parte de la cadena de CanonicalizedResource derivada del URI del recurso debe codificarse exactamente como está en el URI.

Hay dos formatos admitidos para la cadena de CanonicalizedResource:

  • Formato que admite la autorización de clave compartida para la versión 2009-09-19 y posteriores de los servicios blob y cola, y para la versión 2014-02-14 y posteriores del servicio de archivos.

  • Un formato que admite Shared Key y Shared Key Lite para todas las versiones de Table service y Shared Key Lite para la versión 2009-09-19 y posteriores de los servicios Blob y Queue. Este formato es idéntico al usado con versiones anteriores de los servicios de almacenamiento.

Para obtener ayuda para construir el URI del recurso al que está accediendo, consulte uno de los temas siguientes:

Importante

Si la cuenta de almacenamiento se replica con replicación geográfica de acceso de lectura (RA-GRS) y accede a un recurso en la ubicación secundaria, no incluya la designación de –secondary en la cadena de CanonicalizedResource. El URI de recurso usado en el URI de cadena CanonicalizedResource debe ser el URI del recurso en la ubicación principal.

Nota

Si está autorizando en el emulador de almacenamiento, el nombre de la cuenta aparecerá dos veces en la cadena de CanonicalizedResource. Esto es lo esperado. Si está autorizando en los servicios de almacenamiento de Azure, el nombre de la cuenta solo aparecerá una vez en la cadena de CanonicalizedResource.

Formato de clave compartida para 2009-09-19 y versiones posteriores

Este formato admite la autorización de clave compartida para la versión 2009-09-19 y posteriores de los servicios Blob y Queue, y la versión 2014-02-14 y posteriores de los servicios de archivos. Construya la cadena CanonicalizedResource en este formato de la siguiente manera:

  1. A partir de una cadena vacía (""), anexe una barra diagonal (/), seguida del nombre de la cuenta que posee el recurso al que se accede.

  2. Anexe la ruta de acceso de URI codificada del recurso, sin parámetros de consulta.

  3. Recupere todos los parámetros de consulta en el URI del recurso, incluido el parámetro comp si existe.

  4. Convierta todos los nombres de parámetro en minúsculas.

  5. Ordene los parámetros de consulta lexicográficamente por nombre de parámetro, en orden ascendente.

  6. Descodificar la dirección URL de cada nombre y valor del parámetro de consulta.

  7. Incluya un carácter de nueva línea (\n) antes de cada par nombre-valor.

  8. Anexe cada nombre y valor de parámetro de consulta a la cadena en el formato siguiente, asegurándose de incluir los dos puntos (:) entre el nombre y el valor:

    parameter-name:parameter-value

  9. Si un parámetro de consulta tiene más de un valor, ordene todos los valores lexicográficamente, inclúyelos en una lista separada por comas:

    parameter-name:parameter-value-1,parameter-value-2,parameter-value-n

Tenga en cuenta las siguientes reglas para construir la cadena de recursos canónica:

  • Evite usar el carácter de nueva línea (\n) en valores para los parámetros de consulta. Si se debe usar, asegúrese de que no afecta al formato de la cadena de recursos canónica.

  • Evite usar comas en valores de parámetros de consulta.

Estos son algunos ejemplos que muestran la parte CanonicalizedResource de la cadena de firma, ya que se puede construir a partir de un URI de solicitud determinado:

Get Container Metadata  
   GET http://myaccount.blob.core.windows.net/mycontainer?restype=container&comp=metadata
CanonicalizedResource:  
    /myaccount/mycontainer\ncomp:metadata\nrestype:container  
  
List Blobs operation:  
    GET http://myaccount.blob.core.windows.net/container?restype=container&comp=list&include=snapshots&include=metadata&include=uncommittedblobs  
CanonicalizedResource:  
    /myaccount/mycontainer\ncomp:list\ninclude:metadata,snapshots,uncommittedblobs\nrestype:container  
  
Get Blob operation against a resource in the secondary location:  
   GET https://myaccount-secondary.blob.core.windows.net/mycontainer/myblob  
CanonicalizedResource:  
    /myaccount/mycontainer/myblob

Formato shared Key Lite y Table service para 2009-09-19 y versiones posteriores

Este formato admite la clave compartida y la clave compartida Lite para todas las versiones de Table service y Shared Key Lite para la versión 2009-09-19 y posteriores de los servicios de blob y cola y la versión 2014-02-14 y posteriores del servicio file. Este formato es idéntico al usado con versiones anteriores de los servicios de almacenamiento. Construya la cadena CanonicalizedResource en este formato de la siguiente manera:

  1. A partir de una cadena vacía (""), anexe una barra diagonal (/), seguida del nombre de la cuenta que posee el recurso al que se accede.

  2. Anexe la ruta de acceso de URI codificada del recurso. Si el URI de solicitud direcciona un componente del recurso, anexe la cadena de consulta adecuada. La cadena de consulta debe incluir el signo de interrogación y el parámetro comp (por ejemplo, ?comp=metadata). No se debe incluir ningún otro parámetro en la cadena de consulta.

Codificación de la firma

Para codificar la firma, llame al algoritmo HMAC-SHA256 en la cadena de firma con codificación UTF-8 y codifique el resultado como Base64. Tenga en cuenta que también debe descodificar la clave de la cuenta de almacenamiento en Base64. Use el formato siguiente (que se muestra como pseudocódigo):

Signature=Base64(HMAC-SHA256(UTF8(StringToSign), Base64.decode(<your_azure_storage_account_shared_key>)))

Consulte también