Principes de base de la sécurité IoT — 5e partie : se connecter en toute sécurité aux services cloud IoT

Par Stephen Evanczuk

Avec la contribution de Rédacteurs nord-américains de DigiKey

Note de l'éditeur : Malgré la prolifération des dispositifs IoT, la sécurisation de ces dispositifs reste une préoccupation constante, dans la mesure où les problèmes de sécurité peuvent constituer un obstacle à l'adoption des dispositifs connectés dans les applications Internet industriel des objets (IIoT) et les applications stratégiques où les données d'entreprise et personnelles peuvent être compromises en cas d'attaque réussie. Sécuriser les applications IoT peut être intimidant, mais en réalité la sécurité des dispositifs IoT peut reposer sur quelques principes relativement simples qui sont pris en charge par les dispositifs de sécurité matériels. En suivant des pratiques de sécurité bien établies, il est possible de répondre à ces préoccupations. Cette série en plusieurs parties fournit des conseils pratiques pour aider les développeurs à s'assurer que les meilleures pratiques sont suivies dès le départ. La 1re partie traite des algorithmes de cryptographie sous-jacents aux conceptions sécurisées. La 2e partie traite du rôle des clés privées, de la gestion des clés et du stockage sécurisé dans les conceptions IoT sécurisées. La 3e partie étudie les mécanismes intégrés dans les processeurs sécurisés pour atténuer les autres types de menaces sur les dispositifs IoT. La 4e partie identifie des mécanismes de sécurité et montre comment les appliquer dans les processeurs avancés pour contribuer à assurer l'isolement requis pour atténuer les attaques sur l'environnement d'exécution des dispositifs IoT. Ici, la 5e partie décrit comment la sécurité IoT continue à s'étendre depuis les dispositifs IoT par le biais de mesures de sécurité de niveau supérieur utilisées pour connecter ces dispositifs aux ressources cloud IoT.

La sécurité de l'Internet des objets (IoT) dépend de plusieurs couches de protection s'étendant de la base matérielle du dispositif IoT à son environnement d'exécution. Cependant, des menaces subsistent pour tout dispositif connecté, et les exigences des applications IoT typiques pour la connectivité cloud peuvent laisser à la fois les dispositifs IoT et les services cloud vulnérables à de nouvelles attaques. Pour atténuer ces menaces, les fournisseurs de services cloud IoT utilisent des protocoles et des politiques de sécurité spécifiques qui, s'ils sont mal utilisés, peuvent rendre les applications IoT vulnérables. Grâce à des cartes de développement pré-configurées, les développeurs peuvent rapidement acquérir de l'expérience quant aux méthodes de sécurité utilisées par les principaux services cloud IoT pour authentifier les connexions et autoriser l'utilisation des dispositifs IoT et des ressources cloud.

Cet article décrit les exigences de connexion de deux services cloud leaders, Amazon Web Services (AWS) et Microsoft Azure, et montre comment les développeurs peuvent utiliser les kits de développement et les logiciels associés de divers fournisseurs pour se connecter rapidement à ces services.

Rôle des portails IoT dans les services cloud

Lorsqu'un dispositif IoT se connecte à une ressource telle qu'un service cloud ou un hôte distant, il s'expose potentiellement lui-même — et par extension il expose l'ensemble du réseau IoT — à des menaces se faisant passer pour des services ou des serveurs légitimes. Inversement, le service cloud lui-même est également confronté à la menace d'attaques de pirates informatiques imitant les transactions des dispositifs IoT pour tenter de pénétrer les défenses du cloud. Afin de garantir la protection des dispositifs IoT et des ressources cloud, les services cloud requièrent l'utilisation de protocoles de sécurité spécifiques pour l'authentification mutuelle de l'identité au moment de la connexion et l'autorisation ultérieure afin de garantir l'utilisation autorisée des services. Ces protocoles sont généralement inclus dans un ensemble de services qui fournissent un portail sécurisé entre les dispositifs IoT et les ressources cloud.

Comme pour les autres plateformes de services cloud IoT disponibles, AWS et Azure fournissent un portail d'entrée spécifique que les dispositifs IoT doivent utiliser pour interagir avec l'ensemble des ressources cloud de chaque fournisseur, comme les machines virtuelles (VM) et les offres de logiciels en tant que services (SaaS). En utilisant un ensemble de mécanismes et de capacités fonctionnellement similaires, Azure IoT Hub et AWS IoT fournissent ce portail pour leurs offres respectives de cloud d'entreprise.

