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

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

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

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

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

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

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

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

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

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

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

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

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

• Разрешение 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 предоставляют разрешения только на уровне IoT Hub. То есть служба, аутентифицирующая с помощью маркера на основе политики службы может выполнять все операции, предоставленные разрешением ServiceConnect. Эти операции включают в себя получение сообщений с устройства в облако, отправку сообщений из облака на устройство и т. д. Если вы хотите предоставить более детальный доступ к службам, например ограничение службы только на отправку сообщений из облака на устройство, можно использовать идентификатор Microsoft Entra. Дополнительные сведения см. в разделе "Управление доступом к Центру Интернета вещей" с помощью идентификатора Microsoft Entra.

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

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

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

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

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

Если для создания токена используется симметричный ключ удостоверения устройства, то элемент 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.

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

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

Так как политика общего доступа может предоставить доступ к подключению как к любому устройству, важно использовать правильный URI ресурсов при создании маркеров SAS. Этот параметр имеет особое значение для служб маркеров, которые должны определять область действия маркера для конкретного устройства с помощью 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. Устройство или модуль используют маркер непосредственно для подключения к Центру Интернета вещей.

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

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

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

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

Генерация токенов SAS

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

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

• Реализация паттерна службы токенов, как описано в разделе "Создание службы токенов" для интеграции существующих устройств.

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

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

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

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

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

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

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

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;
};

from base64 import b64encode, b64decode
from hashlib import sha256
from time import time
from urllib import parse
from hmac import HMAC

def generate_sas_token(uri, key, policy_name, expiry=3600):
    ttl = time() + expiry
    sign_key = "%s\n%d" % ((parse.quote_plus(uri)), int(ttl))
    print(sign_key)
    signature = b64encode(HMAC(b64decode(key), sign_key.encode('utf-8'), sha256).digest())

    rawtoken = {
        'sr' :  uri,
        'sig': signature,
        'se' : str(int(ttl))
    }

    if policy_name is not None:
        rawtoken['skn'] = policy_name

    return 'SharedAccessSignature ' + parse.urlencode(rawtoken)

using System;
using System.Globalization;
using System.Net;
using System.Net.Http;
using System.Security.Cryptography;
using System.Text;

public static string GenerateSasToken(string resourceUri, string key, string policyName, int expiryInSeconds = 3600)
{
    TimeSpan fromEpochStart = DateTime.UtcNow - new DateTime(1970, 1, 1);
    string expiry = Convert.ToString((int)fromEpochStart.TotalSeconds + expiryInSeconds);

    string stringToSign = WebUtility.UrlEncode(resourceUri) + "\n" + expiry;

    HMACSHA256 hmac = new HMACSHA256(Convert.FromBase64String(key));
    string signature = Convert.ToBase64String(hmac.ComputeHash(Encoding.UTF8.GetBytes(stringToSign)));

    string token = String.Format(CultureInfo.InvariantCulture, "SharedAccessSignature sr={0}&sig={1}&se={2}", WebUtility.UrlEncode(resourceUri), WebUtility.UrlEncode(signature), expiry);

    if (!String.IsNullOrEmpty(policyName))
    {
        token += "&skn=" + policyName;
    }

    return token;
}

public static String generateSasToken(String resourceUri, String key) throws Exception {
    // Token will expire in one hour
    var expiry = Instant.now().getEpochSecond() + 3600;

    String stringToSign = URLEncoder.encode(resourceUri, StandardCharsets.UTF_8) + "\n" + expiry;
    byte[] decodedKey = Base64.getDecoder().decode(key);

    Mac sha256HMAC = Mac.getInstance("HmacSHA256");
    SecretKeySpec secretKey = new SecretKeySpec(decodedKey, "HmacSHA256");
    sha256HMAC.init(secretKey);
    Base64.Encoder encoder = Base64.getEncoder();

    String signature = new String(encoder.encode(
        sha256HMAC.doFinal(stringToSign.getBytes(StandardCharsets.UTF_8))), StandardCharsets.UTF_8);

    String token = "SharedAccessSignature sr=" + URLEncoder.encode(resourceUri, StandardCharsets.UTF_8)
            + "&sig=" + URLEncoder.encode(signature, StandardCharsets.UTF_8.name()) + "&se=" + expiry;
            
    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} — при использовании токенов уровня IoT Hub.
• {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

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

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

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

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

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

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

• Понимание и использование цифровых двойников устройств в IoT Hub
• Поймите и вызовите прямые методы из Центра Интернета вещей
• Планирование заданий на нескольких устройствах