Contrôler l’accès au hub IoT avec des signatures d’accès partagé

IoT Hub utilise des jetons de signature d’accès partagé (SAP) pour authentifier les appareils et les services afin d’éviter d’envoyer des clés sur le câble. Vous utilisez des jetons SAP pour accorder un accès limité dans le temps aux appareils et aux services à des fonctionnalités spécifiques dans IoT Hub. Pour obtenir l’autorisation de se connecter à IoT Hub, les appareils et services doivent envoyer des jetons SAP signés avec une clé symétrique ou d’accès partagé. Les clés symétriques sont stockées avec l’identité de l’appareil dans le registre de l’identité.

Cet article présente :

• Les différentes autorisations que vous pouvez accorder à un client pour accéder à votre hub IoT.
• Les jetons qu’IoT Hub utilise pour vérifier les autorisations.
• Le mode de définition de l’étendue des informations d’identification pour limiter l’accès à des ressources spécifiques.
• Les mécanismes d’authentification d’appareil personnalisés qui utilisent des registres d’identités d’appareil ou des schémas d’authentification existants.

IoT Hub utilise des autorisations pour accorder l’accès à chaque point de terminaison IoT Hub. Les autorisations limitent l’accès à un IoT Hub selon la fonctionnalité. Pour accéder à tout point de terminaison IoT Hub, vous devez disposer des autorisations appropriées. Par exemple, un appareil doit inclure un jeton contenant des informations d’identification de sécurité dans chaque message envoyé à IoT Hub. Toutefois, les clés de signature, comme les clés symétriques d’appareil, ne sont jamais envoyées sur le réseau.

Authentification et autorisation

L’authentification est le processus visant à prouver que vous êtes bien qui vous prétendez être. L’authentification vérifie l’identité d’un utilisateur ou d’un appareil auprès d’IoT Hub. En anglais, elle est parfois abrégée en AuthN. L’autorisation est le processus de confirmation des autorisations pour un utilisateur ou un appareil authentifié sur IoT Hub. Elle spécifie les ressources et les commandes auxquelles vous êtes autorisé à accéder, ainsi que ce que vous pouvez faire avec ces ressources et commandes. En anglais, elle est parfois abrégée en AuthZ.

Cet article décrit l’authentification et l’autorisation à l’aide des signatures d’accès partagé, qui vous permettent de regrouper les autorisations et de les accorder aux applications à l’aide de clés d’accès et de jetons de sécurité signés. Vous pouvez également utiliser des clés symétriques ou des clés d’accès partagé pour authentifier un appareil avec IoT Hub. Les jetons SAP fournissent une authentification pour chaque appel effectué par l’appareil à IoT Hub en associant la clé symétrique à chaque appel.

Contrôle d’accès et autorisations

Utilisez des stratégies d’accès partagé pour l’accès au niveau de l’instance IoT Hub et utilisez les informations d’identification de l’appareil individuel pour limiter l’accès à cet appareil uniquement.

Stratégies d’accès partagé au niveau d’IoT Hub

Les stratégies d’accès partagé peuvent accorder n’importe quelle combinaison d’autorisations. Vous pouvez définir des stratégies dans le portail Azure, par programmation à l’aide des API REST de ressources IoT Hub ou en utilisant l’interface de la commande Azure CLI az iot hub policy. Un hub IoT qui vient d’être créé a les stratégies par défaut suivantes :

Vous pouvez utiliser les autorisations suivantes pour contrôler l’accès à votre concentrateur IoT :

• L’autorisation ServiceConnect est utilisée par les services cloud principaux et accorde l’accès suivant :

  • Accès à la communication de services cloud et à la surveillance des points de terminaison.
  • Recevoir des messages appareil-à-cloud, d’envoyer des messages cloud-à-appareil et de récupérer les accusés de remise correspondants.
  • Récupérer les accusés de remise pour les chargements de fichiers.
  • Accéder aux jumeaux pour mettre à jour les balises et les propriétés voulues, de récupérer les propriétés signalées et d’exécuter des requêtes.

• L’autorisation ServiceConnect est utilisée par les appareils et accorde l’accès suivant :

  • Accès aux points de terminaison côté appareil.
  • Envoyer des messages appareil-à-cloud et de recevoir des messages cloud-à-appareil.
  • Effectuer le chargement du fichier.
  • Recevoir des notifications de propriétés voulues pour les jumeaux d’appareil et de mettre à jour les propriétés signalées pour les jumeaux d’appareil.

