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.

Meilleures 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 Coreest un service cloud géré qui permet aux appareils connectés d'interagir facilement et en toute sécurité avec les applications cloud et d'autres appareils. AWS IoT Core prend en charge HTTP et MQTT, un protocole de communication léger spécialement conçu pour tolérer les connexions intermittentes. WebSocket Si vous vous connectez à AWS IoT l'aide de MQTT, chacune de vos connexions doit être associée à un identifiant appelé ID client. Les ID de client MQTT identifient uniquement des connexions MQTT. 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 supprime l'ancienne connexion pour autoriser la nouvelle connexion. Les identifiants des clients doivent être uniques pour Compte AWS chaque client Région AWS. Cela signifie que vous n'avez pas besoin d'appliquer l'unicité globale des identifiants clients en dehors de votre région Compte AWS ou entre les régions de votre région Compte AWS.

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 :

Pour éviter les conflits entre les identifiants clients et leurs impacts négatifs potentiels, assurez-vous que chaque appareil ou application mobile dispose d'une AWS IoT politique IAM qui limite les ID clients qui peuvent ê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 de plus amples informations, veuillez consulter Autorisation.

Tous les appareils de votre parc doivent disposer d'informations d'identification avec des privilèges qui autorisent uniquement les actions prévues, qui incluent (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 à AWS IoT Message Broker. 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, les types d'objets et les valeurs d'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 AWS IoT connecte. Les variables de politique d'objet 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'AttachThingPrincipalAPI 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 :

Si vous souhaitez identifier les conflits d'identification client en cours, vous pouvez activer et utiliser CloudWatch Logs for AWS IoT. Pour chaque connexion MQTT que le courtier de AWS IoT messages déconnecte 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 les CloudWatch alarmes correspondantes pour une surveillance et des rapports continus.

Vous pouvez utiliser AWS IoT Device Defender pour identifier les politiques IAM AWS IoT et les politiques IAM trop permissives. AWS IoT Device Defender propose également une vérification d'audit qui vous avertit si plusieurs appareils de votre parc se connectent au courtier de AWS IoT messages en utilisant le même ID 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 de sécurité.

Consultez aussi

Veiller à la synchronisation de l'horloge de votre appareil

Il est important d'avoir une heure précise sur votre appareil. X.509 les certificats 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. Real-time les horloges peuvent varier pendant cette période et les batteries peuvent se décharger. Le réglage de l'heure en usine n'est donc pas suffisant.

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 ne s'agit pas d'un autre serveur qui se fait passer pour lui AWS IoT. 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 notre 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 X.509 format et incluent diverses informations telles que le nom de l'organisation, son emplacement, son 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. Certains services AWS IoT Core utilisent des périodes de validité limitées (par exemple, un an) pour leurs certificats de serveur et commencent à en proposer 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 X.509 clients. 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.

Utilise-en une seconde Région AWS en tant que 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 IoTest plus disponible. Bien que la GitHub bibliothèque associée reste accessible, elle est AWS devenue obsolète en juillet 2023 et ne fournit plus de maintenance ni de support pour elle. Pour mettre en œuvre vos propres solutions ou pour explorer d'autres options de support, rendez-vous sur Contact AWS. Si un responsable AWS technique des comptes 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 du temps. AWS IoT fournit un moyen de définir un modèle pour approvisionner les appareils lors de leur première connexion AWS IoT. Pour de plus amples informations, veuillez consulter Just-in-time approvisionnement.

Autorisations d'exécution AWS IoT Tests Device Advisor

Le modèle de politique suivant indique les autorisations minimales et l'entité IAM requises pour exécuter des scénarios de test AWS IoT Device Advisor. Vous devrez remplacer par le rôle your-device-role-arn d'appareil Amazon Resource Name (ARN) que vous avez créé conformément aux prérequis.

Cross-service prévention adjointe confuse pour 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 du problème des adjoints. Cross-service l'usurpation d'identité 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é à accéder autrement. Pour éviter cela, AWS fournit des outils qui vous aident à protéger vos données pour tous les services dont les responsables de service ont eu 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.