Предоставление ограниченного доступа к ресурсам службы хранилища Azure с помощью подписанных URL-адресов (SAS)

Подписанный URL-адрес (SAS) предоставляет защищенный делегированный доступ к ресурсам в учетной записи хранения. С помощью SAS вы можете детально контролировать процесс получения клиентом доступа к данным. Например:

• Ресурсы, к которым может получить доступ клиент.

• Какие разрешения есть у клиента для этих ресурсов.

• Как долго действует SAS.

Типы подписанных URL-адресов

Служба хранилища Azure поддерживает три типа подписанных URL-адресов:

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

• SAS уровня службы

• SAS для учетной записи

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

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

Дополнительные сведения о SAS для делегирования пользователей см. в статье Создание SAS для делегирования пользователей (REST API).

SAS уровня службы

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

Дополнительные сведения об SAS для службы см. в разделе Создание SAS для службы (REST API).

SAS для учетной записи

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

Вы также можете делегировать доступ следующим операциям:

• Операции уровня службы (например, операции Получить/задать свойства службы и Получить статистику службы).

• Операции чтения, записи и удаления, которые не разрешены с помощью SAS для службы.

Чтобы получить дополнительные сведения о SAS для учетной записи, изучите статью Создание SAS для учетной записи (REST API).

Подписанный URL-адрес может принимать одну из двух форм:

• Специальный SAS. При создании специального SAS время начала, время окончания срока действия и разрешения указываются в универсальном коде ресурса (URI) SAS. SAS любого типа может быть специальным.

• SAS для службы с хранимой политикой доступа. Хранимая политика доступа определяется в контейнере ресурсов — контейнере больших двоичных объектов, таблице, очереди или общей папке. Хранимая политика доступа может использоваться для управления ограничениями одного или нескольких подписанных URL-адресов для службы. При сопоставлении подписанного URL-адреса для службы с хранимой политикой доступа этот адрес наследует ограничения (время начала, время окончания и разрешения), определенные для данной хранимой политики доступа.

Принцип работы подписанного URL-адреса

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

Подпись и авторизация SAS

Маркер SAS можно подписать с помощью ключа делегирования пользователей или ключа учетной записи хранения (общий ключ).

Подписывание маркера SAS с помощью ключа делегирования пользователей

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

Чтобы получить ключ, а затем создать SAS, субъект безопасности Microsoft Entra должен быть назначен роли Azure, которая включает Microsoft.Storage/storageAccounts/blobServices/generateUserDelegationKey действие. Дополнительные сведения см. в разделе Создание SAS для делегирования пользователей (REST API).

Подписание маркера SAS с помощью ключа учетной записи

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

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

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

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

Маркер SAS

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

Клиентские приложения предоставляют URI SAS в службу хранилища Azure как часть запроса. Затем служба проверяет параметры SAS и подпись, чтобы убедиться, что она действительна. Если служба подтверждает эту подпись, выполнение запроса разрешается. В противном случае запрос отклоняется и происходит ошибка с кодом 403 (запрещено).

