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 clave compartida, que se describe en este artículo.

Sugerencia

Azure Storage proporciona integración con Microsoft Entra ID para la autorización basada en identidades de las solicitudes a los servicios Blob, File, Queue y Table. Con Microsoft Entra ID, puede usar el control de acceso basado en rol (RBAC) para conceder acceso a recursos de blob, archivo, cola y tabla a usuarios, grupos o aplicaciones. Microsoft Entra ID se puede usar para autorizar el acceso a los recursos de almacenamiento sin almacenar las claves de acceso de la cuenta en las aplicaciones, como sucede con la clave compartida. Para obtener más información, vea Autorizar con Microsoft Entra ID.

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 de archivos):

  • Clave compartida para los servicios Blob, Cola y Archivo. 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 con esta firma aumentada.

  • Shared Key para el servicio Tabla. 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.

  • Shared Key Lite. Use el esquema de autorización Shared Key Lite para realizar solicitudes en los servicios Blob, Queue, Table y File.

    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 tanto, puede utilizar Shared Key Lite para realizar solicitudes en los servicios Blob y Cola sin actualizar la cadena de firma.

Una solicitud autorizada requiere dos encabezados: el Date encabezado o x-ms-date y el Authorization encabezado . 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 blob se puede hacer disponible 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 Delegar el 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 Date estándar. Si se especifican ambos encabezados en la solicitud, el valor de x-ms-date se utiliza como el momento de creación de la solicitud.

Los servicios de almacenamiento comprueban que una solicitud tenga una antigüedad no superior a 15 minutos en el momento en que alcanza el servicio. Esto evita determinados ataques de seguridad, incluidos los ataques de reproducción. Si se produce un error en esta comprobación, el servidor devuelve el código de respuesta 403 (Forbidden).

Nota

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

Especificación del encabezado authorization

Una solicitud autorizada debe incluir el Authorization encabezado . 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 autentificación de mensajes basado en hash (HMAC) construido a partir de la solicitud, calculado mediante el algoritmo SHA256 y, por último, codificado utilizando la codificación Base64.

Nota

Es posible solicitar un recurso que resida en una cuenta diferente, siempre que ese recurso sea accesible públicamente.

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

Construcción de la cadena de firma

La forma en que se construye la cadena de firma depende del servicio y la versión en los que se autoriza y en qué esquema de autorización se usa. 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 hay algún encabezado duplicado, 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 mostrado en el formato de la 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 x-ms-date encabezado, puede omitir el Date encabezado, independientemente de si se especifica en la solicitud y simplemente especificar una línea vacía para la Date parte 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 x-ms-date encabezado.

    Es aceptable especificar y x-ms-dateDate; en este caso, el servicio usa el valor de x-ms-date.

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

  • Todos los caracteres de nueva línea (\n) mostrados se deben incluir en la cadena de firma.

  • La cadena de firma incluye encabezados con formato canónico y cadenas de recursos con formato canónico. Al aplicar un formato canónico a estas cadenas, se les da un formato estándar reconocido por el Almacenamiento de Azure. Para obtener información detallada sobre la construcción de las cadenas CanonicalizedHeaders y CanonicalizedResource que forman parte de la cadena de firma, vea 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 de una solicitud en la versión 19-09-2009 y posterior del servicio Blob o Cola, y la versión 14-02-2014 y posterior del servicio Archivo, usa el formato siguiente:

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 versiones 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 Get Blob . Donde 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

Si se analiza esta cadena línea a línea, se puede ver cada parte de la misma:

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 utilizando el algoritmo HMAC-SHA256 en la cadena de firma codificada mediante UTF-8, construya el encabezado Authorization y, por último, agréguelo 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 últimos cambios posibles, puede modificar los encabezados existentes Authorization para usar Shared Key Lite en lugar de Clave compartida. El formato de firma que requiere Shared Key Lite es idéntico al requerido por Shared Key en las versiones de los servicios Blob y Cola anteriores a la versión 2009-09-19.

Importante

Si va a acceder 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. Para fines de autorización, el nombre de cuenta siempre es el nombre de la ubicación principal, incluso para el acceso a la secundaria.

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

Cuando se usa la versión 2014-02-14 o anterior, si Content-Length es cero, establezca la Content-Length parte de en StringToSign0. Normalmente, sería una cadena vacía.

Por ejemplo, para la siguiente solicitud, el valor del Content-Length encabezado se incluye en incluso StringToSign 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

