Продажи: 1-800-867-1389

Проверка подлинности для служб хранения Azure

Обновлено: Май 2015 г.

Каждый запрос к службе хранилища должен пройти проверку подлинности, если это не запрос к ресурсу большого двоичного объекта или контейнера, к которым возможен общий доступ или доступ по общей подписи.

ImportantВажно!
Службы хранилища Azure поддерживают и протокол HTTP, и протокол HTTPS. Однако настоятельно рекомендуется использовать протокол HTTPS.

Службы BLOB-объектов, очередей, таблиц и файлов поддерживают следующие схемы проверки подлинности Shared Key для версии 2009-09-19 и более поздних (для службы BLOB-объектов, очередей и таблиц) и для версии 2014-02-14 и более поздних (для службы файлов):

  • Shared Key для служб BLOB-объектов, очередей и файлов. Используйте схему проверки подлинности Shared Key для запросов к службам BLOB-объектов, очередей и файлов. Проверка подлинности Shared Key в версии 2009-09-19 и более поздних поддерживает расширенную строку подписи, что повышает безопасность и требует обновления службы для проверки подлинности с помощью этой расширенной подписи.

  • Shared Key для службы таблиц. Используйте схему аутентификации Shared Key для запросов к службе таблиц посредством API REST. Проверка подлинности Shared Key для службы таблиц в версии 2009-09-19 и более поздних использует ту же строку подписи, что и предыдущие версии службы таблиц.

  • Shared Key Lite. Используйте схему проверки подлинности Shared Key Lite для запросов к службам BLOB-объектов, очередей, таблиц и файлов.

    В версии 2009-09-19 и более поздних версиях служб больших двоичных объектов и очередей для проверки подлинности Shared Key Lite поддерживаются строки подписи, идентичные тем, которые поддерживались для Shared Key в предыдущих версиях служб больших двоичных объектов и очередей. Поэтому можно использовать Shared Key Lite для запросов к службам больших двоичных объектов и очередей без обновления строки подписи.

Для запроса с проверкой подлинности необходимы два заголовка: заголовок Date или x-ms-date и заголовок Authorization. Следующие шаги описывают процесс создания этих заголовков.

noteПримечание
Контейнер или BLOB-объект может быть сделан доступным для общего доступа путем настройки разрешений контейнера. Дополнительные сведения см. в Managing Access to Containers and Blobs. Контейнер, BLOB-объект, очередь или таблица могут быть доступны для подписанного доступа посредством подписанного URL-адреса; проверка подлинности подписанного URL-адреса происходит с использованием другого механизма. Дополнительные сведения см. в разделе Делегирование доступа с подписью коллективного доступа.

Все запросы с проверкой подлинности должны включать отметку времени в формате UTC. Указывать отметку времени можно либо в заголовке x-ms-date, либо в стандартном заголовке HTTP/HTTPS Date. Если в запросе указаны оба заголовка, то значение x-ms-date используется как время создания запроса.

Службы хранилища обеспечивают, чтобы запрос был не старее 15 минут на момент достижения им службы. Это дает защиту от некоторых атак на систему безопасности, включая атаки воспроизведения. Если эта проверка завершается ошибкой, сервер возвращает код ответа 403 (отклонено).

noteПримечание
Заголовок x-ms-date предоставляется, поскольку некоторые клиентские библиотеки HTTP и прокси автоматически задают заголовок Date, не давая разработчику возможности прочитать его значение и включить в удостоверенный запрос. Задавая x-ms-date, следует создать подпись с пустым значением для заголовка Date.

Запрос с проверкой подлинности должен включать заголовок Authorization. Если этот заголовок не включен, то запрос анонимный и может завершиться успешно только для контейнера или BLOB-объекта, отмеченного для общего доступа, или для контейнера, BLOB-объекта, очереди или таблицы, если был предоставлен подписанный URL-адрес для делегированного доступа.

Для проверки подлинности запроса необходимо подписать запрос ключом учетной записи, которая выполняет запрос, и передать подпись в составе запроса.

Формат заголовка Authorization выглядит следующим образом:

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

где SharedKey или SharedKeyLite — название схемы авторизации, AccountName — имя учетной записи, запрашивающей ресурс, а Signature — код проверки подлинности на основе хэша (HMAC), построенный из запроса и вычисленный с помощью алгоритма SHA256, а затем закодированный в Base64.

