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.
# Conditions préalables à la prise en charge des instances Amazon EC2
Cette section inclut les conditions préalables à la surveillance du comportement d'exécution de vos instances Amazon EC2. Une fois ces conditions préalables remplies, voir[Activer la surveillance du GuardDuty temps d'exécution](runtime-monitoring-configuration.md).
**Topics**
+ [Gérer les instances EC2 par SSM (pour la configuration automatique des agents uniquement)](#ssm-managed-prereq-ec2)
+ [Valider les exigences architecturales](#validating-architecture-req-ec2)
+ [Validation de la politique de contrôle des services de votre organisation dans un environnement multi-comptes](#validate-organization-scp-ec2)
+ [Lors de l'utilisation de la configuration automatique des agents](#runtime-ec2-prereq-automated-agent)
+ [Limite du processeur et de la mémoire pour GuardDuty l'agent](#ec2-cpu-memory-limits-gdu-agent)
+ [Étape suivante](#next-step-after-prereq-ec2)
## Gérer les instances EC2 par SSM (pour la configuration automatique des agents uniquement)
GuardDuty utilise AWS Systems Manager (SSM) pour déployer, installer et gérer automatiquement l'agent de sécurité sur vos instances. Si vous prévoyez d'installer et de gérer manuellement l' GuardDuty agent, le SSM n'est pas nécessaire.
*Pour gérer vos instances Amazon EC2 avec Systems Manager, consultez la section [Configuration de Systems Manager pour les instances Amazon EC2](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html) dans AWS Systems Manager le guide de l'utilisateur.*
## Valider les exigences architecturales
L'architecture de la distribution de votre système d'exploitation peut avoir un impact sur le comportement GuardDuty de l'agent de sécurité. Vous devez répondre aux exigences suivantes avant d'utiliser Runtime Monitoring pour les instances Amazon EC2 :
+ Le support du noyau inclut`eBPF`, `Tracepoints` et`Kprobe`. Pour les architectures de processeur, Runtime Monitoring prend en charge AMD64 (`x64`) et ARM64 (Graviton2 et versions ultérieures). [1](#runtime-monitoring-ec2-graviton-2-support)
Le tableau suivant indique la distribution du système d'exploitation qui a été vérifiée pour prendre en charge l'agent GuardDuty de sécurité pour les instances Amazon EC2.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html)
1. La surveillance du temps d'exécution pour les ressources Amazon EC2 ne prend pas en charge les instances Graviton de première génération telles que les types d'instances A1.
1. Support pour différents systèmes d'exploitation : la prise en charge de la surveillance du temps d'exécution GuardDuty a été vérifiée pour la distribution d'exploitation répertoriée dans le tableau précédent. Bien que l'agent GuardDuty de sécurité puisse s'exécuter sur des systèmes d'exploitation non répertoriés dans le tableau précédent, l' GuardDuty équipe ne peut garantir la valeur de sécurité attendue.
1. Quelle que soit la version du noyau, vous devez définir l'`CONFIG_DEBUG_INFO_BTF`indicateur sur `y` (c'est-à-dire *vrai*). Cela est nécessaire pour que l'agent GuardDuty de sécurité puisse fonctionner comme prévu.
1. Pour les versions 5.10 et antérieures du noyau, l'agent GuardDuty de sécurité utilise de la mémoire verrouillée dans RAM (`RLIMIT_MEMLOCK`) pour fonctionner comme prévu. Si la `RLIMIT_MEMLOCK` valeur de votre système est trop faible, il est GuardDuty recommandé de définir des limites strictes et souples à au moins 32 Mo. Pour plus d'informations sur la vérification et la modification de la `RLIMIT_MEMLOCK` valeur par défaut, consultez[Affichage et mise à jour `RLIMIT_MEMLOCK` des valeurs](#runtime-monitoring-ec2-modify-rlimit-memlock).
1. Pour Ubuntu 24.04, les versions 6.13 et 6.14 du noyau ne prennent en charge que les versions 1.9.2 et supérieures de l'agent EC2.
+ Exigences supplémentaires : uniquement si vous possédez Amazon ECS/Amazon EC2
Pour Amazon ECS/Amazon EC2, nous vous recommandons d'utiliser la dernière version optimisée pour Amazon ECS AMIs (datée du 29 septembre 2023 ou ultérieure) ou d'utiliser la version v1.77.0 de l'agent Amazon ECS.
### Affichage et mise à jour `RLIMIT_MEMLOCK` des valeurs
Lorsque la `RLIMIT_MEMLOCK` limite de votre système est trop faible, l'agent GuardDuty de sécurité risque de ne pas fonctionner comme prévu. GuardDuty recommande que les limites strictes et souples soient d'au moins 32 Mo. Si vous ne mettez pas à jour les limites, vous ne GuardDuty pourrez pas surveiller les événements d'exécution de votre ressource. Lorsqu'il `RLIMIT_MEMLOCK` est supérieur aux limites minimales indiquées, il est facultatif pour vous de mettre à jour ces limites.
Vous pouvez modifier la `RLIMIT_MEMLOCK` valeur par défaut avant ou après l'installation de l'agent GuardDuty de sécurité.
**Pour afficher les `RLIMIT_MEMLOCK` valeurs**
1. Exécutez `ps aux | grep guardduty`. Cela affichera l'ID du processus (`pid`).
1. Copiez l'ID du processus (`pid`) à partir de la sortie de la commande précédente.
1. Exécutez `grep "Max locked memory" /proc/pid/limits` après avoir `pid` remplacé le par l'ID de processus copié à l'étape précédente.
Cela affichera la quantité maximale de mémoire verrouillée pour exécuter l'agent GuardDuty de sécurité.
**Pour mettre à jour `RLIMIT_MEMLOCK` les valeurs**
1. Si le `/etc/systemd/system.conf.d/NUMBER-limits.conf` fichier existe, commentez la ligne `DefaultLimitMEMLOCK` de ce fichier. Ce fichier définit une valeur par défaut `RLIMIT_MEMLOCK` avec une priorité élevée, qui remplace vos paramètres dans le `/etc/systemd/system.conf` fichier.
1. Ouvrez le `/etc/systemd/system.conf` fichier et décommentez la ligne qui le contient`#DefaultLimitMEMLOCK=`.
1. Mettez à jour la valeur par défaut en fournissant des `RLIMIT_MEMLOCK` limites strictes et souples d'au moins 32 Mo. La mise à jour devrait ressembler à ceci :`DefaultLimitMEMLOCK=32M:32M`. Le format est `soft-limit:hard-limit`.
1. Exécutez `sudo reboot`.
## Validation de la politique de contrôle des services de votre organisation dans un environnement multi-comptes
Si vous avez défini une politique de contrôle des services (SCP) pour gérer les autorisations dans votre organisation, vérifiez que la limite des autorisations autorise l'`guardduty:SendSecurityTelemetry`action. Il est nécessaire pour GuardDuty prendre en charge la surveillance du temps d'exécution sur différents types de ressources.
Si vous êtes un compte membre, connectez-vous à l'administrateur délégué associé. Pour plus d'informations sur la gestion SCPs de votre organisation, voir [Politiques de contrôle des services (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html).
## Lors de l'utilisation de la configuration automatique des agents
Pour [Utiliser la configuration automatique des agents (recommandé)](how-runtime-monitoring-works-ec2.md#use-automated-agent-config-ec2) cela, vous Compte AWS devez remplir les prérequis suivants :
+ Lorsque vous utilisez des balises d'inclusion avec une configuration d'agent automatisée, GuardDuty pour créer une association SSM pour une nouvelle instance, assurez-vous que la nouvelle instance est gérée par SSM et qu'elle apparaît sous **Fleet Manager** dans la [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)console.
+ Lorsque vous utilisez des balises d'exclusion avec une configuration automatique de l'agent :
+ Ajoutez le `false` tag `GuardDutyManaged` : avant de configurer l'agent GuardDuty automatique pour votre compte.
Assurez-vous d'ajouter la balise d'exclusion à vos instances Amazon EC2 avant de les lancer. Une fois que vous avez activé la configuration automatique des agents pour Amazon EC2, toute instance EC2 lancée sans balise d'exclusion sera couverte par la configuration GuardDuty automatique des agents.
+ Activez le paramètre **Autoriser les balises dans les métadonnées** pour vos instances. Ce paramètre est obligatoire car il GuardDuty faut lire la balise d'exclusion du service de métadonnées d'instance (IMDS) pour déterminer s'il doit exclure l'instance de l'installation de l'agent. Pour plus d'informations, consultez [Activer l'accès aux balises dans les métadonnées des instances](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/work-with-tags-in-IMDS.html#allow-access-to-tags-in-IMDS) dans le guide de l'*utilisateur Amazon EC2*.
## Limite du processeur et de la mémoire pour GuardDuty l'agent
**Limite du processeur**
La limite de processeur maximale pour l'agent GuardDuty de sécurité associé aux instances Amazon EC2 est de 10 % du total des cœurs de vCPU. Par exemple, si votre instance EC2 possède 4 cœurs de vCPU, l'agent de sécurité peut utiliser un maximum de 40 % des 400 % disponibles.
**Limite de mémoire**
Parmi la mémoire associée à votre instance Amazon EC2, l'agent de GuardDuty sécurité ne peut utiliser qu'une quantité limitée de mémoire.
Le tableau suivant indique la limite de mémoire.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html)
## Étape suivante
L'étape suivante consiste à configurer la surveillance du temps d'exécution et à gérer l'agent de sécurité (automatiquement ou manuellement).