• L’autorisation RegistryRead est utilisée par les services cloud principaux et accorde l’accès suivant :

  • Accès en lecture au registre des identités. Pour plus d’informations, consultez Registre des identités.

• L’autorisation RegistryReadWrite est utilisée par les services cloud principaux et accorde l’accès suivant :

  • Accès en lecture et en écriture au registre des identités. Pour plus d’informations, consultez Registre des identités.

Informations d’identification de sécurité par appareil

Chaque hub IoT possède un registre des identités qui stocke des informations sur les appareils et modules autorisés à s’y connecter. Pour qu’un appareil ou module puisse se connecter, une entrée correspondant à cet appareil ou module doit figurer dans le registre des identités du hub IoT. Un appareil ou module s’authentifie auprès du hub IoT à l’aide des informations d’identification stockées dans le registre des identités.

Lorsque vous inscrivez un appareil pour utiliser l’authentification par jeton SAP, cet appareil obtient deux clés symétriques. Les clés symétriques accordent l’autorisation DeviceConnect pour l’identité d’appareil associée.

Utiliser des jetons SAP à partir de services

Les services peuvent générer des jetons SAP à l’aide d’une stratégie d’accès partagé qui définit les autorisations appropriées comme expliqué précédemment dans la section Contrôle d’accès et autorisations.

Par exemple, un service qui utilise la stratégie d’accès partagé précréée appelée registryRead crée un jeton avec les paramètres suivants :

• URI de ressource : {IoT hub name}.azure-devices.net,
• clé de signature : une des clés de la stratégie registryRead ,
• nom de la stratégie : registryRead,
• n’importe quelle heure d’expiration.

Par exemple, le code suivant crée un jeton SAP dans Node.js :

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

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

Le résultat, qui accorde l’accès pour lire toutes les identités d’appareil dans le Registre des identités, serait :

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

Pour plus d’exemples, consultez Générer des jetons SAP.

Pour les services, les jetons SAP accordent uniquement des autorisations au niveau du IoT Hub. Autrement dit, un service qui s’authentifie avec un jeton basé sur la stratégie de service peut effectuer toutes les opérations accordées par l’autorisation ServiceConnect. Ces opérations incluent la réception de messages appareil à cloud, l’envoi de messages cloud à appareil, et ainsi de suite. Si vous souhaitez accorder un accès plus précis à vos services, par exemple, limiter un service à l’envoi de messages cloud à appareil uniquement, vous pouvez utiliser Microsoft Entra ID. Pour en savoir plus, consulter S’authentifier avec Microsoft Entra ID.

Utiliser des jetons SAP à partir d’appareils

Il existe deux façons d’obtenir des autorisations DeviceConnect avec IoT Hub au moyen de jetons SAP : utiliser une clé d’appareil symétrique extraite du registre des identités ou une clé d’accès partagé.

Toutes les fonctionnalités accessibles à partir des appareils sont exposées par définition sur les points de terminaison avec le préfixe /devices/{deviceId}.

Les points de terminaison côté appareil sont (quel que soit le protocole) :

Utilisation d’une clé symétrique dans le registre d’identité

Lorsqu’une clé symétrique d’identité de l’appareil est utilisée pour générer un jeton, l’élément PolicyName (skn) du jeton est omis.

Par exemple, un jeton créé pour accéder à toutes les fonctionnalités de l’appareil doit avoir les paramètres suivants :

• URI de ressource : {IoT hub name}.azure-devices.net/devices/{device id},
• clé de signature : n’importe quelle clé symétrique pour l’identité {device id} ,
• pas de nom de stratégie,
• n’importe quelle heure d’expiration.

Par exemple, le code suivant crée un jeton SAP dans Node.js :

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

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

Le résultat, qui accorde l’accès à toutes les fonctionnalités de device1, est alors :

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

Pour plus d’exemples, consultez Générer des jetons SAP.

Utiliser une stratégie d’accès partagé pour accéder au nom d’un appareil

Quand vous créez un jeton à partir d’une stratégie d’accès partagé, spécifiez le nom de la stratégie dans le champ skn. Cette stratégie doit accorder l’autorisation DeviceConnect.

Les deux principaux scénarios pour l’utilisation de stratégies d’accès partagé pour accéder aux fonctionnalités de l’appareil sont :

