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

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

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

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

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

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

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

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

  • SAS для службы

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

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

Безопасность SAS для делегирования пользователей обеспечивается с помощью учетных данных Azure Active Directory (Azure AD), а также разрешений, указанных для 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).

Примечание

Майкрософт рекомендует использовать учетные данные Azure AD, если это возможно, в целях безопасности, вместо применения ключа учетной записи, который легче скомпрометировать. Если для разработки приложения требуются подписанные URL-адреса для доступа к хранилищу больших двоичных объектов, используйте учетные данные Azure AD, чтобы создать SAS для делегирования пользователей, если это возможно, для обеспечения высокого уровня безопасности. Дополнительные сведения см. в статье Авторизация доступа к данным в службе хранилища Azure.

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

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

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

Примечание

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

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

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

Примечание

Аудит создания маркеров SAS невозможен. Любой пользователь, имеющий права на создание маркера SAS с помощью ключа учетной записи или назначения роли Azure, может сделать это, не зная владельца учетной записи хранения. Будьте внимательны, чтобы ограничить разрешения, позволяющие пользователям создавать маркеры SAS. Чтобы запретить пользователям создавать SAS, подписанный ключом учетной записи для рабочих нагрузок BLOB-объектов и очередей, можно запретить доступ к учетной записи хранения по общему ключу. Дополнительные сведения см. в статье Предотвращение авторизации с помощью общего ключа.

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

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

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

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

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

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

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

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

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

Тип SAS Тип авторизации
SAS для делегирования пользователей (только хранилище BLOB-объектов) Azure AD
SAS для службы Общий ключ
SAS для учетной записи Общий ключ

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

Маркер SAS

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

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

Ниже приведен пример URI SAS для службы, в котором показаны URI ресурса и маркер SAS. Так как маркер SAS состоит из строки запроса URI, после URI ресурса необходимо сначала указать вопросительный знак, а затем маркер SAS:

Components of a service SAS URI

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

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

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

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

    Scenario diagram: Front-end proxy service

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

    Scenario diagram: SAS provider service

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

SAS для службы

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

Дальнейшие действия