Поделиться через


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

Центр Интернета вещей использует маркеры подписанного URL-адреса (SAS) для проверки подлинности устройств и служб, чтобы избежать отправки ключей в проводной сети. Маркеры SAS используются для предоставления устройствам и службам ограниченного по времени доступа к определенным функциям в Центре Интернета вещей. Чтобы получить авторизацию для подключения к Центру Интернета вещей, устройства и службы должны отправить маркеры SAS, подписанные с помощью общего ключа доступа или симметричного ключа. Симметричные ключи хранятся с удостоверением устройства в реестре удостоверений.

В этой статье описаны:

  • Различные разрешения, которые можно предоставить клиенту для доступа к Центру Интернета вещей.
  • Маркеры Центра Интернета вещей Azure используются для проверки разрешений.
  • Определение области действия учетных данных для ограничения доступа к определенным ресурсам.
  • Механизмы настраиваемой аутентификации устройства, использующие существующие реестры удостоверений устройств или схемы аутентификации.

Примечание.

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

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

Проверка подлинности и авторизация

Проверка подлинности — это процесс, подтверждающий, что вы являетесь тем, за кого себя выдаете. Проверка подлинности проверяет удостоверение пользователя или устройства на Центр Интернета вещей. Иногда для этого термина используется сокращение AuthN (Authentication). Авторизация — это процесс подтверждения разрешений для прошедшего проверку подлинности пользователя или устройства на Центр Интернета вещей. Он указывает, какие ресурсы и команды можно получить к доступу, а также какие возможности можно сделать с этими ресурсами и командами. Авторизация иногда сокращенно обозначается AuthZ (Authorization).

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

Контроль доступа и разрешений

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

Политики общего доступа на уровне Центра Интернета вещей

Политики общего доступа могут предоставлять любое сочетание разрешений. Политики можно определить в портал Azure программным способом с помощью интерфейсов REST API ресурсов Центр Интернета вещей или с помощью команды azure CLI az iot hub policy. По умолчанию для только что созданного Центра Интернета вещей заданы такие политики:

Политика общего доступа Разрешения
iothubowner Все разрешения
service Разрешения ServiceConnect
device Разрешения DeviceConnect
registryRead Разрешения RegistryRead
registryReadWrite Разрешения RegistryRead и RegistryWrite

Для управления доступом к Центру Интернета вещей можно использовать следующие разрешения:

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

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

    • Доступ к конечным точкам, подключенным к устройству.
    • Отправка сообщений из устройства в облако и получение сообщений из облака в устройство.
    • Выполнение отправки файлов.
    • Получение уведомлений о нужных свойствах двойника устройства и обновление сообщаемых свойств двойника устройства.
  • Разрешение RegistryRead используется внутренними облачными службами и предоставляет следующий доступ:

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

    • Доступ на чтение и запись в реестр удостоверений. Дополнительные сведения см. в разделе о реестре удостоверений.

Учетные данные безопасности на уровне отдельного устройства

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

При регистрации устройства для использования проверки подлинности маркера SAS это устройство получает два симметричного ключа. Симметричные ключи предоставляют разрешение DeviceConnect для связанного удостоверения устройства.

Использование маркеров SAS из служб

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

Например, служба с помощью предварительно созданной политики общего доступа с именем registryRead создаст токен со следующими параметрами:

  • универсальный код ресурса (URI): {IoT hub name}.azure-devices.net;
  • ключ подписывания: один из ключей политики registryRead ;
  • имя политики: registryRead;
  • время окончания срока действия.

Например, следующий код создает маркер SAS в Node.js:

var endpoint = "myhub.azure-devices.net";
var policyName = 'registryRead';
var policyKey = '...';

var token = generateSasToken(endpoint, policyKey, policyName, 60);

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

SharedAccessSignature sr=myhub.azure-devices.net&sig=JdyscqTpXdEJs49elIUCcohw2DlFDR3zfH5KqGJo4r4%3D&se=1456973447&skn=registryRead

Дополнительные примеры см. в разделе "Создание маркеров SAS".

Для служб маркеры SAS предоставляют разрешения только на уровне Центр Интернета вещей. То есть служба, проверяющая подлинность с помощью маркера на основе политики службы , сможет выполнять все операции, предоставленные разрешением ServiceConnect . Эти операции включают в себя получение сообщений с устройства в облако, отправку сообщений из облака на устройство и т. д. Если вы хотите предоставить более детальный доступ к службам, например ограничение службы только на отправку сообщений из облака на устройство, можно использовать идентификатор Microsoft Entra. Дополнительные сведения см. в статье "Проверка подлинности с помощью идентификатора Microsoft Entra".

Использование маркеров SAS с устройств

Существует два способа получения разрешений DeviceConnect для Центра Интернета вещей с маркерами SAS: с помощью симметричного ключа устройства из реестра удостоверений или ключа общего доступа.

Все функциональные возможности, доступные на устройствах, предоставляются с помощью конструктора конечных точек с префиксом /devices/{deviceId}.

Далее указаны конечные точки, доступные с устройства (вне зависимости от протокола).

