Управление доступом к служебной шине с помощью подписанных URL-адресов

Статья
11/28/2023

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

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

Примечание.

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

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

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

Общие сведения о SAS

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

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

Примечание.

Эти ключи являются строками обычного текста с помощью представления Base 64 и не должны быть декодированы до их использования.

Маркер подписанного URL-адреса содержит имя выбранной политики авторизации, универсальный код ресурса (URI), к которому запрашивается доступ, срок действия и криптографическую подпись HMAC-SHA256, вычисленную на основе этих полей с помощью первичного или вторичного криптографического ключа выбранного правила авторизации.

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

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

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

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

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

Право "Управление" включает права отправки и прослушивания.

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

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

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

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

Если вы знаете или подозреваете, что ключ скомпрометирован и необходимо отозвать оба ключа, можно повторно создать ключи PrimaryKey и SecondaryKey в правиле SharedAccessAuthorizationRule, заменив ими старые. В результате этой процедуры все маркеры, подписанные старыми ключами, станут недействительными.

Настройка проверки подлинности подписанного URL-адреса

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

Diagram that shows an example namespace with a few authorization rules.

На этом рисунке правила авторизации manageRuleNS, sendRuleNS и listenRuleNS применяются к очереди Q1 и разделу T1, правила listenRuleQ и sendRuleQ — только к очереди Q1 и правило sendRuleT — только к разделу T1.

Создание маркера подписанного URL-адреса

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

SharedAccessSignature sig=<signature-string>&se=<expiry>&skn=<keyName>&sr=<URL-encoded-resourceURI>

se — срок действия маркера. Количество секунд с начала эпохи UNIX (00:00:00 UTC 1 января 1970 года) до истечения срока действия маркера.
skn — имя правила авторизации.
sr — URI (в кодировке URL) для ресурса, к которому осуществляется доступ.
sig — подпись HMACSHA256 в кодировке URL. Вычисление хэша напоминает следующий псевдокод и возвращает значение base64 необработанных двоичных выходных данных.
```
urlencode(base64(hmacsha256(urlencode('https://<yournamespace>.servicebus.windows.net/') + "\n" + '<expiry instant>', '<signing key>')))
```

Внимание

Примеры создания маркера SAS с использованием разных языков программирования см. в разделе Создание маркера SAS.

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

URI ресурса — это полный URI ресурса служебной шины, к которому запрашивается доступ. Например, http://<namespace>.servicebus.windows.net/<entityPath> или sb://<namespace>.servicebus.windows.net/<entityPath>. Вся строка будет выглядеть так: http://contoso.servicebus.windows.net/contosoTopics/T1/Subscriptions/S3.

URI должен быть закодирован с помощью знака процента.

Правило авторизации общего доступа, используемое для подписи, необходимо настроить для сущности, указанной данным URI или одной из ее иерархических родительских сущностей. Например, в предыдущем примере это — http://contoso.servicebus.windows.net/contosoTopics/T1 или http://contoso.servicebus.windows.net.

Маркер SAS действителен для всех ресурсов с префиксом <resourceURI>, используемым в signature-string.

Повторное создание ключей

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

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

Чтобы повторно создать первичный и вторичный ключи на портале Azure:

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

Если вы используете Azure PowerShell, используйте New-AzServiceBusKey командлет для повторного создания первичных и вторичных ключей для пространства имен служебная шина. Можно также указать значения для создаваемых первичных и вторичных ключей с помощью параметра -KeyValue.

Если вы используете Azure CLI, используйте az servicebus namespace authorization-rule keys renew команду для повторного создания первичных и вторичных ключей для пространства имен служебная шина. Можно также указать значения для создаваемых первичных и вторичных ключей с помощью параметра --key-value.

Проверка подлинности подписанного URL-адреса с помощью служебной шины

Описанные ниже сценарии включают настройку правил авторизации, создание маркеров SAS и авторизацию клиента.

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

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

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

Использование авторизации подписанного URL-адреса

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

Строки подключения могут включать имя правила (SharedAccessKeyName), ключ правила (SharedAccessKey) или ранее выданный маркер (SharedAccessSignature). Если они присутствуют в строке подключения, переданной в конструктор или фабричный метод, принимающий строку подключения, поставщик маркеров SAS создается и заполняется автоматически.

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

Использование подписанного URL-адреса (на уровне HTTP)

Теперь, когда вы знаете, как создавать SAS для всех сущностей в Служебной шине, можно выполнить HTTP-запрос POST:

POST https://<yournamespace>.servicebus.windows.net/<yourentity>/messages
Content-Type: application/json
Authorization: SharedAccessSignature sr=https%3A%2F%2F<yournamespace>.servicebus.windows.net%2F<yourentity>&sig=<yoursignature from code above>&se=1438205742&skn=KeyName
ContentType: application/atom+xml;type=entry;charset=utf-8

Этот способ работает всегда. SAS можно создать для очереди, раздела или подписки.

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

Использование подписанного URL-адреса (на уровне AMQP)

В предыдущем разделе вы увидели, как использовать маркер SAS с помощью запроса HTTP POST для отправки данных в служебную шину. Как известно, доступ к служебной шине можно получить с помощью расширенного протокола управления очередью сообщений (AMQP). Этот протокол является предпочтительным, так как обладает хорошей производительностью во многих сценариях. Использование маркеров SAS с AMQP описывается в документе Безопасность AMQP на основе утверждений, версия 1.0. Этот документ находится в постоянной доработке с 2013 года, но сейчас поддерживается в Azure.

Перед началом отправки данных служебной шине издатель должен отправить маркер SAS внутри сообщения AMQP на узел AMQP с именем $cbs (этот узел отображается как "специальная" очередь, используемая службой для получения и проверки всех маркеров SAS). Издатель должен указать поле ReplyTo в сообщении AMQP. Это узел, на который служба отправит издателю ответ с результатами проверки маркера (простая схема "запрос — ответ" между издателем и службой). Этот узел ответа создается "на лету", в соответствии с "динамическим созданием удаленного узла", описанным в спецификации протокола AMQP 1.0. После проверки правильности маркера SAS издатель может продолжить выполнение и отправить данные в службу.

Ниже показано, как отправить маркер SAS с помощью протокола AMQP и библиотеки AMQP .NET Lite. Это полезно, если вы не можете использовать официальный пакет SDK служебная шина (например, в WinRT, .NET Compact Framework, .NET Micro Framework и Mono), разрабатываемый в C#. Эта библиотека поможет разобраться в том, как работает защита на основе утверждений на уровне AMQP. Вы уже видели, как защита работает на уровне HTTP (с отправкой HTTP-запроса POST и маркера SAS в заголовке Authorization). Если вам не нужны такие глубокие знания об AMQP, вы можете использовать официальный пакет SDK служебная шина на любом из поддерживаемых языков, таких как .NET, JavaScript, JavaScript, Python и Go, которые будут делать это для вас.

C#

/// <summary>
/// Send claim-based security (CBS) token
/// </summary>
/// <param name="shareAccessSignature">Shared access signature (token) to send</param>
private bool PutCbsToken(Connection connection, string sasToken)
{
    bool result = true;
    Session session = new Session(connection);

    string cbsClientAddress = "cbs-client-reply-to";
    var cbsSender = new SenderLink(session, "cbs-sender", "$cbs");
    var cbsReceiver = new ReceiverLink(session, cbsClientAddress, "$cbs");

    // construct the put-token message
    var request = new Message(sasToken);
    request.Properties = new Properties();
    request.Properties.MessageId = Guid.NewGuid().ToString();
    request.Properties.ReplyTo = cbsClientAddress;
    request.ApplicationProperties = new ApplicationProperties();
    request.ApplicationProperties["operation"] = "put-token";
    request.ApplicationProperties["type"] = "servicebus.windows.net:sastoken";
    request.ApplicationProperties["name"] = Fx.Format("amqp://{0}/{1}", sbNamespace, entity);
    cbsSender.Send(request);

    // receive the response
    var response = cbsReceiver.Receive();
    if (response == null || response.Properties == null || response.ApplicationProperties == null)
    {
        result = false;
    }
    else
    {
        int statusCode = (int)response.ApplicationProperties["status-code"];
        if (statusCode != (int)HttpStatusCode.Accepted && statusCode != (int)HttpStatusCode.OK)
        {
            result = false;
        }
    }

    // the sender/receiver might be kept open for refreshing tokens
    cbsSender.Close();
    cbsReceiver.Close();
    session.Close();

    return result;
}

Метод PutCbsToken() получает подключение (экземпляр класса AMQP Connection, предоставляемый библиотекой AMQP .NET Lite). Это подключение представляет подключение TCP к службе и параметр sasToken (отправляемый маркер SAS).

Примечание.

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

Затем издатель создает две ссылки AMQP для отправки маркера SAS и получения ответа (результата проверки маркера) от службы.

