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. # Protection des données dans AWS IoT Core Le [modèle de responsabilité AWS partagée](https://aws.amazon.com/compliance/shared-responsibility-model/) de s'applique à la protection des données dans AWS IoT Core. Comme décrit dans ce modèle, AWS est chargé de protéger l'infrastructure mondiale qui gère tous les AWS Cloud. La gestion du contrôle de votre contenu hébergé sur cette infrastructure relève de votre responsabilité. Vous êtes également responsable des tâches de configuration et de gestion de la sécurité des Services AWS que vous utilisez. Pour plus d’informations sur la confidentialité des données, consultez [Questions fréquentes (FAQ) sur la confidentialité des données](https://aws.amazon.com/compliance/data-privacy-faq/). Pour en savoir plus sur la protection des données en Europe, consultez le billet de blog [Modèle de responsabilité partagée d’AWS et RGPD (Règlement général sur la protection des données)](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) sur le *Blog de sécuritéAWS *. À des fins de protection des données, nous vous recommandons de protéger les Compte AWS informations d'identification et de configurer les utilisateurs individuels avec AWS IAM Identity Center ou Gestion des identités et des accès AWS (IAM). Ainsi, chaque utilisateur se voit attribuer uniquement les autorisations nécessaires pour exécuter ses tâches. Nous vous recommandons également de sécuriser vos données comme indiqué ci-dessous : + Utilisez l’authentification multifactorielle (MFA) avec chaque compte. + SSL/TLS À utiliser pour communiquer avec AWS les ressources. Nous exigeons TLS 1.2 et recommandons TLS 1.3. + Configurez l'API et la journalisation de l'activité des utilisateurs avec AWS CloudTrail. Pour plus d'informations sur l'utilisation des CloudTrail sentiers pour capturer AWS des activités, consultez la section [Utilisation des CloudTrail sentiers](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) dans le *guide de AWS CloudTrail l'utilisateur*. + Utilisez des solutions de AWS chiffrement, ainsi que tous les contrôles de sécurité par défaut qu'ils contiennent Services AWS. + Utilisez des services de sécurité gérés avancés tels qu’Amazon Macie, qui contribuent à la découverte et à la sécurisation des données sensibles stockées dans Amazon S3. + Si vous avez besoin de modules cryptographiques validés par la norme FIPS 140-3 pour accéder AWS via une interface de ligne de commande ou une API, utilisez un point de terminaison FIPS. Pour plus d’informations sur les points de terminaison FIPS disponibles, consultez [Norme FIPS (Federal Information Processing Standard) 140-3](https://aws.amazon.com/compliance/fips/). Nous vous recommandons fortement de ne jamais placer d’informations confidentielles ou sensibles, telles que les adresses e-mail de vos clients, dans des balises ou des champs de texte libre tels que le champ **Nom**. Cela inclut lorsque vous travaillez avec AWS IoT ou d'autres Services AWS utilisateurs de la console, de l'API ou AWS SDKs. AWS CLI Toutes les données que vous entrez dans des balises ou des champs de texte de forme libre utilisés pour les noms peuvent être utilisées à des fins de facturation ou dans les journaux de diagnostic. Si vous fournissez une adresse URL à un serveur externe, nous vous recommandons fortement de ne pas inclure d’informations d’identification dans l’adresse URL permettant de valider votre demande adressée à ce serveur. Pour en savoir plus sur la protection des données, consultez le billet de blog [Modèle de responsabilité partagée AWS et RGPD](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) sur le *Blog sur la sécurité d’AWS *. AWS IoT les appareils collectent des données, les manipulent, puis les envoient à un autre service Web. Vous pouvez choisir de stocker certaines données sur votre appareil pendant une courte durée. Il vous incombe d'assurer la protection de ces données au repos. Lorsque votre appareil envoie des données à AWS IoT, il le fait via une connexion TLS, comme indiqué plus loin dans cette section. AWS IoT les appareils peuvent envoyer des données à n'importe quel AWS service. Pour plus d'informations sur la sécurité des données de chaque service, consultez la documentation de ce service. AWS IoT peut être configuré pour écrire des journaux dans les CloudWatch journaux et enregistrer les appels d' AWS IoT API dans AWS CloudTrail. Pour plus d'informations sur la sécurité des données pour ces services, consultez [Authentification et contrôle d'accès pour Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/auth-and-access-control-cw.html) et [Chiffrement des fichiers CloudTrail journaux avec des clés AWS KMS gérées](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/encrypting-cloudtrail-log-files-with-aws-kms.html). ## Chiffrement des données dans AWS IoT Par défaut, toutes les AWS IoT données en transit et au repos sont cryptées. [Les données en transit sont chiffrées à l'aide du protocole TLS](transport-security.md), tandis que les données au repos sont chiffrées à l'aide de clés AWS détenues. AWS IoT prend en charge la gestion par le client AWS KMS keys (clés KMS) à partir du service de gestion des AWS clés (AWS KMS). Toutefois, Device Advisor et AWS IoT Wireless utilisent uniquement un Clé détenue par AWS pour chiffrer les données des clients. # Sûreté des transports dans AWS IoT Core TLS (Transport Layer Security) est un protocole cryptographique conçu pour sécuriser les communications sur un réseau informatique. La passerelle pour AWS IoT Core appareils oblige les clients à chiffrer toutes les communications pendant le transport en utilisant le protocole TLS pour les connexions entre les appareils et la passerelle. Le protocole TLS est utilisé pour garantir la confidentialité des protocoles d'application (MQTT, HTTP et WebSocket) pris en charge par. AWS IoT Core La prise en charge de TLS est disponible dans un certain nombre de langages de programmation et de systèmes d'exploitation. Les données AWS qu'elles contiennent sont cryptées par le AWS service spécifique. Pour plus d'informations sur le chiffrement des données sur d'autres AWS services, consultez la documentation de sécurité de ce service. **Topics** + [Protocoles TLS](#tls-ssl-policy) + [Stratégies de sécurité](#tls-policy-table) + [Remarques importantes pour la sécurité des transports dans AWS IoT Core](#tls-ssl-core) + [Sécurité du transport pour les appareils sans fil LoRa WAN](#tls-lorawan) ## Protocoles TLS AWS IoT Core prend en charge les versions suivantes du protocole TLS : + TLS 1.3 + TLS 1.2 Avec AWS IoT Core, vous pouvez configurer les paramètres TLS (pour [TLS 1.2 et TLS](https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.2) [1.3](https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.3)) dans les configurations de domaine. Pour de plus amples informations, veuillez consulter [Configuration des paramètres TLS dans les configurations de domaine](iot-endpoints-tls-config.md). ## Stratégies de sécurité Une stratégie de sécurité est une combinaison de protocoles TLS et de leurs chiffrements qui déterminent quels protocoles et chiffrements sont pris en charge lors des négociations TLS entre un client et un serveur. Vous pouvez configurer vos appareils pour utiliser des politiques de sécurité prédéfinies en fonction de vos besoins. Notez que les politiques de sécurité personnalisées AWS IoT Core ne sont pas prises en charge. Vous pouvez choisir l'une des politiques de sécurité prédéfinies pour vos appareils lorsque vous les connectez à AWS IoT Core. Les noms des politiques de sécurité prédéfinies les plus récentes AWS IoT Core incluent des informations de version basées sur l'année et le mois de leur publication. La stratégie de sécurité prédéfinie par défaut est `IoTSecurityPolicy_TLS13_1_2_2022_10`. Pour définir une politique de sécurité, vous pouvez utiliser la AWS IoT console ou le AWS CLI. Pour de plus amples informations, veuillez consulter [Configuration des paramètres TLS dans les configurations de domaine](iot-endpoints-tls-config.md). Le tableau suivant décrit les politiques de sécurité prédéfinies les plus récentes que AWS IoT Core prend en charge. Le `IotSecurityPolicy_` a été supprimé des noms de stratégie dans la ligne d'en-tête afin qu'ils correspondent. | **Politique de sécurité** | TLS13\$11\$13\$12022\$110 | TLS13\$11\$12\$12022\$110 | TLS12\$11\$12\$12022\$110 | TLS12\$11\$10\$12016\$101\$1 | TLS12\$11\$10\$12015\$101\$1 | | --- | --- | --- | --- | --- | --- | | Ports TCP | 443/8443/8883 | 443/8443/8883 | 443/8443/8883 | 443 | 8443/8883 | 443 | 8443/8883 | | Protocoles TLS | | TLS 1.2 | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | TLS 1.3 | ✓ | ✓ | | | | | | | Chiffrements TLS | | TLS\$1AES\$1128\$1GCM\$1 SHA256 | ✓ | ✓ | | | | | | | TLS\$1AES\$1256\$1GCM\$1 SHA384 | ✓ | ✓ | | | | | | | TLS\$1 \$1 \$1 CHACHA20 POLY1305 SHA256 | ✓ | ✓ | | | | | | | ECDHE-RSA- -GCM- AES128 SHA256 | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | ECDHE-RSA- - AES128 SHA256 | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | ECDHE-RSA- -SHA AES128 | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | ECDHE-RSA- -GCM- AES256 SHA384 | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | ECDHE-RSA- - AES256 SHA384 | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | ECDHE-RSA- -SHA AES256 | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | AES128-GCM- SHA256 | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | AES128-SHA256 | | ✓ | ✓ | ✓ | | ✓ | ✓ | | AES128-SHA | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | AES256-GCM- SHA384 | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | AES256-SHA256 | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | AES256-SHA | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | DHE-RSA- -SHA AES256 | | | | | | ✓ | ✓ | | ECDHE-ECDSA- -GCM- AES128 SHA256 | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | ECDHE-ECDSA- - AES128 SHA256 | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | ECDHE-ECDSA- -SHA AES128 | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | ECDHE-ECDSA- -GCM- AES256 SHA384 | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | ECDHE-ECDSA- - AES256 SHA384 | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | | ECDHE-ECDSA- -SHA AES256 | | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | **Note** `TLS12_1_0_2016_01`est uniquement disponible dans les pays suivants Régions AWS : ap-east-1, ap-northeast-2, ap-northeast-2, ap-south-1, ap-southeast-2, ca-central-1, cn-north-1, cn-northwest-1, eu-north-1, eu-west-2, eu-west-3, me-south-1, sa-east-1, us-east-1, us-east-2, -1, -2, us-west-1. us-gov-west us-gov-west `TLS12_1_0_2015_01`n'est disponible que dans les versions suivantes Régions AWS : ap-northeast-1, ap-southeast-1, eu-central-1, eu-west-1, us-east-1, us-west-2. ## Remarques importantes pour la sécurité des transports dans AWS IoT Core Pour les appareils qui se connectent AWS IoT Core via [MQTT](https://docs.aws.amazon.com//iot/latest/developerguide/mqtt.html), le protocole TLS chiffre la connexion entre les appareils et le broker, et AWS IoT Core utilise l'authentification du client TLS pour identifier les appareils. Pour plus d’informations, consultez [Authentification client](https://docs.aws.amazon.com//iot/latest/developerguide/client-authentication.html). Pour les appareils qui se connectent AWS IoT Core via [HTTP](https://docs.aws.amazon.com//iot/latest/developerguide/http.html), le protocole TLS chiffre la connexion entre les appareils et le broker, et l'authentification est déléguée à AWS Signature Version 4. Pour plus d'informations, consultez [Signature des demandes avec Signature Version 4](https://docs.aws.amazon.com//general/latest/gr/create-signed-request.html) dans *AWS Référence Générale*. Lorsque vous connectez des appareils à AWS IoT Core, l'envoi de l'[extension SNI (Server Name Indication)](https://tools.ietf.org/html/rfc3546#section-3.1) n'est pas obligatoire mais fortement recommandé. Pour utiliser des fonctionnalités telles que l'[enregistrement multi-comptes](https://docs.aws.amazon.com//iot/latest/developerguide/x509-client-certs.html#multiple-account-cert), les [domaines personnalisés](https://docs.aws.amazon.com//iot/latest/developerguide/iot-custom-endpoints-configurable-custom.html), les points de terminaison [VPC](https://docs.aws.amazon.com//iot/latest/developerguide/IoTCore-VPC.html) [et les politiques TLS configurées](https://docs.aws.amazon.com//iot/latest/developerguide/iot-endpoints-tls-config.html), vous devez utiliser l'extension SNI et fournir l'adresse complète du point de terminaison dans le champ. `host_name` Le champ `host_name` doit contenir le point de terminaison que vous invoquez. Ce point de terminaison doit être l'un des éléments suivants : + L’adresse `endpointAddress` renvoyée par `aws iot [describe-endpoint](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iot/describe-endpoint.html) --endpoint-type iot:Data-ATS` + L’adresse `domainName` renvoyée par `aws iot [describe-domain-configuration](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iot/describe-domain-configuration.html) –-domain-configuration-name "domain_configuration_name"` Les connexions tentées par des appareils dont la `host_name` valeur est incorrecte ou non valide échoueront. AWS IoT Core enregistrera les échecs CloudWatch pour le type d'authentification de l'[authentification personnalisée](https://docs.aws.amazon.com//iot/latest/developerguide/custom-authentication.html). AWS IoT Core ne prend pas en charge l'[extension SessionTicket TLS.](https://www.ietf.org/rfc/rfc5077.txt) ## Sécurité du transport pour les appareils sans fil LoRa WAN LoRaLes appareils WAN suivent les pratiques de sécurité décrites dans [LoRaWAN™ SECURITY : A White Paper for the LoRa Alliance™ par Gemalto, Actility et Semtech](https://lora-alliance.org/sites/default/files/2019-05/lorawan_security_whitepaper.pdf). Pour plus d'informations sur la sécurité du transport avec les périphériques LoRa WAN, consultez la section [Données LoRa WAN et sécurité du transport](https://docs.aws.amazon.com/iot-wireless/latest/developerguide/iot-lorawan-security.html). # Chiffrement des données dans AWS IoT La protection des données fait référence à la protection des données en transit (lors de leur trajet aller-retour AWS IoT Core) et au repos (lorsqu'elles sont stockées sur des appareils ou par d'autres AWS services). Toutes les données envoyées AWS IoT Core sont envoyées via une connexion TLS à l'aide de MQTT, HTTPS et des WebSocket protocoles, ce qui les rend sécurisées par défaut pendant le transit. AWS IoT Core collecte les données des appareils, puis les envoie à d'autres AWS services pour un traitement ultérieur. Pour plus d'informations sur le chiffrement des données dans d'autres services AWS , consultez la documentation relative à la sécurité du service concerné. Pour plus d'informations, consultez la section [Chiffrement des données au repos](encryption-at-rest.md). FreeRTOS fournit une bibliothèque PKCS\$111 qui isole le stockage des clés, en accédant aux objets cryptographiques et en gérant les sessions. Il vous incombe d'utiliser cette bibliothèque pour chiffrer les données au repos sur vos appareils. Pour plus d’informations, consultez [la bibliothèque FreeRTOS Public Key Cryptography Standard (PKCS) \$111](https://docs.aws.amazon.com/freertos/latest/userguide/security-pkcs.html). # Chiffrement des données au repos AWS IoT Core Par défaut, toutes les AWS IoT Core données au repos sont chiffrées à l'aide de clés AWS détenues. AWS IoT Core prend également en charge les clés symétriques gérées par le client à partir de AWS Key Management Service (AWS KMS). Avec les clés gérées par le client, vous pouvez créer, posséder et gérer les AWS KMS clés de votre AWS compte. AWS IoT Core utilisera vos clés KMS pour chiffrer vos données au repos. Vous avez le contrôle total de ces clés KMS, y compris la création et la gestion de leurs politiques clés. Vous pouvez également configurer des politiques IAM pour les rôles qui accèdent AWS KMS afin de contrôler les autorisations associées à ces clés. ## AWS clés possédées AWS les clés détenues sont un ensemble de clés KMS qu'un AWS service possède et gère pour une utilisation dans plusieurs AWS comptes. AWS les services peuvent utiliser des clés AWS détenues pour protéger vos données. Par défaut, AWS IoT Core chiffre les données au repos à l'aide de clés AWS détenues. Ces clés sont gérées par le service. Vous ne pouvez pas afficher, gérer ou utiliser les clés que vous AWS possédez. Cependant, vous n'avez aucune action à effectuer pour protéger ces clés. Pour plus d'informations sur les clés AWS détenues, consultez la section [clés AWS détenues](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-key) dans le *Guide du AWS Key Management Service développeur*. ## Clés gérées par le client Les clés gérées par le client sont des clés KMS de votre AWS compte que vous créez, détenez et gérez. Vous avez le contrôle total de ces AWS KMS clés, y compris la création et la gestion de leurs politiques clés. Vous pouvez également configurer des politiques IAM pour les rôles qui accèdent AWS KMS afin de contrôler les autorisations associées à ces clés. Vous pouvez configurer AWS IoT Core l'utilisation de clés KMS gérées par le client pour chiffrer vos données. Pour plus d’informations sur les clés gérées par le client, consultez [Clés gérées par le client](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) dans le *Guide du développeur AWS Key Management Service *. Pour activer la gestion des clés par le client AWS IoT Core, procédez comme suit : **Topics** + [Étape 1 : Créer une clé gérée par le client](#encryption-at-rest-cmk-create) + [Étape 2 : créer un rôle IAM pour accorder des AWS IoT Core autorisations d'utilisation de la clé KMS](#create-an-iam-role) + [Étape 3 : activer l'option de gestion des clés par le client AWS IoT Core](#opt-in-customer-managed-keys) + [Étape 4 : Autorisations supplémentaires requises pour les opérations AWS IoT Core du plan de contrôle](#cmk-control-plane-permissions) + [Étape 5 : Gestion des clés](#understanding-key-health) + [Étape 6 : Surveillance de l'état de santé des clés](#health-status-monitoring) ### Étape 1 : Créer une clé gérée par le client Vous pouvez créer une clé symétrique gérée par le client à l'aide de la AWS KMS console ou des commandes de la AWS KMS CLI. Le `keySpec` must `SYMMETRIC_DEFAULT` et le `keyUsage` must be`ENCRYPT_DECRYPT`. **Note** AWS IoT Core ne prend en charge que AWS KMS les `SYMMETRIC_DEFAULT` clés dotées de spécifications et d'utilisation des `ENCRYPT_DECRYPT` clés pour les clés gérées par le client. Voici un exemple de AWS CLI commande pour créer une clé KMS qui peut être utilisée AWS IoT Core pour les clés gérées par le client. ``` aws kms create-key --key-spec SYMMETRIC_DEFAULT --key-usage ENCRYPT_DECRYPT --region us-west-2 ``` Voici un exemple de sortie de la commande. ``` { "KeyMetadata": { "AWSAccountId": "111122223333", "KeyId": "1234abcd-12ab-34cd-56ef-1234567890ab", "Arn": "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab", "CreationDate": "2024-09-19T11:45:23.982000-07:00", "Enabled": true, "Description": "", "KeyUsage": "ENCRYPT_DECRYPT", "KeyState": "Enabled", "Origin": "AWS_KMS", "KeyManager": "CUSTOMER", "CustomerMasterKeySpec": "SYMMETRIC_DEFAULT", "KeySpec": "SYMMETRIC_DEFAULT", "EncryptionAlgorithms": [ "SYMMETRIC_DEFAULT" ], "MultiRegion": false } } ``` Pour plus d'informations, consultez la section [Création d'une clé symétrique gérée par le client](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk) dans le *Guide du AWS Key Management Service développeur*. #### Stratégie de clé Lorsque vous créez une clé gérée par le client, vous pouvez définir une politique clé. Les stratégies de clés contrôlent l’accès à votre clé gérée par le client. Chaque clé gérée par le client doit avoir exactement une stratégie de clé, qui contient des instructions qui déterminent les personnes pouvant utiliser la clé et comment elles peuvent l’utiliser. Pour plus d'informations, consultez [la section Politiques clés](https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html) du *Guide du AWS Key Management Service développeur*. AWS IoT Core utilise un rôle IAM dans votre compte pour accéder à votre clé gérée par le client. Si vous utilisez une politique de clé personnalisée, assurez-vous que le rôle IAM créé sur cette clé possède les autorisations suivantes : + `kms:DescribeKey` + `kms:Decrypt` + `kms:Encrypt` + `kms:GenerateDataKeyWithoutPlaintext` + `kms:ReEncryptTo` + `kms:ReEncryptFrom` ### Étape 2 : créer un rôle IAM pour accorder des AWS IoT Core autorisations d'utilisation de la clé KMS AWS IoT Core Pour utiliser la clé KMS que vous avez créée pour chiffrer vos données au repos, vous devez également créer un rôle IAM dans votre compte, qui AWS IoT Core peut supposer accéder à la clé KMS. Le rôle doit avoir la politique de confiance suivante pour AWS IoT Core pouvoir assumer le rôle. ``` { "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Principal": { "Service": "iot.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "111122223333" }, "ArnLike": { "aws:SourceArn": "arn:aws:iot:us-west-2:111122223333:*" } } } } ``` Assurez-vous que les politiques IAM associées au rôle IAM disposent des autorisations suivantes sur la clé KMS : + `kms:DescribeKey` + `kms:Decrypt` + `kms:Encrypt` + `kms:GenerateDataKeyWithoutPlaintext` + `kms:ReEncryptTo` + `kms:ReEncryptFrom` Voici un exemple de politique IAM avec les autorisations requises pour les clés gérées par le client. ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowIoTToAccessKMSResource", "Effect": "Allow", "Action": [ "kms:DescribeKey", "kms:Decrypt", "kms:Encrypt", "kms:ReEncryptTo", "kms:ReEncryptFrom", "kms:GenerateDataKeyWithoutPlaintext" ], "Resource": [ "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab" ], "Condition": { "StringEquals": { "kms:EncryptionContext:aws-crypto-ec:vendor": "iot.amazonaws.com" } } } ] } ``` Pour plus d'informations, consultez la section [Créer un rôle pour déléguer des autorisations à un utilisateur IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user.html) dans le *Guide de l'Gestion des identités et des accès AWS utilisateur*. ### Étape 3 : activer l'option de gestion des clés par le client AWS IoT Core Après avoir effectué toutes les étapes précédentes, exécutez la commande `update-encryption-configuration` CLI pour vous inscrire à l'aide des clés gérées par le client AWS IoT Core. Lorsque vous optez pour les clés gérées par le client, toutes les AWS IoT Core ressources de votre AWS compte sont cryptées à l'aide de la AWS KMS clé spécifiée. 1. Pour activer l' AWS IoT Core utilisation des clés gérées par le client AWS CLI, exécutez la commande `update-encryption-configuration` CLI. ``` aws iot update-encryption-configuration --encryption-type "CUSTOMER_MANAGED_KMS_KEY" \ --kms-access-role-arn "arn:aws:iam::111122223333:role/myrole" \ --kms-key-arn "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab" --region us-west-2 ``` 1. Pour vérifier que les clés gérées par le client AWS IoT Core sont AWS CLI utilisées, exécutez la commande `describe-encryption-configuration` CLI : ``` aws iot describe-encryption-configuration --region us-west-2 ``` Si vous avez activé les clés gérées par le client dans AWS IoT Core, le résultat peut ressembler à ce qui suit : ``` { "encryptionType": "CUSTOMER_MANAGED_KMS_KEY", "kmsKeyArn": "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab", "kmsAccessRoleArn": "arn:aws:iam::111122223333:role/myrole", "configurationDetails": { "configurationStatus": "HEALTHY" }, "lastModifiedDate": "2024-09-26T22:01:02.365000-07:00" } ``` Le `lastModifiedDate` champ indique la date à laquelle la configuration de chiffrement a été mise à jour pour la dernière fois. Si vous n'avez pas activé les clés gérées par le client, le résultat peut ressembler à ce qui suit : ``` { "encryptionType": "AWS_OWNED_KMS_KEY", "lastModifiedDate": "2024-09-26T22:01:02.365000-07:00" } ``` ### Étape 4 : Autorisations supplémentaires requises pour les opérations AWS IoT Core du plan de contrôle Une fois que vous avez opté pour les clés gérées par le client, toutes les AWS IoT Core ressources appartenant à votre AWS compte sont cryptées à l'aide de la clé KMS fournie. Toutes les opérations du plan de contrôle nécessitent désormais que l'appelant dispose d'`kms:Decrypt`autorisations sur la clé KMS en plus des autorisations requises pour l'opération spécifique sur la AWS IoT Core ressource. Si l'appelant n'est pas `kms:Decrypt` autorisé et qu'il effectue un appel d'API nécessitant le chiffrement ou le déchiffrement de données (par exemple,`GetPolicy`), il recevra un. `UnauthorizedException` Par exemple, lorsque vous appelez`GetPolicy`, vous avez besoin des deux `kms:Decrypt` autorisations `iot:GetPolicy` et des autorisations sur votre clé KMS gérée par le client pour que l'appel d'API réussisse. **Note** Lorsque vous mettez à jour des utilisateurs ou des rôles IAM pour accorder AWS KMS des autorisations sur la clé utilisée pour votre configuration de chiffrement, assurez-vous que la politique de clé KMS accorde également les autorisations requises aux utilisateurs ou rôles IAM respectifs. #### AWS KMS autorisations pour `UpdateEncryptionConfiguration` L'appel d'`UpdateEncryptionConfiguration`API nécessite les AWS KMS autorisations suivantes sur la clé KMS pour pouvoir opter pour les clés gérées par le client ou pour modifier la configuration de la clé : + `kms:DescribeKey` + `kms:Decrypt` + `kms:Encrypt` + `kms:GenerateDataKeyWithoutPlaintext` + `kms:ReEncryptTo` + `kms:ReEncryptFrom` #### AWS KMS autorisations pour tous les autres plans de contrôle APIs La plupart des plans de contrôle APIs nécessitent `kms:Decrypt` des autorisations lorsque les clés gérées par le client sont activées. Toutefois, certains APIs ne nécessitent pas les autorisations supplémentaires suivantes : APIs qui ne nécessitent pas d' AWS KMS autorisations La `List*` terre `Delete*` APIs ne tombe pas dans ce seau. Les clients peuvent toujours invoquer n'importe quelle API `List*` ou une API du plan de `Delete*` contrôle et ces appels d'API seront couronnés de succès même si l'appelant n'en a pas `kms:Decrypt` l'autorisation. Ces appels d'API seront couronnés de succès même si votre clé gérée par le client n'est pas saine `List*` et `Delete*` APIs ne permet aucun déchiffrement. + **Liste\$1 APIs** — Toutes les opérations de listage (par exemple, `ListThings``ListPolicies`,`ListCertificates`) + **Supprimer\$1 APIs** : toutes les opérations de suppression (par exemple,`DeleteThing`,`DeletePolicy`) `DeleteCertificate` ### Étape 5 : Gestion des clés AWS IoT Core effectue des contrôles périodiques sur la configuration des clés gérées par le client pour s'assurer que les opérations de chiffrement et de déchiffrement ne sont pas affectées. Ces contrôles de santé sont exécutés une fois par minute et vérifient AWS IoT Core la capacité à accéder et à utiliser à la fois la AWS KMS clé et le rôle IAM associé pour les opérations de chiffrement et de déchiffrement. SAIN AWS IoT Core peut accéder avec succès à la AWS KMS clé via le rôle IAM spécifié et effectuer des encryption/decryption opérations. Tous les composants fonctionnent correctement. NON SAIN AWS IoT Core Impossible d'accéder à la AWS KMS clé ou de l'utiliser. Cela empêche de nouvelles opérations de chiffrement et peut avoir un impact sur le fonctionnement du service. Le `errorCode` champ indique si le problème est lié à la clé ou au rôle IAM. #### Actions des clients susceptibles d'avoir un impact sur la santé des personnes clés Plusieurs actions du client peuvent faire passer l'état de santé des clés `HEALTHY` à `UNHEALTHY` : Actions liées aux clés + **Supprimer une AWS KMS clé** : lorsque vous planifiez la suppression d'une clé, son `Pending deletion` statut est défini et ne peut pas être utilisée + **Désactivation d'une AWS KMS clé** — Lorsque vous désactivez une clé KMS, elle ne peut plus être utilisée pour les opérations de chiffrement/déchiffrement + **Clé de planification pour la suppression** — La clé devient inutilisable une fois la suppression terminée + **Modification de la politique clé** — Suppression des autorisations d' AWS IoT Core accès nécessaires + **Modification des autorisations d'utilisation des clés** — Restreindre les AWS KMS actions requises Actions liées au rôle de l'IAM + **Suppression du rôle IAM** : AWS IoT Core impossible d'assumer le rôle permettant d'accéder à la clé + **Modification des autorisations de rôle** — Suppression AWS KMS des autorisations requises de la politique de rôle + **Modification de la politique de confiance** — Empêcher le AWS IoT Core service d'assumer le rôle + **Ajout de conditions restrictives** : conditions qui AWS IoT Core empêchent l'utilisation du rôle Actions au niveau du compte + **Modifications relatives à l'accès aux clés entre comptes** — Modification des autorisations relatives aux clés dans différents comptes + **Politiques de contrôle des services (SCPs) : politiques** au niveau de l'organisation qui limitent l'accès AWS KMS + Politiques **IAM au niveau du compte : politiques qui remplacent ou entrent en conflit** avec les clés d'accès **Important** Toute modification apportée aux AWS KMS clés, aux rôles IAM ou aux politiques utilisés par AWS IoT Core doit d'abord être testée dans les environnements de développement. Surveillez attentivement l'état de santé des clés après avoir apporté des modifications afin de vous assurer que AWS IoT Core les fonctionnalités ne sont pas affectées. #### Mettre à jour la configuration de chiffrement Mettez à jour votre configuration de chiffrement AWS IoT Core pour passer d'une clé gérée par le client à une autre, ou entre des clés AWS détenues et des clés gérées par le client. Pour modifier la configuration en utilisant une autre clé gérée par le client : 1. Créez une nouvelle clé gérée par le client en suivant les étapes décrites dans[Étape 1 : Créer une clé gérée par le client](#encryption-at-rest-cmk-create). 1. Mettez à jour votre politique de rôle IAM afin d'inclure des autorisations pour les anciennes et les nouvelles clés pendant la période de mise à jour. 1. Mettez à jour votre configuration de chiffrement pour utiliser la nouvelle clé : ``` aws iot update-encryption-configuration --encryption-type "CUSTOMER_MANAGED_KMS_KEY" \ --kms-access-role-arn "arn:aws:iam::111122223333:role/myrole" \ --kms-key-arn "arn:aws:kms:us-west-2:111122223333:key/new-key-id" ``` Pour modifier la configuration des clés gérées par le client à des clés AWS détenues, procédez comme suit : ``` aws iot update-encryption-configuration --encryption-type "AWS_OWNED_KMS_KEY" ``` **Note** Lorsque vous mettez à jour la configuration de chiffrement pour les nouvelles clés gérées par le client, assurez-vous que les anciennes et les nouvelles clés restent accessibles pour que l'opération réussisse. ##### Scénarios de défaillance courants et impacts Le tableau suivant décrit les scénarios d'échec courants lorsque des clés sont supprimées ou désactivées : | Scénario | Impact immédiat | Conséquences à long terme | | --- | --- | --- | | Clé désactivée | Toutes les nouvelles encryption/decryption opérations échouent immédiatement | Interruption du service jusqu'à ce que la clé soit réactivée ou remplacée | | Clé dont la suppression est prévue | L'état de la clé passe à En attente de suppression et toutes les encryption/decryption opérations échoueront | Défaillance automatique du service lorsque la suppression est terminée | | Clé définitivement supprimée | Défaillance immédiate et permanente de toutes les opérations | Perte de données permanente et impossibilité de récupérer des données chiffrées | | Politique clé modifiée de manière incorrecte | AWS IoT Core perd les autorisations d'accès à la clé | Défaillances de service jusqu'à ce que la politique soit corrigée | | Rôle IAM supprimé | AWS IoT Core ne peut pas assumer le rôle de clé d'accès | Défaillance complète du service de chiffrement | | Le rôle IAM n'est pas correctement modifié | AWS IoT Core Impossible d'assumer le rôle ou d'utiliser le rôle pour accéder à la clé | Défaillances de service jusqu'à ce que le rôle IAM soit corrigé | ##### Prévention et meilleures pratiques Pour éviter la suppression ou la désactivation accidentelle des clés et minimiser le risque de pannes de service : Mettre en œuvre des politiques de cycle de vie Établissez des procédures claires pour la création, la rotation et le retrait des clés. Documentez quelles clés sont utilisées par quelles AWS IoT Core ressources et maintenez un inventaire des clés actives. Utiliser les politiques IAM pour limiter la suppression de clés Créez des politiques IAM qui empêchent les utilisateurs non autorisés de supprimer ou de désactiver des clés de chiffrement critiques. Utilisez des conditions pour exiger une approbation supplémentaire pour les opérations de suppression de clés. Activer la CloudTrail journalisation Surveillez toutes les opérations AWS KMS clés CloudTrail pour détecter les activités de gestion des clés non autorisées ou accidentelles. Configurez des alertes pour la suppression de clés, la désactivation ou les modifications de politique. Tester les procédures de remplacement des clés Testez régulièrement vos procédures de remplacement de clés dans des environnements non liés à la production afin de vous assurer de pouvoir récupérer rapidement après une défaillance liée aux clés. Maintenir les sauvegardes clés Bien que vous ne puissiez pas exporter de matériel AWS KMS clé, conservez des enregistrements détaillés des clés ARNs, des politiques et des AWS IoT Core configurations associées afin de faciliter le remplacement rapide des clés si nécessaire. Surveillez l'état des clés Surveillez en permanence l'`CMK.Health`indicateur et configurez des alertes automatisées pour les principaux changements d'état de santé. Mettez en œuvre des réponses automatisées pour résoudre rapidement les problèmes clés. **Important** Testez toujours les principales procédures de mise à jour dans les environnements de développement avant de les implémenter en production. Disposez d'un plan de réduction documenté et assurez-vous que les principales procédures de remplacement peuvent être exécutées rapidement en cas d'urgence. ### Étape 6 : Surveillance de l'état de santé des clés Dans le cadre des contrôles AWS IoT Core périodiques, des CloudWatch métriques et des journaux sont émis pour fournir une visibilité sur l'état de santé de votre configuration de clés gérée par le client. AWS IoT Core émet la `CMK.Health` métrique CloudWatch au moins une fois par minute. La métrique fournit des informations sur l'état de santé des clés gérées par le client utilisées AWS IoT Core pour chiffrer et déchiffrer vos données. La `CMK.Health` métrique peut prendre les valeurs suivantes : + La valeur est la `1` suivante : AWS IoT Core est capable d'utiliser les clés de chiffrement avec succès pour chiffrer et déchiffrer vos données. + La valeur est la `0` suivante : AWS IoT Core impossible d'utiliser les clés de chiffrement pour chiffrer et déchiffrer vos données. AWS IoT Core émet également des journaux AWS IoT V2 lorsque l'état de santé des clés de chiffrement change. Ces journaux fournissent des informations supplémentaires sur la mise à jour de l'état de santé. Pour consulter ces journaux, vous devez activer les journaux AWS IoT V2. Les `HEALTHY` journaux sont émis au `INFO` niveau et les `UNHEALTHY` journaux sont émis au `ERROR` niveau. Pour plus d'informations sur les niveaux de journalisation, voir [Niveaux de journalisation](https://docs.aws.amazon.com/iot/latest/developerguide/configure-logging.html#log-level). Les exemples suivants sont des entrées de CloudWatch journal émises par AWS IoT Core pour indiquer la mise à jour de l'état de santé des clés gérées par le client. Pour surveiller et réagir efficacement aux principaux changements de l'état de santé : 1. **Configurez CloudWatch des alarmes** pour la `CMK.Health` métrique : ``` aws cloudwatch put-metric-alarm --region us-west-2 \ --alarm-name "IoTCore-CMK-Health-Alert" \ --alarm-description "Alert when IoT Core CMK health is unhealthy" \ --metric-name "CMK.Health" \ --namespace "AWS/IoT" \ --statistic "Minimum" \ --period 300 \ --evaluation-periods 1 \ --threshold 1 \ --comparison-operator "LessThanThreshold" \ --alarm-actions "arn:aws:sns:us-west-2:111122223333:iot-alerts" ``` 1. **Activez la journalisation AWS IoT V2** pour capturer les événements de modification de l'état de santé détaillés avec des codes d'erreur et des messages. 1. **Vérifiez l'état de la configuration** pour le dépannage : ``` aws iot describe-encryption-configuration --region us-west-2 ``` 1. **Vérifiez le statut INSALUBRE** en examinant le `errorCode` champ : + `KMS_KEY_VALIDATION_ERROR`— Problème avec la AWS KMS clé (désactivée, supprimée ou problèmes de politique) + `ROLE_VALIDATION_ERROR`— Problème lié au rôle IAM (suppression, problèmes de politique ou problèmes de confiance) #### De MALSAIN à SAIN Lorsque l'état des clés de chiffrement est mis à jour de `UNHEALTHY` à`HEALTHY`, AWS IoT Core un message de journal AWS IoT V2 est émis au format suivant. ``` { "timestamp": "2017-08-10 15:37:23.476", "logLevel": "INFO", "traceId": "8421693b-f4f0-4e4a-9235-0cff8bab897d", "accountId": "111122223333", "status": "SUCCESS", "cmkStatus": "HEALTHY", "kmsKeyArn": "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab", "kmsAccessRoleArn": "arn:aws:iam::111122223333:role/myrole", "eventType": "CmkHealthCheck" } ``` #### Du sain au malsain Lorsque l'état des clés de chiffrement est mis à jour de `HEALTHY` à`UNHEALTHY`, AWS IoT Core un message de journal AWS IoT V2 est émis au format suivant. ``` { "timestamp": "2017-08-10 15:37:23.476", "logLevel": "ERROR", "traceId": "8421693b-f4f0-4e4a-9235-0cff8bab897d", "accountId": "111122223333", "status": "FAILURE", "cmkStatus": "UNHEALTHY", "errorCode": "KMS_KEY_VALIDATION_ERROR / ROLE_VALIDATION_ERROR", "errorMessage": "Error message on why there was a failure", "kmsKeyArn": "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab", "kmsAccessRoleArn": "arn:aws:iam::111122223333:role/myrole", "eventType": "CmkHealthCheck" } ``` **Avertissement** Lorsque l'état de santé des clés est `UNHEALTHY` atteint, AWS IoT Core les opérations échouent immédiatement. Dans ce cas, passez en revue vos principales configurations, vos autorisations de rôle IAM et vos politiques. Surveillez les changements de statut de la `CMK.Health` métrique. Si les opérations continuent d'échouer après avoir passé en revue vos configurations, contactez votre responsable de compte ou le [AWS Support Center](https://console.aws.amazon.com/support/home#/) pour obtenir une assistance supplémentaire. #### AWS CloudTrail événements Vous pouvez également surveiller AWS IoT Core l'utilisation de la clé KMS pour les opérations de chiffrement et de déchiffrement. AWS IoT Core effectuera `DescribeKey` des `Decrypt` `GenerateDataKeyWithoutPlaintext` opérations sur votre clé KMS pour crypter/déchiffrer les données appartenant à votre AWS compte stockées au repos. `ReEncrypt` Il existe CloudTrail des événements pour `DescribeKey``Decrypt`,`ReEncrypt`, et`GenerateDataKeyWithoutPlaintext`. Ces événements surveillent AWS KMS les opérations appelées AWS IoT Core pour accéder aux données chiffrées par votre clé gérée par le client. ##### Exemple de `Decrypt` ``` { "eventVersion": "1.09", "userIdentity": { "type": "AssumedRole", "principalId": "AROAIGDTESTANDEXAMPLE:Sampleuser01", "arn": "arn:aws:sts::111122223333:assumed-role/Admin/Sampleuser01", "accountId": "111122223333", "accessKeyId": "*********************", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROAIGDTESTANDEXAMPLE:Sampleuser01", "arn": "arn:aws:sts::111122223333:assumed-role/Admin/Sampleuser01", "accountId": "111122223333", "userName": "*****" }, "attributes": { "creationDate": "2024-09-16T20:23:39Z", "mfaAuthenticated": "false" } }, "invokedBy": "iot.amazonaws.com" }, "eventTime": "2024-09-16T20:32:48Z", "eventSource": "kms.amazonaws.com", "eventName": "Decrypt", "awsRegion": "us-west-2", "sourceIPAddress": "iot.amazonaws.com", "userAgent": "iot.amazonaws.com", "requestParameters": { "encryptionContext": { "kms-arn": "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab", "aws-crypto-ec:vendor": "iot.amazonaws.com", "branch-key-id": "111122223333", "type": "branch:ACTIVE" }, "encryptionAlgorithm": "SYMMETRIC_DEFAULT", "keyId": "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab" }, "responseElements": null, "requestID": "1afb6d98-8388-455d-8b48-e62c9e0cf7f4", "eventID": "b59a5f16-0d98-46d8-a590-0e040a48b39b", "readOnly": true, "resources": [ { "accountId": "111122223333", "type": "AWS::KMS::Key", "ARN": "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "111122223333", "eventCategory": "Management" } ```