Конечная точка Функция
{iot hub name}/devices/{deviceId}/messages/events Отправка сообщений с устройства в облако.
{iot hub name}/devices/{deviceId}/messages/devicebound Получение сообщений из облака на устройство.

Использование симметричного ключа в реестре удостоверений

Если для создания маркера используется симметричный ключ удостоверения устройства, то элемент policyName (skn) пропускается.

Например, маркер, созданный для доступа ко всем функциям устройства, должен иметь следующие параметры:

  • универсальный код ресурса (URI): {IoT hub name}.azure-devices.net/devices/{device id};
  • ключ подписывания: любой симметричный ключ для удостоверения {device id} ;
  • имя политики не требуется;
  • время окончания срока действия.

Например, следующий код создает маркер SAS в Node.js:

var endpoint ="myhub.azure-devices.net/devices/device1";
var deviceKey ="...";

var token = generateSasToken(endpoint, deviceKey, null, 60);

Результат, предоставляющий доступ ко всем возможностям устройства device1, будет иметь следующий вид:

SharedAccessSignature sr=myhub.azure-devices.net%2fdevices%2fdevice1&sig=13y8ejUk2z7PLmvtwR5RqlGBOVwiq7rQR3WZ5xZX3N4%3D&se=1456971697

Дополнительные примеры см. в разделе "Создание маркеров SAS".

Использование политики общего доступа для доступа от имени устройства

При создании маркера из политики общего доступа в поле skn укажите имя политики. Эта политика должна предоставить разрешение DeviceConnect.

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

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

Например, служба токенов с помощью предварительно созданной политики общего доступа, называемой устройством , создаст маркер со следующими параметрами:

  • универсальный код ресурса (URI): {IoT hub name}.azure-devices.net/devices/{device id};
  • ключ подписывания: один из ключей политики device ;
  • имя политики: device;
  • время окончания срока действия.

Например, следующий код создает маркер SAS в Node.js:

var endpoint ="myhub.azure-devices.net/devices/device1";
var policyName = 'device';
var policyKey = '...';

var token = generateSasToken(endpoint, policyKey, policyName, 60);

Результат, предоставляющий доступ ко всем возможностям устройства device1, будет иметь следующий вид:

SharedAccessSignature sr=myhub.azure-devices.net%2fdevices%2fdevice1&sig=13y8ejUk2z7PLmvtwR5RqlGBOVwiq7rQR3WZ5xZX3N4%3D&se=1456971697&skn=device

Шлюз протоколов может использовать один и тот же маркер для всех устройств, задав для ресурса URI ресурса значение myhub.azure-devices.net/devices.

Дополнительные примеры см. в разделе "Создание маркеров SAS".

Создание службы маркеров для интеграции существующих устройств

Реестр удостоверений Центр Интернета вещей можно использовать для настройки учетных данных безопасности для каждого устройства или модуля и управления доступом с помощью маркеров. Если в решении Интернета вещей уже есть настраиваемый реестр удостоверений и (или) схема аутентификации, то рекомендуем создать службу маркеров, чтобы интегрировать эту инфраструктуру с Центром Интернета вещей. Таким образом можно использовать и другие функции IoT в решении.

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

Схема, на которую показаны шаги шаблона службы токенов.

Ниже приведены основные этапы для схемы службы маркеров.

  1. Создание политики общего доступа Центра Интернета вещей с разрешением DeviceConnect для вашего центра Интернета вещей. Эту политику можно создать на портале Azure или программным способом. Эту политику служба маркеров будет использовать для подписания создаваемых маркеров.

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

  3. Служба маркеров возвращает маркер. Маркер создается с помощью /devices/{deviceId} или /devices/{deviceId}/modules/{moduleId} resourceURIкак устройства, deviceId прошедшего проверку подлинности, и moduleId в качестве модуля, прошедшего проверку подлинности. Служба маркеров использует политики общего доступа для создания маркера.

  4. Устройство или модуль используют маркер непосредственно для подключения к Центру Интернета вещей.

Примечание.

Для создания маркера в службе маркеров можно использовать класс .NET SharedAccessSignatureBuilder или класс Java IotHubServiceSasToken.

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

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

Сравнение с настраиваемым шлюзом

Вариант со службой маркеров является рекомендованным способом внедрения настраиваемого реестра удостоверений или схемы проверки подлинности с использованием Центра Интернета вещей. Этот вариант рекомендуется, так как Центр Интернета вещей продолжает обрабатывать большую часть трафика решения. Однако, если настраиваемая схема аутентификации настолько тесно переплетена с протоколом, то для обработки всего трафика может потребоваться настраиваемый шлюз. Пример такого сценария — использование протоколов TLS и предварительных ключей (PSKs). Дополнительные сведения см. в разделе Использование устройства IoT Edge в качестве шлюза.

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

Пакеты SDK Для Интернета вещей Azure автоматически создают маркеры, но некоторые сценарии требуют создания и использования маркеров SAS напрямую, включая:

  • Непосредственное использование поверхностей MQTT, AMQP или HTTPS.

  • Реализация шаблона службы токенов, как описано в разделе "Создание службы маркеров".

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

