Создание SAS делегирования пользователей

Маркер подписанного URL-адреса (SAS) можно защитить для доступа к контейнеру, каталогу или BLOB-объекту с помощью учетных данных Microsoft Entra или ключа учетной записи. SAS, защищенный учетными данными Microsoft Entra, называется делегированием пользователей SAS. Рекомендуется использовать учетные данные Microsoft Entra, если это возможно, а не ключ учетной записи, который может быть проще скомпрометирован. Если для разработки приложения требуются подписанные URL-адреса, используйте учетные данные Microsoft Entra для создания SAS делегирования пользователей, чтобы обеспечить более высокую безопасность.

Каждый SAS подписан ключом. Чтобы создать SAS делегирования пользователей, необходимо сначала запросить ключ делегирования пользователей, который затем используется для подписи SAS. Ключ делегирования пользователей аналогиен ключу учетной записи, используемому для подписи SAS службы или SAS учетной записи, за исключением того, что он использует учетные данные Microsoft Entra. Чтобы запросить ключ делегирования пользователей, вызовите операцию получить ключ делегирования пользователей. Затем можно использовать ключ делегирования пользователей для создания SAS.

Поддерживается пользовательская делегация SAS для Blob Storage, Data Lake Storage, Queue Storage, Table Storage или Azure Files. Хранимые политики доступа не поддерживаются для SAS делегирования пользователей.

Сведения об использовании ключа учетной записи для защиты SAS см. в статье Создание SAS службы и создание SAS учетной записи.

Поддержка пользовательской делегации SAS для доступа в области каталогов (только Blob Storage и Data Lake Storage)

SAS делегирования пользователей поддерживает область каталога (sr=d), если версия авторизации (sv) — 2020-02-10 или более поздней версии, а иерархическое пространство имен (HNS) включено. Семантика для области каталога (sr=d) аналогична области контейнера (sr=c), за исключением того, что доступ ограничен каталогом и любыми файлами и подкаталогами в нем. При указании sr=d также требуется параметр запроса sdd.

Формат входа в строку для авторизации версии 2020-02-10 не изменяется.

Поддержка пользовательской делегации SAS для пользовательского OID (только Blob Storage и Data Lake)

SAS делегирования пользователей поддерживает необязательный идентификатор объекта пользователя (OID), который выполняется в параметре saoid или suoid, если версия авторизации (sv) — 2020-02-10 или более поздней версии. Параметры saoid и suoid соответствуют субъекту безопасности для конечного пользователя, который использует SAS, и предоставляет расширенную модель авторизации для рабочих нагрузок кластера с несколькими пользователями, таких как Hadoop и Spark.

Маркеры SAS могут быть ограничены определенной операцией файловой системы и пользователем, что обеспечивает менее уязвимый маркер доступа, который безопаснее распространять в кластере с несколькими пользователями. Одним из вариантов использования этих функций является интеграция драйвера Hadoop ABFS с Apache Ranger.

Дополнительные сведения о необязательных параметрах saoid и suoid см. в статье Указание подписанного идентификатора объекта пользователя.

Авторизация SAS делегирования пользователей

Когда клиент обращается к ресурсу хранилища BLOB-объектов с SAS делегирования пользователей, запрос к службе хранилища Azure авторизован с учетными данными Microsoft Entra, которые использовались для создания SAS. Доступ клиента к ресурсу определяется следующими разрешениями:

• Разрешения управления доступом на основе ролей (RBAC), предоставляемые субъекту безопасности Microsoft Entra, запрашивающим ключ делегирования пользователей.
• Разрешения списка управления доступом POSIX (ACL), предоставленные субъекту безопасности, запрашивающим ключ делегирования пользователей. Эта дополнительная проверка происходит только в том случае, если разрешения RBAC не могут предоставлять доступ, и только если иерархическое пространство имен включено в учетной записи хранения.
• Разрешения, которые явно предоставляются маркеру SAS.

Этот подход обеспечивает дополнительный уровень безопасности и помогает избежать необходимости хранить ключ доступа к учетной записи с помощью кода приложения. По этим причинам создание SAS с помощью учетных данных Microsoft Entra рекомендуется для обеспечения безопасности.

