Авторизация доступа к ресурсам Центров событий с помощью подписанных URL-адресов

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

Примечание.

В этой статье описывается авторизация доступа к ресурсам Центров событий с помощью SAS. Сведения о проверке подлинности ресурсов Центров событий с помощью SAS см. в статье "Проверка подлинности с помощью SAS".

Что такое подписанные URL-адреса?

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

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

Примечание.

Центры событий Azure также поддерживает авторизацию ресурсов Центров событий с помощью идентификатора Microsoft Entra. Авторизация пользователей или приложений с помощью маркера OAuth 2.0, возвращаемого идентификатором Microsoft Entra, обеспечивает более высокую безопасность и простоту использования через подписанные URL-адреса (SAS). С идентификатором Microsoft Entra не требуется хранить маркеры в коде и риск потенциальных уязвимостей безопасности.

Корпорация Майкрософт рекомендует использовать идентификатор Microsoft Entra с Центры событий Azure приложениями, когда это возможно. Дополнительные сведения см. в статье "Авторизация доступа к ресурсу Центры событий Azure с помощью идентификатора Microsoft Entra".

Важно!

Токены SAS (подписанные URL-адреса) имеют очень важное значение для защиты ресурсов. Обеспечивая детализацию, SAS предоставляет клиентам доступ к вашим ресурсам центров событий. Не следует предоставлять к ним общий доступ. Если общий доступ необходим в целях устранения неполадок, используйте сокращенную версию файлов журнала или удалите токены SAS (если есть) из файлов журнала, а также убедитесь, что снимки экрана не содержат данные о SAS.

Политики авторизации общего доступа

Каждое пространство имен Центров событий и каждая сущность Центров событий (концентратор событий или раздел Kafka) содержит политику авторизации общего доступа, состоящей из правил. Политика на уровне пространства имен применяется ко всем сущностям в пространстве имен независимо от настройки их политики. Для каждого правила политики авторизации необходимо выбрать три фрагмента данных: имя, область и права. Имя — это уникальное имя для данной области. Область — это универсальный код (URI) рассматриваемого ресурса. Для пространства имен центров событий область — это полное доменное имя (FQDN), такое как https://<yournamespace>.servicebus.windows.net/.

Правило политики может предоставлять следующие права.

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

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

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

При создании пространства имен центров событий для него автоматически создается правило политики с именем RootManageSharedAccessKey. Эта политика содержит разрешения на управление для всего пространства имен. Рекомендуем обращаться с этим правилом как с учетной записью суперпользователя (администратора) и не использовать его в приложении. Вы можете создать дополнительные правила политики для пространства имен на вкладке Настройка портала с помощью PowerShell или Azure CLI.

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

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

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

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

  • Запрограммируйте автоматическое обновление подписанного URL-адреса клиентами при необходимости. Клиенты должны обновлять SAS задолго до окончания его срока действия, чтобы оставить время для повторных попыток в случае недоступности службы, предоставляющей SAS. Если ваш SAS предназначен для небольшого количества немедленных, краткосрочных операций, которые, как ожидается, будут завершены в течение срока действия, может быть ненужным, так как SAS не ожидается продлением. Однако если имеется клиент, регулярно выполняющий запросы через подпись, то возможность истечения срока действия следует принять во внимание. Рекомендуется сбалансировать требование к кратковременности использования SAS (как указано ранее) с требованием, чтобы клиент запрашивал обновление достаточно рано во избежание проблем, связанных с истечением срока действия SAS до завершения обновления.
  • Внимательно выберите время начала действия SAS. Если задать для времени начала действия SAS значение now, то из-за разницы во времени (разницы в текущем времени на разных компьютерах) могут наблюдаться периодические сбои в течение первых нескольких минут. В общем, устанавливайте время начала действия на 15 минут или более в прошлом времени. Или не задавайте вообще. Так SAS будет немедленно становиться действительным во всех случаях. То же относится и ко времени окончания срока действия. Помните, что для каждого запроса может наблюдаться рассинхронизация по времени до 15 минут в любом направлении.
  • Четко указывайте ресурс, к которому осуществляется доступ. Из соображений безопасности рекомендуется предоставить пользователю минимально необходимый набор прав. Если пользователю требуется только доступ для чтения к отдельной сущности, предоставьте доступ на чтение к этой сущности, а не доступ на чтение, запись и удаление для всех сущностей. Это также позволяет уменьшить ущерб, если SAS скомпрометирован, так как такой SAS предоставляет меньше возможностей злоумышленнику.
  • Не следует всегда использовать SAS. Иногда риски для ваших центров событий, связанные с конкретной операцией, перевешивают преимущества подписанного URL-адреса. Для таких операций создавайте службу среднего уровня, которая записывает данные в ваши центры событий после выполнения аудита, проверки подлинности и проверки на основании бизнес-правил.
  • Всегда используйте HTTPS. Всегда используйте HTTPS для создания подписанного URL-адреса или его распространения. Если SAS передается по протоколу HTTP и перехватывается, посредством атак "злоумышленник в середине" злоумышленник сможет считать SAS и затем использовать его вместо предполагаемого пользователя, что может привести к раскрытию конфиденциальных данных или к повреждению данных злоумышленником.

Заключение

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

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

См. следующие статьи по этой теме: