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 MQTT des connexions dans AWS IoT

AWS IoT Coreest un service cloud géré qui permet aux appareils connectés d'interagir avec des applications cloud et d'autres appareils facilement et en toute sécurité. AWS IoT Core prend en charge HTTP WebSocketMQTT, et un protocole de communication léger spécialement conçu pour tolérer les connexions intermittentes. Si vous vous connectez ou AWS IoT utilisezMQTT, chacune de vos connexions doit être associée à un identifiant appelé ID client. MQTTle client IDs identifie les MQTT connexions de manière unique. Si une nouvelle connexion est établie à l'aide d'un ID client déjà réclamé pour une autre connexion, le courtier de AWS IoT messages abandonne l'ancienne connexion pour autoriser la nouvelle connexion. Le client IDs doit être unique au sein de chacun Compte AWS d'entre eux Région AWS. Cela signifie que vous n'avez pas besoin d'appliquer le caractère unique mondial du client IDs en dehors de votre région Compte AWS ou entre les régions de votre Compte AWS pays.

L'impact et la gravité des interruptions de MQTT connexion sur votre parc d'appareils dépendent de nombreux facteurs. Il s'agit des licences suivantes :

Pour éviter les conflits d'ID client et leurs impacts négatifs potentiels, assurez-vous que chaque appareil ou application mobile dispose d'une IAM politique AWS IoT ou d'une politique qui limite le client IDs pouvant être utilisé pour les MQTT connexions au courtier de AWS IoT messages. Par exemple, vous pouvez utiliser une IAM politique pour empêcher un appareil de fermer involontairement la connexion d'un autre appareil en utilisant un ID client déjà utilisé. Pour de plus amples informations, veuillez consulter 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) des AWS IoT MQTT actions 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 AWS IoT Core variables de politique des variables IAM de stratégie. 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 des variables de politique d'objet 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 MQTT connexion 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 l'authentification TLS mutuelle ou MQTT MQTT via le WebSocket protocole à l'aide d'identités Amazon Cognito authentifiées. Vous pouvez utiliser le AttachThingPrincipalAPIpour 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 MQTT les connexions 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 MQTT connexion 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 pour identifier les politiques trop AWS IoT permissivesIAM. AWS IoT Device Defender fournit également une vérification d'audit qui vous avertit si plusieurs appareils de votre parc se connectent au AWS IoT messager en utilisant le même identifiant client.

Vous pouvez utiliser AWS IoT Device Advisor pour vérifier que vos appareils peuvent se connecter de manière fiable AWS IoT Core et suivre les meilleures pratiques en matière de sécurité.

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 Network Time Protocol (NTP). L'appareil doit attendre de se synchroniser avec un NTP serveur avant de tenter de s'y 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 que l'appareil est synchronisé avec un NTP serveur, 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.

TLSles certificats sont au format X.509 et incluent diverses informations telles que le nom de l'organisation, son emplacement, son nom de domaine et sa 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 n' AWS IoT est plus disponible. Bien que la GitHubbibliothèque associée reste accessible, elle est AWS devenue obsolète en juillet 2023 et n'en assure plus la maintenance ni le support. Pour mettre en œuvre vos propres solutions ou pour explorer d'autres options d'assistance, rendez-vous sur Contact AWS. Si un responsable de compte AWS technique est associé à votre compte, contactez-le pour obtenir de l'aide.

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 de plus amples informations, veuillez consulter 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'IAMentité requises pour exécuter les scénarios de test de AWS IoT Device Advisor. Vous devrez remplacer your-device-role-arn avec le rôle d'appareil Amazon Resource Name (ARN) que vous avez créé conformément aux prérequis.

{
    "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",
                "iotjobsdata:DescribeJobExecution",
                "iot:DescribeJob",                                 
                "iot:DescribeThing",
                "iotjobsdata:GetPendingJobExecutions",
                "iot:GetPolicy",
                "iot:ListAttachedPolicies",
                "iot:ListCertificates",
                "iot:ListPrincipalPolicies",
                "iot:ListThingPrincipals",
                "iot:ListThings",
                "iot:Publish",    
                "iotjobsdata:StartNextPendingJobExecution",
                "iotjobsdata: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 la confusion des 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 celle 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 prémunir contre le problème de confusion des adjoints consiste à utiliser la clé de contexte de la condition aws:SourceArn globale avec l'intégralité ARN de la ressource. Si vous ne connaissez pas l'intégralité ARN de la ressource ou si vous spécifiez plusieurs ressources, utilisez la clé de condition contextuelle aws:SourceArn globale avec des caractères génériques (*) pour les parties inconnues duARN. 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"
      }
    }
  }
}