Au minimum, ces portails et d'autres portails IoT utilisent des protocoles d'authentification spécifiques mis en œuvre via le kit de développement logiciel (SDK) de chaque fournisseur pour créer une connexion sécurisée. Pour AWS, les dispositifs IoT se connectent en utilisant l'authentification mutuelle avec une passerelle de périphériques. La passerelle de périphériques connecte le dispositif IoT à d'autres services de support IoT, en utilisant les informations contenues dans un registre de périphériques pour stocker un identificateur de périphérique unique, des identifiants de sécurité et d'autres métadonnées requises pour gérer l'accès aux services AWS (Figure 1). Dans Azure, le registre d'identité remplit une fonction similaire.

Schéma d'AWS fournissant aux développeurs un ensemble de services spécialisésFigure 1 : Comme les autres fournisseurs de services cloud, AWS fournit aux développeurs un ensemble de services spécialisés conçus pour améliorer la sécurité et l'efficacité des transactions entre les dispositifs IoT et les services cloud des entreprises. (Source de l'image : Amazon Web Services)

AWS IoT et Azure IoT fournissent chacun un service qui maintient les informations d'état dans un dispositif virtuel associé à chaque dispositif IoT physique. Dans AWS IoT, les shadows d'appareils fournissent cette capacité pour AWS IoT, tandis que les jumeaux d'appareils fournissent des capacités similaires pour Azure IoT.

Cette notion de portail de sécurité s'étend aux services périphériques IoT tels qu'AWS Greengrass ou Azure IoT Edge. Ces offres de services périphériques apportent certains services cloud et capacités au réseau local, où les systèmes périphériques sont placés physiquement à proximité des systèmes et dispositifs IoT dans les déploiements à grande échelle. Les développeurs peuvent utiliser un service tel qu'Azure IoT Edge pour mettre en œuvre la logique commerciale des applications ou fournir d'autres capacités fonctionnelles nécessaires pour réduire la latence ou fournir des services aux opérateurs locaux, comme dans l'automatisation industrielle (Figure 2).

Schéma des fournisseurs de services cloud offrant des services spécialisés pour prendre en charge l'edge computingFigure 2 : Pour prendre en charge l'edge computing, les fournisseurs de services cloud offrent des services spécialisés tels que Microsoft Azure IoT Edge, qui rapproche certains services cloud Azure IoT des dispositifs physiques associés à l'application IoT. (Source de l'image : Microsoft Azure)

Gestion des exigences en matière de connectivité du portail IoT

Qu'ils se connectent via un système périphérique ou directement avec le service IoT du fournisseur, les dispositifs IoT doivent généralement satisfaire à une série d'exigences pour se connecter via le portail IoT du fournisseur et utiliser les services cloud de ce dernier. Bien que les détails diffèrent, les dispositifs IoT doivent fournir au minimum certains éléments tels qu'une clé privée, un certificat X.509 ou un autre jeton de sécurité. La clé, le certificat ou le jeton fournit au portail IoT une attestation ou une preuve de l'identité du dispositif IoT pendant la phase d'authentification de la séquence de connexion entre le dispositif et le cloud. De plus, les services cloud IoT nécessitent généralement une spécification des politiques utilisées afin de définir les droits d'accès pour les interactions entre les dispositifs IoT et les services cloud.

Comme pour les autres exigences informatiques des entreprises, les informations d'attestation pour l'authentification et les informations de politique pour la gestion des accès doivent être fournies en utilisant des formats et des procédures précis, spécifiés par les principaux services cloud IoT comme AWS IoT et Azure IoT. Ces services prennent en charge l'authentification par certificat au minimum, mais permettent également l'utilisation d'autres formes d'attestation. Par exemple, les développeurs peuvent utiliser des méthodes d'authentification par jeton basées sur JSON Web Token (JWT) pour AWS IoT, ou sur un jeton de signature d'accès partagé (SAS) pour Azure IoT.