В этом разделе приведены примеры создания маркеров SAS на разных языках кода. Вы также можете создать маркеры SAS с помощью команды расширения CLI az iot hub generate-sas-token или расширения Центр Интернета вещей Azure для Visual Studio Code.

Структура маркера SAS

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

SharedAccessSignature sig={signature-string}&se={expiry}&skn={policyName}&sr={URL-encoded-resourceURI}

Это ожидаемые значения:

значение Описание
{signature} Строка подписи HMAC-SHA256 формата {URL-encoded-resourceURI} + "\n" + expiry. Важно!Ключ шифруется в кодировке base64 и используется для вычислений HMAC-SHA256.
{resourceURI} Начинающийся с имени узла Центра Интернета вещей (без протокола) префикс URI (по сегменту) для конечных точек, доступ к которым можно получить с помощью этого маркера. Маркеры SAS, предоставленные серверным службам, относятся к уровню Центра Интернета вещей; например, myHub.azure-devices.net. Маркеры SAS, предоставляемые устройствам, должны иметь область действия, ограниченную отдельным устройством, например, myHub.azure-devices.net/devices/device1.
{expiry} Строки в формате UTF8, отображающие количество секунд с начала эры 00:00:00 (в формате UTC) 1 января 1970 г.
{URL-encoded-resourceURI} Строчное URL-кодирование строчного URL ресурса
{policyName} Имя политики общего доступа, к которой относится этот маркер. Отсутствует, если маркер относится к учетным данным реестра устройства.

что префикс универсального кода ресурса (URI) вычисляется по сегменту, а не по символу. Например, /a/b это префикс, /a/b/c но не для /a/bc.

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

var generateSasToken = function(resourceUri, signingKey, policyName, expiresInMins) {
    resourceUri = encodeURIComponent(resourceUri);

    // Set expiration in seconds
    var expires = (Date.now() / 1000) + expiresInMins * 60;
    expires = Math.ceil(expires);
    var toSign = resourceUri + '\n' + expires;

    // Use crypto
    var hmac = crypto.createHmac('sha256', Buffer.from(signingKey, 'base64'));
    hmac.update(toSign);
    var base64UriEncoded = encodeURIComponent(hmac.digest('base64'));

    // Construct authorization string
    var token = "SharedAccessSignature sr=" + resourceUri + "&sig="
    + base64UriEncoded + "&se=" + expires;
    if (policyName) token += "&skn="+policyName;
    return token;
};

Особенности протокола

Каждый поддерживаемый протокол, например MQTT, AMQP и HTTPS, передает маркеры разными способами.

При использовании протокола MQTT пакет CONNECT содержит код deviceId как значение ClientId, {iothubhostname}/{deviceId} — в поле "Имя пользователя", а маркер SAS — в поле "Пароль". {iothubhostname} должен быть полным CName центра Интернета вещей (например, myhub.azure-devices.net).

При использовании AMQP Центр Интернета вещей поддерживает SASL PLAIN и защиты AMQP на основе утверждений.

Стандарт защиты AMQP на основе утверждений определяет, как следует передавать эти маркеры.

Для SASL PLAIN имя пользователя может быть следующим:

  • {policyName}@sas.root.{iothubName} — при использовании маркеров уровня Центра Интернета вещей;
  • {deviceId}@sas.{iothubname} — при использовании маркеров уровня устройства.

В обоих случаях поле пароля содержит маркер, как описано в структуре маркера SAS.

Протокол HTTPS реализует аутентификацию путем включения допустимого маркера в заголовок запроса авторизации.

Например, имя пользователя (значение DeviceId следует вводить с учетом регистра): iothubname.azure-devices.net/DeviceId

Пароль (маркер SAS можно создать с помощью команды расширения CLI az iot hub generate-sas-token или расширения Центр Интернета вещей Azure для Visual Studio Code):

SharedAccessSignature sr=iothubname.azure-devices.net%2fdevices%2fDeviceId&sig=kPszxZZZZZZZZZZZZZZZZZAhLT%2bV7o%3d&se=1487709501

Примечание.

Пакеты SDK для Azure IoT автоматически создают маркеры при подключении к службе. В некоторых случаях пакеты SDK для Azure IoT поддерживают не все протоколы или не все методы проверки подлинности.

Специальные рекомендации для SASL PLAIN

При использовании SASL PLAIN с протоколом AMQP клиент, подключающийся к Центру Интернета вещей, может использовать по одному маркеру для каждого TCP-подключения. Когда срок действия маркера истекает, TCP-подключение к службе прерывается и выполняется попытка повторного подключения. Хотя это поведение и не является проблематичным для внутреннего приложения, оно может навредить приложению для устройства по следующим причинам:

  • Шлюзы обычно подключаются от имени многих устройств. Если используется SASL PLAIN, шлюзам нужно создать отдельное TCP-подключение для каждого устройства, подключающегося к Центру Интернета вещей. Этот сценарий значительно повышает потребление электроэнергии и сетевых ресурсов и увеличивает задержку подключения устройства.

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

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

Теперь, когда вы узнали, как управлять доступом к Центру Интернета вещей, вас могут заинтересовать следующие статьи в руководстве разработчика для Центра Интернета вещей: