Bonnes pratiques pour l'exécution d'un backend IoT sur Google Cloud

Last reviewed 2024-05-31 UTC

Ce document présente les bonnes pratiques de sécurité pour la gestion et l'exécution d'un backend IoT (Internet des objets) sur Google Cloud. Dans une solution IoT, un backend IoT connecte les appareils de périphérie à d'autres ressources. Ce document se concentre sur les backends IoT suivants : agent MQTT (Message Queuing Telemetry Transport) et plate-forme IoT.

Ce document fait partie d'une série de documents qui fournissent des informations sur les architectures IoT sur Google Cloud et la migration depuis IoT Core. Cette série comprend également les documents suivants :

Ce document présente les bonnes pratiques pour provisionner et gérer les identifiants des appareils, authentifier et contrôler l'accès aux appareils de périphérie, et permettre aux appareils de périphérie IoT d'accéder aux ressources Google Cloud.

Architecture IoT

Une architecture IoT comprend des services qui vous permettent de provisionner et gérer les identifiants des appareils, d'authentifier et contrôler l'accès aux appareils de périphérie, et d'autoriser les appareils de périphérie à accéder aux ressources Google Cloud. Ce document traite de deux architectures de backend IoT : l'une utilisant l'agent MQTT et l'autre utilisant une plate-forme IoT. Les principales différences de sécurité entre ces deux backends concernent l'identité des appareils et la gestion des appareils. Ces fonctionnalités font partie intégrante des systèmes de plates-formes IoT, contrairement aux agents MQTT qui nécessitent de les fournir.

Le schéma suivant décrit l'architecture IoT.

Architecture backend IoT.

L'architecture montre les services requis pour les trois processus suivants :

  1. Le provisionnement des certificats, c'est-à-dire le processus que vous devez effectuer en vue de préparer un appareil de périphérie pour la configuration.

  2. L'authentification et l'autorisation, qui incluent le schéma d'authentification que l'appareil de périphérie et l'agent MQTT ou la plate-forme IoT utilisent pour s'authentifier mutuellement.

  3. Les connexions entre les appareils de périphérie et les services Google Cloud, qui sont des tâches effectuées par l'appareil de périphérie pour se connecter aux ressources cloud et importer ou télécharger des données.

Ce document traite principalement des bonnes pratiques de sécurité pour le provisionnement et l'authentification.

L'architecture utilise une combinaison des services et fonctionnalités suivants :

  • Un appareil de périphérie (tel qu'un appareil médical) que vous déployez à la périphérie de votre environnement et qui est géographiquement proche des données que vous souhaitez traiter. Les appareils de périphérie se connectent de manière bidirectionnelle à votre backend IoT, ce qui signifie qu'ils peuvent envoyer et recevoir des messages en provenance du backend IoT.
  • Un backend IoT pouvant être un agent MQTT ou une plate-forme IoT.
    • Un agent MQTT fournit une interface sécurisée permettant aux appareils de périphérie de se connecter à l'aide du protocole MQTT. Les agents MQTT ne disposent pas de fonctionnalités d'identité et de gestion des appareils et s'appuient sur des systèmes externes pour les fournir.
    • Une plate-forme IoT est une application cloud qui permet aux appareils de périphérie de se connecter et de communiquer. Les plates-formes IoT fournissent une interface sécurisée permettant aux appareils de périphérie de se connecter à l'aide du protocole MQTT. Chaque plate-forme IoT possède sa propre mise en œuvre de sécurité qui détermine la manière dont elle authentifie et autorise les appareils de périphérie, et comment elle gère les identités des appareils.
  • Un magasin de certificats central qui héberge les certificats pour tous les appareils de périphérie.
  • Les ressources cloud auxquelles les appareils de périphérie doivent accéder.

Provisionner un appareil de périphérie

Avant qu'un appareil de périphérie puisse se connecter à vos charges de travail de backend, vous devez provisionner un certificat pour l'appareil de périphérie. Deux scénarios principaux déterminent la manière dont vous provisionnez le certificat :

  • Si votre solution est basée sur des appareils commerciaux génériques, vous contrôlez entièrement le processus de provisionnement après l'achat de l'appareil.

  • Si vous utilisez des appareils personnalisés, le processus de provisionnement initial se produit lors de la fabrication des appareils et vous devez intégrer le processus de provisionnement avec vos fournisseurs et fabricants.

Dans les deux cas, vous devez créer des certificats d'appareil avec une chaîne de confiance qui renvoie vers une autorité de certification racine (CA). Ces certificats authentifient l'identité de l'appareil et permettent de s'assurer que les mises à jour et les modifications apportées sur celui-ci sont effectuées par des acteurs de confiance. Utilisez une autorité de certification, telle que Certificate Authority Service, pour effectuer les tâches suivantes :

Pour provisionner un certificat d'appareil, vous devez effectuer les tâches suivantes :

  1. Générez la paire de clés publique/privée à l'aide d'une solution de sécurité matérielle compatible avec votre appareil, telle qu'un composant sécurisé (SE) ou un module de sécurité matérielle (HSM). De par sa conception, le composant sécurisé ou le module de sécurité matérielle stocke les clés privées localement et les clés privées ne sont jamais exposées en externe. Si vous n'utilisez pas de solution de sécurité matérielle pour générer une paire de clés publique/privée, utilisez l'autorité de certification pour générer des clés. Pour en savoir plus, consultez la section Utiliser une clé générée automatiquement.

  2. Signez et générez un certificat d'appareil. Après avoir généré la paire de clés publique/privée, téléchargez la clé publique, créez une requête de signature de certificat (CSR), puis envoyez la requête de signature de certificat à l'autorité de certification pour signature. L'autorité de certification génère un certificat d'appareil qui est associé à l'autorité de certification racine. Pour en savoir plus, consultez la section Utiliser une requête de signature de certificat. Lorsque vous utilisez des clés générées automatiquement, vous pouvez demander un certificat d'appareil directement à l'autorité de certification.

  3. Installez le certificat d'appareil signé sur l'appareil de périphérie et envoyez-le à un dépôt de certificats central tel que Secret Manager.

Pour en savoir plus, consultez la section Comment déployer une infrastructure de clé publique sécurisée et fiable avec le service d'autorité de certification de Google Cloud (PDF).

Pour plus d'informations sur les autres bonnes pratiques à adopter pour le provisionnement, consultez la section Bonnes pratiques pour le provisionnement et la configuration automatiques des systèmes et serveurs de périphérie et sur solution Bare Metal.

Trois types de certificats sont utilisés pour aider à sécuriser une solution IoT :

  • Le certificat de l'autorité de certification racine fournit la racine pour la chaîne de confiance de tous les autres certificats de votre système. Les charges de travail de backend utilisent le certificat racine pour valider les certificats clients, et les appareils de périphérie utilisent le certificat racine pour valider le certificat du serveur. Vous devez distribuer le certificat racine au backend IoT et aux appareils de périphérie.

  • Les certificats du serveur permettent de sécuriser les points de terminaison exposés par le backend IoT. Vous disposez de certificats de serveur pour les différents algorithmes de chiffrement que vos points de terminaison doivent prendre en charge. Les certificats de serveur sont associés à l'autorité de certification racine. Un gestionnaire de secrets gère et stocke à la fois les parties privée et publique des certificats de serveur. Vous devez configurer votre backend IoT avec les certificats de serveur et les clés privées correspondantes.

  • Les certificats client sont utilisés pour identifier les appareils de périphérie. Chaque appareil de périphérie possède au moins un certificat client, ce qui signifie que le nombre de certificats dont vous disposez augmente avec le nombre d'appareils de périphérie dans votre environnement. Les certificats clients sont associés à l'autorité de certification racine. Vous devez distribuer les certificats client à vos appareils de périphérie et au backend IoT.

Processus de génération d'un certificat d'appareil à l'aide d'un module de sécurité matérielle ou d'un composant sécurisé

Le schéma suivant montre comment un certificat d'appareil est provisionné lors de l'utilisation d'un module de sécurité matérielle ou d'un composant sécurisé.

Processus de génération d'un certificat d'appareil.

Dans ce schéma, les étapes sont les suivantes :

  1. L'appareil de périphérie génère la paire de clés publique dans le matériel.
  2. Vous téléchargez la clé publique et créez la requête de signature de certificat (CSR) correspondante.
  3. Vous envoyez la requête de signature de certificat à l'autorité de certification afin de demander un certificat.
  4. L'autorité de certification effectue les actions suivantes :
    1. Elle signe le certificat.
    2. Elle renvoie le certificat d'appareil à l'approvisionneur.
  5. L'approvisionneur effectue les actions suivantes :
    1. Il envoie le certificat à l'appareil de périphérie.
    2. Il stocke le certificat dans le magasin de certificats central.
  6. L'appareil de périphérie stocke le certificat dans un emplacement sécurisé.

Processus de génération d'un certificat d'appareil à l'aide de l'autorité de certification

Le schéma suivant montre comment un certificat d'appareil est provisionné lors de l'utilisation d'une autorité de certification.

Processus de génération d'un certificat d'appareil.

Dans ce schéma, les étapes sont les suivantes :

  1. Vous générez une requête de signature de certificat, puis vous l'envoyez à l'autorité de certification afin de demander un certificat.
  2. L'autorité de certification effectue les actions suivantes :
    1. Elle génère une paire de clés publique et signe la clé publique.
    2. Elle renvoie le certificat d'appareil et la clé privée à l'approvisionneur.
  3. Vous effectuez les actions suivantes :
    1. Vous envoyez le certificat et la clé privée à l'appareil de périphérie.
    2. Vous stockez le certificat et la clé privée dans le magasin de certificats central.
  4. L'appareil de périphérie stocke le certificat dans un emplacement sécurisé.

Bonnes pratiques concernant l'identité des appareils

Cette section décrit les bonnes pratiques concernant les identités des appareils.

Utiliser un fournisseur d'identité avec les agents MQTT

Les agents MQTT authentifient les appareils de périphérie à l'aide des identifiants d'appareil fournis par les plug-ins, les bases de données et les fichiers. Pour gérer les identités de vos appareils de manière systématique et évolutive, utilisez un fournisseur d'identité (IdP). Le fournisseur d'identité gère les identités et les identifiants pour tous les appareils et agit comme la principale source de vérité pour les identités des appareils.

Pour maintenir l'identité des appareils à jour dans l'agent MQTT, implémentez une couche d'intégration spécifique au système. Pour en savoir plus sur la gestion des identifiants des appareils, consultez la section Provisionner un appareil de périphérie.

Utiliser les identités numériques de la plate-forme IoT comme source fiable

La plate-forme IoT dispose de fonctionnalités de sécurité qui gèrent les identités et les identifiants des appareils, et authentifient et autorisent les appareils qui tentent d'accéder à la plate-forme. Ces fonctionnalités de sécurité permettent de s'assurer que seuls les appareils autorisés peuvent accéder à la plate-forme IoT et contribuent à garantir l'intégrité des données.

Vérifiez que les identités d'appareil gérées par la plate-forme IoT représentent la principale source fiable de tous les appareils gérés par la plate-forme IoT. Les autres composants d'une solution IoT qui nécessitent des informations sur l'identité de l'appareil doivent s'appuyer sur le système de sécurité de la plate-forme IoT. La plate-forme IoT accorde des droits d'accès aux appareils et propage toutes les modifications de sécurité dans la solution IoT.

Bonnes pratiques pour la connectivité réseau

Il est important de sécuriser la connectivité réseau pour les raisons suivantes :

  • Les réseaux sécurisés permettent de s'assurer qu'un appareil se connecte au bon backend. Par exemple, un réseau sécurisé peut empêcher le spoofing DNS, une attaque qui tente de détourner les appareils pour qu'ils se connectent à un backend non autorisé contrôlé par des pirates informatiques.
  • Les réseaux sécurisés permettent de s'assurer que des tiers ne peuvent pas lire votre trafic de données. Par exemple, un réseau sécurisé peut empêcher une attaque MITM (man-in-the-middle), où les pirates informatiques lisent le trafic entre votre appareil et le backend.

Utilisez le protocole TLS (Transport Layer Security) pour protéger la communication réseau entre les appareils de périphérie et les charges de travail de backend.

Étendez le protocole TLS avec mTLS pour implémenter un schéma d'authentification mutuelle qui permet aux deux parties connectées d'établir l'identité de l'autre.

Pour obtenir des instructions sur l'utilisation de TLS, consultez les sections Architecture d'agent MQTT autonome sur Google Cloud et Architecture des produits de plate-forme IoT sur Google Cloud.

Bonnes pratiques concernant la gestion des certificats pour les agents MQTT

Cette section décrit les bonnes pratiques concernant la gestion des certificats lors de l'utilisation d'agents MQTT.

Stocker les certificats de manière centralisée

Stockez et gérez les certificats de serveur et les certificats d'appareils dans un emplacement central. Plus précisément, assurez-vous que les contrôles suivants sont en place :

  • Un inventaire de tous vos appareils et leurs certificats, ainsi que des points de terminaison du serveur et leurs certificats.
  • Des informations supplémentaires sur les certificats, telles que leur validité.
  • La possibilité d'ajouter et de supprimer des certificats pour les appareils afin qu'ils puissent se connecter à l'aide de nouveaux certificats.
  • Des droits d'accès à votre magasin de certificats central, afin de limiter les actions des différents rôles dans votre backend avec les certificats.

Utilisez une solution de stockage et de gestion de secrets telle que Secret Manager ou HashiCorp Vault. Secret Manager vous permet de créer des révisions, de mettre à jour et d'invalider les identifiants des appareils, et de gérer les règles d'accès à vos identifiants.

Pour une plate-forme IoT, implémentez l'accès aux identifiants à l'aide de l'accès à l'API Secret Manager.

Protéger les certificats sur les appareils de périphérie

Pour stocker des certificats et des clés sur les appareils de périphérie, utilisez un environnement d'exécution sécurisé ou un magasin de certificats local afin de protéger les identifiants et bloquer les accès non autorisés. Si vous devez stocker du contenu secret sur vos appareils, chiffrez-le en utilisant des techniques telles que le chiffrement flash et stockez-le sur des éléments infalsifiables afin d'empêcher toute extraction de données non autorisée.

Synchroniser le magasin de certificats central avec le magasin de certificats de l'agent MQTT

Les agents MQTT doivent accéder aux certificats clients pour l'authentification par certificat. Vous devez donc synchroniser les magasins de certificats des agents MQTT avec le magasin de certificats central. Vérifiez que les modifications apportées au magasin de certificats central, telles que l'ajout, la mise à jour et la suppression de certificats, sont synchronisées avec le magasin de certificats de l'agent MQTT. Les agents MQTT utilisent des magasins de certificats tels que MySQL, PostgresDB et Java Key Store. Selon le magasin de certificats utilisé par votre agent MQTT, assurez-vous que les processus suivants existent :

  • Un processus qui surveille les modifications apportées au magasin de certificats central et notifie le processus de synchronisation.
  • Un processus qui prend en compte les modifications dans le magasin de certificats central et les synchronise avec le magasin de certificats utilisé par l'agent MQTT.

Lorsque vous utilisez Secret Manager comme magasin de certificats, vous pouvez utiliser les notifications d'événement comme processus de surveillance. Vous pouvez implémenter le processus de synchronisation en tant qu'écouteur des notifications d'événements.

Distribuer des certificats à des appareils de périphérie de manière sécurisée

Lorsque vous utilisez des agents MQTT, distribuez les certificats racine et client à vos appareils de périphérie. Lorsque vous distribuez des certificats, vous devez sécuriser vos canaux de communication afin que le trafic ne soit pas intercepté.

Les principaux canaux de communication pour la distribution des certificats sont les suivants :

  • Un chemin d'accès direct du backend IoT vers les appareils de périphérie via les canaux de communication existants.
  • Un chemin d'accès indirect dans lequel les appareils de périphérie demandent et téléchargent les certificats.

Lors de la distribution du certificat, vous avez besoin des composants suivants :

  • Un magasin de certificats dans lequel les certificats sont gérés de manière centralisée.
  • Un coordinateur de distribution qui envoie les certificats et suit le processus de distribution pour chaque appareil de périphérie.
  • Un gestionnaire de mise à jour sur l'appareil de périphérie qui reçoit ou télécharge les certificats et les stocke sur l'appareil.

Distribuez les certificats lors des processus de provisionnement pour les appareils de périphérie, et lorsque vous devez effectuer une rotation des certificats.

Au cours du processus de provisionnement, assurez-vous que l'approvisionneur dispose d'un accès direct aux appareils de périphérie via des canaux chiffrés tels que SSH et qu'il utilise des outils tels que SCP. Comme les appareils ne sont pas en fonctionnement, vous pouvez envoyer des certificats directement aux appareils de périphérie.

Lors de la rotation des certificats, utilisez l'agent MQTT comme canal de communication entre le coordinateur de distribution et les appareils de périphérie. Utilisez d'autres canaux pour télécharger des certificats sur l'appareil. Pour minimiser les perturbations des appareils de périphérie en fonctionnement, utilisez un chemin de distribution de certificats indirect. Le processus comprend les étapes logiques suivantes :

  1. Le coordinateur de distribution acquiert les identifiants d'accès auprès du magasin de certificats.
  2. Le coordinateur de distribution envoie les identifiants d'accès au certificat aux appareils de périphérie avec des informations supplémentaires, telles que l'URL de téléchargement.
  3. Le gestionnaire de mise à jour sur l'appareil reçoit les identifiants d'accès, stocke temporairement les informations et renvoie un accusé de réception.
  4. Le gestionnaire de mise à jour coordonne le téléchargement du certificat lorsque l'appareil n'est pas actif. Le gestionnaire de mises à jour utilise les identifiants d'accès pour télécharger les certificats à partir du magasin d'identifiants.
  5. Une fois les certificats téléchargés, le gestionnaire de mise à jour poursuit le processus de rotation des certificats, décrit dans la section Rotation des certificats.

Lorsque vous utilisez Secret Manager comme magasin de certificats central, vous pouvez générer des jetons d'accès de courte durée pour accorder et limiter l'accès aux certificats. Pour en savoir plus, consultez la section Distribuer les jetons d'accès aux appareils de manière sécurisée.

Pour éviter l'exposition des certificats pendant le transit, chiffrez la connexion entre vos appareils de périphérie et l'agent MQTT. Pour en savoir plus, consultez la section Bonnes pratiques pour la connectivité réseau.

Effectuer une rotation automatique des certificats

Pour limiter les dommages qu'un certificat exposé peut entraîner, générez des certificats avec une période de validité limitée et effectuez une rotation des certificats avant leur expiration. Pour les déploiements IoT à grande échelle, implémentez une procédure de rotation automatique des certificats pour mettre à jour vos appareils de manière cohérente avec les nouveaux certificats avant l'expiration des anciens. Des appareils déployés sans certificats valides signifie qu'ils peuvent cesser de fonctionner, ce qui peut s'avérer coûteux à corriger et peut également affecter défavorablement les fonctionnalités globales de votre solution IoT.

Vos appareils de périphérie doivent se connecter de manière bidirectionnelle avec votre agent MQTT pour s'assurer qu'ils peuvent envoyer des messages à l'agent MQTT et qu'ils peuvent recevoir des messages de l'agent MQTT.

Lors de la rotation des certificats, vous avez besoin des composants suivants :

  • Un processus de surveillance qui parcourt de manière récurrente votre inventaire de certificats et recherche des certificats sur le point d'expirer. Le processus de surveillance déclenche la rotation des certificats pour les certificats arrivant bientôt à expiration.
  • Un processus de rotation qui initialise et supervise la rotation des certificats.
  • Un gestionnaire de rotation de certificats d'appareil sur l'appareil de périphérie qui communique avec l'agent MQTT et exécute les étapes de rotation de certificats sur l'appareil.

Pour procéder à la rotation des certificats, la solution IoT effectue les étapes suivantes :

  1. Le processus de rotation envoie un message d'initialisation à l'appareil de périphérie pour démarrer la rotation du certificat.
  2. Le gestionnaire de rotation des certificats d'appareil accuse réception du message d'initialisation en renvoyant une réponse au job de rotation.
  3. Le processus de rotation demande un nouveau certificat à l'autorité de certification. Cette requête est semblable à la requête de provisionnement de certificats, à la différence que les clés et la requête de signature de certificat sont envoyées en tant que messages d'agent MQTT.
  4. Après avoir reçu le nouveau certificat de l'autorité de certification, le job de rotation distribue le certificat au magasin de certificats central et à l'appareil de périphérie. Il synchronise également le certificat avec le magasin de certificats de l'agent MQTT.
  5. Le gestionnaire de rotation des certificats d'appareil stocke le nouveau certificat et initialise une nouvelle connexion avec l'agent MQTT à l'aide de ce nouveau certificat.
  6. Une fois la nouvelle connexion établie, le gestionnaire de rotation des certificats d'appareil envoie un message d'achèvement à l'agent MQTT.
  7. Après avoir reçu le message d'achèvement, le processus de rotation invalide l'ancien certificat dans le magasin de certificats central.

Pour protéger les certificats envoyés pendant le processus de rotation, utilisez des sujets MQTT dédiés pour la rotation des certificats. Limitez l'accès à ces sujets à la tâche de rotation et à l'appareil de périphérie uniquement.

Pour protéger le processus de rotation des certificats contre les échecs d'exécution, activez la persistance pour les modifications et la progression.

Pour en savoir plus sur la rotation des secrets à l'aide de Secret Manager, consultez la section Rotation des secrets.

Bonnes pratiques concernant la gestion des certificats pour les plates-formes IoT

Si vous utilisez une plate-forme IoT, utilisez les mécanismes de mise à jour et de distribution du certificat fournis par la plate-forme. À des fins de sauvegarde, vous pouvez exporter régulièrement les identifiants de votre plate-forme IoT vers un espace de stockage des secrets secondaire, tel que Secret Manager.

Bonnes pratiques pour l'authentification avec un agent MQTT

Au cours du processus d'authentification mutuelle, les charges de travail de backend vérifient l'identité des appareils de périphérie, et les appareils de périphérie vérifient l'identité des charges de travail de backend. Une fois que les charges de travail de backend ont confirmé l'identité de l'appareil de périphérie, les charges de travail de backend autorisent l'appareil à accéder aux ressources.

Les sections suivantes décrivent les bonnes pratiques concernant les méthodes d'authentification lors de l'utilisation des agents MQTT.

Choisir la méthode d'authentification pour les agents MQTT

Différents backends IoT prennent en charge différentes méthodes d'authentification. Les méthodes couramment utilisées sont les suivantes :

  • L'authentification par nom d'utilisateur et mot de passe, où l'appareil de périphérie présente son nom d'utilisateur et son mot de passe pour vérifier son identité.
  • L'authentification basée sur des jetons, où des jetons de sécurité chiffrés sont utilisés pour vérifier l'identité de l'appareil de périphérie.
  • Les schémas d'authentification personnalisée, où vous implémentez un mécanisme personnalisé pour vérifier l'identité de l'appareil de périphérie.

Dans le cadre de la norme MQTT, les agents MQTT acceptent l'authentification par nom d'utilisateur et mot de passe par défaut pour les paquets MQTT CONNECT.

Le paquet MQTT CONNECT contient également un champ Client Identifier que vous pouvez utiliser pour identifier de manière unique le client auprès de l'agent MQTT. Les appareils de périphérie envoient le paquet MQTT CONNECT à l'agent MQTT lorsqu'ils établissent une connexion.

Outre les champs de nom d'utilisateur, mot de passe et identifiant client dans le paquet MQTT CONNECT, le protocole MQTT 5.0 accepte l'authentification améliorée, qui vous permet de créer des flux d'authentification de type question-réponse. MQTT 5.0 permet plusieurs échanges de paquets AUTH entre l'appareil de périphérie et l'agent MQTT.

Utiliser des magasins de mots de passe avec authentification par nom d'utilisateur et mot de passe

Pour l'authentification par nom d'utilisateur et mot de passe, configurez l'agent MQTT afin qu'il utilise un magasin de mots de passe. Le magasin de mots de passe fournit un emplacement centralisé pour la gestion des mots de passe pour tous les appareils de périphérie qui se connectent à l'agent MQTT. Par défaut, les champs de nom d'utilisateur, mot de passe et identifiant client sont facultatifs dans la spécification MQTT. Par conséquent, concevez votre mécanisme d'authentification de façon à vérifier que les champs de nom d'utilisateur, mot de passe et identifiant client sont présents dans le paquet MQTT CONNECT.

Assurez-vous que les mots de passe sont chiffrés au repos et en transit, comme suit :

Envisager l'authentification basée sur des jetons

Avec l'authentification basée sur des jetons, les appareils de périphérie envoient un jeton à l'agent MQTT pour s'authentifier. Les appareils peuvent générer le jeton eux-mêmes ou obtenir le jeton par le biais d'autres services d'authentification. Par rapport aux mots de passe, les jetons sont de courte durée : les jetons ne sont valides que pendant une période donnée avec une date d'expiration explicite. Vérifiez toujours la date d'expiration lors de la validation des jetons.

Les jetons Web JSON (JWT) permettent d'implémenter l'authentification basée sur des jetons. Les appareils de périphérie peuvent générer le jeton JWT et s'authentifier auprès de l'agent MQTT. Le jeton JWT est intégré au paquet MQTT CONNECT en tant que champ de mot de passe.

Les avantages des jetons JWT sont les suivants :

  • Les jetons JWT vous permettent de choisir l'algorithme de chiffrement utilisé pour signer le jeton. Les jetons JWT fonctionnent bien avec les appareils de périphérie limités, où vous pouvez utiliser un algorithme de chiffrement nécessitant moins de ressources, tel que ECC, pour la signature du jeton.
  • En utilisant la cryptographie à clé publique, la clé privée n'est utilisée que sur l'appareil de périphérie et n'est jamais partagée avec d'autres parties. Une clé privée contribue à rendre cette méthode plus sécurisée que l'authentification par nom d'utilisateur et mot de passe, où les identifiants sont envoyés via la connexion et nécessitent le chiffrement des données.

Envisager des schémas d'authentification personnalisée

Certains agents MQTT sont compatibles avec différents mécanismes d'authentification et protocoles. Par exemple, si votre agent MQTT accepte les schémas d'authentification personnalisée, vous pouvez le configurer pour qu'il prenne en charge les éléments suivants :

  • Protocoles d'authentification standards du secteur, tels que OpenID Connect, SAML (Security Assertion Markup Language), LDAP, Kerberos et SASL (Simple Authentication and Security Layer). Ces protocoles délèguent l'authentification des appareils à vos fournisseurs d'identité existants. Certains agents MQTT acceptent l'authentification renforcée et les mécanismes d'authentification extensibles que vous pouvez utiliser pour étendre l'agent MQTT afin de prendre en charge de nouveaux protocoles et fournisseurs d'identité.
  • Authentification mutuelle basée sur des certificats. Certains agents MQTT acceptent un schéma d'authentification mutuelle, tel que l'authentification basée sur mTLS.

Bonnes pratiques concernant le contrôle des accès et l'autorisation des appareils

En raison du modèle de communication de l'éditeur et de l'abonné du protocole MQTT, le contrôle des accès des appareils est défini à l'aide de sujets MQTT. Les sujets MQTT contrôlent la manière dont un appareil peut communiquer avec votre backend IoT. Chaque backend IoT présente des implémentations différentes pour le contrôle des accès et les autorisations. Par conséquent, consultez la documentation de votre backend IoT pour connaître les options de configuration des sujets MQTT.

Utiliser des comptes de service à usage unique pour accéder aux ressources Google Cloud

L'accès aux ressources Google Cloud est géré par les stratégies d'autorisation IAM qui établissent un lien entre l'autorisation d'accès aux ressources et un ensemble de comptes principaux. Les comptes principaux typiques sont les comptes utilisateur, les comptes de service et les groupes. Les comptes de service sont généralement utilisés par une application ou une charge de travail de calcul pour effectuer des appels d'API autorisés pour des ressources cloud. Les comptes de service permettent aux appareils de périphérie IoT d'accéder aux ressources cloud.

Comme l'identité de l'appareil est gérée par le backend IoT, vous devez mapper une identité entre le backend IoT et IAM afin que l'appareil de périphérie puisse accéder aux ressources Google Cloud.

Si vous gérez un grand nombre d'appareils, la limite du nombre de comptes de service pour chaque projet Google Cloud empêche d'établir un mappage direct de type "un à un" entre l'appareil et le compte de service.

Créez plutôt des comptes de service liés aux ressources cloud auxquelles votre solution IoT doit accéder, comme décrit dans la section Créer des comptes de service à usage unique. Par exemple, créez un compte de service unique pour chacun des cas d'utilisation suivants :

  • Télécharger des packages de mises à jour logicielles
  • Importer des fichiers multimédias volumineux
  • Ingérer des données à partir d'un flux de latence

Pour mettre en œuvre le principe de moindre privilège, assurez-vous que chaque compte de service dispose uniquement des droits d'accès suffisants pour prendre en charge son cas d'utilisation. Par exemple, pour un compte de service utilisé pour télécharger des packages logiciels, accordez uniquement un accès en lecture au bucket Cloud Storage.

Distribuer des jetons d'accès aux appareils de manière sécurisée

En règle générale, vos appareils de périphérie communiquent avec votre plate-forme IoT à l'aide du protocole MQTT. Toutefois, dans certains cas d'utilisation spécifiques, vos appareils peuvent nécessiter un accès direct aux ressources Google Cloud. Nous vous conseillons, par exemple, de suivre les recommandations suivantes :

  • Pour télécharger du contenu, un appareil de périphérie nécessite un accès en lecture seule à un bucket Cloud Storage pendant le processus de téléchargement uniquement.
  • Pour importer des données dans un bucket Cloud Storage, un appareil de périphérie nécessite un accès en écriture au bucket.

Pour ces cas d'utilisation, utilisez la fédération d'identité de charge de travail, où l'accès aux ressources Google Cloud est accordé via des jetons d'accès. La fédération d'identité de charge de travail évite d'avoir à provisionner des identifiants spécifiques au cloud sur les appareils de périphérie, et la distribution des accès se fait de manière dynamique en fonction de la demande.

Pour distribuer des jetons d'accès pour les ressources cloud à vos appareils, configurez la fédération d'identité de charge de travail entre votre fournisseur d'identité d'appareil et Google Cloud. Pour garantir la compatibilité avec la fédération d'identité de charge de travail, assurez-vous que votre backend IoT répond aux exigences de la fédération d'identité de charge de travail et suit les bonnes pratiques en matière de sécurité correspondant à vos cas d'utilisation.

Pour accéder aux ressources Google Cloud à l'aide de la fédération d'identité de charge de travail, vos appareils de périphérie doivent mettre en œuvre le workflow OAuth 2.0 Token Exchange, qui implique les étapes suivantes :

  • L'appareil appelle Security Token Service et fournit ses propres identifiants d'appareil.
  • Security Token Service vérifie l'identité de l'appareil de périphérie en validant les identifiants fournis auprès du fournisseur d'identité de l'appareil.
  • Si la validation de l'identité réussit, Security Token Service renvoie un jeton fédéré à l'appareil de périphérie.
  • L'appareil de périphérie utilise le jeton fédéré pour emprunter l'identité du compte de service à usage unique et obtient un jeton d'accès OAuth 2.0 de courte durée.
  • L'appareil utilise le jeton d'accès OAuth 2.0 de courte durée pour s'authentifier auprès des API Google Cloud et accéder aux ressources cloud requises.

Pour limiter l'accès du jeton d'accès de courte durée à des buckets et des objets spécifiques dans Cloud Storage, utilisez des limites d'accès aux identifiants. Les limites d'accès aux identifiants vous permettent de limiter l'accès des identifiants de courte durée et de réduire le nombre de ressources exposées dans vos buckets Cloud Storage lorsqu'un jeton d'accès est compromis.

La fédération d'identité de charge de travail est un moyen évolutif de distribuer l'accès cloud aux appareils de périphérie de manière sécurisée. Pour en savoir plus sur l'authentification, consultez la page Authentification chez Google.

Surveiller et auditer l'accès aux ressources cloud

Activez Cloud Audit Logs pour créer des entrées de journal lorsque vos appareils de périphérie accèdent aux ressources cloud via des requêtes API authentifiées. Cloud Audit Logs vous permet de surveiller les actions critiques effectuées par vos appareils de périphérie sur Google Cloud. De plus, Cloud Audit Logs crée les traces et journaux d'audit dont vous avez besoin pour examiner les problèmes. Pour en savoir plus, consultez la section Emprunter l'identité d'un compte de service pour accéder à Google Cloud.

Étapes suivantes