AWS IoT Greengrass Version 1 est entré dans la phase de durée de vie prolongée le 30 juin 2023. Pour plus d'informations, consultez la politique de AWS IoT Greengrass V1 maintenance. Après cette date, AWS IoT Greengrass V1 ne publiera pas de mises à jour fournissant des fonctionnalités, des améliorations, des corrections de bogues ou des correctifs de sécurité. Les appareils qui fonctionnent AWS IoT Greengrass V1 sous tension ne seront pas perturbés et continueront à fonctionner et à se connecter au cloud. Nous vous recommandons vivement de migrer vers AWS IoT Greengrass Version 2, qui ajoute de nouvelles fonctionnalités importantes et prend en charge des plateformes supplémentaires.
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Vue d'ensemble de la AWS IoT Greengrass sécurité
AWS IoT Greengrass utilise des certificats X.509, des AWS IoT politiques, des politiques et des rôles IAM pour sécuriser les applications qui s'exécutent sur les appareils de votre environnement Greengrass local.
Le schéma suivant montre les composants du modèle AWS IoT Greengrass de sécurité :
- A - Rôle de service Greengrass
-
Rôle IAM créé par le client et assumé AWS IoT Greengrass lors de l'accès à vos AWS ressources depuis AWS IoT Core AWS Lambda, et à d'autres services. AWS Pour plus d’informations, consultez Rôle de service Greengrass.
- B - Certificat de l'appareil noyau
-
Un certificat X.509 utilisé pour authentifier un noyau Greengrass avec et. AWS IoT Core AWS IoT Greengrass Pour plus d’informations, consultez Authentification et autorisation d'appareil pour AWS IoT Greengrass.
- C - Certificat d'appareil
-
Certificat X.509 utilisé pour authentifier un appareil client, également appelé appareil connecté, avec AWS IoT Core et. AWS IoT Greengrass Pour plus d’informations, consultez Authentification et autorisation d'appareil pour AWS IoT Greengrass.
- D - Rôle de groupe
-
Rôle IAM créé par le client AWS IoT Greengrass lorsqu'il appelle des AWS services à partir d'un noyau Greengrass.
Vous utilisez ce rôle pour spécifier les autorisations d'accès dont vos fonctions et connecteurs Lambda définis par l'utilisateur ont besoin pour AWS accéder à des services, tels que DynamoDB. Vous l'utilisez également pour autoriser l'exportation AWS IoT Greengrass des flux du gestionnaire de flux vers AWS des services et l'écriture dans CloudWatch Logs. Pour plus d’informations, consultez Rôle de groupe Greengrass.
Note
AWS IoT Greengrass n'utilise pas le rôle d'exécution Lambda spécifié dans AWS Lambda pour la version cloud d'une fonction Lambda.
- E - Certificat de serveur MQTT
-
Certificat utilisé pour l'authentification mutuelle TLS (Transport Layer Security) entre un appareil principal de Greengrass et des appareils clients du groupe Greengrass. Le certificat est signé par le certificat CA du groupe, qui est stocké dans le AWS Cloud.
Flux de connexion des appareils
Cette section décrit comment les appareils clients se connectent au AWS IoT Greengrass service et aux appareils principaux de Greengrass. Les appareils clients sont AWS IoT Core des appareils enregistrés qui appartiennent au même groupe Greengrass que le périphérique principal.
-
Un appareil Greengrass Core utilise son certificat d'appareil, sa clé privée et le certificat CA AWS IoT Core racine pour se connecter au AWS IoT Greengrass service. Sur l'appareil principal, l'objet
cryptodu fichier de configuration spécifie le chemin d'accès au fichier pour ces éléments. -
L'appareil noyau Greengrass télécharge les informations d'adhésion au groupe à partir du service AWS IoT Greengrass .
-
Lorsqu'un déploiement est effectué sur l’appareil noyau Greengrass, le gestionnaire de certificats de l'appareil (DCM) s’occupe de la gestion des certificats de serveur local pour l’appareil noyau Greengrass.
-
Un appareil client se connecte au AWS IoT Greengrass service à l'aide de son certificat de périphérique, de sa clé privée et du certificat de l'autorité de certification AWS IoT Core racine. Une fois la connexion établie, l'appareil client utilise le service Greengrass Discovery pour trouver l'adresse IP de son appareil principal Greengrass. L'appareil client télécharge également le certificat CA du groupe, qui est utilisé pour l'authentification mutuelle TLS avec le périphérique principal Greengrass.
-
Un appareil client tente de se connecter au périphérique principal de Greengrass en transmettant son certificat d'appareil et son identifiant client. Si l'ID client correspond au nom de l'appareil client et que le certificat est valide (il fait partie du groupe Greengrass), la connexion est établie. Dans le cas contraire, la connexion est arrêtée.
La AWS IoT politique relative aux appareils clients doit greengrass:Discover autoriser les appareils clients à découvrir les informations de connectivité relatives au cœur. Pour de plus amples informations sur cette instruction de stratégie, veuillez consulter Acvery Service Service Service.
Configuration de AWS IoT Greengrass la sécurité
Pour configurer la sécurité de votre application Greengrass :
-
Créez n'importe AWS IoT Core quel objet pour votre appareil Greengrass principal.
-
Générez une paire de clés et un certificat d’appareil pour votre appareil noyau Greengrass.
-
Créez et attachez une stratégie AWS IoT au certificat d'appareil. Le certificat et la politique permettent à l'appareil principal de Greengrass d'accéder aux services AWS IoT Core et AWS IoT Greengrass d'accéder à ces services. Pour plus d’informations, consultez Stratégie AWS IoT minimale pour l'appareil principal (noyau).
Note
L'utilisation de variables de politique d'objets (
iot:Connection.Thing.) dans la AWS IoT politique d'un appareil principal n'est pas prise en charge. Le noyau utilise le même certificat d'appareil pour établir plusieurs connexions AWS IoT Core , mais l'ID client d'une connexion peut ne pas correspondre exactement au nom de l'objet principal.* -
Créez un rôle de service Greengrass. Ce rôle IAM autorise l'accès AWS IoT Greengrass aux ressources d'autres AWS services en votre nom. Cela permet d' AWS IoT Greengrass effectuer des tâches essentielles, telles que la récupération des AWS Lambda fonctions et la gestion des ombres de l'appareil.
Vous pouvez utiliser le même rôle de service entre Région AWS s, mais il doit être associé Compte AWS au vôtre partout Région AWS où vous l'utilisez AWS IoT Greengrass.
-
(Facultatif) Créez un rôle de groupe Greengrass. Ce rôle IAM autorise les fonctions et connecteurs Lambda exécutés sur un noyau Greengrass à appeler des services. AWS Par exemple, le connecteur Kinesis Firehose nécessite une autorisation pour écrire des enregistrements dans un flux de diffusion Amazon Data Firehose.
Vous ne pouvez attacher qu'un seul rôle à un groupe Greengrass.
-
Créez un AWS IoT Core objet pour chaque appareil qui se connecte à votre Greengrass Core.
Note
Vous pouvez également utiliser des AWS IoT Core objets et des certificats existants.
-
Créez des certificats, des paires de clés et des AWS IoT politiques pour chaque appareil qui se connecte à votre Greengrass Core.
AWS IoT Greengrass principes de sécurité fondamentaux
Le noyau de Greengrass utilise les principes de sécurité suivants : AWS IoT client, serveur MQTT local et gestionnaire de secrets local. La configuration de ces mandataires est stockée dans l'objet crypto situé dans le fichier de configuration config.json. Pour plus d’informations, consultez Fichier de configuration de AWS IoT Greengrass Core.
Cette configuration inclut le chemin d'accès à la clé privée utilisée par le composant principal pour l'authentification et le chiffrement. AWS IoT Greengrass prend en charge deux modes de clé privée : le stockage basé sur le matériel ou le stockage basé sur le système de fichiers (par défaut). Pour plus d'informations sur le stockage des clés sur les modules de sécurité matérielle, consultez Intégration de sécurité matérielle.
- AWS IoT Client
-
Le AWS IoT client (client IoT) gère la communication sur Internet entre le cœur de Greengrass et. AWS IoT Core AWS IoT Greengrass utilise des certificats X.509 avec des clés publiques et privées pour l'authentification mutuelle lors de l'établissement de connexions TLS pour cette communication. Pour de plus amples informations, veuillez consulter Certificats X.509 et AWS IoT Core dans le Manuel du développeur AWS IoT Core .
Le client IoT prend en charge les certificats et les clés RSA et EC. Les chemins du certificat et de la clé privée sont spécifiés pour le mandataire
IoTCertificatedansconfig.json. - Serveur MQTT
-
Le serveur MQTT local gère les communications sur le réseau local entre le cœur de Greengrass et les appareils clients du groupe. AWS IoT Greengrass utilise des certificats X.509 avec des clés publiques et privées pour l'authentification mutuelle lors de l'établissement de connexions TLS pour cette communication.
Par défaut, AWS IoT Greengrass génère une clé privée RSA pour vous. Pour configurer l’appareil principal (core) pour utiliser une autre clé privée, vous devez fournir le chemin de la clé du mandataire
MQTTServerCertificatedansconfig.json. Vous êtes responsable de la rotation d'une clé fournie par le client.Prise en charge des clés privées Clé RSA Clé EC Type de clé Pris en charge Pris en charge Paramètres clés 2 048 bits de longueur minimale Courbe NIST P-256 ou NIST P-384 Format de disque PKCS#1, PKCS#8 SECG1, PKCS#8 Version GGC minimale Utilisez la clé RSA par défaut : 1.0
Spécifiez une clé RSA : 1.7
Spécifiez une clé EC : 1.9
C’est la configuration de la clé privée qui détermine les processus connexes. Pour obtenir la liste des suites de chiffrement que l’appareil principal (core) Greengrass prend en charge en tant que serveur, consultez Prise en charge des suites de chiffrement TLS.
- Si aucune clé privée n’est spécifiée (par défaut)
-
AWS IoT Greengrass fait pivoter la clé en fonction de vos paramètres de rotation.
L’appareil principal (core) génère une clé RSA, qui est utilisée pour générer le certificat.
Le certificat du serveur MQTT possède une clé publique RSA et une signature RSA SHA-256.
- Si une clé privée RSA est spécifiée (nécessite GGC v1.7 ou version ultérieure)
-
Vous êtes responsable de la rotation de la clé.
L’appareil principal (core) utilise la clé spécifiée pour générer le certificat.
La clé RSA doit avoir une longueur minimale de 2 048 bits.
Le certificat du serveur MQTT possède une clé publique RSA et une signature RSA SHA-256.
- Si une clé privée EC est spécifiée (nécessite GGC v1.9 ou version ultérieure)
-
Vous êtes responsable de la rotation de la clé.
L’appareil principal (core) utilise la clé spécifiée pour générer le certificat.
La clé privée EC doit utiliser une courbe NIST P-256 ou NIST P-384.
Le certificat du serveur MQTT possède une clé publique EC et une signature RSA SHA-256.
Le certificat du serveur MQTT présenté par l’appareil principal (core) dispose d'une signature RSA SHA-256, quel que soit le type de clé. Pour cette raison, les clients doivent prendre en charge la validation de certificat RSA SHA-256 pour établir une connexion sécurisée avec l’appareil principal (core).
- Secrets Manager
-
Le gestionnaire de secrets locaux gère en toute sécurité les copies locales des secrets que vous créez dans AWS Secrets Manager. Il utilise une clé privée pour sécuriser la clé de données qui est utilisée pour chiffrer les secrets. Pour plus d’informations, consultez Déployer des secrets sur AWS IoT Greengrass Core.
Par défaut, la clé privée du client IoT est utilisée, mais vous pouvez spécifier une autre clé privée pour le mandataire
SecretsManagerdansconfig.json. Seul le type de clé RSA est pris en charge. Pour plus d’informations, consultez Spécifier la clé privée pour chiffrer un secret.Note
Actuellement, ne AWS IoT Greengrass prend en charge que le mécanisme de remplissage PKCS #1 v1.5
pour le chiffrement et le déchiffrement des secrets locaux lors de l'utilisation de clés privées matérielles. Si vous suivez les instructions fournies par le fournisseur pour générer manuellement des clés privées matérielles, assurez-vous de choisir PKCS #1 v1.5. AWS IoT Greengrass ne prend pas en charge le rembourrage asymétrique optimal (OAEP). Prise en charge des clés privées Clé RSA Clé EC Type de clé Pris en charge Non pris en charge Paramètres clés 2 048 bits de longueur minimale Ne s’applique pas Format de disque PKCS#1, PKCS#8 Ne s’applique pas Version GGC minimale 1,7 Ne s’applique pas
Abonnements gérés dans le flux de travail de messagerie MQTT
AWS IoT Greengrass utilise une table d'abonnement pour définir comment les messages MQTT peuvent être échangés entre les appareils clients, les fonctions et les connecteurs d'un groupe Greengrass, et AWS IoT Core avec ou avec le service fantôme local. Chaque abonnement spécifie une source, une cible et un sujet (ou sujet) MQTT sur lesquels les messages sont envoyés ou reçus. AWS IoT Greengrass autorise l'envoi de messages d'une source vers une cible uniquement si un abonnement correspondant est défini.
Un abonnement définit le flux de messages dans une seule direction, de la source vers la cible. Pour prendre en charge l’échange bidirectionnel de messages, vous devez créer deux abonnements, une pour chaque direction.
Prise en charge des suites de chiffrement TLS
AWS IoT Greengrass utilise le modèle de sécurité AWS IoT Core des transports pour chiffrer les communications avec le cloud à l'aide de suites de chiffrement
Suites de chiffrement prises en charge pour les communications réseau locales
En revanche AWS IoT Core, le AWS IoT Greengrass cœur prend en charge les suites de chiffrement TLS du réseau local suivantes pour les algorithmes de signature de certificats. Toutes ces suites de chiffrement sont prises en charge lorsque des clés privées sont stockées sur le système de fichiers. Un sous-ensemble est pris en charge lorsque l’appareil principal (core) est configuré pour utiliser des modules de sécurité matériels (HSM). Pour plus d’informations, consultez AWS IoT Greengrass principes de sécurité fondamentaux et Intégration de sécurité matérielle. Le tableau indique également la version minimale du logiciel AWS IoT Greengrass Core requise pour le support.
| Chiffrement | Prise en charge de HSM | Version GGC minimale | |
|---|---|---|---|
| TLSv1.2 | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | Pris en charge | 1.0 |
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | Pris en charge | 1.0 | |
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | Pris en charge | 1.0 | |
| TLS_RSA_WITH_AES_128_CBC_SHA | Non pris en charge | 1.0 | |
| TLS_RSA_WITH_AES_128_GCM_SHA256 | Non pris en charge | 1.0 | |
| TLS_RSA_WITH_AES_256_CBC_SHA | Non pris en charge | 1.0 | |
| TLS_RSA_WITH_AES_256_GCM_SHA384 | Non pris en charge | 1.0 | |
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | Pris en charge | 1.9 | |
| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | Pris en charge | 1.9 | |
| TLS v1.1 | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | Pris en charge | 1.0 |
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | Pris en charge | 1.0 | |
| TLS_RSA_WITH_AES_128_CBC_SHA | Non pris en charge | 1.0 | |
| TLS_RSA_WITH_AES_256_CBC_SHA | Non pris en charge | 1.0 | |
| TLS v1.0 | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA | Pris en charge | 1.0 |
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA | Pris en charge | 1.0 | |
| TLS_RSA_WITH_AES_128_CBC_SHA | Non pris en charge | 1.0 | |
| TLS_RSA_WITH_AES_256_CBC_SHA | Non pris en charge | 1.0 |