Comme mentionné précédemment, ces services utilisent des registres pour conserver les métadonnées de chaque dispositif IoT. En plus des informations de sécurité et d'autres informations, ces registres stockent les politiques de droits d'accès qui doivent être définies pour connecter un dispositif IoT. Bien qu'elles soient spécifiées de différentes manières pour différents services cloud, ces définitions de politiques décrivent les droits d'accès pour différents canaux et entités de communication. Par exemple, une simple politique de droit d'accès AWS IoT peut utiliser un format JSON pour indiquer qu'un dispositif IoT avec un nom d'« objet » particulier dans le registre des dispositifs AWS IoT peut se connecter et publier des messages uniquement sur un canal avec le même nom d'objet associé (Liste 1).

Copier
{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action":["iot:Publish"],
        "Resource": ["arn:aws:iot:us-east-1:123456789012:topic/${iot:Connection.Thing.ThingName}"]
      },
      {
        "Effect": "Allow",
        "Action": ["iot:Connect"],
        "Resource": ["arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}"]
      }
    ]
}

Liste 1 : Les développeurs utilisent un format JSON pour décrire les politiques de droits d'accès AWS IoT pour leurs dispositifs IoT. (Source du code : AWS)

Kits de développement prêts pour le cloud

Bien que les fournisseurs de services cloud offrent des spécifications détaillées de ces formats et procédures, les forums de support des fournisseurs croulent généralement sous les questions des développeurs qui sont bloqués par un petit détail vital qui empêche l'authentification et la gestion de l'accès. Pire encore, du point de vue de la sécurité, une mauvaise utilisation involontaire de l'attestation ou une définition incomplète des politiques d'accès peut rendre les dispositifs IoT, les réseaux et les applications vulnérables aux attaques. La disponibilité de cartes de développement prêtes à l'emploi et de progiciels associés permet aux développeurs de naviguer rapidement parmi ces procédures de connexion, en utilisant des exemples fournis par les fournisseurs pour se connecter rapidement aux clouds IoT. Par exemple, le kit IoT ESP32-Azure d'Espressif Systems et le kit de développement IoT AZ3166 de Seeed Technology incluent des cartes certifiées Azure conçues la connexion aisée au cloud Microsoft.

Microsoft propose des démonstrations détaillées complètes, y compris l'authentification et les identifiants d'accès pour les kits de développement pris en charge. Avec la carte AZ3166, par exemple, les développeurs appuient sur des boutons sur la carte pour initier la connexion avec leur réseau Wi-Fi local. Une fois connectés, ils peuvent utiliser Azure IoT Device Workbench contenu dans le pack d'extension Azure IoT Tools pour Microsoft Visual Studio Code pour développer, déboguer et interagir avec Azure IoT Hub. En utilisant cet ensemble d'outils et ses exemples de codes, les développeurs créent un objet pour le dispositif IoT dans Azure IoT Hub et utilisent un fichier fourni pour provisionner le registre d'identité associé avec les identifiants et d'autres métadonnées requises pour connecter la carte IoT à Azure IoT Hub (Figure 3).

Image d'un exemple de code et des identifiants fournis dans Microsoft Azure IoT Device WorkbenchFigure 3 : Les exemples de code et les identifiants fournis dans Microsoft Azure IoT Device Workbench aident les développeurs à compléter le provisionnement pour la connexion du kit de développement IoT AZ3166 de Seeed Technology à Azure IoT Hub. (Source de l'image : Microsoft Azure)

Azure IoT Device Workbench fournit un logiciel de support et des métadonnées supplémentaires qui permettent aux développeurs de charger rapidement la carte AZ3166 avec un code d'exemple et de commencer à transmettre les mesures du capteur de température et d'humidité de la carte vers Azure IoT Hub.

Les étapes nécessaires à la création d'une représentation pour le dispositif IoT physique dans le cloud IoT et pour le provisionnement du registre associé sont nécessaires uniquement pour connecter les dispositifs au cloud IoT. Cependant, pour tirer parti des services cloud, Azure IoT Hub a besoin d'une politique de droits d'accès. Pour surveiller les messages provenant du capteur AZ3166 entre le dispositif et le cloud, les développeurs peuvent simplement utiliser l'écran des politiques d'accès partagé Azure pour sélectionner une politique prédéfinie, conçue pour activer rapidement les droits d'accès requis (Figure 4).

Image des services cloud Azure avec les données des capteurs du kit de développement IoT AZ3166 de Seeed Technology (cliquez pour agrandir)Figure 4 : Les développeurs peuvent utiliser des politiques prédéfinies pour autoriser facilement l'utilisation des services cloud Azure avec les données des capteurs du kit de développement IoT AZ3166 de Seeed Technology. (Source de l'image : Microsoft Azure)