noteПримечание
Можно запросить ресурс, который находится в другой учетной записи, если к этому ресурсу имеется общий доступ.

Следующие шаги описывают процесс создания заголовка Authorization.

Создание строки подписи зависит от того, для каких служб и каких версий производится проверка подлинности и какая схема проверки подлинности используется. При создании строки подписи помните о следующем.

  • Часть VERB строки — это HTTP-команда, например GET или PUT, и она должна быть написана прописными буквами.

  • При проверке подлинности Shared Key для служб BLOB-объектов, очередей и файлов каждый заголовок, включенный в строку подписи, может появляться только один раз. Если какой-либо заголовок дублирован, то служба возвращает код состояния 400 (неправильный запрос).

  • Значения всех стандартных заголовков HTTP необходимо включить в строку в порядке, показанном в формате подписи, без имен заголовков. Эти заголовки могут быть пустыми, если они не указаны как часть запроса. В таком случае требуется только символ новой строки.

  • Если заголовок x-ms-date указан, то можно пропускать заголовок Date независимо от того, указан ли он в запросе, и просто указать пустую строку для части Date строки сигнатуры. В этом случае следуйте инструкциям в разделе Создание элемента CanonicalizedHeaders для добавления заголовка x-ms-date.

    Обратите внимание, что можно указывать как x-ms-date, так и Date; в этом случае служба использует значение x-ms-date.

  • Если заголовок x-ms-date не указан, укажите заголовок Date в строке подписи без включения имени заголовка.

  • Все показанные символы новой строки (\n) необходимы в строке подписи.

  • Строка подписи содержит канонические заголовки и строки ресурсов. Канонизация этих строк преобразовывает их в стандартный формат, распознаваемый службой хранилища Azure. Подробные сведения о создании строк CanonicalizedHeaders и CanonicalizedResource, которые являются частью строки подписи, см. в соответствующих подразделах ниже.

Для кодирования строки подписи Shared Key для запроса к версии 2009-09-19 или более поздней версии службы BLOB-объектов или очередей, а также версии 2014-02-14 или более поздней версии службы файлов используйте следующий формат:

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;

В следующем примере показана строка подписи для операции Получение большого двоичного объекта. Обратите внимание, что значения заголовка нет, указан только символ новой строки.

GET\n\n\n\n\n\n\n\n\n\n\n\nx-ms-date:Sun, 11 Oct 2009 21:49:13 GMT\nx-ms-version:2009-09-19\n/myaccount/ mycontainer\ncomp:metadata\nrestype:container\ntimeout:20

В построчном разборе показана каждая часть одной и той же строки:


GET\n /*HTTP 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*/
x-ms-date:Sun, 11 Oct 2009 21:49:13 GMT\nx-ms-version:2009-09-19\n    /*CanonicalizedHeaders*/
/myaccount /mycontainer\ncomp:metadata\nrestype:container\ntimeout:20    /*CanonicalizedResource*/

Затем следует закодировать эту строку, применив алгоритм HMAC-SHA256 к закодированной в UTF-8 строке подписи, создать заголовок Authorization и добавить этот заголовок к запросу. В следующем примере показан заголовок Authorization для той же операции:

Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Обратите внимание, что для использования проверки подлинности Shared Key в версии 2009-09-19 и более поздних версиях служб больших двоичных объектов и очередей необходимо изменить код для использования расширенной строки подписи.

Если необходимо перенести код в версию 2009-09-19 или более позднюю версию служб больших двоичных объектов и очередей с наименьшим количеством изменений, можно изменить существующие заголовки Authorization для использования с Shared Key Lite вместо Shared Key. Формат подписи, необходимый для Shared Key Lite, идентичен тому, что необходим для Shared Key в версиях служб больших двоичных объектов и очередей до 2009-09-19.

ImportantВажно!
При выполнении доступа к дополнительному расположению в учетной записи хранения, для которого включена георепликация доступа для чтения (RA-GRS), не включайте обозначение -secondary в заголовок авторизации. Для проверки подлинности имя учетной записи всегда является именем первичного расположения, даже для вторичного доступа.

Следует использовать проверку подлинности Shared Key для проверки подлинности запроса к службе таблиц, если служба использует для запроса API-интерфейс REST. Формат строки подписи для Shared Key при запросе к службе таблиц тот же, что для всех версий.