Разрешения, предоставленные клиенту, обладающему SAS, являются пересечением разрешений, предоставленных субъекту безопасности, запрашивающему ключ делегирования пользователей и разрешения, предоставленные ресурсу маркера SAS с помощью поля signedPermissions (sp) . Если разрешение, предоставленное субъекту безопасности через ACL RBAC или POSIX, также не предоставляется маркеру SAS, это разрешение не предоставляется клиенту, который пытается использовать SAS для доступа к ресурсу. При создании SAS делегирования пользователей убедитесь, что разрешения, предоставленные через списки управления доступом RBAC и POSIX, и разрешения, предоставленные с помощью маркера SAS, соответствуют уровню доступа, который требуется клиенту.

Чтобы создать SAS делегирования пользователей, сделайте следующее:

1. Используйте списки ACL RBAC или POSIX, чтобы предоставить необходимые разрешения субъекту безопасности, запрашивающему ключ делегирования пользователей.
2. Получение маркера OAuth 2.0 из идентификатора Microsoft Entra.
3. Используйте маркер для запроса ключа делегирования пользователей, вызвав операцию получить ключ делегирования пользователей.
4. Используйте ключ делегирования пользователей для создания маркера SAS с соответствующими полями.

Назначение разрешений с помощью RBAC

Субъект безопасности, запрашивающий ключ делегирования пользователей, должен иметь соответствующие разрешения. Субъект безопасности Идентификатора Microsoft Entra может быть пользователем, группой, субъектом-службой или управляемым удостоверением.

Чтобы запросить ключ делегирования пользователя, необходимо назначить принципалу безопасности действие Microsoft.Storage/storageAccounts/{serviceType}/generateUserDelegationKey . Следующие встроенные роли RBAC включают действие Microsoft.Storage/storageAccounts/{serviceType}/generateUserDelegationKey , либо явно, либо в рамках определения wildcard:

• участника
• участник учетной записи хранения
• участник данных BLOB-объектов хранилища
• владельца данных BLOB-объектов хранилища
• средства чтения данных BLOB-объектов хранилища
• хранилище BLOB-объектов Delegator
• Делегатор очереди хранения
• Делегатор стола хранения
• Делегатор файлов хранения

Так как операция получения ключа делегирования пользователей действует на уровне учетной записи хранения, действие Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey должно быть ограничено на уровне учетной записи хранения, группы ресурсов или подписки. Если субъект безопасности назначен любой из перечисленных ранее встроенных ролей или настраиваемой роли, которая включает в себя Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey действие, на уровне учетной записи хранения, группы ресурсов или подписки, субъект безопасности может запросить ключ делегирования пользователей.

Если принципал безопасности назначен на роль, разрешающую доступ к данным, но ограничен уровнем контейнера, вы можете дополнительно назначить роль делегатора хранения (например, делегатор блоков хранилища) принципалу безопасности на уровне аккаунта хранения, группы ресурсов или подписки. Роль делегатора хранения предоставляет принципалу безопасности права запросить ключ делегирования пользователя.

Дополнительные сведения о ролях RBAC для службы хранилища Azure см. в статье Авторизация с помощью Microsoft Entra.

Получение маркера OAuth 2.0

Чтобы получить ключ делегирования пользователей, сначала запросите маркер OAuth 2.0 из идентификатора Microsoft Entra. Предоставьте маркер схеме носителя, чтобы авторизовать вызов получить ключ делегирования пользователей. Дополнительные сведения о запросе маркера OAuth из идентификатора Microsoft Entra см. в потоках проверки подлинности и сценариях приложений.

Запрос ключа делегирования пользователей

Вызов получения ключа делегирования пользователей возвращает ключ в виде набора значений, используемых в качестве параметров маркера SAS делегирования пользователей. Эти параметры описаны в ссылке Get User Delegation Key и в следующем разделе Construct a User delegation SAS.

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

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

Создание SAS делегирования пользователей

В следующей таблице приведены поля, поддерживаемые маркером SAS делегирования пользователей. В последующих разделах содержатся дополнительные сведения об указании этих параметров.