Lorsqu'ils travaillent avec AWS IoT, les développeurs peuvent se tourner vers des kits de développement tels que le kit Zero Touch Provisioning AT88CKECC-AWS-XSTK-B de Microchip Technology et le logiciel d'accompagnement pour évaluer rapidement la connectivité cloud. Cette version mise à jour d'un ancien kit Zero Touch Provisioning de Microchip est fournie pré-chargée avec des identifiants d'authentification. En utilisant les scripts supplémentaires fournis avec le kit, les développeurs peuvent rapidement connecter la carte à AWS IoT sans avoir à gérer des clés privées et des certificats (voir l'article relatif à l'adoption de l'approche Zero-Touch pour verrouiller en toute sécurité un dispositif IoT).

D'autres kits de développement, notamment le kit cloud RX65N RTK5RX65N0S01000BE de Renesas et le kit AWS IoT KITXMC48IOTAWSWIFITOBO1 d'Infineon Technologies, étendent la prise en charge de la connectivité AWS IoT avec le support pour le développement rapide d'applications basées sur Amazon FreeRTOS. AWS fournit des instructions détaillées pour l'enregistrement des cartes, la création d'identifiants d'authentification et le chargement des politiques JSON fournies, nécessaires pour la connexion à AWS IoT et l'utilisation des services AWS.

Simplifier le provisionnement pour les déploiements IoT à grande échelle

Les kits de développement tels que ceux mentionnés précédemment servent de plateformes efficaces tant pour le prototypage rapide d'applications IoT que pour l'exploration des exigences de connexion aux services cloud IoT. En pratique, cependant, les développeurs doivent généralement se tourner vers des approches plus avancées, conçues pour simplifier le provisionnement des dispositifs IoT dans les applications du monde réel. Azure IoT et AWS IoT prennent tous les deux en charge une grande variété de méthodes qui permettent un provisionnement plus automatisé de dispositifs individuels ou d'un grand nombre de dispositifs IoT dans un déploiement à grande échelle.

Avec AWS IoT, par exemple, les développeurs peuvent utiliser une méthode d'amorçage pour le provisionnement des certificats. Ici, le produit intelligent est fourni avec un certificat d'amorçage associé aux droits d'accès minimaux requis pour demander et obtenir un nouveau certificat (Figure 5).

Schéma d'AWS IoT prenant en charge une méthode permettant de provisionner un certificat d'amorçage dans les dispositifs IoTFigure 5 : AWS IoT prend en charge une méthode permettant de provisionner un certificat d'amorçage dans les dispositifs IoT. (Source de l'image : DigiKey, d'après Amazon Web Services)

En utilisant le certificat d'amorçage, le dispositif se connecte au cloud (« 1 » dans la Figure 5), demande (« 2 ») un nouveau certificat, reçoit (« 3 ») l'URL du certificat généré par une fonction AWS Lambda sans serveur, et récupère (« 4 ») ce certificat à partir d'un stockage AWS Simple Storage Services (S3). En utilisant ce nouveau certificat, le dispositif se reconnecte ensuite à AWS IoT (« 5 ») pour poursuivre ses opérations normales.

AWS propose d'autres services cloud qui prennent en charge le provisionnement dynamique de jetons d'authentification en utilisant des ressources d'exécution comme les fonctions AWS Lambda. Par exemple, une application automobile peut s'appuyer sur une série de connexions éphémères où l'utilisation d'un jeton est à la fois plus pratique et plus sûre. Ici, une fois qu'un module AWS pour l'authentification et l'autorisation IoT a approuvé la demande de jeton, AWS Security Token Service (STS) génère un jeton à fournir aux systèmes du véhicule. Grâce à ce jeton, ces systèmes peuvent accéder aux services AWS sous réserve de validation par le service AWS Identity and Access Management (IAM) (Figure 6).

Schéma des principaux fournisseurs de services cloud prenant en charge d'autres formes d'attestationFigure 6 : Les principaux fournisseurs de services cloud prennent en charge d'autres formes d'attestation pour l'authentification, comme ce processus de génération dynamique de jetons de sécurité par AWS Security Token Service (STS). (Source de l'image : Amazon Web Services)

AWS offre une capacité similaire pour l'attribution dynamique des droits d'accès. Ici, d'autres fonctions AWS Lambda affecteraient un ensemble de politiques associées à un jeton valide (Figure 7).

