Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Voraussetzungen für die Unterstützung von Amazon EC2 EC2-Instances
Dieser Abschnitt enthält die Voraussetzungen für die Überwachung des Laufzeitverhaltens Ihrer Amazon EC2 EC2-Instances. Wenn diese Voraussetzungen erfüllt sind, finden Sie weitere Informationen unter[GuardDuty Laufzeitüberwachung aktivieren](runtime-monitoring-configuration.md).
**Topics**
+ [Machen Sie EC2-Instances SSM-verwaltet (nur für die automatische Agentenkonfiguration)](#ssm-managed-prereq-ec2)
+ [Überprüfen Sie die architektonischen Anforderungen](#validating-architecture-req-ec2)
+ [Validierung der Servicesteuerungsrichtlinie Ihrer Organisation in einer Umgebung mit mehreren Konten](#validate-organization-scp-ec2)
+ [Bei Verwendung der automatisierten Agentenkonfiguration](#runtime-ec2-prereq-automated-agent)
+ [CPU- und Speicherlimit für den Agenten GuardDuty](#ec2-cpu-memory-limits-gdu-agent)
+ [Nächster Schritt](#next-step-after-prereq-ec2)
## Machen Sie EC2-Instances SSM-verwaltet (nur für die automatische Agentenkonfiguration)
GuardDuty verwendet AWS Systems Manager (SSM), um den Security Agent auf Ihren Instances automatisch bereitzustellen, zu installieren und zu verwalten. Wenn Sie den GuardDuty Agenten manuell installieren und verwalten möchten, ist SSM nicht erforderlich.
Informationen zur Verwaltung Ihrer Amazon EC2 EC2-Instances mit Systems Manager finden Sie im *AWS Systems Manager Benutzerhandbuch* unter [Systems Manager für Amazon EC2 EC2-Instances einrichten](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up-ec2.html).
## Überprüfen Sie die architektonischen Anforderungen
Die Architektur Ihrer Betriebssystemverteilung kann sich auf das Verhalten des GuardDuty Security Agents auswirken. Sie müssen die folgenden Anforderungen erfüllen, bevor Sie Runtime Monitoring für Amazon EC2 EC2-Instances verwenden können:
+ Die Kernel-Unterstützung umfasst`eBPF`, `Tracepoints` und`Kprobe`. Für CPU-Architekturen unterstützt Runtime Monitoring AMD64 (`x64`) und ARM64 (Graviton2 und höher). [1](#runtime-monitoring-ec2-graviton-2-support)
Die folgende Tabelle zeigt die Betriebssystemdistribution, für die verifiziert wurde, dass sie den GuardDuty Security Agent für Amazon EC2 EC2-Instances unterstützt.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html)
1. Runtime Monitoring für Amazon EC2 EC2-Ressourcen unterstützt Graviton-Instances der ersten Generation wie A1-Instance-Typen nicht.
1. Support für verschiedene Betriebssysteme — GuardDuty hat die Runtime Monitoring-Unterstützung für die in der obigen Tabelle aufgeführte Betriebssystemdistribution verifiziert. Der GuardDuty Security Agent kann zwar auf Betriebssystemen ausgeführt werden, die in der obigen Tabelle nicht aufgeführt sind, aber das GuardDuty Team kann den erwarteten Sicherheitswert nicht garantieren.
1. Für jede Kernel-Version müssen Sie das `CONFIG_DEBUG_INFO_BTF` Flag auf `y` (was *wahr* bedeutet) setzen. Dies ist erforderlich, damit der GuardDuty Security Agent wie erwartet ausgeführt werden kann.
1. Bei Kernel-Versionen 5.10 und früher verwendet der GuardDuty Security Agent den gesperrten Arbeitsspeicher im RAM (`RLIMIT_MEMLOCK`), um erwartungsgemäß zu funktionieren. Wenn der `RLIMIT_MEMLOCK` Wert Ihres Systems zu niedrig ist, GuardDuty empfiehlt es sich, sowohl harte als auch weiche Grenzwerte auf mindestens 32 MB festzulegen. Hinweise zur Überprüfung und Änderung des `RLIMIT_MEMLOCK` Standardwerts finden Sie unter[Werte anzeigen und aktualisieren `RLIMIT_MEMLOCK`](#runtime-monitoring-ec2-modify-rlimit-memlock).
1. Für Ubuntu 24.04 unterstützen die Kernel-Versionen 6.13 und 6.14 nur die EC2-Agentenversionen 1.9.2 und höher.
+ Zusätzliche Anforderungen — Nur wenn Sie Amazon ECS/Amazon EC2 haben
Für Amazon ECS/Amazon EC2 empfehlen wir, die neueste Amazon ECS-optimierte Version AMIs (vom 29. September 2023 oder später) oder die Amazon ECS-Agent-Version v1.77.0 zu verwenden.
### Werte anzeigen und aktualisieren `RLIMIT_MEMLOCK`
Wenn das `RLIMIT_MEMLOCK` Limit Ihres Systems zu niedrig eingestellt ist, GuardDuty funktioniert der Security Agent möglicherweise nicht wie vorgesehen. GuardDuty empfiehlt, dass sowohl die harten als auch die weichen Grenzwerte mindestens 32 MB betragen müssen. Wenn Sie die Grenzwerte nicht aktualisieren, GuardDuty können die Laufzeitereignisse für Ihre Ressource nicht überwacht werden. Wenn `RLIMIT_MEMLOCK` es über den angegebenen Mindestgrenzen liegt, ist es für Sie optional, diese Grenzwerte zu aktualisieren.
Sie können den `RLIMIT_MEMLOCK` Standardwert entweder vor oder nach der Installation des GuardDuty Security Agents ändern.
**Um `RLIMIT_MEMLOCK` Werte anzuzeigen**
1. Führen Sie `ps aux | grep guardduty`. Dadurch wird die Prozess-ID (`pid`) ausgegeben.
1. Kopieren Sie die Prozess-ID (`pid`) aus der Ausgabe des vorherigen Befehls.
1. Führen Sie den Befehl aus, `grep "Max locked memory" /proc/pid/limits` nachdem Sie den `pid` durch die aus dem vorherigen Schritt kopierte Prozess-ID ersetzt haben.
Dadurch wird der maximal gesperrte Speicher für die Ausführung des GuardDuty Security Agents angezeigt.
**Um `RLIMIT_MEMLOCK` Werte zu aktualisieren**
1. Wenn die `/etc/systemd/system.conf.d/NUMBER-limits.conf` Datei existiert, kommentieren Sie die Zeile von `DefaultLimitMEMLOCK` aus dieser Datei aus. Diese Datei legt einen Standard `RLIMIT_MEMLOCK` mit hoher Priorität fest, der Ihre Einstellungen in der `/etc/systemd/system.conf` Datei überschreibt.
1. Öffnen Sie die `/etc/systemd/system.conf` Datei und entfernen Sie den Kommentar zu der Zeile mit. `#DefaultLimitMEMLOCK=`
1. Aktualisieren Sie den Standardwert, indem Sie sowohl feste als auch weiche `RLIMIT_MEMLOCK` Grenzwerte von mindestens 32 MB angeben. Das Update sollte so aussehen:`DefaultLimitMEMLOCK=32M:32M`. Das Format ist `soft-limit:hard-limit`.
1. Führen Sie `sudo reboot`.
## Validierung der Servicesteuerungsrichtlinie Ihrer Organisation in einer Umgebung mit mehreren Konten
Wenn Sie eine Service Control Policy (SCP) zur Verwaltung von Berechtigungen in Ihrer Organisation eingerichtet haben, überprüfen Sie, ob die Rechtegrenze die Aktion zulässt. `guardduty:SendSecurityTelemetry` Sie ist erforderlich GuardDuty , um Runtime Monitoring für verschiedene Ressourcentypen zu unterstützen.
Wenn Sie ein Mitgliedskonto sind, stellen Sie eine Verbindung mit dem zugehörigen delegierten Administrator her. Informationen zur Verwaltung SCPs für Ihre Organisation finden Sie unter [Richtlinien zur Servicesteuerung (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html).
## Bei Verwendung der automatisierten Agentenkonfiguration
Dazu [Verwenden Sie die automatische Agentenkonfiguration (empfohlen)](how-runtime-monitoring-works-ec2.md#use-automated-agent-config-ec2) AWS-Konto müssen Sie die folgenden Voraussetzungen erfüllen:
+ Wenn Sie Inclusion-Tags mit automatisierter Agentenkonfiguration verwenden, GuardDuty um eine SSM-Zuordnung für eine neue Instance zu erstellen, stellen Sie sicher, dass die neue Instance SSM-verwaltet wird und in der [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)Konsole unter **Fleet Manager** angezeigt wird.
+ Wenn Sie Ausschlusstags mit automatisierter Agentenkonfiguration verwenden:
+ Fügen Sie das `false` Tag`GuardDutyManaged`: hinzu, bevor Sie den GuardDuty automatisierten Agenten für Ihr Konto konfigurieren.
Stellen Sie sicher, dass Sie Ihren Amazon EC2 EC2-Instances das Ausschluss-Tag hinzufügen, bevor Sie sie starten. Sobald Sie die automatische Agentenkonfiguration für Amazon EC2 aktiviert haben, wird jede EC2-Instance, die ohne Ausschluss-Tag gestartet wird, von der GuardDuty automatisierten Agentenkonfiguration abgedeckt.
+ Aktivieren **Sie die Einstellung „Tags in Metadaten zulassen**“ für Ihre Instances. Diese Einstellung ist erforderlich, da das Ausschluss-Tag aus dem Instanz-Metadatendienst (IMDS) gelesen werden GuardDuty muss, um festzustellen, ob die Instanz von der Agenteninstallation ausgeschlossen werden soll. Weitere Informationen finden Sie unter [Aktivieren des Zugriffs auf Tags in Instance-Metadaten](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/work-with-tags-in-IMDS.html#allow-access-to-tags-in-IMDS) im *Amazon EC2 EC2-Benutzerhandbuch*.
## CPU- und Speicherlimit für den Agenten GuardDuty
**CPU-Limit**
Das maximale CPU-Limit für den GuardDuty Security Agent, der Amazon EC2 EC2-Instances zugeordnet ist, beträgt 10 Prozent der gesamten vCPU-Kerne. Wenn Ihre EC2-Instance beispielsweise über 4 vCPU-Kerne verfügt, kann der Security Agent maximal 40 Prozent der insgesamt verfügbaren 400 Prozent verwenden.
**Speicherlimit**
Aus dem Speicher, der Ihrer Amazon EC2 EC2-Instance zugeordnet ist, steht ein begrenzter Speicher zur Verfügung, den der GuardDuty Security Agent verwenden kann.
Die folgende Tabelle zeigt das Speicherlimit.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html)
## Nächster Schritt
Der nächste Schritt besteht darin, Runtime Monitoring zu konfigurieren und auch den Security Agent (automatisch oder manuell) zu verwalten.