Сообщение AMQP содержит набор свойств и больше информации по сравнению с простым сообщением. Маркер SAS составляет тело сообщения (с помощью конструктора). Свойству ReplyTo присваивается имя узла для получения результата проверки по ссылке получателя (при желании это имя можно изменить, и оно будет создано службой динамически). Последние три свойства приложения или пользовательских свойства используются службой, чтобы понять, какую операцию ей нужно выполнить. Как описано в черновой спецификации CBS, это должно быть имя операции (put-token), тип маркера (в этом случае servicebus.windows.net:sastoken) и, наконец, "имя" аудитории, к которой относится маркер (вся сущность).

После отправки маркера SAS по ссылке отправителя издателю нужно будет прочитать ответ по ссылке получателя. Ответ представляет собой простое сообщение AMQP со свойством приложения status-code , которое может содержать те же значения, что и код состояния HTTP.

Права, необходимые для операций служебной шины

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

Операция	Требуемое утверждение	Область утверждения
Пространство имен
Настройка правила авторизации для пространства имен	Управление	Любой адрес пространства имен
Регистр служб
Перечисление частных политик	Управление	Любой адрес пространства имен
Начало прослушивания в пространстве имен	Прослушивание	Любой адрес пространства имен
Отправка сообщений в прослушиватель в пространстве имен	Отправить	Любой адрес пространства имен
Очередь
Создать очередь	Управление	Любой адрес пространства имен
Удаление очереди	Управление	Любой допустимый адрес очереди
Перечисление очередей	Управление	/$Resources/Queues
Получение описания очереди	Управление	Любой допустимый адрес очереди
Настройка правила авторизации для очереди	Управление	Любой допустимый адрес очереди
Отправка в очередь	Отправить	Любой допустимый адрес очереди
Получение сообщений из очереди	Прослушивание	Любой допустимый адрес очереди
Прерывание или завершение обмена сообщениями после получения сообщения в режиме чтения с блокировкой	Прослушивание	Любой допустимый адрес очереди
Откладывание сообщения для последующего получения	Прослушивание	Любой допустимый адрес очереди
Назначение сообщению статуса недоставленного	Прослушивание	Любой допустимый адрес очереди
Получение состояния, связанного с сеансом очереди сообщений	Прослушивание	Любой допустимый адрес очереди
Назначение состояния, связанного с сеансом очереди сообщений	Прослушивание	Любой допустимый адрес очереди
Планирование доставки сообщения через некоторое время	Прослушивание	Любой допустимый адрес очереди
Раздел
Создание темы	Управление	Любой адрес пространства имен
Удаление раздела	Управление	Любой допустимый адрес раздела
Перечисление разделов	Управление	/$Resources/Topics
Получение описания раздела	Управление	Любой допустимый адрес раздела
Настройка правила авторизации для раздела	Управление	Любой допустимый адрес раздела
Отправка в раздел	Отправить	Любой допустимый адрес раздела
Подписка
Создание подписки	Управление	Любой адрес пространства имен
Удаление подписки	Управление	../myTopic/Subscriptions/mySubscription
Перечисление подписок	Управление	../myTopic/Subscriptions
Получение описания подписки	Управление	../myTopic/Subscriptions/mySubscription
Прерывание или завершение обмена сообщениями после получения сообщения в режиме чтения с блокировкой	Прослушивание	../myTopic/Subscriptions/mySubscription
Откладывание сообщения для последующего получения	Прослушивание	../myTopic/Subscriptions/mySubscription
Назначение сообщению статуса недоставленного	Прослушивание	../myTopic/Subscriptions/mySubscription
Получение состояния, связанного с сеансом раздела	Прослушивание	../myTopic/Subscriptions/mySubscription
Назначение состояния, связанного с сеансом раздела	Прослушивание	../myTopic/Subscriptions/mySubscription
Правила
Создание правила	Прослушивание	../myTopic/Subscriptions/mySubscription
Удалить правило	Прослушивание	../myTopic/Subscriptions/mySubscription
Перечисление правил	Управление или прослушивание	../myTopic/Subscriptions/mySubscription/Rules

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

Дополнительную информацию об обмене сообщениями через служебную шину см. в следующих разделах.

Управление доступом к служебной шине с помощью подписанных URL-адресов

Общие сведения о SAS

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

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

Настройка проверки подлинности подписанного URL-адреса

Создание маркера подписанного URL-адреса

Повторное создание ключей

Проверка подлинности подписанного URL-адреса с помощью служебной шины

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

Использование авторизации подписанного URL-адреса

Использование подписанного URL-адреса (на уровне HTTP)

Использование подписанного URL-адреса (на уровне AMQP)

C#

Права, необходимые для операций служебной шины

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

Дополнительные ресурсы