View a markdown version of this page

Conditions requises pour la prise en charge des instances Amazon EC2 - Amazon GuardDuty
Gérer les instances EC2 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 de processeur et de 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 la prise en charge des instances Amazon EC2

Cette section inclut les prérequis pour surveiller le comportement d'exécution de vos instances Amazon EC2. Une fois ces conditions préalables remplies, voirActiver la surveillance du GuardDuty temps d'exécution.

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, SSM n'est pas requis.

Pour gérer vos instances Amazon EC2 avec Systems Manager, consultez la section Configuration de Systems Manager pour les instances Amazon EC2 dans le Guide de l'AWS Systems Manager 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 remplir les conditions suivantes avant d'utiliser Runtime Monitoring pour les instances Amazon EC2 :

  • La prise en charge du noyau incluteBPF, Tracepoints etKprobe. Pour les architectures CPU, 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 instances Amazon EC2.

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

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

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

    5,4 4, 5,10 4, 5,15, 6,1, 6,5, 6,8, 6,13, 6,14, 7,0
    Debian 11, 12 et 13

    5,4 4, 5,10 4, 5,15, 6,1, 6,5, 6,8, 6,12
    RedHat 9,4 et 10,2

    5,14 et 6,12
    Fedora 34, 40, 41, 43, 44

    5,11, 5,17, 6,8, 6,12, 7,1
    CentOS Stream 9 et 10

    5,14 et 6,12
    Oracle Linux 8.9 et 9.3

    5,15
    Rocky Linux 9.5 et 10.1

    5,14 et 6,12
    Alma Linux 9 et 10

    5,14 et 6,12
    SUSE Linux Enterprise Server 16

    6,12

    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. Prise en charge de différents systèmes d'exploitation : GuardDuty a vérifié la prise en charge de Runtime Monitoring 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 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 des valeurs RLIMIT_MEMLOCK.

  • Exigences supplémentaires : uniquement si vous possédez Amazon ECS/Amazon EC2

    Pour Amazon ECS/Amazon EC2, nous vous recommandons d'utiliser les dernières ECS-optimized AMI Amazon (datées du 29 septembre 2023 ou ultérieure), ou d'utiliser la version de l'agent Amazon ECS v1.77.0.

Affichage et mise à jour des valeurs RLIMIT_MEMLOCK

Lorsque la RLIMIT_MEMLOCK limite de votre système est trop basse, 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. Lorsque la valeur RLIMIT_MEMLOCK est supérieure aux limites minimales indiquées, la mise à jour de ces limites devient facultative.

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 valeurs RLIMIT_MEMLOCK

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

  2. Copiez l'ID du processus (pid) depuis 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 mémoire verrouillée maximale pour exécuter l'agent GuardDuty de sécurité.

Pour mettre à jour les valeurs RLIMIT_MEMLOCK

  1. Si le /etc/systemd/system.conf.d/NUMBER-limits.conf fichier existe, commentez la ligne de DefaultLimitMEMLOCK from this file. Ce fichier définit une valeur par défaut RLIMIT_MEMLOCK avec une priorité élevée, qui remplace les paramètres que vous avez définis dans le /etc/systemd/system.conf fichier.

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

  3. Mettez à jour la valeur par défaut en fournissant des RLIMIT_MEMLOCK limites strictes et souples à 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 configuré 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:SendSecurityTelemetryaction. GuardDuty nécessite cette autorisation pour prendre en charge la surveillance de l'exécution sur différents types de ressources.

Si votre compte est un compte de membre, contactez l'administrateur délégué associé. Pour plus d'informations sur la gestion des SCP pour votre organisation, consultez la section Politiques de contrôle des services (SCP).

Lors de l'utilisation de la configuration automatique des agents

PourUtiliser la configuration automatique des agents (recommandé), 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 d'agent automatisée :

    • 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 section Configuration GuardDuty automatique de l'agent.

    • Activez Autoriser les balises dans le paramètre de métadonnées pour vos instances. Ce paramètre est obligatoire car il GuardDuty doit 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 la section Activer l'accès aux balises dans les métadonnées de l'instance dans le guide de l'utilisateur Amazon EC2.

Limite de CPU et de mémoire pour GuardDuty l'agent

Limite du processeur

GuardDuty limite l'agent de sécurité à 10 % de la capacité totale du processeur virtuel de l'instance. Par exemple, sur une instance dotée de 4 cœurs de processeur virtuel, l'agent peut utiliser au maximum 0,4 processeur virtuel.

Limite de mémoire

Dans la mémoire associée à votre instance Amazon EC2, 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'instance Amazon EC2

Mémoire maximale pour l' GuardDuty agent

Moins de 8 Go

128 Mo

8 Go à moins de 32 Go

256 Mo

Supérieur ou égal à 32 Go

1 Go

Étape suivante

L'étape suivante consiste à configurer Runtime Monitoring et à gérer l'agent de sécurité (automatiquement ou manuellement).