Conditions requises pour le support des EC2 instances Amazon - Amazon GuardDuty
Gérer EC2 les instances par SSM (pour les agents automatisés uniquement)Valider les exigences architecturalesValidation de la politique de contrôle des services de votre organisation dans un environnement multi-comptesLors de l'utilisation de la configuration automatique des agentsLimite du processeur et de la mémoireÉtape suivante

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.

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 incluteBPF, Tracepoints etKprobe. Pour les architectures de processeur, Runtime Monitoring prend en charge AMD64 (x64) et ARM64 (Graviton2 et versions ultérieures). 1

    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 EC2 instances Amazon.

    Distribution du système d'exploitation 2 Version du noyau 3
    Amazon Linux 2

    5,4 4, 5,10 4, 5,15
    Amazon Linux 2023

    5,4 4, 5,10 4, 5,15, 6,1, 6,5, 6,8, 6,12
    Ubuntu 20.04 et Ubuntu 22.04

    5,4 4, 5,10 4, 5,15, 6,1, 6,5, 6,8
    Ubuntu 24.04

    6.8
    Debian 11 et Debian 12

    5,4 4, 5,10 4, 5,15, 6,1, 6,5, 6,8
    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

    1. 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.

    2. 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.

    3. Quelle que soit la version du noyau, vous devez définir l'CONFIG_DEBUG_INFO_BTFindicateur sur y (c'est-à-dire vrai). Cela est nécessaire pour que l'agent GuardDuty de sécurité puisse fonctionner comme prévu.

    4. 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, 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

  1. Exécutez ps aux | grep guardduty. Cela affichera l'ID du processus (pid).

  2. Copiez l'ID du processus (pid) à partir de la sortie de la commande précédente.

  3. 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.

  2. Ouvrez le /etc/systemd/system.conf fichier et décommentez la ligne qui le contient#DefaultLimitMEMLOCK=.

  3. 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.

  4. 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:SendSecurityTelemetryaction. 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 tag GuardDutyManaged : 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).