

# Contrôles d’audit
<a name="device-defender-audit-checks"></a>

**Note**  
Lorsque vous activez une vérification, la collecte des données démarre immédiatement. Si un grand nombre de données doit être collecté dans votre compte, les résultats du contrôle risquent de ne pas être disponibles immédiatement après l’activation.

Les contrôles d’audit suivants sont pris en charge :
+ [L’autorité de certification intermédiaire a été révoquée pour vérification des certificats d’appareils actifs](audit-chk-active-intermediary-device-revoked-CA.md)
+ [Le certificat CA révoqué est toujours actif](audit-chk-revoked-ca-cert.md)
+ [Certificat d’appareil partagé](audit-chk-device-cert-shared.md)
+ [Qualité de la clé du certificat de l’appareil](audit-chk-device-cert-key-quality.md)
+ [Qualité de la clé du certificat CA](audit-chk-ca-cert-key-quality.md)
+ [Le rôle Cognito non authentifié est trop permissif](audit-chk-unauth-cognito-role-permissive.md)
+ [Le rôle de Cognito authentifié est trop permissif](audit-chk-auth-cognito-role-permissive.md)
+ [Politiques AWS IoT trop permissives](audit-chk-iot-policy-permissive.md)
+ [Politique AWS IoT potentiellement mal configurée](audit-chk-iot-misconfigured-policies.md)
+ [Alias de rôle trop permissif](audit-chk-iot-role-alias-permissive.md)
+ [L’alias de rôle permet d’accéder aux services non utilisés](audit-chk-role-alias-unused-svcs.md)
+ [Expiration du certificat CA](audit-chk-ca-cert-approaching-expiration.md)
+ [Identifiants clients MQTT conflictuels](audit-chk-conflicting-client-ids.md)
+ [Expiration du certificat de l’appareil](audit-chk-device-cert-approaching-expiration.md)
+ [Vérification de l’âge du certificat d’appareil](device-certificate-age-check.md)
+ [Un certificat d’appareil révoqué est toujours actif.](audit-chk-revoked-device-cert.md)
+ [Journalisation désactivée.](audit-chk-logging-disabled.md)

# L’autorité de certification intermédiaire a été révoquée pour vérification des certificats d’appareils actifs
<a name="audit-chk-active-intermediary-device-revoked-CA"></a>

Utilisez cette vérification pour identifier tous les certificats d’appareil associés qui sont toujours actifs malgré la révocation d’une autorité de certification intermédiaire.

Cette vérification apparaît comme `INTERMEDIATE_CA_REVOKED_FOR_ACTIVE_DEVICE_CERTIFICATES_CHECK` dans la CLI et l’API.

**Gravité :** Critique

## Détails
<a name="audit-chk-active-device-intermediary-revoked-CA-details"></a>

Les codes de motif sont renvoyés lorsque ce contrôle trouve une non-conformité :
+ INTERMEDIATE\$1CA\$1REVOKED\$1BY\$1ISSUER

## Pourquoi est-ce important ?
<a name="audit-chk-active-device-intermediary-revoked-CA-why-it-matters"></a>

L’autorité de certification intermédiaire a été révoquée pour les certificats d’appareils actifs évalue l’identité et la confiance de l’appareil, en déterminant s’il existe des certificats d’appareil actifs AWS IoT Core dans lesquels les autorités de certification émettrices intermédiaires ont été révoquées dans la chaîne d’autorités de certification.

Une autorité de certification intermédiaire révoquée ne doit plus être utilisée pour signer une autre autorité de certification ou un autre certificat d’appareil dans la chaîne d’autorités de certification. Les appareils nouvellement ajoutés avec des certificats signés à l’aide de ce certificat d’autorité de certification après la révocation de l’autorité de certification intermédiaire constitueront une menace pour la sécurité.

## Comment réparer
<a name="audit-chk-active-device-intermediary-revoked-CA-how-to-fix"></a>

Vérifiez l’activité d’enregistrement du certificat de l’appareil pendant la période qui a suivi la révocation du certificat CA. Suivez les bonnes pratiques en matière de sécurité pour traiter cette situation. Il se peut que vous souhaitiez :

1. Fournissez de nouveaux certificats, signés par une autre autorité de certification, pour les appareils concernés.

1. Vérifier que les nouveaux certificats sont valides et que les appareils peuvent les utiliser pour se connecter.

