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 Aktivierung von Runtime Monitoring Um Runtime Monitoring zu aktivieren und den GuardDuty Security Agent zu verwalten, müssen Sie die Voraussetzungen für jeden Ressourcentyp erfüllen, den Sie auf Bedrohungserkennung überwachen möchten. Jeder Ressourcentyp hat unterschiedliche Voraussetzungen. GuardDuty Unterstützt beispielsweise je nach Ressourcentyp unterschiedliche Betriebssystemverteilungen. Wenn Sie nur Amazon EC2 EC2-Ressourcen überwachen möchten, müssen Sie die Voraussetzungen für Amazon EC2 EC2-Instances erfüllen. Wenn Sie sich zu einem späteren Zeitpunkt dafür entscheiden, Amazon EKS-Ressourcen zu überwachen, müssen Sie die spezifischen Voraussetzungen für Amazon EKS-Cluster erfüllen. Die folgenden Abschnitte enthalten Voraussetzungen, die auf dem Ressourcentyp basieren. **Topics** + [Voraussetzungen für die Unterstützung von Amazon EC2 EC2-Instances](prereq-runtime-monitoring-ec2-support.md) + [Voraussetzungen für den Support AWS Fargate (nur Amazon ECS)](prereq-runtime-monitoring-ecs-support.md) + [Voraussetzungen für die Unterstützung von Amazon EKS-Clustern](prereq-runtime-monitoring-eks-support.md) # 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. # Voraussetzungen für den Support AWS Fargate (nur Amazon ECS) Dieser Abschnitt enthält die Voraussetzungen für die Überwachung des Laufzeitverhaltens Ihrer Fargate-Amazon ECS-Ressourcen. Wenn diese Voraussetzungen erfüllt sind, finden Sie weitere Informationen unter. [GuardDuty Laufzeitüberwachung aktivieren](runtime-monitoring-configuration.md) **Topics** + [Validierung der architektonischen Anforderungen](#validating-architecture-req-ecs) + [Voraussetzungen für den Zugriff auf Container-Images](#before-enable-runtime-monitoring-ecs) + [Validierung der Service-Control-Richtlinie Ihres Unternehmens in einer Umgebung mit mehreren Konten](#validate-organization-scp-ecs) + [Überprüfung der Rollenberechtigungen und der Grenzen der Richtlinienberechtigungen](#guardduty-runtime-monitoring-ecs-permission-boundary) + [CPU- und Arbeitsspeicherlimits](#ecs-runtime-agent-cpu-memory-limits) ## Validierung der architektonischen Anforderungen Die von Ihnen verwendete Plattform kann sich darauf auswirken, wie der GuardDuty Security Agent GuardDuty den Empfang der Runtime-Ereignisse von Ihren Amazon ECS-Clustern unterstützt. Sie müssen bestätigen, dass Sie eine der verifizierten Plattformen verwenden. **Erste Überlegungen:** Die AWS Fargate Plattform für Ihre Amazon ECS-Cluster muss Linux sein. Die entsprechende Plattformversion muss mindestens`1.4.0`, oder sein`LATEST`. Weitere Informationen zu den Plattformversionen finden Sie unter [Linux-Plattformversionen](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/platform-linux-fargate.html) im *Amazon Elastic Container Service Developer Guide*. Die Windows-Plattformversionen werden noch nicht unterstützt. ### Verifizierte Plattformen Die Betriebssystemverteilung und die CPU-Architektur wirken sich auf die Unterstützung durch den GuardDuty Security Agent aus. Die folgende Tabelle zeigt die verifizierte Konfiguration für die Installation des GuardDuty Security Agents und die Konfiguration von Runtime Monitoring. | Verteilung des Betriebssystems **[1](#runtime-monitoring-ecs-os-support)** | Kernel-Unterstützung | CPU-Architektur x64 () AMD64 | CPU-Architektur Graviton () ARM64 | | --- | --- | --- | --- | | Linux | eBPF, Tracepoints, Kprobe | Unterstützt | Unterstützt | 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. ## Voraussetzungen für den Zugriff auf Container-Images Die folgenden Voraussetzungen helfen Ihnen beim Zugriff auf das GuardDuty Sidecar-Container-Image aus dem Amazon ECR-Repository. ### Berechtigungsanforderungen Für die Aufgabenausführungsrolle sind bestimmte Amazon Elastic Container Registry (Amazon ECR) -Berechtigungen erforderlich, um das Container-Image des GuardDuty Security Agents herunterzuladen: ``` ... "ecr:GetAuthorizationToken", "ecr:BatchCheckLayerAvailability", "ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage", ... ``` Um die Amazon ECR-Berechtigungen weiter einzuschränken, können Sie den Amazon ECR-Repository-URI hinzufügen, der den GuardDuty Security Agent für hostet AWS Fargate (nur Amazon ECS). Weitere Informationen finden Sie unter [GuardDuty Hosting-Agent für Amazon ECR Repositorys](runtime-monitoring-ecr-repository-gdu-agent.md). Sie können entweder die von [Amazon ECSTask ExecutionRolePolicy](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_execution_IAM_role.html) verwaltete Richtlinie verwenden oder die oben genannten Berechtigungen zu Ihrer `TaskExecutionRole` Richtlinie hinzufügen. ### Konfiguration der Aufgabendefinition Wenn Sie Amazon ECS-Services erstellen oder aktualisieren, müssen Sie Subnetzinformationen in Ihrer Aufgabendefinition angeben: Für die Ausführung von [CreateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_CreateService.html)und [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html) APIs in der *Amazon Elastic Container Service API-Referenz* müssen Sie die Subnetzinformationen übergeben. Weitere Informationen finden Sie unter [Amazon ECS-Aufgabendefinitionen](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task_definitions.html) im *Amazon Elastic Container Service Developer Guide*. ### Anforderungen an die Netzwerkkonnektivität Sie müssen die Netzwerkkonnektivität sicherstellen, um das GuardDuty Container-Image von Amazon ECR herunterzuladen. Diese Anforderung ist spezifisch für, GuardDuty da das Unternehmen Amazon ECR verwendet, um seinen Sicherheitsagenten zu hosten. Abhängig von Ihrer Netzwerkkonfiguration müssen Sie eine der folgenden Optionen implementieren: **Option 1 — Nutzung des öffentlichen Netzwerkzugangs (falls verfügbar)** Wenn Ihre Fargate-Aufgaben in Subnetzen mit ausgehendem Internetzugang ausgeführt werden, ist keine zusätzliche Netzwerkkonfiguration erforderlich. **Option 2 — Verwendung von Amazon VPC-Endpunkten (für private Subnetze)** Wenn Ihre Fargate-Aufgaben in privaten Subnetzen ohne Internetzugang ausgeführt werden, müssen Sie VPC-Endpunkte für ECR konfigurieren, um sicherzustellen, dass der ECR-Repository-URI, der den Security Agent hostet, über das Netzwerk zugänglich ist. GuardDuty Ohne diese Endpunkte können Aufgaben in privaten Subnetzen das Container-Image nicht herunterladen. GuardDuty Anweisungen zur Einrichtung von VPC-Endpunkten finden Sie unter [Erstellen der VPC-Endpunkte für Amazon ECR](https://docs.aws.amazon.com/AmazonECR/latest/userguide/vpc-endpoints.html#ecr-setting-up-vpc-create) im *Amazon Elastic Container* Registry-Benutzerhandbuch. Informationen darüber, wie Fargate den GuardDuty Container herunterladen kann, finden Sie unter [Verwenden von Amazon ECR-Images mit Amazon ECS](https://docs.aws.amazon.com/AmazonECR/latest/userguide/ECR_on_ECS.html) im *Amazon Elastic Container Registry-Benutzerhandbuch*. ### Sicherheitsgruppenkonfiguration Die GuardDuty Container-Images befinden sich in Amazon ECR und erfordern Amazon S3 S3-Zugriff. Diese Anforderung ist spezifisch für das Herunterladen von Container-Images von Amazon ECR. Für Aufgaben mit eingeschränktem Netzwerkzugriff müssen Sie Ihre Sicherheitsgruppen so konfigurieren, dass sie den Zugriff auf S3 zulassen. Fügen Sie Ihrer Sicherheitsgruppe eine Regel für ausgehenden Datenverkehr hinzu, die den Datenverkehr zur [Liste der verwalteten S3-Präfixe (`pl-xxxxxxxx`) an Port 443](https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html#gateway-endpoint-security) zulässt. Informationen zum Hinzufügen einer ausgehenden Regel finden [Sie unter Sicherheitsgruppenregeln konfigurieren](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-security-group-rules.html) im *Amazon VPC-Benutzerhandbuch*. Informationen zur Anzeige Ihrer AWS verwalteten Präfixlisten in der Konsole oder zur Beschreibung mit AWS Command Line Interface (AWS CLI) finden Sie unter [AWS-verwaltete Präfixlisten](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html) im *Amazon VPC-Benutzerhandbuch*. ## Validierung der Service-Control-Richtlinie Ihres Unternehmens in einer Umgebung mit mehreren Konten In diesem Abschnitt wird erklärt, wie Sie Ihre SCP-Einstellungen (Service Control Policy) validieren, um sicherzustellen, dass Runtime Monitoring in Ihrer gesamten Organisation erwartungsgemäß funktioniert. Wenn Sie eine oder mehrere Service Control-Richtlinien zur Verwaltung von Berechtigungen in Ihrer Organisation eingerichtet haben, müssen Sie sicherstellen, dass die `guardduty:SendSecurityTelemetry` Aktion nicht verweigert wird. Informationen zur Funktionsweise SCPs finden Sie unter [SCP-Evaluierung](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_evaluation.html) im *AWS Organizations Benutzerhandbuch*. Wenn Sie ein Mitgliedskonto sind, stellen Sie eine Verbindung mit dem zugehörigen delegierten Administrator her. Informationen zur Verwaltung SCPs für Ihr Unternehmen finden Sie unter [Richtlinien zur Servicesteuerung (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) im *AWS Organizations Benutzerhandbuch*. Führen Sie die folgenden Schritte für alle aus SCPs , die Sie in Ihrer Umgebung mit mehreren Konten eingerichtet haben: **Die Validierung `guardduty:SendSecurityTelemetry` ist in SCP nicht verweigert** 1. Melden Sie sich in der Organisationskonsole unter an [https://console.aws.amazon.com/organizations/](https://console.aws.amazon.com/organizations/). Sie müssen sich als IAM-Rolle oder als Root-Benutzer [(nicht empfohlen)](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials) im Verwaltungskonto der Organisation anmelden. 1. Wählen Sie im linken Navigationsbereich **Policies (Richtlinien)**. Wählen Sie dann unter **Unterstützte Richtlinientypen die** Option **Dienststeuerungsrichtlinien** aus. 1. Wählen Sie auf der Seite **Service Control-Richtlinien** den Namen der Richtlinie aus, die Sie validieren möchten. 1. Sehen Sie sich auf der Detailseite der Richtlinie den **Inhalt** dieser Richtlinie an. Stellen Sie sicher, dass die `guardduty:SendSecurityTelemetry` Aktion nicht verweigert wird. Die folgende SCP-Richtlinie ist ein Beispiel dafür, wie die Aktion *nicht verweigert* werden kann: `guardduty:SendSecurityTelemetry` ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "guardduty:SendSecurityTelemetry" ], "Resource": "*" } ] } ``` ------ Wenn Ihre Richtlinie diese Aktion ablehnt, müssen Sie die Richtlinie aktualisieren. Weitere Informationen finden Sie unter [Aktualisieren einer Service-Kontrollrichtlinie (SCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_policies_update.html#update_policy) im *AWS Organizations -Benutzerhandbuch*. ## Überprüfung der Rollenberechtigungen und der Grenzen der Richtlinienberechtigungen Gehen Sie wie folgt vor, um zu überprüfen, ob die mit der Rolle und der zugehörigen Richtlinie verknüpften Berechtigungsgrenzen **nicht** die `guardduty:SendSecurityTelemetry` Aktion einschränken. **So zeigen Sie die Berechtigungsgrenzen für Rollen und deren Richtlinie an** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die IAM-Konsole unter [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. Wählen Sie im linken Navigationsbereich unter **Zugriffsverwaltung** die Option **Rollen** aus. 1. Wählen Sie auf der Seite **Rollen** die Rolle aus*`TaskExecutionRole`*, die Sie möglicherweise erstellt haben. 1. Erweitern Sie auf der Seite der ausgewählten Rolle auf der Registerkarte **Berechtigungen** den mit dieser Rolle verknüpften Richtliniennamen. Stellen Sie anschließend sicher, dass diese Richtlinie keine Einschränkungen vorsieht`guardduty:SendSecurityTelemetry`. 1. Wenn die **Grenze für Berechtigungen** festgelegt ist, erweitern Sie diesen Abschnitt. Erweitern Sie dann jede Richtlinie, um sicherzustellen, dass sie die `guardduty:SendSecurityTelemetry` Aktion nicht einschränkt. Die Richtlinie sollte in etwa so aussehen[Example SCP policy](#ecs-runtime-scp-not-deny-policy-example). Führen Sie bei Bedarf eine der folgenden Aktionen aus: + Um die Richtlinie zu ändern, wählen Sie **Bearbeiten** aus. Aktualisieren Sie auf der Seite „**Berechtigungen ändern**“ für diese Richtlinie die **Richtlinie im Richtlinien-Editor**. Stellen Sie sicher, dass das JSON-Schema gültig bleibt. Wählen Sie anschließend **Weiter**. Anschließend können Sie die Änderungen überprüfen und speichern. + Um diese Berechtigungsgrenze zu ändern und eine andere Grenze auszuwählen, wählen Sie **Grenze ändern**. + Um diese Berechtigungsgrenze zu entfernen, wählen Sie **Grenze entfernen** aus. Informationen zur Verwaltung von Richtlinien finden Sie unter [Richtlinien und Berechtigungen AWS Identity and Access Management im](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) *IAM-Benutzerhandbuch*. ## CPU- und Arbeitsspeicherlimits In der Fargate-Aufgabendefinition müssen Sie den CPU- und Speicherwert auf Taskebene angeben. Die folgende Tabelle zeigt die gültigen Kombinationen von CPU- und Speicherwerten auf Taskebene sowie die entsprechende maximale Speicherbegrenzung des GuardDuty Security Agents für den Container. GuardDuty [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/prereq-runtime-monitoring-ecs-support.html) Nachdem Sie Runtime Monitoring aktiviert und festgestellt haben, dass der Abdeckungsstatus Ihres Clusters **fehlerfrei** ist, können Sie die Container Insight-Metriken einrichten und anzeigen. Weitere Informationen finden Sie unter [Überwachung auf dem Amazon ECS-Cluster einrichten](runtime-monitoring-setting-cpu-mem-monitoring.md#ecs-runtime-cpu-memory-monitoring-agent). Der nächste Schritt besteht darin, Runtime Monitoring und auch den Security Agent zu konfigurieren. # Voraussetzungen für die Unterstützung von Amazon EKS-Clustern Dieser Abschnitt enthält die Voraussetzungen für die Überwachung des Laufzeitverhaltens Ihrer Amazon EKS-Ressourcen. Diese Voraussetzungen sind entscheidend, damit der GuardDuty Agent wie erwartet funktioniert. Wenn diese Voraussetzungen erfüllt sind, beginnen [GuardDuty Laufzeitüberwachung aktivieren](runtime-monitoring-configuration.md) Sie mit der Überwachung Ihrer Ressourcen. ## Support für Amazon EKS-Funktionen Runtime Monitoring **unterstützt** Amazon EKS-Cluster, die auf Amazon EC2 EC2-Instances ausgeführt werden, und Amazon EKS Auto Mode. Runtime Monitoring **unterstützt keine** Amazon EKS-Cluster mit Amazon EKS-Hybridknoten und solche, die darauf laufen AWS Fargate. Informationen zu diesen Amazon EKS-Funktionen finden Sie unter [Was ist Amazon EKS?](https://docs.aws.amazon.com/eks/latest/userguide/what-is-eks.html) im **Amazon EKS-Benutzerhandbuch**. ## Validierung der architektonischen Anforderungen Die von Ihnen verwendete Plattform kann sich darauf auswirken, wie der GuardDuty Security Agent den Empfang von Runtime-Ereignissen aus Ihren EKS-Clustern unterstützt GuardDuty . Sie müssen bestätigen, dass Sie eine der verifizierten Plattformen verwenden. Wenn Sie den GuardDuty Agenten manuell verwalten, stellen Sie sicher, dass die Kubernetes-Version die GuardDuty Agentenversion unterstützt, die derzeit verwendet wird. ### Verifizierte Plattformen Die Betriebssystemverteilung, die Kernel-Version und die CPU-Architektur wirken sich auf die vom GuardDuty Security Agent bereitgestellte Unterstützung aus. 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-eks-graviton-2-support) Die folgende Tabelle zeigt die verifizierte Konfiguration für die Bereitstellung des GuardDuty Security Agents und die Konfiguration von EKS Runtime Monitoring. | Verteilung des Betriebssystems **[2](#runtime-monitoring-eks-os-support)** | Kernel-Version **[3](#runtime-monitoring-eks-kernel-version-required-flag)** | Unterstützte Kubernetes-Version | | --- | --- | --- | | Bottlerocket | 5,4, 5,10, 5,15, 6,1 [4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.23 - v1.35 | | Ubuntu | 5.4, 5,10, 5,15, 6,1 [4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 | | Amazon Linux 2 | 5.4, 5,10, 5,15, 6,1 [4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 | | Amazon Linux 2023 *[5](#runtime-eks-al2023-support-v1.6.0)* | 5,4, 5,10, 5,15, 6,1 [4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 | | RedHat 9.4 | 5,14 [4](#v6.1-kernel-dns-findings-unsupported-eks) | v1.21 - v1.35 | | Fedora 34 | 5,11, 5,17 | v1.21 - v1.35 | | Fedora 40 | 6.8 | v1.28 - v1.35 | | Fedora 41 | 6,12 | v1.28 - v1.35 | | CentOS Stream 9 | 5,14 | v1.21 - v1.35 | 1. Runtime Monitoring für Amazon EKS-Cluster 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. Derzeit GuardDuty können mit der Kernel-Version `6.1` keine Dateien generiert werden[GuardDuty Runtime Monitoring: Typen finden](findings-runtime-monitoring.md), die sich darauf [DNS-Ereignisse (Domain Name System)](runtime-monitoring-collected-events.md#eks-runtime-dns-events) beziehen. 1. Runtime Monitoring unterstützt AL2023 ab der Version des GuardDuty Security Agents v1.6.0 und höher. Weitere Informationen finden Sie unter [GuardDuty Security-Agent-Versionen für Amazon EKS-Ressourcen](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history). #### Kubernetes-Versionen, die vom Security Agent unterstützt werden GuardDuty Die folgende Tabelle zeigt die Kubernetes-Versionen für Ihre EKS-Cluster, die vom Security Agent unterstützt werden. GuardDuty | Version des Amazon GuardDuty EKS-Zusatz-Sicherheitsagenten | Kubernetes-Version | | --- | --- | | v1.12.1 (aktuell — v1.12.1-eksbuild.2) | 1.28 - 1.35 | | v1.11.0 (aktuell - v1.11.0-eksbuild.4) | 1.28 - 1.34 | | v1.10.0 (aktuell - v1.10.0-eksbuild.2) | 1.21 - 1.33 | | v1.9.0 (aktuell - v1.9.0-eksbuild.2) v1.8.1 (aktuell - v1.8.1-eksbuild.2) | 1.21 - 1.32 | | v1.7.1 Version 1.7,0 v1.6.1 | 1,21 - 1,31 | | v1.6.0 Version 1.5.0 v1.4.1 Version 1.4.0 v1.3.1 | 1,21 - 1,29 | | v1.3.0 v1.2.0 | 1,21 - 1,28 | | v1.1.0 | 1,21 - 1,26 | | v1.0.0 | 1,21 - 1,25 | Für einige Versionen des GuardDuty Security Agents wird der Standardsupport auslaufen. Informationen zu den Agent-Release-Versionen finden Sie unter. [GuardDuty Security-Agent-Versionen für Amazon EKS-Ressourcen](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history) ### CPU- und Arbeitsspeicherlimits Die folgende Tabelle zeigt die CPU- und Speicherlimits für das Amazon EKS-Add-on für GuardDuty (`aws-guardduty-agent`). | Parameter | Minimale Grenze | Maximale Grenze | | --- | --- | --- | | CPU | 200m | 1000m | | Arbeitsspeicher | 256 Mi | 1024Mi | Wenn Sie Amazon EKS Add-on Version 1.5.0 oder höher verwenden, GuardDuty bietet es die Möglichkeit, das Add-On-Schema für Ihre CPU- und Speicherwerte zu konfigurieren. Informationen zum konfigurierbaren Bereich finden Sie unter[Konfigurierbare Parameter und Werte](guardduty-configure-security-agent-eks-addon.md#gdu-eks-addon-configure-parameters-values). Nachdem Sie die EKS-Laufzeit-Überwachung aktiviert und den Abdeckungsstatus Ihrer EKS-Cluster bewertet haben, können Sie die Container-Erkenntnis-Metriken einrichten und anzeigen. Weitere Informationen finden Sie unter [Einrichten der CPU- und Arbeitsspeicherüberwachung](runtime-monitoring-setting-cpu-mem-monitoring.md). ## Überprüfen Sie die Service Control-Richtlinie Ihrer Organisation Wenn Sie eine Service Control Policy (SCP) zur Verwaltung von Berechtigungen in Ihrer Organisation eingerichtet haben, stellen Sie sicher, dass die Rechtegrenzen nicht einschränkend sind. `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).