Управление доступом для клиентов MQTT

Управление доступом позволяет управлять авторизацией клиентов для публикации или подписки на разделы с помощью модели управления доступом на основе ролей. Учитывая огромный масштаб сред Интернета вещей, назначение разрешений для каждого клиента для каждого топика невероятно трудоемко. Функция брокера MQTT службы Azure Event Grid решает задачу масштабирования путем группировки клиентов и тем в группы клиентов и пространства тем.

Основными компонентами модели управления доступом являются:

Клиент представляет устройство или приложение, которое должно публиковать и/или подписываться на разделы MQTT.

Группа клиентов — это набор клиентов, которым требуется тот же доступ к публикации и /или подписке на тот же набор разделов MQTT. Клиентская группа представляет принципала в модели RBAC.

Пространство тем представляет несколько тем с помощью набора шаблонов тем. Шаблоны разделов — это расширение фильтров MQTT, поддерживающих переменные, а также подстановочные знаки MQTT. Каждое пространство разделов представляет темы, которые должны использовать один и тот же набор клиентов для обмена данными. Тематическое пространство отображает ресурс в модели RBAC.

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

Примеры:

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

Пример 1.

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

Конфигурация

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

Пример 2.

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

Конфигурация:

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

Гранулированный контроль доступа

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

Несмотря на то, что группа клиентов может иметь доступ к определенному пространству тем со всеми шаблонами разделов, переменные в шаблонах тем позволяют управлять авторизацией каждого клиента в этой группе клиентов для публикации или подписки на свой собственный раздел. Например, если группа клиентов "машины" включает два клиента: “machine1” и “machine2”. С помощью переменных можно разрешить устройству "machine1" публиковать свои телеметрические данные только на тему MQTT "machines/machine1/telemetry", а устройству "machine2" разрешить публиковать сообщения на тему MQTT "machines/machine2/telemetry".

Переменные представляют имена проверки подлинности клиента или атрибуты клиента. При взаимодействии с брокером MQTT каждый клиент заменит переменную в разделе MQTT замененным значением. Например, переменная ${client.authenticationName} будет заменена именем проверки подлинности каждого клиента: machine1, machine2 и т. д. Брокер MQTT будет разрешать доступ только к клиентам, имеющим заменяемое значение, соответствующее имени проверки подлинности или значению указанного атрибута.

Например, рассмотрим следующую конфигурацию:

• Группа клиентов: компьютеры
• Тематика: MachinesTelemetry
  • Шаблон раздела "machines/${client.authenticationName}/telemetry".
• Привязка разрешений: группа клиентов: машины; пространство тем: телеметрия машин; доступ: издатель

В этой конфигурации только клиент с именем проверки подлинности клиента "machine1" может публиковаться в разделе "компьютеры/компьютер1/телеметрия", и только компьютер с именем проверки подлинности клиента "machine 2" может публиковаться в разделе "machine/machine2/telemetry" и т. д. Соответственно, machine2 не может публиковать ложные сведения от имени компьютера1, несмотря на то, что он имеет доступ к одному и тому же пространству тем, и наоборот.

Дальнейшие действия:

Дополнительные сведения об авторизации и проверке подлинности:

• Проверка подлинности клиента
• Клиенты
• Группы клиентов
• Тематические пространства