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.
# Corriger les résultats de GuardDuty sécurité détectés
Amazon GuardDuty génère des [résultats](guardduty_findings.md) qui indiquent les problèmes de sécurité potentiels associés à la détection GuardDuty des menaces de base et aux plans de protection dédiés. Les sections suivantes décrivent les étapes de correction recommandées pour ces scénarios. S'il existe d'autres scénarios de correction, ils seront décrits dans les descriptions de chaque type de constatation. Vous pouvez accéder aux informations complètes sur un type de résultat en le sélectionnant dans le [tableau des types de résultat actifs](guardduty_finding-types-active.md).
**Topics**
+ [Corriger une instance Amazon EC2 potentiellement compromise](compromised-ec2.md)
+ [Corriger un compartiment S3 potentiellement compromis](compromised-s3.md)
+ [Corriger un objet S3 potentiellement malveillant](compromised-s3object-malware-protection-gdu.md)
+ [Corriger un instantané EBS potentiellement compromis](compromised-snapshot.md)
+ [Corriger une AMI EC2 potentiellement compromise](compromised-ami.md)
+ [Corriger un point de restauration EC2 potentiellement compromis](compromised-ec2-recoverypoint.md)
+ [Corriger un point de restauration S3 potentiellement compromis](compromised-s3-recoverypoint.md)
+ [Corriger un cluster ECS potentiellement compromis](compromised-ecs.md)
+ [Corriger les informations d'identification potentiellement compromises AWS](compromised-creds.md)
+ [Corriger un conteneur autonome potentiellement compromis](remediate-compromised-standalone-container.md)
+ [Corriger les résultats de la protection EKS](guardduty-remediate-kubernetes.md)
+ [Correction des résultats de la surveillance d’exécution](guardduty-remediate-runtime-monitoring.md)
+ [Corriger une base de données potentiellement compromise](guardduty-remediate-compromised-database-rds.md)
+ [Corriger une fonction Lambda potentiellement compromise](remediate-lambda-protection-finding-types.md)
# Corriger une instance Amazon EC2 potentiellement compromise
**Lorsque GuardDuty des [types de recherche indiquant des ressources Amazon EC2 potentiellement compromises sont générées](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html#findings-table), votre **ressource sera une** instance.** Les types de recherche potentiels peuvent être [Types de résultat EC2](guardduty_finding-types-ec2.md)[GuardDuty Types de recherche liés à la surveillance du temps](findings-runtime-monitoring.md), ou[Protection contre les programmes malveillants pour les types de détection EC2](findings-malware-protection.md). Si le comportement à l'origine de la découverte était attendu dans votre environnement, envisagez d'utiliser[Règles de suppression](findings_suppression-rule.md).
Procédez comme suit pour corriger l'instance Amazon EC2 potentiellement compromise :
1. **Identifiez l'instance Amazon EC2 potentiellement compromise**
Recherchez dans l'instance potentiellement compromise des programmes malveillants et supprimez ceux qui sont détectés. Vous pouvez utiliser [Analyse des malwares à la demande dans GuardDuty](on-demand-malware-scan.md) pour identifier les logiciels malveillants dans l'instance EC2 potentiellement compromise, ou consulter [AWS Marketplace](https://aws.amazon.com/marketplace) pour vérifier s'il existe des produits partenaires utiles afin d'identifier et de supprimer les logiciels malveillants.
1. **Isolez l'instance Amazon EC2 potentiellement compromise**
Si possible, procédez comme suit pour isoler l'instance potentiellement compromise :
1. Créez un groupe de sécurité dédié à **l'isolation**. Un groupe de sécurité d'isolation ne doit avoir un accès entrant et sortant qu'à partir d'adresses IP spécifiques. Assurez-vous qu'aucune règle entrante ou sortante n'autorise le trafic pour. `0.0.0.0/0 (0-65535)`
1. Associez le groupe de sécurité **Isolation** à cette instance.
1. Supprimez toutes les associations de groupes de sécurité autres que le nouveau groupe de sécurité **Isolation** de l'instance potentiellement compromise.
**Note**
Les connexions suivies existantes ne seront pas interrompues suite à un changement de groupe de sécurité. Seul le trafic futur sera effectivement bloqué par le nouveau groupe de sécurité.
Pour plus d'informations sur le blocage du trafic provenant de connexions existantes suspectes, voir [Appliquer NACLs en fonction du réseau IoCs pour empêcher tout trafic supplémentaire](https://github.com/aws-samples/aws-customer-playbook-framework/blob/main/docs/Ransom_Response_EC2_Linux.md#enforce-nacls-based-on-network-iocs-to-prevent-further-traffic) dans le *manuel de réponse aux incidents*.
1. **Identifiez la source de l'activité suspecte**.
Si un logiciel malveillant est détecté, identifiez et arrêtez l'activité potentiellement non autorisée sur votre instance EC2 en fonction du type de résultat dans votre compte. Cela peut nécessiter des actions telles que la fermeture de tous les ports ouverts, la modification des stratégies d'accès et la mise à niveau des applications pour corriger les vulnérabilités.
Si vous ne parvenez pas à identifier et à arrêter toute activité non autorisée sur votre instance EC2 potentiellement compromise, nous vous recommandons de mettre fin à l'instance EC2 compromise et de la remplacer par une nouvelle instance si nécessaire. Les ressources supplémentaires suivantes vous permettent de sécuriser vos instances EC2 :
+ Section Sécurité et réseau de [Bonnes pratiques pour Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html).
+ [Groupes de sécurité Amazon EC2 pour les instances Linux.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html)
+ [Sécurité dans Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security.html)
+ [Conseils pour sécuriser vos instances EC2 (Linux)](https://aws.amazon.com/articles/tips-for-securing-your-ec2-instance/).
+ [AWS meilleures pratiques en matière de sécurité](https://aws.amazon.com//architecture/security-identity-compliance/)
+ [AWS Guide technique de réponse aux incidents de sécurité](https://docs.aws.amazon.com/security-ir/latest/userguide/security-incident-response-guide.html).
1. **Parcourir AWS re:Post**
Naviguez [AWS re:Post](https://repost.aws/)pour obtenir de l'aide supplémentaire.
1. **Soumission d'une demande de support technique**
Si vous êtes abonné à un package Premium Support, vous pouvez soumettre une demande de [support technique](https://console.aws.amazon.com/support/home#/case/create?issueType=technical).
# Corriger un compartiment S3 potentiellement compromis
Lorsqu'il est GuardDuty généré[GuardDuty Types de détection de S3 Protection](guardduty_finding-types-s3.md), cela indique que vos compartiments Amazon S3 ont été compromis. Si le comportement à l'origine de la découverte était attendu dans votre environnement, envisagez de le créer[Règles de suppression](findings_suppression-rule.md). Si ce comportement n'était pas prévu, suivez ces étapes recommandées pour remédier à un compartiment Amazon S3 potentiellement compromis dans votre AWS environnement :
1. **Identifiez la ressource S3 potentiellement compromise.**
Une GuardDuty recherche pour S3 indiquera le compartiment S3 associé, son Amazon Resource Name (ARN) et son propriétaire dans les détails de la recherche.
1. **Identifiez la source de l'activité suspecte et l'appel d'API utilisé.**
L'appel d'API utilisé est répertorié en tant qu'`API` dans les détails d'un résultat. La source sera un principal IAM (rôle IAM, utilisateur ou compte) et les informations d'identification seront répertoriées dans le résultat. Selon le type de source, l'adresse IP distante ou les informations sur le domaine source seront disponibles et peuvent vous aider à déterminer si la source était autorisée. Si la recherche impliquait des informations d'identification provenant d'une instance Amazon EC2, les détails de cette ressource seront également inclus.
1. **Déterminez si la source de l'appel était autorisée à accéder à la ressource identifiée.**
Prenons l'exemple suivant :
+ Si un utilisateur IAM était impliqué, est-il possible que ses informations d'identification aient été potentiellement compromises ? Pour de plus amples informations, veuillez consulter [Corriger les informations d'identification potentiellement compromises AWS](compromised-creds.md).
+ Si une API a été invoquée par un principal qui n'a jamais invoqué ce type d'API, cette source a-t-elle besoin d'autorisations d'accès pour cette opération ? Les autorisations du compartiment peuvent-elles être davantage restreintes ?
+ Si l'accès a été détecté à partir du **nom d'utilisateur** `ANONYMOUS_PRINCIPAL` avec le **type d'utilisateur** de `AWSAccount`, cela indique que le compartiment est public et qu'il a été consulté. Ce compartiment doit-il être public ? Si ce n'est pas le cas, veuillez consulter les recommandations de sécurité ci-dessous pour découvrir des solutions alternatives au partage des ressources S3.
+ Si l'accès a eu lieu par le biais d'un appel `PreflightRequest` réussi constaté à partir du **nom d'utilisateur** `ANONYMOUS_PRINCIPAL` avec le **type d'utilisateur** `AWSAccount`, cela indique que le compartiment dispose d'une stratégie de partage des ressources entre origines multiples (CORS) définie. Ce compartiment doit-il être doté d'une stratégie CORS ? Dans le cas contraire, assurez-vous que le compartiment n'a pas été rendu public par inadvertance et veuillez consulter les recommandations de sécurité ci-dessous pour trouver des solutions alternatives au partage des ressources S3. Pour plus d'informations sur CORS, veuillez consulter la section [Utilisation du partage des ressources entre origines multiples (CORS)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/cors.html) du Guide de l'utilisateur S3.
1. **Déterminez si le compartiment S3 contient des données sensibles.**
Utilisez [Amazon Macie](https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html) pour déterminer si le compartiment S3 contient des données sensibles, telles que des données d'identification personnelle (PII), des données financières ou des informations d'identification. Si la découverte automatique des données sensibles est activée pour votre compte Macie, examinez les détails du compartiment S3 pour mieux comprendre son contenu. Si cette fonctionnalité est désactivée pour votre compte Macie, nous vous recommandons de l'activer pour accélérer votre évaluation. Vous pouvez également créer et exécuter une tâche de découverte de données sensibles pour inspecter les objets du compartiment S3 afin de détecter des données sensibles. Pour plus d'informations, veuillez consulter [Découverte de données sensibles avec Macie](https://docs.aws.amazon.com/macie/latest/user/data-classification.html) (langue française non garantie).
Si l'accès a été autorisé, vous pouvez ignorer le résultat. La [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)console vous permet de configurer des règles pour supprimer complètement les résultats individuels afin qu'ils n'apparaissent plus. Pour de plus amples informations, veuillez consulter [Règles de suppression dans GuardDuty](findings_suppression-rule.md).
Si vous déterminez que vos données S3 ont été exposées ou consultées par un tiers non autorisé, consultez les recommandations de sécurité S3 suivantes pour renforcer les autorisations et restreindre l'accès. Les solutions de correction appropriées dépendent des besoins de votre environnement spécifique.
## Recommandations basées sur les besoins spécifiques d'accès aux compartiments S3
**La liste suivante fournit des recommandations basées sur les besoins spécifiques d'accès aux compartiments Amazon S3 :**
+ Pour limiter de manière centralisée l'accès public à l'utilisation de vos données S3, S3 bloque l'accès public. Les paramètres de blocage de l'accès public peuvent être activés pour les points d'accès, les compartiments et les AWS comptes via quatre paramètres différents afin de contrôler la granularité de l'accès. Pour plus d'informations, consultez la section [Bloquer les paramètres d'accès public](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-control-block-public-access.html#access-control-block-public-access-options) dans le *guide de l'utilisateur Amazon S3*.
+ AWS Les politiques d'accès peuvent être utilisées pour contrôler la manière dont les utilisateurs IAM peuvent accéder à vos ressources ou à vos buckets. Pour plus d'informations, consultez la section [Utilisation des politiques relatives aux compartiments et des politiques utilisateur](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security_iam_service-with-iam.html) dans le *guide de l'utilisateur Amazon S3*.
Vous pouvez également utiliser des points de terminaison de cloud privé virtuel (VPC) avec des stratégies de compartiment S3 pour restreindre l'accès à des points de terminaison d'un VPC spécifiques. Pour plus d'informations, consultez la section [Contrôle de l'accès depuis les points de terminaison VPC à l'aide de politiques de compartiment](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-bucket-policies-vpc-endpoint.html) dans le guide de l'utilisateur *Amazon* S3.
+ Pour autoriser temporairement l'accès à vos objets S3 à des entités approuvées extérieures à votre compte, vous pouvez créer une URL présignée via S3. Cet accès est créé à l'aide des informations d'identification de votre compte et, selon les informations d'identification utilisées, peut durer de 6 heures à 7 jours. Pour plus d'informations, consultez la section [Utilisation de la signature présignée URLs pour télécharger et charger des objets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-presigned-url.html) dans le *guide de l'utilisateur Amazon S3*.
+ Pour les cas d'utilisation nécessitant le partage d'objets S3 entre différentes sources, vous pouvez utiliser les points d'accès S3 pour créer des ensembles d'autorisations qui limitent l'accès aux seuls utilisateurs de votre réseau privé. Pour plus d'informations, consultez [la section Gestion de l'accès aux ensembles de données partagés avec des points d'accès](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-points.html) dans le *guide de l'utilisateur Amazon S3*.
+ Pour accorder l'accès sécurisé à vos ressources S3 à d'autres AWS comptes, vous pouvez utiliser une liste de contrôle d'accès (ACL). Pour plus d'informations, consultez la [présentation de la liste de contrôle d'accès (ACL)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/acl-overview.html) dans le *guide de l'utilisateur Amazon S3*.
Pour plus d'informations sur les options de sécurité S3, consultez [les meilleures pratiques de sécurité pour Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html) dans le *guide de l'utilisateur Amazon S3*.
# Corriger un objet S3 potentiellement malveillant
Lorsqu'il est GuardDuty généré[Protection contre les programmes malveillants pour le type de recherche S3](gdu-malware-protection-s3-finding-types.md), il indique qu'un objet récemment chargé dans votre compartiment Amazon S3 contient un logiciel malveillant. Le type de ressource est un **S3Object**.
Suivez les étapes recommandées ci-dessous pour éventuellement corriger le résultat généré :
1. Identifiez l'objet S3 potentiellement malveillant en vérifiant le **S3 ObjectDetails** associé à la découverte.
1. Isolez l'objet S3 concerné. Si vous aviez activé le balisage au moment de l'activation de Malware Protection for S3 pour le compartiment Amazon S3 associé, vous GuardDuty devez avoir attribué un tag **Malicious** à cet objet. Utilisez le contrôle d'accès basé sur des balises (TBAC) pour restreindre l'accès à cet objet S3. Pour de plus amples informations, veuillez consulter [Utilisation du contrôle d'accès basé sur des balises (TBAC)](tag-based-access-s3-malware-protection.md).
Si vous n'avez plus besoin de cet objet, vous pouvez également choisir de le supprimer ou de le déplacer vers un compartiment S3 isolé. Pour plus d'informations sur les considérations relatives à la suppression d'un objet S3, consultez [Supprimer des objets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeletingObjects.html) dans le *guide de l'utilisateur Amazon S3*.
# Corriger un instantané EBS potentiellement compromis
Quand GuardDuty génère une exécution : EC2/ \$1 MaliciousFile Type de détection d'instantanés, il indique qu'un logiciel malveillant a été détecté dans un instantané Amazon EBS. Procédez comme suit pour corriger le snapshot potentiellement compromis :
1. **Identifiez l'instantané potentiellement compromis**
1. Identifiez l'instantané potentiellement compromis. Une GuardDuty recherche concernant un instantané EBS indiquera l'ID de l'instantané concerné, son Amazon Resource Name (ARN) et les détails de l'analyse des programmes malveillants associés dans les détails de la recherche.
1. Vérifiez les détails du point de récupération à l'aide de la commande suivante :
```
aws backup describe-recovery-point —backup-vault-name 021345abcdef6789 —recovery-point-arn "arn:aws:ec2:us-east-1::snapshot/snap-abcdef01234567890"
```
1. **Restreindre l'accès à l'instantané compromis**
Passez en revue et modifiez les politiques d'accès au coffre de sauvegarde afin de restreindre l'accès aux points de restauration et de suspendre toutes les tâches de restauration automatique susceptibles d'utiliser cet instantané.
1. Vérifiez les autorisations de partage actuelles :
```
aws ec2 describe-snapshot-attribute --snapshot-id snap-abcdef01234567890 --attribute createVolumePermission
```
1. Supprimer l'accès à un compte spécifique :
```
aws ec2 modify-snapshot-attribute --snapshot-id snap-abcdef01234567890 --attribute createVolumePermission --operation-type remove --user-ids 111122223333
```
1. Pour des options de CLI supplémentaires, consultez la [documentation de la modify-snapshot-attribute CLI](https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-snapshot-attribute.html).
1. **Prendre des mesures correctives**
+ Avant de procéder à la suppression, assurez-vous d'avoir identifié toutes les dépendances et de disposer de sauvegardes appropriées si nécessaire.
# Corriger une AMI EC2 potentiellement compromise
Quand GuardDuty génère une exécution : EC2/ \$1 MaliciousFile Type de recherche d'AMI, il indique qu'un logiciel malveillant a été détecté dans une Amazon Machine Image (AMI). Procédez comme suit pour corriger l'AMI potentiellement compromise :
1. **Identifiez l'AMI potentiellement compromise**
1. Une GuardDuty recherche pour AMIs indiquera l'ID de l'AMI concerné, son nom de ressource Amazon (ARN) et les détails de l'analyse des programmes malveillants associés dans les détails de la recherche.
1. Vérifiez l'image source de l'AMI :
```
aws ec2 describe-images --image-ids ami-021345abcdef6789
```
1. **Restreindre l'accès aux ressources compromises**
1. Passez en revue et modifiez les politiques d'accès au coffre de sauvegarde afin de restreindre l'accès au point de restauration et de suspendre toutes les tâches de restauration automatique susceptibles d'utiliser ce point de restauration.
1. Supprimer les autorisations des autorisations de l'AMI source
Consultez d'abord les autorisations existantes :
```
aws ec2 describe-image-attribute --image-id ami-abcdef01234567890 --attribute launchPermission
```
Supprimez ensuite les autorisations individuelles :
```
aws ec2 modify-image-attribute --image-id ami-abcdef01234567890 --launch-permission '{"Remove":[{"UserId":"111122223333"}]}'
```
Pour des options CLI supplémentaires, consultez [Partager une AMI avec des comptes spécifiques - Amazon Elastic Compute Cloud](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/sharingamis-explicit.html#unsharing-an-ami)
1. Si la source est une instance EC2, voir : [Corriger une instance Amazon EC2 potentiellement compromise](https://docs.aws.amazon.com/guardduty/latest/ug/compromised-ec2.html).
1. **Prendre des mesures correctives**
+ Avant de procéder à la suppression, assurez-vous d'avoir identifié toutes les dépendances et de disposer de sauvegardes appropriées si nécessaire.
# Corriger un point de restauration EC2 potentiellement compromis
Quand GuardDuty génère une exécution : EC2/ \$1 MaliciousFile RecoveryPoint type de recherche, cela indique qu'un logiciel malveillant a été détecté dans une ressource EC2 Recovery Point Backup. Procédez comme suit pour corriger le point de restauration potentiellement compromis :
1. **Identifiez le point de restauration EC2 potentiellement compromis**
1. Une GuardDuty recherche concernant EC2 Recovery Point indiquera son nom de ressource Amazon (ARN) et les détails de l'analyse des programmes malveillants associés dans les détails de la recherche :
```
aws backup describe-recovery-point --backup-vault-name 021345abcdef6789 --recovery-point-arn "arn:aws:backup:us-east-1:111122223333:recovery-point:a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
```
1. Passez en revue les détails de la restauration pour rechercher l'image source :
```
aws backup get-recovery-point-restore-metadata --backup-vault-name 021345abcdef6789 --recovery-point-arn "arn:aws:backup:us-east-1:111122223333:recovery-point:a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
```
1. **Restreindre l'accès aux ressources compromises**
+ Passez en revue et modifiez les politiques d'accès au coffre de sauvegarde afin de restreindre l'accès au point de restauration et de suspendre toutes les tâches de restauration automatique susceptibles d'utiliser ce point de restauration. Si votre environnement utilise le balisage des ressources, balisez le point de restauration de manière appropriée pour indiquer qu'il est en cours d'investigation et envisagez de suspendre les sauvegardes planifiées si nécessaire.
Exemple :
*aws backup tag-resource -—resource-arn arn:aws:backup:us-east-1:111122223333:recovery-point:a1b2c3d4-5678-90ab-cdef-EXAMPLE11111 -—tags Investigation=Malware,DoNotDelete=True*
1. **Prendre des mesures correctives**
+ Avant de procéder à la suppression, assurez-vous d'avoir identifié toutes les dépendances et de disposer de sauvegardes appropriées si nécessaire.
# Corriger un point de restauration S3 potentiellement compromis
Quand GuardDuty génère une exécution : S3/ \$1 MaliciousFile RecoveryPoint type de recherche, cela indique qu'un logiciel malveillant a été détecté dans une ressource S3 Recovery Point Backup. Procédez comme suit pour corriger le point de restauration potentiellement compromis :
1. **Identifiez le point de restauration S3 potentiellement compromis**
1. Une GuardDuty recherche concernant les points de restauration S3 indiquera l'ARN du point de restauration concerné, le nom du coffre de sauvegarde et les détails de l'analyse des programmes malveillants associés dans les détails de la recherche.
1. Passez en revue les détails du point de récupération :
```
aws backup describe-recovery-point --backup-vault-name 021345abcdef6789 --recovery-point-arn arn:aws:backup:us-east-1:123456789012:recovery-point:abcdef01234567890
```
1. **Restreindre l'accès aux ressources compromises**
+ Passez en revue et modifiez les politiques d'accès au coffre de sauvegarde afin de restreindre l'accès au point de restauration et de suspendre toutes les tâches de restauration automatique susceptibles d'utiliser ce point de restauration. Si votre environnement utilise le balisage des ressources, balisez le point de restauration de manière appropriée pour indiquer qu'il est en cours d'investigation et envisagez de suspendre les sauvegardes planifiées si nécessaire.
Exemple :
```
aws backup tag-resource —resource-arn arn:aws:backup:us-east-1:111122223333:recovery-point:abcdef01234567890 —tags Investigation=Malware,DoNotDelete=True
```
Pour plus de détails, voir : Référence de commande de la [CLI tag-resource](https://docs.aws.amazon.com/cli/latest/reference/backup/tag-resource.html)
1. **Prendre des mesures correctives**
+ Avant de procéder à la suppression, assurez-vous d'avoir identifié toutes les dépendances et de disposer de sauvegardes appropriées si nécessaire.
# Corriger un cluster ECS potentiellement compromis
La découverte d'un cluster ECS potentiellement compromis indique qu'une activité suspecte ou malveillante a été détectée dans votre environnement Amazon ECS. Cela peut inclure un accès non autorisé, l'exécution de logiciels malveillants ou tout autre comportement malveillant mettant en danger les charges de travail de vos conteneurs.
Procédez comme suit pour corriger un cluster Amazon ECS potentiellement compromis :
1. **Identifier le cluster ECS potentiellement compromis et la menace détectée (résultats)**
Les détails du cluster ECS concerné sont répertoriés dans le panneau GuardDuty des détails de recherche.
1. **Évaluez la source de la menace/du programme malveillant**
Vérifiez la présence de logiciels malveillants dans les images des conteneurs. Si un logiciel malveillant est détecté, passez en revue l'image du conteneur utilisée. [https://docs.aws.amazon.com//AmazonECS/latest/APIReference/API_ListTasks.html](https://docs.aws.amazon.com//AmazonECS/latest/APIReference/API_ListTasks.html)À utiliser pour identifier toutes les autres tâches en cours qui utilisent la même image potentiellement compromise.
1. **Isolez les tâches concernées**
Mettez fin à la menace en bloquant tout le trafic réseau (entrant et sortant) destiné aux tâches concernées. Cette isolation du réseau permet de prévenir toute attaque en cours en coupant toutes les connexions à la tâche compromise.
**Remarque** : Si vous déterminez que ce résultat a été déclenché par une expected/legitimate activité dans votre environnement, vous pouvez configurer une règle de suppression pour empêcher l'apparition de résultats similaires. Pour plus d’informations, consultez [Règles de suppression dans GuardDuty](findings_suppression-rule.md).
# Corriger les informations d'identification potentiellement compromises AWS
Lorsqu'il est GuardDuty généré[Types de résultat IAM](guardduty_finding-types-iam.md), cela indique que vos AWS informations d'identification ont été compromises. Le type de **ressource** potentiellement compromise est **AccessKey**.
Pour corriger les informations d'identification potentiellement compromises dans votre AWS environnement, effectuez les opérations suivantes :
1. **Identifiez l'entité IAM potentiellement compromise et l'appel d'API utilisé.**
L'appel d'API utilisé est répertorié en tant qu'`API` dans les détails d'un résultat. L'entité IAM (rôle ou utilisateur IAM) et ses informations d'identification seront répertoriées dans la section **Ressources des détails** de la recherche. Le type de l'entité IAM impliquée peut être déterminé par le champ **User Type (Type d'utilisateur)**, le nom de l'entité IAM se trouvant dans le champ **User name (Nom d'utilisateur)**. Le type de l'entité IAM impliquée dans le résultat peut également être déterminé par l'**Access key ID (ID de clé d'accès)** utilisé.
Pour les clés commençant par `AKIA` :
Ce type de clé est une information d'identification à long terme gérée par le client associée à un utilisateur IAM ou à un Utilisateur racine d'un compte AWS. Pour de plus amples informations sur la gestion des clés d'accès pour les utilisateurs IAM, veuillez consulter [Gestion des clés d'accès pour les utilisateurs IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html).
Pour les clés commençant par `ASIA` :
Ce type de clé est une information d'identification temporaire à court terme générée par AWS Security Token Service. Ces clés n'existent que pour une courte période et ne peuvent être ni affichées ni gérées dans la console AWS de gestion. Les rôles IAM utiliseront toujours des AWS STS informations d'identification, mais elles peuvent également être générées pour les utilisateurs IAM. Pour plus d'informations sur AWS STS [IAM : informations d'identification de sécurité temporaires](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html#sts-introduction).
Si un rôle a été utilisé, le champ **Nom d'utilisateur** contient des informations sur le nom du rôle utilisé. Vous pouvez déterminer comment la clé a été demandée AWS CloudTrail en examinant l'`sessionIssuer`élément de l'entrée du CloudTrail journal. Pour plus d'informations, voir [IAM et les AWS STS informations dans CloudTrail](https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html#iam-info-in-cloudtrail).
1. **Vérifiez les autorisations pour l'entité IAM.**
Ouvrez la console IAM. Selon le type d'entité utilisé, choisissez l'onglet **Utilisateurs** ou **Rôles** et localisez l'entité affectée en saisissant le nom identifié dans le champ de recherche. Utilisez les onglets **Permission** et **Access Advisor** pour vérifier les autorisations effectives pour cette entité.
1. **Déterminez si les informations d'identification de l'entité IAM ont été utilisées de manière légitime.**
Contactez l'utilisateur des informations d'identification pour déterminer si l'activité était intentionnelle.
Recherchez par exemple si l'utilisateur a effectué les actions suivantes :
+ A invoqué l'opération d'API répertoriée dans le GuardDuty résultat
+ Appeler l'opération API au moment où elle est répertoriée dans le résultat GuardDuty
+ Appeler l'opération API à partir de l'adresse IP répertoriée dans le résultat GuardDuty
Si cette activité constitue une utilisation légitime des AWS informations d'identification, vous pouvez ignorer le GuardDuty résultat. La [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)console vous permet de configurer des règles pour supprimer complètement les résultats individuels afin qu'ils n'apparaissent plus. Pour de plus amples informations, veuillez consulter [Règles de suppression dans GuardDuty](findings_suppression-rule.md).
Si vous ne pouvez pas confirmer si cette activité constitue une utilisation légitime, elle peut être le résultat d'une compromission de la clé d'accès en question, à savoir les informations de connexion de l'utilisateur IAM, ou éventuellement de l'intégralité. Compte AWS Si vous pensez que vos informations d'identification ont été compromises, consultez les informations figurant dans [Mon Compte AWS compte peut être compromis](https://repost.aws/knowledge-center/potential-account-compromise) afin de remédier à ce problème.
# Corriger un conteneur autonome potentiellement compromis
Lorsque des [types de recherche indiquant un conteneur potentiellement compromis sont GuardDuty ](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html#findings-table) générés, votre **type de ressource** sera **Conteneur**. Si le comportement à l'origine de la découverte était attendu dans votre environnement, envisagez d'utiliser[Règles de suppression](findings_suppression-rule.md).
Pour corriger les informations d'identification potentiellement compromises dans votre AWS environnement, effectuez les opérations suivantes :
1. **Isolez le contenant potentiellement compromis**
Les étapes suivantes vous aideront à identifier la charge de travail de conteneur potentiellement malveillante :
+ Ouvrez la GuardDuty console à l'adresse [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
+ Sur la page **Résultats**, choisissez le résultat correspondant pour afficher le panneau des résultats.
+ Dans le panneau des résultats, sous la section **Ressource concernée**, vous pouvez voir l'**ID** et le **nom** du conteneur.
Isolez ce conteneur des autres charges de travail de conteneur.
1. **Mise en pause du conteneur**
Suspendez tous les processus dans votre conteneur.
Pour plus d'informations sur la congélation de votre contenant, voir [Suspendre un contenant](https://docs.docker.com/engine/api/v1.35/#tag/Container/operation/ContainerPause).
**Arrêtez le contenant**.
Si l'étape ci-dessus échoue et que le conteneur ne se suspend pas, arrêtez son exécution. Si vous avez activé cette [Conservation des instantanés](malware-protection-customizations.md#mp-snapshots-retention) GuardDuty fonctionnalité, les instantanés de vos volumes EBS contenant des logiciels malveillants seront conservés.
Pour plus d'informations sur l'arrêt du conteneur, voir [Arrêter un conteneur](https://docs.docker.com/engine/api/v1.35/#tag/Container).
1. **Évaluation de la présence de logiciels malveillants**
Évaluez si un logiciel malveillant se trouvait dans l'image du conteneur.
Si l'accès a été autorisé, vous pouvez ignorer le résultat. La [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)console vous permet de configurer des règles pour supprimer complètement les résultats individuels afin qu'ils n'apparaissent plus. La GuardDuty console vous permet de configurer des règles pour supprimer complètement les résultats individuels afin qu'ils n'apparaissent plus. Pour de plus amples informations, veuillez consulter [Règles de suppression dans GuardDuty](findings_suppression-rule.md).
# Corriger les résultats de la protection EKS
Amazon GuardDuty génère des [résultats](guardduty_findings.md) qui indiquent les problèmes de sécurité potentiels liés à Kubernetes lorsque la protection EKS est activée pour votre compte. Pour de plus amples informations, veuillez consulter [Protection EKS](kubernetes-protection.md). Les sections suivantes décrivent les étapes de correction recommandées pour ces scénarios. Les mesures correctives spécifiques sont décrites dans l'entrée correspondant à ce type de résultat spécifique. Vous pouvez accéder aux informations complètes sur un type de résultat en le sélectionnant dans le [tableau des types de résultat actifs](guardduty_finding-types-active.md).
Si l'un des types de résultats de la protection EKS a été généré comme prévu, vous pouvez envisager d'en ajouter [Règles de suppression dans GuardDuty](findings_suppression-rule.md) pour éviter de futures alertes.
Différents types d'attaques et de problèmes de configuration peuvent déclencher les découvertes de la protection GuardDuty EKS. Ce guide vous aide à identifier les causes profondes des GuardDuty découvertes concernant votre cluster et présente des conseils de correction appropriés. Les principales causes à l'origine des découvertes de GuardDuty Kubernetes sont les suivantes :
+ [Problèmes de configuration potentiels](#compromised-kubernetes-config)
+ [Corriger les utilisateurs Kubernetes potentiellement compromis](#compromised-kubernetes-user)
+ [Corriger les pods Kubernetes potentiellement compromis](#compromised-kubernetes-pod)
+ [Corriger les nœuds Kubernetes potentiellement compromis](#compromised-kubernetes-node)
+ [Corriger les images de conteneurs potentiellement compromises](#compromised-kubernetes-image)
**Note**
Avant la version 1.14 de Kubernetes, le `system:unauthenticated` groupe était associé à `system:discovery` et par défaut. `system:basic-user` **ClusterRoles** Cela peut autoriser un accès involontaire de la part d'utilisateurs anonymes. Les mises à jour de cluster ne révoquent pas ces autorisations, ce qui signifie que même si vous avez mis à jour votre cluster vers la version 1.14 ou ultérieure, elles peuvent toujours être en place. Nous vous recommandons de dissocier ces autorisations du groupe `system:unauthenticated`.
Pour plus d'informations sur la suppression de ces autorisations, consultez la section [Sécurisez les clusters Amazon EKS avec les meilleures pratiques](https://docs.aws.amazon.com/eks/latest/userguide/security-best-practices.html) dans le **guide de l'utilisateur Amazon EKS**.
## Problèmes de configuration potentiels
Si un résultat indique un problème de configuration, veuillez consulter la section sur la correction de ce résultat pour obtenir des conseils sur la résolution de ce problème particulier. Pour de plus amples informations, veuillez consulter les types de résultat suivants qui indiquent des problèmes de configuration :
+ [Policy:Kubernetes/AnonymousAccessGranted](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-anonymousaccessgranted)
+ [Policy:Kubernetes/ExposedDashboard](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-exposeddashboard)
+ [Policy:Kubernetes/AdminAccessToDefaultServiceAccount](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-adminaccesstodefaultserviceaccount)
+ [Policy:Kubernetes/KubeflowDashboardExposed](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-kubeflowdashboardexposed)
+ Toute découverte qui se termine par **SuccessfulAnonymousAccess**
## Corriger les utilisateurs Kubernetes potentiellement compromis
Un GuardDuty résultat peut indiquer un utilisateur Kubernetes compromis lorsqu'un utilisateur identifié dans le résultat a effectué une action d'API inattendue. Vous pouvez identifier l'utilisateur dans la section **Détails de l'utilisateur Kubernetes** des détails d'un résultat dans la console, ou dans les `resource.kubernetesDetails.kubernetesUserDetails` des résultats JSON. Ces détails de l'utilisateur incluent `user name`, `uid` et les groupes Kubernetes auxquels l'utilisateur appartient.
Si l'utilisateur accédait à la charge de travail via une entité IAM, vous pouvez utiliser la section `Access Key details` pour identifier les détails d'un utilisateur ou d'un rôle IAM. Consultez les types d'utilisateur suivants et leurs conseils en matière de correction.
**Note**
Vous pouvez utiliser Amazon Detective pour étudier plus en détail l'utilisateur ou le rôle IAM identifié dans le résultat. Lorsque vous consultez les détails de la recherche dans GuardDuty la console, choisissez **Investigate in Detective**. Sélectionnez ensuite un AWS utilisateur ou un rôle parmi les éléments répertoriés pour l'étudier dans Detective.
**Administrateur Kubernetes intégré** : utilisateur par défaut attribué par Amazon EKS à l'identité IAM qui a créé le cluster. Ce type d'utilisateur est identifié par le nom d'utilisateur `kubernetes-admin`.
**Pour révoquer l'accès d'un administrateur Kubernetes intégré :**
+ Identifiez le `userType` dans la section `Access Key details`.
+ Si le `userType` est **Rôle** et que le rôle appartient à un rôle d'instance EC2 :
+ Identifiez cette instance, puis suivez les instructions fournies dans [Corriger une instance Amazon EC2 potentiellement compromise](compromised-ec2.md).
+ Si le `userType` est **Utilisateur** ou un **rôle** assumé par un utilisateur :
1. [Effectuez une rotation de la clé d'accès](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) de cet utilisateur.
1. Effectuez une rotation de tous les secrets auxquels l'utilisateur avait accès.
1. Consultez les informations figurant dans [Mon Compte AWS compte peut être compromis](https://repost.aws/knowledge-center/potential-account-compromise) pour plus de détails.
**Utilisateur authentifié OIDC** : utilisateur auquel l'accès a été accordé par un fournisseur OIDC. Généralement, le nom d'utilisateur OIDC est une adresse e-mail. Vous pouvez vérifier si votre cluster utilise OIDC avec la commande suivante : `aws eks list-identity-provider-configs --cluster-name your-cluster-name `.
**Pour révoquer l'accès d'un utilisateur authentifié OIDC :**
1. Effectuez une rotation des informations d'identification de cet utilisateur dans le fournisseur OIDC.
1. Effectuez une rotation de tous les secrets auxquels l'utilisateur avait accès.
**AWS-Utilisateur ConfigMap défini par -Auth : utilisateur** IAM auquel l'accès a été accordé par le biais d'un -auth. AWS ConfigMap Pour plus d'informations, consultez [la section Gestion des utilisateurs ou des rôles IAM pour votre cluster](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html) dans le **guide de l'utilisateur Amazon EKS**. Vous pouvez consulter les autorisations à l'aide de la commande suivante : `kubectl edit configmaps aws-auth --namespace kube-system`
**Pour révoquer l'accès d'un AWS ConfigMap utilisateur :**
1. Utilisez la commande suivante pour ouvrir le ConfigMap.
```
kubectl edit configmaps aws-auth --namespace kube-system
```
1. Identifiez le rôle ou l'entrée utilisateur dans la section **MapRoles** ou **MapUsers** avec le même nom d'utilisateur que celui indiqué dans la section des informations utilisateur Kubernetes de votre recherche. GuardDuty Consultez l'exemple suivant, où l'utilisateur administrateur a été identifié dans un résultat.
```
apiVersion: v1
data:
mapRoles: |
- rolearn: arn:aws:iam::444455556666:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
user name: system:node:EC2_PrivateDNSName
groups:
- system:bootstrappers
- system:nodes
mapUsers: |
- userarn: arn:aws:iam::123456789012:user/admin
username: admin
groups:
- system:masters
- userarn: arn:aws:iam::111122223333:user/ops-user
username: ops-user
groups:
- system:masters
```
1. Supprimez cet utilisateur du ConfigMap. Consultez l'exemple suivant où l'utilisateur administrateur a été supprimé.
```
apiVersion: v1
data:
mapRoles: |
- rolearn: arn:aws:iam::111122223333:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
mapUsers: |
- userarn: arn:aws:iam::111122223333:user/ops-user
username: ops-user
groups:
- system:masters
```
1. Si le `userType` est **Utilisateur** ou un **rôle** assumé par un utilisateur :
1. [Effectuez une rotation de la clé d'accès](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) de cet utilisateur.
1. Effectuez une rotation de tous les secrets auxquels l'utilisateur avait accès.
1. Consultez les informations dans [Mon AWS compte peut être compromis](https://aws.amazon.com//premiumsupport/knowledge-center/potential-account-compromise/) pour plus de détails.
Si le résultat ne comporte pas de section `resource.accessKeyDetails`, l'utilisateur est un compte de service Kubernetes.
**Compte de service** : le compte de service fournit une identité aux pods et peut être identifié par un nom d'utilisateur au format suivant : `system:serviceaccount:namespace:service_account_name`.
**Pour révoquer l'accès à un compte de service :**
1. Effectuez une rotation des informations d'identification du compte de service.
1. Consultez les instructions relatives à la compromission du pod dans la section suivante.
## Corriger les pods Kubernetes potentiellement compromis
Lorsque vous GuardDuty spécifiez les détails d'un pod ou d'une ressource de charge de travail dans la `resource.kubernetesDetails.kubernetesWorkloadDetails` section, cet espace ou cette ressource de charge de travail a été potentiellement compromis. Une GuardDuty découverte peut indiquer qu'un seul pod a été compromis ou que plusieurs pods ont été compromis par le biais d'une ressource de niveau supérieur. Consultez les scénarios de compromission suivants pour savoir comment identifier le ou les pods compromis.
**Pods compromis individuels**
Si le champ `type` dans la section `resource.kubernetesDetails.kubernetesWorkloadDetails` est **pods**, le résultat identifie un seul pod. Le champ de nom est le `name` des pods et le champ `namespace` est son espace de noms.
Pour plus d'informations sur l'identification du nœud de travail exécutant les pods, consultez la section [Identifier les pods et le nœud de travail incriminés](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pod_and_worker_node) dans le *guide des meilleures pratiques Amazon EKS*.
**Pods compromis par le biais d'une ressource de charge de travail**
Si le champ `type` de la section `resource.kubernetesDetails.kubernetesWorkloadDetails` identifie une **ressource de charge de travail**, comme un `Deployment`, il est probable que tous les pods de cette ressource de charge de travail aient été compromis.
Pour plus d'informations sur l'identification de tous les pods de la ressource de charge de travail et des nœuds sur lesquels ils s'exécutent, consultez la section [Identifier les pods et nœuds de travail incriminés à l'aide du nom de la charge](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pods_and_worker_nodes_using_workload_name) de travail dans le *guide des meilleures pratiques Amazon EKS*.
**Pods compromis par le biais d'un compte de service**
Si un GuardDuty résultat identifie un compte de service dans la `resource.kubernetesDetails.kubernetesUserDetails` section, il est probable que les pods utilisant le compte de service identifié soient compromis. Le nom d'utilisateur indiqué par un résultat est un compte de service s'il a le format suivant : `system:serviceaccount:namespace:service_account_name`.
Pour plus d'informations sur l'identification de tous les pods utilisant le compte de service et les nœuds sur lesquels ils s'exécutent, consultez la section [Identifier les pods et nœuds de travail incriminés à l'aide du nom du compte de service](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pods_and_worker_nodes_using_service_account_name) dans le *guide des meilleures pratiques Amazon EKS*.
Après avoir identifié tous les pods compromis et les nœuds sur lesquels ils s'exécutent, consultez [Isoler le pod en créant une politique réseau interdisant tout trafic entrant et sortant vers le pod dans le guide](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod) des *meilleures pratiques Amazon EKS*.
**Pour réparer un pod potentiellement compromis :**
1. Identifiez la vulnérabilité qui a compromis les pods.
1. Mettez en œuvre le correctif pour cette vulnérabilité et démarrez de nouveaux pods de remplacement.
1. Supprimez les pods vulnérables.
Pour plus d'informations, consultez la section [Redéployer un pod ou une ressource de charge de travail compromise](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_redeploy_compromised_pod_or_workload_resource) dans le *guide des meilleures pratiques Amazon EKS*.
Si un rôle IAM a été attribué au nœud de travail qui permet aux Pods d'accéder à d'autres AWS ressources, supprimez ces rôles de l'instance pour éviter que l'attaque ne cause de nouveaux dommages. De même, si un rôle IAM a été attribué au pod, déterminez si vous pouvez supprimer les politiques IAM du rôle en toute sécurité sans affecter les autres charges de travail.
## Corriger les images de conteneurs potentiellement compromises
Lorsqu'un GuardDuty résultat indique une compromission du pod, l'image utilisée pour lancer le pod peut être potentiellement malveillante ou compromise. GuardDuty les résultats identifient l'image du conteneur `resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image` sur le terrain. Vous pouvez déterminer si l'image est malveillante en l'analysant afin de détecter des logiciels malveillants.
**Pour corriger une image de conteneur potentiellement compromise :**
1. Arrêtez immédiatement d'utiliser l'image et supprimez-la de votre référentiel d'images.
1. Identifiez tous les pods à l'aide de l'image potentiellement compromise.
Pour plus d'informations, consultez la section [Identifier les pods présentant des images vulnérables ou compromises et les nœuds](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_pods_with_vulnerable_or_compromised_images_and_worker_nodes) de travail dans le *guide des meilleures pratiques Amazon EKS*.
1. Isolez les modules potentiellement compromis, alternez les informations d'identification et collectez des données à des fins d'analyse. Pour plus d'informations, consultez [Isoler le module en créant une politique réseau interdisant tout trafic entrant et sortant vers le module dans le guide](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod) des *meilleures pratiques Amazon EKS*.
1. Supprimez tous les modules utilisant l'image potentiellement compromise.
## Corriger les nœuds Kubernetes potentiellement compromis
Une GuardDuty découverte peut indiquer une compromission d'un nœud si l'utilisateur identifié dans la découverte représente une identité de nœud ou si la découverte indique l'utilisation d'un conteneur privilégié.
L'identité de l'utilisateur est un composant master si le champ **username** a le format suivant : `system:node:node name`. Par exemple, `system:node:ip-192-168-3-201.ec2.internal`. Cela indique que l'adversaire a obtenu l'accès au nœud et qu'il utilise les informations d'identification du nœud pour communiquer avec le point de terminaison de l'API Kubernetes.
Un résultat indique l'utilisation d'un conteneur privilégié si un ou plusieurs conteneurs répertoriés dans le résultat a le champ de résultat `resource.kubernetesDetails.kubernetesWorkloadDetails.containers.securityContext.privileged` défini sur `True`.
**Pour réparer un nœud potentiellement compromis, procédez comme suit :**
1. Isolez le module, modifiez ses informations d'identification et collectez des données pour une analyse médico-légale.
Pour plus d'informations, consultez [Isoler le module en créant une politique réseau interdisant tout trafic entrant et sortant vers le module dans le guide](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod) des *meilleures pratiques Amazon EKS*.
1. Identifiez les comptes de service utilisés par tous les pods exécutés sur le nœud potentiellement compromis. Vérifiez leurs autorisations et effectuez une rotation des comptes de service, si nécessaire.
1. Mettez fin au nœud potentiellement compromis.
# Correction des résultats de la surveillance d’exécution
Lorsque vous activez la surveillance du temps d'exécution pour votre compte, Amazon GuardDuty peut générer des informations [GuardDuty Types de recherche liés à la surveillance du temps](findings-runtime-monitoring.md) indiquant des problèmes de sécurité potentiels dans votre AWS environnement. Les problèmes de sécurité potentiels indiquent soit une instance Amazon EC2 compromise, soit une charge de travail de conteneur, soit un cluster Amazon EKS, soit un ensemble d'informations d'identification compromises dans votre AWS environnement. L'agent de sécurité surveille les événements d'exécution provenant de plusieurs types de ressources. Pour identifier la ressource potentiellement compromise, consultez le **type de ressource** dans les informations de recherche générées dans la GuardDuty console. La section suivante décrit les étapes de correction recommandées pour chaque type de ressource.
------
#### [ Instance ]
Si le **type de ressource** indiqué dans les détails du résultat est **Instance**, cela indique qu'une instance EC2 ou un nœud EKS est potentiellement compromis.
+ Pour corriger un nœud EKS compromis, veuillez consulter [Corriger les nœuds Kubernetes potentiellement compromis](guardduty-remediate-kubernetes.md#compromised-kubernetes-node).
+ Pour corriger une instance EC2 compromise, veuillez consulter [Corriger une instance Amazon EC2 potentiellement compromise](compromised-ec2.md).
------
#### [ EKSCluster ]
Si le **type de ressource** indiqué dans les détails de la recherche est **EKSCluster**, cela indique qu'un pod ou un conteneur au sein d'un cluster EKS est potentiellement compromis.
+ Pour corriger un pod compromis, veuillez consulter [Corriger les pods Kubernetes potentiellement compromis](guardduty-remediate-kubernetes.md#compromised-kubernetes-pod).
+ Pour corriger une image de conteneur compromise, veuillez consulter [Corriger les images de conteneurs potentiellement compromises](guardduty-remediate-kubernetes.md#compromised-kubernetes-image).
------
#### [ ECSCluster ]
Si le **type de ressource** indiqué dans les détails de la recherche est **ECSCluster**, cela indique qu'une tâche ECS ou un conteneur à l'intérieur d'une tâche ECS est potentiellement compromis.
1. **Identifiez le cluster ECS concerné**
La constatation GuardDuty Runtime Monitoring fournit les détails du cluster ECS dans le panneau de détails de la découverte ou dans la `resource.ecsClusterDetails` section du JSON de recherche.
1. **Identifiez la tâche ECS affectée**
La constatation GuardDuty Runtime Monitoring fournit les détails de la tâche ECS dans le panneau de détails de la recherche ou dans la `resource.ecsClusterDetails.taskDetails` section du JSON de recherche.
1. **Isolez la tâche affectée**
Isolez la tâche affectée en refusant tout trafic entrant et sortant vers la tâche. Une règle interdisant tout trafic peut aider à stopper une attaque déjà en cours, en coupant toutes les connexions à la tâche.
1. **Corriger la tâche compromise**
1. Identifiez la vulnérabilité qui a compromis la tâche.
1. Mettez en œuvre le correctif pour cette vulnérabilité et lancez une nouvelle tâche de remplacement.
1. Arrêtez cette tâche vulnérable.
------
#### [ Container ]
Si le **type de ressource** indiqué dans les détails du résultat est **Conteneur**, cela indique qu'un conteneur autonome est potentiellement compromis.
+ Pour remédier à cette situation, veuillez consulter [Corriger un conteneur autonome potentiellement compromis](remediate-compromised-standalone-container.md).
+ Si le résultat est généré sur plusieurs conteneurs à l'aide de la même image de conteneur, veuillez consulter [Corriger les images de conteneurs potentiellement compromises](guardduty-remediate-kubernetes.md#compromised-kubernetes-image).
+ Si le conteneur a accédé à l'hôte EC2 sous-jacent, ses informations d'identification d'instance associées ont peut-être été compromises. Pour de plus amples informations, veuillez consulter [Corriger les informations d'identification potentiellement compromises AWS](compromised-creds.md).
+ Si un acteur potentiellement malveillant a accédé au nœud EKS sous-jacent ou à une instance EC2, consultez les mesures correctives recommandées sous les onglets *EKSCluster*et *Instance*.
------
## Correction des images de conteneur compromises
Lorsqu'un GuardDuty résultat indique la compromission d'une tâche, l'image utilisée pour lancer la tâche peut être malveillante ou compromise. GuardDuty les résultats identifient l'image du conteneur `resource.ecsClusterDetails.taskDetails.containers.image` sur le terrain. Vous pouvez déterminer si l'image est malveillante ou non en la scannant à la recherche de logiciels malveillants.
**Pour corriger une image de conteneur compromise**
1. Arrêtez immédiatement d'utiliser l'image et supprimez-la de votre référentiel d'images.
1. Identifiez toutes les tâches qui utilisent cette image.
1. Arrêtez toutes les tâches utilisant l'image compromise. Mettez à jour leurs définitions de tâches afin qu'ils cessent d'utiliser l'image compromise.
# Corriger une base de données potentiellement compromise
GuardDuty génère [Types de résultat de la protection RDS](findings-rds-protection.md) qui indiquent un comportement de connexion potentiellement suspect et anormal chez vous [Bases de données prises en charge](rds-protection.md#rds-pro-supported-db) après l'activation[Protection RDS](rds-protection.md). L'activité de connexion RDS permet d' GuardDuty analyser et de profiler les menaces en identifiant les modèles inhabituels lors des tentatives de connexion.
**Note**
Vous pouvez accéder aux informations complètes sur un type de résultat en le sélectionnant dans la [GuardDuty types de recherche actifs](guardduty_finding-types-active.md#findings-table).
Suivez ces étapes recommandées pour corriger une base de données Amazon Aurora potentiellement compromise dans votre AWS environnement.
**Topics**
+ [Correction d'une base de données potentiellement compromise avec des événements de connexion réussie](#gd-compromised-db-successful-attempt)
+ [Correction d'une base de données potentiellement compromise avec des événements de connexion échouée](#gd-compromised-db-failed-attempt)
+ [Correction d'informations d'identification compromises](#gd-rds-database-compromised-credentials)
+ [Retreindre l'accès au réseau](#gd-rds-database-restrict-network-access)
## Correction d'une base de données potentiellement compromise avec des événements de connexion réussie
Les étapes recommandées ci-dessous peuvent vous aider à corriger une base de données Aurora potentiellement compromise qui présente un comportement inhabituel lié à des événements de connexion réussie.
1. **Identifiez la base de données et l'utilisateur concernés.**
Le GuardDuty résultat généré fournit le nom de la base de données affectée et les informations utilisateur correspondantes. Pour de plus amples informations, veuillez consulter [Détails d’un résultat](guardduty_findings-summary.md).
1. **Vérifiez si ce comportement est attendu ou inattendu.**
La liste suivante indique les scénarios potentiels susceptibles d'avoir entraîné GuardDuty la génération d'un résultat :
+ Un utilisateur qui se connecte à sa base de données après une longue période.
+ Un utilisateur qui se connecte à sa base de données de façon occasionnelle, par exemple un analyste financier qui se connecte chaque trimestre.
+ Un acteur potentiellement suspect impliqué dans une tentative de connexion réussie peut compromettre la base de données.
1. **Commencez cette étape si le comportement est inattendu.**
1. **Restreindre l'accès à la base de données**
Limitez l'accès à la base de données pour les comptes suspects et la source de cette activité de connexion. Pour plus d’informations, consultez [Correction d'informations d'identification compromises](#gd-rds-database-compromised-credentials) et [Retreindre l'accès au réseau](#gd-rds-database-restrict-network-access).
1. **Évaluez l'impact et déterminez quelles informations ont été consultées.**
+ Le cas échéant, veuillez consulter les journaux d'audit pour identifier les informations susceptibles d'avoir été consultées. Pour de plus amples informations, veuillez consulter [Surveillance des événements, des journaux et des flux dans un cluster de base de données Amazon Aurora](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/CHAP_Monitor_Logs_Events.html) dans le *Guide de l'utilisateur Amazon Aurora*.
+ Déterminez si des informations sensibles ou protégées ont été consultées ou modifiées.
## Correction d'une base de données potentiellement compromise avec des événements de connexion échouée
Les étapes recommandées ci-dessous peuvent vous aider à corriger une base de données Aurora potentiellement compromise qui présente un comportement inhabituel lié à des événements de connexion échouée.
1. **Identifiez la base de données et l'utilisateur concernés.**
Le GuardDuty résultat généré fournit le nom de la base de données affectée et les informations utilisateur correspondantes. Pour de plus amples informations, veuillez consulter [Détails d’un résultat](guardduty_findings-summary.md).
1. **Identifiez la source des tentatives de connexion infructueuses.**
Le GuardDuty résultat généré fournit l'**adresse IP** et **l'organisation ASN** (s'il s'agissait d'une connexion publique) dans la section **Acteur** du panneau de recherche.
Un système autonome est un groupe d'un ou de plusieurs préfixes IP (listes d'adresses IP accessibles sur un réseau) gérés par un ou plusieurs opérateurs réseau qui appliquent une stratégie de routage unique et clairement définie. Les opérateurs de réseaux ont besoin de numéros de système autonomes (ASNs) pour contrôler le routage au sein de leurs réseaux et pour échanger des informations de routage avec d'autres fournisseurs de services Internet (ISPs).
1. **Vérifiez que ce comportement est inattendu.**
Vérifiez si cette activité représente une tentative d'obtenir un accès non autorisé supplémentaire à la base de données comme suit :
+ Si la source est interne, vérifiez si une application est mal configurée et tente de se connecter à plusieurs reprises.
+ S'il s'agit d'un acteur externe, vérifiez si la base de données correspondante est accessible au public ou si elle est mal configurée, ce qui permet à des acteurs malveillants potentiels de recourir à une attaque en force visant à obtenir les noms d'utilisateur courants.
1. **Commencez cette étape si le comportement est inattendu.**
1. **Restreindre l'accès à la base de données**
Limitez l'accès à la base de données pour les comptes suspects et la source de cette activité de connexion. Pour plus d’informations, consultez [Correction d'informations d'identification compromises](#gd-rds-database-compromised-credentials) et [Retreindre l'accès au réseau](#gd-rds-database-restrict-network-access).
1. **Effectuez une analyse des causes profondes et déterminez les étapes qui ont potentiellement donné lieu à cette activité.**
Configurez une alerte pour être averti lorsqu'une activité modifie une stratégie réseau et crée un état non sécurisé. Pour plus d'informations, veuillez consulter [Politiques de pare-feu dans AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewall-policies.html) dans le *Guide du développeur AWS Network Firewall * (langue française non garantie).
## Correction d'informations d'identification compromises
Une GuardDuty découverte peut indiquer que les informations d'identification d'utilisateur d'une base de données affectée ont été compromises lorsque l'utilisateur identifié dans la recherche a effectué une opération de base de données inattendue. Vous pouvez identifier l'utilisateur dans la section **Détails de l'utilisateur de la base de données RDS** dans le panneau de résultat de la console, ou dans les `resource.rdsDbUserDetails` des résultats JSON. Ces informations utilisateur incluent le nom d'utilisateur, l'application utilisée, la base de données consultée, la version SSL et la méthode d'authentification.
+ Pour révoquer l'accès ou modifier les mots de passe pour des utilisateurs spécifiques impliqués dans le résultat, veuillez consulter [Sécurité avec Amazon Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Security.html) ou [Sécurité avec Amazon Aurora PostgreSQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.Security.html) dans le *Guide de l'utilisateur Amazon Aurora*.
+ AWS Secrets Manager À utiliser pour stocker en toute sécurité et transférer automatiquement les secrets des bases de données Amazon Relational Database Service (RDS). Pour plus d'informations, veuillez consulter la rubrique [Didacticiels AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials.html) dans le *Guide de l'utilisateur AWS Secrets Manager *.
+ Utilisez l'authentification de base de données IAM pour gérer l'accès des utilisateurs de base de données sans avoir besoin de mots de passe. Pour de plus amples informations, veuillez consulter [Authentification de base de données IAM](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.IAMDBAuth.html) dans le *Guide de l'utilisateur Amazon Aurora*.
Pour de plus amples informations, veuillez consulter [Bonnes pratiques en matière de sécurité pour Amazon Relational Database Service](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_BestPractices.Security.html) dans le *Guide de l'utilisateur Amazon RDS*.
## Retreindre l'accès au réseau
Une GuardDuty découverte peut indiquer qu'une base de données est accessible au-delà de vos applications ou du Virtual Private Cloud (VPC). Si l'adresse IP distante indiquée dans le résultat est une source de connexion inattendue, vérifiez les groupes de sécurité. Une liste des groupes de sécurité attachés à la base de données est disponible sous **Groupes de sécurité** dans la [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)console ou dans le JSON `resource.rdsDbInstanceDetails.dbSecurityGroups` des résultats. Pour de plus amples informations sur la configuration des groupes de sécurité, veuillez consulter [Contrôle d'accès par groupes de sécurité](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.RDSSecurityGroups.html) dans le *Guide de l'utilisateur Amazon RDS*.
Si vous utilisez un pare-feu, limitez l'accès réseau à la base de données en reconfigurant les listes de contrôle d'accès réseau (NACLs). Pour plus d'informations, veuillez consulter [Pare-feux dans AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/firewalls.html) dans le *Guide du développeur AWS Network Firewall *.
# Corriger une fonction Lambda potentiellement compromise
Lors de GuardDuty la [Types de résultat de la protection Lambda](lambda-protection-finding-types.md) génération, votre fonction Lambda peut être compromise. Si l'activité GuardDuty à l'origine de ce résultat était attendue, vous pouvez envisager d'utiliser[Règles de suppression](findings_suppression-rule.md). Nous vous recommandons de suivre les étapes suivantes pour corriger une fonction Lambda compromise :
**Pour corriger les résultats de la protection Lambda**
1. **Identifiez la version de la fonction Lambda potentiellement compromise**.
Une GuardDuty recherche pour Lambda Protection fournit le nom, le nom de ressource Amazon (ARN), la version de la fonction et l'ID de révision associés à la fonction Lambda répertoriés dans les détails de la recherche.
1. **Identifiez la source de l'activité potentiellement suspecte**.
1. Examinez le code associé à la version de la fonction Lambda impliquée dans le résultat.
1. Examinez les bibliothèques et les couches importées de la version de la fonction Lambda impliquée dans le résultat.
1. Si vous avez activé [AWS Lambda les fonctions de numérisation avec Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/user/scanning-lambda.html), consultez les [résultats Amazon Inspector](https://docs.aws.amazon.com/inspector/latest/user/findings-understanding-locating-analyzing.html) associés à la fonction Lambda impliquée dans le résultat.
1. Passez en revue les AWS CloudTrail journaux pour identifier le principal responsable de la mise à jour de la fonction et assurez-vous que l'activité était autorisée ou attendue.
1. **Corrigez la fonction Lambda potentiellement compromise**.
1. Désactivez les déclencheurs d'exécution de la fonction Lambda impliqués dans le résultat. Pour de plus amples informations, veuillez consulter [DeleteFunctionEventInvokeConfig](https://docs.aws.amazon.com/lambda/latest/dg/API_DeleteFunctionEventInvokeConfig.html).
1. Examinez le code Lambda et mettez à jour les importations de bibliothèques et les [couches de fonctions Lambda](https://docs.aws.amazon.com/lambda/latest/dg/chapter-layers.html) afin de supprimer les bibliothèques et les couches potentiellement suspectes.
1. Atténuez les résultats Amazon Inspector liés à la fonction Lambda impliquée dans le résultat.