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

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

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

Типы подписей общего доступа

Azure Storage поддерживает три типа подписанных URL доступа:

• SAS для делегирования пользователей
• Уровень обслуживания SAS
• САС учетной записи

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

Пользовательская делегированная SAS защищена учетными данными Microsoft Entra, а также разрешениями, определенными для SAS. SAS делегирования пользователей поддерживается для Хранилища объектов BLOB (включая Data Lake Storage и конечные точки dfs), хранилища очередей, табличного хранилища или Azure Files.

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

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

SAS службы защищается ключом учетной записи хранилища. SAS службы делегирует доступ к ресурсу только в одной из служб Azure Storage: Blob Storage (включая Data Lake Storage и конечные точки dfs), хранилище очередей, хранилище таблиц или Azure Files.

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

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

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

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

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

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

Совместная подпись доступа может принимать одну из следующих двух форм:

• Ад-хок SAS. При создании ad hoc SAS время начала, время окончания и разрешения указываются в SAS URI. SAS любого типа может быть одноразовым.
• Service SAS с хранимой политикой доступа. Заданная политика доступа определяется на контейнере ресурсов, который может быть контейнером блобов, таблицей, очередью или общей папкой. Хранимая политика доступа может использоваться для управления ограничениями для одной или нескольких служб с разделяемыми подписями доступа. При связывании служебного SAS с хранимой политикой доступа, SAS наследует ограничения — время начала, разрешения и срок действия, определенные для хранимой политики доступа.

Как работает общая подпись доступа

Общая сигнатура доступа — это маркер, добавляемый к URI для ресурса Azure Storage. Маркер, содержащий специальный набор параметров запроса, указывающий, как ресурсы могут быть доступны клиенту. Один из параметров запроса (подпись) состоит из параметров 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 Storage для предоставления доступа клиенту, обладающему SAS.

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

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

Маркер SAS

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

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

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

Когда следует использовать подписанный общий доступ

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

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

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

   

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

   

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

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

• При копировании объекта BLOB в другой объект BLOB, расположенный в другой учетной записи хранения. Кроме того, можно использовать SAS для авторизации доступа к целевому объекту BLOB.
• При копировании файла в файл, который находится в другой учетной записи хранения. Кроме того, можно использовать SAS для авторизации доступа к целевому файлу.
• При копировании большого двоичного объекта в файл или файла в большой двоичный объект. Необходимо использовать SAS, даже если исходные и целевые объекты находятся в той же учетной записи storage.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Начните работать с SAS

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

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

• Создайте SAS с делегированием пользователей для контейнера или блоба с помощью PowerShell
• Создать SAS делегирования пользователя для контейнера или BLOB с помощью Azure CLI
• Создайте SAS делегирования пользователя для контейнера или BLOB с .NET
• Создайте делегированный SAS пользователя для контейнера или BLOB с использованием Python
• Создайте SAS для делегирования пользователей для контейнера или BLOB с помощью JavaScript
• Создайте маркер делегирования пользователя SAS для контейнера или BLOB с помощью Java

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

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

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

• Создать учетную запись SAS с .NET
• Создайте учетную запись SAS с помощью Python
• Создайте учетную запись SAS с помощью JavaScript
• Создать учётную запись SAS в Java

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

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