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

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

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

Предпочтительный метод авторизации

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

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

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

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

Обзор SAS

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

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

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

Маркер SAS содержит следующее:

• Имя выбранной политики авторизации.
• URI ресурса, к который требуется получить доступ.
• Момент истечения срока действия.
• Криптографическая подпись HMAC-SHA256, вычисленная для этих полей с использованием либо первичного, либо вторичного криптографического ключа по выбранному правилу авторизации.

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

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

Для каждого правила политики авторизации вы решите использовать три фрагмента информации:

• Имя. Уникальное имя в области.

• Область применения. URI ресурса, о котором идет речь. Для пространства имен служебной шины область — это полное пространство имен, например https://<yournamespace>.servicebus.windows.net/.

• Права. Права, которые предоставляет правило политики. Они могут быть комбинацией:

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

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

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

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

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

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

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

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

Рекомендации по использованию общих ключей доступа

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

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

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

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

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

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

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

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

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

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

• Всегда используйте ПРОТОКОЛ HTTPS для создания или распространения SAS. Если SAS передается по протоколу HTTP и перехватывается, злоумышленник, выполняющий атаку типа "человек посередине", может считать SAS, а затем использовать его так же, как и предполагаемый пользователь. Эта ситуация может скомпрометировать конфиденциальные данные или позволить злоумышленнику повредить данные.

Настройка проверки подлинности SAS

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

В следующем примере manageRuleNSsendRuleNSlistenRuleNS правила авторизации применяются как к очереди Q1, так и к разделу T1. listenRuleQ и sendRuleQ правила применяются только к очереди Q1. Правило sendRuleT применяется только к разделу T1.

Создание маркера SAS

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

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

• se: момент истечения срока действия токена. Целое число отражает количество секунд, прошедших с 00:00:00 UTC эпохи UNIX (1 января 1970 г.) до момента истечения срока действия маркера.

• skn: имя правила авторизации.

• sr: URI ресурса в кодировке URL.

• sig: HMAC-SHA256 сигнатура в формате кодирования 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.

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

Восстановление ключей

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

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

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

Azure portal

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

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

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

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

   

5. Чтобы повторно создать вторичный ключ, на панели "Политика SAS: RootManageSharedAccessKey" выберите многоточие (...) на панели команд, а затем нажмите кнопку "Повторно создать дополнительный ключ".

   

Azure PowerShell

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

Azure CLI

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

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

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

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

Доступ к правилам SAS для объекта

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

Использование авторизации SAS

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

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

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

Используйте общую подпись доступа на уровне HTTP

Теперь, когда вы знаете, как создать маркер разделенного доступа для любых сущностей в служебная шина, вы готовы выполнить 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-адреса на уровне AMQP

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

Прежде чем издатель начнет отправлять данные в служебную шину, он должен отправить маркер 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, Java, JavaScript, Python и Go. Пакет SDK сделает это для вас.

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, как указано библиотекой AMQP .NET Lite). Этот экземпляр представляет TCP-подключение к службе и параметр sasToken, являющийся отправляемым маркером SAS.

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

Сообщение AMQP содержит набор свойств и больше сведений, чем простое сообщение:

• Токен SAS является телом сообщения (используя его конструктор).
• Свойство ReplyTo устанавливается на имя узла для приема результата проверки на сайте получателя. Его имя можно изменить, если требуется, и служба создает ее динамически.
• Служба использует последние три свойства приложения или пользовательских свойств, чтобы указать, какая операция должна выполняться. Как описано в черновой спецификации безопасности AMQP Claim-Based Security, они должны быть:
  • Имя операции (put-token)
  • Тип токена (в данном случае servicebus.windows.net:sastoken)
  • Имя аудитории, к которой применяется токен (вся аудитория)

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

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

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

Связанный контент

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

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