Укажите поле подписанной версии

Необходимое поле signedVersion (sv) указывает версию службы для подписанного URL-адреса. Это значение указывает версию службы, которая используется для создания поля signature, и указывает версию службы, которая обрабатывает запрос, сделанный с помощью этой подписанной url-адреса. Значение поля sv должно быть версии 2018-11-09 или более поздней.

Укажите поле с подписанным ресурсом (только Blob Storage)

Необходимое поле signedResource (sr) указывает, какие ресурсы доступны с помощью подписанного URL-адреса. В следующей таблице описывается, как ссылаться на большой двоичный объект, контейнер или ресурс каталога в маркере SAS:

Укажите поле с подписанным ресурсом (только Azure Files)

Необходимое поле signedResource (sr) указывает, какие ресурсы доступны с помощью подписанного URL-адреса. В следующей таблице описано, как обращаться к файлу или ресурсу для совместного использования в URI.

Задайте параметры запроса для переопределения заголовков ответов (только Blob Storage и Azure Files)

Чтобы определить значения для определенных заголовков ответа, возвращаемых при использовании подписанного URL-адреса в запросе, можно указать заголовки ответа в параметрах запроса. Эта функция поддерживается с версии 2013-08-15 для Blob Storage и версии 2015-02-21 для Azure Files. Подписи общего доступа, использующие эту функцию, должны включать параметры, sv установленные до 2013-08-15 или позже для Blob Storage, или для 2015-02-21 Azure Files.

Заголовки ответов и соответствующие параметры запроса приведены в следующей таблице:

Например, если указать rsct=binary параметр запроса на подписи общего доступа, созданной с версии 2013-08-15 или выше, Content-Type заголовок ответа устанавливается на binary. Это значение переопределяет Content-Type значение заголовка, хранящееся для blob для запроса, использующего только эту подпись общего доступа.

Если вы создаёте сигнатуру общего доступа, которая указывает заголовки ответа как параметры запроса, вы должны включить их в строку от подписи к знаку, используемую для построения строки подписи. Для получения дополнительной информации см. раздел «Укажите подпись » позже в этой статье. Для дополнительных примеров см. примеры Service SAS.

Укажите длительность срока действия подписи

Поля signedStart (st) и signedExpiry (se) указывают время начала и истечения срока действия SAS. Требуется поле signedExpiry. Поле signedStart является необязательным. Если это опущено, текущее время в формате UTC используется в качестве времени начала.

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

Дополнительные сведения о принятых форматах UTC см. в разделе Формат значений DateTime.

Укажите имя таблицы (только хранилище таблиц)

Поле tableName указывает название таблицы для совместного использования.

Указание разрешений

Разрешения, указанные для поля signedPermissions (sp) маркера SAS, указывают, какие операции выполняет клиент, имеющий SAS, может выполняться в ресурсе.

Разрешения можно объединить, чтобы разрешить клиенту выполнять несколько операций с одинаковым SAS. При создании SAS необходимо включить разрешения в следующем порядке:

racwdxltmeop

Примеры допустимых параметров разрешений для контейнера включают rw, rd, rl, wd, wlи rl. Примеры недопустимых параметров включают wr, dr, lrи dw. Указание назначения разрешений несколько раз не разрешено.

SAS делегирования пользователей не может предоставить доступ к определенным операциям:

• Контейнеры, очереди и таблицы нельзя создавать, удалять или перечислять.
• Метаданные и свойства контейнера не могут быть прочитаны или записаны.
• Очереди нельзя очистить, и их метаданные нельзя записать.
• Контейнеры не могут быть арендованы.

Чтобы создать SAS, предоставляющий доступ к этим операциям, используйте SAS учетной записи. Дополнительные сведения см. в статье СозданиеSAS учетной записи.

Разрешения для каталога, контейнера или blob

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

Права на файл

Разрешения на использование

Разрешения для очереди

Разрешения для таблицы

Указание IP-адреса или диапазона IP-адресов