Обратите внимание, что строка сигнатуры Shared Key для запроса к службе таблиц слегка отличается от строки для запроса к службе BLOB-объектов или очередей: она не содержит часть CanonicalizedHeaders. Кроме того, заголовок Date в этом случае никогда не пустует, даже если в запросе задан заголовок x-ms-date. Если в запросе задан заголовок x-ms-date, это значение также используется для значения заголовка Date.

Для кодирования строки подписи для запроса к службе таблиц, сделанного с помощью API-интерфейса REST, используйте следующий формат:

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

noteПримечание
Начиная с версии 2009-09-19, служба таблиц требует, чтобы все вызовы REST включали заголовки DataServiceVersion и MaxDataServiceVersion. Дополнительные сведения см. в разделе Установка заголовков версий данных службы OData.

Можно использовать проверку подлинности Shared Key Lite для проверки подлинности запроса, выполняемого к версии 2009-09-19 и более поздним версиям служб BLOB-объектов и очередей, а также к версии 2014-02-14 и более поздним версиям служб файлов.

Строка подписи для Shared Key Lite идентична строке подписи для проверки подлинности Shared Key в версиях служб BLOB-объектов и очередей до версий 2009-09-19. Поэтому если нужно перенести код с минимальным количеством изменений в версии 2009-09-19 служб BLOB-объектов и очередей, можно изменить код, чтобы он использовал Shared Key Lite, не меняя саму строку подписи. Обратите внимание, использование Shared Key Lite не обеспечивает расширение функций безопасности, достигаемое с помощью Shared Key в версии API 2009-09-19 и более поздних версиях.

Для кодирования строки подписи для запроса к службе BLOB-объектов или очередей используйте следующий формат:

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

В следующем примере показана строка подписи для операции Вставка большого двоичного объекта. Обратите внимание, что строка заголовка Content-MD5 пуста. Заголовки, показанные в строке, — это пары "имя-значение", указывающие пользовательские значения метаданных для нового большого двоичного объекта.

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

Затем следует закодировать эту строку, применив алгоритм HMAC-SHA256 к закодированной в UTF-8 строке подписи, создать заголовок Authorization и добавить этот заголовок к запросу. В следующем примере показан заголовок Authorization для той же операции:

Authorization: SharedKeyLite myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

Можно использовать проверку подлинности Shared Key Lite для проверки подлинности запроса, выполняемого к любой версии службы таблиц.

Для кодирования строки подписи для запроса к службе таблиц, сделанного с помощью Shared Key Lite, используйте следующий формат:

StringToSign = Date + "\n" 
               CanonicalizedResource

В следующем примере показана строка подписи для операции Создание таблицы.

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

Затем закодируйте эту строку с помощью алгоритма HMAC-SHA256, создайте заголовок Authorization и добавьте заголовок к запросу. В следующем примере показан заголовок Authorization для той же операции:

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

Чтобы построить часть CanonicalizedHeaders строки подписи, выполните следующие действия.

  1. Получите все заголовки для ресурса, начинающиеся с x-ms-, включая заголовок x-ms-date.

  2. Преобразуйте все имена заголовков HTTP к нижнему регистру.

  3. Лексикографически отсортируйте заголовки по имени в порядке возрастания. Каждый заголовок может появляться в строке только один раз.

    noteПримечание
    Лексикографическое упорядочение может не всегда совпадать с традиционным алфавитным упорядочением.

  4. Разверните строку, заменяя все разрывающие пробелы одним пробелом.

  5. Усеките все пробелы вокруг двоеточия в заголовке.

  6. Наконец, добавьте символ новой строки к каждому каноническому заголовку в полученном списке. Постройте строку CanonicalizedHeaders, объединив все заголовки в этом списке в одну строку.

На приведенном ниже рисунке показан пример строки канонических заголовков.

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

Часть строки подписи CanonicalizedResource представляет ресурс служб хранилища, которому направлен запрос. Любая часть строки CanonicalizedResource, выведенная из URI ресурса, должна быть кодирована точно так же, как в URI.

