Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Подпись для общего доступа (SAS) предоставляет вам способ предоставить ограниченный доступ к ресурсам в вашем пространстве имен Event Hubs. SAS защищает доступ к ресурсам центров событий на основе правил авторизации. Эти правила настраиваются либо в пространстве имен, либо в концентраторе событий. В этой статье приводится обзор модели SAS и рассматриваются рекомендации по использованию SAS.
Примечание.
В этой статье описывается авторизация доступа к ресурсам Центров событий с помощью SAS. Сведения о проверке подлинности ресурсов Центров событий с помощью SAS см. в статье "Проверка подлинности с помощью SAS".
Что такое общие ключи доступа?
Подпись общей доступа (SAS) предоставляет делегированный доступ к ресурсам центров событий на основе правил авторизации. Право авторизации имеет имя, связано с определенными правами и содержит пару криптографических ключей. Вы можете использовать имя и ключ правила в клиентах центров событий или в собственном коде, чтобы создать токены SAS. Затем клиент может передать токен в центры событий для подтверждения авторизации запрашиваемой операции.
SAS — механизм авторизации на основе утверждений, использующий простые токены. При использовании SAS ключи никогда не передаются по проводу. Ключи криптографически подписывают сведения, которые впоследствии будут проверены службой. SAS можно использовать так же, как и схему с именем пользователя и паролем, где клиент имеет немедленный доступ к имени правила авторизации и соответствующему ключу. Кроме того, SAS можно использовать подобно федеративной модели безопасности, где клиент получает подписанный токен доступа с ограниченным временем действия из службы токенов безопасности, не используя ключа для подписи.
Примечание.
Центры событий Azure также поддерживает авторизацию ресурсов Центров событий с помощью идентификатора Microsoft Entra. Авторизация пользователей или приложений с помощью токена OAuth 2.0, возвращаемого идентификатором Microsoft Entra, обеспечивает более высокую безопасность и удобство использования по сравнению с общими подписями доступа (SAS). С Microsoft Entra ID нет необходимости хранить токены в коде и подвергать себя потенциальным уязвимостям безопасности.
Корпорация Майкрософт рекомендует использовать Microsoft Entra ID с приложениями Azure Event Hubs, когда это возможно. Дополнительные сведения см. в статье "Авторизация доступа к ресурсу Центры событий Azure с помощью идентификатора Microsoft Entra".
Внимание
Токены SAS (вспомогательные общие подписи) критически важны для защиты ваших ресурсов. Обеспечивая детализацию, SAS предоставляет клиентам доступ к вашим ресурсам центров событий. Не следует предоставлять к ним общий доступ. Если общий доступ необходим в целях устранения неполадок, используйте сокращенную версию файлов журнала или удалите токены SAS (если есть) из файлов журнала, а также убедитесь, что снимки экрана не содержат данные о SAS.
Политики авторизации общего доступа
Каждое пространство имен Центров событий и каждая сущность Центров событий (концентратор событий или раздел Kafka) содержит политику авторизации общего доступа, состоящей из правил. Политика на уровне пространства имен применяется ко всем сущностям в пространстве имен независимо от настройки их политики.
Для каждого правила политики авторизации необходимо выбрать три фрагмента данных: имя, область и права. Имя — это уникальное название в данной области. Область — это универсальный код (URI) рассматриваемого ресурса. Для пространства имен центров событий область — это полное доменное имя (FQDN), например, https://<yournamespace>.servicebus.windows.net/
.
Предоставленные правилами политики права могут являться комбинацией следующих:
- Отправка предоставляет право отправки сообщений сущности.
- Прослушивание — дает право прослушивать или получать сообщения от сущности
- Управление — дает право управлять топологией пространства имен, включая создание и удаление сущностей. Право на управление включает в себя права на отправку и прослушивание.
Политика пространства имен или сущности может содержать до 12 правил авторизации общего доступа, обеспечивая место для трех наборов правил, каждый из которых включает основные права, а также их сочетание для отправки и приема данных. Это ограничение подчеркивает, что хранилище политики SAS не предназначено быть хранилищем учетных записей пользователя или службы. Если для приложения необходимо предоставить доступ к ресурсам центров событий на основе удостоверений пользователя или службы, в нем необходимо реализовать службу токенов безопасности, которая выдает токены SAS после проверки подлинности и проверки доступа.
Правилу авторизации назначаются первичный и вторичный ключи. Это криптографически стойкие ключи. Не теряйте их и не допускайте их утечки. Они всегда доступны на портале Azure. Вы можете использовать любой из созданных ключей и создавать их повторно в любое время. Если вы повторно создадите или измените ключ в политике безопасности, все ранее выданные токены на его основе сразу становятся недействительными. Однако текущие подключения, созданные на основе таких маркеров, продолжают работать до истечения срока действия маркера.
При создании пространства имен центров событий для него автоматически создается правило политики с именем RootManageSharedAccessKey. Эта политика содержит разрешения на управление для всего пространства имен. Рекомендуем обращаться с этим правилом как с учетной записью суперпользователя (администратора) и не использовать его в приложении. Вы можете создать дополнительные правила политики для пространства имен на вкладке Настройка портала с помощью PowerShell или Azure CLI.
Рекомендации по использованию SAS
При использовании подписей общего доступа в приложениях необходимо иметь в виду две потенциальные проблемы:
- В случае утечки учетных данных SAS, кто угодно сможет ими воспользоваться, что может привести к компрометации ваших ресурсов в центрах событий.
- Если срок действия SAS, предоставленный клиентскому приложению, истекает, и приложению не удается получить новый SAS из службы, функциональные возможности приложения могут быть затруднены.
Следующие рекомендации по использованию подписанных URL-адресов помогут нейтрализовать эти риски:
- Обеспечьте, чтобы клиенты автоматически обновляли SAS при необходимости. Клиенты должны обновлять SAS задолго до окончания его срока действия, чтобы оставить время для повторных попыток в случае недоступности службы, предоставляющей SAS. Если ваш SAS предназначен для небольшого количества немедленных краткосрочных операций, которые должны быть завершены в течение срока действия SAS, он может оказаться ненужным, так как не предполагается его продлевать. Однако если имеется клиент, регулярно выполняющий запросы через подпись, то возможность истечения срока действия следует принять во внимание. Ключевое внимание заключается в том, чтобы сбалансировать потребность SAS в кратковременном режиме (как было указано ранее) с необходимостью убедиться, что клиент запрашивает продление достаточно рано (чтобы избежать прерывания из-за истечения срока действия SAS до успешного продления).
- Будьте осторожны со временем начала SAS: если задать время начала ДЛЯ SAS сейчас, то из-за отклонений часов (различия в текущем времени в соответствии с различными компьютерами), ошибки могут наблюдаться периодически в течение первых нескольких минут. В общем, устанавливайте время начала действия на 15 минут или более в прошлом времени. Или не устанавливайте его вообще, что делает его допустимым немедленно во всех случаях. То же относится и ко времени окончания срока действия. Помните, что вы можете наблюдать до 15 минут рассинхронизацию времени в обе стороны в рамках любого запроса.
- Четко указывайте ресурс, к которому осуществляется доступ. Из соображений безопасности рекомендуется предоставить пользователю минимально необходимый набор прав. Если пользователю требуется только доступ для чтения к отдельной сущности, предоставьте доступ на чтение к этой сущности, а не доступ на чтение, запись и удаление для всех сущностей. Это также позволяет уменьшить ущерб, если SAS скомпрометирован, так как такой SAS предоставляет меньше возможностей злоумышленнику.
- Не всегда используйте SAS. Иногда риски, связанные с конкретной операцией с вашими центрами событий, перевешивают преимущества использования механизма SAS. Для таких операций создайте службу среднего уровня, которая передаёт данные в ваши центры событий, сначала проверив бизнес-правила, аутентификацию и проведя аудит.
- Всегда используйте ПРОТОКОЛ HTTPS: всегда используйте ПРОТОКОЛ HTTPS для создания или распространения SAS. Если SAS передается по протоколу HTTP и перехватывается, злоумышленник, осуществляющий атаку типа «человек в середине», может прочитать SAS и использовать его так же, как и предполагаемый пользователь, что может привести к компрометации конфиденциальных данных или повреждению данных.
Заключение
Подписанные ключи доступа можно использовать для предоставления клиентам ограниченных разрешений к ресурсам Event Hubs. Они являются жизненно важной частью модели безопасности для любого приложения, использующего Azure Event Hubs. Если следовать лучшим практикам, приведенным в этой статье, вы можете использовать SAS, чтобы обеспечить большую гибкость доступа к вашим ресурсам, не ставя под угрозу безопасность вашего приложения.
Связанный контент
См. следующие статьи по этой теме:
- Проверка подлинности запросов к Центрам событий Azure с помощью подписей общего доступа
- Проверка подлинности запросов на Центры событий Azure из приложения с помощью идентификатора Microsoft Entra
- Аутентификация управляемого удостоверения с помощью Microsoft Entra ID для доступа к ресурсам Event Hubs