Необязательное поле signedIp (sip) указывает общедоступный IP-адрес или диапазон общедоступных IP-адресов, из которых следует принимать запросы. Если IP-адрес, из которого создается запрос, не соответствует диапазону IP-адресов или диапазону адресов, указанному в маркере SAS, запрос не авторизован. Поддерживаются только адреса IPv4.

При указании диапазона IP-адресов диапазон включается включительно. Например, указание sip=198.51.100.0 или sip=198.51.100.10-198.51.100.20 в SAS ограничивает запрос на эти IP-адреса.

В следующей таблице описывается, следует ли включить поле signedIp в маркер SAS для заданного сценария в зависимости от клиентской среды и расположения учетной записи хранения.

Указание протокола HTTP

Необязательное поле signedProtocol (spr) указывает протокол, разрешенный для запросов, выполненных с помощью SAS. Возможные значения : HTTPS и HTTP (https,http) или только HTTPS (https). Значение по умолчанию — https,http.

Укажите диапазоны доступа к таблице

Поля startPk, startRk, endPkи endRk определяют ряд сущностей таблицы, связанных с общей подписью доступа. Запросы к таблице возвращают только результаты, находящиеся в пределах диапазона, и попытки использовать подпись общего доступа для добавления, обновления или удаления сущностей вне этого диапазона будут неудачными.

Если startPk равно endPk, подпись общего доступа авторизирует доступ к сущностям только в одном разделе таблицы.

Если startPk равно endPk и startRk равно endRk, подпись общего доступа может получить доступ только к одной сущности в одном разделе.

Чтобы понять, как эти поля ограничивают доступ к сущностям в таблице, обратитесь к следующей таблице:

Укажите идентификатор подписанного объекта

Поле signedObjectId (skoid) требуется для SAS делегирования пользователей. Операция получения ключа делегирования пользователей возвращает это значение в рамках ответа. Подписанный идентификатор объекта — это значение GUID, которое служит неизменяемым идентификатором субъекта безопасности на платформе удостоверений Майкрософт.

Указание подписанного идентификатора клиента

Поле signedTenantId (sktid) требуется для SAS делегирования пользователей. Операция получения ключа делегирования пользователей возвращает это значение в рамках ответа. Подписанный идентификатор клиента — это значение GUID, представляющее клиент Microsoft Entra, в котором определен субъект безопасности.

Указание времени начала подписанного ключа

Необходимое поле signedKeyStartTime (skt) указывает начало времени существования ключа делегирования пользователя в формате ISO Date. Операция получения ключа делегирования пользователей возвращает это значение в рамках ответа.

Указание срока действия подписанного ключа

Поле signedKeyExpiryTime (ske) требуется для SAS делегирования пользователей в формате ISO Date. Операция получения ключа делегирования пользователей возвращает это значение в рамках ответа. Время истечения срока действия подписанного ключа указывает конец времени существования ключа делегирования пользователей. Значение срока действия может быть не более семи дней с момента начала SAS.

Указание службы подписанных ключей

Поле signedKeyService (sks) требуется для SAS делегирования пользователей. Операция получения ключа делегирования пользователей возвращает это значение в рамках ответа. Поле службы подписанных ключей указывает службу, для которой допустимы ключ делегирования пользователей. Значение поля службы подписанных ключей для хранилища BLOB-объектов b.

Указание версии подписанного ключа

Поле signedkeyversion (skv) требуется для SAS делегирования пользователей. Операция получения ключа делегирования пользователей возвращает это значение в рамках ответа. Поле signedkeyversion указывает версию службы хранилища, которая используется для получения ключа делегирования пользователей. Это поле должно указать версию 2018-11-09 или более позднюю.

Указание подписанного идентификатора объекта пользователя для субъекта безопасности

Необязательные поля signedAuthorizedObjectId (saoid) и signedUnauthorizedObjectId (suoid) позволяют интегрироваться с Apache Hadoop и Apache Ranger для рабочих нагрузок Azure Data Lake Storage. Используйте одно из этих полей в маркере SAS, чтобы указать идентификатор объекта для субъекта безопасности:

• Поле saoid указывает идентификатор объекта для субъекта безопасности Microsoft Entra, авторизованного владельцем ключа делегирования пользователей для выполнения действия, предоставленного маркером SAS. Служба хранилища Azure проверяет маркер SAS и гарантирует, что владелец ключа делегирования пользователя имеет необходимые разрешения, прежде чем служба хранилища Azure предоставляет доступ. Дополнительная проверка разрешений на списки ACL POSIX не выполняется.
• Поле suoid указывает идентификатор объекта для субъекта безопасности Microsoft Entra, если иерархическое пространство имен включено для учетной записи хранения. Поле suoid допустимо только для учетных записей с иерархическим пространством имен. Если поле suoid входит в маркер SAS, служба хранилища Azure выполняет проверку ACL POSIX по идентификатору объекта перед авторизацией операции. Если эта проверка ACL не выполнена, операция завершается ошибкой. Иерархическое пространство имен должно быть включено для учетной записи хранения, если поле suoid входит в маркер SAS. В противном случае проверка разрешений завершится ошибкой авторизации.

Идентификатор объекта для субъекта безопасности, запрашивающего ключ делегирования пользователей, фиксируется в требуемом поле skoid. Чтобы указать идентификатор объекта для маркера SAS с помощью поля saoid или suoid, Субъект безопасности, определенный в поле skoid, должен быть назначен роль RBAC, которая включает Microsoft.Storage/storageAccounts/blobServices/container/blobs/runAsSuperUser/action или Microsoft.Storage/storageAccounts/blobServices/container/blobs/manageOwnership/action. Дополнительные сведения об этих действиях см. в операциях поставщика ресурсов Azure.

Указав идентификатор объекта в поле saoid или suoid, можно также ограничить операции, связанные с владельцем каталога или БОЛЬШОго двоичного объекта, следующим образом:

• Если операция создает каталог или большой двоичный объект, служба хранилища Azure задает владельцу каталога или большого двоичного объекта значение, указанное идентификатором объекта. Если идентификатор объекта не указан, служба хранилища Azure задает владельцу каталога или большого двоичного объекта значение, указанное параметром skoid.
• Если в родительском каталоге задана липкая бита, а операция удаляет или переименовывает каталог или большой двоичный объект, идентификатор объекта владельца родительского каталога или владельца ресурса должен соответствовать значению, указанному идентификатором объекта.
• Если операция задает владельца каталога или большого двоичного объекта и заголовок x-ms-owner, то значение, указанное идентификатором объекта, должно соответствовать значению, заданному заголовком x-ms-owner.
• Если операция задает группу для каталога или большого двоичного объекта и заголовок x-ms-group, то значение, указанное идентификатором объекта, должно быть членом группы, указанной заголовком x-ms-group.
• Если операция задает разрешения или ACL для каталога или большого двоичного объекта, необходимо выполнить одно из следующих двух условий:
  • Значение, указанное для идентификатора объекта, должно быть владельцем каталога или большого двоичного объекта.
  • Значение поля signedPermissions (sp) должно содержать разрешение Ownership (o) в дополнение к разрешению Permissions (p) .

Идентификатор объекта, указанный в поле saoid или suoid, включается в журналы диагностики при выполнении запросов с помощью маркера SAS.

Поле saoid или suoid поддерживается только в том случае, если для поля signedVersion (sv) задано значение версии 2020-02-10 или более поздней. В маркер SAS можно включить только одно из этих полей.

Указание идентификатора корреляции

Поле signedCorrelationId (scid) указывает идентификатор корреляции, который может использоваться для сопоставления журналов аудита хранилища с журналами аудита, используемыми субъектом, создающим и распространяющим SAS. Например, у доверенной службы авторизации обычно есть управляемое удостоверение, которое выполняет проверку подлинности и авторизацию пользователей, создает SAS, добавляет запись в локальный журнал аудита и возвращает SAS пользователю, который затем может использовать SAS для доступа к ресурсам службы хранилища Azure. Включив идентификатор корреляции как в локальный журнал аудита, так и в журнал аудита хранилища, эти события можно сопоставить позже. Значением является GUID без фигурных скобок и строчных символов.

Это поле поддерживается с версией 2020-02-10 и более поздними версиями.

Укажите делегированного пользователя

Необязательное sduoid поле гарантирует, что только указанный пользователь может получить доступ к ресурсам с помощью токена SAS.

Поле sduoid указывает идентификатор объекта для принципа безопасности Microsoft Entra, который принадлежит конечному пользователю. При указании вызывающий также должен отправить токен Bearer; Его претензия на OID должна совпадать с sduoid. Кроме того, конечный пользователь должен находиться в том же entra tenant, что и аккаунт хранения.

Дополнительное skdutid поле требуется только тогда, когда арендатор Microsoft Entra определённого sduoid пользователя отличается от арендатора аккаунта хранилища. Перед использованием этого поля необходимо также указать DelegatedUserTid при вызове API Get User Delegation Key Key.

Поле skdutid представляет идентификатор арендатора (tid ) принципала Microsoft Entra по безопасности, который будет использовать токен SAS. Когда skduti включено:

• Вызывающий должен предъявить жетон предъявителя, чья tid-заявка соответствует значению skdutid.
• Значение DelegatedUserTid в возвращаемом UserDelegationKey также должно совпадать skdutidс .

Эти проверки гарантируют, что токен SAS может использоваться только для идентификаторов от правильного арендатора Microsoft Entra, сохраняя сильную изоляцию на уровне арендатора для делегированного доступа.

Указание глубины каталога

Если поле signedResource указывает каталог (sr=d), необходимо также указать поле signedDirectoryDepth (sdd), чтобы указать количество подкаталогов в корневом каталоге. Значение поля sdd должно быть неотрицательное целое число.

Например, корневой каталог https://{account}.blob.core.windows.net/{container}/ имеет глубину 0. Каждая подкаталога в корневом каталоге добавляется к глубине на 1. Каталог https://{account}.blob.core.windows.net/{container}/d1/d2 имеет глубину 2.

Это поле поддерживается с версией 2020-02-10 и более поздними версиями.

Закажите подписанные заголовки запроса и параметры запроса

Используйте srh (signedRequestHeaders) для перечисления заголовков, которые должны быть в запросе. Указывайте имена заголовков в виде списка, разделённого запятой. Каждый заголовок, указанный в , srh должен отображаться в запросе, а канонизированные значения должны совпадать с теми, что были включены при создании SAS. Дублирующиеся или пустые имена заголовков отклоняются.

Используйте srq (signedRequestQueryParameters) для перечисления параметров запроса, которые должны быть в запросе. Приведите имена параметров в виде списка, разделённого запятой. Каждый параметр, указанный в , srq должен отображаться в URI запроса, а Azure Storage проверяет канонизированные пары имени и значения при оценке токена SAS.

Когда srh указано или srq указано, заполнить канонизированные поля, которые добавляются в строку в знак при версии авторизации 2026-04-06 и более позднее:

Generate canonicalizedSignedRequestHeaders

• Соберите заголовки, перечисленные в srh том же порядке, в котором они отображаются в srh.
• Нормализуйте каждый заголовок в headerName:headerValue и завершите каждую пару новой строкой (\n).
• Если запрос содержит несколько значений для одного и того же заголовка, соединяйте значения с запятыми в порядке получения перед добавлением новой строки. Названия заголовков должны появляться только один раз.
• Не включайте пустые названия заголовков. Запросы, в которых не указаны заголовки, не проходят авторизацию.

Generate canonicalizedSignedRequestQueryParameters

• Соберите параметры запроса, перечисленные в srq том же порядке, в котором они появляются в srq.
• Нормализуйте каждый параметр до parameterName=parameterValue и добавите новую строку\n ().
• Если запрос предоставляет несколько значений параметра, соединяйте значения с запятыми в порядке получения перед добавлением каждой новой строки.
• Имена параметров не должны быть пустыми. Если имя параметра содержит запятую, закодировать запятую в URI запроса (например, %2C), но использовать незакодированное имя в канонизированной строке.

Эти канонизированные строки вставляются в строку-знак так, чтобы только запросы, воссоздающие те же значения параметров заголовка и запроса, были успешны. Если srh или srq опущена, соответствующая канонизированная строка рассматривается как пустая строка.

Пример: Базовый динамический сценарий использования SAS