Для строки CanonicalizedResource поддерживаются два формата.

  • Формат, который поддерживает проверку подлинности Shared Key для версии 2009-09-19 и более поздних версий служб BLOB-объектов и очередей, а также для версии 2014-02-14 и более поздних версий службы файлов.

  • Формат, который поддерживает Shared Key и Shared Key Lite для всех версий службы таблиц, а также Shared Key Lite для версии 2009-09-19 и более поздних версий служб больших двоичных объектов и очередей. Этот формат идентичен тому, что использовался в предыдущих версиях служб хранилища.

Справку по созданию URI для ресурса, к которому производится доступ, см. в одном из следующих разделов:

ImportantВажно!
Если ваша учетная запись хранения реплицируются при использовании георепликации с доступом только для чтения (RA-GRS) и выполняется доступ к ресурсу в дополнительном расположении, не включайте обозначение –secondary в строку CanonicalizedResource. URI ресурса, используемый в URI строки CanonicalizedResource, должен быть URI ресурса из основного расположения.

noteПримечание
При проверке подлинности с помощью эмулятора хранилища имя учетной записи появится в строке CanonicalizedResource дважды. Этого можно ожидать. Если вы выполняете проверку подлинности в службах хранилища Azure, то имя учетной записи отобразится в строке CanonicalizedResource только один раз.

Формат Shared Key версии 2009-09-19 и более поздних версий

Формат, который поддерживает проверку подлинности Shared Key для версии 2009-09-19 и более поздних версий служб BLOB-объектов и очередей, а также для версии 2014-02-14 и более поздних версий службы файлов. Постройте строку CanonicalizedResource в этом формате следующим образом.

  1. Начиная с пустой строки (""), добавьте косую черту (/), а за ней имя учетной записи, владеющей ресурсом, к которому производится доступ.

  2. Добавьте закодированный URI путь к ресурсу без параметров запроса.

  3. Добавляйте символ новой строки (\ n) после имени ресурса.

  4. Получите все параметры запроса для URI источника, включая параметр comp, если он существует.

  5. Преобразуйте все имена параметров к нижнему регистру.

  6. Лексикографически отсортируйте параметры запроса по имени параметра по возрастанию.

  7. Закодируйте в URL имя параметра и значение для каждого запроса.

  8. Добавьте имя и значение каждого параметра запроса к строке в следующем формате, включая двоеточие (:) между именем и значением.

    parameter-name:parameter-value

  9. Если параметр запроса имеет более одного значения, отсортируйте все значения лексикографически, а затем включите их в список с разделителями-запятыми:

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

  10. Добавляйте символ новой строки (\ n) после каждой пары "имя-значение".

Учитывайте следующие правила для создания канонической строки ресурса.

  • Избегайте использования символа новой строки (\ n) в значениях параметров запроса. Если его необходимо использовать, убедитесь, что он не влияет на канонический формат строки ресурса.

  • Не используйте запятые в значениях параметра запроса.

Ниже приведены примеры, в которых показана часть CanonicalizedResource строки подписи, как она может быть построена от заданного URI запроса.


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


Формат Shared Key Lite и службы таблицы версии 2009-09-19 и более поздних версий

Этот формат поддерживает Shared Key и Shared Key Lite для всех версий службы таблиц, Shared Key Lite для версии 2009-09-19 и более поздних версий служб BLOB-объектов и очередей, а также для версии 2014-02-14 и более поздних версий службы файлов. Этот формат идентичен тому, что использовался в предыдущих версиях служб хранилища. Постройте строку CanonicalizedResource в этом формате следующим образом.

  1. Начиная с пустой строки (""), добавьте косую черту (/), а за ней имя учетной записи, владеющей ресурсом, к которому производится доступ.

  2. Добавьте закодированный путь URI ресурса. Если в запросе URI обращается к компоненту ресурса, добавьте соответствующую строку в запрос. Строка запроса должна содержать знак вопроса и параметр comp (например, ?comp=metadata). Никакие другие параметры не должны быть включены в строку запроса.

Для кодирования сигнатуры вызовите алгоритм HMAC-SHA256 для строки сигнатуры в кодировке UTF-8 и закодируйте результат в Base64. Используйте следующий формат (показан как псевдокод):

Signature=Base64(HMAC-SHA256(UTF8(StringToSign)))

См. также

Была ли вам полезна эта информация?
(1500 символов осталось)
Спасибо за ваш отзыв
Показ:
© 2015 Microsoft