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.
Bonnes pratiques en matière de sécurité dans AWS IoT Core
Cette section contient des informations sur les meilleures pratiques de sécurité pour AWS IoT Core. Pour plus d’informations sur les règles de sécurité pour les solutions Industrial IoT, consultez Dix règles d’or de sécurité pour les solutions Industrial IoT
Protection des connexions MQTT dans AWS IoT
AWS IoT Core
L'impact et la gravité de l'abandon des connexions MQTT sur votre parc d'appareils dépend de nombreux facteurs. Il s'agit des licences suivantes :
-
Votre cas d'utilisation (par exemple, les données auxquelles vos appareils envoient AWS IoT, la quantité de données et la fréquence à laquelle les données sont envoyées).
-
La configuration de votre client MQTT (par exemple, les paramètres de reconnexion automatique, les temporisations de back-off associées et l'utilisation de sessions persistantes MQTT).
-
Contraintes liées aux ressources de l'appareil.
-
La cause première des déconnexions, leur agressivité et leur persistance.
Pour éviter les conflits d'ID client et leurs impacts négatifs potentiels, assurez-vous que chaque appareil ou application mobile dispose d'une politique AWS IoT ou d'une politique IAM qui restreint les identifiants clients pouvant être utilisés pour les connexions MQTT au AWS IoT courtier de messages. Par exemple, vous pouvez utiliser une politique IAM pour empêcher un appareil de fermer involontairement la connexion d'un autre appareil à l'aide d'un ID client déjà utilisé. Pour plus d’informations, consultez Autorisation.
Tous les appareils de votre parc doivent disposer d'informations d'identification avec des privilèges autorisant uniquement les actions prévues, notamment (mais sans s'y limiter) les actions AWS IoT MQTT telles que la publication de messages ou l'abonnement à des sujets ayant une portée et un contexte spécifiques. Les stratégies d'autorisation spécifiques peuvent varier selon vos cas d'utilisation. Identifiez les stratégies d'autorisation qui répondent le mieux aux exigences de votre entreprise et de sécurité.
Pour simplifier la création et la gestion des politiques d'autorisation, vous pouvez utiliser les AWS IoT Core variables de politique et les variables de la politique IAM. Les variables de la stratégie peuvent être placées dans une stratégie et lorsque celle-ci est évaluée, les variables sont remplacées par les valeurs provenant de la demande de l'appareil. Avec des variables de stratégie, vous pouvez créer une stratégie unique pour l'octroi d'autorisations à plusieurs appareils. Vous pouvez identifier les variables de politique pertinentes pour votre cas d'utilisation en fonction de la configuration de votre AWS IoT compte, du mécanisme d'authentification et du protocole réseau utilisés pour vous connecter au courtier de AWS IoT messages. Toutefois, pour écrire les meilleures stratégies d'autorisation, vous devez prendre en compte les spécificités de votre cas d'utilisation et votre modèle de menaces
Par exemple, si vous avez enregistré vos appareils dans le AWS IoT registre, vous pouvez utiliser les variables de politique des objets dans les AWS IoT politiques pour accorder ou refuser des autorisations en fonction des propriétés des objets, telles que les noms des objets, les types d'objets et les valeurs des attributs des objets. Le nom de l'objet est obtenu à partir de l'ID client figurant dans le message de connexion MQTT envoyé lorsqu'un objet se connecte à AWS IoT. Les variables de politique des objets sont remplacées lorsqu'un objet se connecte AWS IoT via MQTT à l'aide de l'authentification mutuelle TLS ou MQTT via le WebSocket protocole à l'aide d'identités Amazon Cognito authentifiées. Vous pouvez utiliser l'API AttachThingPrincipal pour associer des certificats et des identités Amazon Cognito authentifiées à un objet. iot:Connection.Thing.ThingNameest une variable de politique utile pour appliquer les restrictions d'identification des clients. L'exemple de AWS IoT politique suivant exige que le nom d'un objet enregistré soit utilisé comme ID client pour les connexions MQTT au courtier de AWS IoT messages :
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iot:Connect", "Resource": [ "arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}" ] } ] }
Si vous souhaitez identifier les conflits d'ID client en cours, vous pouvez activer et utiliser CloudWatch Logs for AWS IoT. Pour chaque connexion MQTT déconnectée par le courtier de AWS IoT messages en raison de conflits d'ID client, un enregistrement de journal similaire au suivant est généré :
{ "timestamp": "2019-04-28 22:05:30.105", "logLevel": "ERROR", "traceId": "02a04a93-0b3a-b608-a27c-1ae8ebdb032a", "accountId": "123456789012", "status": "Failure", "eventType": "Disconnect", "protocol": "MQTT", "clientId": "clientId01", "principalId": "1670fcf6de55adc1930169142405c4a2493d9eb5487127cd0091ca0193a3d3f6", "sourceIp": "203.0.113.1", "sourcePort": 21335, "reason": "DUPLICATE_CLIENT_ID", "details": "A new connection was established with the same client ID" }
Vous pouvez utiliser un filtre CloudWatch Logs, par exemple {$.reason= "DUPLICATE_CLIENT_ID" } pour rechercher des cas de conflits d'ID client ou pour configurer des filtres CloudWatch métriques et des CloudWatch alarmes correspondantes pour une surveillance et des rapports continus.
Vous pouvez utiliser AWS IoT Device Defender
Vous pouvez utiliser AWS IoT Device Advisor pour vérifier que vos appareils peuvent se connecter de manière fiable aux meilleures pratiques en matière de sécurité AWS IoT Core et les suivre.
Consultez aussi
Veiller à la synchronisation de l'horloge de votre appareil
Il est important que l'heure soit exacte sur votre appareil. Les certificats X.509 ont une date et une heure d'expiration. L'horloge de votre appareil est utilisée pour vérifier qu'un certificat de serveur est toujours valide. Si vous construisez des appareils IoT commerciaux, n'oubliez pas que vos produits peuvent être stockés pendant de longues périodes avant d'être vendus. Les horloges en temps réel peuvent dériver pendant cette période et les batteries peuvent se décharger, par conséquent, il ne suffit pas de régler l'heure en usine.
Pour la plupart des systèmes, cela signifie que le logiciel de l’appareil doit inclure un client NTP (Network Time Protocol). L’appareil doit attendre qu'il se synchronise avec un serveur NTP avant d'essayer de se connecter à AWS IoT Core. Si ce n'est pas possible, le système doit fournir un moyen aux utilisateurs de définir l'heure de l'appareil afin que les connexions suivantes réussissent.
Une fois l'appareil synchronisé avec un serveur NTP, il peut établir une connexion avec AWS IoT Core. L’ampleur du décalage d'horloge autorisé dépend de ce que vous essayez de faire avec la connexion.
Valider le certificat de serveur
La première chose avec laquelle un appareil interagit AWS IoT est d'ouvrir une connexion sécurisée. Lorsque vous connectez votre appareil à AWS IoT, assurez-vous que vous parlez à un autre serveur AWS IoT et qu'il n'y a pas d'usurpation AWS IoT d'identité. Chacun des AWS IoT serveurs est approvisionné avec un certificat émis pour le iot.amazonaws.com domaine. Ce certificat a été délivré AWS IoT par une autorité de certification fiable qui a vérifié notre identité et la propriété du domaine.
L'une des premières choses à AWS IoT Core faire lorsqu'un appareil se connecte est de lui envoyer un certificat de serveur. Les appareils peuvent vérifier qu'ils sont censés se connecter à iot.amazonaws.com et que le serveur à l'autre extrémité de cette connexion possède un certificat provenant d'une autorité de confiance pour ce domaine.
Les certificats TLS sont au format X.509 et comprennent diverses informations, telles que le nom de l'organisation, l'emplacement, le nom de domaine et une période de validité. La période de validité est spécifiée sous la forme d'une paire de valeurs temporelles nommées notBefore et notAfter. Des services tels que AWS IoT Core l'utilisation de périodes de validité limitées (par exemple, un an) pour leurs certificats de serveur et commencent à en servir de nouveaux avant l'expiration des anciens.
Utiliser une identité unique par appareil
Utilisez une identité unique par client. Les appareils utilisent généralement des certificats client X.509. Les applications Web et mobiles utilisent Amazon Cognito Identity. Cela vous permet d'appliquer des autorisations précises à vos appareils.
Par exemple, si une application se compose d'un téléphone mobile qui reçoit des mises à jour d'état de deux objets connectés différents – une ampoule et un thermostat. L'ampoule envoie l'état de son niveau de batterie, et un thermostat envoie des messages indiquant la température.
AWS IoT authentifie les appareils individuellement et traite chaque connexion individuellement. Vous pouvez appliquer des contrôles d'accès précis grâce à des stratégies d'autorisation. Vous pouvez définir une stratégie pour le thermostat, qui l'autorise à publier dans un espace de rubrique. Vous pouvez définir une stratégie distincte pour l'ampoule, qui l'autorise à publier dans un autre espace de rubrique. Enfin, vous pouvez définir une stratégie pour l'application mobile, qui l'autorise uniquement à se connecter et à s'abonner aux rubriques du thermostat et de l'ampoule, afin de recevoir des messages de ces appareils.
Appliquez le principe du moins de privilèges et définissez les autorisations par appareil autant que possible. Tous les appareils ou utilisateurs doivent disposer d'une AWS IoT politique leur AWS IoT permettant uniquement de se connecter avec un identifiant client connu, de publier et de s'abonner à un ensemble de sujets identifiés et fixes.
Utiliser une seconde Région AWS comme sauvegarde
Envisagez de stocker une copie de vos données en une seconde à Région AWS titre de sauvegarde. Notez que la AWS solution nommée Disaster Recovery for
Utiliser la mise en service juste à temps
La création et le provisionnement manuels de chaque appareil peuvent prendre beaucoup de temps. AWS IoT fournit un moyen de définir un modèle pour approvisionner les appareils lorsqu'ils se connectent pour la première fois à AWS IoT. Pour plus d’informations, consultez ust-in-time Approvisionnement J.
Autorisations pour exécuter des tests AWS IoT Device Advisor
Le modèle de politique suivant indique les autorisations minimales et l'entité IAM requises pour exécuter les scénarios de test de AWS IoT Device Advisor. Vous devrez remplacer your-device-role-arn par le rôle de périphérique Amazon Resource Name (ARN) que vous avez créé selon les conditions préalables.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "iam:PassRole", "Resource": "your-device-role-arn", "Condition": { "StringEquals": { "iam:PassedToService": "iotdeviceadvisor.amazonaws.com" } } }, { "Sid": "VisualEditor1", "Effect": "Allow", "Action": [ "execute-api:Invoke*", "iam:ListRoles", // Required to list device roles in the Device Advisor console "iot:Connect", "iot:CreateJob", "iot:DeleteJob", "iot:DescribeCertificate", "iot:DescribeEndpoint", "iot:DescribeJobExecution", "iot:DescribeJob", "iot:DescribeThing", "iot:GetPendingJobExecutions", "iot:GetPolicy", "iot:ListAttachedPolicies", "iot:ListCertificates", "iot:ListPrincipalPolicies", "iot:ListThingPrincipals", "iot:ListThings", "iot:Publish", "iot:StartNextPendingJobExecution", "iot:UpdateJobExecution", "iot:UpdateThingShadow", "logs:CreateLogGroup", "logs:CreateLogStream", "logs:DescribeLogGroups", "logs:DescribeLogStreams", "logs:PutLogEvents", "logs:PutRetentionPolicy" ], "Resource": "*" }, { "Sid": "VisualEditor2", "Effect": "Allow", "Action": "iotdeviceadvisor:*", "Resource": "*" } ] }
Prévention du problème de l'adjoint confus entre services pour l'interface Device Advisor
Le problème de député confus est un problème de sécurité dans lequel une entité qui n’est pas autorisée à effectuer une action peut contraindre une entité plus privilégiée à le faire. En AWS, l'usurpation d'identité interservices peut entraîner un problème de confusion chez les adjoints. L’usurpation d’identité entre services peut se produire lorsqu’un service (le service appelant) appelle un autre service (le service appelé). Le service appelant peut être manipulé et ses autorisations utilisées pour agir sur les ressources d’un autre client auxquelles on ne serait pas autorisé d’accéder autrement. Pour éviter cela, AWS fournit des outils qui vous aident à protéger vos données pour tous les services auprès des principaux fournisseurs de services qui ont obtenu l'accès aux ressources de votre compte.
Nous vous recommandons d'utiliser les clés de contexte aws:SourceArn et de condition globale aws:SourceAccount dans les politiques de ressources afin de limiter les autorisations à la ressource octroyées par Device Advisor à un autre service. Si vous utilisez les deux clés de contexte de condition globale, la valeur aws:SourceAccount et le compte de la valeur aws:SourceArn doit utiliser le même ID de compte lorsqu’il est utilisé dans la même déclaration de stratégie.
La valeur de aws:SourceArn doit être l’ARN de votre ressource de définition de suite. La ressource de définition de suite fait référence à la suite de tests que vous avez créée avec Device Advisor.
Le moyen le plus efficace de se protéger contre le problème de député confus consiste à utiliser la clé de contexte de condition globale aws:SourceArn avec l’ARN complet de la ressource. Si vous ne connaissez pas l’ARN complet de la ressource ou si vous spécifiez plusieurs ressources, utilisez la clé de contexte de condition globale aws:SourceArn avec des caractères génériques (*) pour les parties inconnues de l’ARN. Par exemple, arn:aws:iotdeviceadvisor:*: account-id:suitedefinition/*
L'exemple suivant montre comment utiliser les clés contextuelles aws:SourceArn et de condition globale aws:SourceAccount dans Device Advisor pour éviter le problème de confusion des adjoints.
{ "Version": "2012-10-17", "Statement": { "Sid": "ConfusedDeputyPreventionExamplePolicy", "Effect": "Allow", "Principal": { "Service": "iotdeviceadvisor.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "ArnLike": { "aws:SourceArn":"arn:aws:iotdeviceadvisor:us-east-1:123456789012:suitedefinition/ygp6rxa3tzvn"}, "StringEquals": { "aws:SourceAccount":"123456789012"} } } }