Следующий SAS-фрагмент требует одного пользовательского заголовка и одного параметра запроса:

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

Headers:
foo:123
bar:456

Когда клиент отправляет запрос, динамические компоненты, добавленные в строку к знаку, должны выглядеть так (без двойных кавычек)

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

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

Пример: Крайние случаи с повторяющимися значениями и закодированными именами

Рассмотрим SAS, который требует двух заголовков и параметра запроса, имя которого содержит запятую:

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

Если клиент отправляет следующие метаданные запроса:

foo:123
bar:456
foo:789

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

Тогда канонизированные строки, которые должны быть включены в оценку подписи, следующие:

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

Обратите внимание, что значения заголовков соединяются запятыми в порядке получения, в то время как параметр запроса сохраняет своё незакодированное имя (day,id) внутри канонизированной строки, даже если URL запроса кодирует запятую как %2C.

Указание параметров запроса для переопределения заголовков ответа

Чтобы определить значения для определенных заголовков ответа, возвращаемых при использовании подписанного URL-адреса в запросе, можно указать заголовки ответа в параметрах запроса. Заголовки ответа и соответствующие параметры запроса приведены следующим образом:

Например, если указать параметр запроса rsct=binary для маркера SAS, заголовок ответа Content-Type имеет значение binary. Это значение переопределяет значение заголовка Content-Type, хранящееся для большого двоичного объекта для запроса, используя только эту подпись общего доступа.

При создании подписанного URL-адреса, указывающего заголовки ответов в качестве параметров запроса, необходимо включить эти заголовки ответа в подписи, которая используется для создания строки подписи. Дополнительные сведения см. в разделе "Указаниеподписи".

Указание области шифрования

Поле signed encryption scope (ses) указывает область шифрования, которую клиентское приложение использует при отправке больших двоичных объектов с помощью маркера SAS через операцию Put BLOB-объект. Поле signed encryption scope поддерживается при использовании подписанной версии (sv) маркера SAS версии 2020-12-06 или более поздней. Если поле подписанной версии указывает версию, которая выше поддерживаемой версии, служба возвращает код ответа об ошибке 403 (запрещено).

Если для контейнера или файловой системы задана область шифрования по умолчанию, поле ses учитывает политику шифрования контейнеров. Если между параметром запроса ses и заголовком x-ms-default-encryption-scope имеется несоответствие, а заголовок x-ms-deny-encryption-scope-override имеет значение true, служба возвращает код ответа на ошибку 403 (запрещено).

Если заголовок x-ms-encryption-scope и параметр запроса ses указаны как в запросе PUT, так и есть несоответствие, служба возвращает код ответа на ошибку 400 (недопустимый запрос).

Указание подписи

Поле signature (sig) используется для авторизации запроса, сделанного клиентом с подписью общего доступа. Строка —это уникальная строка, созданная из полей, которые должны быть проверены для авторизации запроса. Сигнатура — это HMAC, вычисленная по протоколу "строка — подпись" с помощью алгоритма SHA256, а затем закодированная с помощью кодировки Base64.

Чтобы создать строку подписи SAS делегирования пользователей, создайте строку для входа из полей, составляющих запрос, закодируйте строку как UTF-8, а затем вычислить подпись с помощью алгоритма HMAC-SHA256. Поля, включенные в вход, должны быть декодированы ПО URL-адресу.

Поля, необходимые в строковом входе, зависят от версии службы, используемой для авторизации (полеsv). В следующих разделах описана конфигурация входа в строку для версий, поддерживающих SAS делегирования пользователей.

Версия 2026-04-06 и более поздние (Blob Storage и Data Lake Storage)

Версия авторизации 2026-04-06 вводит канонизированные строки для srh и srq. Заполните эти значения так, как описано в разделе «Укажите подписанные заголовки запроса и параметры запроса ». Используйте пустые строки, когда srh они опускаются или srq опускаются.

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

Версия 2025-07-05 и более поздние версии

Строка для Blob Storage с авторизационной версией 2025-07-05 и более поздней имеет следующий формат:

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