• passerelles de protocole cloud,
• services de jeton utilisés pour implémenter des schémas d’authentification personnalisés.

Étant donné que la stratégie d’accès partagé peut potentiellement accorder un accès pour se connecter comme n’importe quel appareil, il est important d’utiliser l’URI de ressource correct lors de la création de jetons SAP. Ce paramètre est particulièrement important pour les services de jeton dont il faut définir l’étendue pour un appareil spécifique à l’aide de l’URI de ressource. Ce point est moins important pour les passerelles de protocole, car elles interceptent déjà le trafic pour tous les appareils.

Par exemple, un service de jeton utilisant la stratégie d’accès partagé précréée appelée appareil crée un jeton avec les paramètres suivants :

• URI de ressource : {IoT hub name}.azure-devices.net/devices/{device id},
• clé de signature : une des clés de la stratégie device ,
• nom de la stratégie : device,
• n’importe quelle heure d’expiration.

Par exemple, le code suivant crée un jeton SAP dans Node.js :

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

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

Le résultat, qui accorde l’accès à toutes les fonctionnalités de device1, est alors :

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

Une passerelle de protocole peut utiliser le même jeton pour tous les appareils en définissant l’URI de ressource sur myhub.azure-devices.net/devices.

Pour plus d’exemples, consultez Générer des jetons SAP.

Créer un service de jeton pour intégrer des appareils existants

Vous pouvez utiliser le registre des identités IoT Hub pour configurer les informations d’identification de sécurité et le contrôle d’accès par appareil ou par module à l’aide de jetons. Si une solution IoT a déjà un registre des identités et/ou un schéma d’authentification personnalisé, vous pouvez créer un service de jeton pour intégrer cette infrastructure existante à IoT Hub. De cette façon, vous pouvez utiliser d'autres fonctionnalités IoT dans votre solution.

Un service de jeton est un service cloud personnalisé. Il utilise une stratégie d’accès partagé d’IoT Hub avec l’autorisation DeviceConnect pour créer des jetons device-scoped ou module-scoped. Ces jetons permettent à un appareil ou à un module de se connecter à votre hub IoT.

Voici les principales étapes du schéma de service de jeton :

1. Créez une stratégie d’accès partagé IoT Hub avec des autorisations DeviceConnect pour votre hub IoT. Vous pouvez créer cette stratégie dans le Portail Azure ou par programme. Le service de jetons utilise cette stratégie pour signer les jetons qu'elle crée.

2. Quand un appareil ou un module doit accéder à votre hub IoT, il demande à votre service de jetons un jeton signé. L’appareil peut s’authentifier avec votre registre des identités personnalisé/schéma d’authentification pour déterminer l’identité d’appareil/de module que le service de jeton utilise pour créer le jeton.

3. Le service de jeton renvoie un jeton. Le jeton est créé à partir de /devices/{deviceId} ou /devices/{deviceId}/modules/{moduleId} en tant que resourceURI, avec deviceId en tant qu’appareil en cours d’authentification et moduleId en tant que module en cours d’authentification. Le service de jeton utilise la stratégie d'accès partagé pour construire le jeton.

4. L’appareil/le module utilise le jeton directement avec le hub IoT.

Le service de jetons peut définir l’expiration du jeton comme vous le souhaitez. Quand le jeton expire, le hub IoT interrompt la connexion. L’appareil/le /module doit ensuite demander un nouveau jeton au service de jeton. Un délai d’expiration court accroît la charge de l’appareil/du module et du service de jeton.

Pour qu’un appareil/module se connecte à votre hub, vous devez l’ajouter au registre des identités IoT Hub, même s’il utilise un jeton et non une clé pour se connecter. Ainsi, vous pouvez continuer d’utiliser le contrôle d’accès par appareil/par module en activant ou désactivant les identités des appareils/modules dans le registre des identités. Cette approche réduit les risques liés à l'utilisation de jetons avec des délais d'expiration longs.

Comparaison avec une passerelle personnalisée

Le modèle de service de jeton est la méthode recommandée pour implémenter un schéma de registre d’identité/d’authentification avec IoT Hub. Ce modèle est recommandé car il laisse IoT Hub gérer la plupart du trafic de la solution. Toutefois, si l’entrelacement entre le schéma d’authentification personnalisé et le protocole SSL est conséquent, vous aurez peut-être besoin d’une passerelle personnalisée pour traiter tout le trafic. Le protocole TLS (Transport Layer Security) et les clés prépartagées (PSK) en sont un exemple. Pour plus d’informations, consultez Guide pratique pour utiliser un appareil IoT Edge en tant que passerelle.

