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 requises pour le support des EC2 instances Amazon
Cette section inclut les conditions préalables à la surveillance du comportement d'exécution de vos EC2 instances Amazon. Une fois ces conditions préalables remplies, voirActiver la surveillance du GuardDuty temps d'exécution.
Rubriques
Gérer EC2 les instances par SSM (pour la configuration automatisée 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 EC2 instances Amazon avec Systems Manager, consultez la section Configuration de Systems Manager pour les EC2 instances Amazon dans le Guide de AWS Systems Manager 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 EC2 instances Amazon :
-
Le support du noyau inclut
eBPF
,Tracepoints
etKprobe
. Pour les architectures de processeur, Runtime Monitoring prend en charge AMD64 (x64
) et ARM64 (Graviton2 et versions ultérieures). 1Le 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 EC2 instances Amazon.
Distribution du système d'exploitation 2 Version du noyau 3 Amazon Linux 2 Amazon Linux 2023 Ubuntu 20.04 et Ubuntu 22.04 Ubuntu 24.04 6.8
Debian 11 et Debian 12 RedHat 9,4 5,14
Fedora 34.0 5,11, 5,17
Fedora 40 6.8
Fedora 41 6,12
CentOS Stream 9 5,14
Oracle Linux 8.9 5,15
Oracle Linux 9.3 5,15
Rocky Linux 9.5 5,14
-
Runtime Monitoring for Amazon EC2 Resources ne prend pas en charge les instances Graviton de première génération telles que les types d'instances A1.
-
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.
-
Quelle que soit la version du noyau, vous devez définir l'
CONFIG_DEBUG_INFO_BTF
indicateur sury
(c'est-à-dire vrai). Cela est nécessaire pour que l'agent GuardDuty de sécurité puisse fonctionner comme prévu. -
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 laRLIMIT_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 laRLIMIT_MEMLOCK
valeur par défaut, consultezAffichage et mise à jour RLIMIT_MEMLOCK des valeurs.
-
-
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 serez pas en mesure de 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
-
Exécutez
ps aux | grep guardduty
. Cela affichera l'ID du processus (pid
). -
Copiez l'ID du processus (
pid
) à partir de la sortie de la commande précédente. -
Exécutez
grep "Max locked memory" /proc/
après avoirpid
/limitspid
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
-
Si le
/etc/systemd/system.conf.d/
fichier existe, commentez la ligneNUMBER
-limits.confDefaultLimitMEMLOCK
de ce fichier. Ce fichier définit une valeur par défautRLIMIT_MEMLOCK
avec une priorité élevée, qui remplace vos paramètres dans le/etc/systemd/system.conf
fichier. -
Ouvrez le
/etc/systemd/system.conf
fichier et décommentez la ligne qui le contient#DefaultLimitMEMLOCK=
. -
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 estsoft-limit:hard-limit
. -
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 au sein de 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).
Lors de l'utilisation de la configuration automatique des agents
Pour Utiliser la configuration automatique des agents (recommandé) 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/
console. -
Lorsque vous utilisez des balises d'exclusion avec une configuration automatique de l'agent :
-
Ajoutez le
false
tagGuardDutyManaged
: avant de configurer l'agent GuardDuty automatique pour votre compte.Assurez-vous d'ajouter la balise d'exclusion à vos EC2 instances Amazon avant de les lancer. Une fois que vous avez activé la configuration automatique des agents pour Amazon EC2, toute EC2 instance 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 dans le guide de EC2 l'utilisateur Amazon.
-
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 EC2 instances Amazon est de 10 % du total des cœurs de vCPU. Par exemple, si votre EC2 instance possède 4 cœurs de vCPU, l'agent de sécurité peut utiliser au maximum 40 % des 400 % disponibles.
- Limite de mémoire
-
En ce qui concerne la mémoire associée à votre EC2 instance Amazon, l'agent de GuardDuty sécurité peut utiliser une quantité limitée de mémoire.
Le tableau suivant indique la limite de mémoire.
Mémoire de l' EC2 instance Amazon
Mémoire maximale pour l' GuardDuty agent
Moins de 8 Go
128 Mo
Moins de 32 Go
256 Mo
Plus ou égal à 32 Go
1 Go
É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).