Строка для Table Storage с версией авторизации 2025-07-05 и более поздней имеет следующий формат:

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

Строка для Queue Storage с авторизацией версии 2025-07-05 и более поздней имеет следующий формат:

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

Строка для подписи Azure Files с авторизацией версии 2025-07-05 и более поздней имеет следующий формат:

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

Версия 2020-12-06 и более поздних версий

Строковый вход для авторизации версии 2020-12-06 и более поздних версий имеет следующий формат:

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

Версия 2020-02-10

Строковый вход для авторизации версии 2020-02-10 имеет следующий формат:

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

Версии ранее 2020-02-10

Строка входа для версий авторизации, предшествующих версии 2020-02-10, имеет следующий формат:

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

Канонизированный ресурс

canonicalizedResource часть строки является каноническим путем к подписанному ресурсу. Он должен содержать конечную точку хранилища BLOB-объектов (либо blobdfs) и имя ресурса, а также должен быть декодирован с помощью URL-адреса. Путь большого двоичного объекта должен содержать его контейнер. Путь к каталогу должен содержать количество подкаталогов, соответствующих параметру sdd.

Каноническая строка ресурса для контейнера должна опустить косую черту (/) для SAS, предоставляющей доступ к такому контейнеру.

В следующих примерах показано, как создать canonicalizedResource часть строки в зависимости от типа ресурса.

Пример контейнера (хранилище BLOB-объектов Azure)

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

Пример BLOB-объектов (хранилище BLOB-объектов Azure)

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

Пример контейнера (Azure Data Lake Storage)

URL = https://myaccount.dfs.core.windows.net/music  
canonicalizedResource = "/blob/myaccount/music"  

Пример каталога (Azure Data Lake Storage)

URL = https://myaccount.dfs.core.windows.net/music/instruments/guitar/  
canonicalizedResource = "/blob/myaccount/music/instruments/guitar/"  

Пример BLOB-объектов (Azure Data Lake Storage)

URL = https://myaccount.dfs.core.windows.net/music/intro.mp3  
canonicalizedResource = "/blob/myaccount/music/intro.mp3"  

Файловые ресурсы

Для версии 2025-07-05 и более позднее:

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

Files

Для версии 2025-07-05 и более позднее:

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

Queues

Для версии 2025-07-05 и более позднее:

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

Tables

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

Для версии 2025-07-05 и более позднее:

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

Необязательные поля

Если поле является необязательным и не предоставляется в рамках маркера SAS, укажите пустую строку для поля. Не забудьте включить новый символ (\n) после пустой строки.

Пример SAS делегирования пользователей

В следующем примере показан URI BLOB-объектов с маркером SAS делегирования пользователей, добавленным к нему. Маркер SAS делегирования пользователей предоставляет разрешения на чтение и запись большого двоичного объекта.

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>

Каждая часть URI описана в следующей таблице:

Отмена SAS делегирования пользователей

Если вы считаете, что SAS скомпрометирован, его следует отозвать. Вы можете отменить SAS делегирования пользователей, отменив ключ делегирования пользователей или изменив или удалив назначения ролей RBAC и списки ACL POSIX для субъекта безопасности, используемого для создания SAS.

Отзыв ключа делегирования пользователей

Ключ делегирования пользователя можно отозвать, вызвав операцию отмены ключей делегирования пользователей. При отмене ключа делегирования пользователей все подписанные URL-адреса, использующие этот ключ, становятся недействительными. Затем можно снова вызвать операцию получить ключ делегирования пользователей и использовать ключ для создания новых подписанных URL-адресов. Это самый быстрый способ отозвать SAS делегирования пользователей.

Изменение или удаление назначений ролей или списков управления доступом

Вы можете изменить или удалить назначение ролей RBAC и списки ACL POSIX для субъекта безопасности, используемого для создания SAS. Когда клиент использует SAS для доступа к ресурсу, служба хранилища Azure проверяет, что субъект безопасности, учетные данные которого использовались для защиты SAS, имеют необходимые разрешения для ресурса.

См. также

• Делегирование доступа с помощью подписанного URL-адреса
• создание SAS службы
• Создание учетной записи SAS
• коды ошибок SAS