Schéma des développeurs pouvant utiliser les services cloud pour mettre en œuvre l'affectation dynamique des droits d'accèsFigure 7 : Les développeurs peuvent utiliser les services cloud pour mettre en œuvre l'affectation dynamique des droits d'accès, ce qui est particulièrement utile pour les applications avec des connexions éphémères ou des opérations de courte durée. (Source de l'image : Amazon Web Services)

D'autres services cloud IoT permettent aux développeurs de gérer plus efficacement le provisionnement dans les déploiements à grande échelle. Par exemple, AWS IoT fournit des capacités de provisionnement de flotte, y compris la prise en charge pour un déploiement à plus grande échelle du type de méthode d'amorçage décrite plus haut. Le service Device Provisioning Service d'Azure IoT offre une capacité d'enregistrement de groupe qui permet de provisionner un grand nombre de dispositifs IoT qui partagent le même certificat X.509 ou le même jeton SAS.

Une responsabilité partagée en matière de sécurité

Les fournisseurs cloud IoT fournissent un certain nombre de méthodes efficaces pour renforcer la sécurité de bout en bout des applications IoT. Néanmoins, les développeurs IoT ne peuvent pas s'attendre à ce que ces méthodes puissent supporter tout le poids des exigences de sécurité pour leur application IoT particulière. En fait, les fournisseurs de services cloud définissent soigneusement leur rôle et leurs responsabilités spécifiques en matière de sécurité des applications IoT avec des modèles spécifiques tels que le modèle de responsabilité partagée d'AWS (Figure 8).

Schéma d'AWS décrivant les responsabilités partagées avec les utilisateurs cloudFigure 8 : Comme d'autres fournisseurs cloud leaders, AWS décrit les responsabilités qu'il partage avec les utilisateurs cloud pour protéger l'infrastructure cloud d'une part et les applications des clients d'autre part. (Source de l'image : Amazon Web Services)

AWS et Microsoft Azure fournissent chacun des documents sur les responsabilités partagées qui décrivent et expliquent le rôle du fournisseur et celui du client dans la sécurisation des ressources, des données et des applications. Dans sa documentation, Microsoft offre également un aperçu de certaines relations entre la sécurité partagée et les exigences de conformité. Au bout du compte, les fournisseurs cloud restent responsables de la sécurité du cloud, tandis que les clients restent responsables des applications, des données et des ressources utilisées dans le cloud.

Conclusion

Les applications IoT dépendent de couches de sécurité établies à partir de mécanismes matériels de cryptographie et de stockage sécurisé des clés. Comme pour tout produit connecté, les menaces de sécurité peuvent se manifester sous la forme de toutes sortes d'interactions lorsque les dispositifs IoT se connectent à des services cloud. Pour se protéger et protéger leurs clients, les fournisseurs cloud IoT imposent des exigences spécifiques en matière d'authentification et de gestion des droits d'accès. Bien que les fournisseurs offrent une documentation détaillée sur ces exigences et les spécifications associées, les développeurs peuvent constater que leurs efforts pour mettre en œuvre une connectivité sécurisée laissent parfois les ressources exposées ou, à l'inverse, inaccessibles. Grâce aux cartes de développement et aux logiciels associés, les développeurs peuvent se connecter rapidement aux services cloud et prototyper rapidement des applications IoT avec une sécurité de bout en bout.

DigiKey logo

Avertissement : les opinions, convictions et points de vue exprimés par les divers auteurs et/ou participants au forum sur ce site Web ne reflètent pas nécessairement ceux de DigiKey ni les politiques officielles de la société.

À propos de l'auteur

Image of Stephen Evanczuk

Stephen Evanczuk

Stephen Evanczuk affiche plus de 20 ans d'expérience dans la rédaction de contenu pour et sur l'industrie électronique, couvrant un large éventail de sujets, notamment le matériel, les logiciels, les systèmes et les applications, y compris l'IoT. Il a obtenu son doctorat (Ph.D.) en neurosciences sur les réseaux neuronaux et a travaillé dans l'industrie aérospatiale sur les systèmes sécurisés massivement distribués et les méthodes d'accélération par algorithmes. Actuellement, lorsqu'il n'écrit pas d'articles techniques, il travaille sur l'application de l'apprentissage approfondi pour les systèmes de reconnaissance et de recommandation.

À propos de l'éditeur

Rédacteurs nord-américains de DigiKey