1. Utiliser [UpdateCertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateCertificate.html) pour marquer l’ancien certificat comme REVOKED (RÉVOQUÉ) dans AWS IoT. Vous pouvez également utiliser des actions d’atténuation pour effectuer les actions suivantes :
   + Appliquer l’action d’atténuation `UPDATE_DEVICE_CERTIFICATE` sur vos résultats d’audit pour effectuer ce changement. 
   + Appliquer l’action d’atténuation `ADD_THINGS_TO_THING_GROUP` pour ajouter le dispositif à un groupe où vous pouvez prendre des mesures à son égard.
   + Appliquer l’action d’atténuation `PUBLISH_FINDINGS_TO_SNS` si vous souhaitez mettre en œuvre une réponse personnalisée pour répondre au message Amazon SNS. 
   + Vérifiez l’activité d’enregistrement de certificat d’appareil pendant la période après laquelle le certificat intermédiaire de CA a été révoqué et envisagez de révoquer les certificats d’appareil qui ont pu être émis pendant cette période. Utilisez [ListRelatedResourcesForAuditFinding](https://docs.aws.amazon.com/iot/latest/apireference/API_ListRelatedResourcesForAuditFinding.html) pour répertorier les certificats d’appareil signés par le certificat CA et [UpdateCertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateCertificate.html) pour révoquer un certificat d’appareil.
   + Détacher l’ancien certificat de l’appareil. (Voir [ DetachThingPrincipal](https://docs.aws.amazon.com/iot/latest/apireference/API_DetachThingPrincipal.html).)

   Pour de plus amples informations, consultez [Actions d'atténuation](dd-mitigation-actions.md).

# Le certificat CA révoqué est toujours actif
<a name="audit-chk-revoked-ca-cert"></a>

Un certificat CA a été révoqué, mais demeure actif dans AWS IoT.

Cette vérification apparaît comme `REVOKED_CA_CERTIFICATE_STILL_ACTIVE_CHECK` dans la CLI et l’API.

**Gravité :** Critique

## Détails
<a name="audit-chk-revoked-ca-cert-details"></a>

Un certificat CA est marqué comme étant révoqué dans la liste de révocation des certificats gérée par l’autorité d’émission mais est encore marqué comme étant ACTIVE (ACTIF) ou PENDING TRANSFER (EN ATTENTE DE TRANSFERT) dans AWS IoT.

Voici les codes de motif renvoyés lorsque ce contrôle trouve un certificat CA non conforme :
+ CERTIFICATE\$1REVOKED\$1BY\$1ISSUER

## Pourquoi est-ce important ?
<a name="audit-chk-revoked-ca-cert-why-it-matters"></a>

Un certificat CA révoqué ne doit plus être utilisé pour signer des certificats d’appareil. Il peut avoir été révoqué car compromis. Les appareils nouvellement ajoutés avec des certificats signés à l’aide de ce certificat CA peuvent constituer une menace à la sécurité. 

## Comment réparer
<a name="audit-chk-revoked-ca-cert-how-to-fix"></a>

1. Utilisez [UpdateCACertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateCACertificate.html) pour marquer le certificat CA comme INACTIVE (INACTIF) dans AWS IoT. Vous pouvez également utiliser des actions d’atténuation pour effectuer les actions suivantes :
   + Appliquer l’action d’atténuation `UPDATE_CA_CERTIFICATE` sur vos résultats d’audit pour effectuer ce changement. 
   + Appliquez l’action d’atténuation `PUBLISH_FINDINGS_TO_SNS` si vous souhaitez mettre en œuvre une réponse personnalisée pour répondre au message Amazon SNS. 

   Pour de plus amples informations, consultez [Actions d'atténuation](dd-mitigation-actions.md).

1. Vérifiez l’activité d’enregistrement de certificat d’appareil pendant la période après laquelle le certificat de CA a été révoqué et envisagez de révoquer les certificats d’appareil qui ont pu être émis pendant cette période. Utilisez [ListCertificatesByCA](https://docs.aws.amazon.com/iot/latest/apireference/API_ListCertificatesByCA.html) pour répertorier les certificats d’appareil signés par le certificat CA et [UpdateCertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateCertificate.html) pour révoquer un certificat d’appareil.

# Certificat d’appareil partagé
<a name="audit-chk-device-cert-shared"></a>

Plusieurs connexions simultanées utilisent le même certificat X.509 pour s’authentifier auprès d’ AWS IoT.

Cette vérification apparaît comme `DEVICE_CERTIFICATE_SHARED_CHECK` dans la CLI et l’API.

**Gravité :** Critique

## Détails
<a name="audit-chk-device-cert-shared-details"></a>

Lorsqu’elle est effectuée dans le cadre d’un audit à la demande, cette vérification examine les certificats et les ID client qui ont été utilisés par les appareils pour se connecter au cours des 31 jours précédant le début de l’audit jusqu’à 2 heures avant l’exécution de la vérification. Pour les audits planifiés, cette vérification examine les données de 2 heures avant la dernière exécution de l’audit jusqu’à 2 heures avant le début de cette instance d’audit. Si vous avez pris des mesures pour atténuer cette condition pendant la période contrôlée, notez à quel moment les connexions simultanées ont été effectuées pour déterminer si le problème persiste.

Les codes de motif sont renvoyés lorsque ce contrôle trouve un certificat non conforme :
+ CERTIFICATE\$1SHARED\$1BY\$1MULTIPLE\$1DEVICES

En outre, les résultats renvoyés par ce contrôle incluent l’ID du certificat partagé, les ID des clients utilisant le certificat pour se connecter et les heures de connexion/déconnexion. Les résultats les plus récents sont répertoriés en premier.

## Pourquoi est-ce important ?
<a name="audit-chk-device-cert-shared-why-it-matters"></a>

Chaque appareil doit avoir un certificat unique pour s’authentifier auprès d’ AWS IoT. Lorsque plusieurs appareils utilisent le même certificat, cela peut indiquer qu’un appareil est compromis. Son identité peut avoir été clonée pour compromettre davantage le système. 

## Comment réparer
<a name="audit-chk-device-cert-shared-how-to-fix"></a>

Vérifiez que le certificat d’appareil n’a pas été compromis. S’il l’a été, suivez les bonnes pratiques en matière de sécurité pour traiter cette situation. 

Si vous utilisez le même certificat sur plusieurs appareils, vous pouvez :

1. Allouer de nouveaux certificats uniques et les attacher à chaque appareil. 

1. Vérifier que les nouveaux certificats sont valides et que les appareils peuvent les utiliser pour se connecter.

1. Utiliser [UpdateCertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateCertificate.html) pour marquer l’ancien certificat comme REVOKED (RÉVOQUÉ) dans AWS IoT. Vous pouvez également utiliser des actions d’atténuation pour effectuer les opérations suivantes :
   + Appliquer l’action d’atténuation `UPDATE_DEVICE_CERTIFICATE` sur vos résultats d’audit pour effectuer ce changement. 
   + Appliquer l’action d’atténuation `ADD_THINGS_TO_THING_GROUP` pour ajouter le dispositif à un groupe où vous pouvez prendre des mesures à son égard.
   + Appliquer l’action d’atténuation `PUBLISH_FINDINGS_TO_SNS` si vous souhaitez mettre en œuvre une réponse personnalisée pour répondre au message Amazon SNS. 

   Pour de plus amples informations, consultez [Actions d'atténuation](dd-mitigation-actions.md). 

1. Détacher l’ancien certificat de chacun des appareils.

# Qualité de la clé du certificat de l’appareil
<a name="audit-chk-device-cert-key-quality"></a>

Les clients AWS IoT s’appuient souvent sur l’authentification mutuelle TLS à l’aide de certificats X.509 pour s’authentifier auprès de l’agent de messages AWS IoT. Ces certificats et leurs certificats d’autorité de certification doivent être enregistrés dans leur compte AWS IoT avant d’être utilisés. AWS IoT effectue les vérifications d’intégrité élémentaires sur ces certificats lorsqu’ils sont enregistrés. Ces vérifications portent notamment sur les éléments suivants :
+ Le format des certificats doit être valide.
+ Les certificats doivent être signés par une autorité de certification enregistrée.
+ La période de validité des certificats ne doit pas avoir expiré.
+ La taille des clé de chiffrement des certificats doit correspondre à une taille minimale requise (pour les clés RSA, elles doivent être de 2 048 bits ou plus).

Cette vérification d’audit fournit les tests supplémentaires suivants concernant la qualité de votre clé de chiffrement :
+ CVE-2008-0166 – Vérifie si la clé a été générée à l’aide d’OpenSSL versions 0.9.8c-1 à 0.9.8g-9 (non incluse) sur un système d’exploitation basé sur Debian.< Ces versions d’OpenSSL utilisent un générateur de nombres aléatoires qui génère des nombres prévisibles, ce qui facilite les attaques par force brute des clés de chiffrement menées par des personnes malveillantes.
+ CVE-2017-15361 – Vérifiez si la clé a été générée par la bibliothèque Infineon RSA 1.02.013 dans le micrologiciel Infineon Trusted Platform Module (TPM), comme les versions antérieures à 00000000000000422 – 4.34, avant 000000000000062b – 6.43 et avant 0000000000008521 – 133.33. Cette bibliothèque gère de manière incorrecte la génération de clés RSA, ce qui permet aux personnes malveillantes de vaincre plus facilement certains mécanismes de protection de chiffrement grâce à des attaques ciblées. BitLocker avec TPM 1.2, la génération de clés PGP YubiKey 4 (avant 4.3.5) et la fonctionnalité de chiffrement des données utilisateur mises en cache dans Chrome OS sont des exemples de technologies ayant été affectées.

AWS IoT Device Defender déclare les certificats non conformes s’ils échouent à ces tests.

Cette vérification apparaît comme `DEVICE_CERTIFICATE_KEY_QUALITY_CHECK` dans la CLI et l’API.

**Gravité :** Critique

## Détails
<a name="audit-chk-device-cert-key-quality-details"></a>

Ce contrôle s’applique aux certificats d’appareil qui sont ACTIVE ou PENDING\$1TRANSFER.

Les codes de motif sont renvoyés lorsque ce contrôle trouve un certificat non conforme :
+ CERTIFICATE\$1KEY\$1VULNERABILITY\$1CVE-2017-15361
+ CERTIFICATE\$1KEY\$1VULNERABILITY\$1CVE-2008-0166

## Pourquoi est-ce important ?
<a name="audit-chk-device-cert-key-quality-why-it-matters"></a>

Lorsqu’un appareil utilise un certificat vulnérable, les personnes malveillantes peuvent plus facilement le compromettre.

## Comment réparer
<a name="audit-chk-device-cert-key-quality-how-to-fix"></a>

Mettez à jour les certificats de vos appareils afin de remplacer ceux qui présentent des vulnérabilités connues.

Si vous utilisez le même certificat sur plusieurs appareils, vous pouvez :

1. Allouer de nouveaux certificats uniques et les attacher à chaque appareil. 

1. Vérifier que les nouveaux certificats sont valides et que les appareils peuvent les utiliser pour se connecter.

1. Utiliser [UpdateCertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateCertificate.html) pour marquer l’ancien certificat comme REVOKED (RÉVOQUÉ) dans AWS IoT. Vous pouvez également utiliser des actions d’atténuation pour effectuer les actions suivantes :
   + Appliquer l’action d’atténuation `UPDATE_DEVICE_CERTIFICATE` sur vos résultats d’audit pour effectuer ce changement. 
   + Appliquer l’action d’atténuation `ADD_THINGS_TO_THING_GROUP` pour ajouter le dispositif à un groupe où vous pouvez prendre des mesures à son égard.
   + Appliquer l’action d’atténuation `PUBLISH_FINDINGS_TO_SNS` si vous souhaitez mettre en œuvre une réponse personnalisée pour répondre au message Amazon SNS. 

   Pour de plus amples informations, consultez [Actions d'atténuation](dd-mitigation-actions.md). 

1. Détacher l’ancien certificat de chacun des appareils.

# Qualité de la clé du certificat CA
<a name="audit-chk-ca-cert-key-quality"></a>

Les clients AWS IoT s’appuient souvent sur l’authentification mutuelle TLS à l’aide de certificats X.509 pour s’authentifier auprès de l’agent de messages AWS IoT. Ces certificats et leurs certificats d’autorité de certification doivent être enregistrés dans leur compte AWS IoT avant d’être utilisés. AWS IoT effectue des vérifications d’intégrité élémentaires sur ces certificats lorsqu’ils sont enregistrés, notamment :
+ Le format des certificats doit être valide.
+ La période de validité des certificats ne doit pas avoir expiré.
+ La taille des clé de chiffrement des certificats doit correspondre à une taille minimale requise (pour les clés RSA, elles doivent être de 2048 bits ou plus).

Cette vérification d’audit fournit les tests supplémentaires suivants concernant la qualité de votre clé de chiffrement :
+ CVE-2008-0166 – Vérifie si la clé a été générée à l’aide d’OpenSSL versions 0.9.8c-1 à 0.9.8g-9 (non incluse) sur un système d’exploitation basé sur Debian.< Ces versions d’OpenSSL utilisent un générateur de nombres aléatoires qui génère des nombres prévisibles, ce qui facilite les attaques par force brute des clés de chiffrement menées par des personnes malveillantes.
+ CVE-2017-15361 – Vérifiez si la clé a été générée par la bibliothèque Infineon RSA 1.02.013 dans le micrologiciel Infineon Trusted Platform Module (TPM), comme les versions antérieures à 00000000000000422 – 4.34, avant 000000000000062b – 6.43 et avant 0000000000008521 – 133.33. Cette bibliothèque gère de manière incorrecte la génération de clés RSA, ce qui permet aux personnes malveillantes de vaincre plus facilement certains mécanismes de protection de chiffrement grâce à des attaques ciblées. BitLocker avec TPM 1.2, la génération de clés PGP YubiKey 4 (avant 4.3.5) et la fonctionnalité de chiffrement des données utilisateur mises en cache dans Chrome OS sont des exemples de technologies ayant été affectées.

AWS IoT Device Defender déclare les certificats non conformes s’ils échouent à ces tests.

Cette vérification apparaît comme `CA_CERTIFICATE_KEY_QUALITY_CHECK` dans la CLI et l’API.

**Gravité :** Critique

## Détails
<a name="audit-chk-ca-cert-key-quality-details"></a>

Ce contrôle s’applique aux certificats CA ACTIVE ou PENDING\$1TRANSFER.

Les codes de motif sont renvoyés lorsque ce contrôle trouve un certificat non conforme :
+ CERTIFICATE\$1KEY\$1VULNERABILITY\$1CVE-2017-15361
+ CERTIFICATE\$1KEY\$1VULNERABILITY\$1CVE-2008-0166

## Pourquoi est-ce important ?
<a name="audit-chk-ca-cert-key-quality-why-it-matters"></a>

Les appareils nouvellement ajoutés signés à l’aide de ce certificat CA peuvent constituer une menace pour la sécurité.

## Comment réparer
<a name="audit-chk-ca-cert-key-quality-how-to-fix"></a>

1. Utilisez [UpdateCACertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateCACertificate.html) pour marquer le certificat CA comme INACTIVE (INACTIF) dans AWS IoT. Vous pouvez également utiliser des actions d’atténuation pour effectuer les actions suivantes :
   + Appliquer l’action d’atténuation `UPDATE_CA_CERTIFICATE` sur vos résultats d’audit pour effectuer ce changement. 
   + Appliquer l’action d’atténuation `PUBLISH_FINDINGS_TO_SNS` si vous souhaitez mettre en œuvre une réponse personnalisée pour répondre au message Amazon SNS. 

   Pour de plus amples informations, consultez [Actions d'atténuation](dd-mitigation-actions.md).

1. Vérifiez l’activité d’enregistrement de certificat d’appareil pendant la période après laquelle le certificat de CA a été révoqué et envisagez de révoquer les certificats d’appareil qui ont pu être émis pendant cette période. (Utilisez [ListCertificatesByCA](https://docs.aws.amazon.com/iot/latest/apireference/API_ListCertificatesByCA.html) pour répertorier les certificats d’appareil signés par le certificat CA et [UpdateCertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateCertificate.html) pour révoquer un certificat d’appareil.)

# Le rôle Cognito non authentifié est trop permissif
<a name="audit-chk-unauth-cognito-role-permissive"></a>

Une politique attachée à un rôle de réserve d’identités Amazon Cognito non authentifié est considérée comme trop permissive, car elle accorde l’autorisation d’effectuer l’une des actions AWS IoT suivantes :
+ Gérer ou modifier des objets.
+ Lire les données administratives d’objet.
+ Gérer les données ou ressources liées à d’autres éléments que les objets.

Ou, car elle accorde l’autorisation d’effectuer les actions AWS IoT suivantes sur une large gamme d’appareils :
+ Utiliser MQTT pour la connexion, la publication, l’abonnement aux rubriques réservées (y compris les données de shadow ou d’exécution des tâches).
+ Utiliser les commandes d’API pour lire ou modifier les données shadow ou d’exécution des tâches.

En général, les appareils qui se connectent à l’aide d’un rôle de réserve d’identités Amazon Cognito non authentifié ne doivent disposer que d’une autorisation limitée pour publier et s’abonner à des sujets MQTT spécifiques à un objet ou utiliser les commandes API pour lire et modifier des données spécifiques à un objet liées aux données d’exécution de tâches ou d’observation.

Cette vérification apparaît comme `UNAUTHENTICATED_COGNITO_ROLE_OVERLY_PERMISSIVE_CHECK` dans la CLI et l’API.

**Gravité :** Critique

## Détails
<a name="audit-chk-unauth-cognito-role-permissive-details"></a>

Pour cette vérification, AWS IoT Device Defender audite tous les groupes d’identités Amazon Cognito qui ont été utilisés pour se connecter à l’agent de messages AWS IoT au cours des 31 jours précédant l’exécution de l’audit. Toutes les réserves d’identité Amazon Cognito à partir desquels une identité Amazon Cognito authentifiée ou non est connectée sont inclus dans l’audit.

Les codes de motif suivants sont renvoyés lorsque cette vérification détecte un rôle de réserve d’identités Amazon Cognito non authentifié et non conforme :
+ ALLOWS\$1ACCESS\$1TO\$1IOT\$1ADMIN\$1ACTIONS
+ ALLOWS\$1BROAD\$1ACCESS\$1TO\$1IOT\$1DATA\$1PLANE\$1ACTIONS

## Pourquoi est-ce important ?
<a name="audit-chk-unauth-cognito-role-permissive-why-it-matters"></a>

Comme les identités non authentifiées ne sont jamais authentifiées par l’utilisateur, elles présentent un risque bien plus élevé que les identités Amazon Cognito authentifiées. Si une identité non authentifiée est compromise, elle peut utiliser les actions administratives pour modifier des paramètres du compte, supprimer des ressources ou accéder à des données sensibles. Ou, avec un large accès aux paramètres de l’appareil, elle peut accéder ou modifier des shadows et des tâches pour tous les appareils de votre compte. Un utilisateur invité pourrait utiliser les autorisations pour compromettre l’ensemble de votre flotte ou lancer une attaque DDOS à l’aide de messages.

## Comment réparer
<a name="audit-chk-unauth-cognito-role-permissive-how-to-fix"></a>

Une politique attachée à un rôle de réserve d’identités Amazon Cognito non authentifié doit accorder uniquement les autorisations requises pour qu’un appareil fasse son travail. Nous vous recommandons la procédure suivante :

1. Créez un nouveau rôle conforme.

1. Créez un réserve d’identités Amazon Cognito et attachez le rôle adéquat..

1. Vérifiez que vos identités peuvent accéder à AWS IoT à l’aide du nouveau groupe.

1. Lorsque le contrôle est terminé, attachez le rôle conforme au réserve d’identités Amazon Cognito qui a été signalé comme non conforme.

Vous pouvez également utiliser des actions d’atténuation pour effectuer les actions suivantes :
+ Appliquez l’action d’atténuation `PUBLISH_FINDINGS_TO_SNS` si vous souhaitez mettre en œuvre une réponse personnalisée pour répondre au message Amazon SNS. 

Pour de plus amples informations, consultez [Actions d'atténuation](dd-mitigation-actions.md). 

## Gérer ou modifier des objets
<a name="manage-modify-things-check"></a>

Les actions d’API AWS IoT suivantes sont utilisées pour gérer ou modifier des objets. L’autorisation d’exécuter ces actions ne doit pas être accordée aux appareils se connectant via une réserve d’identités Amazon Cognito non authentifiée.
+ `AddThingToThingGroup` 
+ `AttachThingPrincipal` 
+ `CreateThing` 
+ `DeleteThing` 
+ `DetachThingPrincipal` 
+ `ListThings` 
+ `ListThingsInThingGroup` 
+ `RegisterThing` 
+ `RemoveThingFromThingGroup` 
+ `UpdateThing` 
+ `UpdateThingGroupsForThing` 

Tout rôle qui accorde l’autorisation d’effectuer ces actions sur une seule ressource est considéré comme non conforme.

## Lire les données administratives d’objet
<a name="read-thing-admin-data-check"></a>

Les actions d’API AWS IoT suivantes sont utilisées pour lire ou modifier les données d’objet. L’autorisation d’exécuter ces actions ne doit pas être accordée aux appareils se connectant via une réserve d’identités Amazon Cognito non authentifiée.
+ `DescribeThing`
+ `ListJobExecutionsForThing`
+ `ListThingGroupsForThing`
+ `ListThingPrincipals`

**Example**  
+ non conforme :

------
#### [ JSON ]

****  

  ```
  {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
      {
        "Sid": "AllowIoTThingOperations",
        "Effect": "Allow",
        "Action": [ 
            "iot:DescribeThing",
            "iot:ListJobExecutionsForThing",
            "iot:ListThingGroupsForThing",
            "iot:ListThingPrincipals"
        ],
        "Resource": [
          "arn:aws:iot:us-east-1:123456789012:thing/name-of-thing"
        ]
      }
    ]
  }
  ```

------

  Cela permet à l’appareil d’effectuer les actions spécifiées, même si l’action est accordée pour un seul objet.

## Gérer les non-objets
<a name="manage-non-things-check"></a>

Les appareils qui se connectent par le biais d’une réserve d’identités Amazon Cognito non authentifiées ne doivent pas être autorisés à effectuer des actions d’API AWS IoT autres que celles présentées dans les sections suivantes. Afin de gérer votre compte avec une application qui se connecte via une réserve d’identités Amazon Cognito non authentifiée, créez une autre réserve d’identités non utilisé par les appareils.

## S’abonner/publier sur les rubriques MQTT
<a name="audit-chk-unauth-cognito-role-permissive-mqtt-topics"></a>

Les messages MQTT sont envoyés via l’agent de messages AWS IoT et sont utilisés par les appareils afin d’effectuer diverses actions, dont l’accès à l’état du shadow et sa modification, ainsi que l’état de l’exécution des tâches. Une stratégie qui accorde l’autorisation à un appareil de se connecter à des messages MQTT, de les publier ou de s’y abonner, doit limiter ces actions à des ressources spécifiques comme suit :

**Connexion**  
+ non conforme :

  ```
  arn:aws:iot:region:account-id:client/*
  ```

  Le caractère générique « \$1 » permet à n’importe quel appareil de se connecter à AWS IoT.

  ```
  arn:aws:iot:region:account-id:client/${iot:ClientId}
  ```

  Sauf si `iot:Connection.Thing.IsAttached` est défini sur true dans les clés de condition, c’est l’équivalent du caractère générique « \$1 » dans l’exemple précédent.
+ conforme :

------
#### [ JSON ]

****  

  ```
  {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "iot:Connect"
        ],
        "Resource": [
          "arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}"
        ]
      }
    ]
  }
  ```

------

  La spécification de ressource contient une variable qui correspond au nom de l’appareil utilisé pour la connexion. L’instruction de condition limite encore l’autorisation en vérifiant que le certificat utilisé par le client MQTT correspondent à celui attaché à l’objet avec le nom utilisé.

**Publication**  
+ non conforme :

  ```
  arn:aws:iot:region:account-id:topic/$aws/things/*/shadow/update
  ```

  Cela permet à l’appareil de mettre à jour le shadow de n’importe quel appareil (\$1 = tous les appareils).

  ```
  arn:aws:iot:region:account-id:topic/$aws/things/*
  ```

  Cela permet à l’appareil de lire, mettre à jour ou supprimer le shadow de n’importe quel appareil.
+ conforme :

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "iot:Publish"
              ],
              "Resource": [
                  "arn:aws:iot:us-east-1:123456789012:topic/$aws/things/${iot:Connection.Thing.ThingName}/shadow/*"
              ]
          }
      ]
  }
  ```

------

  La spécification de ressource contient un caractère générique, mais il correspond uniquement à une rubrique liée au shadow pour l’appareil dont le nom d’objet est utilisé pour la connexion.

**S’abonner**  
+ non conforme :

  ```
  arn:aws:iot:region:account-id:topicfilter/$aws/things/*
  ```

  Cela permet à l’appareil de s’abonner aux rubriques de shadow ou de tâche réservées pour tous les appareils.

  ```
  arn:aws:iot:region:account-id:topicfilter/$aws/things/*
  ```

  Identique à l’exemple précédent, mais à l’aide du caractère générique \$1.

  ```
  arn:aws:iot:region:account-id:topicfilter/$aws/things/+/shadow/update
  ```

  Cela permet à l’appareil d’afficher les mises à jour du shadow sur n’importe quel appareil (\$1 = tous les appareils).
+ conforme :

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "iot:Subscribe"
              ],
              "Resource": [
                  "arn:aws:iot:us-east-1:123456789012:topicfilter/$aws/things/${iot:Connection.Thing.ThingName}/shadow/*",
                  "arn:aws:iot:us-east-1:123456789012:topicfilter/$aws/things/${iot:Connection.Thing.ThingName}/jobs/*"
              ]
          }
      ]
  }
  ```

------

  La spécification de ressource contient des caractères génériques, mais ils correspondent uniquement à une rubrique liée au shadow ou à une tâche pour l’appareil dont le nom d’objet est utilisé pour la connexion.

**Réception**  
+ conforme :

  ```
  arn:aws:iot:region:account-id:topicfilter/$aws/things/*
  ```

  Cela est acceptable, car le dispositif peut recevoir uniquement des messages à partir de rubriques auxquelles il a l’autorisation de s’abonner.

## Lecture/modification des données shadow ou de tâche
<a name="read-modify-shadow-job-data-check"></a>

Une stratégie qui accorde l’autorisation à un appareil d’exécuter une action d’API pour accéder aux données des shadows d’appareil ou d’exécution des tâches, ou les modifier, doit limiter ces actions à des ressources spécifiques. Voici les actions d’API :
+ `DeleteThingShadow`
+ `GetThingShadow`
+ `UpdateThingShadow`
+ `DescribeJobExecution`
+ `GetPendingJobExecutions`
+ `StartNextPendingJobExecutio`n
+ `UpdateJobExecution`

**Example**  
+ non conforme :

  ```
  arn:aws:iot:region:account-id:thing/*
  ```

  Cela permet à l’appareil d’effectuer l’action spécifiée sur n’importe quel objet.
+ conforme :

------
#### [ JSON ]

****  

  ```
  {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [ 
            "iot:DeleteThingShadow",
            "iot:GetThingShadow",
            "iot:UpdateThingShadow",
            "iotjobsdata:DescribeJobExecution",
            "iotjobsdata:GetPendingJobExecutions",
            "iotjobsdata:StartNextPendingJobExecution",
            "iotjobsdata:UpdateJobExecution"
        ],
        "Resource": [
          "arn:aws:iot:us-east-1:123456789012:thing/MyThing1",
          "arn:aws:iot:us-east-1:123456789012:thing/MyThing2"
        ]
      }
    ]
  }
  ```

------

  Cela permet à l’appareil d’effectuer les actions spécifiées sur deux objets uniquement.

# Le rôle de Cognito authentifié est trop permissif
<a name="audit-chk-auth-cognito-role-permissive"></a>

Une stratégie attachée à un rôle de réserve d’identités Amazon Cognito authentifié est considérée comme trop permissive, car elle accorde l’autorisation d’effectuer les actions suivantes AWS IoT :
+ Gérer ou modifier des objets.
+ Gérer les données ou ressources liées à d’autres éléments que les objets.

Ou, car elle accorde l’autorisation d’effectuer les actions AWS IoT suivantes sur une large gamme d’appareils :
+ Lire les données administratives d’objet.
+ Utiliser MQTT pour la connexion/la publication/l’abonnement aux rubriques réservées (y compris les données shadow ou d’exécution des tâches).
+ Utiliser les commandes d’API pour lire ou modifier les données shadow ou d’exécution des tâches.

En général, les appareils qui se connectent à l’aide d’un rôle de réserve d’identités Amazon Cognito authentifié ne doivent disposer que d’une autorisation limitée pour lire les données administratives spécifiques à un objet, publier et s’abonner à des rubriques MQTT spécifiques à un objet, ou utiliser les commandes API pour lire et modifier des données spécifiques à un objet liés aux données miroir ou d’exécution de tâches.

Cette vérification apparaît comme `AUTHENTICATED_COGNITO_ROLE_OVERLY_PERMISSIVE_CHECK` dans la CLI et l’API.

**Gravité :** Critique

## Détails
<a name="audit-chk-auth-cognito-role-permissive-details"></a>

Pour cette vérification, AWS IoT Device Defender audite tous les groupes d’identités Amazon Cognito qui ont été utilisés pour se connecter à l’agent de messages AWS IoT au cours des 31 jours précédant l’exécution de l’audit. Toutes les réserves d’identité Amazon Cognito à partir desquels une identité Amazon Cognito authentifiée ou non est connectée sont inclus dans l’audit.

Voici les codes de motif renvoyés lorsque ce contrôle trouve un groupe d’identités Amazon Cognito authentifiées non conforme :
+ ALLOWS\$1BROAD\$1ACCESS\$1TO\$1IOT\$1THING\$1ADMIN\$1READ\$1ACTIONS
+ ALLOWS\$1ACCESS\$1TO\$1IOT\$1NON\$1THING\$1ADMIN\$1ACTIONS
+ ALLOWS\$1ACCESS\$1TO\$1IOT\$1THING\$1ADMIN\$1WRITE\$1ACTIONS

## Pourquoi est-ce important ?
<a name="audit-chk-auth-cognito-role-permissive-why-it-matters"></a>

Si une identité authentifiée est compromise, elle peut utiliser les actions administratives pour modifier des paramètres du compte, supprimer des ressources ou accéder à des données sensibles.

## Comment réparer
<a name="audit-chk-auth-cognito-role-permissive-how-to-fix"></a>

Une stratégie attachée à un rôle de groupe d’identités Amazon Cognito authentifiées doit accorder uniquement les autorisations requises pour qu’un appareil fasse son travail. Nous vous recommandons la procédure suivante :

1. Créez un nouveau rôle conforme.

1. Créez un réserve d’identités Amazon Cognito et attachez le rôle adéquat..

1. Vérifiez que vos identités peuvent accéder à AWS IoT à l’aide du nouveau groupe.

1. Lorsque le contrôle est terminé, attachez le rôle conforme au réserve d’identités Amazon Cognito qui a été signalé comme non conforme.

Vous pouvez également utiliser des actions d’atténuation pour effectuer les actions suivantes :
+ Appliquez l’action d’atténuation `PUBLISH_FINDINGS_TO_SNS` si vous souhaitez mettre en œuvre une réponse personnalisée pour répondre au message Amazon SNS. 

Pour de plus amples informations, consultez [Actions d'atténuation](dd-mitigation-actions.md). 

## Gérer ou modifier des objets
<a name="audit-chk-auth-cognito-role-permissive-manage-things"></a>

Les actions d’API AWS IoT suivantes sont utilisées pour gérer ou modifier les objets afin que l’autorisation de les exécuter ne soit pas accordée aux appareils se connectant via un réserve d’identités Amazon Cognito authentifiées :
+ `AddThingToThingGroup` 
+ `AttachThingPrincipal` 
+ `CreateThing` 
+ `DeleteThing` 
+ `DetachThingPrincipal` 
+ `ListThings`
+ `ListThingsInThingGroup` 
+ `RegisterThing` 
+ `RemoveThingFromThingGroup` 
+ `UpdateThing` 
+ `UpdateThingGroupsForThing`

Tout rôle qui accorde l’autorisation d’effectuer ces actions sur une seule ressource est considéré comme non conforme.

## Gérer les non-objets
<a name="audit-chk-auth-cognito-role-permissive-manage-non-things"></a>

Les appareils qui se connectent par le biais d’une réserve d’identités Amazon Cognito authentifiées ne doivent pas être autorisés à effectuer des actions d’API AWS IoT autres que celles présentées dans les sections suivantes. Afin de gérer votre compte avec une application qui se connecte via une réserve d’identités Amazon Cognito authentifiées, créez un autre groupe d’identités non utilisé par les appareils.

## Lire les données administratives d’objet
<a name="audit-chk-auth-cognito-role-permissive-read-things-admin-data"></a>

Les actions d’API AWS IoT suivantes sont utilisées pour lire les données des objets afin que les appareils se connectant via une réserve d’identités Amazon Cognito authentifiées reçoive l’autorisation de ne les exécuter que sur un ensemble limité d’objets :
+ `DescribeThing`
+ `ListJobExecutionsForThing`
+ `ListThingGroupsForThing`
+ `ListThingPrincipals`
+ non conforme :

  ```
  arn:aws:iot:region:account-id:thing/*
  ```

  Cela permet à l’appareil d’effectuer l’action spécifiée sur n’importe quel objet.
+ conforme :

------
#### [ JSON ]

****  

  ```
  {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [ 
            "iot:DescribeThing",
            "iot:ListJobExecutionsForThing",
            "iot:ListThingGroupsForThing",
            "iot:ListThingPrincipals"
        ],
        "Resource": [
          "arn:aws:iot:us-east-1:123456789012:thing/MyThing"
        ]
      }
    ]
  }
  ```

------

  Cela permet à l’appareil d’effectuer les actions spécifiées sur un seul objet.
+ conforme :

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "iot:DescribeThing",
                  "iot:ListJobExecutionsForThing",
                  "iot:ListThingGroupsForThing",
                  "iot:ListThingPrincipals"
              ],
              "Resource": [
                  "arn:aws:iot:us-east-1:123456789012:thing/MyThing*"
              ]
          }
      ]
  }
  ```

------

  Cela est conforme, car même si la ressource est spécifiée à l’aide d’un caractère générique (« \$1 »), elle est précédée d’une chaîne spécifique qui limite l’ensemble des éléments accessibles à ceux dont les noms ont le préfixe donné.
+ non conforme :

  ```
  arn:aws:iot:region:account-id:thing/*
  ```

  Cela permet à l’appareil d’effectuer l’action spécifiée sur n’importe quel objet.
+ conforme :

------
#### [ JSON ]

****  

  ```
  {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [ 
            "iot:DescribeThing",
            "iot:ListJobExecutionsForThing",
            "iot:ListThingGroupsForThing",
            "iot:ListThingPrincipals"
        ],
        "Resource": [
          "arn:aws:iot:us-east-1:123456789012:thing/MyThing"
        ]
      }
    ]
  }
  ```

------

  Cela permet à l’appareil d’effectuer les actions spécifiées sur un seul objet.
+ conforme :

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "iot:DescribeThing",
                  "iot:ListJobExecutionsForThing",
                  "iot:ListThingGroupsForThing",
                  "iot:ListThingPrincipals"
              ],
              "Resource": [
                  "arn:aws:iot:us-east-1:123456789012:thing/MyThing*"
              ]
          }
      ]
  }
  ```

------

  Cela est conforme, car même si la ressource est spécifiée à l’aide d’un caractère générique (« \$1 »), elle est précédée d’une chaîne spécifique qui limite l’ensemble des éléments accessibles à ceux dont les noms ont le préfixe donné.

## S’abonner/publier sur les rubriques MQTT
<a name="audit-chk-auth-cognito-role-permissive-mqtt-topic"></a>

Les messages MQTT sont envoyés via l’agent de messages AWS IoT et sont utilisés par les appareils pour effectuer diverses actions, dont l’accès à l’état du shadow et d’exécution des tâches, ainsi que sa modification. Une stratégie qui accorde l’autorisation à un appareil de se connecter à des messages MQTT, de les publier ou de s’y abonner, doit limiter ces actions à des ressources spécifiques comme suit :

**Connexion**  
+ non conforme :

  ```
  arn:aws:iot:region:account-id:client/*
  ```

  Le caractère générique « \$1 » permet à n’importe quel appareil de se connecter à AWS IoT.

  ```
  arn:aws:iot:region:account-id:client/${iot:ClientId}
  ```

  Sauf si `iot:Connection.Thing.IsAttached` est défini sur true dans les clés de condition, c’est l’équivalent du caractère générique « \$1 » dans l’exemple précédent.
+ conforme :

------
#### [ JSON ]

****  

  ```
  {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "iot:Connect"
        ],
        "Resource": [
          "arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}"
        ]
      }
    ]
  }
  ```

------

  La spécification de ressource contient une variable qui correspond au nom de l’appareil utilisé pour se connecter et la déclaration de la condition limite plus avant l’autorisation en vérifiant que le certificat utilisé par le client MQTT correspond à celui attaché à l’objet avec le nom utilisé.

**Publication**  
+ non conforme :

  ```
  arn:aws:iot:region:account-id:topic/$aws/things/*/shadow/update
  ```

  Cela permet à l’appareil de mettre à jour le shadow de n’importe quel appareil (\$1 = tous les appareils).

  ```
  arn:aws:iot:region:account-id:topic/$aws/things/*
  ```

  Cela permet à l’appareil de lire/mettre à jour/supprimer le shadow de n’importe quel appareil.
+ conforme :

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "iot:Publish"
              ],
              "Resource": [
                  "arn:aws:iot:us-east-1:123456789012:topic/$aws/things/${iot:Connection.Thing.ThingName}/shadow/*"
              ]
          }
      ]
  }
  ```

------

  La spécification de ressource contient un caractère générique, mais il correspond uniquement à une rubrique liée au shadow pour l’appareil dont le nom d’objet est utilisé pour la connexion.

**S’abonner**  
+ non conforme :

  ```
  arn:aws:iot:region:account-id:topicfilter/$aws/things/*
  ```

  Cela permet à l’appareil de s’abonner aux rubriques de shadow ou de tâche réservées pour tous les appareils.

  ```
  arn:aws:iot:region:account-id:topicfilter/$aws/things/#
  ```

  Identique à l’exemple précédent, mais à l’aide du caractère générique \$1.

  ```
  arn:aws:iot:region:account-id:topicfilter/$aws/things/+/shadow/update
  ```

  Cela permet à l’appareil d’afficher les mises à jour du shadow sur n’importe quel appareil (\$1 = tous les appareils).
+ conforme :

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "iot:Subscribe"
              ],
              "Resource": [
                  "arn:aws:iot:us-east-1:123456789012:topicfilter/$aws/things/${iot:Connection.Thing.ThingName}/shadow/*",
                  "arn:aws:iot:us-east-1:123456789012:topicfilter/$aws/things/${iot:Connection.Thing.ThingName}/jobs/*"
              ]
          }
      ]
  }
  ```

------

  La spécification de ressource contient des caractères génériques, mais ils correspondent uniquement à une rubrique liée au shadow ou à une tâche pour l’appareil dont le nom d’objet est utilisé pour la connexion.

**Réception**  
+ conforme :

  ```
  arn:aws:iot:region:account-id:topicfilter/$aws/things/*
  ```

  Conforme, car l’appareil peut uniquement recevoir des messages à partir de rubriques auxquelles il est autorisé à s’abonner.

## Lire ou modifier les données shadow ou de tâche
<a name="audit-chk-auth-cognito-role-permissive-shadow-job-data"></a>

Une stratégie qui accorde l’autorisation à un appareil d’exécuter une action d’API pour accéder aux données des shadows d’appareil ou d’exécution des tâches, ou les modifier, doit limiter ces actions à des ressources spécifiques. Voici les actions d’API :
+ `DeleteThingShadow`
+ `GetThingShadow`
+ `UpdateThingShadow`
+ `DescribeJobExecution`
+ `GetPendingJobExecutions`
+ `StartNextPendingJobExecution`
+ `UpdateJobExecution`

**Exemples d**
+ non conforme :

  ```
  arn:aws:iot:region:account-id:thing/*
  ```

  Cela permet à l’appareil d’effectuer l’action spécifiée sur n’importe quel objet.
+ conforme :

------
#### [ JSON ]

****  

  ```
  {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "iot:DeleteThingShadow",
          "iot:GetThingShadow",
          "iot:UpdateThingShadow",
          "iot:DescribeJobExecution",
          "iotjobsdata:DescribeJobExecution",
          "iotjobsdata:UpdateJobExecution"
        ],
        "Resource": [
          "arn:aws:iot:us-east-1:123456789012:thing/MyThing1",
          "arn:aws:iot:us-east-1:123456789012:thing/MyThing2"
        ]
      }
    ]
  }
  ```

------

  Cela permet à l’appareil d’effectuer les actions spécifiées sur deux objets uniquement.

# Politiques AWS IoT trop permissives
<a name="audit-chk-iot-policy-permissive"></a>

Une stratégie AWS IoT accorde des autorisations qui sont trop larges ou illimitées. Elle accorde l’autorisation d’envoyer ou de recevoir des messages MQTT pour une large gamme d’appareils, ou accorde l’autorisation d’accéder aux données shadow et d’exécution des tâches (ou de les modifier) pour un vaste éventail d’appareils. 

En général, une stratégie pour un appareil doit accorder l’accès à des ressources associées pratiquement à ce seul appareil. Avec certaines exceptions, l’utilisation d’un caractère générique (par exemple, « \$1 ») pour spécifier des ressources dans une telle stratégie est considérée comme trop large ou illimitée.

Cette vérification apparaît comme `IOT_POLICY_OVERLY_PERMISSIVE_CHECK` dans la CLI et l’API.

**Gravité :** Critique

## Détails
<a name="audit-chk-iot-policy-permissive-details"></a>

Le code de motif suivant est renvoyé lorsque ce contrôle trouve une stratégie AWS IoT non conforme :
+ ALLOWS\$1BROAD\$1ACCESS\$1TO\$1IOT\$1DATA\$1PLANE\$1ACTIONS

## Pourquoi est-ce important ?
<a name="audit-chk-iot-policy-permissive-why-it-matters"></a>

Un certificat, une identité Amazon Cognito ou un groupe d’objets avec une stratégie trop permissive, peuvent influer, en cas de compromission, sur la sécurité de l’ensemble de votre compte. Un pirate informatique pourrait utiliser un tel accès étendu pour lire ou modifier les shadows, les tâches ou les exécutions de tâche de tous vos appareils. Ou un pirate peut utiliser un certificat mis en danger pour connecter des appareils malveillantes ou lancer une attaque DDOS sur votre réseau.

## Comment réparer
<a name="audit-chk-iot-policy-permissive-how-to-fix"></a>

Suivez ces étapes pour corriger les stratégies non conformes attachées à des objets, des groupes d’objets ou d’autres entités :

1. Utilisez [CreatePolicyVersion](https://docs.aws.amazon.com/iot/latest/apireference/API_CreatePolicyVersion.html) pour créer une nouvelle version conforme de la stratégie. Définissez l’indicateur `setAsDefault` sur true. (Cela rend cette nouvelle version opérationnelle pour toutes les entités qui utilisent la stratégie.)

1. Utilisez [ListTargetsForPolicy](https://docs.aws.amazon.com/iot/latest/apireference/API_ListTargetsForPolicy.html) pour obtenir la liste des cibles (certificats, groupes d’objets) auxquelles la stratégie est attachée et déterminer les appareils qui sont inclus dans les groupes ou qui utilisent les certificats pour se connecter.

1. Vérifiez que tous les appareils associés sont en mesure de se connecter à AWS IoT. Si un appareil n’est pas en mesure de se connecter, utilisez [ SetPolicyVersion](https://docs.aws.amazon.com/iot/latest/apireference/API_SetPolicyVersion.html) pour restaurer la stratégie par défaut à la version précédente, révisez la stratégie et faites une nouvelle tentative. 

Vous pouvez utiliser des actions d’atténuation pour effectuer les actions suivantes :
+ Appliquer l’action d’atténuation `REPLACE_DEFAULT_POLICY_VERSION` sur vos résultats d’audit pour effectuer ce changement. 
+ Appliquer l’action d’atténuation `PUBLISH_FINDINGS_TO_SNS` si vous souhaitez mettre en œuvre une réponse personnalisée pour répondre au message Amazon SNS. 

Pour de plus amples informations, consultez [Actions d'atténuation](dd-mitigation-actions.md). 

Consultez [Variables de stratégie AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/iot-policy-variables.html) pour faire référence de manière dynamique aux ressources AWS IoT dans vos politiques.

## Autorisations MQTT
<a name="audit-chk-iot-policy-permissive-mqtt-permissions"></a>

Les messages MQTT sont envoyés via l’agent de messages AWS IoT et sont utilisés par les appareils afin d’effectuer diverses actions, dont l’accès à l’état du shadow et sa modification, ainsi que l’état de l’exécution des tâches. Une stratégie qui accorde l’autorisation à un appareil de se connecter à des messages MQTT, de les publier ou de s’y abonner, doit limiter ces actions à des ressources spécifiques comme suit :

**Connexion**  
+ non conforme :

  ```
  arn:aws:iot:region:account-id:client/*
  ```

  Le caractère générique « \$1 » permet à n’importe quel appareil de se connecter à AWS IoT.

  ```
  arn:aws:iot:region:account-id:client/${iot:ClientId}
  ```

  Sauf si `iot:Connection.Thing.IsAttached` est défini sur true dans les clés de condition, c’est l’équivalent du caractère générique « \$1 » comme dans l’exemple précédent.
+ conforme :

------
#### [ JSON ]

****  

  ```
  {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "iot:Connect"
        ],
        "Resource": [
          "arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}"
        ]
      }
    ]
  }
  ```

------

  La spécification de ressource contient une variable qui correspond au nom de l’appareil utilisé pour la connexion. L’instruction de condition limite encore l’autorisation en vérifiant que le certificat utilisé par le client MQTT correspondent à celui attaché à l’objet avec le nom utilisé.

**Publication**  
+ non conforme :

  ```
  arn:aws:iot:region:account-id:topic/$aws/things/*/shadow/update
  ```

  Cela permet à l’appareil de mettre à jour le shadow de n’importe quel appareil (\$1 = tous les appareils).

  ```
  arn:aws:iot:region:account-id:topic/$aws/things/*
  ```

  Cela permet à l’appareil de lire, mettre à jour ou supprimer le shadow de n’importe quel appareil.
+ conforme :

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "iot:Publish"
              ],
              "Resource": [
                  "arn:aws:iot:us-east-1:123456789012:topic/$aws/things/${iot:Connection.Thing.ThingName}/shadow/*"
              ]
          }
      ]
  }
  ```

------

  La spécification de ressource contient un caractère générique, mais il correspond uniquement à une rubrique liée au shadow pour l’appareil dont le nom d’objet est utilisé pour la connexion.

**S’abonner**  
+ non conforme :

  ```
  arn:aws:iot:region:account-id:topicfilter/$aws/things/*
  ```

  Cela permet à l’appareil de s’abonner aux rubriques de shadow ou de tâche réservées pour tous les appareils.

  ```
  arn:aws:iot:region:account-id:topicfilter/$aws/things/*
  ```

  Identique à l’exemple précédent, mais à l’aide du caractère générique \$1.

  ```
  arn:aws:iot:region:account-id:topicfilter/$aws/things/+/shadow/update
  ```

  Cela permet à l’appareil d’afficher les mises à jour du shadow sur n’importe quel appareil (\$1 = tous les appareils).
+ conforme :

------
#### [ JSON ]

****  

  ```
  {
      "Version":"2012-10-17",		 	 	 
      "Statement": [
          {
              "Effect": "Allow",
              "Action": [
                  "iot:Subscribe"
              ],
              "Resource": [
                  "arn:aws:iot:us-east-1:123456789012:topicfilter/$aws/things/${iot:Connection.Thing.ThingName}/shadow/*",
                  "arn:aws:iot:us-east-1:123456789012:topicfilter/$aws/things/${iot:Connection.Thing.ThingName}/jobs/*"
              ]
          }
      ]
  }
  ```

------

  La spécification de ressource contient des caractères génériques, mais ils correspondent uniquement à une rubrique liée au shadow ou à une tâche pour l’appareil dont le nom d’objet est utilisé pour la connexion.

**Réception**  
+ conforme :

  ```
  arn:aws:iot:region:account-id:topic/$aws/things/*
  ```

  Conforme, car l’appareil peut uniquement recevoir des messages à partir de rubriques auxquelles il est autorisé à s’abonner.

## Autorisations de tâche et de shadow
<a name="shadow-job-permissions"></a>

Une stratégie qui accorde l’autorisation à un appareil d’exécuter une action d’API pour accéder aux données des shadows d’appareil ou d’exécution des tâches, ou les modifier, doit limiter ces actions à des ressources spécifiques. Voici les actions d’API :
+ `DeleteThingShadow`
+ `GetThingShadow`
+ `UpdateThingShadow`
+ `DescribeJobExecution`
+ `GetPendingJobExecutions`
+ `StartNextPendingJobExecution`
+ `UpdateJobExecution`

**Exemples d**
+ non conforme :

  ```
  arn:aws:iot:region:account-id:thing/*
  ```

  Cela permet à l’appareil d’effectuer l’action spécifiée sur n’importe quel objet.
+ conforme :

------
#### [ JSON ]

****  

  ```
  {
    "Version":"2012-10-17",		 	 	 
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [ 
            "iot:DeleteThingShadow",
            "iot:GetThingShadow",
            "iot:UpdateThingShadow",
            "iotjobsdata:DescribeJobExecution",
            "iotjobsdata:GetPendingJobExecutions",
            "iotjobsdata:StartNextPendingJobExecution",
            "iotjobsdata:UpdateJobExecution"
        ],
        "Resource": [
          "arn:aws:iot:us-east-1:123456789012:thing/MyThing1",
          "arn:aws:iot:us-east-1:123456789012:thing/MyThing2"
        ]
      }
    ]
  }
  ```

------

  Cela permet à l’appareil d’effectuer les actions spécifiées sur deux objets uniquement.

# Politique AWS IoT potentiellement mal configurée
<a name="audit-chk-iot-misconfigured-policies"></a>

Une politique AWS IoT a été identifiée comme potentiellement mal configurée. Des politiques mal configurées, notamment des politiques trop permissives, peuvent provoquer des incidents de sécurité tels que le fait de permettre aux appareils d’accéder à des ressources inattendues.

La vérification de la politique **AWS IoT potentiellement mal configurée** est un avertissement qui vous permet de vous assurer que seules les actions prévues sont autorisées avant de mettre à jour la politique.

Dans la CLI et l’API, cette vérification apparaît comme `IOT_POLICY_POTENTIAL_MISCONFIGURATION_CHECK`

**Gravité :** Moyenne

## Détails
<a name="audit-chk-iot-misconfigured-policies-details"></a>

AWS IoT renvoie le code de motif suivant lorsque cette vérification détecte une politique AWS IoT potentiellement mal configurée :
+ POLICY\$1CONTAINS\$1MQTT\$1WILDCARDS\$1IN\$1DENY\$1STATEMENT
+ TOPIC\$1FILTERS\$1INTENDED\$1TO\$1DENY\$1ALLOWED\$1USING\$1WILDCARDS

## Pourquoi est-ce important ?
<a name="audit-chk-iot-misconfigured-policies-why-it-matters"></a>

Des politiques mal configurées peuvent entraîner des conséquences inattendues en accordant plus d’autorisations aux appareils que nécessaire. Nous recommandons d’examiner attentivement la politique afin de limiter l’accès aux ressources et de prévenir les menaces de sécurité.

### La politique contient des caractères génériques MQTT dans un exemple de déclaration de refus
<a name="example-section-id"></a>

La politique **AWS IoT de vérification potentiellement mal configurée** inspecte la présence de caractères génériques MQTT (`+` ou `#`) dans les instructions de refus. Les caractères génériques sont traités comme des chaînes littérales par les politiques AWS IoT et peuvent rendre la politique trop permissive.

L’exemple suivant vise à refuser l’abonnement à des sujets liés à `building/control_room` à l’aide du caractère générique MQTT dans les politiques `#`. Cependant, les caractères génériques MQTT n’ont pas de signification générique dans les politiques AWS IoT auxquelles les appareils peuvent s’abonner `building/control_room/data1`.

La vérification de la politique **AWS IoT potentiellement mal configurée** signalera cette politique avec un code `POLICY_CONTAINS_MQTT_WILDCARDS_IN_DENY_STATEMENT` anomalie.​

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iot:Subscribe",
            "Resource": "arn:aws:iot:us-east-1:123456789012:topicfilter/building/*"
        },
        {
            "Effect": "Deny",
            "Action": "iot:Subscribe",
            "Resource": "arn:aws:iot:us-east-1:123456789012:topicfilter/building/control_room/#"
        },
        {
            "Effect": "Allow",
            "Action": "iot:Receive",
            "Resource": "arn:aws:iot:us-east-1:123456789012:topic/building/*"
        }
    ]
}
```

------

Voici un exemple de politique correctement configurée. Les appareils ne sont pas autorisés à s’abonner aux sous-rubriques de `building/control_room/` et ne sont pas autorisés à recevoir des messages provenant de rubriques secondaires de `building/control_room/`.

------
#### [ JSON ]

****  

```
{
  "Version":"2012-10-17",		 	 	 
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "iot:Subscribe",
      "Resource": "arn:aws:iot:us-east-1:123456789012:topicfilter/building/*"
    },
    {
      "Effect": "Deny",
      "Action": "iot:Subscribe",
      "Resource": "arn:aws:iot:us-east-1:123456789012:topicfilter/building/control_room/*"
    },
    {
      "Effect": "Allow",
      "Action": "iot:Receive",
      "Resource": "arn:aws:iot:us-east-1:123456789012:topic/building/*"
    },
    {
      "Effect": "Deny",
      "Action": "iot:Receive",
      "Resource": "arn:aws:iot:us-east-1:123456789012:topic/building/control_room/*"
    }
  ]
}
```

------

### Exemple de filtres de rubrique destinés à refuser l’autorisation à l’aide de caractères génériques
<a name="example-section-id2"></a>

L’exemple de politique suivant vise à refuser l’abonnement à des rubriques liées à `building/control_room` en refusant la ressource `building/control_room/*`. Cependant, les appareils peuvent envoyer des demandes d’abonnement `building/#` et de réception de messages concernant toutes les rubriques connexes `building`, y compris `building/control_room/data1`.

La vérification de la politique **AWS IoT potentiellement mal configurée** signalera cette politique avec un code `TOPIC_FILTERS_INTENDED_TO_DENY_ALLOWED_USING_WILDCARDS` anomalie.​

L’exemple de politique suivant permet de recevoir des messages sur `building/control_room topics` :

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iot:Subscribe",
            "Resource": "arn:aws:iot:us-east-1:123456789012:topicfilter/building/*"
        },
        {
            "Effect": "Deny",
            "Action": "iot:Subscribe",
            "Resource": "arn:aws:iot:us-east-1:123456789012:topicfilter/building/control_room/*"
        },
        {
            "Effect": "Allow",
            "Action": "iot:Receive",
            "Resource": "arn:aws:iot:us-east-1:123456789012:topic/building/*"
        }
    ]
}
```

------

Voici un exemple de politique correctement configurée. Les appareils ne sont pas autorisés à s’abonner aux sous-rubriques de `building/control_room/` et ne sont pas autorisés à recevoir des messages provenant de rubriques secondaires de `building/control_room/`.

------
#### [ JSON ]

****  

```
{
    "Version":"2012-10-17",		 	 	 
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "iot:Subscribe",
            "Resource": "arn:aws:iot:us-east-1:123456789012:topicfilter/building/*"
        },
        {
            "Effect": "Deny",
            "Action": "iot:Subscribe",
            "Resource": "arn:aws:iot:us-east-1:123456789012:topicfilter/building/control_room/*"
        },
        {
            "Effect": "Allow",
            "Action": "iot:Receive",
            "Resource": "arn:aws:iot:us-east-1:123456789012:topic/building/*"
        },
        {
            "Effect": "Deny",
            "Action": "iot:Receive",
            "Resource": "arn:aws:iot:us-east-1:123456789012:topic/building/control_room/*"
        }
    ]
}
```

------

**Note**  
Cette vérification peut signaler des faux positifs. Nous vous recommandons d’évaluer toutes les politiques signalées et de marquer les ressources faussement positives à l’aide de suppressions d’audit.

## Comment réparer
<a name="audit-chk-iot-misconfigured-policies-how-to-fix"></a>

Cette vérification signale les politiques potentiellement mal configurées, de sorte qu’il peut y avoir des faux positifs. Marquez les faux positifs à l’aide de [suppressions d’audit](audit-finding-suppressions.md) afin qu’ils ne soient pas signalés à l’avenir.

Vous pouvez également suivre ces étapes pour corriger les politiques non conformes attachées aux objets, groupes d’objets ou autres entités :

1. Utilisez [CreatePolicyVersion](https://docs.aws.amazon.com/iot/latest/apireference/API_CreatePolicyVersion.html) pour créer une nouvelle version conforme de la stratégie. Définissez l’indicateur `setAsDefault` sur true. (Cela rend cette nouvelle version opérationnelle pour toutes les entités qui utilisent la stratégie.)

   Pour des exemples de création de politiques AWS IoT pour des cas d’utilisation courants, consultez [Exemples de politiques de publication/d’abonnement](https://docs.aws.amazon.com/iot/latest/developerguide/pub-sub-policy.html) dans le *Guide du développeur AWS IoT Core*.

1. Vérifiez que tous les appareils associés sont en mesure de se connecter à AWS IoT. Si un appareil n’est pas en mesure de se connecter, utilisez [ SetPolicyVersion](https://docs.aws.amazon.com/iot/latest/apireference/API_SetPolicyVersion.html) pour restaurer la stratégie par défaut à la version précédente, révisez la stratégie et faites une nouvelle tentative. 

Vous pouvez utiliser des actions d’atténuation pour effectuer les actions suivantes :
+ Appliquer l’action d’atténuation `REPLACE_DEFAULT_POLICY_VERSION` sur vos résultats d’audit pour effectuer ce changement. 
+ Appliquer l’action d’atténuation `PUBLISH_FINDINGS_TO_SNS` si vous souhaitez mettre en œuvre une réponse personnalisée pour répondre au message Amazon SNS. 

Pour de plus amples informations, consultez [Actions d'atténuation](dd-mitigation-actions.md). 

Consultez [Variables de stratégie IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/iot-policy-variables.html) dans le *Guide du développeur AWS IoT Core* pour faire référence de manière dynamique aux ressources AWS IoT dans vos politiques.

# Alias de rôle trop permissif
<a name="audit-chk-iot-role-alias-permissive"></a>

L’alias du rôle AWS IoT fournit un mécanisme permettant aux dispositifs connectés de s’authentifier auprès de AWS IoT à l’aide de certificats X.509, puis d’obtenir des informations d’identification AWS de durée limitée à partir d’un rôle IAM associé à un alias de rôle AWS IoT. Les autorisations pour ces informations d’identification doivent être limitées à l’aide de stratégies d’accès avec des variables de contexte d’authentification. Si vos stratégies ne sont pas configurées correctement, vous risquez de vous exposer à une attaque par escalade de privilèges. Ce contrôle d’audit garantit que les informations d’identification temporaires fournies par les alias de rôle AWS IoT ne sont pas trop permissives. 

Ce contrôle est déclenché si l’une des conditions suivantes est identifiée :
+ La stratégie fournit des autorisations administratives à tous les services utilisés au cours de l’année écoulée par cet alias de rôle (par exemple, « iot:\$1 », « dynamodb:\$1 », « iam:\$1 », etc.).
+ La stratégie fournit un accès étendu aux actions de métadonnées d’objets, un accès aux actions AWS IoT restreintes ou un accès étendu aux actions de plan de données AWS IoT.
+ La stratégie donne accès à des services d’audit de sécurité tels que « iam », « cloudtrail », « guardduty », « inspecteur » ou « trustedadvisor ».

Cette vérification apparaît comme `IOT_ROLE_ALIAS_OVERLY_PERMISSIVE_CHECK` dans la CLI et l’API.

**Gravité :** Critique

## Détails
<a name="audit-chk-iot-role-alias-permissive-details"></a>

Les codes de motif suivants sont renvoyés lorsque ce contrôle trouve une stratégie IoT non conforme :
+ ALLOWS\$1BROAD\$1ACCESS\$1TO\$1USED\$1SERVICES
+ ALLOWS\$1ACCESS\$1TO\$1SECURITY\$1AUDITING\$1SERVICES
+ ALLOWS\$1BROAD\$1ACCESS\$1TO\$1IOT\$1THING\$1ADMIN\$1READ\$1ACTIONS
+ ALLOWS\$1ACCESS\$1TO\$1IOT\$1NON\$1THING\$1ADMIN\$1ACTIONS
+ ALLOWS\$1ACCESS\$1TO\$1IOT\$1THING\$1ADMIN\$1WRITE\$1ACTIONS
+ ALLOWS\$1BROAD\$1ACCESS\$1TO\$1IOT\$1DATA\$1PLANE\$1ACTIONS

## Pourquoi est-ce important ?
<a name="audit-chk-iot-role-alias-permissive-why-it-matters"></a>

En limitant les autorisations à celles qui sont nécessaires pour qu’un appareil puisse fonctionner normalement, vous réduisez les risques qui pèsent sur votre compte si un appareil est compromis.

## Comment réparer
<a name="audit-chk-iot-role-alias-permissive-how-to-fix"></a>

Suivez ces étapes pour corriger les stratégies non conformes attachées à des objets, des groupes d’objets ou d’autres entités :

1. Suivez les étapes décrites dans [Autoriser les appels directs vers les services AWS à l’aide du fournisseur d’informations d’identification AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html) pour appliquer une politique plus restrictive à votre alias de rôle.

Vous pouvez utiliser des actions d’atténuation pour effectuer les actions suivantes :
+ Appliquez l’action d’atténuation `PUBLISH_FINDINGS_TO_SNS` si vous souhaitez mettre en œuvre une action personnalisée pour répondre au message Amazon SNS. 

Pour de plus amples informations, consultez [Actions d'atténuation](dd-mitigation-actions.md). 

# L’alias de rôle permet d’accéder aux services non utilisés
<a name="audit-chk-role-alias-unused-svcs"></a>

L’alias du rôle AWS IoT fournit un mécanisme permettant aux dispositifs connectés de s’authentifier auprès de AWS IoT à l’aide de certificats X.509, puis d’obtenir des informations d’identification AWS de durée limitée à partir d’un rôle IAM associé à un alias de rôle AWS IoT. Les autorisations pour ces informations d’identification doivent être limitées à l’aide de stratégies d’accès avec des variables de contexte d’authentification. Si vos stratégies ne sont pas configurées correctement, vous risquez de vous exposer à une attaque par escalade de privilèges. Ce contrôle d’audit garantit que les informations d’identification temporaires fournies par les alias de rôle AWS IoT ne sont pas trop permissives. 

Ce contrôle est déclenché si l’alias de rôle a accès à des services qui n’ont pas été utilisés pour l’appareil AWS IoT au cours de l’année écoulée. Par exemple, les rapports d’audit indiquent si un rôle IAM lié à l’alias de rôle a uniquement utilisé AWS IoT au cours de l’année écoulée, mais que la stratégie attachée au rôle accorde également des autorisations à `"iam:getRole"` et `"dynamodb:PutItem"`.

Cette vérification apparaît comme `IOT_ROLE_ALIAS_ALLOWS_ACCESS_TO_UNUSED_SERVICES_CHECK` dans la CLI et l’API.

**Gravité :** Moyenne

## Détails
<a name="audit-chk-role-alias-unused-svcs-details"></a>

Les codes de motif suivants sont renvoyés lorsque ce contrôle trouve une stratégie AWS IoT non conforme :
+ ALLOWS\$1ACCESS\$1TO\$1UNUSED\$1SERVICES

## Pourquoi est-ce important ?
<a name="audit-chk-role-alias-unused-svcs-why-it-matters"></a>

En limitant les autorisations aux services qui sont nécessaires pour qu’un appareil puisse fonctionner normalement, vous réduisez les risques qui pèsent sur votre compte si un appareil est compromis.

## Comment réparer
<a name="audit-chk-role-alias-unused-svcs-how-to-fix"></a>

Suivez ces étapes pour corriger les stratégies non conformes attachées à des objets, des groupes d’objets ou d’autres entités :

1. Suivez les étapes décrites dans [Autoriser les appels directs vers les services AWS à l’aide du fournisseur d’informations d’identification AWS IoT Core](https://docs.aws.amazon.com/iot/latest/developerguide/authorizing-direct-aws.html) pour appliquer une politique plus restrictive à votre alias de rôle.

Vous pouvez utiliser des actions d’atténuation pour effectuer les actions suivantes :
+ Appliquez l’action d’atténuation `PUBLISH_FINDINGS_TO_SNS` si vous souhaitez mettre en œuvre une action personnalisée pour répondre au message Amazon SNS. 

Pour de plus amples informations, consultez [Actions d'atténuation](dd-mitigation-actions.md). 

# Expiration du certificat CA
<a name="audit-chk-ca-cert-approaching-expiration"></a>

Un certificat CA expire sous 30 jours ou a expiré.

Cette vérification apparaît comme `CA_CERTIFICATE_EXPIRING_CHECK` dans la CLI et l’API.

**Gravité :** Moyenne

## Détails
<a name="audit-chk-ca-cert-approaching-expiration-details"></a>

Ce contrôle s’applique aux certificats CA ACTIVE ou PENDING\$1TRANSFER.

Voici les codes de motif renvoyés lorsque ce contrôle trouve un certificat CA non conforme :
+ CERTIFICATE\$1APPROACHING\$1EXPIRATION
+ CERTIFICATE\$1PAST\$1EXPIRATION

## Pourquoi est-ce important ?
<a name="audit-chk-ca-cert-approaching-expiration-why-it-matters"></a>

Un certificat CA expiré ne doit plus être utilisé pour signer de nouveaux certificats d’appareil.

## Comment réparer
<a name="audit-chk-ca-cert-approaching-expiration-how-to-fix"></a>

Consultez vos bonnes pratiques de sécurité pour savoir comment procéder. Il se peut que vous souhaitiez :

1. Enregistrer un nouveau certificat de CA auprès d’ AWS IoT.

1. Vérifier que vous pouvez signer les certificats d’appareil à l’aide du nouveau certificat de CA.

1. Utilisez [UpdateCACertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateCACertificate.html) pour marquer l’ancien certificat CA comme INACTIF dans AWS IoT. Vous pouvez également utiliser des actions d’atténuation pour effectuer les opérations suivantes :
   + Appliquer l’action d’atténuation `UPDATE_CA_CERTIFICATE` sur vos résultats d’audit pour effectuer ce changement. 
   + Appliquer l’action d’atténuation `PUBLISH_FINDINGS_TO_SNS` si vous souhaitez mettre en œuvre une réponse personnalisée pour répondre au message Amazon SNS. 

   Pour de plus amples informations, consultez [Actions d'atténuation](dd-mitigation-actions.md). 

# Identifiants clients MQTT conflictuels
<a name="audit-chk-conflicting-client-ids"></a>

Plusieurs appareils se connectent en utilisant le même ID client.

Cette vérification apparaît comme `CONFLICTING_CLIENT_IDS_CHECK` dans la CLI et l’API.

**Gravité :** Élevée

## Détails
<a name="audit-chk-conflicting-client-ids-details"></a>

Plusieurs connexions ont été établies avec le même ID client, ce qui a entraîné la déconnexion d’un appareil déjà connecté. La spécification MQTT autorise une seule connexion active par ID client. Par conséquent, si un autre appareil se connecte avec le même ID client, l’appareil précédent est déconnecté.

Lorsqu’il est effectué dans le cadre d’une demande d’audit, ce contrôle examine la façon dont les ID client ont été utilisés pour se connecter au cours des 31 jours avant le début de l’audit. Pour les audits planifiés, ce contrôle examine les données entre la dernière fois où le contrôle a été exécuté et le moment où cette instance de l’audit a démarré. Si vous avez pris des mesures pour atténuer cette condition pendant la période contrôlée, notez à quel moment les connexions/déconnexions ont été effectuées pour déterminer si le problème persiste.

Les codes de motif sont renvoyés lorsque ce contrôle trouve une non-conformité :
+ DUPLICATE\$1CLIENT\$1ID\$1ACROSS\$1CONNECTIONS

Les résultats renvoyés par ce contrôle incluent également l’ID client utilisé pour se connecter, les ID principaux et les heures de déconnexion. Les résultats les plus récents sont répertoriés en premier.

## Pourquoi est-ce important ?
<a name="audit-chk-conflicting-client-ids-why-it-matters"></a>

Les appareils dont les ID sont en conflit sont contraints de se reconnecter en permanence, ce qui peut entraîner la perte de messages ou faire qu’un appareil ne peut pas se connecter.

Cela peut indiquer qu’un appareil ou les informations d’identification d’un appareil ont été divulgués, et peut faire partie d’une attaque DDoS. Il est également possible que les appareils soient mal configurés dans le compte ou qu’un appareil ait une mauvaise connexion et soit forcé de se reconnecter plusieurs fois par minute.

## Comment réparer
<a name="audit-chk-conflicting-client-ids-how-to-fix"></a>

Enregistrez chaque appareil en tant qu’objet unique dans AWS IoT et utilisez le nom d’objet comme ID client pour la connexion. Ou utilisez un UUID comme lD client lors de la connexion de l’appareil via MQTT. Vous pouvez également utiliser des actions d’atténuation pour effectuer les actions suivantes :
+ Appliquer l’action d’atténuation `PUBLISH_FINDINGS_TO_SNS` si vous souhaitez mettre en œuvre une réponse personnalisée pour répondre au message Amazon SNS. 

Pour de plus amples informations, consultez [Actions d'atténuation](dd-mitigation-actions.md).

# Expiration du certificat de l’appareil
<a name="audit-chk-device-cert-approaching-expiration"></a>

Un certificat d’appareil arrive à expiration dans la période de seuil configurée ou a expiré. Le seuil de vérification de l’expiration du certificat peut être configuré entre 30 jours (minimum) et 3 652 jours (10 ans, maximum) avec une valeur par défaut de 30 jours.

Cette vérification apparaît comme `DEVICE_CERTIFICATE_EXPIRING_CHECK` dans la CLI et l’API.

**Gravité :** Moyenne

## Détails
<a name="audit-chk-device-cert-approaching-expiration-details"></a>

Ce contrôle s’applique aux certificats d’appareil qui sont ACTIVE ou PENDING\$1TRANSFER.

Les codes de motif suivants sont renvoyés lorsque ce contrôle trouve un certificat d’appareil non conforme :
+ CERTIFICATE\$1APPROACHING\$1EXPIRATION
+ CERTIFICATE\$1PAST\$1EXPIRATION

## Pourquoi est-ce important ?
<a name="audit-chk-device-cert-approaching-expiration-why-it-matters"></a>

Un certificat d’appareil ne doit pas être utilisé après son expiration.

## Configuration de la vérification de l’expiration du certificat d’appareil
<a name="w2aab9c11c43c13"></a>

Cette configuration vous permet de surveiller et de recevoir des alertes pour les certificats approchant de leur date d’expiration sur l’ensemble de votre flotte d’appareils. Par exemple, si vous souhaitez être averti lorsque les certificats arrivent à expiration dans les 30 jours, vous pouvez configurer la vérification comme suit :

```
{
    "roleArn": "your-audit-role-arn",
    "auditCheckConfigurations": {
        "DEVICE_CERTIFICATE_EXPIRING_CHECK": {
            "enabled": true,
            "configuration": {
                "CERT_EXPIRATION_THRESHOLD_IN_DAYS": "30"
            }
        }
    }
}
```

## Comment réparer
<a name="audit-chk-device-cert-approaching-expiration-how-to-fix"></a>

Consultez vos bonnes pratiques de sécurité pour savoir comment procéder. Il se peut que vous souhaitiez :

1. Allouer un nouveau certificat et l’attacher à l’appareil. 

1. Vérifier que le nouveau certificat est valide et que l’appareil peut l’utiliser pour se connecter.

1. Utilisez [UpdateCertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateCertificate.html) pour marquer l’ancien certificat comme étant INACTIVE dans AWS IoT. Vous pouvez également utiliser des actions d’atténuation pour effectuer les actions suivantes :
   + Appliquer l’action d’atténuation `UPDATE_DEVICE_CERTIFICATE` sur vos résultats d’audit pour effectuer ce changement. 
   + Appliquer l’action d’atténuation `ADD_THINGS_TO_THING_GROUP` pour ajouter le dispositif à un groupe où vous pouvez prendre des mesures à son égard.
   + Appliquer l’action d’atténuation `PUBLISH_FINDINGS_TO_SNS` si vous souhaitez mettre en œuvre une réponse personnalisée pour répondre au message Amazon SNS. 

   Pour de plus amples informations, consultez [Actions d'atténuation](dd-mitigation-actions.md). 

1. Détacher l’ancien certificat de l’appareil. (Voir [ DetachThingPrincipal](https://docs.aws.amazon.com/iot/latest/apireference/API_DetachThingPrincipal.html).)

# Vérification de l’âge du certificat d’appareil
<a name="device-certificate-age-check"></a>

Cette vérification d’audit vous alerte lorsqu’un certificat d’appareil est actif depuis un nombre de jours supérieur ou égal au nombre que vous avez spécifié. Cette vérification vous permet de rester informé de l’état de vos certificats, de prendre des mesures périodiques en temps opportun, quel que soit le moment où le certificat atteint la fin de sa durée de vie, et d’améliorer la sécurité en réduisant le risque de compromission des certificats.

Le seuil de vérification de l’âge du certificat peut être configuré entre 30 jours (minimum) et 3 652 jours (10 ans, maximum), avec une valeur par défaut de 365 jours.

Cette vérification apparaît comme `DEVICE_CERTIFICATE_AGE_CHECK` dans la CLI et l’API. Cette vérification est désactivée par défaut. Sévérité : **faible** 

## Détails
<a name="w2aab9c11c45b9"></a>

Ce contrôle s’applique aux certificats d’appareil qui sont ACTIVE ou PENDING\$1TRANSFER. Les codes de motif suivants sont renvoyés lorsque ce contrôle trouve un certificat d’appareil non conforme : 
+ CERTIFICATE\$1PAST\$1AGE\$1THRESHOLD

## Configuration de la vérification de l’âge du certificat de l’appareil
<a name="w2aab9c11c45c11"></a>

Cette configuration vous permet d’adapter les alertes de rotation des certificats aux besoins spécifiques de votre flotte, ce qui vous permet de maintenir un niveau de sécurité élevé sur tous les appareils. Vous pouvez configurer cette vérification à l’aide de l’API `UpdateAccountAuditConfiguration`. Par exemple, si vous souhaitez être alerté lorsque les certificats sont actifs depuis plus de 365 jours, vous pouvez configurer la vérification comme suit :

```
{
    "roleArn": "your-audit-role-arn",
    "auditCheckConfigurations": {
        "DEVICE_CERTIFICATE_AGE_CHECK": {
            "enabled": true,
            "configuration": {
                "CERT_AGE_THRESHOLD_IN_DAYS": "365"
            }
        }
    }
}
```

# Un certificat d’appareil révoqué est toujours actif.
<a name="audit-chk-revoked-device-cert"></a>

Un certificat d’appareil révoqué est toujours actif.

Cette vérification apparaît comme `REVOKED_DEVICE_CERTIFICATE_STILL_ACTIVE_CHECK` dans la CLI et l’API.

**Gravité :** Moyenne

## Détails
<a name="audit-chk-revoked-device-cert-details"></a>

Un certificat d’appareil figure dans la [liste de révocation des certificats](https://en.wikipedia.org/wiki/Certificate_revocation_list) de sa CA, mais est encore actif dans AWS IoT.

Ce contrôle s’applique aux certificats d’appareil qui sont ACTIVE ou PENDING\$1TRANSFER.

Les codes de motif sont renvoyés lorsque ce contrôle trouve une non-conformité :
+ CERTIFICATE\$1REVOKED\$1BY\$1ISSUER

## Pourquoi est-ce important ?
<a name="audit-chk-revoked-device-cert-why-it-matters"></a>

Un certificat d’appareil est généralement révoqué s’il a été compromis. Il est possible qu’il n’ait pas encore été révoqué dans AWS IoT en raison d’une erreur ou d’une omission.

## Comment réparer
<a name="audit-chk-revoked-device-cert-how-to-fix"></a>

Vérifiez que le certificat d’appareil n’a pas été compromis. S’il l’a été, suivez les bonnes pratiques en matière de sécurité pour traiter cette situation. Il se peut que vous souhaitiez :

1. Allouer un nouveau certificat pour l’appareil.

1. Vérifier que le nouveau certificat est valide et que l’appareil peut l’utiliser pour se connecter.

1. Utiliser [UpdateCertificate](https://docs.aws.amazon.com/iot/latest/apireference/API_UpdateCertificate.html) pour marquer l’ancien certificat comme REVOKED (RÉVOQUÉ) dans AWS IoT. Vous pouvez également utiliser des actions d’atténuation pour effectuer les actions suivantes :
   + Appliquer l’action d’atténuation `UPDATE_DEVICE_CERTIFICATE` sur vos résultats d’audit pour effectuer ce changement. 
   + Appliquer l’action d’atténuation `ADD_THINGS_TO_THING_GROUP` pour ajouter le dispositif à un groupe où vous pouvez prendre des mesures à son égard.
   + Appliquer l’action d’atténuation `PUBLISH_FINDINGS_TO_SNS` si vous souhaitez mettre en œuvre une réponse personnalisée pour répondre au message Amazon SNS. 

   Pour de plus amples informations, consultez [Actions d'atténuation](dd-mitigation-actions.md). 

1. Détacher l’ancien certificat de l’appareil. (Voir [ DetachThingPrincipal](https://docs.aws.amazon.com/iot/latest/apireference/API_DetachThingPrincipal.html).)

# Journalisation désactivée.
<a name="audit-chk-logging-disabled"></a>

Les journaux AWS IoT ne sont pas activés dans Amazon CloudWatch. Vérifie la journalisation des versions V1 et V2.

Cette vérification apparaît comme `LOGGING_DISABLED_CHECK` dans la CLI et l’API.

**Gravité : ** Faible

## Détails
<a name="audit-chk-logging-disabled-details"></a>

Les codes de motif sont renvoyés lorsque ce contrôle trouve une non-conformité :
+ LOGGING\$1DISABLED

## Pourquoi est-ce important ?
<a name="audit-chk-logging-disabled-why-it-matters"></a>

Les journaux AWS IoT dans CloudWatch apportent une visibilité sur les comportements dans AWS IoT, y compris les échecs d’authentification et les connexions/déconnexions inattendues qui peuvent indiquer qu’un appareil a été compromis.

## Comment réparer
<a name="audit-chk-logging-disabled-how-to-fix"></a>

Activez les journaux dans CloudWatch AWS IoT. Consultez [Journalisation et surveillance](https://docs.aws.amazon.com/iot/latest/developerguide/security-logging.html) dans le *Guide du développeur AWS IoT Core*. Vous pouvez également utiliser des actions d’atténuation pour effectuer les actions suivantes :
+ Appliquer l’action d’atténuation `ENABLE_IOT_LOGGING` sur vos résultats d’audit pour effectuer ce changement. 
+ Appliquer l’action d’atténuation `PUBLISH_FINDINGS_TO_SNS` si vous souhaitez mettre en œuvre une réponse personnalisée pour répondre au message Amazon SNS. 

Pour de plus amples informations, consultez [Actions d'atténuation](dd-mitigation-actions.md).