Ниже приведен пример URI SAS службы, показывающий URI ресурса, символ разделителя ('?) и маркер SAS.

Когда следует использовать подписанный URL-адрес?

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

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

1. клиенты отправляют и скачивают данные с помощью службы интерфейсного прокси-сервера, выполняющей аутентификацию. Эта служба интерфейсного прокси-сервера позволяет проверять бизнес-правила. Однако для больших объемов данных или крупных транзакций создание службы, поддерживающей масштабирование в соответствии с потребностями, может оказаться дорогостоящей или сложной задачей.

   

2. Облегченная служба аутентифицирует клиент по мере необходимости, а затем создает SAS. После того как клиентское приложение получит SAS, оно может получить доступ к ресурсам учетной записи хранения напрямую. Разрешения на доступ определяются SAS и для интервала, разрешенного SAS. Подписанный URL-адрес уменьшает потребность в маршрутизации всех данных через службу интерфейсного прокси-сервера.

   

Многие реальные службы могут использовать сочетание этих двух подходов. Например, некоторые данные могут обрабатываться и проверяться интерфейсным прокси-сервером. Другие данные сохраняются и (или) считываются напрямую с помощью SAS.

Кроме того, в некоторых сценариях SAS потребуется для авторизации доступа к исходному объекту в операции копирования:

• При копировании большого двоичного объекта в другой большой двоичный объект, который относится к другой учетной записи хранения.

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

• При копировании файла в другой файл, который относится к другой учетной записи хранения.

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

• При копировании большого двоичного объекта в файл или файла в большой двоичный объект.

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

Рекомендации по использованию SAS

При использовании подписей общего доступа в приложениях необходимо иметь в виду две потенциальные проблемы:

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

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

Следующие рекомендации по использованию подписанных URL-адресов помогут нейтрализовать эти риски:

• Всегда используйте HTTPS для создания подписанного URL-адреса или его распространения. Если SAS, который передается по протоколу HTTP, будет перехвачен, злоумышленник, выполняющий атаку "злоумышленник в середине", сможет читать SAS. Затем он может использовать этот SAS так же, как и предполагаемый пользователь. При этом возможна компрометация конфиденциальных данных или повреждение данных злоумышленником.

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

• Подготовьте план отзыва для SAS. Убедитесь, что вы готовы отреагировать, если SAS скомпрометирован.

• Настройте политику срока действия SAS в учетной записи хранения. Политика срока действия SAS задает рекомендуемый интервал, в течение которого SAS является действительным. Политики срока действия SAS применяются к SAS службы или SAS учетной записи. Когда пользователь создает SAS службы или SAS учетной записи, у которого срок действия превышает рекомендуемый интервал, он увидит предупреждение. Если в Azure Monitor включено ведение журнала для службы хранилища Azure, то в журналы службы хранилища Azure сохраняется соответствующая запись. Подробнее см. в статье Создание политики срока действия для подписанных URL-адресов.

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

• Используйте быстро истекающие сроки действия для специального SAS для службы или SAS для учетной записи. Таким образом, даже если SAS скомпрометирован, он будет действителен только в течение короткого времени. Это особенно важно в случаях, когда нельзя ссылаться на хранимую политику доступа. Небольшой срок также позволяет ограничить объем данных, который может быть записан в большой двоичный объект, путем ограничения времени на отправку этих данных.

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

• Будьте осторожны со временем начала действия SAS. Если в качестве времени начала для SAS задано текущее время, в течение первых нескольких минут периодически могут происходить сбои. Это происходит из-за того, что текущее время на разных компьютерах слегка различается (это называется рассинхронизацией часов). В общем, устанавливайте время начала действия на 15 минут или более в прошлом времени. Или не задавайте вообще. Так SAS будет немедленно становиться действительным во всех случаях. То же касается и времени истечения срока действия. Помните, что для каждого запроса может наблюдаться рассинхронизация по времени до 15 минут в любом направлении. Для клиентов, использующих версию REST ниже 12.02.2012, максимальная продолжительность для SAS, который не ссылается на хранимую политику доступа, составляет 1 час. Все политики, которые задают срок более 1 часа, завершатся ошибкой.

• Будьте внимательны с форматом даты и времени в SAS. Для AzCopy и некоторых других служебных программ значения даты и времени должны иметь формат "+%Y-%m-%dT%H:%M:%SZ". Этот формат, в частности, содержит секунды.

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

  Нет прямого способа определить, к каким клиентам был доступ к ресурсу. Однако для отслеживания доступа можно использовать уникальные поля в SAS, подписанный IP-адрес (), подписанный начальный (sipst) и подписанный срок действия (se). Например, можно создать маркер SAS с уникальным временем истечения срока действия, которое затем можно сопоставить с клиентом, которому он был выдан.

• Поймите, что счет за использование учетной записи будет выставлен счет при любом использовании, в том числе с помощью SAS. Если вы предоставляете доступ на запись к BLOB-объекту, пользователь может отправить BLOB-объект размером 200 ГБ. Если вы также предоставляете доступ на чтение, пользователь может скачать его 10 раз, в результате чего вам потребуется оплачивать исходящий трафик объемом 2 ТБ. Опять же, ограниченные разрешения помогают сузить спектр возможностей злоумышленников. Используйте краткосрочные подписи, чтобы снизить угрозу (но помните о влиянии рассинхронизации часов на время окончания действия).

• Проверьте данные, записанные с помощью SAS. Когда клиентское приложение записывает данные в вашу учетную запись хранения, помните, что эти данные могут стать источником проблем. Если вы планируете проверить данные, выполните эту проверку после того, как данные будут записаны и до того, как они будут использоваться приложением. Такой подход также обеспечивает защиту от поврежденных или вредоносных данных, записываемых в вашу учетную запись как пользователем, который получил подпись правомерно, так и пользователем, использующим подпись после ее утечки.

• Узнайте, когда не следует использовать SAS. Иногда риски для вашей учетной записи хранения, связанные с конкретной операцией, перевешивают преимущества использования SAS. Для таких операций создавайте службу среднего уровня, которая записывает данные в вашу учетную запись хранения после выполнения проверки, проверки подлинности и аудита на основании бизнес-правил. Кроме того, иногда проще организовать управление доступом другим образом. Например, если вы хотите сделать все BLOB-объекты в контейнере общедоступными для чтения, вместо предоставления всем клиентам подписанного URL-адреса можно сделать этот контейнер общедоступным.

• Используйте Azure Monitor и журналы службы хранилища Azure для мониторинга приложения. Ошибки авторизации могут возникать из-за сбоя в службе поставщика SAS. Они также могут возникать из-за непреднамеренного удаления хранимой политики доступа. Вы можете использовать Azure Monitor и ведение журнала аналитики хранилища, чтобы отслеживать резкое увеличение количества этих типов ошибок авторизации. Дополнительные сведения см. в разделе Метрики службы хранилища Azure в Azure Monitor и Аналитика службы хранилища Azure. Ведение журналов.

• Настройте политику срока действия SAS в учетной записи хранения. Рекомендуется ограничить интервал для SAS в случае взлома. Задав политику срока действия SAS для учетных записей хранения, вы можете установить рекомендуемый верхний предел срока действия, когда пользователь создает SAS или учетную запись SAS. Дополнительные сведения см. в статье "Создание политики истечения срока действия для подписей общего доступа".

Начало работы с SAS

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

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

• Создание SAS для делегирования пользователей для контейнера или большого двоичного объекта с помощью PowerShell
• Создание SAS для делегирования пользователей для контейнера или большого двоичного объекта с помощью Azure CLI
• Создание SAS делегирования пользователей для контейнера или большого двоичного объекта с помощью .NET

SAS уровня службы

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

SAS для учетной записи

• Создание SAS для учетной записи с помощью .NET

Следующие шаги

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