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

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

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

• Проверка подлинности и авторизация приложения с помощью идентификатора Microsoft Entra для доступа к Служебная шина Azure сущностям.
• Проверка подлинности управляемого удостоверения с помощью идентификатора Microsoft Entra для доступа к ресурсам Служебная шина Azure

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

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

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

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

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

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

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

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

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

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

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

На этом рисунке правила авторизации 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>')))
  

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

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:

1. Перейдите к пространству имен служебной шины на портале Azure.

2. Выберите Политики общего доступа в меню слева.

3. Выберите политику в списке. В следующем примере используется RootManageSharedAccessKey.

4. Чтобы повторно создать первичный ключ, на странице "Политика SAS: RootManageSharedAccessKey" выберите "Повторно создать первичный ключ " на панели команд.

   

5. Чтобы повторно создать вторичный ключ, на странице "Политика 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).

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

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

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

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

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

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

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

• Очереди, разделы и подписки служебной шины
• Начало работы с очередями служебной шины
• Начало работы с разделами служебной шины