Se StringToSign 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, debe StringToSign 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 Shared Key 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 el servicio Blob o Queue, en que no incluye la CanonicalizedHeaders parte de la cadena. Además, en este caso el encabezado Date nunca está vacío, aunque la solicitud establezca el encabezado x-ms-date. Si la solicitud establece x-ms-date, este valor también se utiliza para el valor del encabezado Date.

Para codificar la cadena de firma de una solicitud en el servicio Tabla mediante la API de REST, utilice el formato siguiente:

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 a REST incluyan los encabezados DataServiceVersion y MaxDataServiceVersion. Consulte Establecimiento de los encabezados de versión del servicio de datos de OData para obtener más información.

Servicios Blob, Queue y File (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 de archivo.

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 al 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. Al usar Shared Key Lite, no obtendrá la funcionalidad de seguridad mejorada proporcionada mediante el uso de clave compartida con la versión 2009-09-19 y posteriores.

Para codificar la cadena de firma de una solicitud en el servicio Blob o Cola, utilice el formato siguiente:

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 . Observe que la línea de encabezado Content-MD5 está vacía. Los encabezados mostrados 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 utilizando el algoritmo HMAC-SHA256 en la cadena de firma codificada mediante UTF-8, construya el encabezado Authorization y, por último, agréguelo 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 para una solicitud contra Table service usando Shared Key Lite, use el formato siguiente:

StringToSign = Date + "\n"
               CanonicalizedResource

En el ejemplo siguiente se muestra una cadena de firma para una operación Crear tabla .

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

A continuación, codifique esta cadena utilizando el algoritmo HMAC-SHA256, construya el encabezado Authorization y, por último, agréguelo 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 a la parte CanonicalizedHeaders de la cadena de firma, siga estos pasos:

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

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

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

    Nota

    La 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 con formato canónico en la lista resultante. Construya la cadena CanonicalizedHeaders concatenando todos los encabezados de esta lista en una sola cadena.

A continuación se muestra un ejemplo de una cadena de encabezados con formato canónico:

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 nueva línea de terminación.

Construcción de la cadena de recursos canónica

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

La cadena CanonicalizedResource admite dos formatos:

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

  • Un formato que admite la clave compartida y la clave compartida ligera para todas las versiones del servicio Tabla, y la clave compartida ligera para la versión 19-09-2009 y posterior de los servicios Blob y Cola. Este formato es idéntico al utilizado con versiones anteriores de los servicios de almacenamiento.

Para obtener ayuda acerca cómo construir el URI para el recurso al que está obteniendo acceso, vea 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 va a acceder a un recurso en la ubicación secundaria, no incluya la designación –secondary en la cadena CanonicalizedResource. El URI del recurso utilizado en el URI de la 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 CanonicalizedResource cadena. Se espera que esto sea así. Si está autorizando en los servicios de almacenamiento de Azure, el nombre de la cuenta solo aparecerá una vez en la CanonicalizedResource cadena.

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 de los servicios de archivo. Construya la cadena CanonicalizedResource en este formato de la manera siguiente:

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

  2. Anexe la ruta de acceso URI codificada del recurso, sin ningún parámetro de consulta.

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

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

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

  6. Extraiga de la dirección URL el nombre y el valor de cada uno de los parámetros de consulta.

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

  8. Anexe el nombre y el valor de cada uno de los parámetros de consulta a la cadena con 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 y, a continuación, inclúyalos en una lista separada por comas:

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

Aplique las reglas siguientes para construir la cadena de recurso con formato canónico:

  • Evite usar el carácter de nueva línea (\n) en valores de parámetros de consulta. Si es imprescindible hacerlo, asegúrese de que no afecte al formato de la cadena de recurso con formato canónico.

  • Evite el uso de comas en los valores de los parámetros de consulta.

Estos son algunos ejemplos que muestran la CanonicalizedResource parte 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 ligera para todas las versiones del servicio Tabla, y la clave compartida ligera para la versión 19-09-2009 y posterior de los servicios Blob y Cola, y para la versión 14-02-2014 y posterior del servicio Archivo. Este formato es idéntico al utilizado con versiones anteriores de los servicios de almacenamiento. Construya la cadena CanonicalizedResource en este formato de la manera siguiente:

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

  2. Anexe la ruta de acceso URI codificada del recurso. Si el URI de solicitud hace referencia a 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 codificada mediante UTF-8 y codifique el resultado como Base64. Tenga en cuenta que también debe descodificar en Base64 la clave de la cuenta de almacenamiento. Utilice el formato siguiente (mostrado como pseudocódigo):

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

Consulte también