Générer un jeton SAS

Les kits de développement logiciel (SDK) Azure IoT génèrent automatiquement des jetons, mais certains scénarios vous obligent à générer et à utiliser des jetons SAP directement, notamment :

• Utilisation directe des surfaces MQTT, AMQP ou HTTPS.

• L’implémentation du modèle de service de jetons, comme expliqué dans la section Créer un service de jetons.

Un jeton signé avec une clé d’accès partagé accorde un accès à toutes les fonctionnalités associées aux autorisations de stratégie d’accès partagé. Un jeton signé avec la clé symétrique de l’identité de l’appareil accorde uniquement l’autorisation DeviceConnect à l’identité de l’appareil associée.

Cette section fournit des exemples de génération de jetons SAP dans différents langages de code. Vous pouvez également générer des jetons SAP à l’aide de la commande d’extension de l’interface CLI az iot hub generate-sas-token ou de l’extension Azure IoT Hub pour Visual Studio Code.

Structure de jeton SAS

Un jeton SAP a le format suivant :

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

Voici les valeurs attendues :

le préfixe URI est calculé par segment et non par caractère. Par exemple , /a/b est un préfixe de /a/b/c, mais pas de /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;
}

Spécifications de protocole

Chaque protocole pris en charge (par exemple, MQTT, AMQP et HTTPS) transporte des jetons de différentes façons.

Quand vous utilisez MQTT, le paquet CONNECT utilise deviceid en tant que ClientId, {iothubhostname}/{deviceId} dans le champ Nom d’utilisateur et un jeton SAP dans le champ Mot de passe. {iothubhostname} doit être le nom canonique (CNAME) complet du hub IoT (par exemple, myhub.azure-devices.net).

Lorsque vous utilisez AMQP, IoT Hub prend en charge SASL PLAIN et la sécurité basée sur des revendications AMQP.

Si vous utilisez une sécurité basée sur des revendications AMQP, la norme indique comment transmettre les jetons répertoriés ci-dessus.

Pour SASL PLAIN, le nom d’utilisateur peut être :

• {policyName}@sas.root.{iothubName} si vous utilisez des jetons au niveau du hub IoT.
• {deviceId}@sas.{iothubname} si vous utilisez des jetons à l’échelle de l’appareil.

Dans les deux cas, le champ de mot de passe contient le jeton, comme indiqué dans la structure Jetons SAP .

Le protocole HTTPS implémente l’authentification en incluant un jeton valide dans l’en-tête de requête Authorization.

Par exemple, nom d’utilisateur (DeviceId respecte la casse) : iothubname.azure-devices.net/DeviceId

Mot de passe (vous pouvez générer un jeton SAS à l’aide de la commande d’extension de l’interface CLI az iot hub generate-sas-token ou de l’extension Azure IoT Hub pour Visual Studio Code) :

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

Considérations spécifiques concernant SASL PLAIN

Lorsque vous utilisez SASL PLAIN avec AMQP, un client qui se connecte à un IoT Hub peut utiliser un jeton unique pour chaque connexion TCP. Quand le jeton expire, la connexion TCP est déconnectée du service, ce qui déclenche une reconnexion. Bien que non problématique pour une application principale, ce comportement peut créer des dommages pour une application d’appareil pour les motifs suivants :

• Les passerelles se connectent généralement au nom de nombreux appareils. Lorsque vous utilisez SASL PLAIN, elles doivent créer une connexion TCP distincte pour chaque appareil se connectant à un hub IoT. Ce scénario augmente considérablement la consommation des ressources d’alimentation et de mise en réseau, ainsi que la latence de chaque connexion d’appareil.

• Les appareils avec des contraintes de ressources sont affectés par l’utilisation accrue des ressources pour se reconnecter après chaque expiration du jeton.

Étapes suivantes

Maintenant que vous savez comment contrôler l’accès à IoT Hub, vous serez peut-être intéressé par les rubriques suivantes du Guide du développeur IoT Hub :

• Utiliser des jumeaux d’appareil pour synchroniser les données d’état et de configuration
• Appeler une méthode directe sur un appareil
• Planifier des travaux sur plusieurs appareils