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.
# GuardDuty Überwachung der Laufzeit
Runtime Monitoring beobachtet und analysiert Ereignisse auf Betriebssystemebene, Netzwerk- und Dateiereignisse, um Ihnen zu helfen, potenzielle Bedrohungen in bestimmten AWS Workloads in Ihrer Umgebung zu erkennen.
**Unterstützte AWS Ressourcen in Runtime Monitoring** — GuardDuty hatte Runtime Monitoring ursprünglich veröffentlicht, um nur Amazon Elastic Kubernetes Service (Amazon EKS) -Ressourcen zu unterstützen. Jetzt können Sie die Runtime Monitoring-Funktion verwenden, um Bedrohungen auch für Ihre AWS Fargate Amazon Elastic Container Service (Amazon ECS) - und Amazon Elastic Compute Cloud (Amazon EC2) -Ressourcen zu erkennen.
GuardDuty unterstützt keine Amazon EKS-Cluster, die auf laufen AWS Fargate.
In diesem Dokument und anderen Abschnitten, die sich auf Runtime Monitoring beziehen, GuardDuty verwendet die Terminologie des **Ressourcentyps**, um sich auf Amazon EKS-, Fargate, Amazon ECS- und Amazon EC2 EC2-Ressourcen zu beziehen.
Runtime Monitoring verwendet einen GuardDuty Security Agent, der Einblicke in das Laufzeitverhalten wie Dateizugriff, Prozessausführung, Befehlszeilenargumente und Netzwerkverbindungen bietet. Für jeden Ressourcentyp, den Sie auf potenzielle Bedrohungen überwachen möchten, können Sie den Security Agent für diesen spezifischen Ressourcentyp entweder automatisch oder manuell verwalten (mit Ausnahme von Fargate (nur Amazon ECS)). Wenn Sie den Security Agent automatisch verwalten, erlauben Sie, GuardDuty den Security Agent in Ihrem Namen zu installieren und zu aktualisieren. Wenn Sie den Security Agent für Ihre Ressourcen jedoch manuell verwalten, sind Sie dafür verantwortlich, den Security Agent bei Bedarf zu installieren und zu aktualisieren.
Mit dieser erweiterten Funktion GuardDuty können Sie potenzielle Bedrohungen identifizieren und darauf reagieren, die möglicherweise auf Anwendungen und Daten abzielen, die in Ihren individuellen Workloads und Instanzen ausgeführt werden. Eine Bedrohung kann beispielsweise dadurch entstehen, dass ein einzelner Container kompromittiert wird, auf dem eine anfällige Web-Anwendung ausgeführt wird. Diese Web-Anwendung verfügt möglicherweise über Zugriffsberechtigungen für die zugrunde liegenden Container und Workloads. In diesem Fall könnten falsch konfigurierte Anmeldedaten möglicherweise zu einem umfassenderen Zugriff auf das Konto und die darin gespeicherten Daten führen.
Durch die Analyse der Laufzeitereignisse der einzelnen Container und Workloads GuardDuty kann in einer Anfangsphase potenziell die Kompromittierung eines Containers und der zugehörigen AWS Anmeldeinformationen erkannt und Versuche, Berechtigungen zu erweitern, verdächtige API-Anfragen und böswillige Zugriffe auf die Daten in Ihrer Umgebung erkannt werden.
**Topics**
+ [Funktionsweise](how-does-runtime-monitoring-work.md)
+ [Wie funktioniert die kostenlose 30-Tage-Testversion in Runtime Monitoring](runtime-monitoring-free-trial-works.md)
+ [Voraussetzungen für die Aktivierung von Runtime Monitoring](runtime-monitoring-prerequisites.md)
+ [GuardDuty Laufzeitüberwachung aktivieren](runtime-monitoring-configuration.md)
+ [Verwaltung von GuardDuty Security Agents](runtime-monitoring-managing-agents.md)
+ [Überprüfung der Statistiken zur Laufzeitabdeckung und Behebung von Problemen](runtime-monitoring-assessing-coverage.md)
+ [Einrichten der CPU- und Arbeitsspeicherüberwachung](runtime-monitoring-setting-cpu-mem-monitoring.md)
+ [Gemeinsam genutzte VPC mit Runtime Monitoring verwenden](runtime-monitoring-shared-vpc.md)
+ [Verwendung von Infrastructure as Code (IaC) mit GuardDuty automatisierten Sicherheitsagenten](using-iac-with-gdu-automated-agents-runtime-monitoring.md)
+ [Gesammelte Laufzeit-Ereignistypen, die GuardDuty verwendet](runtime-monitoring-collected-events.md)
+ [GuardDuty Hosting-Agent für Amazon ECR Repositorys](runtime-monitoring-ecr-repository-gdu-agent.md)
+ [Zwei Security Agents auf demselben zugrunde liegenden Host](two-security-agents-installed-on-ec2-node.md)
+ [EKS-Laufzeitüberwachung in GuardDuty](eks-runtime-monitoring-guardduty.md)
+ [GuardDuty Release-Versionen des Security Agents](runtime-monitoring-agent-release-history.md)
+ [Ressourcen in Runtime Monitoring deaktivieren, deinstallieren und bereinigen](runtime-monitoring-agent-resource-clean-up.md)
# Funktionsweise
Um Runtime Monitoring verwenden zu können, müssen Sie Runtime Monitoring aktivieren und anschließend den GuardDuty Security Agent verwalten. In der folgenden Liste wird dieser zweistufige Prozess erklärt:
1. **Aktivieren Sie Runtime Monitoring** für Ihr Konto, damit es die Runtime-Ereignisse akzeptieren GuardDuty kann, die es von Ihren Amazon EC2 EC2-Instances, Amazon ECS-Clustern und Amazon EKS-Workloads empfängt.
1. **Verwalten Sie den GuardDuty Agenten** für die einzelnen Ressourcen, für die Sie das Laufzeitverhalten überwachen möchten. Je nach Ressourcentyp können Sie Folgendes wählen:
+ Verwenden Sie die automatische Agentenkonfiguration, die die Agentenbereitstellung GuardDuty verwaltet, und automatisch einen Amazon Virtual Private Cloud (Amazon VPC) -Endpunkt.
+ Installieren Sie den Agenten manuell, wofür Sie als Voraussetzung den VPC-Endpunkt erstellen müssen.
Der Security Agent verwendet den VPC-Endpunkt, um Ereignisse zu übertragen GuardDuty und so sicherzustellen, dass die Daten im AWS Netzwerk bleiben. Dieser Ansatz verbessert die Sicherheit und ermöglicht GuardDuty die Überwachung und Analyse des Laufzeitverhaltens Ihrer Ressourcen (Amazon EKS, Amazon EC2 und AWS Fargate-Amazon ECS). GuardDuty verwendet [Instanzidentitätsrollen](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#ec2-instance-identity-roles), die den Security Agent für jeden Ressourcentyp authentifizieren, um die zugehörigen Laufzeitereignisse an den VPC-Endpunkt zu senden.
**Anmerkung**
GuardDuty macht die Runtime-Ereignisse für Sie nicht zugänglich.
Wenn Sie den Security Agent (entweder manuell oder über GuardDuty) in EKS Runtime Monitoring oder Runtime Monitoring for EC2-Instances verwalten und derzeit auf einer Amazon EC2 EC2-Instance bereitgestellt GuardDuty ist und diese [Gesammelte Laufzeit-Ereignistypen](runtime-monitoring-collected-events.md) von dieser Instance empfängt, GuardDuty wird Ihnen die Analyse der VPC-Flow-Logs von dieser Amazon EC2 EC2-Instance nicht in Rechnung gestellt. AWS-Konto Dadurch werden doppelte Nutzungskosten für das Konto GuardDuty vermieden.
In den folgenden Themen wird erklärt, wie die Aktivierung von Runtime Monitoring und die Verwaltung des GuardDuty Security Agents für jeden Ressourcentyp unterschiedlich funktionieren.
**Topics**
+ [Funktionsweise von Runtime Monitoring mit Amazon-EKS-Clustern](how-runtime-monitoring-works-eks.md)
+ [So funktioniert Runtime Monitoring mit Amazon EC2 EC2-Instances](how-runtime-monitoring-works-ec2.md)
+ [So funktioniert Runtime Monitoring mit Fargate (nur Amazon ECS)](how-runtime-monitoring-works-ecs-fargate.md)
+ [Nachdem Sie Runtime Monitoring aktiviert haben](runtime-monitoring-after-configuration.md)
# Funktionsweise von Runtime Monitoring mit Amazon-EKS-Clustern
Runtime Monitoring verwendet ein [EKS-Add-on `aws-guardduty-agent`](https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html#workloads-add-ons-available-eks), das auch als GuardDuty Security Agent bezeichnet wird. Nachdem der GuardDuty Security Agent auf Ihren EKS-Clustern installiert wurde, GuardDuty kann er Runtime-Ereignisse für diese EKS-Cluster empfangen.
**Hinweise**
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**.
Sie können die Laufzeitereignisse Ihrer Amazon EKS-Cluster entweder auf Konto- oder Clusterebene überwachen. Sie können den GuardDuty Security Agent nur für die Amazon EKS-Cluster verwalten, die Sie im Hinblick auf die Erkennung von Bedrohungen überwachen möchten. Sie können den GuardDuty Security Agent entweder manuell verwalten oder indem GuardDuty Sie die automatische Agentenkonfiguration verwenden, indem Sie die automatische Agentenkonfiguration verwenden.
Wenn Sie den Ansatz der automatisierten Agentenkonfiguration verwenden, GuardDuty um die Bereitstellung des Security Agents in Ihrem Namen zu verwalten, wird automatisch **ein Amazon Virtual Private Cloud (Amazon VPC) -Endpunkt erstellt**. Der Security Agent übermittelt die Runtime-Ereignisse über diesen Amazon VPC-Endpunkt an. GuardDuty
Erstellt zusammen mit dem VPC-Endpunkt GuardDuty auch eine neue Sicherheitsgruppe. Die Regeln für eingehenden Datenverkehr (Eingangsregeln) steuern den Datenverkehr, der die Ressourcen erreichen darf, die der Sicherheitsgruppe zugeordnet sind. GuardDuty fügt eingehende Regeln hinzu, die dem VPC-CIDR-Bereich für Ihre Ressource entsprechen, und passt sich diesem auch an, wenn sich der CIDR-Bereich ändert. Weitere Informationen finden Sie unter [VPC CIDR-Bereich](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html) im *Amazon VPC-Benutzerhandbuch*.
**Hinweise**
Für die Nutzung des VPC-Endpunkts fallen keine zusätzlichen Kosten an.
Arbeiten mit zentralisierter VPC mit automatisiertem Agenten — Wenn Sie die GuardDuty automatisierte Agentenkonfiguration für einen Ressourcentyp verwenden, GuardDuty wird in Ihrem Namen ein VPC-Endpunkt für alle erstellt. VPCs Dazu gehören die zentralisierte VPC und Spoke VPCs. GuardDuty unterstützt nicht die Erstellung eines VPC-Endpunkts nur für die zentralisierte VPC. Weitere Informationen zur Funktionsweise der zentralisierten VPC finden Sie unter [Interface VPC Endpoints](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html#interface-vpc-endpoints) im *AWS Whitepaper — Aufbau einer skalierbaren und sicheren* Multi-VPC-Netzwerkinfrastruktur. AWS
## Ansätze zur Verwaltung von GuardDuty Sicherheitsagenten in Amazon EKS-Clustern
Vor dem 13. September 2023 konnten Sie den Security Agent so konfigurieren, GuardDuty dass er auf Kontoebene verwaltet wird. Dieses Verhalten deutete darauf hin, dass der Security Agent standardmäßig auf allen EKS-Clustern verwaltet GuardDuty wird, die zu einem gehören AWS-Konto. GuardDuty Bietet jetzt eine detaillierte Funktion, die Ihnen bei der Auswahl der EKS-Cluster hilft, auf denen Sie den Security Agent verwalten GuardDuty möchten.
Wenn Sie [Den GuardDuty Security Agent manuell verwalten](#eks-runtime-using-gdu-agent-manually) wählen, können Sie immer noch die EKS-Cluster auswählen, die Sie überwachen möchten. Um den Agenten jedoch manuell verwalten zu können, AWS-Konto ist die Erstellung eines Amazon VPC-Endpunkts für Sie Voraussetzung.
**Anmerkung**
Unabhängig davon, welchen Ansatz Sie zur Verwaltung des GuardDuty Security Agents verwenden, ist EKS Runtime Monitoring immer auf Kontoebene aktiviert.
**Topics**
+ [Verwalten Sie den Security Agent über GuardDuty](#eks-runtime-using-gdu-agent-management-auto)
+ [Den GuardDuty Security Agent manuell verwalten](#eks-runtime-using-gdu-agent-manually)
### Verwalten Sie den Security Agent über GuardDuty
GuardDuty verteilt und verwaltet den Security Agent in Ihrem Namen. Sie können die EKS-Cluster in Ihrem Konto jederzeit überwachen, indem Sie einen der folgenden Ansätzen verwenden.
**Topics**
+ [Überwachen Sie alle EKS-Cluster](#gdu-security-agent-all-eks-custers)
+ [Schließt selektive EKS-Cluster aus](#eks-runtime-using-exclusion-tags)
+ [Ausgewählte EKS-Cluster einbeziehen](#eks-runtime-using-inclusion-tags)
#### Überwachen Sie alle EKS-Cluster
Verwenden Sie diesen Ansatz, wenn Sie GuardDuty den Security Agent für alle EKS-Cluster in Ihrem Konto bereitstellen und verwalten möchten. Standardmäßig GuardDuty wird der Security Agent auch auf einem potenziell neuen EKS-Cluster installiert, der in Ihrem Konto erstellt wurde.
**Auswirkungen der Verwendung dieses Ansatzes**
+ GuardDuty erstellt einen Amazon Virtual Private Cloud (Amazon VPC) -Endpunkt, über den der GuardDuty Security Agent die Runtime-Ereignisse übermittelt GuardDuty. Es fallen keine zusätzlichen Kosten für die Erstellung des Amazon VPC-Endpunkts an, wenn Sie den Security Agent über GuardDuty verwalten.
+ Es ist erforderlich, dass Ihr Worker-Knoten über einen gültigen Netzwerkpfad zu einem aktiven `guardduty-data` VPC-Endpunkt verfügt. GuardDuty stellt den Security Agent auf Ihren EKS-Clustern bereit. Amazon Elastic Kubernetes Service (Amazon EKS) koordiniert die Bereitstellung des Sicherheitsagenten auf den Knoten innerhalb der EKS-Cluster.
+ GuardDuty Wählt auf der Grundlage der IP-Verfügbarkeit das Subnetz aus, um einen VPC-Endpunkt zu erstellen. Wenn Sie erweiterte Netzwerktopologien verwenden, müssen Sie überprüfen, ob die Konnektivität möglich ist.
#### Schließt selektive EKS-Cluster aus
Verwenden Sie diesen Ansatz, wenn Sie GuardDuty den Security Agent für alle EKS-Cluster in Ihrem Konto verwalten, aber ausgewählte EKS-Cluster ausschließen möchten. Bei dieser Methode wird ein Tag-basierter [1](#eks-runtime-inclusion-exclusion-tags) Ansatz verwendet, bei dem Sie die EKS-Cluster taggen können, für die Sie keine Laufzeit-Ereignisse erhalten möchten. Das vordefinierte Tag muss `GuardDutyManaged`-`false` als Schlüssel-Wert-Paar haben.
**Auswirkungen der Verwendung dieses Ansatzes**
Bei diesem Ansatz müssen Sie die automatische GuardDuty Agentenverwaltung erst aktivieren, nachdem Sie den EKS-Clustern, die Sie von der Überwachung ausschließen möchten, Tags hinzugefügt haben.
Daher gilt auch für diesen Ansatz die Auswirkung von [Verwalten Sie den Security Agent über GuardDuty](#eks-runtime-using-gdu-agent-management-auto). Wenn Sie Tags hinzufügen, bevor Sie die automatische GuardDuty Agentenverwaltung aktivieren, GuardDuty wird der Security Agent für die EKS-Cluster, die von der Überwachung ausgeschlossen sind, weder bereitgestellt noch verwaltet.
**Überlegungen**
+ Sie müssen das Tag-Schlüssel-Wert-Paar wie folgt hinzufügen`GuardDutyManaged`: `false` für die ausgewählten EKS-Cluster, bevor Sie die automatische Agentenkonfiguration aktivieren. Andernfalls wird der GuardDuty Security Agent auf allen EKS-Clustern installiert, bis Sie das Tag verwenden.
+ Sie müssen verhindern, dass die Tags geändert werden, es sei denn, es handelt sich um vertrauenswürdige Identitäten.
**Wichtig**
Verwalten Sie die Berechtigungen zum Ändern des Werts des `GuardDutyManaged`-Tags für Ihren EKS-Cluster mithilfe von Service-Kontrollrichtlinie oder IAM-Richtlinien. Weitere Informationen finden Sie unter [Richtlinien zur Dienststeuerung (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) im *AWS Organizations Benutzerhandbuch* oder [Steuern des Zugriffs auf AWS Ressourcen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html) im *IAM-Benutzerhandbuch*.
+ Bei einem potenziell neuen EKS-Cluster, den Sie nicht überwachen möchten, stellen Sie sicher, dass Sie bei der Erstellung dieses EKS-Clusters das Schlüssel-Wert-Paar `GuardDutyManaged`-`false` hinzufügen.
+ Bei diesem Ansatz werden auch dieselben Überlegungen berücksichtigt, wie für [Überwachen Sie alle EKS-Cluster](#gdu-security-agent-all-eks-custers) angegeben.
#### Ausgewählte EKS-Cluster einbeziehen
Verwenden Sie diesen Ansatz, wenn Sie GuardDuty die Updates für den Security Agent nur für ausgewählte EKS-Cluster in Ihrem Konto bereitstellen und verwalten möchten. Bei dieser Methode wird ein Tag-basierter [1](#eks-runtime-inclusion-exclusion-tags)-Ansatz verwendet, bei dem Sie die EKS-Cluster markieren können, für die Sie Laufzeit-Ereignisse erhalten möchten.
**Auswirkungen der Verwendung dieses Ansatzes**
+ Durch die Verwendung von Inklusion-Tags GuardDuty wird der Security Agent automatisch nur für die ausgewählten EKS-Cluster bereitgestellt und verwaltet, die mit `GuardDutyManaged` - `true` als Schlüssel-Wert-Paar gekennzeichnet sind.
+ Dieser Ansatz hat auch die gleichen Auswirkungen, wie für [Überwachen Sie alle EKS-Cluster](#gdu-security-agent-all-eks-custers) angegeben.
**Überlegungen**
+ Wenn der Wert des `GuardDutyManaged`-Tags nicht auf `true` festgelegt ist, funktioniert das Einschließen-Tag nicht wie erwartet, und dies kann sich auf die Überwachung Ihres EKS-Clusters auswirken.
+ Um sicherzustellen, dass Ihre ausgewählten EKS-Cluster überwacht werden, müssen Sie verhindern, dass die Tags geändert werden, es sei denn, es handelt sich um vertrauenswürdige Identitäten.
**Wichtig**
Verwalten Sie die Berechtigungen zum Ändern des Werts des `GuardDutyManaged`-Tags für Ihren EKS-Cluster mithilfe von Service-Kontrollrichtlinie oder IAM-Richtlinien. Weitere Informationen finden Sie unter [Richtlinien zur Dienststeuerung (SCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) im *AWS Organizations Benutzerhandbuch* oder [Steuern des Zugriffs auf AWS Ressourcen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html) im *IAM-Benutzerhandbuch*.
+ Bei einem potenziell neuen EKS-Cluster, den Sie nicht überwachen möchten, stellen Sie sicher, dass Sie bei der Erstellung dieses EKS-Clusters das Schlüssel-Wert-Paar `GuardDutyManaged`-`false` hinzufügen.
+ Bei diesem Ansatz werden auch dieselben Überlegungen berücksichtigt, wie für [Überwachen Sie alle EKS-Cluster](#gdu-security-agent-all-eks-custers) angegeben.
1Weitere Informationen zum Markieren von ausgewählten EKS-Clustern finden Sie unter [Markieren Ihrer Amazon-EKS-Ressourcen](https://docs.aws.amazon.com/eks/latest/userguide/eks-using-tags.html) im **Amazon-EKS-Benutzerhandbuch**.
### Den GuardDuty Security Agent manuell verwalten
Verwenden Sie diesen Ansatz, wenn Sie den GuardDuty Security Agent auf all Ihren EKS-Clustern manuell verteilen und verwalten möchten. Stellen Sie sicher, dass EKS-Laufzeit-Überwachung für Ihre Konten aktiviert ist. Der GuardDuty Security Agent funktioniert möglicherweise nicht wie erwartet, wenn Sie EKS Runtime Monitoring nicht aktivieren.
**Auswirkungen der Verwendung dieses Ansatzes**
Sie müssen die Bereitstellung des GuardDuty Security Agents in Ihren EKS-Clustern für alle Konten und für alle Standorte, AWS-Regionen an denen diese Funktion verfügbar ist, koordinieren. Sie müssen auch die Agent-Version aktualisieren, wenn sie GuardDuty veröffentlicht wird. Weitere Informationen zu Agentenversionen für EKS finden Sie unter[GuardDuty Security-Agent-Versionen für Amazon EKS-Ressourcen](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history).
**Überlegungen**
Sie müssen einen sicheren Datenfluss unterstützen und gleichzeitig Deckungslücken überwachen und schließen, da ständig neue Cluster und Workloads bereitgestellt werden.
# So funktioniert Runtime Monitoring mit Amazon EC2 EC2-Instances
Ihre Amazon EC2 EC2-Instances können mehrere Arten von Anwendungen und Workloads in Ihrer AWS Umgebung ausführen. Wenn Sie Runtime Monitoring aktivieren und den GuardDuty Security Agent verwalten, GuardDuty hilft er Ihnen, Bedrohungen in Ihren bestehenden Amazon EC2 EC2-Instances und potenziell neuen zu erkennen. Diese Funktion unterstützt auch von Amazon ECS verwaltete Amazon EC2 EC2-Instances. Weitere Informationen finden Sie unter [Unterstützung für verwaltete Instances in Guardduty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_managed-instances.html).
**Anmerkung**
Runtime Monitoring unterstützt keine Anwendungen, die auf [Amazon ECS Managed Instances ausgeführt werden](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ManagedInstances.html).
Durch die Aktivierung von Runtime Monitoring können Runtime-Ereignisse von aktuell laufenden und neuen Prozessen innerhalb von Amazon EC2 EC2-Instances verarbeitet werden. GuardDuty GuardDuty erfordert einen Security Agent, an den Runtime-Ereignisse von Ihrer EC2-Instance gesendet werden. GuardDuty
Bei Amazon EC2 EC2-Instances arbeitet der GuardDuty Security Agent auf Instance-Ebene. Sie können entscheiden, ob Sie alle oder nur ausgewählte Amazon EC2 EC2-Instances in Ihrem Konto überwachen möchten. Wenn Sie ausgewählte Instances verwalten möchten, ist der Security Agent nur für diese Instances erforderlich.
GuardDuty kann auch Laufzeitereignisse von neuen Aufgaben und bestehenden Aufgaben verarbeiten, die in Amazon EC2 EC2-Instances innerhalb von Amazon ECS-Clustern ausgeführt werden.
Um den GuardDuty Security Agent zu installieren, bietet Runtime Monitoring die folgenden zwei Optionen:
+ [Verwenden Sie die automatische Agentenkonfiguration (empfohlen)](#use-automated-agent-config-ec2), oder
+ [Den Security Agent manuell verwalten](#ec2-security-agent-option2-manual)
## Verwenden Sie die automatische Agentenkonfiguration über GuardDuty (empfohlen)
Verwenden Sie die automatische Agentenkonfiguration, die es GuardDuty ermöglicht, den Security Agent in Ihrem Namen auf Ihren Amazon EC2 EC2-Instances zu installieren. GuardDuty verwaltet auch die Updates für den Security Agent.
GuardDuty Installiert den Security Agent standardmäßig auf allen Instanzen in Ihrem Konto. Wenn Sie den Security Agent nur für ausgewählte EC2-Instances installieren und verwalten möchten GuardDuty , fügen Sie Ihren EC2-Instances nach Bedarf Inklusions- oder Ausschluss-Tags hinzu.
Manchmal möchten Sie möglicherweise nicht die Laufzeitereignisse für alle Amazon EC2 EC2-Instances überwachen, die zu Ihrem Konto gehören. In Fällen, in denen Sie die Runtime-Ereignisse für eine begrenzte Anzahl von Instances überwachen möchten, fügen Sie diesen ausgewählten Instances ein Inclusion-Tag wie`GuardDutyManaged`: `true` hinzu. Beginnend mit der Verfügbarkeit der automatisierten Agentenkonfiguration für Amazon EC2 gilt: Wenn Ihre EC2-Instance über ein Inclusion-Tag (`GuardDutyManaged`:`true`) verfügt, GuardDuty berücksichtigt das Tag und verwaltet den Security Agent für die ausgewählten Instances, auch wenn Sie die automatische Agentenkonfiguration nicht explizit aktivieren.
Wenn es jedoch eine begrenzte Anzahl von EC2-Instances gibt, für die Sie Laufzeitereignisse nicht überwachen möchten, fügen Sie diesen ausgewählten Instances ein Ausschluss-Tag (`GuardDutyManaged`:`false`) hinzu. GuardDuty berücksichtigt das Ausschluss-Tag, indem der Security Agent für diese EC2-Ressourcen **weder** **installiert noch** verwaltet wird.
### Auswirkung
Wenn Sie die automatische Agentenkonfiguration in einer AWS-Konto oder einer Organisation verwenden, GuardDuty erlauben Sie, die folgenden Schritte in Ihrem Namen durchzuführen:
+ GuardDuty erstellt eine SSM-Zuordnung für all Ihre Amazon EC2 EC2-Instances, die SSM-verwaltet werden und in der Konsole unter **Fleet Manager** angezeigt werden. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
+ Verwendung von Inclusion-Tags bei deaktivierter automatisierter Agentenkonfiguration — Wenn Sie nach der Aktivierung von Runtime Monitoring die automatische Agentenkonfiguration nicht aktivieren, sondern Ihrer Amazon EC2 EC2-Instance ein Inclusion-Tag hinzufügen, bedeutet dies, dass Sie erlauben, den Security Agent in Ihrem Namen GuardDuty zu verwalten. Die SSM-Zuordnung installiert dann den Security Agent in jeder Instance, die über das Inklusion-Tag (:) `GuardDutyManaged` verfügt. `true`
+ Wenn Sie die automatische Agentenkonfiguration aktivieren, installiert die SSM-Zuordnung den Security Agent dann auf allen EC2-Instances, die zu Ihrem Konto gehören.
+ Verwenden von Ausschluss-Tags mit automatisierter Agentenkonfiguration — Bevor Sie die automatische Agentenkonfiguration aktivieren und Ihrer Amazon EC2 EC2-Instance ein Ausschluss-Tag hinzufügen, bedeutet dies, dass Sie die Installation und Verwaltung des Security Agents für diese ausgewählte Instance verhindern. GuardDuty
Wenn Sie nun die automatische Agentenkonfiguration aktivieren, installiert und verwaltet die SSM-Verbindung den Security Agent in allen EC2-Instances mit Ausnahme der Instances, die mit dem Ausschluss-Tag gekennzeichnet sind.
+ GuardDuty erstellt VPC-Endpoints in allen VPCs, einschließlich gemeinsam genutzter VPCs, sofern in dieser VPC mindestens eine Linux EC2-Instance vorhanden ist, die sich nicht im Status Beendet oder Herunterfahren der Instance befindet. Dazu gehören die zentralisierte VPC und Spoke VPCs. GuardDuty unterstützt nicht die Erstellung eines VPC-Endpunkts nur für die zentralisierte VPC. Weitere Informationen zur Funktionsweise der zentralisierten VPC finden Sie unter [Interface VPC Endpoints](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html#interface-vpc-endpoints) im *AWS Whitepaper — Aufbau einer skalierbaren und sicheren* Multi-VPC-Netzwerkinfrastruktur. AWS
Informationen zu den verschiedenen Instance-Status finden Sie unter [Instance-Lebenszyklus](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-lifecycle.html) im *Amazon EC2 EC2-Benutzerhandbuch*.
GuardDuty unterstützt [Gemeinsam genutzte VPC mit Runtime Monitoring verwenden](runtime-monitoring-shared-vpc.md) auch. Wenn alle Voraussetzungen für Ihre Organisation erfüllt sind AWS-Konto, GuardDuty wird die gemeinsam genutzte VPC zum Empfangen von Laufzeitereignissen verwendet.
**Anmerkung**
Für die Nutzung des VPC-Endpunkts fallen keine zusätzlichen Kosten an.
+ Erstellt zusammen mit dem VPC-Endpunkt GuardDuty auch eine neue Sicherheitsgruppe. Die Regeln für eingehenden Datenverkehr (Eingangsregeln) steuern den Datenverkehr, der die Ressourcen erreichen darf, die der Sicherheitsgruppe zugeordnet sind. GuardDuty fügt eingehende Regeln hinzu, die dem VPC-CIDR-Bereich für Ihre Ressource entsprechen, und passt sich diesem auch an, wenn sich der CIDR-Bereich ändert. Weitere Informationen finden Sie unter [VPC CIDR-Bereich](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html) im *Amazon VPC-Benutzerhandbuch*.
## Den Security Agent manuell verwalten
Es gibt zwei Möglichkeiten, den Security Agent für Amazon EC2 manuell zu verwalten:
+ Verwenden Sie GuardDuty verwaltete Dokumente AWS Systems Manager , um den Security Agent auf Ihren Amazon EC2 EC2-Instances zu installieren, die bereits über SSM verwaltet werden.
Wenn Sie eine neue Amazon EC2 EC2-Instance starten, stellen Sie sicher, dass sie SSM-aktiviert ist.
+ Verwenden Sie RPM Package Manager (RPM) -Skripts, um den Security Agent auf Ihren Amazon EC2 EC2-Instances zu installieren, unabhängig davon, ob sie SSM-verwaltet werden oder nicht.
## Nächster Schritt
Erste Schritte mit der Runtime Monitoring-Konfiguration zur Überwachung Ihrer Amazon EC2 EC2-Instances finden Sie unter[Voraussetzungen für die Unterstützung von Amazon EC2 EC2-Instances](prereq-runtime-monitoring-ec2-support.md).
# So funktioniert Runtime Monitoring mit Fargate (nur Amazon ECS)
Wenn Sie Runtime Monitoring aktivieren, ist GuardDuty es bereit, die Laufzeitereignisse einer Aufgabe zu verarbeiten. Diese Aufgaben werden innerhalb der Amazon ECS-Cluster ausgeführt, die wiederum auf den AWS Fargate Instances ausgeführt werden. GuardDuty Um diese Runtime-Ereignisse empfangen zu können, müssen Sie den vollständig verwalteten, dedizierten Security Agent verwenden.
**Anmerkung**
Runtime Monitoring unterstützt keine Anwendungen, die auf [Amazon ECS Managed Instances ausgeführt werden](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ManagedInstances.html).
Sie können zulassen GuardDuty , dass der GuardDuty Security Agent in Ihrem Namen verwaltet wird, indem Sie die automatische Agentenkonfiguration für ein AWS Konto oder eine Organisation verwenden. GuardDuty beginnt mit der Bereitstellung des Security Agents für die neuen Fargate-Aufgaben, die in Ihren Amazon ECS-Clustern gestartet werden. In der folgenden Liste wird angegeben, was zu erwarten ist, wenn Sie den GuardDuty Security Agent aktivieren.**Auswirkungen der Aktivierung des GuardDuty Security Agents**
**GuardDuty erstellt einen Virtual Private Cloud (VPC) -Endpunkt und eine Sicherheitsgruppe**
+ Wenn Sie den GuardDuty Security Agent bereitstellen, GuardDuty erstellt er einen VPC-Endpunkt, über den der Security Agent die Runtime-Ereignisse übermittelt GuardDuty.
Erstellt zusammen mit dem VPC-Endpunkt GuardDuty auch eine neue Sicherheitsgruppe. Die Regeln für eingehenden Datenverkehr (Eingangsregeln) steuern den Datenverkehr, der die Ressourcen erreichen darf, die der Sicherheitsgruppe zugeordnet sind. GuardDuty fügt eingehende Regeln hinzu, die dem VPC-CIDR-Bereich für Ihre Ressource entsprechen, und passt sich diesem auch an, wenn sich der CIDR-Bereich ändert. Weitere Informationen finden Sie unter [VPC CIDR-Bereich](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-cidr-blocks.html) im *Amazon VPC-Benutzerhandbuch*.
+ Arbeiten mit zentralisierter VPC mit automatisiertem Agenten — Wenn Sie die GuardDuty automatisierte Agentenkonfiguration für einen Ressourcentyp verwenden, GuardDuty wird in Ihrem Namen ein VPC-Endpunkt für alle erstellt. VPCs Dazu gehören die zentralisierte VPC und Spoke VPCs. GuardDutyunterstützt nicht die Erstellung eines VPC-Endpunkts nur für die zentralisierte VPC. Weitere Informationen zur Funktionsweise der zentralisierten VPC finden Sie unter [Interface VPC Endpoints](https://docs.aws.amazon.com/whitepapers/latest/building-scalable-secure-multi-vpc-network-infrastructure/centralized-access-to-vpc-private-endpoints.html#interface-vpc-endpoints) im *AWS Whitepaper — Aufbau einer skalierbaren und sicheren* Multi-VPC-Netzwerkinfrastruktur. AWS
+ Für die Nutzung des VPC-Endpunkts fallen keine zusätzlichen Kosten an.
**GuardDuty fügt einen Sidecar-Container hinzu**
Bei einer neuen Fargate-Aufgabe oder einem neuen Fargate-Dienst, der gestartet wird, hängt sich ein GuardDuty Container (Sidecar) an jeden Container innerhalb der Amazon ECS Fargate-Aufgabe an. Der GuardDuty Security Agent wird innerhalb des angehängten Containers ausgeführt. GuardDuty Auf diese Weise GuardDuty können die Laufzeitereignisse jedes Containers erfasst werden, der im Rahmen dieser Tasks ausgeführt wird.
Das GuardDuty Sidecar-Container-Image wird in Amazon Elastic Container Registry (Amazon ECR) gespeichert, und die Bildebenen werden in Amazon S3 gespeichert. Wenn Ihre Aufgabe gestartet wird, muss sie dieses Image aus ECR abrufen. Abhängig von Ihrer Netzwerkkonfiguration sind hierfür möglicherweise bestimmte Einstellungen erforderlich, um den Zugriff auf ECR und S3 sicherzustellen. Wenn Sie beispielsweise Sicherheitsgruppen mit eingeschränktem Zugriff verwenden, müssen Sie den Zugriff auf die Liste der verwalteten S3-Präfixe zulassen. Weitere Information dazu finden Sie unter [Voraussetzungen für den Zugriff auf Container-Images](prereq-runtime-monitoring-ecs-support.md#before-enable-runtime-monitoring-ecs).
Wenn Sie eine Fargate-Aufgabe starten und der GuardDuty Container (Sidecar) nicht in einem fehlerfreien Zustand gestartet werden kann, ist Runtime Monitoring so konzipiert, dass die Ausführung der Aufgaben nicht verhindert wird.
Standardmäßig ist eine Fargate-Aufgabe unveränderlich. GuardDuty stellt den Sidecar nicht bereit, wenn sich eine Aufgabe bereits im laufenden Zustand befindet. Wenn Sie einen Container in einer bereits laufenden Aufgabe überwachen möchten, können Sie die Aufgabe beenden und erneut starten.
## Ansätze zur Verwaltung von GuardDuty Sicherheitsagenten in Amazon ECS-Fargate-Ressourcen
Runtime Monitoring bietet Ihnen die Möglichkeit, potenzielle Sicherheitsbedrohungen entweder auf allen Amazon ECS-Clustern (Kontoebene) oder auf ausgewählten Clustern (Cluster-Ebene) in Ihrem Konto zu erkennen. Wenn Sie die automatische Agentenkonfiguration für jede auszuführende Amazon ECS Fargate-Aufgabe aktivieren, GuardDuty wird für jeden Container-Workload innerhalb dieser Aufgabe ein Sidecar-Container hinzugefügt. Der GuardDuty Security Agent wird in diesem Sidecar-Container bereitgestellt. Auf diese Weise GuardDuty erhalten Sie Einblick in das Laufzeitverhalten der Container in den Amazon ECS-Aufgaben.
Runtime Monitoring unterstützt die Verwaltung des Security Agents für Ihre Amazon ECS-Cluster (AWS Fargate) nur über GuardDuty. Die manuelle Verwaltung des Security Agents auf Amazon ECS-Clustern wird nicht unterstützt.
Bevor Sie Ihre Konten konfigurieren, sollten Sie prüfen, ob Sie das Laufzeitverhalten aller Container überwachen möchten, die zu den Amazon ECS-Aufgaben gehören, oder ob Sie bestimmte Ressourcen ein- oder ausschließen möchten. Ziehen Sie die folgenden Ansätze in Betracht.
**Monitor für alle Amazon ECS-Cluster**
Dieser Ansatz hilft Ihnen dabei, potenzielle Sicherheitsbedrohungen auf Kontoebene zu erkennen. Verwenden Sie diesen Ansatz, wenn Sie potenzielle Sicherheitsbedrohungen für alle Amazon ECS-Cluster erkennen möchten GuardDuty , die zu Ihrem Konto gehören.
**Bestimmte Amazon ECS-Cluster ausschließen**
Verwenden Sie diesen Ansatz, wenn GuardDuty Sie potenzielle Sicherheitsbedrohungen für die meisten Amazon ECS-Cluster in Ihrer AWS Umgebung erkennen, einige Cluster jedoch ausschließen möchten. Dieser Ansatz hilft Ihnen, das Laufzeitverhalten der Container innerhalb Ihrer Amazon ECS-Aufgaben auf Cluster-Ebene zu überwachen. Die Anzahl der Amazon ECS-Cluster, die zu Ihrem Konto gehören, beträgt beispielsweise 1000. Sie möchten jedoch nur 930 Amazon ECS-Cluster überwachen.
Bei diesem Ansatz müssen Sie den Amazon ECS-Clustern, die Sie nicht überwachen möchten, ein vordefiniertes GuardDuty Tag hinzufügen. Weitere Informationen finden Sie unter [Verwaltung eines automatisierten Sicherheitsagenten für Fargate (nur Amazon ECS)](managing-gdu-agent-ecs-automated.md).
**Spezifische Amazon ECS-Cluster einbeziehen**
Verwenden Sie diesen Ansatz, wenn GuardDuty Sie potenzielle Sicherheitsbedrohungen für einige der Amazon ECS-Cluster erkennen möchten. Dieser Ansatz hilft Ihnen, das Laufzeitverhalten der Container innerhalb Ihrer Amazon ECS-Aufgaben auf Cluster-Ebene zu überwachen. Die Anzahl der Amazon ECS-Cluster, die zu Ihrem Konto gehören, beträgt beispielsweise 1000. Sie möchten jedoch nur 230 Cluster überwachen.
Bei diesem Ansatz müssen Sie den Amazon ECS-Clustern, die Sie überwachen möchten, ein vordefiniertes GuardDuty Tag hinzufügen. Weitere Informationen finden Sie unter [Verwaltung eines automatisierten Sicherheitsagenten für Fargate (nur Amazon ECS)](managing-gdu-agent-ecs-automated.md).
# Nachdem Sie Runtime Monitoring aktiviert haben
Nachdem Sie Runtime Monitoring aktiviert und den GuardDuty Security Agent in Ihrem eigenständigen Konto oder mehreren Mitgliedskonten installiert haben, können Sie mit den folgenden Schritten sicherstellen, dass die Schutzplan-Einstellung wie erwartet funktioniert, und überwachen, wie viel Speicher und CPU der GuardDuty Security Agent verwendet.
**Beurteilen Sie die Runtime-Abdeckung**
GuardDuty empfiehlt Ihnen, den Schutzstatus der Ressource, auf der Sie den Security Agent installiert haben, kontinuierlich zu überprüfen. Der Schutzstatus kann entweder fehlerfrei oder ****fehlerfrei**** sein. Der **Deckungsstatus** Fehlerfrei gibt an, dass GuardDuty die Laufzeitereignisse von der entsprechenden Ressource empfangen werden, wenn eine Aktivität auf Betriebssystemebene stattfindet.
**Wenn der Abdeckungsstatus für die Ressource auf Fehlerfrei gesetzt GuardDuty wird, kann sie die Laufzeitereignisse empfangen und sie zur Bedrohungserkennung analysieren.** Wenn eine potenzielle Sicherheitsbedrohung in den Aufgaben oder Anwendungen GuardDuty entdeckt wird, die in Ihren Container-Workloads und -Instances ausgeführt werden, GuardDuty generiert[GuardDuty Runtime Monitoring: Typen finden](findings-runtime-monitoring.md).
Sie können Amazon EventBridge (EventBridge) auch so konfigurieren, dass Sie eine Benachrichtigung erhalten, wenn sich der Versicherungsstatus von **Ungesund auf Gesund** **usw.** ändert. Weitere Informationen finden Sie unter [Überprüfung der Statistiken zur Laufzeitabdeckung und Behebung von Problemen](runtime-monitoring-assessing-coverage.md).
**Richten Sie die CPU- und Speicherüberwachung für den GuardDuty Security Agent ein**
Nachdem Sie festgestellt haben, dass der Schutzstatus als Fehlerfrei **angezeigt** wird, können Sie die Leistung des Security Agents für Ihren Ressourcentyp bewerten. GuardDuty Unterstützt für Amazon EKS-Cluster mit dem Security Agent Version v1.5 oder höher die Konfiguration der Parameter des (Add-on-) Security Agents. Weitere Informationen finden Sie unter [Einrichten der CPU- und Arbeitsspeicherüberwachung](runtime-monitoring-setting-cpu-mem-monitoring.md).
**GuardDuty erkennt potenzielle Bedrohungen**
Sobald GuardDuty die Laufzeitereignisse für Ihre Ressource empfangen werden, beginnt es mit der Analyse dieser Ereignisse. Wenn eine potenzielle Sicherheitsbedrohung in einer Ihrer Amazon EC2 EC2-Instances, Amazon ECS-Cluster oder Amazon EKS-Cluster GuardDuty erkannt wird, generiert es eine oder mehrere[GuardDuty Runtime Monitoring: Typen finden](findings-runtime-monitoring.md). Sie können auf die Ergebnisdetails zugreifen, um die betroffenen Ressourcen einzusehen.
# Wie funktioniert die kostenlose 30-Tage-Testversion in Runtime Monitoring
Die 30-tägige kostenlose Testphase funktioniert unterschiedlich für neue GuardDuty Konten und für bestehende Konten, für die EKS Runtime Monitoring bereits aktiviert wurde, bevor die Runtime Monitoring-Funktion auf Amazon EC2 EC2-Instances ausgedehnt wurde und AWS Fargate (nur Amazon ECS).
## Ich verwende die GuardDuty Testphase oder habe EKS Runtime Monitoring noch nie aktiviert
In der folgenden Liste wird erklärt, wie die kostenlose 30-Tage-Testphase funktioniert, wenn Sie entweder die GuardDuty 30-Tage-Testphase verwenden oder EKS Runtime Monitoring noch nie aktiviert haben:
+ Wenn Sie Runtime Monitoring und EKS Runtime Monitoring GuardDuty zum ersten Mal aktivieren, werden Runtime Monitoring und EKS Runtime Monitoring standardmäßig nicht aktiviert.
Wenn Sie Runtime Monitoring für Ihr Konto oder Ihre Organisation aktivieren, stellen Sie sicher, dass Sie auch den GuardDuty Security Agent für die Ressource konfigurieren, die Sie auf Bedrohungserkennung überwachen möchten. Wenn Sie beispielsweise Runtime Monitoring für Ihre Amazon EC2-Instances verwenden möchten, müssen Sie nach der Aktivierung von Runtime Monitoring auch den Security Agent für Amazon EC2 konfigurieren. Sie können wählen, ob Sie dies manuell oder automatisch über tun möchten. GuardDuty
+ Der Runtime Monitoring-Schutzplan ist auf **Kontoebene** aktiviert. Die kostenlose 30-Tage-Testphase gilt auf **Ressourcenebene**. Nachdem der GuardDuty Security Agent für einen bestimmten Ressourcentyp bereitgestellt wurde, beginnt die kostenlose 30-Tage-Testversion, sobald GuardDuty das **erste Runtime-Ereignis** im Zusammenhang mit diesem Ressourcentyp eintrifft. Sie haben den GuardDuty Agenten beispielsweise auf Ressourcenebene bereitgestellt (für Amazon EC2 EC2-Instance, Amazon ECS-Cluster und Amazon EKS-Cluster). Wenn das GuardDuty erste Runtime-Event für eine Amazon EC2-Instance eingeht, startet die kostenlose 30-Tage-Testversion nur für Amazon EC2.
+ Wenn Sie nur EKS Runtime Monitoring aktivieren möchten — Wenn Sie EKS Runtime Monitoring GuardDuty zum ersten Mal aktivieren, ist EKS Runtime Monitoring standardmäßig nicht aktiviert (nach der Veröffentlichung von Runtime Monitoring). Sie müssen EKS Runtime Monitoring aktivieren. Um ihn optimal zu nutzen, stellen Sie sicher, dass Sie den GuardDuty Security Agent entweder manuell verwalten oder die automatische Agentenkonfiguration aktivieren, sodass der Agent in Ihrem Namen GuardDuty verwaltet wird. Ihre 30-tägige kostenlose Testphase für EKS Runtime Monitoring beginnt, wenn GuardDuty das erste Runtime-Ereignis für die Amazon EKS-Ressource eingeht.
# Ich habe EKS Runtime Monitoring vor dem Start von Runtime Monitoring aktiviert
Verwenden Sie diesen Abschnitt nur, wenn EKS Runtime Monitoring für Sie AWS-Konto aktiviert war und Sie jetzt zu Runtime Monitoring migrieren möchten.
Die folgende Liste enthält Szenarien, die auf Ihren Anwendungsfall der Aktivierung von Runtime Monitoring zutreffen könnten:
+ Für ein vorhandenes GuardDuty Konto, für das der EKS Runtime Monitoring-Schutzplan aktiviert ist und das die GuardDuty Konsolenerfahrung verwendet, um diesen Schutzplan zu verwenden — Mit der Ankündigung von Runtime Monitoring wurde das Erlebnis der EKS Runtime Monitoring-Konsole nun in Runtime Monitoring konsolidiert. Ihre bestehende Konfiguration für EKS Runtime Monitoring bleibt unverändert. Sie können die API/CLI-Unterstützung weiterhin verwenden, um Operationen im Zusammenhang mit EKS Runtime Monitoring auszuführen.
+ Um EKS Runtime Monitoring als Teil von Runtime Monitoring verwenden zu können, müssen Sie Runtime Monitoring für Ihr Konto oder Ihre Organisation konfigurieren. Informationen zur Beibehaltung derselben Konfiguration für Runtime Monitoring finden Sie unter[Migration von EKS Runtime Monitoring zu Runtime Monitoring](migrating-from-eksrunmon-to-runtime-monitoring.md). Dies hat jedoch keine Auswirkungen auf Ihre kostenlose 30-Tage-Testversion für die Amazon EKS-Ressource.
+ Der Runtime Monitoring-Schutzplan ist auf Kontoebene pro Region aktiviert. Nachdem der GuardDuty Security Agent auf einem der angegebenen Ressourcentypen (Amazon EC2-Instance und Amazon ECS-Cluster) bereitgestellt wurde, beginnt die kostenlose 30-Tage-Testversion, sobald das erste Runtime-Ereignis im Zusammenhang mit der Ressource GuardDuty empfangen wird. Für jeden Ressourcentyp ist eine kostenlose 30-Tage-Testversion verfügbar.
Nachdem Sie Runtime Monitoring aktiviert haben, entscheiden Sie sich beispielsweise dafür, den GuardDuty Agenten nur auf einer Amazon EC2 EC2-Instance bereitzustellen. Die kostenlose 30-Tage-Testversion für diese Ressource beginnt erst, wenn das erste Runtime-Ereignis für eine Amazon EC2 EC2-Instance GuardDuty empfangen wird. Später, wenn Sie den GuardDuty Agenten für Fargate bereitstellen (nur Amazon ECS), beginnt die kostenlose 30-Tage-Testversion für diese Ressource erst, wenn das erste Runtime-Ereignis für den Amazon ECS-Cluster GuardDuty empfangen wird. Da Sie EKS Runtime Monitoring bereits für Ihr Konto aktiviert haben, wird die kostenlose 30-Tage-Testversion für eine Amazon EKS-Ressource GuardDuty nicht zurückgesetzt.
# 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).
# GuardDuty Laufzeitüberwachung aktivieren
Bevor Sie Runtime Monitoring in Ihrem Konto aktivieren, stellen Sie sicher, dass der Ressourcentyp, für den Sie die Laufzeitereignisse überwachen möchten, die Plattformanforderungen unterstützt. Weitere Informationen finden Sie unter [Voraussetzungen](runtime-monitoring-prerequisites.md).
Wenn Sie EKS Runtime Monitoring vor dem Start von Runtime Monitoring verwendet haben, können Sie mit dem APIs die bestehende Konfiguration für EKS Runtime Monitoring überprüfen und aktualisieren. Sie können Ihre bestehende Konfiguration auch von EKS Runtime Monitoring zu Runtime Monitoring migrieren. Weitere Informationen finden Sie unter [Migration von EKS Runtime Monitoring zu Runtime Monitoring](migrating-from-eksrunmon-to-runtime-monitoring.md).
**Anmerkung**
Derzeit enthält diese Dokumentation Schritte zur Aktivierung von Runtime Monitoring für Ihre Konten und Ihr Unternehmen nur über die Konsole. Sie können Runtime Monitoring auch mithilfe von [API-Aktionen](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_Operations.html) oder [AWS CLI für GuardDuty](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/guardduty/index.html#cli-aws-guardduty) aktivieren.
Sie können Runtime Monitoring mithilfe der Schritte in den folgenden Themen konfigurieren.
**Topics**
+ [Runtime Monitoring für Umgebungen mit mehreren Konten aktivieren](enable-runtime-monitoring-multiple-acc-env.md)
+ [Runtime Monitoring für ein eigenständiges Konto aktivieren](enable-runtime-monitoring-standalone-acc.md)
# Runtime Monitoring für Umgebungen mit mehreren Konten aktivieren
In Umgebungen mit mehreren Konten kann nur das delegierte GuardDuty Administratorkonto Runtime Monitoring für die Mitgliedskonten aktivieren oder deaktivieren und die automatische Agentenkonfiguration für die Ressourcentypen verwalten, die zu den Mitgliedskonten in ihrer Organisation gehören. Die GuardDuty Mitgliedskonten können diese Konfiguration nicht von ihren Konten aus ändern. Das delegierte GuardDuty Administratorkonto verwaltet seine Mitgliedskonten mithilfe von AWS Organizations. Weitere Informationen zu Umgebungen mit mehreren Konten finden Sie unter [Verwaltung mehrerer Konten](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html).
## Für ein delegiertes Administratorkonto GuardDuty
**Um Runtime Monitoring für ein delegiertes GuardDuty Administratorkonto zu aktivieren**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die GuardDuty Konsole unter [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. Wählen Sie im Navigationsbereich **Runtime Monitoring** aus.
1. Wählen Sie auf der Registerkarte **Konfiguration** im Abschnitt **Runtime Monitoring-Konfiguration** die Option **Bearbeiten** aus.
1.
**Verwendung von Für alle Konten aktivieren**
Wenn Sie Runtime Monitoring für alle Konten aktivieren möchten, die zur Organisation gehören, einschließlich des delegierten GuardDuty Administratorkontos, wählen Sie **Für alle Konten aktivieren** aus.
1.
**Verwendung von Konten manuell konfigurieren**
Wenn Sie Runtime Monitoring für jedes Mitgliedskonto einzeln aktivieren möchten, wählen Sie **Konten manuell konfigurieren**.
1. Wählen Sie im Abschnitt **Delegierter Administrator (dieses Konto)** die Option **Aktivieren**.
1. GuardDuty Um Runtime-Ereignisse von einem oder mehreren Ressourcentypen — einer Amazon EC2 EC2-Instance, einem Amazon ECS-Cluster oder einem Amazon EKS-Cluster — zu empfangen, verwenden Sie die folgenden Optionen, um den Security Agent für diese Ressourcen zu verwalten:
**Um den GuardDuty Security Agent zu aktivieren**
+ [Automatisierten Security Agent für Amazon EC2 EC2-Instance aktivieren](managing-gdu-agent-ec2-automated.md)
+ [Manuelles Verwalten des Security Agents für Amazon EC2 EC2-Ressourcen](managing-gdu-agent-ec2-manually.md)
+ [Verwaltung eines automatisierten Sicherheitsagenten für Fargate (nur Amazon ECS)](managing-gdu-agent-ecs-automated.md)
+ [Automatisches Verwalten des Security Agents für Amazon EKS-Ressourcen](managing-gdu-agent-eks-automatically.md)
+ [Manuelles Verwalten des Security Agents für den Amazon EKS-Cluster](managing-gdu-agent-eks-manually.md)
## Für alle Mitgliedskonten
**Um Runtime Monitoring für alle Mitgliedskonten in der Organisation zu aktivieren**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die GuardDuty Konsole unter [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
Melden Sie sich mit dem delegierten GuardDuty Administratorkonto an.
1. Wählen Sie im Navigationsbereich **Runtime Monitoring** aus.
1. Wählen Sie auf der Seite Runtime Monitoring auf der Registerkarte **Konfiguration** im Abschnitt **Runtime Monitoring-Konfiguration** die Option **Bearbeiten** aus.
1. Wählen Sie **Für alle Konten aktivieren**.
1. GuardDuty Um Runtime-Ereignisse von einem oder mehreren Ressourcentypen — einer Amazon EC2 EC2-Instance, einem Amazon ECS-Cluster oder einem Amazon EKS-Cluster — zu empfangen, verwenden Sie die folgenden Optionen, um den Security Agent für diese Ressourcen zu verwalten:
**Um den GuardDuty Security Agent zu aktivieren**
+ [Automatisierten Security Agent für Amazon EC2 EC2-Instance aktivieren](managing-gdu-agent-ec2-automated.md)
+ [Manuelles Verwalten des Security Agents für Amazon EC2 EC2-Ressourcen](managing-gdu-agent-ec2-manually.md)
+ [Verwaltung eines automatisierten Sicherheitsagenten für Fargate (nur Amazon ECS)](managing-gdu-agent-ecs-automated.md)
+ [Automatisches Verwalten des Security Agents für Amazon EKS-Ressourcen](managing-gdu-agent-eks-automatically.md)
+ [Manuelles Verwalten des Security Agents für den Amazon EKS-Cluster](managing-gdu-agent-eks-manually.md)
## Für alle bestehenden aktiven Mitgliedskonten
**Um Runtime Monitoring für bestehende Mitgliedskonten in der Organisation zu aktivieren**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die GuardDuty Konsole unter [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
Melden Sie sich mit dem delegierten GuardDuty Administratorkonto für die Organisation an.
1. Wählen Sie im Navigationsbereich **Runtime Monitoring** aus.
1. Auf der **Runtime Monitoring-Seite** können Sie auf der Registerkarte **Konfiguration** den aktuellen Status der Runtime Monitoring-Konfiguration einsehen.
1. Wählen Sie im Bereich Runtime Monitoring im Abschnitt **Aktive Mitgliedskonten** die Option **Aktionen** aus.
1. Wählen Sie im Dropdownmenü **Aktionen** die Option **Aktivieren für alle vorhandenen aktiven Mitgliedskonten**.
1. Wählen Sie **Bestätigen** aus.
1. GuardDuty Um Runtime-Ereignisse von einem oder mehreren Ressourcentypen — einer Amazon EC2 EC2-Instance, einem Amazon ECS-Cluster oder einem Amazon EKS-Cluster — zu empfangen, verwenden Sie die folgenden Optionen, um den Security Agent für diese Ressourcen zu verwalten:
**Um den GuardDuty Security Agent zu aktivieren**
+ [Automatisierten Security Agent für Amazon EC2 EC2-Instance aktivieren](managing-gdu-agent-ec2-automated.md)
+ [Manuelles Verwalten des Security Agents für Amazon EC2 EC2-Ressourcen](managing-gdu-agent-ec2-manually.md)
+ [Verwaltung eines automatisierten Sicherheitsagenten für Fargate (nur Amazon ECS)](managing-gdu-agent-ecs-automated.md)
+ [Automatisches Verwalten des Security Agents für Amazon EKS-Ressourcen](managing-gdu-agent-eks-automatically.md)
+ [Manuelles Verwalten des Security Agents für den Amazon EKS-Cluster](managing-gdu-agent-eks-manually.md)
**Anmerkung**
Die Aktualisierung der Konfiguration der Mitgliedskonten kann bis zu 24 Stunden dauern.
## Automatische Aktivierung der Laufzeitüberwachung nur für neue Mitgliedskonten
**Um Runtime Monitoring für neue Mitgliedskonten in Ihrer Organisation zu aktivieren**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die GuardDuty Konsole unter [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
Melden Sie sich mit dem designierten delegierten GuardDuty Administratorkonto der Organisation an.
1. Wählen Sie im Navigationsbereich **Runtime** Monitoring aus
1. Wählen Sie auf der Registerkarte **Konfiguration** im Abschnitt **Runtime Monitoring-Konfiguration** die Option **Bearbeiten** aus.
1. Wählen Sie **Konten manuell konfigurieren**.
1. Wählen Sie **Automatisch für neue Mitgliedskonten aktivieren**.
1. GuardDuty Um Runtime-Ereignisse von einem oder mehreren Ressourcentypen — einer Amazon EC2 EC2-Instance, einem Amazon ECS-Cluster oder einem Amazon EKS-Cluster — zu empfangen, verwenden Sie die folgenden Optionen, um den Security Agent für diese Ressourcen zu verwalten:
**Um den GuardDuty Security Agent zu aktivieren**
+ [Automatisierten Security Agent für Amazon EC2 EC2-Instance aktivieren](managing-gdu-agent-ec2-automated.md)
+ [Manuelles Verwalten des Security Agents für Amazon EC2 EC2-Ressourcen](managing-gdu-agent-ec2-manually.md)
+ [Verwaltung eines automatisierten Sicherheitsagenten für Fargate (nur Amazon ECS)](managing-gdu-agent-ecs-automated.md)
+ [Automatisches Verwalten des Security Agents für Amazon EKS-Ressourcen](managing-gdu-agent-eks-automatically.md)
+ [Manuelles Verwalten des Security Agents für den Amazon EKS-Cluster](managing-gdu-agent-eks-manually.md)
## Nur für ausgewählte aktive Mitgliedskonten
**Um die Laufzeitüberwachung für einzelne aktive Mitgliedskonten zu aktivieren**
1. Öffnen Sie die GuardDuty Konsole unter [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
Melden Sie sich mit den Anmeldeinformationen für das delegierte GuardDuty Administratorkonto an.
1. Wählen Sie im Navigationsbereich **Accounts (Konten)** aus.
1. Überprüfen Sie auf der Seite **Konten** die Werte in den Spalten **Runtime Monitoring** und **Agent automatisch verwalten**. Diese Werte geben an, ob Runtime Monitoring und GuardDuty Agentenverwaltung für das entsprechende Konto **aktiviert** **oder nicht aktiviert** sind.
1. Wählen Sie in der Tabelle Konten das Konto aus, für das Sie Runtime Monitoring aktivieren möchten. Sie können mehrere Konten gleichzeitig auswählen.
1. Wählen Sie **Bestätigen** aus.
1. Wählen Sie **Schutzpläne bearbeiten** aus. Wählen Sie die geeignete Aktion aus.
1. Wählen Sie **Bestätigen** aus.
1. GuardDuty Um Runtime-Ereignisse von einem oder mehreren Ressourcentypen — einer Amazon EC2 EC2-Instance, einem Amazon ECS-Cluster oder einem Amazon EKS-Cluster — zu empfangen, verwenden Sie die folgenden Optionen, um den Security Agent für diese Ressourcen zu verwalten:
**Um den GuardDuty Security Agent zu aktivieren**
+ [Automatisierten Security Agent für Amazon EC2 EC2-Instance aktivieren](managing-gdu-agent-ec2-automated.md)
+ [Manuelles Verwalten des Security Agents für Amazon EC2 EC2-Ressourcen](managing-gdu-agent-ec2-manually.md)
+ [Verwaltung eines automatisierten Sicherheitsagenten für Fargate (nur Amazon ECS)](managing-gdu-agent-ecs-automated.md)
+ [Automatisches Verwalten des Security Agents für Amazon EKS-Ressourcen](managing-gdu-agent-eks-automatically.md)
+ [Manuelles Verwalten des Security Agents für den Amazon EKS-Cluster](managing-gdu-agent-eks-manually.md)
# Runtime Monitoring für ein eigenständiges Konto aktivieren
Ein eigenständiges Konto hat die Entscheidung, einen Schutzplan AWS-Konto in einem bestimmten Bereich zu aktivieren oder zu deaktivieren AWS-Region.
Wenn Ihr Konto über oder über AWS Organizations die Einladungsmethode mit einem GuardDuty Administratorkonto verknüpft ist, gilt dieser Abschnitt nicht für Ihr Konto. Weitere Informationen finden Sie unter [Runtime Monitoring für Umgebungen mit mehreren Konten aktivieren](enable-runtime-monitoring-multiple-acc-env.md).
Nachdem Sie Runtime Monitoring aktiviert haben, stellen Sie sicher, dass Sie den GuardDuty Security Agent durch automatische Konfiguration oder manuelle Installation installieren. Nachdem Sie alle im folgenden Verfahren aufgeführten Schritte ausgeführt haben, stellen Sie sicher, dass Sie den Security Agent installieren.
**Um Runtime Monitoring in einem eigenständigen Konto zu aktivieren**
1. Melden Sie sich bei an AWS-Managementkonsole und öffnen Sie die GuardDuty Konsole unter [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. Wählen Sie im Navigationsbereich **Runtime Monitoring** aus.
1. Wählen Sie auf der Registerkarte **Konfiguration** die Option **Aktivieren** aus, um Runtime Monitoring für Ihr Konto zu aktivieren.
1. GuardDuty Um Runtime-Ereignisse von einem oder mehreren Ressourcentypen — einer Amazon EC2 EC2-Instance, einem Amazon ECS-Cluster oder einem Amazon EKS-Cluster — zu empfangen, verwenden Sie die folgenden Optionen, um den Security Agent für diese Ressourcen zu verwalten:
**Um den GuardDuty Security Agent zu aktivieren**
+ [Automatisierten Security Agent für Amazon EC2 EC2-Instance aktivieren](managing-gdu-agent-ec2-automated.md)
+ [Manuelles Verwalten des Security Agents für Amazon EC2 EC2-Ressourcen](managing-gdu-agent-ec2-manually.md)
+ [Verwaltung eines automatisierten Sicherheitsagenten für Fargate (nur Amazon ECS)](managing-gdu-agent-ecs-automated.md)
+ [Automatisches Verwalten des Security Agents für Amazon EKS-Ressourcen](managing-gdu-agent-eks-automatically.md)
+ [Manuelles Verwalten des Security Agents für den Amazon EKS-Cluster](managing-gdu-agent-eks-manually.md)
# Verwaltung von GuardDuty Security Agents
Sie können den GuardDuty Security Agent für die Ressource verwalten, die Sie überwachen möchten. Wenn Sie mehr als einen Ressourcentyp überwachen möchten, stellen Sie sicher, dass Sie den GuardDuty Agenten für diese Ressource verwalten.
Die folgenden Themen helfen Ihnen bei den nächsten Schritten zur Verwaltung des Security Agents.
**Topics**
+ [Automatisierten Security Agent für Amazon EC2 EC2-Instance aktivieren](managing-gdu-agent-ec2-automated.md)
+ [Manuelles Verwalten des Security Agents für Amazon EC2 EC2-Ressourcen](managing-gdu-agent-ec2-manually.md)
+ [Verwaltung eines automatisierten Sicherheitsagenten für Fargate (nur Amazon ECS)](managing-gdu-agent-ecs-automated.md)
+ [Automatisches Verwalten des Security Agents für Amazon EKS-Ressourcen](managing-gdu-agent-eks-automatically.md)
+ [Manuelles Verwalten des Security Agents für den Amazon EKS-Cluster](managing-gdu-agent-eks-manually.md)
+ [Konfigurieren Sie die Parameter des GuardDuty Security Agents (Add-on) für Amazon EKS](guardduty-configure-security-agent-eks-addon.md)
+ [Validierung der VPC-Endpunktkonfiguration](validate-vpc-endpoint-config-runtime-monitoring.md)
# Automatisierten Security Agent für Amazon EC2 EC2-Instance aktivieren
Dieser Abschnitt enthält Schritte zur Aktivierung des GuardDuty automatisierten Agenten für Ihre Amazon EC2 EC2-Ressourcen in Ihrem eigenständigen Konto oder einer Umgebung mit mehreren Konten.
Bevor Sie fortfahren, stellen Sie sicher, dass Sie alle Anweisungen befolgen. [Voraussetzungen für die Unterstützung von Amazon EC2 EC2-Instances](prereq-runtime-monitoring-ec2-support.md)
Wenn Sie von der manuellen Verwaltung des GuardDuty Agenten zur Aktivierung des GuardDuty automatisierten Agenten wechseln, finden Sie weitere Informationen unter[Migration vom manuellen Amazon EC2 EC2-Agenten zum automatisierten Agenten](migrate-from-ec2-manual-to-automated-agent.md), bevor Sie die Schritte zur Aktivierung des GuardDuty automatisierten Agenten ausführen.
# GuardDuty Agent für Amazon EC2 EC2-Ressourcen in einer Umgebung mit mehreren Konten aktivieren
In Umgebungen mit mehreren Konten kann nur das delegierte GuardDuty Administratorkonto die automatische Agentenkonfiguration für die Ressourcentypen aktivieren oder deaktivieren, die zu den Mitgliedskonten in ihrer Organisation gehören. Die GuardDuty Mitgliedskonten können diese Konfiguration nicht von ihren Konten aus ändern. Das delegierte GuardDuty Administratorkonto verwaltet seine Mitgliedskonten mithilfe von AWS Organizations. Weitere Informationen zu Umgebungen mit mehreren Konten finden Sie unter [Verwaltung mehrerer Konten](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html).
## Für ein delegiertes Administratorkonto GuardDuty
------
#### [ Configure for all instances ]
Wenn Sie für Runtime Monitoring die Option **Für alle Konten aktivieren** ausgewählt haben, wählen Sie eine der folgenden Optionen für das delegierte GuardDuty Administratorkonto:
+ **Option 1**
Wählen Sie unter **Automatisierte Agentenkonfiguration** im Abschnitt **EC2** die Option **Für alle Konten aktivieren** aus.
+ **Option 2**
+ Wählen Sie unter **Automatisierte Agentenkonfiguration** im Abschnitt **EC2** die Option **Konten manuell konfigurieren** aus.
+ **Wählen Sie unter **Delegierter Administrator (dieses Konto)** die Option Aktivieren aus.**
+ Wählen Sie **Speichern**.
Wenn Sie **Konten manuell für Runtime Monitoring konfigurieren** ausgewählt haben, führen Sie die folgenden Schritte aus:
+ Wählen Sie unter **Automatisierte Agentenkonfiguration** im Abschnitt **EC2** die Option **Konten manuell konfigurieren** aus.
+ **Wählen Sie unter **Delegierter Administrator (dieses Konto)** die Option Aktivieren aus.**
+ Wählen Sie **Speichern**.
Unabhängig davon, welche Option Sie wählen, um die automatische Agentenkonfiguration für das delegierte GuardDuty Administratorkonto zu aktivieren, können Sie sicherstellen, dass die SSM-Zuordnung, die GuardDuty erstellt wird, den Security Agent auf allen EC2-Ressourcen installiert und verwaltet, die zu diesem Konto gehören.
1. Öffnen Sie die Konsole unter AWS Systems Manager . [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Öffnen Sie die Registerkarte **Ziele** für die SSM-Zuordnung (`GuardDutyRuntimeMonitoring-do-not-delete`). Beachten Sie, dass der **Tag-Schlüssel** als **InstanceIds**angezeigt wird.
------
#### [ Using inclusion tag in selected instances ]
**So konfigurieren Sie den GuardDuty Agenten für ausgewählte Amazon EC2 EC2-Instances**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon EC2 EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Fügen Sie den Instances, die Sie überwachen und potenzielle Bedrohungen erkennen GuardDuty möchten, das `true` Tag`GuardDutyManaged`: hinzu. Informationen zum Hinzufügen dieses Tags finden Sie unter [So fügen Sie einer einzelnen Ressource ein Tag hinzu](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags).
Durch Hinzufügen dieses Tags GuardDuty kann der Security Agent für diese ausgewählten EC2-Instances installiert und verwaltet werden. Sie **müssen die automatische Agentenkonfiguration nicht** explizit aktivieren.
1. Sie können überprüfen, ob die SSM-Verknüpfung, die GuardDuty erstellt wird, den Security Agent nur auf den EC2-Ressourcen installiert und verwaltet, die mit den Inclusion-Tags gekennzeichnet sind.
Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Öffnen Sie die Registerkarte **Ziele** für die SSM-Zuordnung, die erstellt wird (`GuardDutyRuntimeMonitoring-do-not-delete`). Der **Tag-Schlüssel** wird als **Tag: GuardDutyManaged** angezeigt.
------
#### [ Using exclusion tag in selected instances ]
**Anmerkung**
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.
**So konfigurieren Sie den GuardDuty Agenten für ausgewählte Amazon EC2 EC2-Instances**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon EC2 EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Fügen Sie den Instances, die Sie nicht überwachen und potenzielle Bedrohungen **nicht** erkennen GuardDuty möchten, das `false` Tag`GuardDutyManaged`: hinzu. Informationen zum Hinzufügen dieses Tags finden Sie unter [So fügen Sie einer einzelnen Ressource ein Tag hinzu](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags).
1.
**Gehen Sie wie folgt vor[, damit die Ausschluss-Tags in den Instanz-Metadaten verfügbar](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#general-runtime-monitoring-prereq-ec2) sind:**
1. Sehen Sie sich auf dem Tab „**Details**“ Ihrer Instance den Status für **Tags zulassen in den Instanz-Metadaten** an.
Wenn es derzeit **Deaktiviert** ist, gehen Sie wie folgt vor, um den Status auf **Aktiviert** zu ändern. Andernfalls überspringen Sie diesen Schritt.
1. Wählen Sie im Menü **Aktionen** die Option **Instanzeinstellungen** aus.
1. Wähle „**Tags in Instanz-Metadaten zulassen**“.
1. Nachdem Sie das Ausschluss-Tag hinzugefügt haben, führen Sie dieselben Schritte aus, wie auf der Registerkarte **Für alle Instanzen konfigurieren** angegeben.
------
Sie können jetzt die Laufzeit beurteilen[Runtime-Abdeckung und Fehlerbehebung für Amazon EC2 EC2-Instance](gdu-assess-coverage-ec2.md).
## Automatische Aktivierung für alle Mitgliedskonten
**Anmerkung**
Die Aktualisierung der Konfiguration der Mitgliedskonten kann bis zu 24 Stunden dauern.
------
#### [ Configure for all instances ]
Bei den folgenden Schritten wird davon ausgegangen, dass Sie im Abschnitt Runtime Monitoring die Option **Für alle Konten aktivieren** ausgewählt haben:
1. Wählen Sie im Abschnitt **Automatisierte Agentenkonfiguration** **für **Amazon EC2** die Option Für alle Konten aktivieren** aus.
1. Sie können überprüfen, ob die SSM-Verknüpfung, die (`GuardDutyRuntimeMonitoring-do-not-delete`) GuardDuty erstellt, den Security Agent auf allen EC2-Ressourcen installiert und verwaltet, die zu diesem Konto gehören.
1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Öffnen Sie die Registerkarte **Ziele** für die SSM-Verknüpfung. Beachten Sie, dass der **Tag-Schlüssel** als **InstanceIds**angezeigt wird.
------
#### [ Using inclusion tag in selected instances ]
**So konfigurieren Sie den GuardDuty Agenten für ausgewählte Amazon EC2 EC2-Instances**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon EC2 EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Fügen Sie den EC2-Instances, die Sie überwachen und potenzielle Bedrohungen erkennen GuardDuty möchten, das `true` Tag`GuardDutyManaged`: hinzu. Informationen zum Hinzufügen dieses Tags finden Sie unter [So fügen Sie einer einzelnen Ressource ein Tag hinzu](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags).
Durch Hinzufügen dieses Tags GuardDuty kann der Security Agent für diese ausgewählten EC2-Instances installiert und verwaltet werden. Sie **müssen die automatische Agentenkonfiguration nicht** explizit aktivieren.
1. Sie können überprüfen, ob die SSM-Verknüpfung, die GuardDuty erstellt wird, den Security Agent auf allen EC2-Ressourcen installiert und verwaltet, die zu Ihrem Konto gehören.
1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Öffnen Sie die Registerkarte **Ziele** für die SSM-Zuordnung (`GuardDutyRuntimeMonitoring-do-not-delete`). Beachten Sie, dass der **Tag-Schlüssel** als **InstanceIds**angezeigt wird.
------
#### [ Using exclusion tag in selected instances ]
**Anmerkung**
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.
**So konfigurieren Sie den GuardDuty Security Agent für ausgewählte Amazon EC2 EC2-Instances**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon EC2 EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Fügen Sie den Instances, die Sie nicht überwachen und potenzielle Bedrohungen **nicht** erkennen GuardDuty möchten, das `false` Tag`GuardDutyManaged`: hinzu. Informationen zum Hinzufügen dieses Tags finden Sie unter [So fügen Sie einer einzelnen Ressource ein Tag hinzu](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags).
1.
**Gehen Sie wie folgt vor[, damit die Ausschluss-Tags in den Instanz-Metadaten verfügbar](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#general-runtime-monitoring-prereq-ec2) sind:**
1. Sehen Sie sich auf dem Tab „**Details**“ Ihrer Instance den Status für **Tags zulassen in den Instanz-Metadaten** an.
Wenn es derzeit **Deaktiviert** ist, gehen Sie wie folgt vor, um den Status auf **Aktiviert** zu ändern. Andernfalls überspringen Sie diesen Schritt.
1. Wählen Sie im Menü **Aktionen** die Option **Instanzeinstellungen** aus.
1. Wähle „**Tags in Instanz-Metadaten zulassen**“.
1. Nachdem Sie das Ausschluss-Tag hinzugefügt haben, führen Sie dieselben Schritte aus, wie auf der Registerkarte **Für alle Instanzen konfigurieren** angegeben.
------
Sie können jetzt die Laufzeit beurteilen[Runtime-Abdeckung und Fehlerbehebung für Amazon EC2 EC2-Instance](gdu-assess-coverage-ec2.md).
## Automatische Aktivierung nur für neue Mitgliedskonten
Das delegierte GuardDuty Administratorkonto kann die automatische Agentenkonfiguration für die Amazon EC2 EC2-Ressource so einrichten, dass sie automatisch für die neuen Mitgliedskonten aktiviert wird, wenn sie der Organisation beitreten.
------
#### [ Configure for all instances ]
Bei den folgenden Schritten wird davon ausgegangen, dass Sie im Abschnitt **Runtime Monitoring** die Option **Automatisch für neue Mitgliedskonten aktivieren** ausgewählt haben:
1. Wählen Sie im Navigationsbereich **Runtime Monitoring** aus.
1. Wählen Sie auf der Seite **Runtime Monitoring** die Option **Bearbeiten** aus.
1. Wählen Sie **Automatisch für neue Mitgliedskonten aktivieren**. Dieser Schritt stellt sicher, dass jedes Mal, wenn ein neues Konto Ihrer Organisation beitritt, die automatische Agentenkonfiguration für Amazon EC2 automatisch für das Konto aktiviert wird. Nur das delegierte GuardDuty Administratorkonto der Organisation kann diese Auswahl ändern.
1. Wählen Sie **Speichern**.
Wenn der Organisation ein neues Mitgliedskonto beitritt, wird diese Konfiguration automatisch für dieses Mitglied aktiviert. GuardDuty Um den Sicherheitsagenten für die Amazon EC2 EC2-Instances zu verwalten, die zu diesem neuen Mitgliedskonto gehören, müssen Sie sicherstellen, dass alle Voraussetzungen erfüllt [Für eine EC2-Instance](prereq-runtime-monitoring-ec2-support.md) sind.
Wenn eine SSM-Zuordnung erstellt wird (`GuardDutyRuntimeMonitoring-do-not-delete`), können Sie überprüfen, ob die SSM-Zuordnung den Security Agent auf allen EC2-Instances installiert und verwaltet, die zu dem neuen Mitgliedskonto gehören.
+ Öffnen Sie die Konsole unter AWS Systems Manager . [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
+ Öffnen Sie die Registerkarte **Ziele** für die SSM-Verknüpfung. Beachten Sie, dass der **Tag-Schlüssel** als **InstanceIds**angezeigt wird.
------
#### [ Using inclusion tag in selected instances ]
**Um den GuardDuty Security Agent für ausgewählte Instanzen in Ihrem Konto zu konfigurieren**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon EC2 EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Fügen Sie den Instances, die Sie überwachen und potenzielle Bedrohungen erkennen GuardDuty möchten, das `true` Tag`GuardDutyManaged`: hinzu. Informationen zum Hinzufügen dieses Tags finden Sie unter [So fügen Sie einer einzelnen Ressource ein Tag hinzu](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags).
Wenn Sie dieses Tag hinzufügen GuardDuty , können Sie den Security Agent für diese ausgewählten Instanzen installieren und verwalten. Sie müssen die automatische Agentenkonfiguration nicht explizit aktivieren.
1. Sie können überprüfen, ob die SSM-Verknüpfung, die GuardDuty erstellt wird, den Security Agent nur auf den EC2-Ressourcen installiert und verwaltet, die mit den Inclusion-Tags gekennzeichnet sind.
1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Öffnen Sie die Registerkarte **Ziele** für die SSM-Verknüpfung, die erstellt wird. Der **Tag-Schlüssel** wird als **Tag: GuardDutyManaged** angezeigt.
------
#### [ Using exclusion tag in selected instances ]
**Anmerkung**
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.
**Um den GuardDuty Security Agent für bestimmte Instances in Ihrem eigenständigen Konto zu konfigurieren**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon EC2 EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Fügen Sie den Instances, die Sie nicht überwachen und potenzielle Bedrohungen **nicht** erkennen GuardDuty möchten, das `false` Tag`GuardDutyManaged`: hinzu. Informationen zum Hinzufügen dieses Tags finden Sie unter [So fügen Sie einer einzelnen Ressource ein Tag hinzu](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags).
1.
**Gehen Sie wie folgt vor[, damit die Ausschluss-Tags in den Instanz-Metadaten verfügbar](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#general-runtime-monitoring-prereq-ec2) sind:**
1. Sehen Sie sich auf dem Tab „**Details**“ Ihrer Instance den Status für **Tags zulassen in den Instanz-Metadaten** an.
Wenn es derzeit **Deaktiviert** ist, gehen Sie wie folgt vor, um den Status auf **Aktiviert** zu ändern. Andernfalls überspringen Sie diesen Schritt.
1. Wählen Sie im Menü **Aktionen** die Option **Instanzeinstellungen** aus.
1. Wähle „**Tags in Instanz-Metadaten zulassen**“.
1. Nachdem Sie das Ausschluss-Tag hinzugefügt haben, führen Sie dieselben Schritte aus, wie auf der Registerkarte **Für alle Instanzen konfigurieren** angegeben.
------
Sie können jetzt die Laufzeit beurteilen[Runtime-Abdeckung und Fehlerbehebung für Amazon EC2 EC2-Instance](gdu-assess-coverage-ec2.md).
## Nur ausgewählte Mitgliedskonten
------
#### [ Configure for all instances ]
1. Wählen Sie auf der Seite **Konten** ein oder mehrere Konten aus, für die Sie die **Runtime Monitoring-Automated Agent-Konfiguration (Amazon** EC2) aktivieren möchten. Stellen Sie sicher, dass Runtime Monitoring für die Konten, die Sie in diesem Schritt auswählen, bereits aktiviert ist.
1. Wählen Sie **unter Schutzpläne bearbeiten** die entsprechende Option aus, um die **Runtime Monitoring-Automated Agent-Konfiguration (Amazon** EC2) zu aktivieren.
1. Wählen Sie **Bestätigen** aus.
------
#### [ Using inclusion tag in selected instances ]
**Um den GuardDuty Security Agent für ausgewählte Instances zu konfigurieren**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon EC2 EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Fügen Sie den Instances, die Sie überwachen und potenzielle Bedrohungen erkennen GuardDuty möchten, das `true` Tag`GuardDutyManaged`: hinzu. Informationen zum Hinzufügen dieses Tags finden Sie unter [So fügen Sie einer einzelnen Ressource ein Tag hinzu](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags).
Durch Hinzufügen dieses Tags können Sie GuardDuty den Security Agent für Ihre markierten Amazon EC2 EC2-Instances verwalten. Sie müssen die automatische Agentenkonfiguration nicht explizit aktivieren (**Runtime Monitoring — Automated Agent Configuration (EC2**)).
------
#### [ Using exclusion tag in selected instances ]
**Anmerkung**
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.
**Um den GuardDuty Security Agent für ausgewählte Instances zu konfigurieren**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon EC2 EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Fügen Sie den EC2-Instances, die Sie nicht überwachen oder potenzielle **Bedrohungen nicht** erkennen GuardDuty möchten, das `false` Tag`GuardDutyManaged`: hinzu. Informationen zum Hinzufügen dieses Tags finden Sie unter [So fügen Sie einer einzelnen Ressource ein Tag hinzu](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags).
1.
**Gehen Sie wie folgt vor[, damit die Ausschluss-Tags in den Instanz-Metadaten verfügbar](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#general-runtime-monitoring-prereq-ec2) sind:**
1. Sehen Sie sich auf dem Tab „**Details**“ Ihrer Instance den Status für **Tags zulassen in den Instanz-Metadaten** an.
Wenn es derzeit **Deaktiviert** ist, gehen Sie wie folgt vor, um den Status auf **Aktiviert** zu ändern. Andernfalls überspringen Sie diesen Schritt.
1. Wählen Sie im Menü **Aktionen** die Option **Instanzeinstellungen** aus.
1. Wähle „**Tags in Instanz-Metadaten zulassen**“.
1. Nachdem Sie das Ausschluss-Tag hinzugefügt haben, führen Sie dieselben Schritte aus, wie auf der Registerkarte **Für alle Instanzen konfigurieren** angegeben.
------
Sie können jetzt beurteilen[Runtime-Abdeckung und Fehlerbehebung für Amazon EC2 EC2-Instance](gdu-assess-coverage-ec2.md).
# Aktivierung eines GuardDuty automatisierten Agenten für Amazon EC2 EC2-Ressourcen in einem eigenständigen Konto
Ein eigenständiges Konto hat die Entscheidung, einen Schutzplan AWS-Konto in einem bestimmten Bereich zu aktivieren oder zu deaktivieren AWS-Region.
Wenn Ihr Konto über oder über AWS Organizations die Einladungsmethode mit einem GuardDuty Administratorkonto verknüpft ist, gilt dieser Abschnitt nicht für Ihr Konto. Weitere Informationen finden Sie unter [Runtime Monitoring für Umgebungen mit mehreren Konten aktivieren](enable-runtime-monitoring-multiple-acc-env.md).
Nachdem Sie Runtime Monitoring aktiviert haben, stellen Sie sicher, dass Sie den GuardDuty Security Agent durch automatische Konfiguration oder manuelle Installation installieren. Nachdem Sie alle im folgenden Verfahren aufgeführten Schritte ausgeführt haben, stellen Sie sicher, dass Sie den Security Agent installieren.
Je nachdem, ob Sie alle oder ausgewählte Amazon EC2 EC2-Ressourcen überwachen möchten, wählen Sie eine bevorzugte Methode und folgen Sie den Schritten in der folgenden Tabelle.
------
#### [ Configure for all instances ]
**Um Runtime Monitoring für alle Instances in Ihrem eigenständigen Konto zu konfigurieren**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die GuardDuty Konsole unter [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. Wählen Sie im Navigationsbereich **Runtime Monitoring** aus.
1. Wählen Sie auf der Registerkarte **Konfiguration** die Option **Bearbeiten** aus.
1. Wählen Sie im Abschnitt **EC2** die Option **Aktivieren** aus.
1. Wählen Sie **Speichern**.
1. Sie können überprüfen, ob die SSM-Verknüpfung, die GuardDuty erstellt wird, den Security Agent auf allen EC2-Ressourcen installiert und verwaltet, die zu Ihrem Konto gehören.
1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Öffnen Sie die Registerkarte **Ziele** für die SSM-Zuordnung (`GuardDutyRuntimeMonitoring-do-not-delete`). Beachten Sie, dass der **Tag-Schlüssel** als **InstanceIds**angezeigt wird.
------
#### [ Using inclusion tag in selected instances ]
**So konfigurieren Sie den GuardDuty Security Agent für ausgewählte Amazon EC2 EC2-Instances**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon EC2 EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Fügen Sie den Instances, die Sie überwachen und potenzielle Bedrohungen erkennen GuardDuty möchten, das `true` Tag`GuardDutyManaged`: hinzu. Informationen zum Hinzufügen dieses Tags finden Sie unter [So fügen Sie einer einzelnen Ressource ein Tag hinzu](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags).
1. Sie können überprüfen, ob die SSM-Zuordnung, die GuardDuty erstellt wird, den Security Agent nur auf den EC2-Ressourcen installiert und verwaltet, die mit den Inklusion-Tags gekennzeichnet sind.
Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Öffnen Sie die Registerkarte **Ziele** für die SSM-Zuordnung, die erstellt wird (`GuardDutyRuntimeMonitoring-do-not-delete`). Der **Tag-Schlüssel** wird als **Tag: GuardDutyManaged** angezeigt.
------
#### [ Using exclusion tag in selected instances ]
**Anmerkung**
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.
**So konfigurieren Sie den GuardDuty Security Agent für ausgewählte Amazon EC2 EC2-Instances**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon EC2 EC2-Konsole unter [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/).
1. Fügen Sie den Instances, die Sie nicht überwachen und potenzielle Bedrohungen **nicht** erkennen GuardDuty möchten, das `false` Tag`GuardDutyManaged`: hinzu. Informationen zum Hinzufügen dieses Tags finden Sie unter [So fügen Sie einer einzelnen Ressource ein Tag hinzu](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags).
1.
**Gehen Sie wie folgt vor[, damit die Ausschluss-Tags in den Instanz-Metadaten verfügbar](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#general-runtime-monitoring-prereq-ec2) sind:**
1. Sehen Sie sich auf dem Tab „**Details**“ Ihrer Instance den Status für **Tags zulassen in den Instanz-Metadaten** an.
Wenn es derzeit **Deaktiviert** ist, gehen Sie wie folgt vor, um den Status auf **Aktiviert** zu ändern. Andernfalls überspringen Sie diesen Schritt.
1. Wählen Sie die Instanz aus, für die Sie Tags zulassen möchten.
1. Wählen Sie im Menü **Aktionen** die Option **Instanzeinstellungen** aus.
1. Wähle „**Tags in Instanz-Metadaten zulassen**“.
1. Wählen **Sie unter Zugriff auf Tags in Instanzmetadaten** die Option **Zulassen** aus.
1. Wählen Sie **Speichern**.
1. Nachdem Sie das Ausschluss-Tag hinzugefügt haben, führen Sie dieselben Schritte aus, wie auf der Registerkarte **Für alle Instanzen konfigurieren** angegeben.
------
Sie können jetzt die Laufzeit beurteilen. [Runtime-Abdeckung und Fehlerbehebung für Amazon EC2 EC2-Instance](gdu-assess-coverage-ec2.md)
# Migration vom manuellen Amazon EC2 EC2-Agenten zum automatisierten Agenten
Dieser Abschnitt gilt für den AWS-Konto Fall, dass Sie den Security Agent zuvor manuell verwaltet haben und jetzt die GuardDuty automatische Agentenkonfiguration verwenden möchten. Falls dies nicht auf Sie zutrifft, fahren Sie mit der Konfiguration des Security Agents für Ihr Konto fort.
Wenn Sie den GuardDuty Automated Agent aktivieren, GuardDuty verwaltet er den Security Agent in Ihrem Namen. Informationen darüber, welche GuardDuty Schritte erforderlich sind, finden Sie unter[Verwenden Sie die automatische Agentenkonfiguration (empfohlen)](how-runtime-monitoring-works-ec2.md#use-automated-agent-config-ec2).
## Bereinigen von Ressourcen
**SSM-Zuordnung löschen**
+ Löschen Sie alle SSM-Verknüpfungen, die Sie möglicherweise erstellt haben, als Sie den Security Agent für Amazon EC2 manuell verwaltet haben. Weitere Informationen finden Sie unter Verknüpfungen [löschen](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-state-manager-delete-association.html).
+ Dies geschieht, damit Sie die Verwaltung von SSM-Aktionen übernehmen GuardDuty können, unabhängig davon, ob Sie automatisierte Agenten auf Konto- oder Instanzebene verwenden (mithilfe von Inklusions- oder Ausschlusstags). Weitere Informationen darüber, welche SSM-Aktionen ausführen können, GuardDuty finden Sie unter. [Mit dem Dienst verknüpfte Rollenberechtigungen für GuardDuty](slr-permissions.md)
+ Wenn Sie eine SSM-Verknüpfung löschen, die zuvor für die manuelle Verwaltung des Security Agents erstellt wurde, kann es bei GuardDuty der Erstellung einer SSM-Verknüpfung zur automatischen Verwaltung des Security Agents zu einer kurzen Überschneidung kommen. Während dieses Zeitraums kann es aufgrund der SSM-Planung zu Konflikten kommen. Weitere Informationen finden Sie unter [Amazon EC2 SSM-Planung](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-scheduler.html).
**Einschluss- und Ausschluss-Tags für Ihre Amazon EC2 EC2-Instances verwalten**
+ **Inclusion-Tags** — Wenn Sie die GuardDuty automatische Agentenkonfiguration nicht aktivieren, sondern eine Ihrer Amazon EC2 EC2-Instances mit einem Inclusion-Tag (`GuardDutyManaged`:`true`) kennzeichnen, wird eine SSM-Zuordnung GuardDuty erstellt, die den Security Agent auf den ausgewählten EC2-Instances installiert und verwaltet. Dies ist ein erwartetes Verhalten, das Ihnen hilft, den Security Agent nur auf ausgewählten EC2-Instances zu verwalten. Weitere Informationen finden Sie unter [So funktioniert Runtime Monitoring mit Amazon EC2 EC2-Instances](how-runtime-monitoring-works-ec2.md).
Um die Installation und Verwaltung des Security Agents zu GuardDuty verhindern, entfernen Sie das Inclusion-Tag von diesen EC2-Instances. Weitere Informationen finden [Sie unter Hinzufügen und Löschen von Tags](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#adding-or-deleting-tags) im *Amazon EC2 EC2-Benutzerhandbuch*.
+ **Ausschluss-Tags** — Wenn Sie die GuardDuty automatische Agentenkonfiguration für alle EC2-Instances in Ihrem Konto aktivieren möchten, stellen Sie sicher, dass keine EC2-Instance mit einem Ausschluss-Tag (:) `GuardDutyManaged` gekennzeichnet ist. `false`
# Manuelles Verwalten des Security Agents für Amazon EC2 EC2-Ressourcen
Dieser Abschnitt enthält die Schritte zur manuellen Installation und Aktualisierung des Security Agents für Ihre Amazon EC2 EC2-Ressourcen.
Nachdem Sie Runtime Monitoring aktiviert haben, müssen Sie den GuardDuty Security Agent manuell installieren. Um den GuardDuty Security Agent manuell zu verwalten, müssen Sie zunächst manuell einen Amazon VPC-Endpunkt erstellen. Danach können Sie den Security Agent so installieren, dass er GuardDuty die Runtime-Ereignisse von den Amazon EC2 EC2-Instances empfängt. Wenn eine neue Agentenversion für diese Ressource GuardDuty veröffentlicht wird, können Sie die Agentenversion in Ihrem Konto aktualisieren.
Die folgenden Themen umfassen die Schritte zur kontinuierlichen Verwaltung des Security Agents für Ihre Amazon EC2 EC2-Ressourcen.
**Topics**
+ [Voraussetzung — Manuelles Erstellen eines Amazon VPC-Endpunkts](creating-vpc-endpoint-ec2-agent-manually.md)
+ [Manuelles Installieren des Security Agents](installing-gdu-security-agent-ec2-manually.md)
+ [Manuelles Aktualisieren des GuardDuty Security Agents für die Amazon EC2 EC2-Instance](gdu-update-security-agent-ec2.md)
# Voraussetzung — Manuelles Erstellen eines Amazon VPC-Endpunkts
Bevor Sie den GuardDuty Security Agent installieren können, müssen Sie einen Amazon Virtual Private Cloud (Amazon VPC) -Endpunkt erstellen. Dies hilft beim GuardDuty Empfang der Runtime-Ereignisse Ihrer Amazon EC2 EC2-Instances.
**Anmerkung**
Für die Nutzung des VPC-Endpunkts fallen keine zusätzlichen Kosten an.
**So erstellen Sie einen Amazon VPC-Endpunkt**
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon VPC-Konsole unter [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Wählen Sie im Navigationsbereich unter **VPC Private Cloud** die Option **Endpoints** aus.
1. Klicken Sie auf **Endpunkt erstellen**.
1. Wählen Sie auf der Seite **Endpunkt erstellen** für **Servicekategorie** die Option **Andere Endpunkt-Services**.
1. Geben Sie unter **Servicename** **com.amazonaws.*us-east-1*.guardduty-data** ein.
Stellen Sie sicher, dass Sie es durch Ihr *us-east-1* ersetzen. AWS-Region Dies muss dieselbe Region sein wie die Amazon EC2 EC2-Instance, die zu Ihrer AWS Konto-ID gehört.
1. Wählen Sie **Service verifizieren**.
1. Nachdem der Dienstname erfolgreich verifiziert wurde, wählen Sie die **VPC** aus, in der sich Ihre Instance befindet. Fügen Sie die folgende Richtlinie hinzu, um die Nutzung von Amazon VPC-Endpunkten nur auf das angegebene Konto zu beschränken. Unter Angabe der unter dieser Richtlinie angegebenen Organisations-`Condition` können Sie die folgende Richtlinie aktualisieren, um den Zugriff auf Ihren Endpunkt einzuschränken. Informationen zur Bereitstellung von Amazon VPC-Endpunktunterstützung für ein bestimmtes Konto IDs in Ihrer Organisation finden Sie unter[Organization condition to restrict access to your endpoint](#gdu-runtime-ec2-organization-restrict-access-vpc-endpoint).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": "*",
"Resource": "*",
"Effect": "Allow",
"Principal": "*"
},
{
"Condition": {
"StringNotEquals": {
"aws:PrincipalAccount": "111122223333"
}
},
"Action": "*",
"Resource": "*",
"Effect": "Deny",
"Principal": "*"
}
]
}
```
------
Die `aws:PrincipalAccount`-Konto-ID muss mit dem Konto übereinstimmen, das die VPC und den VPC-Endpunkt enthält. Die folgende Liste zeigt, wie Sie den VPC-Endpunkt mit einem anderen AWS Konto IDs teilen können:
+ Um mehrere Konten für den Zugriff auf den VPC-Endpunkt anzugeben, `"aws:PrincipalAccount: "111122223333"` ersetzen Sie ihn durch den folgenden Block:
```
"aws:PrincipalAccount": [
"666666666666",
"555555555555"
]
```
Stellen Sie sicher, dass Sie das AWS Konto IDs durch das Konto IDs der Konten ersetzen, die auf den VPC-Endpunkt zugreifen müssen.
+ Um allen Mitgliedern einer Organisation den Zugriff auf den VPC-Endpunkt zu ermöglichen, `"aws:PrincipalAccount: "111122223333"` ersetzen Sie ihn durch die folgende Zeile:
```
"aws:PrincipalOrgID": "o-abcdef0123"
```
Achten Sie darauf, die Organisation *o-abcdef0123* durch Ihre Organisations-ID zu ersetzen.
+ Um den Zugriff auf eine Ressource anhand einer Organisations-ID einzuschränken, fügen Sie Ihre `ResourceOrgID` zur Richtlinie hinzu. Weitere Informationen finden Sie unter [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceorgid](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceorgid) im *IAM-Benutzerhandbuch*.
```
"aws:ResourceOrgID": "o-abcdef0123"
```
1. Wählen Sie unter **Zusätzliche Einstellungen** die Option **DNS-Name aktivieren**.
1. Wählen Sie unter **Subnetze** die Subnetze aus, in denen sich Ihre Instance befindet.
1. Wählen Sie unter **Sicherheitsgruppen** eine Sicherheitsgruppe aus, für die der eingehende Port 443 von Ihrer VPC (oder Ihrer Amazon EC2 EC2-Instance) aktiviert ist. Wenn Sie noch keine Sicherheitsgruppe haben, für die ein eingehender Port 443 aktiviert ist, finden [Sie weitere Informationen unter Erstellen einer Sicherheitsgruppe für Ihre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/creating-security-groups.html) im *Amazon VPC-Benutzerhandbuch*.
Wenn bei der Einschränkung der eingehenden Berechtigungen für Ihre VPC (oder Instance) ein Problem auftritt, können Sie den eingehenden Port 443 von einer beliebigen IP-Adresse aus verwenden. `(0.0.0.0/0)` GuardDuty Empfiehlt jedoch, IP-Adressen zu verwenden, die dem CIDR-Block für Ihre VPC entsprechen. Weitere Informationen finden Sie unter [VPC CIDR-Blöcke](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-cidr-blocks.html) im *Amazon VPC-Benutzerhandbuch*.
Nachdem Sie die Schritte ausgeführt haben, stellen [Validierung der VPC-Endpunktkonfiguration](validate-vpc-endpoint-config-runtime-monitoring.md) Sie sicher, dass der VPC-Endpunkt korrekt eingerichtet wurde.
# Manuelles Installieren des Security Agents
GuardDuty bietet die folgenden zwei Methoden zur Installation des GuardDuty Security Agents auf Ihren Amazon EC2 EC2-Instances. Bevor Sie fortfahren, stellen Sie sicher, dass Sie die folgenden Schritte befolgen. [Voraussetzung — Manuelles Erstellen eines Amazon VPC-Endpunkts](creating-vpc-endpoint-ec2-agent-manually.md)
Wählen Sie eine bevorzugte Zugriffsmethode, um den Security Agent in Ihren Amazon EC2 EC2-Ressourcen zu installieren.
+ [Methode 1 — Verwenden AWS Systems Manager](#install-gdu-by-using-sys-runtime-monitoring)— Für diese Methode muss Ihre Amazon EC2 EC2-Instance AWS Systems Manager verwaltet werden.
+ [Methode 2 — Verwenden von Linux-Paketmanagern](#install-gdu-by-rpm-scripts-runtime-monitoring)— Sie können diese Methode unabhängig davon verwenden, ob Ihre Amazon EC2 EC2-Instances AWS Systems Manager verwaltet werden oder nicht. Basierend auf Ihren [Betriebssystemverteilungen](https://docs.aws.amazon.com/guardduty/latest/ug/prereq-runtime-monitoring-ec2-support.html#validating-architecture-req-ec2) können Sie eine geeignete Methode wählen, um entweder RPM-Skripte oder Debian-Skripte zu installieren. Wenn Sie die *Fedora-Plattform* verwenden, müssen Sie diese Methode verwenden, um den Agenten zu installieren.
## Methode 1 — Verwenden AWS Systems Manager
Um diese Methode zu verwenden, stellen Sie sicher, dass Ihre Amazon EC2 EC2-Instances AWS Systems Manager verwaltet werden, und installieren Sie dann den Agenten.
### AWS Systems Manager verwaltete Amazon EC2 EC2-Instanz
Gehen Sie wie folgt vor, um Ihre Amazon EC2 EC2-Instances zu AWS Systems Manager verwalten.
+ [AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/what-is-systems-manager.html)hilft Ihnen bei der Verwaltung Ihrer AWS Anwendungen und Ressourcen end-to-end und ermöglicht sichere Abläufe in großem Maßstab.
Informationen zur Verwaltung Ihrer Amazon EC2 EC2-Instances mit AWS Systems Manager finden Sie 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) im *AWS Systems Manager Benutzerhandbuch*.
+ Die folgende Tabelle zeigt die neuen GuardDuty verwalteten AWS Systems Manager Dokumente:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/installing-gdu-security-agent-ec2-manually.html)
Weitere Informationen zu AWS Systems Manager finden Sie in den [Amazon EC2 Systems Manager Manager-Dokumenten](https://docs.aws.amazon.com/systems-manager/latest/userguide/documents.html) im *AWS Systems Manager Benutzerhandbuch*.
**Für Debian-Server**
Für die von bereitgestellten Amazon Machine Images (AMIs) für Debian Server AWS müssen Sie den AWS Systems Manager Agenten (SSM-Agent) installieren. Sie müssen einen zusätzlichen Schritt ausführen, um den SSM-Agenten zu installieren, damit Ihre Amazon EC2 EC2-Debian-Server-Instances SSM verwaltet werden. *Informationen zu den Schritten, die Sie ergreifen müssen, finden Sie unter [Manuelles Installieren des SSM-Agenten auf Debian-Server-Instances im Benutzerhandbuch](https://docs.aws.amazon.com/systems-manager/latest/userguide/agent-install-deb.html).AWS Systems Manager *
**Um den GuardDuty Agenten für die Amazon EC2 EC2-Instance zu installieren, verwenden Sie AWS Systems Manager**
1. Öffnen Sie die AWS Systems Manager Konsole unter. [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)
1. Wählen Sie im Navigationsbereich **Dokumente**
1. Wählen Sie **unter Owned by Amazon** die Option aus`AmazonGuardDuty-ConfigureRuntimeMonitoringSsmPlugin`.
1. Wählen Sie **Run Command (Befehl ausführen)** aus.
1. Geben Sie die folgenden Run-Command-Parameter ein
+ Aktion: Wählen Sie **Installieren**.
+ Installationstyp: Wählen **Sie Installieren oder Deinstallieren.**
+ Name: `AmazonGuardDuty-RuntimeMonitoringSsmPlugin`
+ Version: Wenn dieses Feld leer bleibt, erhalten Sie die neueste Version des GuardDuty Security Agents. Weitere Informationen zu den Release-Versionen finden Sie unter[GuardDuty Security-Agent-Versionen für Amazon EC2 EC2-Instances](runtime-monitoring-agent-release-history.md#ec2-gdu-agent-release-history).
1. Wählen Sie die Amazon EC2 EC2-Zielinstanz aus. Sie können eine oder mehrere Amazon EC2 EC2-Instances auswählen. Weitere Informationen finden Sie im *AWS Systems Manager Benutzerhandbuch* unter [Befehle von der Konsole aus AWS Systems Manager ausführen](https://docs.aws.amazon.com/systems-manager/latest/userguide/running-commands-console.html)
1. Überprüfen Sie, ob die GuardDuty Agenteninstallation fehlerfrei ist. Weitere Informationen finden Sie unter [Der Installationsstatus des GuardDuty Security Agents wird überprüft](#validate-ec2-gdu-agent-installation-healthy).
## Methode 2 — Verwenden von Linux-Paketmanagern
Mit dieser Methode können Sie den GuardDuty Security Agent installieren, indem Sie RPM- oder Debian-Skripte ausführen. Je nach Betriebssystem können Sie eine bevorzugte Methode wählen:
+ Verwenden Sie RPM-Skripte, um den Security Agent auf Betriebssystem-Distributionen AL2,, AL2023 RedHat, CentOS oder Fedora zu installieren.
+ Verwenden Sie Debian-Skripte, um den Security Agent auf den Betriebssystem-Distributionen Ubuntu oder Debian zu installieren. Hinweise zu den unterstützten Ubuntu- und Debian-Betriebssystem-Distributionen finden Sie unter. [Überprüfen Sie die architektonischen Anforderungen](prereq-runtime-monitoring-ec2-support.md#validating-architecture-req-ec2)
------
#### [ RPM installation ]
**Wichtig**
Wir empfehlen, die RPM-Signatur des GuardDuty Security Agents zu überprüfen, bevor Sie ihn auf Ihrem Computer installieren.
1. Überprüfen Sie die GuardDuty RPM-Signatur des Security Agents
1.
**Bereiten Sie die Vorlage vor**
Bereiten Sie die Befehle mit dem entsprechenden öffentlichen Schlüssel, der Signatur von x86\$164 RPM, der Signatur von arm64 RPM und dem entsprechenden Zugriffslink zu den RPM-Skripten vor, die in Amazon S3 S3-Buckets gehostet werden. Ersetzen Sie den Wert von AWS-Region, der AWS Konto-ID und der GuardDuty Agentenversion, um auf die RPM-Skripts zuzugreifen.
+ **Öffentlicher Schlüssel**:
```
s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/publickey.pem
```
+ **GuardDuty RPM-Signatur des Security Agents**:
Signatur von x86\$164 RPM
```
s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/x86_64/amazon-guardduty-agent-1.9.2.x86_64.sig
```
Signatur von arm64 RPM
```
s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/arm64/amazon-guardduty-agent-1.9.2.arm64.sig
```
+ **Greifen Sie auf Links zu den RPM-Skripten im Amazon S3 S3-Bucket** zu:
Zugangslink für x86\$164 RPM
```
s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/x86_64/amazon-guardduty-agent-1.9.2.x86_64.rpm
```
Zugangslink für arm64 RPM
```
s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/arm64/amazon-guardduty-agent-1.9.2.arm64.rpm
```
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/installing-gdu-security-agent-ec2-manually.html)
1.
**Laden Sie die Vorlage herunter**
Stellen Sie sicher, dass Sie im folgenden Befehl zum Herunterladen des entsprechenden öffentlichen Schlüssels, der Signatur von x86\$164 RPM, der Signatur von arm64 RPM und des entsprechenden Zugriffs-Links zu den RPM-Skripten, die in Amazon S3 S3-Buckets gehostet werden, die Konto-ID durch die entsprechende AWS-Konto ID und die Region durch Ihre aktuelle Region ersetzen.
```
aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/x86_64/amazon-guardduty-agent-1.9.2.x86_64.rpm ./amazon-guardduty-agent-1.9.2.x86_64.rpm
aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/x86_64/amazon-guardduty-agent-1.9.2.x86_64.sig ./amazon-guardduty-agent-1.9.2.x86_64.sig
aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-rpm-artifacts/1.9.2/publickey.pem ./publickey.pem
```
1.
**Importieren Sie den öffentlichen Schlüssel**
Verwenden Sie den folgenden Befehl, um den öffentlichen Schlüssel in die Datenbank zu importieren:
```
gpg --import publickey.pem
```
gpg zeigt, dass der Import erfolgreich war
```
gpg: key 093FF49D: public key "AwsGuardDuty" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
```
1.
**Verifiziere die Signatur**
Verwenden Sie den folgenden Befehl, um die Signatur zu überprüfen
```
gpg --verify amazon-guardduty-agent-1.9.2.x86_64.sig amazon-guardduty-agent-1.9.2.x86_64.rpm
```
Wenn die Überprüfung erfolgreich ist, wird eine Meldung ähnlich dem folgenden Ergebnis angezeigt. Sie können jetzt mit der Installation des GuardDuty Security Agents mithilfe von RPM fortfahren.
Beispielausgabe:
```
gpg: Signature made Fri 17 Nov 2023 07:58:11 PM UTC using ? key ID 093FF49D
gpg: Good signature from "AwsGuardDuty"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7478 91EF 5378 1334 4456 7603 06C9 06A7 093F F49D
```
Wenn die Überprüfung fehlschlägt, bedeutet dies, dass die Signatur auf RPM möglicherweise manipuliert wurde. Sie müssen den öffentlichen Schlüssel aus der Datenbank entfernen und den Überprüfungsprozess erneut versuchen.
Beispiel:
```
gpg: Signature made Fri 17 Nov 2023 07:58:11 PM UTC using ? key ID 093FF49D
gpg: BAD signature from "AwsGuardDuty"
```
Verwenden Sie den folgenden Befehl, um den öffentlichen Schlüssel aus der Datenbank zu entfernen:
```
gpg --delete-keys AwsGuardDuty
```
Versuchen Sie nun erneut, die Überprüfung durchzuführen.
1. Stellen Sie [von Linux oder macOS aus eine Connect mit SSH](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-ssh.html) her.
1. Installieren Sie den GuardDuty Security Agent mit dem folgenden Befehl:
```
sudo rpm -ivh amazon-guardduty-agent-1.9.2.x86_64.rpm
```
1. Überprüfen Sie, ob die GuardDuty Agent-Installation fehlerfrei ist. Weitere Informationen zu den Schritten finden Sie unter[Der Installationsstatus des GuardDuty Security Agents wird überprüft](#validate-ec2-gdu-agent-installation-healthy).
------
#### [ Debian installation ]
**Wichtig**
Wir empfehlen, die Debian-Signatur des GuardDuty Security Agents zu überprüfen, bevor Sie ihn auf Ihrem Computer installieren.
1. Überprüfen Sie die GuardDuty Debian-Signatur des Security Agents
1.
**Bereiten Sie Vorlagen für den entsprechenden öffentlichen Schlüssel, die Signatur des amd64-Debian-Pakets, die Signatur des arm64-Debian-Pakets und den entsprechenden Zugangslink zu den Debian-Skripten vor, die in Amazon S3 S3-Buckets gehostet werden**
Ersetzen Sie in den folgenden Vorlagen den Wert von, die AWS Konto-ID und die AWS-Region GuardDuty Agentenversion, um auf die Debian-Paketskripte zuzugreifen.
+ **Öffentlicher Schlüssel**:
```
s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/publickey.pem
```
+ **GuardDuty Debian-Signatur des Sicherheitsagenten**:
Signatur von amd64
```
s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/amd64/amazon-guardduty-agent-1.9.2.amd64.sig
```
Signatur von arm64
```
s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/arm64/amazon-guardduty-agent-1.9.2.arm64.sig
```
+ **Zugriffs-Links zu den Debian-Skripten im Amazon S3 S3-Bucket**:
Zugangslink für amd64
```
s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/amd64/amazon-guardduty-agent-1.9.2.amd64.deb
```
Zugangslink für arm64
```
s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/arm64/amazon-guardduty-agent-1.9.2.arm64.deb
```
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/installing-gdu-security-agent-ec2-manually.html)
1.
**Laden Sie den entsprechenden öffentlichen Schlüssel, die Signatur von amd64, die Signatur von arm64 und den entsprechenden Zugangslink zu den Debian-Skripten herunter, die in Amazon S3 S3-Buckets gehostet werden**
Ersetzen Sie in den folgenden Befehlen die Konto-ID durch die entsprechende AWS-Konto ID und die Region durch Ihre aktuelle Region.
```
aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/amd64/amazon-guardduty-agent-1.9.2.amd64.deb ./amazon-guardduty-agent-1.9.2.amd64.deb
aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/amd64/amazon-guardduty-agent-1.9.2.amd64.sig ./amazon-guardduty-agent-1.9.2.amd64.sig
aws s3 cp s3://694911143906-eu-west-1-guardduty-agent-deb-artifacts/1.9.2/publickey.pem ./publickey.pem
```
1. Importieren Sie den öffentlichen Schlüssel in die Datenbank
```
gpg --import publickey.pem
```
gpg zeigt, dass der Import erfolgreich war
```
gpg: key 093FF49D: public key "AwsGuardDuty" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
```
1. Verifiziere die Signatur
```
gpg --verify amazon-guardduty-agent-1.9.2.amd64.sig amazon-guardduty-agent-1.9.2.amd64.deb
```
Nach einer erfolgreichen Überprüfung wird eine Meldung angezeigt, die dem folgenden Ergebnis ähnelt:
Beispielausgabe:
```
gpg: Signature made Fri 17 Nov 2023 07:58:11 PM UTC using ? key ID 093FF49D
gpg: Good signature from "AwsGuardDuty"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 7478 91EF 5378 1334 4456 7603 06C9 06A7 093F F49D
```
Sie können nun mit der Installation des GuardDuty Security Agents unter Verwendung von Debian fortfahren.
Wenn die Überprüfung jedoch fehlschlägt, bedeutet dies, dass die Signatur im Debian-Paket möglicherweise manipuliert wurde.
Beispiel:
```
gpg: Signature made Fri 17 Nov 2023 07:58:11 PM UTC using ? key ID 093FF49D
gpg: BAD signature from "AwsGuardDuty"
```
Verwenden Sie den folgenden Befehl, um den öffentlichen Schlüssel aus der Datenbank zu entfernen:
```
gpg --delete-keys AwsGuardDuty
```
Versuchen Sie nun erneut, den Überprüfungsprozess durchzuführen.
1. Stellen Sie [von Linux oder macOS aus eine Connect mit SSH](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-ssh.html) her.
1. Installieren Sie den GuardDuty Security Agent mit dem folgenden Befehl:
```
sudo dpkg -i amazon-guardduty-agent-1.9.2.amd64.deb
```
1. Überprüfen Sie, ob die GuardDuty Agent-Installation fehlerfrei ist. Weitere Informationen zu den Schritten finden Sie unter[Der Installationsstatus des GuardDuty Security Agents wird überprüft](#validate-ec2-gdu-agent-installation-healthy).
------
## Fehler: Nicht genügend Arbeitsspeicher
Wenn bei der manuellen Installation oder Aktualisierung des GuardDuty Security Agents für Amazon EC2 ein `out-of-memory` Fehler auftritt, finden Sie weitere Informationen unter[Behebung eines Fehlers wegen unzureichenden Speichers](troubleshooting-guardduty-runtime-monitoring.md#troubleshoot-ec2-cpu-out-of-memory-error).
## Der Installationsstatus des GuardDuty Security Agents wird überprüft
Nachdem Sie die Schritte zur Installation des GuardDuty Security Agents ausgeführt haben, überprüfen Sie mit den folgenden Schritten den Status des Agents:
**Um zu überprüfen, ob der GuardDuty Security Agent fehlerfrei ist**
1. Stellen Sie [von Linux oder macOS aus eine Connect mit SSH](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-ssh.html) her.
1. Führen Sie den folgenden Befehl aus, um den Status des GuardDuty Security Agents zu überprüfen:
```
sudo systemctl status amazon-guardduty-agent
```
Wenn Sie die Installationsprotokolle des Security Agents einsehen möchten, finden Sie sie unter`/var/log/amzn-guardduty-agent/`.
Um die Protokolle einzusehen, tun Sie dies`sudo journalctl -u amazon-guardduty-agent`.
# Manuelles Aktualisieren des GuardDuty Security Agents für die Amazon EC2 EC2-Instance
GuardDuty veröffentlicht Updates für die Security Agent-Versionen. Wenn Sie den Security Agent manuell verwalten, sind Sie dafür verantwortlich, den Agenten für Ihre Amazon EC2 EC2-Instances zu aktualisieren. Informationen zu neuen Agentenversionen finden Sie unter [GuardDuty Release-Versionen des Security Agents](runtime-monitoring-agent-release-history.md) Für Amazon EC2 EC2-Instances. Informationen zum Erhalt von Benachrichtigungen über die Veröffentlichung einer neuen Agentenversion finden Sie unter[Amazon GuardDuty SNS SNS-Ankündigungen abonnieren](guardduty_sns.md).
**Um den Security Agent für die Amazon EC2 EC2-Instance manuell zu aktualisieren**
Der Vorgang zur Aktualisierung des Security Agents entspricht der Installation des Security Agents. Abhängig von der Methode, mit der Sie den Agenten installiert haben, können Sie die Schritte unter [Manuelles Installieren des Security Agents](installing-gdu-security-agent-ec2-manually.md) für Amazon EC2 EC2-Instances ausführen.
Wenn Sie [Methode 1 — Mit verwenden verwenden AWS Systems Manager](https://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-ec2-manually.html#manage-ssm-ec2-instance-runtime-monitoring), können Sie den Security Agent mit dem **Befehl Run** aktualisieren. Verwenden Sie die Agent-Version, auf die Sie aktualisieren möchten.
Wenn Sie [Methode 2 — Mithilfe von Linux-Paketmanagern](https://docs.aws.amazon.com/guardduty/latest/ug/managing-gdu-agent-ec2-manually.html#heading:r2l:) verwenden, können Sie die im [Manuelles Installieren des Security Agents](installing-gdu-security-agent-ec2-manually.md) Abschnitt angegebenen Skripts verwenden. Die Skripts enthalten bereits die neueste Agent-Release-Version. Informationen zu kürzlich veröffentlichten Agentenversionen finden Sie unter[GuardDuty Security-Agent-Versionen für Amazon EC2 EC2-Instances](runtime-monitoring-agent-release-history.md#ec2-gdu-agent-release-history).
Nachdem Sie den Security Agent aktualisiert haben, können Sie den Installationsstatus anhand der Protokolle überprüfen. Weitere Informationen finden Sie unter [Der Installationsstatus des GuardDuty Security Agents wird überprüft](installing-gdu-security-agent-ec2-manually.md#validate-ec2-gdu-agent-installation-healthy).
# Verwaltung eines automatisierten Sicherheitsagenten für Fargate (nur Amazon ECS)
Runtime Monitoring unterstützt die Verwaltung des Security Agents für Ihre Amazon ECS-Cluster (AWS Fargate) nur über GuardDuty. Die manuelle Verwaltung des Security Agents auf Amazon ECS-Clustern wird nicht unterstützt.
Bevor Sie mit den Schritten in diesem Abschnitt fortfahren, stellen Sie sicher, dass Sie die folgenden Punkte beachten[Voraussetzungen für den Support AWS Fargate (nur Amazon ECS)](prereq-runtime-monitoring-ecs-support.md).
Wählen Sie auf der Grundlage von eine bevorzugte Methode aus[Ansätze zur Verwaltung von GuardDuty Sicherheitsagenten in Amazon ECS-Fargate-Ressourcen](how-runtime-monitoring-works-ecs-fargate.md#gdu-runtime-approaches-agent-deployment-ecs-clusters), um den GuardDuty automatisierten Agenten für Ihre Ressourcen zu aktivieren.
**Topics**
## Konfiguration des GuardDuty Agenten für eine Umgebung mit mehreren Konten
In einer Umgebung mit mehreren Konten kann nur das delegierte GuardDuty Administratorkonto die automatische Agentenkonfiguration für die Mitgliedskonten aktivieren oder deaktivieren und die automatische Agentenkonfiguration für Amazon ECS-Cluster verwalten, die zu den Mitgliedskonten in ihrer Organisation gehören. Ein GuardDuty Mitgliedskonto kann diese Konfiguration nicht ändern. Das delegierte GuardDuty Administratorkonto verwaltet seine Mitgliedskonten mithilfe von AWS Organizations. Weitere Informationen zu Umgebungen mit mehreren Konten finden Sie unter [Verwaltung mehrerer Konten](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html) in. GuardDuty
### Aktivierung der automatisierten Agentenkonfiguration für ein delegiertes Administratorkonto GuardDuty
------
#### [ Manage for all Amazon ECS clusters (account level) ]
Wenn Sie für Runtime Monitoring die Option **Für alle Konten aktivieren** ausgewählt haben, stehen Ihnen die folgenden Optionen zur Verfügung:
+ Wählen Sie im Abschnitt Automatisierte Agentenkonfiguration die Option **Für alle Konten aktivieren** aus. GuardDuty wird den Security Agent für alle Amazon ECS-Aufgaben bereitstellen und verwalten, die gestartet werden.
+ Wählen Sie **Konten manuell konfigurieren**.
Wenn Sie im Bereich Runtime Monitoring die Option **Konten manuell konfigurieren** ausgewählt haben, gehen Sie wie folgt vor:
1. Wählen Sie im Abschnitt Automatisierte Agentenkonfiguration die Option **Konten manuell konfigurieren** aus.
1. Wählen Sie im Abschnitt **Delegiertes GuardDuty Administratorkonto (dieses Konto)** die Option **Aktivieren** aus.
Wählen Sie **Speichern**.
Wenn Sie Aufgaben überwachen GuardDuty möchten, die Teil eines Dienstes sind, ist eine neue Dienstbereitstellung erforderlich, nachdem Sie Runtime Monitoring aktiviert haben. Wenn die letzte Bereitstellung für einen bestimmten ECS-Service gestartet wurde, bevor Sie Runtime Monitoring aktiviert haben, können Sie den Dienst entweder neu starten oder den Dienst aktualisieren, indem `forceNewDeployment` Sie
Schritte zur Aktualisierung des Dienstes finden Sie in den folgenden Ressourcen:
+ [Aktualisierung eines Amazon ECS-Service mithilfe der Konsole](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) im *Amazon Elastic Container Service Developer Guide*.
+ [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)in der *Amazon Elastic Container Service API-Referenz*.
+ [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in der *AWS CLI Befehlsreferenz*.
------
#### [ Manage for all Amazon ECS clusters but exclude some of the clusters (cluster level) ]
1. Fügen Sie diesem Amazon ECS-Cluster ein Tag mit dem Schlüssel-Wert-Paar als `GuardDutyManaged` - hinzu. `false`
1. Verhindern Sie die Änderung von Tags, außer durch vertrauenswürdige Entitäten. Die im *AWS Organizations Benutzerhandbuch unter [Verhindern, dass Tags nicht durch autorisierte Prinzipien geändert](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) werden, beschriebene Richtlinie wurde dahingehend* geändert, dass sie hier gilt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
1. Öffnen Sie die GuardDuty Konsole unter [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. Wählen Sie im Navigationsbereich **Runtime Monitoring** aus.
1.
**Anmerkung**
Fügen Sie Ihren Amazon ECS-Clustern immer das Ausschluss-Tag hinzu, bevor Sie die automatische Agentenkonfiguration für Ihr Konto aktivieren. Andernfalls wird der GuardDuty Sidecar-Container an alle Container in den Amazon ECS-Aufgaben angehängt, die gestartet werden.
Wählen Sie auf der Registerkarte **Konfiguration** in der **automatisierten Agentenkonfiguration** die Option **Aktivieren** aus.
Für die Amazon ECS-Cluster, die nicht ausgeschlossen wurden, GuardDuty wird die Bereitstellung des Security Agents im Sidecar-Container verwaltet.
1. Wählen Sie **Speichern**.
1. Wenn Sie Aufgaben überwachen GuardDuty möchten, die Teil eines Service sind, ist nach der Aktivierung von Runtime Monitoring eine neue Servicebereitstellung erforderlich. Wenn die letzte Bereitstellung für einen bestimmten ECS-Service gestartet wurde, bevor Sie Runtime Monitoring aktiviert haben, können Sie den Dienst entweder neu starten oder den Dienst aktualisieren, indem `forceNewDeployment` Sie
Schritte zur Aktualisierung des Dienstes finden Sie in den folgenden Ressourcen:
+ [Aktualisierung eines Amazon ECS-Service mithilfe der Konsole](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) im *Amazon Elastic Container Service Developer Guide*.
+ [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)in der *Amazon Elastic Container Service API-Referenz*.
+ [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in der *AWS CLI Befehlsreferenz*.
------
#### [ Manage for selective (inclusion only) Amazon ECS clusters (cluster level) ]
1. Fügen Sie einem Amazon ECS-Cluster, für den Sie alle Aufgaben einbeziehen möchten, ein Tag hinzu. Das Schlüssel-Wert-Paar muss - sein. `GuardDutyManaged` `true`
1. Verhindern Sie die Änderung dieser Tags, außer durch vertrauenswürdige Entitäten. Die im *AWS Organizations Benutzerhandbuch unter [Verhindern, dass Tags nicht durch autorisierte Prinzipien geändert](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) werden, beschriebene Richtlinie wurde dahingehend* geändert, dass sie hier gilt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
**Anmerkung**
Wenn Sie Inclusion-Tags für Ihre Amazon ECS-Cluster verwenden, müssen Sie den GuardDuty Agenten nicht explizit über die automatische Agentenkonfiguration aktivieren.
1. Wenn Sie Aufgaben überwachen GuardDuty möchten, die Teil eines Service sind, ist nach der Aktivierung von Runtime Monitoring eine neue Servicebereitstellung erforderlich. Wenn die letzte Bereitstellung für einen bestimmten ECS-Service gestartet wurde, bevor Sie Runtime Monitoring aktiviert haben, können Sie den Dienst entweder neu starten oder den Dienst aktualisieren, indem `forceNewDeployment` Sie
Schritte zur Aktualisierung des Dienstes finden Sie in den folgenden Ressourcen:
+ [Aktualisierung eines Amazon ECS-Service mithilfe der Konsole](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) im *Amazon Elastic Container Service Developer Guide*.
+ [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)in der *Amazon Elastic Container Service API-Referenz*.
+ [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in der *AWS CLI Befehlsreferenz*.
------
### Automatische Aktivierung für alle Mitgliedskonten
------
#### [ Manage for all Amazon ECS clusters (account level) ]
Bei den folgenden Schritten wird davon ausgegangen, dass Sie im Abschnitt Runtime Monitoring die Option **Für alle Konten aktivieren** ausgewählt haben.
1. Wählen Sie im Abschnitt Automatisierte Agentenkonfiguration die Option **Für alle Konten aktivieren** aus. GuardDuty wird den Security Agent für alle Amazon ECS-Aufgaben bereitstellen und verwalten, die gestartet werden.
1. Wählen Sie **Speichern**.
1. Wenn Sie Aufgaben überwachen GuardDuty möchten, die Teil eines Service sind, ist nach der Aktivierung von Runtime Monitoring eine neue Servicebereitstellung erforderlich. Wenn die letzte Bereitstellung für einen bestimmten ECS-Service gestartet wurde, bevor Sie Runtime Monitoring aktiviert haben, können Sie den Dienst entweder neu starten oder den Dienst aktualisieren, indem `forceNewDeployment` Sie
Schritte zur Aktualisierung des Dienstes finden Sie in den folgenden Ressourcen:
+ [Aktualisierung eines Amazon ECS-Service mithilfe der Konsole](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) im *Amazon Elastic Container Service Developer Guide*.
+ [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)in der *Amazon Elastic Container Service API-Referenz*.
+ [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in der *AWS CLI Befehlsreferenz*.
------
#### [ Manage for all Amazon ECS clusters but exclude some of the clusters (cluster level) ]
1. Fügen Sie diesem Amazon ECS-Cluster ein Tag mit dem Schlüssel-Wert-Paar als `GuardDutyManaged` - hinzu. `false`
1. Verhindern Sie die Änderung von Tags, außer durch vertrauenswürdige Entitäten. Die im *AWS Organizations Benutzerhandbuch unter [Verhindern, dass Tags nicht durch autorisierte Prinzipien geändert](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) werden, beschriebene Richtlinie wurde dahingehend* geändert, dass sie hier gilt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
1. Öffnen Sie die GuardDuty Konsole unter [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. Wählen Sie im Navigationsbereich **Runtime Monitoring** aus.
1.
**Anmerkung**
Fügen Sie Ihren Amazon ECS-Clustern immer das Ausschluss-Tag hinzu, bevor Sie die automatische Agentenkonfiguration für Ihr Konto aktivieren. Andernfalls wird der GuardDuty Sidecar-Container an alle Container in den Amazon ECS-Aufgaben angehängt, die gestartet werden.
**Wählen Sie auf der Registerkarte **Konfiguration** die Option Bearbeiten aus.**
1. Wählen Sie im Abschnitt **Automatisierte Agentenkonfiguration** die Option **Für alle Konten aktivieren**
Für die Amazon ECS-Cluster, die nicht ausgeschlossen wurden, GuardDuty wird die Bereitstellung des Security Agents im Sidecar-Container verwaltet.
1. Wählen Sie **Speichern**.
1. Wenn Sie Aufgaben überwachen GuardDuty möchten, die Teil eines Service sind, ist nach der Aktivierung von Runtime Monitoring eine neue Servicebereitstellung erforderlich. Wenn die letzte Bereitstellung für einen bestimmten ECS-Service gestartet wurde, bevor Sie Runtime Monitoring aktiviert haben, können Sie den Dienst entweder neu starten oder den Dienst aktualisieren, indem `forceNewDeployment` Sie
Schritte zur Aktualisierung des Dienstes finden Sie in den folgenden Ressourcen:
+ [Aktualisierung eines Amazon ECS-Service mithilfe der Konsole](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) im *Amazon Elastic Container Service Developer Guide*.
+ [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)in der *Amazon Elastic Container Service API-Referenz*.
+ [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in der *AWS CLI Befehlsreferenz*.
------
#### [ Manage for selective (inclusion-only) Amazon ECS clusters (cluster level) ]
Unabhängig davon, wie Sie Runtime Monitoring aktivieren, helfen Ihnen die folgenden Schritte dabei, ausgewählte Amazon ECS Fargate-Aufgaben für alle Mitgliedskonten in Ihrer Organisation zu überwachen.
1. Aktivieren Sie im Abschnitt Automatisierte Agentenkonfiguration keine Konfiguration. Behalten Sie die Runtime Monitoring-Konfiguration bei, die Sie im vorherigen Schritt ausgewählt haben.
1. Wählen Sie **Speichern**.
1. Verhindern Sie die Änderung dieser Tags, außer durch vertrauenswürdige Entitäten. Die im *AWS Organizations Benutzerhandbuch unter [Verhindern, dass Tags nicht durch autorisierte Prinzipien geändert](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) werden, beschriebene Richtlinie wurde dahingehend* geändert, dass sie hier gilt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
**Anmerkung**
Wenn Sie Inclusion-Tags für Ihre Amazon ECS-Cluster verwenden, müssen Sie die **automatische Verwaltung der GuardDuty Agenten** nicht explizit aktivieren.
1. Wenn Sie Aufgaben überwachen GuardDuty möchten, die Teil eines Service sind, ist eine neue Servicebereitstellung erforderlich, nachdem Sie Runtime Monitoring aktiviert haben. Wenn die letzte Bereitstellung für einen bestimmten ECS-Service gestartet wurde, bevor Sie Runtime Monitoring aktiviert haben, können Sie den Dienst entweder neu starten oder den Dienst aktualisieren, indem `forceNewDeployment` Sie
Schritte zur Aktualisierung des Dienstes finden Sie in den folgenden Ressourcen:
+ [Aktualisierung eines Amazon ECS-Service mithilfe der Konsole](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) im *Amazon Elastic Container Service Developer Guide*.
+ [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)in der *Amazon Elastic Container Service API-Referenz*.
+ [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in der *AWS CLI Befehlsreferenz*.
------
### Aktivierung der automatisierten Agentenkonfiguration für bestehende aktive Mitgliedskonten
------
#### [ Manage for all Amazon ECS clusters (account level) ]
1. Auf der Seite Runtime Monitoring können Sie auf der Registerkarte **Konfiguration** den aktuellen Status der automatisierten Agentenkonfiguration einsehen.
1. Wählen Sie im Bereich Automatisierte Agentenkonfiguration im Abschnitt **Aktive Mitgliedskonten** die Option **Aktionen** aus.
1. Wählen Sie bei **Aktionen** die Option **Aktivieren für alle vorhandenen aktiven Mitgliedskonten**.
1. Wählen Sie **Bestätigen** aus.
1. Wenn Sie Aufgaben überwachen GuardDuty möchten, die Teil eines Dienstes sind, ist eine neue Dienstbereitstellung erforderlich, nachdem Sie Runtime Monitoring aktiviert haben. Wenn die letzte Bereitstellung für einen bestimmten ECS-Service gestartet wurde, bevor Sie Runtime Monitoring aktiviert haben, können Sie den Dienst entweder neu starten oder den Dienst aktualisieren, indem `forceNewDeployment` Sie
Schritte zur Aktualisierung des Dienstes finden Sie in den folgenden Ressourcen:
+ [Aktualisierung eines Amazon ECS-Service mithilfe der Konsole](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) im *Amazon Elastic Container Service Developer Guide*.
+ [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)in der *Amazon Elastic Container Service API-Referenz*.
+ [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in der *AWS CLI Befehlsreferenz*.
------
#### [ Manage for all Amazon ECS clusters but exclude some of the clusters (cluster level) ]
1. Fügen Sie diesem Amazon ECS-Cluster ein Tag mit dem Schlüssel-Wert-Paar als `GuardDutyManaged` - hinzu. `false`
1. Verhindern Sie die Änderung von Tags, außer durch vertrauenswürdige Entitäten. Die im *AWS Organizations Benutzerhandbuch unter [Verhindern, dass Tags nicht durch autorisierte Prinzipien geändert](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) werden, beschriebene Richtlinie wurde dahingehend* geändert, dass sie hier gilt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
1. Öffnen Sie die GuardDuty Konsole unter [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. Wählen Sie im Navigationsbereich **Runtime Monitoring** aus.
1.
**Anmerkung**
Fügen Sie Ihren Amazon ECS-Clustern immer das Ausschluss-Tag hinzu, bevor Sie die automatische Agentenkonfiguration für Ihr Konto aktivieren. Andernfalls wird der GuardDuty Sidecar-Container an alle Container in den Amazon ECS-Aufgaben angehängt, die gestartet werden.
**Wählen Sie auf der Registerkarte **Konfiguration** im Abschnitt Automatisierte Agentenkonfiguration unter **Aktive Mitgliedskonten** die Option Aktionen aus.**
1. Wählen Sie bei **Aktionen** die Option **Aktivieren für alle vorhandenen aktiven Mitgliedskonten**.
Für die Amazon ECS-Cluster, die nicht ausgeschlossen wurden, GuardDuty wird die Bereitstellung des Security Agents im Sidecar-Container verwaltet.
1. Wählen Sie **Bestätigen** aus.
1. Wenn Sie Aufgaben überwachen GuardDuty möchten, die Teil eines Service sind, ist nach der Aktivierung von Runtime Monitoring eine neue Servicebereitstellung erforderlich. Wenn die letzte Bereitstellung für einen bestimmten ECS-Service gestartet wurde, bevor Sie Runtime Monitoring aktiviert haben, können Sie den Dienst entweder neu starten oder den Dienst aktualisieren, indem `forceNewDeployment` Sie
Schritte zur Aktualisierung des Dienstes finden Sie in den folgenden Ressourcen:
+ [Aktualisierung eines Amazon ECS-Service mithilfe der Konsole](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) im *Amazon Elastic Container Service Developer Guide*.
+ [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)in der *Amazon Elastic Container Service API-Referenz*.
+ [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in der *AWS CLI Befehlsreferenz*.
------
#### [ Manage for selective (inclusion only) Amazon ECS clusters (cluster level) ]
1. Fügen Sie einem Amazon ECS-Cluster, für den Sie alle Aufgaben einbeziehen möchten, ein Tag hinzu. Das Schlüssel-Wert-Paar muss - sein. `GuardDutyManaged` `true`
1. Verhindern Sie die Änderung dieser Tags, außer durch vertrauenswürdige Entitäten. Die im *AWS Organizations Benutzerhandbuch unter [Verhindern, dass Tags nicht durch autorisierte Prinzipien geändert](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) werden, beschriebene Richtlinie wurde dahingehend* geändert, dass sie hier gilt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
**Anmerkung**
Wenn Sie Inclusion-Tags für Ihre Amazon ECS-Cluster verwenden, müssen Sie die **automatische Agentenkonfiguration** nicht explizit aktivieren.
1. Wenn Sie Aufgaben überwachen GuardDuty möchten, die Teil eines Service sind, ist eine neue Servicebereitstellung erforderlich, nachdem Sie Runtime Monitoring aktiviert haben. Wenn die letzte Bereitstellung für einen bestimmten ECS-Service gestartet wurde, bevor Sie Runtime Monitoring aktiviert haben, können Sie den Dienst entweder neu starten oder den Dienst aktualisieren, indem `forceNewDeployment` Sie
Schritte zur Aktualisierung des Dienstes finden Sie in den folgenden Ressourcen:
+ [Aktualisierung eines Amazon ECS-Service mithilfe der Konsole](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) im *Amazon Elastic Container Service Developer Guide*.
+ [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)in der *Amazon Elastic Container Service API-Referenz*.
+ [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in der *AWS CLI Befehlsreferenz*.
------
### Automatische Aktivierung der automatischen Agentenkonfiguration für neue Mitglieder
------
#### [ Manage for all Amazon ECS clusters (account level) ]
1. Wählen Sie auf der Seite Runtime Monitoring die Option **Bearbeiten** aus, um die bestehende Konfiguration zu aktualisieren.
1. Wählen Sie im Abschnitt Automatisierte Agentenkonfiguration die Option **Automatisch für neue Mitgliedskonten aktivieren** aus.
1. Wählen Sie **Speichern**.
1. Wenn Sie Aufgaben überwachen GuardDuty möchten, die Teil eines Dienstes sind, ist eine neue Dienstbereitstellung erforderlich, nachdem Sie Runtime Monitoring aktiviert haben. Wenn die letzte Bereitstellung für einen bestimmten ECS-Service gestartet wurde, bevor Sie Runtime Monitoring aktiviert haben, können Sie den Dienst entweder neu starten oder den Dienst aktualisieren, indem `forceNewDeployment` Sie
Schritte zur Aktualisierung des Dienstes finden Sie in den folgenden Ressourcen:
+ [Aktualisierung eines Amazon ECS-Service mithilfe der Konsole](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) im *Amazon Elastic Container Service Developer Guide*.
+ [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)in der *Amazon Elastic Container Service API-Referenz*.
+ [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in der *AWS CLI Befehlsreferenz*.
------
#### [ Manage for all Amazon ECS clusters but exclude some of the clusters (cluster level) ]
1. Fügen Sie diesem Amazon ECS-Cluster ein Tag mit dem Schlüssel-Wert-Paar als `GuardDutyManaged` - hinzu. `false`
1. Verhindern Sie die Änderung von Tags, außer durch vertrauenswürdige Entitäten. Die im *AWS Organizations Benutzerhandbuch unter [Verhindern, dass Tags nicht durch autorisierte Prinzipien geändert](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) werden, beschriebene Richtlinie wurde dahingehend* geändert, dass sie hier gilt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
1. Öffnen Sie die GuardDuty Konsole unter [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. Wählen Sie im Navigationsbereich **Runtime Monitoring** aus.
1.
**Anmerkung**
Fügen Sie Ihren Amazon ECS-Clustern immer das Ausschluss-Tag hinzu, bevor Sie die automatische Agentenkonfiguration für Ihr Konto aktivieren. Andernfalls wird der GuardDuty Sidecar-Container an alle Container in den Amazon ECS-Aufgaben angehängt, die gestartet werden.
Wählen Sie auf der Registerkarte **Konfiguration** im Abschnitt ****Automatisierte Agentenkonfiguration die Option Automatisch** für neue Mitgliedskonten aktivieren** aus.
Für die Amazon ECS-Cluster, die nicht ausgeschlossen wurden, GuardDuty wird die Bereitstellung des Security Agents im Sidecar-Container verwaltet.
1. Wählen Sie **Speichern**.
1. Wenn Sie Aufgaben überwachen GuardDuty möchten, die Teil eines Service sind, ist nach der Aktivierung von Runtime Monitoring eine neue Servicebereitstellung erforderlich. Wenn die letzte Bereitstellung für einen bestimmten ECS-Service gestartet wurde, bevor Sie Runtime Monitoring aktiviert haben, können Sie den Dienst entweder neu starten oder den Dienst aktualisieren, indem `forceNewDeployment` Sie
Schritte zur Aktualisierung des Dienstes finden Sie in den folgenden Ressourcen:
+ [Aktualisierung eines Amazon ECS-Service mithilfe der Konsole](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) im *Amazon Elastic Container Service Developer Guide*.
+ [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)in der *Amazon Elastic Container Service API-Referenz*.
+ [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in der *AWS CLI Befehlsreferenz*.
------
#### [ Manage for selective (inclusion only) Amazon ECS clusters (cluster level) ]
1. Fügen Sie einem Amazon ECS-Cluster, für den Sie alle Aufgaben einbeziehen möchten, ein Tag hinzu. Das Schlüssel-Wert-Paar muss - sein. `GuardDutyManaged` `true`
1. Verhindern Sie die Änderung dieser Tags, außer durch vertrauenswürdige Entitäten. Die im *AWS Organizations Benutzerhandbuch unter [Verhindern, dass Tags nicht durch autorisierte Prinzipien geändert](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) werden, beschriebene Richtlinie wurde dahingehend* geändert, dass sie hier gilt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
**Anmerkung**
Wenn Sie Inclusion-Tags für Ihre Amazon ECS-Cluster verwenden, müssen Sie die **automatische Agentenkonfiguration** nicht explizit aktivieren.
1. Wenn Sie Aufgaben überwachen GuardDuty möchten, die Teil eines Service sind, ist eine neue Servicebereitstellung erforderlich, nachdem Sie Runtime Monitoring aktiviert haben. Wenn die letzte Bereitstellung für einen bestimmten ECS-Service gestartet wurde, bevor Sie Runtime Monitoring aktiviert haben, können Sie den Dienst entweder neu starten oder den Dienst aktualisieren, indem `forceNewDeployment` Sie
Schritte zur Aktualisierung des Dienstes finden Sie in den folgenden Ressourcen:
+ [Aktualisierung eines Amazon ECS-Service mithilfe der Konsole](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) im *Amazon Elastic Container Service Developer Guide*.
+ [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)in der *Amazon Elastic Container Service API-Referenz*.
+ [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in der *AWS CLI Befehlsreferenz*.
------
### Selektives Aktivieren der automatisierten Agentenkonfiguration für aktive Mitgliedskonten
------
#### [ Manage for all Amazon ECS (account level) ]
1. Wählen Sie auf der Seite Konten die Konten aus, für die Sie die Runtime Monitoring-Automated Agent-Konfiguration (ECS-Fargate) aktivieren möchten. Sie können mehrere Konten auswählen. Stellen Sie sicher, dass die Konten, die Sie in diesem Schritt auswählen, bereits für Runtime Monitoring aktiviert sind.
1. Wählen **Sie unter Schutzpläne bearbeiten** die entsprechende Option aus, um die **Runtime Monitoring-Automated Agent-Konfiguration (**ECS-Fargate) zu aktivieren.
1. Wählen Sie **Bestätigen** aus.
1. Wenn Sie Aufgaben überwachen GuardDuty möchten, die Teil eines Dienstes sind, ist nach der Aktivierung von Runtime Monitoring eine neue Servicebereitstellung erforderlich. Wenn die letzte Bereitstellung für einen bestimmten ECS-Service gestartet wurde, bevor Sie Runtime Monitoring aktiviert haben, können Sie den Dienst entweder neu starten oder den Dienst aktualisieren, indem `forceNewDeployment` Sie
Schritte zur Aktualisierung des Dienstes finden Sie in den folgenden Ressourcen:
+ [Aktualisierung eines Amazon ECS-Service mithilfe der Konsole](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) im *Amazon Elastic Container Service Developer Guide*.
+ [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)in der *Amazon Elastic Container Service API-Referenz*.
+ [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in der *AWS CLI Befehlsreferenz*.
------
#### [ Manage for all Amazon ECS clusters but exclude some of the clusters (cluster level) ]
1. Fügen Sie diesem Amazon ECS-Cluster ein Tag mit dem Schlüssel-Wert-Paar als `GuardDutyManaged` - hinzu. `false`
1. Verhindern Sie die Änderung von Tags, außer durch vertrauenswürdige Entitäten. Die im *AWS Organizations Benutzerhandbuch unter [Verhindern, dass Tags nicht durch autorisierte Prinzipien geändert](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) werden, beschriebene Richtlinie wurde dahingehend* geändert, dass sie hier gilt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
1. Öffnen Sie die GuardDuty Konsole unter [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. Wählen Sie im Navigationsbereich **Runtime Monitoring** aus.
1.
**Anmerkung**
Fügen Sie Ihren Amazon ECS-Clustern immer das Ausschluss-Tag hinzu, bevor Sie die automatische GuardDuty Agentenverwaltung für Ihr Konto aktivieren. Andernfalls wird der GuardDuty Sidecar-Container an alle Container in den Amazon ECS-Aufgaben angehängt, die gestartet werden.
Wählen Sie auf der Seite Konten die Konten aus, für die Sie die Runtime Monitoring-Automated Agent-Konfiguration (ECS-Fargate) aktivieren möchten. Sie können mehrere Konten auswählen. Stellen Sie sicher, dass die Konten, die Sie in diesem Schritt auswählen, bereits für Runtime Monitoring aktiviert sind.
Für die Amazon ECS-Cluster, die nicht ausgeschlossen wurden, GuardDuty wird die Bereitstellung des Security Agents im Sidecar-Container verwaltet.
1. Wählen **Sie unter Schutzpläne bearbeiten** die entsprechende Option aus, um die **Runtime Monitoring-Automated Agent-Konfiguration (**ECS-Fargate) zu aktivieren.
1. Wählen Sie **Speichern**.
1. Wenn Sie Aufgaben überwachen GuardDuty möchten, die Teil eines Dienstes sind, ist nach der Aktivierung von Runtime Monitoring eine neue Servicebereitstellung erforderlich. Wenn die letzte Bereitstellung für einen bestimmten ECS-Service gestartet wurde, bevor Sie Runtime Monitoring aktiviert haben, können Sie den Dienst entweder neu starten oder den Dienst aktualisieren, indem `forceNewDeployment` Sie
Schritte zur Aktualisierung des Dienstes finden Sie in den folgenden Ressourcen:
+ [Aktualisierung eines Amazon ECS-Service mithilfe der Konsole](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) im *Amazon Elastic Container Service Developer Guide*.
+ [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)in der *Amazon Elastic Container Service API-Referenz*.
+ [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in der *AWS CLI Befehlsreferenz*.
------
#### [ Manage for selective (inclusion only) Amazon ECS clusters (cluster level) ]
1. Stellen Sie sicher, dass Sie die **automatische Agentenkonfiguration** (oder **Runtime Monitoring-Automated Agent-Konfiguration (ECS-Fargate))** nicht für die ausgewählten Konten aktivieren, die über die Amazon ECS-Cluster verfügen, die Sie überwachen möchten.
1. Fügen Sie einem Amazon ECS-Cluster, für den Sie alle Aufgaben einbeziehen möchten, ein Tag hinzu. Das Schlüssel-Wert-Paar muss - sein. `GuardDutyManaged` `true`
1. Verhindern Sie die Änderung dieser Tags, außer durch vertrauenswürdige Entitäten. Die im *AWS Organizations Benutzerhandbuch unter [Verhindern, dass Tags nicht durch autorisierte Prinzipien geändert](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) werden, beschriebene Richtlinie wurde dahingehend* geändert, dass sie hier gilt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
**Anmerkung**
Wenn Sie Inclusion-Tags für Ihre Amazon ECS-Cluster verwenden, müssen Sie die **automatische Agentenkonfiguration** nicht explizit aktivieren.
1. Wenn Sie Aufgaben überwachen GuardDuty möchten, die Teil eines Service sind, ist eine neue Servicebereitstellung erforderlich, nachdem Sie Runtime Monitoring aktiviert haben. Wenn die letzte Bereitstellung für einen bestimmten ECS-Service gestartet wurde, bevor Sie Runtime Monitoring aktiviert haben, können Sie den Dienst entweder neu starten oder den Dienst aktualisieren, indem `forceNewDeployment` Sie
Schritte zur Aktualisierung des Dienstes finden Sie in den folgenden Ressourcen:
+ [Aktualisierung eines Amazon ECS-Service mithilfe der Konsole](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) im *Amazon Elastic Container Service Developer Guide*.
+ [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)in der *Amazon Elastic Container Service API-Referenz*.
+ [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in der *AWS CLI Befehlsreferenz*.
------
## Den GuardDuty Agenten für ein eigenständiges Konto konfigurieren
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die GuardDuty Konsole unter [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. Wählen Sie im Navigationsbereich **Runtime Monitoring** aus.
1. Gehen Sie auf der Registerkarte **Konfiguration** wie folgt vor:
1.
**Zur Verwaltung der automatisierten Agentenkonfiguration für alle Amazon ECS-Cluster (Kontoebene)**
Wählen Sie im Abschnitt **Automatisierte Agentenkonfiguration** für **AWS Fargate (nur ECS)** die Option **Aktivieren** aus. Wenn eine neue Fargate Amazon ECS-Task gestartet GuardDuty wird, wird die Bereitstellung des Sicherheitsagenten verwaltet.
1. Wählen Sie **Speichern**.
1.
**Verwaltung der automatisierten Agentenkonfiguration durch Ausschluss einiger Amazon ECS-Cluster (Cluster-Ebene)**
1. Fügen Sie dem Amazon ECS-Cluster, für den Sie alle Aufgaben ausschließen möchten, ein Tag hinzu. Das Schlüssel-Wert-Paar muss - sein. `GuardDutyManaged` `false`
1. Verhindern Sie die Änderung dieser Tags, außer durch vertrauenswürdige Entitäten. Die im *AWS Organizations Benutzerhandbuch unter [Verhindern, dass Tags nicht durch autorisierte Prinzipien geändert](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) werden, beschriebene Richtlinie wurde dahingehend* geändert, dass sie hier gilt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
1. Wählen Sie auf der Registerkarte **Konfiguration** im Abschnitt **Automatisierte Agentenkonfiguration** die Option **Aktivieren** aus.
**Anmerkung**
Fügen Sie Ihrem Amazon ECS-Cluster immer das Ausschluss-Tag hinzu, bevor Sie die automatische GuardDuty Agentenverwaltung für Ihr Konto aktivieren. Andernfalls wird der Security Agent bei allen Aufgaben eingesetzt, die innerhalb des entsprechenden Amazon ECS-Clusters gestartet werden.
Für die Amazon ECS-Cluster, die nicht ausgeschlossen wurden, GuardDuty wird die Bereitstellung des Security Agents im Sidecar-Container verwaltet.
1. Wählen Sie **Speichern**.
1.
**Verwaltung der automatisierten Agentenkonfiguration durch Einbeziehung einiger Amazon ECS-Cluster (Cluster-Ebene)**
1. Fügen Sie einem Amazon ECS-Cluster, für den Sie alle Aufgaben einbeziehen möchten, ein Tag hinzu. Das Schlüssel-Wert-Paar muss - sein. `GuardDutyManaged` `true`
1. Verhindern Sie die Änderung dieser Tags, außer durch vertrauenswürdige Entitäten. Die im *AWS Organizations Benutzerhandbuch unter [Verhindern, dass Tags nicht durch autorisierte Prinzipien geändert](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin) werden, beschriebene Richtlinie wurde dahingehend* geändert, dass sie hier gilt.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyModifyTagsIfResAuthzTagAndPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"ecs:ResourceTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"ecs:ResourceTag/GuardDutyManaged": false
}
}
},
{
"Sid": "DenyModifyResAuthzTagIfPrinTagDontMatch",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:RequestTag/GuardDutyManaged": "${aws:PrincipalTag/GuardDutyManaged}",
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"ForAnyValue:StringEquals": {
"aws:TagKeys": [
"GuardDutyManaged"
]
}
}
},
{
"Sid": "DenyModifyTagsIfPrinTagNotExists",
"Effect": "Deny",
"Action": [
"ecs:TagResource",
"ecs:UntagResource"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEquals": {
"aws:PrincipalArn": "arn:aws:iam::123456789012:role/org-admins/iam-admin"
},
"Null": {
"aws:PrincipalTag/GuardDutyManaged": true
}
}
}
]
}
```
------
1. Wenn Sie Aufgaben überwachen GuardDuty möchten, die Teil eines Dienstes sind, ist eine neue Dienstbereitstellung erforderlich, nachdem Sie Runtime Monitoring aktiviert haben. Wenn die letzte Bereitstellung für einen bestimmten ECS-Service gestartet wurde, bevor Sie Runtime Monitoring aktiviert haben, können Sie den Dienst entweder neu starten oder den Dienst aktualisieren, indem `forceNewDeployment` Sie
Schritte zur Aktualisierung des Dienstes finden Sie in den folgenden Ressourcen:
+ [Aktualisierung eines Amazon ECS-Service mithilfe der Konsole](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/update-service-console-v2.html) im *Amazon Elastic Container Service Developer Guide*.
+ [UpdateService](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_UpdateService.html)in der *Amazon Elastic Container Service API-Referenz*.
+ [update-service](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ecs/update-service.html) in der *AWS CLI Befehlsreferenz*.
# Automatisches Verwalten des Security Agents für Amazon EKS-Ressourcen
Runtime Monitoring unterstützt die Aktivierung des Security Agents durch GuardDuty automatische Konfiguration und manuell. In diesem Abschnitt werden die Schritte zur Aktivierung der automatisierten Agentenkonfiguration für Amazon EKS-Cluster beschrieben.
Bevor Sie fortfahren, stellen Sie sicher, dass Sie die befolgt haben[Voraussetzungen für die Unterstützung von Amazon EKS-Clustern](prereq-runtime-monitoring-eks-support.md).
Wählen Sie die Schritte in den folgenden Abschnitten entsprechend Ihrer bevorzugten Vorgehensweise aus. [Verwalten Sie den Security Agent über GuardDuty](how-runtime-monitoring-works-eks.md#eks-runtime-using-gdu-agent-management-auto)
## Konfiguration eines automatisierten Agenten für Umgebungen mit mehreren Konten
In Umgebungen mit mehreren Konten kann nur das delegierte GuardDuty Administratorkonto die automatische Agentenkonfiguration für die Mitgliedskonten aktivieren oder deaktivieren und den automatisierten Agenten für die EKS-Cluster verwalten, die zu den Mitgliedskonten in ihrer Organisation gehören. Die GuardDuty Mitgliedskonten können diese Konfiguration nicht von ihren Konten aus ändern. Das delegierte GuardDuty Administratorkonto verwaltet seine Mitgliedskonten mithilfe von AWS Organizations. Weitere Informationen zu Umgebungen mit mehreren Konten finden Sie unter [Verwaltung mehrerer Konten](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html).
### Konfiguration der automatisierten Agentenkonfiguration für das delegierte Administratorkonto GuardDuty
| **Bevorzugter Ansatz zur Verwaltung des GuardDuty Security Agents** | **Schritte** |
| --- | --- |
| Verwalten Sie den Security Agent über GuardDuty (Alle EKS-Cluster überwachen) | Wenn Sie im Bereich Runtime Monitoring die Option **Für alle Konten aktivieren** ausgewählt haben, stehen Ihnen die folgenden Optionen zur Verfügung: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) Wenn Sie im Bereich Runtime Monitoring die Option **Konten manuell konfigurieren** ausgewählt haben, gehen Sie wie folgt vor: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) Wählen Sie **Speichern**. |
| Alle EKS-Cluster überwachen, jedoch einige davon ausschließen (mithilfe des Ausschluss-Tags) | Wählen Sie aus den folgenden Verfahren eines der Szenarien aus, das auf Sie zutrifft. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
| Ausgewählte EKS-Cluster mithilfe von Einschließen-Tags überwachen | Unabhängig davon, wie Sie Runtime Monitoring aktiviert haben, helfen Ihnen die folgenden Schritte bei der Überwachung ausgewählter EKS-Cluster in Ihrem Konto: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
| Den GuardDuty Security Agent manuell verwalten | Unabhängig davon, wie Sie Runtime Monitoring aktiviert haben, können Sie den Security Agent für Ihre EKS-Cluster manuell verwalten. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
### Automatischer Agent für alle Mitgliedskonten automatisch aktivieren
**Anmerkung**
Die Aktualisierung der Konfiguration der Mitgliedskonten kann bis zu 24 Stunden dauern.
| **Bevorzugter Ansatz zur Verwaltung des GuardDuty Security Agents** | **Schritte** |
| --- | --- |
| Verwalten Sie den Security Agent über GuardDuty (Alle EKS-Cluster überwachen) | In diesem Thema geht es darum, Runtime Monitoring für alle Mitgliedskonten zu aktivieren. Daher wird bei den folgenden Schritten davon ausgegangen, dass Sie im Abschnitt Runtime Monitoring die Option **Für alle Konten aktivieren** ausgewählt haben. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
| Alle EKS-Cluster überwachen, jedoch einige davon ausschließen (mithilfe des Ausschluss-Tags) | Wählen Sie aus den folgenden Verfahren eines der Szenarien aus, das auf Sie zutrifft. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
| Ausgewählte EKS-Cluster mithilfe von Einschließen-Tags überwachen | Unabhängig davon, wie Sie Runtime Monitoring aktiviert haben, helfen Ihnen die folgenden Schritte bei der Überwachung ausgewählter EKS-Cluster für alle Mitgliedskonten in Ihrer Organisation: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
| Den GuardDuty Security Agent manuell verwalten | Unabhängig davon, wie Sie Runtime Monitoring aktiviert haben, können Sie den Security Agent für Ihre EKS-Cluster manuell verwalten. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
### Aktivierung des automatisierten Agenten für alle vorhandenen aktiven Mitgliedskonten
**Anmerkung**
Die Aktualisierung der Konfiguration der Mitgliedskonten kann bis zu 24 Stunden dauern.
**Um den GuardDuty Security Agent für bestehende aktive Mitgliedskonten in Ihrem Unternehmen zu verwalten**
+ GuardDuty Um Runtime-Ereignisse von den EKS-Clustern zu empfangen, die zu den bestehenden aktiven Mitgliedskonten in der Organisation gehören, müssen Sie einen bevorzugten Ansatz für die Verwaltung des GuardDuty Security Agents für diese EKS-Cluster wählen. Weitere Informationen zu diesen Ansätzen finden Sie unter [Ansätze zur Verwaltung von GuardDuty Sicherheitsagenten in Amazon EKS-Clustern](how-runtime-monitoring-works-eks.md#eksrunmon-approach-to-monitor-eks-clusters).
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html)
### Automatische Aktivierung der automatischen Agentenkonfiguration für neue Mitglieder
| **Bevorzugter Ansatz zur Verwaltung des GuardDuty Security Agents** | **Schritte** |
| --- | --- |
| Verwalten Sie den Security Agent über GuardDuty (Alle EKS-Cluster überwachen) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
| Alle EKS-Cluster überwachen, jedoch einige davon ausschließen (mithilfe des Ausschluss-Tags) | Wählen Sie aus den folgenden Verfahren eines der Szenarien aus, das auf Sie zutrifft. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
| Ausgewählte EKS-Cluster mithilfe von Einschließen-Tags überwachen | Unabhängig davon, wie Sie Runtime Monitoring aktiviert haben, helfen Ihnen die folgenden Schritte bei der Überwachung ausgewählter EKS-Cluster auf die neuen Mitgliedskonten in Ihrer Organisation. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
| Den GuardDuty Security Agent manuell verwalten | Unabhängig davon, wie Sie Runtime Monitoring aktiviert haben, können Sie den Security Agent für Ihre EKS-Cluster manuell verwalten. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
### Selektives Konfigurieren des automatisierten Agenten für aktive Mitgliedskonten
| **Bevorzugter Ansatz zur Verwaltung des GuardDuty Security Agents** | **Schritte** |
| --- | --- |
| Verwalten Sie den Security Agent über GuardDuty (Alle EKS-Cluster überwachen) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
| Alle EKS-Cluster überwachen, jedoch einige davon ausschließen (mithilfe des Ausschluss-Tags) | Wählen Sie aus den folgenden Verfahren eines der Szenarien aus, das auf Sie zutrifft. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
| Ausgewählte EKS-Cluster mithilfe von Einschließen-Tags überwachen | Unabhängig davon, wie Sie Runtime Monitoring aktiviert haben, helfen Ihnen die folgenden Schritte bei der Überwachung ausgewählter EKS-Cluster, die zu den ausgewählten Konten gehören: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
| Den GuardDuty Security Agent manuell verwalten | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html) |
## Konfiguration des automatisierten Agenten für ein eigenständiges Konto
Ein eigenständiges Konto hat die Entscheidung, einen Schutzplan AWS-Konto in einem bestimmten Bereich zu aktivieren oder zu deaktivieren AWS-Region.
Wenn Ihr Konto über oder über AWS Organizations die Einladungsmethode mit einem GuardDuty Administratorkonto verknüpft ist, gilt dieser Abschnitt nicht für Ihr Konto. Weitere Informationen finden Sie unter [Runtime Monitoring für Umgebungen mit mehreren Konten aktivieren](enable-runtime-monitoring-multiple-acc-env.md).
Nachdem Sie Runtime Monitoring aktiviert haben, stellen Sie sicher, dass Sie den GuardDuty Security Agent durch automatische Konfiguration oder manuelle Installation installieren. Nachdem Sie alle im folgenden Verfahren aufgeführten Schritte ausgeführt haben, stellen Sie sicher, dass Sie den Security Agent installieren.
Je nachdem, ob Sie alle oder ausgewählte Amazon EKS-Ressourcen überwachen möchten, wählen Sie eine bevorzugte Methode und folgen Sie den Schritten in der folgenden Tabelle.
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die GuardDuty Konsole unter [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
1. Wählen Sie im Navigationsbereich **Runtime Monitoring** aus.
1. Wählen Sie auf der Registerkarte **Konfiguration** die Option **Aktivieren** aus, um die automatische Agentenkonfiguration für Ihr Konto zu aktivieren.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/managing-gdu-agent-eks-automatically.html)
# Manuelles Verwalten des Security Agents für den Amazon EKS-Cluster
In diesem Abschnitt wird beschrieben, wie Sie Ihren Amazon EKS-Zusatzagenten (GuardDuty Agenten) verwalten können, nachdem Sie Runtime Monitoring (oder EKS Runtime Monitoring) aktiviert haben. Um Runtime Monitoring verwenden zu können, müssen Sie Runtime Monitoring aktivieren und das Amazon EKS-Add-on konfigurieren`aws-guardduty-agent`. Sie müssen beide Schritte ausführen, um potenzielle Bedrohungen GuardDuty zu erkennen und zu generieren[GuardDuty Runtime Monitoring: Typen finden](findings-runtime-monitoring.md).
Für die manuelle Verwaltung des Agenten müssen Sie als Voraussetzung einen VPC-Endpunkt erstellen. Dies hilft beim GuardDuty Empfang der Runtime-Ereignisse. Danach können Sie den Security Agent so installieren, dass er GuardDuty die Runtime-Ereignisse von den Amazon EKS-Ressourcen empfängt. Wenn eine neue Agentenversion für diese Ressource GuardDuty veröffentlicht wird, können Sie die Agentenversion in Ihrem Konto aktualisieren.
**Topics**
+ [Voraussetzung — Erstellen eines Amazon VPC-Endpunkts](eksrunmon-prereq-deploy-security-agent.md)
+ [Manuelles Installieren des GuardDuty Security Agents auf Amazon EKS-Ressourcen](eksrunmon-deploy-security-agent.md)
+ [Manuelles Aktualisieren des Security Agents für Amazon EKS-Ressourcen](eksrunmon-update-security-agent.md)
# Voraussetzung — Erstellen eines Amazon VPC-Endpunkts
Bevor Sie den GuardDuty Security Agent installieren können, müssen Sie einen Amazon Virtual Private Cloud (Amazon VPC) -Endpunkt erstellen. Dies hilft beim GuardDuty Empfang der Runtime-Ereignisse Ihrer Amazon EKS-Ressourcen.
**Anmerkung**
Für die Nutzung des VPC-Endpunkts fallen keine zusätzlichen Kosten an.
Wählen Sie eine bevorzugte Zugriffsmethode, um einen Amazon VPC-Endpunkt zu erstellen.
------
#### [ Console ]
**So erstellen Sie einen VPC-Endpunkt**
1. Öffnen Sie die Amazon-VPC-Konsole unter [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Wählen Sie im Navigationsmenü unter **Virtual Private Cloud** die Option **Endpunkte**.
1. Klicken Sie auf **Endpunkt erstellen**.
1. Wählen Sie auf der Seite **Endpunkt erstellen** für **Servicekategorie** die Option **Andere Endpunkt-Services**.
1. Geben Sie unter **Servicename** **com.amazonaws.*us-east-1*.guardduty-data** ein.
Stellen Sie sicher, dass Sie *us-east-1* durch die richtige Region ersetzen. Dies muss dieselbe Region sein wie der EKS-Cluster, der zu Ihrer AWS-Konto ID gehört.
1. Wählen Sie **Service verifizieren**.
1. Nachdem der Servicename erfolgreich verifiziert wurde, wählen Sie die **VPC** aus, in der sich Ihr Cluster befindet. Fügen Sie die folgende Richtlinie hinzu, um die Nutzung von VPC-Endpunkten auf das angegebene Konto zu beschränken. Unter Angabe der unter dieser Richtlinie angegebenen Organisations-`Condition` können Sie die folgende Richtlinie aktualisieren, um den Zugriff auf Ihren Endpunkt einzuschränken. Informationen zur Bereitstellung von VPC-Endpunktunterstützung für ein bestimmtes Konto IDs in Ihrer Organisation finden Sie unter[Organization condition to restrict access to your endpoint](#gdu-shared-vpc-endpoint-org).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": "*",
"Resource": "*",
"Effect": "Allow",
"Principal": "*"
},
{
"Condition": {
"StringNotEquals": {
"aws:PrincipalAccount": "111122223333"
}
},
"Action": "*",
"Resource": "*",
"Effect": "Deny",
"Principal": "*"
}
]
}
```
------
Die `aws:PrincipalAccount`-Konto-ID muss mit dem Konto übereinstimmen, das die VPC und den VPC-Endpunkt enthält. Die folgende Liste zeigt, wie Sie den VPC-Endpunkt mit anderen AWS-Konto IDs teilen können:
**Organisationsbedingung , um den Zugriff auf Ihren Endpunkt einzuschränken**
+ Um mehrere Konten für den Zugriff auf den VPC-Endpunkt anzugeben, ersetzen Sie `"aws:PrincipalAccount": "111122223333"` durch Folgendes:
```
"aws:PrincipalAccount": [
"666666666666",
"555555555555"
]
```
+ Um allen Mitgliedern einer Organisation den Zugriff auf den VPC-Endpunkt zu ermöglichen, ersetzen Sie `"aws:PrincipalAccount": "111122223333"` durch Folgendes:
```
"aws:PrincipalOrgID": "o-abcdef0123"
```
+ Um den Zugriff auf eine Ressource auf eine Organisations-ID zu beschränken, fügen Sie Ihre `ResourceOrgID` zur Richtlinie hinzu.
Weitere Informationen finden Sie unter [ResourceOrgID.](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourceorgid)
```
"aws:ResourceOrgID": "o-abcdef0123"
```
1. Wählen Sie unter **Zusätzliche Einstellungen** die Option **DNS-Name aktivieren**.
1. Wählen Sie unter **Subnetze** die Subnetze aus, in denen sich Ihr Cluster befindet.
1. Wählen Sie unter **Sicherheitsgruppen** eine Sicherheitsgruppe aus, für die der eingehende Port 443 von Ihrer VPC (oder Ihrem EKS-Cluster) aktiviert ist. Wenn Sie noch keine Sicherheitsgruppe haben, für die der eingehende Port 443 aktiviert ist, [Erstellen Sie eine Sicherheitsgruppe](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#creating-security-group).
Wenn bei der Einschränkung der eingehenden Berechtigungen für Ihre VPC (oder Instance) ein Problem auftritt, können Sie den eingehenden Port 443 von einer beliebigen IP-Adresse aus verwenden. `(0.0.0.0/0)` GuardDuty Empfiehlt jedoch, IP-Adressen zu verwenden, die dem CIDR-Block für Ihre VPC entsprechen. Weitere Informationen finden Sie unter [VPC CIDR-Blöcke](https://docs.aws.amazon.com//vpc/latest/userguide/vpc-cidr-blocks.html) im *Amazon VPC-Benutzerhandbuch*.
------
#### [ API/CLI ]
**So erstellen Sie einen VPC-Endpunkt**
+ Aufrufen [CreateVpcEndpoint](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateVpcEndpoint.html).
+ Verwenden Sie die folgenden Werte für die Parameter:
+ Geben Sie unter **Servicename** **com.amazonaws.*us-east-1*.guardduty-data** ein.
Stellen Sie sicher, dass Sie es *us-east-1* durch die richtige Region ersetzen. Dies muss dieselbe Region sein wie der EKS-Cluster, der zu Ihrer AWS-Konto ID gehört.
+ Aktivieren Sie für die private DNS-Option [DNSOptions](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DnsOptions.html), indem Sie sie auf setzen`true`.
+ AWS Command Line Interface Näheres dazu finden Sie unter [create-vpc-endpoint](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/create-vpc-endpoint.html).
------
Nachdem Sie die Schritte ausgeführt haben, stellen [Validierung der VPC-Endpunktkonfiguration](validate-vpc-endpoint-config-runtime-monitoring.md) Sie sicher, dass der VPC-Endpunkt korrekt eingerichtet wurde.
# Manuelles Installieren des GuardDuty Security Agents auf Amazon EKS-Ressourcen
In diesem Abschnitt wird beschrieben, wie Sie den GuardDuty Security Agent zum ersten Mal für bestimmte EKS-Cluster bereitstellen können. Bevor Sie mit diesem Abschnitt fortfahren, stellen Sie sicher, dass Sie die Voraussetzungen bereits eingerichtet und Runtime Monitoring für Ihre Konten aktiviert haben. Der GuardDuty Security Agent (EKS-Add-on) funktioniert nicht, wenn Sie Runtime Monitoring nicht aktivieren.
Wählen Sie Ihre bevorzugte Zugriffsmethode, um den GuardDuty Security Agent zum ersten Mal zu installieren.
------
#### [ Console ]
1. Öffnen Sie die Amazon EKS-Konsole unter [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie Ihren **Clusternamen** aus.
1. Wählen Sie die Registerkarte **Add-ons**.
1. Wählen Sie **Weitere Add-Ons erhalten**.
1. **Wählen Sie auf der Seite „Add-Ons** auswählen“ **Amazon GuardDuty EKS Runtime Monitoring** aus.
1. GuardDuty empfiehlt, die neueste und standardmäßige **Agentenversion** zu wählen.
1. Verwenden Sie auf der Seite **Ausgewählte Add-On-Einstellungen konfigurieren** die Standardeinstellungen. Wenn der **Status** Ihres EKS-Add-ons **Aktivierung erfordert** lautet, wählen Sie **Aktivieren** aus GuardDuty. Diese Aktion öffnet die GuardDuty Konsole, in der Sie Runtime Monitoring für Ihre Konten konfigurieren können.
1. Nachdem Sie Runtime Monitoring für Ihre Konten konfiguriert haben, kehren Sie zur Amazon EKS-Konsole zurück. Der **Status** Ihres EKS-Add-Ons sollte sich auf **Bereit zur Installation** geändert haben.
1.
**(Optional) Bereitstellung des Konfigurationsschemas für das EKS-Add-On**
Wenn Sie für die **Add-On-Version Version** **v1.5.0** oder höher wählen, unterstützt Runtime Monitoring die Konfiguration bestimmter GuardDuty Agentenparameter. Hinweise zu Parameterbereichen finden Sie unter[Konfigurieren Sie die Parameter für das EKS-Zusatz](guardduty-configure-security-agent-eks-addon.md).
1. Erweitern Sie **Optionale Konfigurationseinstellungen**, um die konfigurierbaren Parameter sowie deren erwarteten Wert und Format anzuzeigen.
1. Stellen Sie die Parameter ein. Die Werte müssen in dem angegebenen Bereich liegen[Konfigurieren Sie die Parameter für das EKS-Zusatz](guardduty-configure-security-agent-eks-addon.md).
1. Wählen Sie **Änderungen speichern**, um das Add-on auf der Grundlage der erweiterten Konfiguration zu erstellen.
1. Bei der **Methode zur Konfliktlösung** wird die von Ihnen gewählte Option verwendet, um einen Konflikt zu lösen, wenn Sie den Wert eines Parameters auf einen anderen Wert als den Standardwert aktualisieren. Weitere Informationen zu den aufgelisteten Optionen finden Sie unter [ResolveConflicts](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateAddon.html#AmazonEKS-UpdateAddon-request-resolveConflicts) in der *Amazon EKS-API-Referenz*.
1. Wählen Sie **Weiter** aus.
1. Überprüfen Sie auf der Seite **Überprüfen und erstellen** alle Details und wählen Sie dann **Erstellen**.
1. Gehen Sie zurück zu den Cluster-Details und wählen Sie die Registerkarte **Ressourcen**.
1. Sie können die neuen Pods mit dem Präfix anzeigen. **aws-guardduty-agent**
------
#### [ API/CLI ]
Sie können den Amazon-EKS-Add-On-Agent (`aws-guardduty-agent`) konfigurieren, indem Sie eine der folgenden Optionen verwenden:
+ Lauf [CreateAddon](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateAddon.html)für dein Konto.
+
**Anmerkung**
Wenn Sie für das Add-on `version` **Version 1.5.0 oder höher** wählen, unterstützt Runtime Monitoring die Konfiguration bestimmter GuardDuty Agentenparameter. Weitere Informationen finden Sie unter [Konfigurieren Sie die Parameter für das EKS-Zusatz](guardduty-configure-security-agent-eks-addon.md).
Verwenden Sie die folgenden Werte für die Parameter:
+ Geben Sie unter `addonName` den Wert `aws-guardduty-agent` ein.
Sie können das folgende AWS CLI Beispiel verwenden, wenn Sie konfigurierbare Werte verwenden, die für Add-On-Versionen `v1.5.0` oder höher unterstützt werden. Achten Sie darauf, die rot markierten Platzhalterwerte und die `Example.json` mit den konfigurierten Werten verknüpften Platzhalterwerte zu ersetzen.
```
aws eks create-addon --region us-east-1 --cluster-name myClusterName --addon-name aws-guardduty-agent --addon-version v1.12.1-eksbuild.2 --configuration-values 'file://example.json'
```
**example.json**
```
{
"priorityClassName": "aws-guardduty-agent.priorityclass-high",
"dnsPolicy": "Default",
"resources": {
"requests": {
"cpu": "237m",
"memory": "512Mi"
},
"limits": {
"cpu": "2000m",
"memory": "2048Mi"
}
}
}
```
+ Weitere Informationen zu unterstützten `addonVersion` finden Sie unter [Kubernetes-Versionen, die vom Security Agent unterstützt werden GuardDuty](prereq-runtime-monitoring-eks-support.md#gdu-agent-supported-k8-version).
+ Alternativ können Sie verwenden. AWS CLI Weitere Informationen finden Sie unter [create-addon](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/eks/create-addon.html).
------
**Private DNS-Namen für VPC-Endpunkt**
Standardmäßig löst der Security Agent den privaten DNS-Namen des VPC-Endpunkts auf und stellt eine Verbindung zu ihm her. Bei einem Nicht-FIPS-Endpunkt wird Ihr privater DNS im folgenden Format angezeigt:
Nicht-FIPS-Endpunkt — `guardduty-data.us-east-1.amazonaws.com`
Das AWS-Region,*us-east-1*, ändert sich je nach Ihrer Region.
# Manuelles Aktualisieren des Security Agents für Amazon EKS-Ressourcen
Wenn Sie den GuardDuty Security Agent manuell verwalten, sind Sie dafür verantwortlich, ihn für Ihr Konto zu aktualisieren. Um über neue Agent-Versionen informiert zu werden, können Sie einen RSS-Feed abonnieren[GuardDuty Release-Versionen des Security Agents](runtime-monitoring-agent-release-history.md).
Sie können den Security Agent auf die neueste Version aktualisieren, um von der zusätzlichen Unterstützung und den Verbesserungen zu profitieren. Wenn der Standardsupport für Ihre aktuelle Agentenversion ausläuft, müssen Sie auf eine nächste verfügbare oder die neueste Agentenversion aktualisieren, um Runtime Monitoring (oder EKS Runtime Monitoring) weiterhin verwenden zu können.
**Voraussetzung**
Bevor Sie die Security Agent-Version aktualisieren, stellen Sie sicher, dass die Agent-Version, die Sie jetzt verwenden möchten, mit Ihrer Kubernetes-Version kompatibel ist. Weitere Informationen finden Sie unter [Kubernetes-Versionen, die vom Security Agent unterstützt werden GuardDuty](prereq-runtime-monitoring-eks-support.md#gdu-agent-supported-k8-version).
------
#### [ Console ]
1. Öffnen Sie die Amazon EKS-Konsole unter [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie Ihren **Clusternamen** aus.
1. **Wählen Sie unter den **Cluster-Informationen** den Tab Add-Ons aus.**
1. Wählen Sie auf der Registerkarte „**Add-Ons**“ die Option **GuardDutyEKS Runtime Monitoring** aus.
1. Wählen Sie **Bearbeiten**, um die Agentendetails zu aktualisieren.
1. Aktualisieren Sie auf der Seite ** GuardDuty EKS Runtime Monitoring konfigurieren** die Details.
1.
**(Optional) Aktualisierung der optionalen Konfigurationseinstellungen**
Wenn Ihre **EKS-Add-On-Version** *1.5.0* oder höher ist, können Sie auch das Add-On-Konfigurationsschema aktualisieren.
1. Erweitern Sie **Optionale Konfigurationseinstellungen**, um das Konfigurationsschema anzuzeigen.
1. Aktualisieren Sie die Parameterwerte basierend auf dem angegebenen Bereich unter[Konfigurieren Sie die Parameter für das EKS-Zusatz](guardduty-configure-security-agent-eks-addon.md).
1. Wählen Sie **Änderungen speichern**, um das Update zu starten.
1. Bei der **Methode zur Konfliktlösung** wird die von Ihnen gewählte Option verwendet, um einen Konflikt zu lösen, wenn Sie den Wert eines Parameters auf einen Wert aktualisieren, der nicht dem Standard entspricht. Weitere Informationen zu den aufgelisteten Optionen finden Sie unter [ResolveConflicts](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateAddon.html#AmazonEKS-UpdateAddon-request-resolveConflicts) in der *Amazon EKS-API-Referenz*.
------
#### [ API/CLI ]
Informationen zum Update des GuardDuty Security Agents für Ihre Amazon EKS-Cluster finden Sie unter [Ein Add-on aktualisieren](https://docs.aws.amazon.com/eks/latest/userguide/managing-add-ons.html#updating-an-add-on).
**Anmerkung**
Wenn Sie für das Add-on `version` **Version 1.5.0 oder höher** wählen, unterstützt Runtime Monitoring die Konfiguration bestimmter GuardDuty Agentenparameter. Hinweise zu Parameterbereichen finden Sie unter[Konfigurieren Sie die Parameter für das EKS-Zusatz](guardduty-configure-security-agent-eks-addon.md).
Sie können das folgende AWS CLI Beispiel verwenden, wenn Sie konfigurierbare Werte verwenden, die für die Add-On-Versionen *1.5.0 und höher* unterstützt werden. Achten Sie darauf, die rot markierten Platzhalterwerte und die `Example.json` mit den konfigurierten Werten verknüpften Platzhalterwerte zu ersetzen.
```
aws eks update-addon --region us-east-1 --cluster-name myClusterName --addon-name aws-guardduty-agent --addon-version v1.12.1-eksbuild.2 --configuration-values 'file://example.json'
```
**example.json**
```
{
"priorityClassName": "aws-guardduty-agent.priorityclass-high",
"dnsPolicy": "Default",
"resources": {
"requests": {
"cpu": "237m",
"memory": "512Mi"
},
"limits": {
"cpu": "2000m",
"memory": "2048Mi"
}
}
}
```
------
Wenn Ihre Amazon EKS-Add-On-Version 1.5.0 oder höher ist und Sie das Add-On-Schema konfiguriert haben, können Sie überprüfen, ob die Werte für Ihren Cluster korrekt angezeigt werden. Weitere Informationen finden Sie unter [Aktualisierungen des Konfigurationsschemas werden überprüft](guardduty-configure-security-agent-eks-addon.md#gdu-verify-eks-add-on-configuration-param).
# Konfigurieren Sie die Parameter des GuardDuty Security Agents (Add-on) für Amazon EKS
Sie können spezifische Parameter Ihres GuardDuty Security Agents für Amazon EKS konfigurieren. Diese Unterstützung ist für GuardDuty Security Agent Version 1.5.0 und höher verfügbar. Informationen zu den neuesten Add-On-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).
**Warum sollte ich das Security Agent Konfigurationsschema aktualisieren**
Das Konfigurationsschema für den GuardDuty Security Agent ist für alle Container in Ihren Amazon EKS-Clustern dasselbe. Wenn die Standardwerte nicht mit den zugehörigen Workloads und der Instance-Größe übereinstimmen, sollten Sie die Konfiguration der CPU-Einstellungen, Speichereinstellungen und `dnsPolicy` Einstellungen in Betracht ziehen. `PriorityClass` Unabhängig davon, wie Sie den GuardDuty Agenten für Ihre Amazon EKS-Cluster verwalten, können Sie die bestehende Konfiguration dieser Parameter konfigurieren oder aktualisieren.
## Automatisiertes Verhalten der Agentenkonfiguration mit konfigurierten Parametern
Wenn er den Security Agent (EKS-Add-on) in Ihrem Namen GuardDuty verwaltet, aktualisiert er das Add-on bei Bedarf. GuardDuty setzt den Wert der konfigurierbaren Parameter auf einen Standardwert. Sie können die Parameter jedoch immer noch auf einen gewünschten Wert aktualisieren. Wenn dies zu einem Konflikt führt, ist die Standardoption für [ResolveConflicts](https://docs.aws.amazon.com/eks/latest/APIReference/API_UpdateAddon.html#AmazonEKS-UpdateAddon-request-resolveConflicts). `None`
## Konfigurierbare Parameter und Werte
Informationen zu den Schritten zur Konfiguration der Zusatzparameter finden Sie unter:
+ [Manuelles Installieren des GuardDuty Security Agents auf Amazon EKS-Ressourcen](eksrunmon-deploy-security-agent.md) oder
+ [Manuelles Aktualisieren des Security Agents für Amazon EKS-Ressourcen](eksrunmon-update-security-agent.md)
Die folgenden Tabellen enthalten die Bereiche und Werte, die Sie verwenden können, um das Amazon EKS-Add-on manuell bereitzustellen oder die vorhandenen Add-On-Einstellungen zu aktualisieren.
**CPU-Einstellungen**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/guardduty-configure-security-agent-eks-addon.html)
**Speicher-Einstellungen**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/guardduty-configure-security-agent-eks-addon.html)
**`PriorityClass`-Einstellungen**
Wenn Sie GuardDuty ein Amazon EKS-Add-on für Sie erstellen, `PriorityClass` ist das zugewiesene`aws-guardduty-agent.priorityclass`. Das bedeutet, dass auf der Grundlage der Priorität des Agenten-Pods keine Maßnahmen ergriffen werden. Sie können diesen Zusatzparameter konfigurieren, indem Sie eine der folgenden `PriorityClass` Optionen wählen:
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/guardduty-configure-security-agent-eks-addon.html)
**1** Kubernetes bietet diese beiden `PriorityClass` Optionen — und. `system-cluster-critical` `system-node-critical` Weitere Informationen finden Sie [PriorityClass](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/#how-to-use-priority-and-preemption)in der *Kubernetes-Dokumentation*.
**`dnsPolicy`-Einstellungen**
Wählen Sie eine der folgenden DNS-Richtlinienoptionen, die Kubernetes unterstützt. Wird als Standardwert verwendet, wenn keine Konfiguration angegeben `ClusterFirst` ist.
+ `ClusterFirst`
+ `ClusterFirstWithHostNet`
+ `Default`
Informationen zu diesen Richtlinien finden Sie in [der *Kubernetes-Dokumentation* unter DNS-Richtlinie von Pod](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy).
## Aktualisierungen des Konfigurationsschemas werden überprüft
Nachdem Sie die Parameter konfiguriert haben, führen Sie die folgenden Schritte aus, um zu überprüfen, ob das Konfigurationsschema aktualisiert wurde:
1. Öffnen Sie die Amazon EKS-Konsole unter [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters).
1. Klicken Sie im Navigationsbereich auf **Cluster**.
1. Wählen Sie auf der **Cluster-Seite** den **Cluster-Namen** aus, für den Sie die Updates überprüfen möchten.
1. Wählen Sie die Registerkarte **Resources (Ressourcen)** aus.
1. Wählen Sie im Bereich **Ressourcentypen** unter **Workloads** die Option **DaemonSets**.
1. Wählen Sie **aws-guardduty-agent**.
1. Wählen Sie auf der **aws-guardduty-agent**Seite die Option **Rohansicht** aus, um die unformatierte JSON-Antwort anzuzeigen. Stellen Sie sicher, dass die konfigurierbaren Parameter den von Ihnen angegebenen Wert anzeigen.
Wechseln Sie nach der Überprüfung zur GuardDuty Konsole. Wählen Sie das entsprechende aus AWS-Region und sehen Sie sich den Deckungsstatus für Ihre Amazon EKS-Cluster an. Weitere Informationen finden Sie unter [Runtime-Abdeckung und Fehlerbehebung für Amazon EKS-Cluster](eks-runtime-monitoring-coverage.md).
# Validierung der VPC-Endpunktkonfiguration
Nachdem Sie den Security Agent manuell oder über die GuardDuty automatische Konfiguration installiert haben, können Sie dieses Dokument verwenden, um die VPC-Endpunktkonfiguration zu überprüfen. Sie können diese Schritte auch verwenden, nachdem Sie alle Probleme mit der [Runtime-Abdeckung für einen Ressourcentyp behoben](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring-assessing-coverage.html) haben. Sie können sicherstellen, dass die Schritte erwartungsgemäß ausgeführt wurden und der Deckungsstatus möglicherweise als Fehlerfrei angezeigt **wird**.
Gehen Sie wie folgt vor, um zu überprüfen, ob die VPC-Endpunktkonfiguration für Ihren Ressourcentyp im VPC-Besitzerkonto korrekt eingerichtet ist:
1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon VPC-Konsole unter [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/).
1. Wählen Sie im Navigationsbereich unter **Virtual Private Cloud** die Option **Your VPCs** aus.
1. Wählen Sie auf der VPCs Seite **Ihr IPv4 ** **CIDR** aus, das mit Ihrer **VPC-ID** verknüpft ist.
1. Wählen Sie im Navigationsmenü unter **Virtual Private Cloud** die Option **Endpunkte**.
1. **Wählen Sie in der Tabelle **Endpoints** die Zeile mit dem **Servicenamen aus, der com.amazonaws** ähnelt. *us-east-1*.guardduty-data.** Die Region (`us-east-1`) kann für Ihren Endpunkt unterschiedlich sein.
1. Ein Fenster mit Endpunktdetails wird angezeigt. Wählen Sie auf der Registerkarte **Sicherheitsgruppen** den zugehörigen **Gruppen-ID-Link** aus, um weitere Informationen zu erhalten.
1. Wählen Sie in der Tabelle **Sicherheitsgruppen** die Zeile mit der zugehörigen **Sicherheitsgruppen-ID** aus, um die Details anzuzeigen.
1. **Stellen Sie auf der Registerkarte **Regeln für eingehenden** Datenverkehr sicher, dass es eine Eingangsrichtlinie mit dem **Portbereich** **443** und dem aus dem CIDR kopierten Wert **Source** gibt. IPv4 ** Eingehende Regeln steuern den eingehenden Datenverkehr, der die Instance erreichen darf. Die folgende Abbildung zeigt die Regeln für eingehende Nachrichten für eine Sicherheitsgruppe, die der vom GuardDuty Security Agent verwendeten VPC zugeordnet ist.
Wenn Sie noch keine Sicherheitsgruppe haben, für die ein eingehender Port 443 aktiviert ist, [erstellen Sie im *Amazon EC2 EC2-Benutzerhandbuch* eine Sicherheitsgruppe](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/working-with-security-groups.html#creating-security-group).
Wenn bei der Einschränkung der Eingangsberechtigungen für Ihre VPC (oder Ihren Cluster) ein Problem auftritt, stellen Sie die Unterstützung für den eingehenden Port 443 von einer beliebigen IP-Adresse (0.0.0.0/0) bereit.
Die folgende Liste enthält wichtige Informationen nach der Installation oder Aktualisierung des Security Agents.
**Beurteilen Sie die Laufzeitabdeckung**
Der nächste Schritt nach der Installation oder Aktualisierung Ihres Security Agents ist die Bewertung der Laufzeitabdeckung Ihrer Ressourcen. Wenn der Runtime-Coverage-Status „**Ungesund**“ lautet, müssen Sie das Problem beheben. Weitere Informationen finden Sie unter [Probleme mit der Runtime-Abdeckung und Problembehebung](runtime-monitoring-assessing-coverage.md).
Wenn der Status der Runtime-Coverage als Fehlerfrei angezeigt wird**,** bedeutet dies, dass Runtime Monitoring in der Lage ist, Laufzeitereignisse zu sammeln und zu empfangen. Eine Liste dieser Ereignisse finden Sie unter[Gesammelte Laufzeit-Ereignistypen](runtime-monitoring-collected-events.md).
**Privater DNS-Name für den Endpunkt**
Nachdem Sie den GuardDuty Security Agent für Ihre Ressourcen installiert haben, löst er standardmäßig den privaten DNS-Namen des VPC-Endpunkts auf und stellt eine Verbindung zu diesem her. Bei einem Nicht-FIPS-Endpunkt wird der private DNS im folgenden Format angezeigt:
`guardduty-data.us-east-1.amazonaws.com`
Das AWS-Region,*us-east-1*, ändert sich je nach Ihrer Region.
**Ein Host kann mit zwei Security Agents installiert werden**
Wenn Sie mit einem GuardDuty Security Agent für eine Amazon EC2 EC2-Instance arbeiten, können Sie den Agenten auf dem zugrunde liegenden Host innerhalb eines Amazon EKS-Clusters installieren und verwenden. Wenn Sie bereits einen Security Agent auf diesem EKS-Cluster installiert haben, könnten auf demselben Host zwei Security Agents gleichzeitig ausgeführt werden. Informationen zur GuardDuty Funktionsweise in diesem Szenario finden Sie unter[Security Agents auf demselben Host](two-security-agents-installed-on-ec2-node.md).
# Überprüfung der Statistiken zur Laufzeitabdeckung und Behebung von Problemen
Nachdem Sie Runtime Monitoring aktiviert haben und der GuardDuty Security Agent auf Ihrer Ressource installiert wurde, GuardDuty liefert er Deckungsstatistiken für den entsprechenden Ressourcentyp und den individuellen Schutzstatus für die Ressourcen, die zu Ihrem Konto gehören. Der Deckungsstatus wird bestimmt, indem Sie sicherstellen, dass Sie Runtime Monitoring aktiviert haben, Ihr Amazon VPC-Endpunkt erstellt wurde und der GuardDuty Security Agent für die entsprechende Ressource bereitgestellt wurde. Der **Coverage-Status** „Fehlerfrei“ gibt an, dass, wenn es ein Laufzeitereignis im Zusammenhang mit Ihrer Ressource gibt, GuardDuty das besagte Laufzeitereignis über den Amazon VPC-Endpunkt empfangen und das Verhalten überwachen kann. Wenn bei der Konfiguration von Runtime Monitoring, der Erstellung eines Amazon VPC-Endpunkts oder der Bereitstellung des GuardDuty Security Agents ein Problem aufgetreten ist, wird der Deckungsstatus als **Ungesund** angezeigt. Wenn der Deckungsstatus fehlerhaft ist, kann GuardDuty das Laufzeitverhalten der entsprechenden Ressource nicht empfangen oder überwacht werden, und es können auch keine Runtime Monitoring-Ergebnisse generiert werden.
Die folgenden Themen helfen Ihnen dabei, Deckungsstatistiken zu überprüfen, EventBridge Benachrichtigungen zu konfigurieren und Probleme mit der Abdeckung für einen bestimmten Ressourcentyp zu beheben.
**Topics**
+ [Runtime-Abdeckung und Fehlerbehebung für Amazon EC2 EC2-Instance](gdu-assess-coverage-ec2.md)
+ [Runtime-Abdeckung und Fehlerbehebung für Amazon ECS-Cluster](gdu-assess-coverage-ecs.md)
+ [Runtime-Abdeckung und Fehlerbehebung für Amazon EKS-Cluster](eks-runtime-monitoring-coverage.md)
# Runtime-Abdeckung und Fehlerbehebung für Amazon EC2 EC2-Instance
Für eine Amazon EC2 EC2-Ressource wird die Laufzeitabdeckung auf Instance-Ebene bewertet. Ihre Amazon EC2 EC2-Instances können unter anderem mehrere Arten von Anwendungen und Workloads in Ihrer AWS Umgebung ausführen. Diese Funktion unterstützt auch von Amazon ECS verwaltete Amazon EC2 EC2-Instances. Wenn Sie Amazon ECS-Cluster auf einer Amazon EC2 EC2-Instance ausführen, werden die Deckungsprobleme auf Instance-Ebene unter Amazon EC2 EC2-Laufzeitabdeckung angezeigt.
**Topics**
+ [Überprüfen der Abdeckungsstatistiken](#review-coverage-statistics-ec2-runtime-monitoring)
+ [Änderung des Abdeckungsstatus mit Benachrichtigungen EventBridge](#ec2-runtime-monitoring-coverage-status-change)
+ [Behebung von Problemen mit der Amazon EC2 EC2-Runtime-Abdeckung](#ec2-runtime-monitoring-coverage-issues-troubleshoot)
## Überprüfen der Abdeckungsstatistiken
Die Deckungsstatistik für die Amazon EC2 EC2-Instances, die mit Ihren eigenen Konten oder Ihren Mitgliedskonten verknüpft sind, ist der Prozentsatz der fehlerfreien EC2-Instances an allen EC2-Instances in den ausgewählten. AWS-Region Die folgende Gleichung stellt dies wie folgt dar:
*(Fehlerfreie Instances) \$1100 instances/All *
Wenn Sie den GuardDuty Security Agent auch für Ihre Amazon ECS-Cluster bereitgestellt haben, wird jedes Problem mit der Abdeckung auf Instance-Ebene im Zusammenhang mit Amazon ECS-Clustern, die auf einer Amazon EC2 EC2-Instance ausgeführt werden, als ein Problem mit der Laufzeit der Amazon EC2 EC2-Instance angezeigt.
Wählen Sie eine der Zugriffsmethoden, um die Abdeckungsstatistiken für Ihre Konten einzusehen.
------
#### [ Console ]
+ Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die GuardDuty Konsole unter. [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)
+ Wählen Sie im Navigationsbereich **Runtime Monitoring** aus.
+ Wählen Sie die Registerkarte **Runtime Coverage** aus.
+ Auf der Registerkarte **EC2-Instance-Laufzeitabdeckung** können Sie die Deckungsstatistiken einsehen, die nach dem Deckungsstatus jeder Amazon EC2 EC2-Instance aggregiert sind, die in der Tabelle mit der **Instance-Liste** verfügbar sind.
+ Sie können die Tabelle mit der **Instance-Liste** nach den folgenden Spalten filtern:
+ **Konto-ID**
+ **Agentenverwaltungs-Typ**
+ **Version des Agenten**
+ **Abdeckungsstatus**
+ **Instanz-ID**
+ **Cluster-ARN**
+ Wenn eine Ihrer EC2-Instances den **Coverage-Status** als **Unhealthy** hat, enthält die Spalte **Issue** zusätzliche Informationen über den Grund für den Status **Unhealthy**.
------
#### [ API/CLI ]
+ Führen Sie die [ListCoverage](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListCoverage.html)API mit Ihrer eigenen gültigen Melder-ID, Ihrer aktuellen Region und Ihrem Service-Endpunkt aus. Mit dieser API können Sie die Instanzliste filtern und sortieren.
+ Sie können das Beispiel `filter-criteria` ändern mit einer der folgenden Optionen für `CriterionKey`:
+ `ACCOUNT_ID`
+ `RESOURCE_TYPE`
+ `COVERAGE_STATUS`
+ `AGENT_VERSION`
+ `MANAGEMENT_TYPE`
+ `INSTANCE_ID`
+ `CLUSTER_ARN`
+ Wenn **EC2 `filter-criteria`** enthalten `RESOURCE_TYPE` ist, unterstützt Runtime Monitoring nicht die Verwendung von **ISSUE** als. `AttributeName` Wenn Sie es verwenden, führt die API-Antwort zu`InvalidInputException`.
Sie können das Beispiel `AttributeName` in `sort-criteria` ändern mit einer der folgenden Optionen:
+ `ACCOUNT_ID`
+ `COVERAGE_STATUS`
+ `INSTANCE_ID`
+ `UPDATED_AT`
+ Sie können das ändern *max-results* (bis zu 50).
+ Informationen zu den Einstellungen `detectorId` für Ihr Konto und Ihre aktuelle Region finden Sie auf der Seite **„Einstellungen**“ in der [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)Konsole oder führen Sie die [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html)API aus.
```
aws guardduty --region us-east-1 list-coverage --detector-id 12abc34d567e8fa901bc2d34e56789f0 --sort-criteria '{"AttributeName": "EKS_CLUSTER_NAME", "OrderBy": "DESC"}' --filter-criteria '{"FilterCriterion":[{"CriterionKey":"ACCOUNT_ID", "FilterCondition":{"EqualsValue":"111122223333"}}] }' --max-results 5
```
+ Führen Sie die [GetCoverageStatistics](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_GetCoverageStatistics.html)API aus, um aggregierte Statistiken zur Abdeckung abzurufen, die `statisticsType` auf dem basieren.
+ Sie können das Beispiel `statisticsType` zu einer der folgenden Optionen ändern:
+ `COUNT_BY_COVERAGE_STATUS` – Stellt Abdeckungsstatistiken für EKS-Cluster dar, aggregiert nach Abdeckungs-Status.
+ `COUNT_BY_RESOURCE_TYPE`— Statistiken zur Abdeckung, aggregiert auf der Grundlage des AWS Ressourcentyps in der Liste.
+ Sie können das Beispiel `filter-criteria` im Befehl ändern. Sie können die folgenden Optionen für `CriterionKey` verwenden:
+ `ACCOUNT_ID`
+ `RESOURCE_TYPE`
+ `COVERAGE_STATUS`
+ `AGENT_VERSION`
+ `MANAGEMENT_TYPE`
+ `INSTANCE_ID`
+ `CLUSTER_ARN`
+ Informationen zu den Einstellungen `detectorId` für Ihr Konto und Ihre aktuelle Region finden Sie auf der Seite **„Einstellungen**“ in der [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)Konsole oder führen Sie die [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html)API aus.
```
aws guardduty --region us-east-1 get-coverage-statistics --detector-id 12abc34d567e8fa901bc2d34e56789f0 --statistics-type COUNT_BY_COVERAGE_STATUS --filter-criteria '{"FilterCriterion":[{"CriterionKey":"ACCOUNT_ID", "FilterCondition":{"EqualsValue":"123456789012"}}] }'
```
------
Wenn der Deckungsstatus Ihrer EC2-Instance **Unhealthy** lautet, finden Sie weitere Informationen unter. [Behebung von Problemen mit der Amazon EC2 EC2-Runtime-Abdeckung](#ec2-runtime-monitoring-coverage-issues-troubleshoot)
## Änderung des Abdeckungsstatus mit Benachrichtigungen EventBridge
Der Deckungsstatus Ihrer Amazon EC2 EC2-Instance wird möglicherweise als **Ungesund** angezeigt. **Um zu wissen, wann sich der Deckungsstatus ändert, empfehlen wir Ihnen, den Deckungsstatus regelmäßig zu überwachen und Fehler zu beheben, falls der Status auf Ungesund umgestellt wird.** **Alternativ können Sie eine EventBridge Amazon-Regel erstellen, um eine Benachrichtigung zu erhalten, wenn sich der Versicherungsstatus von „**Ungesund**“ in „Fehlerfrei“ oder anderweitig ändert.** GuardDuty Veröffentlicht dies standardmäßig im [EventBridge Bus](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-bus.html) für Ihr Konto.
### Beispiel für ein Benachrichtigungsschema
In einer EventBridge Regel können Sie die vordefinierten Beispielereignisse und Ereignismuster verwenden, um eine Benachrichtigung über den Versicherungsstatus zu erhalten. Weitere Informationen zum Erstellen einer EventBridge Regel finden Sie unter [Regel erstellen](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html#eb-gs-create-rule) im * EventBridge Amazon-Benutzerhandbuch*.
Darüber hinaus können Sie mithilfe des folgenden Beispiel-Benachrichtigungsschemas ein benutzerdefiniertes Ereignismuster erstellen. Achten Sie darauf, die Werte für Ihr Konto zu ersetzen. Um benachrichtigt zu werden, wenn sich der Deckungsstatus Ihrer Amazon EC2 EC2-Instance von `Healthy` zu ändert`Unhealthy`, `detail-type` sollte dies der Fall sein*GuardDuty Runtime Protection Unhealthy*. Um benachrichtigt zu werden, wenn sich der Deckungsstatus von `Unhealthy` auf ändert`Healthy`, ersetzen Sie den Wert von `detail-type` durch*GuardDuty Runtime Protection Healthy*.
```
{
"version": "0",
"id": "event ID",
"detail-type": "GuardDuty Runtime Protection Unhealthy",
"source": "aws.guardduty",
"account": "AWS-Konto ID",
"time": "event timestamp (string)",
"region": "AWS-Region",
"resources": [
],
"detail": {
"schemaVersion": "1.0",
"resourceAccountId": "string",
"currentStatus": "string",
"previousStatus": "string",
"resourceDetails": {
"resourceType": "EC2",
"ec2InstanceDetails": {
"instanceId":"",
"instanceType":"",
"clusterArn": "",
"agentDetails": {
"version":""
},
"managementType":""
}
},
"issue": "string",
"lastUpdatedAt": "timestamp"
}
}
```
## Behebung von Problemen mit der Amazon EC2 EC2-Runtime-Abdeckung
Wenn der Deckungsstatus Ihrer Amazon EC2 EC2-Instance **Unhealthy** lautet, können Sie den Grund in der Spalte **Problem** einsehen.
Wenn Ihre EC2-Instance einem EKS-Cluster zugeordnet ist und der Security Agent für EKS entweder manuell oder über eine automatische Agentenkonfiguration installiert wurde, finden Sie Informationen zur Behebung des Deckungsproblems unter. [Runtime-Abdeckung und Fehlerbehebung für Amazon EKS-Cluster](eks-runtime-monitoring-coverage.md)
In der folgenden Tabelle sind die Problemtypen und die entsprechenden Schritte zur Fehlerbehebung aufgeführt.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/gdu-assess-coverage-ec2.html)
# Runtime-Abdeckung und Fehlerbehebung für Amazon ECS-Cluster
Die Laufzeitabdeckung für Amazon ECS-Cluster umfasst die Aufgaben, die auf AWS Fargate Amazon ECS-Container-Instances ausgeführt werden [1](#ecs-container-instance).
Für einen Amazon ECS-Cluster, der auf Fargate läuft, wird die Laufzeitabdeckung auf Aufgabenebene bewertet. Die Laufzeitabdeckung des ECS-Clusters umfasst die Fargate-Aufgaben, die gestartet wurden, nachdem Sie Runtime Monitoring und automatisierte Agentenkonfiguration für Fargate aktiviert haben (nur ECS). Standardmäßig ist eine Fargate-Aufgabe unveränderlich. GuardDuty kann den Security Agent nicht installieren, um Container bei bereits laufenden Aufgaben zu überwachen. Um eine solche Fargate-Aufgabe einzubeziehen, müssen Sie die Aufgabe beenden und erneut starten. Stellen Sie sicher, dass Sie überprüfen, ob der zugehörige Dienst unterstützt wird.
Informationen zum Amazon ECS-Container finden Sie unter [Kapazitätserstellung](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/create-capacity.html).
**Topics**
+ [Überprüfen der Abdeckungsstatistiken](#ecs-review-coverage-statistics-ecs-runtime-monitoring)
+ [Änderung des Deckungsstatus mit EventBridge Benachrichtigungen](#ecs-runtime-monitoring-coverage-status-change)
+ [Behebung von Problemen mit der Amazon ECS-Fargate-Runtime-Abdeckung](#ecs-runtime-monitoring-coverage-issues-troubleshoot)
## Überprüfen der Abdeckungsstatistiken
Die Deckungsstatistik für die Amazon ECS-Ressourcen, die mit Ihrem eigenen Konto oder Ihren Mitgliedskonten verknüpft sind, ist der Prozentsatz der fehlerfreien Amazon ECS-Cluster im Vergleich zu allen Amazon ECS-Clustern in den ausgewählten AWS-Region. Dies beinhaltet die Abdeckung für Amazon ECS-Cluster, die sowohl mit Fargate- als auch mit Amazon EC2 EC2-Instances verknüpft sind. Die folgende Gleichung stellt dies wie folgt dar:
*(Fehlerfreie clusters/All Cluster) \$1100*
### Überlegungen
+ Die Deckungsstatistiken für den ECS-Cluster beinhalten den Abdeckungsstatus der Fargate-Aufgaben oder ECS-Container-Instances, die diesem ECS-Cluster zugeordnet sind. Der Deckungsstatus der Fargate-Aufgaben umfasst Aufgaben, die sich entweder im Status Running befinden oder deren Ausführung vor Kurzem abgeschlossen wurde.
+ Auf der Registerkarte **Runtime Coverage von ECS-Clustern** gibt das Feld **Abgedeckte Container-Instances** den Abdeckungsstatus der Container-Instances an, die mit Ihrem Amazon ECS-Cluster verknüpft sind.
Wenn Ihr Amazon ECS-Cluster nur Fargate-Aufgaben enthält, wird die Anzahl als **0/0** angezeigt.
+ Wenn Ihr Amazon ECS-Cluster mit einer Amazon EC2 EC2-Instance verknüpft ist, die keinen Sicherheitsagenten hat, hat der Amazon ECS-Cluster auch den Status **Unhealthy** Coverage.
Informationen zur Identifizierung und Behebung des Deckungsproblems für die zugehörige Amazon EC2 EC2-Instance finden Sie unter [Behebung von Problemen mit der Amazon EC2 EC2-Runtime-Abdeckung](gdu-assess-coverage-ec2.md#ec2-runtime-monitoring-coverage-issues-troubleshoot) Amazon EC2 EC2-Instances.
Wählen Sie eine der Zugriffsmethoden, um die Abdeckungsstatistiken für Ihre Konten einzusehen.
------
#### [ Console ]
+ Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die GuardDuty Konsole unter. [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)
+ Wählen Sie im Navigationsbereich **Runtime Monitoring** aus.
+ Wählen Sie die Registerkarte **Runtime Coverage** aus.
+ Auf der Registerkarte **ECS-Cluster-Laufzeitabdeckung** können Sie die Deckungsstatistiken einsehen, die nach dem Abdeckungsstatus jedes Amazon ECS-Clusters aggregiert sind, der in der **Cluster-Listentabelle** verfügbar ist.
+ Sie können die **Cluster-Listentabelle** nach den folgenden Spalten filtern:
+ **Konto-ID**
+ **Cluster-Name**
+ **Agentenverwaltungs-Typ**
+ **Abdeckungsstatus**
+ Wenn einer Ihrer Amazon ECS-Cluster den **Deckungsstatus** **Ungesund** hat, enthält die Spalte **Problem** zusätzliche Informationen über den Grund für den Status **Ungesund**.
**Wenn Ihre Amazon ECS-Cluster mit einer Amazon EC2 EC2-Instance verknüpft sind, navigieren Sie zur Registerkarte **EC2-Instance-Laufzeitabdeckung** und filtern Sie nach dem Feld **Clustername**, um das zugehörige Problem anzuzeigen.**
------
#### [ API/CLI ]
+ Führen Sie die [ListCoverage](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListCoverage.html)API mit Ihrer eigenen gültigen Detektor-ID, Ihrer aktuellen Region und Ihrem Service-Endpunkt aus. Mit dieser API können Sie die Instanzliste filtern und sortieren.
+ Sie können das Beispiel `filter-criteria` ändern mit einer der folgenden Optionen für `CriterionKey`:
+ `ACCOUNT_ID`
+ `ECS_CLUSTER_NAME`
+ `COVERAGE_STATUS`
+ `MANAGEMENT_TYPE`
+ Sie können das Beispiel `AttributeName` in `sort-criteria` ändern mit einer der folgenden Optionen:
+ `ACCOUNT_ID`
+ `COVERAGE_STATUS`
+ `ISSUE`
+ `ECS_CLUSTER_NAME`
+ `UPDATED_AT`
Das Feld wird nur aktualisiert, wenn entweder eine neue Aufgabe im zugehörigen Amazon ECS-Cluster erstellt wird oder wenn sich der entsprechende Deckungsstatus ändert.
+ Sie können den *max-results* (bis zu 50) ändern.
+ Informationen zu den Einstellungen `detectorId` für Ihr Konto und Ihre aktuelle Region finden Sie auf der Seite **„Einstellungen**“ in der [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)Konsole oder führen Sie die [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html)API aus.
```
aws guardduty --region us-east-1 list-coverage --detector-id 12abc34d567e8fa901bc2d34e56789f0 --sort-criteria '{"AttributeName": "ECS_CLUSTER_NAME", "OrderBy": "DESC"}' --filter-criteria '{"FilterCriterion":[{"CriterionKey":"ACCOUNT_ID", "FilterCondition":{"EqualsValue":"111122223333"}}] }' --max-results 5
```
+ Führen Sie die [GetCoverageStatistics](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_GetCoverageStatistics.html)API aus, um aggregierte Statistiken zur Abdeckung abzurufen, die `statisticsType` auf dem basieren.
+ Sie können das Beispiel `statisticsType` zu einer der folgenden Optionen ändern:
+ `COUNT_BY_COVERAGE_STATUS`— Stellt Deckungsstatistiken für ECS-Cluster dar, die nach dem Abdeckungsstatus aggregiert sind.
+ `COUNT_BY_RESOURCE_TYPE`— Statistiken zur Abdeckung, aggregiert auf der Grundlage des AWS Ressourcentyps in der Liste.
+ Sie können das Beispiel `filter-criteria` im Befehl ändern. Sie können die folgenden Optionen für `CriterionKey` verwenden:
+ `ACCOUNT_ID`
+ `ECS_CLUSTER_NAME`
+ `COVERAGE_STATUS`
+ `MANAGEMENT_TYPE`
+ `INSTANCE_ID`
+ Informationen zu den Einstellungen `detectorId` für Ihr Konto und Ihre aktuelle Region finden Sie auf der Seite **„Einstellungen**“ in der [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)Konsole oder führen Sie die [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html)API aus.
```
aws guardduty --region us-east-1 get-coverage-statistics --detector-id 12abc34d567e8fa901bc2d34e56789f0 --statistics-type COUNT_BY_COVERAGE_STATUS --filter-criteria '{"FilterCriterion":[{"CriterionKey":"ACCOUNT_ID", "FilterCondition":{"EqualsValue":"123456789012"}}] }'
```
------
Weitere Informationen zu Deckungsproblemen finden Sie unter[Behebung von Problemen mit der Amazon ECS-Fargate-Runtime-Abdeckung](#ecs-runtime-monitoring-coverage-issues-troubleshoot).
## Änderung des Deckungsstatus mit EventBridge Benachrichtigungen
Der Abdeckungsstatus Ihres Amazon ECS-Clusters wird möglicherweise als **Ungesund** angezeigt. Um zu wissen, wann sich der Deckungsstatus ändert, empfehlen wir Ihnen, den Deckungsstatus regelmäßig zu überwachen und Fehler zu beheben, falls der Status auf **Ungesund** umgestellt wird. **Alternativ können Sie eine EventBridge Amazon-Regel erstellen, um eine Benachrichtigung zu erhalten, wenn sich der Versicherungsstatus von „**Ungesund**“ in „Fehlerfrei“ oder anderweitig ändert.** GuardDuty Veröffentlicht dies standardmäßig im [EventBridge Bus](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-bus.html) für Ihr Konto.
### Beispiel für ein Benachrichtigungsschema
In einer EventBridge Regel können Sie die vordefinierten Beispielereignisse und Ereignismuster verwenden, um eine Benachrichtigung über den Versicherungsstatus zu erhalten. Weitere Informationen zum Erstellen einer EventBridge Regel finden Sie unter [Regel erstellen](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html#eb-gs-create-rule) im * EventBridge Amazon-Benutzerhandbuch*.
Darüber hinaus können Sie mithilfe des folgenden Beispiel-Benachrichtigungsschemas ein benutzerdefiniertes Ereignismuster erstellen. Achten Sie darauf, die Werte für Ihr Konto zu ersetzen. Um benachrichtigt zu werden, wenn sich der Deckungsstatus Ihres Amazon ECS-Clusters von `Healthy` zu ändert`Unhealthy`, `detail-type` sollte dies der Fall sein*GuardDuty Runtime Protection Unhealthy*. Um benachrichtigt zu werden, wenn sich der Deckungsstatus von `Unhealthy` auf ändert`Healthy`, ersetzen Sie den Wert von `detail-type` durch*GuardDuty Runtime Protection Healthy*.
```
{
"version": "0",
"id": "event ID",
"detail-type": "GuardDuty Runtime Protection Unhealthy",
"source": "aws.guardduty",
"account": "AWS-Konto ID",
"time": "event timestamp (string)",
"region": "AWS-Region",
"resources": [
],
"detail": {
"schemaVersion": "1.0",
"resourceAccountId": "string",
"currentStatus": "string",
"previousStatus": "string",
"resourceDetails": {
"resourceType": "ECS",
"ecsClusterDetails": {
"clusterName":"",
"fargateDetails":{
"issues":[],
"managementType":""
},
"containerInstanceDetails":{
"coveredContainerInstances":int,
"compatibleContainerInstances":int
}
}
},
"issue": "string",
"lastUpdatedAt": "timestamp"
}
}
```
## Behebung von Problemen mit der Amazon ECS-Fargate-Runtime-Abdeckung
Wenn der Abdeckungsstatus Ihres Amazon ECS-Clusters **fehlerhaft** ist, können Sie den Grund in der Spalte **Problem** einsehen.
Die folgende Tabelle enthält die empfohlenen Schritte zur Fehlerbehebung bei Fargate-Problemen (nur Amazon ECS). Informationen zu Problemen mit der Abdeckung von Amazon EC2 EC2-Instances finden Sie unter [Behebung von Problemen mit der Amazon EC2 EC2-Runtime-Abdeckung](gdu-assess-coverage-ec2.md#ec2-runtime-monitoring-coverage-issues-troubleshoot) Für Amazon EC2 EC2-Instances.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/gdu-assess-coverage-ecs.html)
# Runtime-Abdeckung und Fehlerbehebung für Amazon EKS-Cluster
Nachdem Sie Runtime Monitoring aktiviert und den GuardDuty Security Agent (Add-on) für EKS entweder manuell oder über die automatische Agentenkonfiguration installiert haben, können Sie mit der Bewertung der Abdeckung Ihrer EKS-Cluster beginnen.
**Topics**
+ [Überprüfen der Abdeckungsstatistiken](#reviewing-coverage-statistics-eks-runtime-monitoring)
+ [Änderung des Deckungsstatus mit EventBridge Benachrichtigungen](#eks-runtime-monitoring-coverage-status-change)
+ [Behebung von Problemen mit der Amazon EKS-Runtime-Abdeckung](#eks-runtime-monitoring-coverage-issues-troubleshoot)
## Überprüfen der Abdeckungsstatistiken
Die Abdeckungsstatistiken für die EKS-Cluster, die Ihren eigenen Konten oder Ihren Mitgliedskonten zugeordnet sind, geben den Prozentsatz der fehlerfreien EKS-Cluster an allen EKS-Clustern in der ausgewählten AWS-Region an. Die folgende Gleichung stellt dies wie folgt dar:
*(Fehlerfreie clusters/All Cluster) \$1100*
Wählen Sie eine der Zugriffsmethoden, um die Abdeckungsstatistiken für Ihre Konten einzusehen.
------
#### [ Console ]
+ Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die GuardDuty Konsole unter [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/).
+ Wählen Sie im Navigationsbereich **Runtime Monitoring** aus.
+ Wählen Sie die Registerkarte **Laufzeitabdeckung von EKS-Clustern**.
+ Auf der Registerkarte **Laufzeitabdeckung von EKS-Clustern** können Sie die Abdeckungsstatistiken einsehen, die nach dem Abdeckungsstatus aggregiert sind, der in der **Cluster-Listentabelle** verfügbar ist.
+ Sie können die Tabelle mit der **Cluster-Liste** nach den folgenden Spalten filtern:
+ **Cluster name**
+ **Konto-ID**
+ **Agentenverwaltungs-Typ**
+ **Abdeckungsstatus**
+ **Add-On-Version**
+ Wenn einer Ihrer EKS-Cluster den **Abdeckungsstatus** **Fehlerhaft** hat, kann die Spalte **Problem** zusätzliche Informationen über den Grund für den Status **Fehlerhaft** enthalten.
------
#### [ API/CLI ]
+ Führen Sie die [ListCoverage](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListCoverage.html)API mit Ihrer eigenen gültigen Detektor-ID, Region und Ihrem Service-Endpunkt aus. Mit dieser API können Sie die Cluster-Liste filtern und sortieren.
+ Sie können das Beispiel `filter-criteria` ändern mit einer der folgenden Optionen für `CriterionKey`:
+ `ACCOUNT_ID`
+ `CLUSTER_NAME`
+ `RESOURCE_TYPE`
+ `COVERAGE_STATUS`
+ `ADDON_VERSION`
+ `MANAGEMENT_TYPE`
+ Sie können das Beispiel `AttributeName` in `sort-criteria` ändern mit einer der folgenden Optionen:
+ `ACCOUNT_ID`
+ `CLUSTER_NAME`
+ `COVERAGE_STATUS`
+ `ISSUE`
+ `ADDON_VERSION`
+ `UPDATED_AT`
+ Sie können die ändern *max-results* (bis zu 50).
+ Informationen zu den Einstellungen `detectorId` für Ihr Konto und Ihre aktuelle Region finden Sie auf der Seite **„Einstellungen**“ in der [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)Konsole oder führen Sie die [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html)API aus.
```
aws guardduty --region us-east-1 list-coverage --detector-id 12abc34d567e8fa901bc2d34e56789f0 --sort-criteria '{"AttributeName": "EKS_CLUSTER_NAME", "OrderBy": "DESC"}' --filter-criteria '{"FilterCriterion":[{"CriterionKey":"ACCOUNT_ID", "FilterCondition":{"EqualsValue":"111122223333"}}] }' --max-results 5
```
+ Führen Sie die [GetCoverageStatistics](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_GetCoverageStatistics.html)API aus, um aggregierte Statistiken zur Abdeckung abzurufen, die `statisticsType` auf dem basieren.
+ Sie können das Beispiel `statisticsType` zu einer der folgenden Optionen ändern:
+ `COUNT_BY_COVERAGE_STATUS` – Stellt Abdeckungsstatistiken für EKS-Cluster dar, aggregiert nach Abdeckungs-Status.
+ `COUNT_BY_RESOURCE_TYPE`— Statistiken zur Abdeckung, aggregiert auf der Grundlage des AWS Ressourcentyps in der Liste.
+ Sie können das Beispiel `filter-criteria` im Befehl ändern. Sie können die folgenden Optionen für `CriterionKey` verwenden:
+ `ACCOUNT_ID`
+ `CLUSTER_NAME`
+ `RESOURCE_TYPE`
+ `COVERAGE_STATUS`
+ `ADDON_VERSION`
+ `MANAGEMENT_TYPE`
+ Informationen zu den Einstellungen `detectorId` für Ihr Konto und Ihre aktuelle Region finden Sie auf der Seite **„Einstellungen**“ in der [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)Konsole oder führen Sie die [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html)API aus.
```
aws guardduty --region us-east-1 get-coverage-statistics --detector-id 12abc34d567e8fa901bc2d34e56789f0 --statistics-type COUNT_BY_COVERAGE_STATUS --filter-criteria '{"FilterCriterion":[{"CriterionKey":"ACCOUNT_ID", "FilterCondition":{"EqualsValue":"123456789012"}}] }'
```
------
Wenn der Abdeckungsstatus Ihres EKS-Clusters **Fehlerhaft** ist, finden Sie weitere Informationen unter [Behebung von Problemen mit der Amazon EKS-Runtime-Abdeckung](#eks-runtime-monitoring-coverage-issues-troubleshoot).
## Änderung des Deckungsstatus mit EventBridge Benachrichtigungen
Der Abdeckungsstatus eines EKS-Clusters in Ihrem Konto wird möglicherweise als **Fehlerhaft** angezeigt. Um zu erkennen, wann der Abdeckungsstatus **Fehlerhaft** wird, empfehlen wir Ihnen, den Abdeckungsstatus regelmäßig zu überwachen und Fehler zu beheben, falls der Status **Fehlerhaft** ist. Alternativ können Sie eine EventBridge Amazon-Regel erstellen, die Sie benachrichtigt, wenn sich der Deckungsstatus von einem `Unhealthy` auf `Healthy` oder einem anderen Wert ändert. GuardDuty Veröffentlicht dies standardmäßig im [EventBridge Bus](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-event-bus.html) für Ihr Konto.
### Beispiel für ein Benachrichtigungsschema
In einer EventBridge Regel können Sie die vordefinierten Beispielereignisse und Ereignismuster verwenden, um eine Benachrichtigung über den Versicherungsstatus zu erhalten. Weitere Informationen zum Erstellen einer EventBridge Regel finden Sie unter [Regel erstellen](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html#eb-gs-create-rule) im * EventBridge Amazon-Benutzerhandbuch*.
Darüber hinaus können Sie mithilfe des folgenden Beispiel-Benachrichtigungsschemas ein benutzerdefiniertes Ereignismuster erstellen. Achten Sie darauf, die Werte für Ihr Konto zu ersetzen. Um benachrichtigt zu werden, wenn sich der Abdeckungsstatus Ihres Amazon EKS-Clusters von `Healthy` zu ändert`Unhealthy`, `detail-type` sollte dies der Fall sein*GuardDuty Runtime Protection Unhealthy*. Um benachrichtigt zu werden, wenn sich der Deckungsstatus von `Unhealthy` auf ändert`Healthy`, ersetzen Sie den Wert von `detail-type` durch*GuardDuty Runtime Protection Healthy*.
```
{
"version": "0",
"id": "event ID",
"detail-type": "GuardDuty Runtime Protection Unhealthy",
"source": "aws.guardduty",
"account": "AWS-Konto ID",
"time": "event timestamp (string)",
"region": "AWS-Region",
"resources": [
],
"detail": {
"schemaVersion": "1.0",
"resourceAccountId": "string",
"currentStatus": "string",
"previousStatus": "string",
"resourceDetails": {
"resourceType": "EKS",
"eksClusterDetails": {
"clusterName": "string",
"availableNodes": "string",
"desiredNodes": "string",
"addonVersion": "string"
}
},
"issue": "string",
"lastUpdatedAt": "timestamp"
}
}
```
## Behebung von Problemen mit der Amazon EKS-Runtime-Abdeckung
Wenn der Deckungsstatus für Ihren EKS-Cluster lautet`Unhealthy`, können Sie den entsprechenden Fehler entweder in der Spalte **Problem** in der GuardDuty Konsole oder mithilfe des [CoverageResource](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_CoverageResource.html)Datentyps anzeigen.
Wenn Sie mit Einschluss- oder Ausschluss-Tags arbeiten, um Ihre EKS-Cluster selektiv zu überwachen, kann es einige Zeit dauern, bis die Tags synchronisiert sind. Dies kann sich auf den Abdeckungsstatus des zugehörigen EKS-Clusters auswirken. Sie können erneut versuchen, das entsprechende Tag (Einschluss oder Ausschluss) zu entfernen und hinzuzufügen. Weitere Informationen finden Sie unter [Markieren Ihrer Amazon-EKS-Ressourcen](https://docs.aws.amazon.com/eks/latest/userguide/eks-using-tags.html) im **Amazon-EKS-Entwicklerhandbuch**.
Die Struktur eines Abdeckungsproblems ist `Issue type:Extra information`. In der Regel verfügen die Probleme über optionale *Zusatzinformationen*, die eine spezifische Ausnahme oder eine Beschreibung des Problems enthalten können. Basierend auf *zusätzlichen Informationen* enthalten die folgenden Tabellen die empfohlenen Schritte zur Behebung von Deckungsproblemen für Ihre EKS-Cluster.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/eks-runtime-monitoring-coverage.html)
**Schritte zur Fehlerbehebung bei einem creation/updation Addon-Fehler mit dem Addon-Problemcode**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/eks-runtime-monitoring-coverage.html)
# Einrichten der CPU- und Arbeitsspeicherüberwachung
Nachdem Sie Runtime Monitoring aktiviert und festgestellt haben, dass der Abdeckungsstatus Ihres Clusters **fehlerfrei** ist, können Sie die Insight-Metriken einrichten und anzeigen.
Anhand der folgenden Themen können Sie beurteilen, wie der bereitgestellte Agent im Vergleich zu den CPU- und Speicherlimits für den GuardDuty Agenten abschneidet.
## Überwachung auf dem Amazon ECS-Cluster einrichten
Mithilfe der folgenden Schritte aus dem * CloudWatch Amazon-Benutzerhandbuch* können Sie beurteilen, wie der bereitgestellte Agent im Vergleich zu den CPU- und Speicherlimits für den GuardDuty Agenten abschneidet:
1. [Einrichtung von Container Insights auf Amazon ECS für Metriken auf Cluster- und Service-Ebene](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-ECS-cluster.html)
1. [Amazon ECS Container Insights-Metriken](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-ECS.html)
## Überwachung auf dem Amazon EKS-Cluster einrichten
Nachdem der GuardDuty Security Agent bereitgestellt wurde und Sie festgestellt haben, dass der Schutzstatus Ihres Clusters **fehlerfrei** ist, können Sie die Container Insight-Metriken einrichten und anzeigen.
**Bewerten Sie die Leistung des Security Agents**
1. [Einrichtung von Container Insights auf Amazon EKS und Kubernetes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/deploy-container-insights-EKS.html) im *Amazon-Benutzerhandbuch CloudWatch *
1. [Kennzahlen zu Amazon EKS und Kubernetes Container Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Container-Insights-metrics-EKS.html) im *Amazon-Benutzerhandbuch CloudWatch *
**Verwalten Sie die Leistung mit dem Security Agent v1.5.0 und höher**
Bei Security Agent [v1.5.0 und höher](https://docs.aws.amazon.com/guardduty/latest/ug/runtime-monitoring-agent-release-history.html#eks-runtime-monitoring-agent-release-history) können Sie bestimmte Parameter konfigurieren, wenn die Erkenntnisse darauf hindeuten, dass der zugehörige GuardDuty Agent die zugewiesenen Grenzwerte erreicht. Weitere Informationen finden Sie unter [Konfigurieren Sie die Parameter für das EKS-Zusatz](guardduty-configure-security-agent-eks-addon.md).
# Gemeinsam genutzte VPC mit Runtime Monitoring verwenden
GuardDuty Runtime Monitoring unterstützt die Nutzung der gemeinsam genutzten Amazon Virtual Private Cloud (Amazon VPC) für Sie AWS-Konten , die derselben Organisation angehören. AWS Organizations Sie können gemeinsam genutzte VPC auf zwei Arten verwenden:
+ **Automatisierte Agentenkonfiguration (empfohlen)** — Wenn der Security Agent GuardDuty automatisch verwaltet wird, konfiguriert er auch die Amazon VPC-Endpunktrichtlinie. Diese Richtlinie basiert auf den gemeinsamen VPC-Einstellungen Ihrer Organisation.
Sie müssen die automatische Agentenkonfiguration im gemeinsamen VPC-Besitzerkonto und allen teilnehmenden Konten, die diese VPC gemeinsam nutzen, aktivieren.
+ **Manuell verwalteter Agent** — Wenn Sie den Security Agent manuell mit gemeinsam genutzter VPC verwalten, müssen Sie die VPC-Endpunktrichtlinie aktualisieren, damit die entsprechenden Konten auf die gemeinsam genutzte VPC zugreifen können. Dazu können Sie die Beispielrichtlinie verwenden, die im folgenden Abschnitt beschrieben wird. [Funktionsweise](#how-shared-vpc-works-runtime-monitoring-auto)
Bei manuellen Verwaltungsszenarien mit teilnehmenden Konten für gemeinsam genutzte VPC ist der Deckungsstatus möglicherweise nicht korrekt. Um den up-to-date Schutz und die Abdeckung Ihrer Ressourcen sicherzustellen, GuardDuty empfiehlt es sich, die automatische Agentenkonfiguration für alle Konten zu aktivieren, die gemeinsam genutzte VPC verwenden.
**Topics**
+ [Funktionsweise](#how-shared-vpc-works-runtime-monitoring-auto)
+ [Voraussetzungen für die Verwendung von Shared VPC](#shared-vpc-prerequisite-runtime-monitoring)
## Funktionsweise
Diejenigen AWS-Konten , die derselben Organisation angehören wie das gemeinsame Amazon VPC-Besitzerkonto, können sich auch denselben Amazon VPC-Endpunkt teilen. Jedes Konto, das dieselbe Amazon VPC-Endpunktrichtlinie verwendet, wird als ** AWS Teilnehmerkonto** der zugehörigen gemeinsamen Amazon VPC bezeichnet.
Das folgende Beispiel zeigt die Standard-VPC-Endpunktrichtlinie des gemeinsamen VPC-Besitzerkontos und des Teilnehmerkontos. Das `aws:PrincipalOrgID` zeigt die Organisations-ID an, die der gemeinsam genutzten VPC-Ressource zugeordnet ist. Die Verwendung dieser Richtlinie ist auf die Teilnehmerkonten beschränkt, die in der Organisation des Eigentümerkontos vorhanden sind.
**Example Beispiel für eine gemeinsam genutzte VPC-Endpunktrichtlinie**
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Action": "*",
"Resource": "*",
"Effect": "Allow",
"Principal": "*"
},
{
"Condition": {
"StringNotEquals": {
"aws:PrincipalOrgID": "o-abcdef0123"
}
},
"Action": "*",
"Resource": "*",
"Effect": "Deny",
"Principal": "*"
}
]
}
```
### Mit GuardDuty automatischer Agentenkonfiguration
Wenn das Besitzerkonto der gemeinsam genutzten VPC Runtime Monitoring und automatische Agentenkonfiguration für eine der Ressourcen (Amazon EKS oder AWS Fargate (nur Amazon ECS)) aktiviert, kommen alle gemeinsam genutzten VPCs Ressourcen für die automatische Installation des gemeinsamen Amazon VPC-Endpunkts und der zugehörigen Sicherheitsgruppe im gemeinsamen VPC-Eigentümerkonto in Frage. GuardDuty ruft die Organisations-ID ab, die mit der gemeinsam genutzten Amazon VPC verknüpft ist.
GuardDuty erstellt einen Amazon VPC-Endpunkt, wenn entweder das gemeinsame VPC-Eigentümerkonto oder das teilnehmende Konto ihn benötigt. Beispiele für die Notwendigkeit eines Amazon VPC-Endpunkts sind die Aktivierung GuardDuty, Runtime Monitoring, EKS Runtime Monitoring oder das Starten einer neuen Amazon ECS-Fargate-Aufgabe. Wenn diese Konten Runtime Monitoring und automatische Agentenkonfiguration für einen beliebigen Ressourcentyp aktivieren, GuardDuty wird ein Amazon VPC-Endpunkt erstellt und die Endpunktrichtlinie mit derselben Organisations-ID wie die des gemeinsamen VPC-Besitzerkontos festgelegt. GuardDuty fügt ein `GuardDutyManaged` Tag hinzu und setzt es `true` für den Amazon VPC-Endpunkt, der GuardDuty erstellt, auf. Wenn das gemeinsame Amazon VPC-Besitzerkonto weder Runtime Monitoring noch automatische Agentenkonfiguration für eine der Ressourcen aktiviert hat, GuardDuty wird die Amazon VPC-Endpunktrichtlinie nicht festgelegt. Informationen zur Konfiguration von Runtime Monitoring und zur automatischen Verwaltung des Security Agents im gemeinsamen VPC-Besitzerkonto finden Sie unter[GuardDuty Laufzeitüberwachung aktivieren](runtime-monitoring-configuration.md).
### Verwendung mit einem manuell verwalteten Agenten
Wenn Sie eine gemeinsam genutzte VPC mit einem manuell verwalteten Agenten verwenden, stellen Sie sicher, dass es keine explizite `Deny` Endpunktrichtlinie gibt, die jedes Konto blockiert, das die gemeinsam genutzte VPC verwenden muss. Dadurch wird verhindert, dass der Security Agent Telemetriedaten an sendet GuardDuty, was zu einem `Unhealthy` Empfangsstatus führt. Informationen zum Einrichten der Endpunktrichtlinie finden Sie unter[Example shared VPC endpoint policy](#guardduty-runtime-monitoring-shared-vpc-endpoint-policy-example).
In Szenarien wie fehlenden Berechtigungen für die gemeinsam genutzte VPC ist die Laufzeitabdeckung möglicherweise nicht korrekt. Sie können die Ressourcenabdeckung kontinuierlich überwachen, indem Sie die Schritte für Ihren Ressourcentyp befolgen. [Überprüfung der Statistiken zur Laufzeitabdeckung und Behebung von Problemen](runtime-monitoring-assessing-coverage.md)
Um den kontinuierlichen Runtime Monitoring-Schutz Ihrer Rechenressourcen zu gewährleisten, GuardDuty empfiehlt es sich, die automatische Agentenkonfiguration für das gemeinsame VPC-Besitzerkonto und alle beteiligten Konten für Ihre Ressourcen zu aktivieren.
## Voraussetzungen für die Verwendung von Shared VPC
Führen Sie im Rahmen der Ersteinrichtung die folgenden Schritte in dem aus AWS-Konto , dass Sie Eigentümer der gemeinsam genutzten VPC sein möchten:
1. **Organisation** erstellen — Erstellen Sie eine Organisation, indem Sie die Schritte unter [Organisation erstellen und verwalten](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_org.html) im *AWS Organizations Benutzerhandbuch befolgen*.
Informationen zum Hinzufügen oder Entfernen von Mitgliedskonten finden Sie unter [Verwaltung AWS-Konten in Ihrer Organisation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts.html).
1. **Eine gemeinsam genutzte VPC-Ressource** erstellen — Sie können eine gemeinsam genutzte VPC-Ressource über das Besitzerkonto erstellen. Weitere Informationen finden Sie unter [Teilen Sie Ihre VPC-Subnetze mit anderen Konten](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html) im *Amazon VPC-Benutzerhandbuch*.
### Spezifische Voraussetzungen für Runtime Monitoring GuardDuty
Die folgende Liste enthält die spezifischen Voraussetzungen für GuardDuty:
+ Das Besitzerkonto der gemeinsam genutzten VPC und das teilnehmende Konto können von verschiedenen Organisationen in GuardDuty stammen. Sie müssen jedoch derselben Organisation in AWS Organizations angehören. Dies ist erforderlich GuardDuty , um einen Amazon VPC-Endpunkt und eine Sicherheitsgruppe für die gemeinsam genutzte VPC zu erstellen. Informationen darüber, wie geteilte VPCs Arbeit funktioniert, finden Sie unter [Teilen Sie Ihre VPC mit anderen Konten](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-sharing.html) im *Amazon VPC-Benutzerhandbuch*.
+ Aktivieren Sie Runtime Monitoring oder EKS Runtime Monitoring und die GuardDuty automatische Agentenkonfiguration für jede Ressource im gemeinsamen VPC-Besitzerkonto und im Teilnehmerkonto. Weitere Informationen finden Sie unter [Laufzeitüberwachung aktivieren](runtime-monitoring-configuration.md).
Wenn Sie diese Konfigurationen bereits abgeschlossen haben, fahren Sie mit dem nächsten Schritt fort.
+ Wenn Sie entweder mit einer Amazon EKS- oder einer Amazon ECS-Aufgabe (AWS Fargate nur) arbeiten, stellen Sie sicher, dass Sie die gemeinsam genutzte VPC-Ressource auswählen, die dem Besitzerkonto zugeordnet ist, und wählen Sie deren Subnetze aus.
# Verwendung von Infrastructure as Code (IaC) mit GuardDuty automatisierten Sicherheitsagenten
Verwenden Sie diesen Abschnitt nur, wenn die folgende Liste auf Ihren Anwendungsfall zutrifft:
+ Sie verwenden Infrastructure-as-Code-Tools (IaC) wie Terraform, um Ihre AWS Ressourcen zu verwalten, AWS Cloud Development Kit (AWS CDK) und
+ Sie müssen die GuardDuty automatische Agentenkonfiguration für einen oder mehrere Ressourcentypen aktivieren — Amazon EKS, Amazon EC2 oder Amazon ECS-Fargate.
## Diagramm zur Abhängigkeit von IaC-Ressourcen
Wenn Sie die GuardDuty automatische Agentenkonfiguration für einen Ressourcentyp aktivieren, GuardDuty werden automatisch ein VPC-Endpunkt und eine diesem VPC-Endpunkt zugeordnete Sicherheitsgruppe erstellt und der Security Agent für diesen Ressourcentyp installiert. Standardmäßig GuardDuty werden der VPC-Endpunkt und die zugehörige Sicherheitsgruppe erst gelöscht, nachdem Sie Runtime Monitoring deaktiviert haben. Weitere Informationen finden Sie unter [Ressourcen in Runtime Monitoring deaktivieren, deinstallieren und bereinigen](runtime-monitoring-agent-resource-clean-up.md).
Wenn Sie ein IaC-Tool verwenden, verwaltet es ein Abhängigkeitsdiagramm der Ressourcen. Zum Zeitpunkt des Löschens von Ressourcen mithilfe des IaC-Tools werden nur Ressourcen gelöscht, die als Teil des Abhängigkeitsdiagramms von Ressourcen nachverfolgt werden können. IaC-Tools wissen möglicherweise nichts über die Ressourcen, die außerhalb ihrer angegebenen Konfiguration erstellt wurden. Sie erstellen beispielsweise eine VPC mit einem IaC-Tool und fügen dieser VPC dann mithilfe einer AWS Konsole oder einer API-Operation eine Sicherheitsgruppe hinzu. Im Diagramm der Ressourcenabhängigkeit hängt die VPC-Ressource, die Sie erstellen, von der zugehörigen Sicherheitsgruppe ab. Wenn Sie diese VPC-Ressource mit dem IaC-Tool löschen, wird eine Fehlermeldung angezeigt. Sie können diesen Fehler umgehen, indem Sie die zugehörige Sicherheitsgruppe manuell löschen oder die IaC-Konfiguration so aktualisieren, dass sie diese hinzugefügte Ressource enthält.
## Häufiges Problem — Löschen von Ressourcen in IaC
Wenn Sie die GuardDuty automatische Agentenkonfiguration verwenden, möchten Sie möglicherweise eine Ressource (Amazon EKS, Amazon EC2 oder Amazon ECS-Fargate) löschen, die Sie mithilfe eines IaC-Tools erstellt haben. Diese Ressource ist jedoch von einem VPC-Endpunkt abhängig, der GuardDuty erstellt wurde. Dadurch wird verhindert, dass das IaC-Tool die Ressource selbst löscht, und Sie müssen Runtime Monitoring deaktivieren, wodurch der VPC-Endpunkt weiterhin automatisch gelöscht wird.
Wenn Sie beispielsweise versuchen, den VPC-Endpunkt zu löschen, der in Ihrem Namen GuardDuty erstellt wurde, erhalten Sie eine Fehlermeldung, die den folgenden Beispielen ähnelt.
**Example**
**Beispiel für einen Fehler bei der Verwendung von CDK**
```
The following resource(s) failed to delete: [mycdkvpcapplicationpublicsubnet1Subnet1SubnetEXAMPLE1, mycdkvpcapplicationprivatesubnet1Subnet2SubnetEXAMPLE2].
Resource handler returned message: "The subnet 'subnet-APKAEIVFHP46CEXAMPLE' has dependencies and cannot be deleted. (Service: Ec2, Status Code: 400, Request ID: e071c3c5-7442-4489-838c-0dfc6EXAMPLE)" (RequestToken: 4381cff8-6240-208a-8357-5557b7EXAMPLE, HandlerErrorCode: InvalidRequest)
```
**Example**
**Fehlerbeispiel bei der Verwendung von Terraform**
```
module.vpc.aws_subnet.private[1]: Still destroying... [id=subnet-APKAEIVFHP46CEXAMPLE, 19m50s elapsed]
module.vpc.aws_subnet.private[1]: Still destroying... [id=subnet-APKAEIVFHP46CEXAMPLE, 20m0s elapsed]
Error: deleting EC2 Subnet (subnet-APKAEIBAERJR2EXAMPLE): DependencyViolation: The subnet 'subnet-APKAEIBAERJR2EXAMPLE' has dependencies and cannot be deleted.
status code: 400, request id: e071c3c5-7442-4489-838c-0dfc6EXAMPLE
```
### Lösung - Vermeiden Sie das Problem beim Löschen von Ressourcen
In diesem Abschnitt können Sie den VPC-Endpunkt und die Sicherheitsgruppe unabhängig von GuardDuty verwalten.
Führen Sie die folgenden Schritte in der angegebenen Reihenfolge aus, um die vollständige Kontrolle über die Ressourcen zu erlangen, die mithilfe des IaC-Tools konfiguriert wurden:
1. Erstellen Sie eine VPC. Um Eingangsberechtigungen zuzulassen, ordnen Sie dieser GuardDuty VPC einen VPC-Endpunkt mit der Sicherheitsgruppe zu.
1. Aktivieren Sie die GuardDuty automatische Agentenkonfiguration für Ihren Ressourcentyp
Nachdem Sie die vorherigen Schritte abgeschlossen haben, erstellt GuardDuty es keinen eigenen VPC-Endpunkt und verwendet den, den Sie mit dem IaC-Tool erstellt haben, erneut.
Informationen zum Erstellen Ihrer eigenen VPC finden Sie unter [Eine VPC nur in den *Amazon VPC* Transit Gateways erstellen](https://docs.aws.amazon.com/vpc/latest/userguide/create-vpc.html#create-vpc-only). Informationen zum Erstellen eines VPC-Endpunkts finden Sie im folgenden Abschnitt für Ihren Ressourcentyp:
+ Informationen zu Amazon EC2 finden Sie unter[Voraussetzung — Manuelles Erstellen eines Amazon VPC-Endpunkts](creating-vpc-endpoint-ec2-agent-manually.md).
+ Informationen zu Amazon EKS finden Sie unter[Voraussetzung — Erstellen eines Amazon VPC-Endpunkts](eksrunmon-prereq-deploy-security-agent.md).
# Gesammelte Laufzeit-Ereignistypen, die GuardDuty verwendet
Der GuardDuty Security Agent sammelt die folgenden Ereignistypen und sendet sie zur Erkennung und Analyse von Bedrohungen an das GuardDuty Backend. GuardDuty macht Ihnen diese Ereignisse nicht zugänglich. Wenn eine potenzielle Bedrohung GuardDuty erkannt und eine generiert wird[Runtime Monitoring findet Typen](findings-runtime-monitoring.md), können Sie die entsprechenden Ergebnisdetails einsehen.
Hinweise zur GuardDuty Verwendung der gesammelten Ereignistypen in Runtime Monitoring finden Sie unter[Abmeldung von der Verwendung Ihrer Daten zur Serviceverbesserung](guardduty-opting-out-using-data.md).
## Ereignisse verarbeiten
Prozessereignisse stellen Informationen dar, die mit den Prozessen verknüpft sind, die auf Amazon EC2 EC2-Instances und Container-Workloads ausgeführt werden. Die folgende Tabelle enthält die Feldnamen und Beschreibungen der Prozessereignisse, die Runtime Monitoring erfasst, um potenzielle Bedrohungen zu erkennen.
| Feldname | Description |
| --- | --- |
| Prozessname | Name des beobachteten Prozesses. |
| Prozesspfad | Absoluter Pfad der ausführbaren Datei des Prozesses. |
| Prozess-ID | Die ID, die dem Prozess vom Betriebssystem zugewiesen wurde. |
| Namespace-PID | Die Prozess-ID des Prozesses in einem sekundären PID-Namespace, bei dem es sich nicht um den PID-Namespace auf Host-Ebene handelt. Bei Prozessen innerhalb eines Containers ist dies die Prozess-ID, die innerhalb des Containers beobachtet wird. |
| Prozess-Benutzer-ID | Die eindeutige ID des Benutzers, der den Prozess ausgeführt hat. |
| Prozess-UUID | Die eindeutige ID, die dem Prozess von zugewiesen wurde GuardDuty. |
| Prozess-GID | Prozess-ID der Prozessgruppe. |
| Prozess-EGID | Effektive Gruppen-ID der Prozessgruppe. |
| Prozess-EUID | Effektive Benutzer-ID des Prozesses. |
| Prozess-Benutzername | Der Benutzername, der den Prozess ausgeführt hat. |
| Prozesses-Startzeit | Die Zeit, zu der der Prozess erstellt wurde. Dieses Feld hat das UTC-Datums-Zeichenfolgenformat (`2023-03-22T19:37:20.168Z`). |
| Ausführbare Prozessdatei SHA-256 | Der Hash `SHA256` der ausführbaren Prozessesdatei. |
| Prozess-Skriptpfad | Pfad der Skriptdatei, die ausgeführt wurde. |
| Prozess-Umgebungsvariable | Die Umgebungsvariable, die dem Prozess zur Verfügung gestellt wurde. Nur `LD_PRELOAD` und `LD_LIBRARY_PATH` werden gesammelt. |
| Aktuelles Arbeitsverzeichnis (PWD) des Prozesses | Derzeitiges Arbeitsverzeichnis des Prozesses. |
| Übergeordneter Prozess | Prozessdetails des übergeordneten Prozesses. Ein übergeordneter Prozess ist ein Prozess, der den beobachteten Prozess erzeugt hat. |
| Befehlszeilenargumente Derzeit ist dieses Feld auf bestimmte Agentenversionen beschränkt, die dem Ressourcentyp entsprechen: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/runtime-monitoring-collected-events.html) Weitere Informationen finden Sie unter [GuardDuty Release-Versionen des Security Agents](runtime-monitoring-agent-release-history.md). | Befehlszeilenargumente, die zum Zeitpunkt der Prozessausführung bereitgestellt wurden. Dieses Feld kann sensible Kundendaten enthalten. |
## Container-Ereignisse
Container-Ereignisse stellen Informationen dar, die mit Aktivitäten der Container-Workloads verknüpft sind. Die folgende Tabelle enthält die Feldnamen und Beschreibungen der Container-Workload-Ereignisse, die Runtime Monitoring erfasst, um potenzielle Bedrohungen zu erkennen.
| Feldname | Description |
| --- | --- |
| Container-Name | Name des Containers. Falls verfügbar, zeigt dieses Feld den Wert des Labels `io.kubenetes.container.name` an. |
| Container-UID | Die eindeutige ID des Containers, die von der Container-Laufzeit zugewiesen wurde. |
| Container-Laufzeit | Die Container-Laufzeit (wie z. B. `docker` oder `containerd`), die zum Ausführen des Containers verwendet wurde. |
| Container-Image-ID | Die ID des Container-Images. |
| Container-Image-Name | Name des Container-Images. |
## AWS Fargate (nur Amazon ECS) Aufgabenereignisse
Fargate-Amazon ECS-Aufgabenereignisse stellen Aktivitäten dar, die mit Amazon ECS-Aufgaben verknüpft sind, die auf Fargate-Computern ausgeführt werden. Die folgende Tabelle enthält die Feldnamen und Beschreibungen der Amazon ECS-Fargate-Task-Ereignisse, die Runtime Monitoring sammelt, um potenzielle Bedrohungen zu erkennen.
| Feldname | Description |
| --- | --- |
| Amazon-Ressourcenname (ARN) der Aufgabe | Der ARN der Aufgabe. |
| Cluster-Name | Der Name des Amazon ECS-Clusters. |
| Familienname | Der Familienname der Aufgabendefinition. Der `family` wird als Name für die Aufgabendefinition verwendet, mit der die Aufgabe gestartet wird. |
| Service-Name | Der Name des Amazon ECS-Service, wenn die Aufgabe als Teil eines Services gestartet wurde. |
| Starttyp | Die Infrastruktur, auf der Ihre Aufgabe ausgeführt wird. Für Runtime Monitoring mit dem Ressourcentyp as `ECSCluster` könnte der Starttyp entweder `EC2` oder sein`FARGATE`. |
| CPU | Die Anzahl der von der Aufgabe verwendeten CPU-Einheiten, wie in der Aufgabendefinition angegeben. |
## Kubernetes-Pod-Ereignisse
Die folgende Tabelle enthält die Feldnamen und Beschreibungen der Kubernetes-Pod-Ereignisse, die Runtime Monitoring erfasst, um potenzielle Bedrohungen zu erkennen.
| Feldname | Description |
| --- | --- |
| Pod-ID | Die ID des Kubernetes-Pods. |
| Pod-Name | Name des Kubernetes-Pods. |
| Pod-Namespace | Name des Kubernetes-Namespace, zu dem der Kubernetes-Workload gehört. |
| Kubernetes-Cluster-Name | Name des Kubernetes-Clusters. |
## DNS-Ereignisse (Domain Name System)
Die DNS-Ereignisse (Domain Name System) enthalten Details zu den DNS-Abfragen, die von Ihren Ressourcentypen gestellt wurden, und zu den entsprechenden Antworten. Die folgende Tabelle enthält die Feldnamen und Beschreibungen der DNS-Ereignisse, die Runtime Monitoring erfasst, um potenzielle Bedrohungen zu erkennen.
| Feldname | Description |
| --- | --- |
| Socket-Typ | Socket-Typ zur Angabe der Kommunikationssemantik. Beispiel, `SOCK_RAW`. |
| Adress-Familie | Stellt das der Adresse zugeordnete Kommunikationsprotokoll dar. Die Adressfamilie `AF_INET` wird beispielsweise für das IP-v4-Protokoll verwendet. |
| Richtungs-ID | Die ID der Verbindungsrichtung. |
| Protokollnummer | Die Layer-4-Protokollnummer, z. B. 17 für UDP und 6 für TCP. |
| DNS-Remote-Endpunkt-IP | Die Remote-IP-Informationen der Verbindung. |
| DNS-Remote-Endpunkt-Port | Die Portnummer der Verbindung. |
| Lokale DNS-Endpunkt-IP | Die lokale IP der Verbindung. |
| Lokaler DNS-Endpunkt-Port | Die Portnummer der Verbindung. |
| DNS-Nutzlast | Die Nutzlast von DNS-Paketen, die DNS-Abfragen und -Antworten enthalten. |
## Offene Ereignisse
Offene Ereignisse stehen im Zusammenhang mit Dateizugriffen und Dateiänderungen. Die folgende Tabelle enthält die Feldnamen und Beschreibungen der offenen Ereignisse, die Runtime Monitoring erfasst, um potenzielle Bedrohungen zu erkennen.
| Feldname | Description |
| --- | --- |
| Dateipfad | Pfad der Datei, die in diesem Ereignis geöffnet wird. |
| Flags | Beschreibt den Dateizugriffsmodus, z. B. Schreibgeschützt, Nur-Schreiben und Lesen-Schreiben. |
## Lastmodul-Ereignis
Die folgende Tabelle enthält den Feldnamen und die Beschreibung des Lademodul-Ereignisses, das Runtime Monitoring erfasst, um potenzielle Bedrohungen zu erkennen.
| Feldname | Description |
| --- | --- |
| Modulname | Name des in den Kernel geladenen Moduls. |
## Mprotect-Ereignisse
Mprotect-Ereignisse liefern Informationen über Änderungen an den Speicherschutzeinstellungen der Prozesse, die auf den überwachten Systemen ausgeführt werden. Die folgende Tabelle enthält die Feldnamen und Beschreibungen der Mprotect-Ereignisse, die Runtime Monitoring erfasst, um potenzielle Bedrohungen zu erkennen.
| Feldname | Description |
| --- | --- |
| Adressbereiche | Der Adressbereich, für den der Zugriffsschutz geändert wurde. |
| Arbeitsspeicherregionen | Gibt die Region des Adressraums eines Prozesses an, z. B. Stapel und Heap. |
| Flags | Stellt Optionen dar, die das Verhalten dieses Ereignisses steuern. |
## Mount-Ereignisse
Mount-Ereignisse liefern Informationen im Zusammenhang mit dem Mounten und Unmounten von Dateisystemen auf Ihrer überwachten Ressource. Die folgende Tabelle enthält die Feldnamen und Beschreibungen der Mount-Ereignisse, die Runtime Monitoring sammelt, um potenzielle Bedrohungen zu erkennen.
| Feldname | Description |
| --- | --- |
| Mount-Ziel | Der Pfad, in dem die Mount-Quelle gemountet ist. |
| Mount-Quelle | Der Pfad auf dem Host, der am Mount-Ziel gemountet ist. |
| Typ des Dateisystems | Repräsentiert den Typ des bereitgestellten Dateisystems. |
| Flags | Stellt Optionen dar, die das Verhalten dieses Ereignisses steuern. |
## Verknüpfungs-Ereignisse
Link-Ereignisse bieten Einblick in die Link-Management-Aktivitäten im Dateisystem in Ihren überwachten Ressourcen. Die folgende Tabelle enthält die Feldnamen und Beschreibungen der Link-Ereignisse, die Runtime Monitoring erfasst, um potenzielle Bedrohungen zu erkennen.
| Feldname | Description |
| --- | --- |
| Verknüpfungs-Pfad | Pfad, in dem der Hardlink erstellt wird. |
| Zielpfad | Pfad der Datei, auf die der Hardlink verweist. |
## Symlink-Ereignisse
Symlink-Ereignisse bieten Einblick in die Aktivitäten zur Verwaltung symbolischer Links im Dateisystem in Ihren überwachten Ressourcen. Die folgende Tabelle enthält die Feldnamen und Beschreibungen der Symlink-Ereignisse, die Runtime Monitoring erfasst, um potenzielle Bedrohungen zu erkennen.
| Feldname | Description |
| --- | --- |
| Verknüpfungs-Pfad | Pfad, in dem der symbolische Link erstellt wird. |
| Zielpfad | Pfad der Datei, auf die der symbolische Link verweist. |
## Dup-Ereignisse
Dup-Ereignisse bieten Einblick in die Duplizierung von Dateideskriptoren durch Prozesse, die auf den überwachten Ressourcen ausgeführt werden. Die folgende Tabelle enthält die Feldnamen und Beschreibungen der Dup-Ereignisse, die Runtime Monitoring erfasst, um potenzielle Bedrohungen zu erkennen.
| Feldname | Description |
| --- | --- |
| Alter Dateideskriptor | Ein Dateideskriptor, der ein geöffnetes Dateiobjekt darstellt. |
| Neuer Dateideskriptor | Ein neuer Dateideskriptor, der ein Duplikat des alten Dateideskriptors ist. Sowohl der alte als auch der neue Dateideskriptor stehen für dasselbe offene Dateiobjekt. |
| DNS-Remote-Endpunkt-IP | Die Remote-IP-Adresse des Netzwerk-Sockets, dargestellt durch den alten Dateideskriptor. Gilt nur, wenn der alte Dateideskriptor einen Netzwerk-Socket darstellt. |
| DNS-Remote-Endpunkt-Port | Die Remote-IP-Adresse des Netzwerk-Sockets, dargestellt durch den alten Dateideskriptor. Gilt nur, wenn der alte Dateideskriptor einen Netzwerk-Socket darstellt. |
| Lokale Dup-Endpunkt-IP | Die lokale IP-Adresse des Netzwerk-Sockets, dargestellt durch den alten Dateideskriptor. Gilt nur, wenn der alte Dateideskriptor einen Netzwerk-Socket darstellt. |
| Lokaler Dup-Endpunkt-Port | Der lokale Port des Netzwerk-Sockets, dargestellt durch den alten Dateideskriptor. Gilt nur, wenn der alte Dateideskriptor einen Netzwerk-Socket darstellt. |
## Arbeitsspeicherzuordnungs-Ereignis
Die folgende Tabelle enthält den Feldnamen und eine Beschreibung der Speicherzuordnungsereignisse, die Runtime Monitoring erfasst, um potenzielle Bedrohungen zu erkennen.
| Feldname | Description |
| --- | --- |
| Dateipfad | Pfad der Datei, der der Arbeitsspeicher zugeordnet ist. |
## Socket-Ereignisse
Socket-Ereignisse liefern Informationen über die Netzwerk-Socket-Verbindungen, die für die Aktivitäten der überwachten Ressourcen verwendet werden. Die folgende Tabelle enthält die Feldnamen und Beschreibungen der Socket-Ereignisse, die Runtime Monitoring erfasst, um potenzielle Bedrohungen zu erkennen.
| Feldname | Description |
| --- | --- |
| Adress-Familie | Stellt das der Adresse zugeordnete Kommunikationsprotokoll dar. Die Adressfamilie `AF_INET` wird beispielsweise für das IP-v4-Protokoll verwendet. |
| Socket-Typ | Socket-Typ zur Angabe der Kommunikationssemantik. Beispiel, `SOCK_RAW`. |
| Protokollnummer | Spezifiziert ein bestimmtes Protokoll innerhalb der Adressfamilie. Normalerweise gibt es ein einziges Protokoll in Adressfamilien. Beispielsweise hat die Adressfamilie `AF_INET` nur das IP-Protokoll. |
## Verbindungs-Ereignisse
Connect-Ereignisse bieten Einblick in die Netzwerkverbindungen, die durch die Prozesse auf Ihren überwachten Ressourcen hergestellt wurden. Die folgende Tabelle enthält die Feldnamen und Beschreibungen der Verbindungsereignisse, die Runtime Monitoring erfasst, um potenzielle Bedrohungen zu erkennen.
| Feldname | Description |
| --- | --- |
| Adress-Familie | Stellt das der Adresse zugeordnete Kommunikationsprotokoll dar. Die Adressfamilie `AF_INET` wird beispielsweise für das IP-v4-Protokoll verwendet. |
| Socket-Typ | Socket-Typ zur Angabe der Kommunikationssemantik. Beispiel, `SOCK_RAW`. |
| Protokollnummer | Spezifiziert ein bestimmtes Protokoll innerhalb der Adressfamilie. Normalerweise gibt es ein einziges Protokoll in Adressfamilien. Beispielsweise hat die Adressfamilie `AF_INET` nur das IP-Protokoll. |
| Dateipfad | Pfad der Socket-Datei, falls die Adressfamilie `AF_UNIX` ist. |
| Remote-Endpunkt-IP | Die Remote-IP-Informationen der Verbindung. |
| Remote-Endpunkt-Port | Die Portnummer der Verbindung. |
| Lokale Endpunkt-IP | Die lokale IP der Verbindung. |
| Lokaler Endpunkt-Port | Die Portnummer der Verbindung. |
## Prozess-VM-Readv-Ereignisse
Readv-Ereignisse von Process VM bieten Einblick in die Lesevorgänge, die von den Prozessen in ihren eigenen virtuellen Speicherbereichen ausgeführt werden. Die folgende Tabelle enthält die Feldnamen und Beschreibungen der Prozess-VM-Readv-Ereignisse, die Runtime Monitoring erfasst, um potenzielle Bedrohungen zu erkennen.
| Feldname | Description |
| --- | --- |
| Flags | Stellt Optionen dar, die das Verhalten dieses Ereignisses steuern. |
| Ziel-PID | Prozess-ID des Prozesses, aus dessen Arbeitsspeicher gelesen wird. |
| UUID des Zielprozesses | Die eindeutige ID des Zielprozesses. |
| Pfad der ausführbaren Zieldatei | Absoluter Pfad der ausführbaren Zieldatei des Prozesses. |
## Prozess-VM-Writev-Ereignisse
Process VM-Writev-Ereignisse bieten Einblick in die Schreibvorgänge, die von den Prozessen in ihren eigenen virtuellen Speicherbereichen ausgeführt werden. Die folgende Tabelle enthält die Feldnamen und Beschreibungen der Prozess-VM-Writev-Ereignisse, die Runtime Monitoring erfasst, um potenzielle Bedrohungen zu erkennen.
| Feldname | Description |
| --- | --- |
| Flags | Stellt Optionen dar, die das Verhalten dieses Ereignisses steuern. |
| Ziel-PID | Prozess-ID des Prozesses, in den Arbeitsspeicher geschrieben wird. |
| UUID des Zielprozesses | Die eindeutige ID des Zielprozesses. |
| Pfad der ausführbaren Zieldatei | Absoluter Pfad der ausführbaren Zieldatei des Prozesses. |
## Prozessablaufverfolgungsereignisse (Ptrace)
Der Systemaufruf Process Trace (Ptrace) ist ein Debugging- und Ablaufverfolgungsmechanismus, der es einem Prozess (Tracer) ermöglicht, die Ausführung eines anderen Prozesses (Tracee) zu beobachten und zu kontrollieren. Dadurch kann der Tracer den Speicher, die Register und den Ausführungsablauf des Zielprozesses überprüfen und ändern.
Ptrace-Ereignisse bieten Einblick in die Verwendung des Ptrace-Systemaufrufs durch Prozesse, die auf den überwachten Ressourcen laufen. Die folgende Tabelle enthält die Feldnamen und Beschreibungen der Ptrace-Ereignisse, die Runtime Monitoring sammelt, um potenzielle Bedrohungen zu erkennen.
| Feldname | Description |
| --- | --- |
| Ziel-PID | Prozess-ID des Zielprozesses. |
| UUID des Zielprozesses | Die eindeutige ID des Zielprozesses. |
| Pfad der ausführbaren Zieldatei | Absoluter Pfad der ausführbaren Zieldatei des Prozesses. |
| Flags | Stellt Optionen dar, die das Verhalten dieses Ereignisses steuern. |
## Ereignisse binden
Bindungsereignisse bieten Einblick in die Bindung von Netzwerk-Sockets durch Prozesse, die auf den überwachten Ressourcen ausgeführt werden. Die folgende Tabelle enthält die Feldnamen und Beschreibungen der Bind-Ereignisse, die Runtime Monitoring sammelt, um potenzielle Bedrohungen zu erkennen.
| Feldname | Description |
| --- | --- |
| Adress-Familie | Stellt das der Adresse zugeordnete Kommunikationsprotokoll dar. Die Adressfamilie `AF_INET` wird beispielsweise für das IP-v4-Protokoll verwendet. |
| Socket-Typ | Socket-Typ zur Angabe der Kommunikationssemantik. Beispiel, `SOCK_RAW`. |
| Protokollnummer | Die Layer-4-Protokollnummer, z. B. 17 für UDP und 6 für TCP. |
| Lokale Endpunkt-IP | Die lokale IP der Verbindung. |
| Lokaler Endpunkt-Port | Die Portnummer der Verbindung. |
## Ereignisse abhören
Listen-Ereignisse geben Aufschluss über den Empfangsstatus von Netzwerk-Sockets und geben an, ob ein Netzwerk-Socket bereit ist, eingehende Verbindungen anzunehmen. Ein Prozess, der auf Ihrer überwachten Ressource ausgeführt wird, versetzt den Netzwerk-Socket in einen Listening-Status. Die folgende Tabelle enthält die Feldnamen und Beschreibungen der Listen-Ereignisse, die Runtime Monitoring sammelt, um potenzielle Bedrohungen zu erkennen.
| Feldname | Description |
| --- | --- |
| Adress-Familie | Stellt das der Adresse zugeordnete Kommunikationsprotokoll dar. Die Adressfamilie `AF_INET` wird beispielsweise für das IP-v4-Protokoll verwendet. |
| Socket-Typ | Socket-Typ zur Angabe der Kommunikationssemantik. Beispiel, `SOCK_RAW`. |
| Protokollnummer | Die Layer-4-Protokollnummer, z. B. 17 für UDP und 6 für TCP. |
| Lokale Endpunkt-IP | Die lokale IP der Verbindung. |
| Lokaler Endpunkt-Port | Die Portnummer der Verbindung. |
## Ereignisse umbenennen
Umbenennungsereignisse liefern Informationen über das Umbenennen von Dateien und Verzeichnissen durch Prozesse, die auf den überwachten Ressourcen ausgeführt werden. Die folgende Tabelle enthält die Feldnamen und Beschreibungen der Umbenennungsereignisse, die Runtime Monitoring erfasst, um potenzielle Bedrohungen zu erkennen.
| Feldname | Description |
| --- | --- |
| Dateipfad | Pfad, in dem die Datei umbenannt wurde. |
| Target | Der neue Pfad der Datei. |
## Legen Sie Benutzer-ID-Ereignisse (UID) fest
Ereignisse mit festgelegter Benutzer-ID (UID) bieten Einblick in die Änderungen, die an der Benutzer-ID (UID) vorgenommen wurden, die mit den laufenden Prozessen auf Ihren überwachten Ressourcen verknüpft sind. Die folgende Tabelle enthält die Feldnamen und Beschreibungen der festgelegten UID-Ereignisse, die Runtime Monitoring erfasst, um potenzielle Bedrohungen zu erkennen.
| Feldname | Description |
| --- | --- |
| Neue EUID | Die neue effektive Benutzer-ID des Prozesses. |
| Neue UID | Die neue Benutzer-ID des Prozesses. |
## Chmod-Ereignisse
Chmod-Ereignisse bieten Einblick in die Änderungen der Berechtigungen (Modus) von Dateien und Verzeichnissen auf den überwachten Ressourcen. Die folgende Tabelle enthält die Feldnamen und Beschreibungen der Chmod-Ereignisse, die Runtime Monitoring erfasst, um potenzielle Bedrohungen zu erkennen.
| Feldname | Description |
| --- | --- |
| Dateipfad | Pfad der Datei, die dieses Ereignis auslöst. |
| Dateimodus | Die aktualisierten Zugriffsberechtigungen für die zugehörige Datei. |
# GuardDuty Hosting-Agent für Amazon ECR Repositorys
In den folgenden Abschnitten sind die Amazon Elastic Container Registry (Amazon ECR) -Repositorys aufgeführt, in denen der Sicherheitsagent GuardDuty gehostet wird, der auf Ihren Amazon EKS- und Amazon ECS-Clustern bereitgestellt wird.
Voraussetzung dafür ist, [Voraussetzungen für den Zugriff auf Container-Images](prereq-runtime-monitoring-ecs-support.md#before-enable-runtime-monitoring-ecs) dass Sie eine Aufgabenausführungsrolle angeben, die über bestimmte Amazon Elastic Container Registry (Amazon ECR) -Berechtigungen verfügt. Um diese Berechtigungen weiter einzuschränken, können Sie den Amazon ECR-Repository-URI hinzufügen, der den GuardDuty Agenten für Fargate-Amazon ECS-Ressourcen hostet.
**Topics**
+ [ECR-Repository für die EKS-Agentenversionen 1.12.1 — 1.8.1 (eks.build.2)](eks-runtime-agent-ecr-image-uri-v1-8-1-build-2.md)
+ [ECR-Repository für EKS Agent Version 1.8.1 () `eks.build.1`](eks-runtime-agent-ecr-image-uri-v1-8-1-build-1.md)
+ [ECR-Repository für GuardDuty Agenten auf AWS Fargate (nur Amazon ECS)](ecs-runtime-agent-ecr-image-uri.md)
# ECR-Repository für die EKS-Agentenversionen 1.12.1 — 1.8.1 (eks.build.2)
Wenn Sie die GuardDuty automatische Konfiguration für Runtime Monitoring for EKS aktivieren, GuardDuty wird diese Agentenversion auf Ihren Amazon EKS-Clustern bereitgestellt. Informationen zur Aktivierung von Automated Agents finden Sie unter[Automatisches Verwalten des Security Agents für Amazon EKS-Ressourcen](managing-gdu-agent-eks-automatically.md).
Die folgende Tabelle zeigt das Amazon ECR-Repository, URIs in dem die GuardDuty Security Agent-Versionen`1.12.1.eks.build.2`,`1.11.0.eks.build.2`, `1.10.0.eks.build.2``1.9.0.eks.build.2`, und `1.8.0.eks.build.2` für Amazon EKS gehostet werden.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/eks-runtime-agent-ecr-image-uri-v1-8-1-build-2.html)
# ECR-Repository für EKS Agent Version 1.8.1 () `eks.build.1`
Dieser Abschnitt enthält das Amazon ECR-Repository für den Amazon EKS-Agenten Version **1.8.1 (v1.8.1-eks-build.1**). Wenn Sie v1.8.1-eks-build.1 verwenden, empfiehlt es sich, zur Standard-Agentenversion zu wechseln, bei der es sich in der Regel um die neueste Agentenversion handelt. GuardDuty Identifizieren Sie dazu den neuesten Agenten von und führen Sie dann die Schritte unter aus[Veröffentlichte Agentenversionen für Amazon EKS-Ressourcen](runtime-monitoring-agent-release-history.md#eks-runtime-monitoring-agent-release-history). [Manuelles Aktualisieren des Security Agents für Amazon EKS-Ressourcen](eksrunmon-update-security-agent.md)
Die folgende Tabelle zeigt das Amazon ECR-Repository, URIs in dem die GuardDuty Security Agent-Version `1.8.1-eks-build.1` für Amazon EKS gehostet wird.
| **AWS-Region** | **Amazon-ECR-Repository-URI** |
| --- | --- |
| USA West (Oregon) | `039403964562.dkr.ecr.us-west-2.amazonaws.com` |
| Europa (Paris) | `113643092156.dkr.ecr.eu-west-3.amazonaws.com` |
| Asien-Pazifik (Mumbai) | `610108029387.dkr.ecr.ap-south-1.amazonaws.com` |
| Asien-Pazifik (Hyderabad) | `618745550137.dkr.ecr.ap-south-2.amazonaws.com` |
| Kanada (Zentral) | `001188825231.dkr.ecr.ca-central-1.amazonaws.com` |
| Naher Osten (VAE) | `601769779514.dkr.ecr.me-central-1.amazonaws.com` |
| Europa (London) | `109118265657.dkr.ecr.eu-west-2.amazonaws.com` |
| USA West (Nordkalifornien) | `373421517865.dkr.ecr.us-west-1.amazonaws.com` |
| USA Ost (Nord-Virginia) | `031903291036.dkr.ecr.us-east-1.amazonaws.com` |
| USA Ost (Ohio) | `591382732059.dkr.ecr.us-east-2.amazonaws.com` |
| Europa (Irland) | `673884943994.dkr.ecr.eu-west-1.amazonaws.com` |
| Südamerika (São Paulo) | `941219317354.dkr.ecr.sa-east-1.amazonaws.com` |
| Europa (Stockholm) | `366771026645.dkr.ecr.eu-north-1.amazonaws.com` |
| Europa (Frankfurt) | `409493279830.dkr.ecr.eu-central-1.amazonaws.com` |
| Europa (Zürich) | `718440343717.dkr.ecr.eu-central-2.amazonaws.com` |
| Asien-Pazifik (Singapur) | `584580519942.dkr.ecr.ap-southeast-1.amazonaws.com` |
| Asien-Pazifik (Sydney) | `011662287384.dkr.ecr.ap-southeast-2.amazonaws.com` |
| Asien-Pazifik (Jakarta) | `617474730032.dkr.ecr.ap-southeast-3.amazonaws.com` |
| Asien-Pazifik (Tokio) | `781592569369.dkr.ecr.ap-northeast-1.amazonaws.com` |
| Asien-Pazifik (Seoul) | `732248494576.dkr.ecr.ap-northeast-2.amazonaws.com` |
| Asien-Pazifik (Osaka) | `810724417379.dkr.ecr.ap-northeast-3.amazonaws.com` |
| Asien-Pazifik (Hongkong) | `790429075973.dkr.ecr.ap-east-1.amazonaws.com` |
| Middle East (Bahrain) | `541829937850.dkr.ecr.me-south-1.amazonaws.com` |
| Europa (Milan) | `528450769569.dkr.ecr.eu-south-1.amazonaws.com` |
| Europa (Spain) | `531047660167.dkr.ecr.eu-south-2.amazonaws.com` |
| Afrika (Kapstadt) | `379032919888.dkr.ecr.af-south-1.amazonaws.com` |
| Asien-Pazifik (Melbourne) | `750462861327.dkr.ecr.ap-southeast-4.amazonaws.com` |
| Israel (Tel Aviv) | `292660727137.dkr.ecr.il-central-1.amazonaws.com` |
# ECR-Repository für GuardDuty Agenten auf AWS Fargate (nur Amazon ECS)
Als Voraussetzung für die Verwendung von Runtime Monitoring für Amazon ECS-Fargate müssen Sie. [Voraussetzungen für den Zugriff auf Container-Images](prereq-runtime-monitoring-ecs-support.md#before-enable-runtime-monitoring-ecs) Das GuardDuty Agent-Sidecar-Container-Image wird in Amazon ECR gespeichert, und die Bildebenen werden in Amazon S3 gespeichert. Weitere Informationen finden Sie unter [So funktioniert Runtime Monitoring mit Fargate (nur Amazon ECS)](how-runtime-monitoring-works-ecs-fargate.md).
Die folgende Tabelle zeigt die Amazon ECR-Repositorys, die jeweils den GuardDuty Agenten für AWS Fargate (nur Amazon ECS) hosten. AWS-Region
| **AWS-Region** | **Amazon-ECR-Repository-URI** |
| --- | --- |
| USA West (Oregon) | `733349766148.dkr.ecr.us-west-2.amazonaws.com/aws-guardduty-agent-fargate` |
| Europa (Paris) | `665651866788.dkr.ecr.eu-west-3.amazonaws.com/aws-guardduty-agent-fargate` |
| Asien-Pazifik (Mumbai) | `251508486986.dkr.ecr.ap-south-1.amazonaws.com/aws-guardduty-agent-fargate` |
| Asien-Pazifik (Hyderabad) | `950823858135.dkr.ecr.ap-south-2.amazonaws.com/aws-guardduty-agent-fargate` |
| Kanada (Zentral) | `354763396469.dkr.ecr.ca-central-1.amazonaws.com/aws-guardduty-agent-fargate` |
| Naher Osten (VAE) | `000014521398.dkr.ecr.me-central-1.amazonaws.com/aws-guardduty-agent-fargate` |
| Europa (London) | `892757235363.dkr.ecr.eu-west-2.amazonaws.com/aws-guardduty-agent-fargate` |
| USA West (Nordkalifornien) | `684579721401.dkr.ecr.us-west-1.amazonaws.com/aws-guardduty-agent-fargate` |
| USA Ost (Nord-Virginia) | `593207742271.dkr.ecr.us-east-1.amazonaws.com/aws-guardduty-agent-fargate` |
| USA Ost (Ohio) | `307168627858.dkr.ecr.us-east-2.amazonaws.com/aws-guardduty-agent-fargate` |
| Europa (Irland) | `694911143906.dkr.ecr.eu-west-1.amazonaws.com/aws-guardduty-agent-fargate` |
| Südamerika (São Paulo) | `758426053663.dkr.ecr.sa-east-1.amazonaws.com/aws-guardduty-agent-fargate` |
| Europa (Stockholm) | `591436053604.dkr.ecr.eu-north-1.amazonaws.com/aws-guardduty-agent-fargate` |
| Europa (Frankfurt) | `323658145986.dkr.ecr.eu-central-1.amazonaws.com/aws-guardduty-agent-fargate` |
| Europa (Zürich) | `529164026651.dkr.ecr.eu-central-2.amazonaws.com/aws-guardduty-agent-fargate` |
| Asien-Pazifik (Singapur) | `174946120834.dkr.ecr.ap-southeast-1.amazonaws.com/aws-guardduty-agent-fargate` |
| Asien-Pazifik (Sydney) | `005257825471.dkr.ecr.ap-southeast-2.amazonaws.com/aws-guardduty-agent-fargate` |
| Asien-Pazifik (Jakarta) | `510637619217.dkr.ecr.ap-southeast-3.amazonaws.com/aws-guardduty-agent-fargate` |
| Asien-Pazifik (Tokio) | `533107202818.dkr.ecr.ap-northeast-1.amazonaws.com/aws-guardduty-agent-fargate` |
| Asien-Pazifik (Seoul) | `914738172881.dkr.ecr.ap-northeast-2.amazonaws.com/aws-guardduty-agent-fargate` |
| Asien-Pazifik (Osaka) | `273192626886.dkr.ecr.ap-northeast-3.amazonaws.com/aws-guardduty-agent-fargate` |
| Asien-Pazifik (Hongkong) | `258348409381.dkr.ecr.ap-east-1.amazonaws.com/aws-guardduty-agent-fargate` |
| Middle East (Bahrain) | `536382113932.dkr.ecr.me-south-1.amazonaws.com/aws-guardduty-agent-fargate` |
| Europa (Milan) | `266869475730.dkr.ecr.eu-south-1.amazonaws.com/aws-guardduty-agent-fargate` |
| Europa (Spain) | `919611009337.dkr.ecr.eu-south-2.amazonaws.com/aws-guardduty-agent-fargate` |
| Afrika (Kapstadt) | `197869348890.dkr.ecr.af-south-1.amazonaws.com/aws-guardduty-agent-fargate` |
| Asien-Pazifik (Melbourne) | `251357961535.dkr.ecr.ap-southeast-4.amazonaws.com/aws-guardduty-agent-fargate` |
| Israel (Tel Aviv) | `870907303882.dkr.ecr.il-central-1.amazonaws.com/aws-guardduty-agent-fargate` |
| Asien-Pazifik (Malaysia) | `156041399949.dkr.ecr.ap-southeast-5.amazonaws.com/aws-guardduty-agent-fargate` |
| Asien-Pazifik (Thailand) | `054037130133.dkr.ecr.ap-southeast-7.amazonaws.com/aws-guardduty-agent-fargate` |
| Kanada West (Calgary) | `339712888787.dkr.ecr.ca-west-1.amazonaws.com/aws-guardduty-agent-fargate` |
| Mexiko (Zentral) | `311141559934.dkr.ecr.mx-central-1.amazonaws.com/aws-guardduty-agent-fargate` |
| Asien-Pazifik (Taipeh) | `259886477082.dkr.ecr.ap-east-2.amazonaws.com/aws-guardduty-agent-fargate` |
# Zwei Security Agents auf demselben zugrunde liegenden Host
Amazon EC2 EC2-Instances können mehrere Arten von Workloads unterstützen. Wenn Sie einen automatisierten Security Agent auf einer Amazon EC2 EC2-Instance konfigurieren, verfügt dieselbe EC2-Instance möglicherweise über EKS über einen anderen Security Agent.
## -Übersicht
Stellen Sie sich ein Szenario vor, in dem Sie Runtime Monitoring aktiviert haben. Jetzt aktivieren Sie den automatisierten Agenten für Amazon EKS über GuardDuty. Sie haben auch den automatisierten Agenten für Amazon EC2 aktiviert. Es kann vorkommen, dass derselbe zugrunde liegende Host mit zwei Security Agents installiert wird — einer für Amazon EKS und der andere für Amazon EC2. Dies kann dazu führen, dass zwei Security Agents auf demselben Host laufen, Laufzeitereignisse sammeln und an GuardDuty diese senden und möglicherweise doppelte Ergebnisse generieren.
## Auswirkung
+ Wenn mehr als ein Security Agent auf demselben Host ausgeführt wird, kann es sein, dass Ihr Konto doppelt so viel CPU- und Speicherverarbeitung benötigt. Informationen zu den CPU- und Speicherlimits für jeden Ressourcentyp finden Sie unter [Voraussetzungen](runtime-monitoring-prerequisites.md) für diese Ressource.
+ GuardDuty hat die Runtime Monitoring-Funktion so konzipiert, dass Ihr Konto nur für einen Stream von Runtime-Ereignissen belastet wird, selbst wenn sich zwei Security Agents überschneiden, die Runtime-Ereignisse von demselben zugrundeliegenden Host sammeln.
## Wie GuardDuty geht man mit mehreren Agenten um
GuardDuty erkennt, wenn zwei Security Agents auf demselben Host laufen, und bestimmt nur einen davon als Security Agent, der aktiv Runtime-Ereignisse sammelt. Der zweite Agent verbraucht nur minimale Systemressourcen, um jegliche Beeinträchtigung der Leistung Ihrer Anwendungen zu verhindern.
GuardDuty berücksichtigt die folgenden Szenarien:
+ Wenn eine EC2-Instance sowohl in den Geltungsbereich von Amazon EKS als auch von Amazon EC2-Sicherheitsagenten fällt, hat der EKS-Sicherheitsagent Vorrang. Dies gilt nur, wenn Sie den Security Agent v1.1.0 oder höher für Amazon EC2 verwenden. Ältere Agentenversionen werden weiterhin ausgeführt und sammeln Runtime-Ereignisse, da ältere Agentenversionen von der Priorisierung nicht betroffen sind.
+ Wenn sowohl Amazon EKS als auch Amazon EC2 Security Agents GuardDuty verwaltet haben und Ihre Amazon EC2 EC2-Instance ebenfalls SSM-verwaltet wird, werden beide Security Agents auf Host-Ebene installiert. Sobald die Agenten installiert sind, wird GuardDuty entschieden, welcher Security Agent weiter ausgeführt wird. Wenn beide Security Agents ausgeführt werden, sammelt letztendlich nur einer von ihnen Runtime-Ereignisse.
+ Wenn die Security Agents, die sowohl EC2 als auch EKS zugeordnet sind, gleichzeitig ausgeführt werden, GuardDuty kann es nur während der Überschneidungszeit zu doppelten Ergebnissen kommen.
Dies kann passieren, wenn:
+ Security Agents für EC2 und EKS werden GuardDuty (automatisch) konfiguriert, oder
+ Ihre Amazon EKS-Ressource verfügt über einen automatisierten Sicherheitsagenten.
+ Wenn der EKS Security Agent bereits läuft und Sie den EC2 Security Agent manuell auf demselben zugrunde liegenden Host bereitstellen und alle Voraussetzungen erfüllen, wird GuardDuty möglicherweise kein zweiter Security Agent installiert.
# EKS-Laufzeitüberwachung in GuardDuty
EKS Runtime Monitoring bietet Runtime-Bedrohungserkennung für Amazon Elastic Kubernetes Service (Amazon EKS) -Knoten und -Container in Ihrer AWS Umgebung. EKS Runtime Monitoring verwendet einen GuardDuty Sicherheitsagenten, der für Runtime-Transparenz bei einzelnen EKS-Workloads sorgt, z. B. beim Dateizugriff, bei der Prozessausführung und bei Netzwerkverbindungen. Der GuardDuty Security Agent hilft dabei, bestimmte Container in Ihren EKS-Clustern zu GuardDuty identifizieren, die potenziell gefährdet sind. Er kann auch Versuche erkennen, Rechte von einem einzelnen Container auf den zugrunde liegenden EC2-Host und die gesamte Umgebung auszuweiten. AWS
Mit der Verfügbarkeit von Runtime Monitoring GuardDuty wurde die Konsolenerfahrung für EKS Runtime Monitoring in Runtime Monitoring konsolidiert. GuardDuty migriert Ihre EKS Runtime Monitoring-Einstellungen nicht automatisch in Ihrem Namen. Dies erfordert eine Aktion von Ihrer Seite. Wenn Sie weiterhin nur EKS Runtime Monitoring verwenden möchten, können Sie das APIs oder verwenden, AWS CLI um den bestehenden Konfigurationsstatus für EKS Runtime Monitoring zu überprüfen und zu aktualisieren. GuardDuty Empfiehlt [Migration von EKS Runtime Monitoring zu Runtime Monitoring](migrating-from-eksrunmon-to-runtime-monitoring.md) jedoch, Runtime Monitoring zur Überwachung Ihrer Amazon EKS-Cluster zu verwenden.
**Topics**
+ [Konfiguration von EKS Runtime Monitoring für Umgebungen mit mehreren Konten (API)](eks-runtime-monitoring-configuration-multiple-accounts.md)
+ [Konfiguration von EKS Runtime Monitoring für ein eigenständiges Konto (API)](eks-runtime-monitoring-configuration-standalone-acc.md)
+ [Migration von EKS Runtime Monitoring zu Runtime Monitoring](migrating-from-eksrunmon-to-runtime-monitoring.md)
# Konfiguration von EKS Runtime Monitoring für Umgebungen mit mehreren Konten (API)
In Umgebungen mit mehreren Konten kann nur das delegierte GuardDuty Administratorkonto EKS Runtime Monitoring für die Mitgliedskonten aktivieren oder deaktivieren und die GuardDuty Agentenverwaltung für die EKS-Cluster verwalten, die zu den Mitgliedskonten in ihrer Organisation gehören. Die GuardDuty Mitgliedskonten können diese Konfiguration nicht von ihren Konten aus ändern. Das delegierte GuardDuty Administratorkonto verwaltet seine Mitgliedskonten mithilfe von AWS Organizations. Weitere Informationen zu Umgebungen mit mehreren Konten finden Sie unter [Verwaltung mehrerer Konten](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_accounts.html).
## Konfiguration von EKS Runtime Monitoring für das delegierte Administratorkonto GuardDuty
Dieser Abschnitt enthält Schritte zur Konfiguration von EKS Runtime Monitoring und zur Verwaltung des GuardDuty Security Agents für die EKS-Cluster, die zum delegierten GuardDuty Administratorkonto gehören.
Auf der Grundlage von [Ansätze zur Verwaltung von GuardDuty Sicherheitsagenten in Amazon EKS-Clustern](how-runtime-monitoring-works-eks.md#eksrunmon-approach-to-monitor-eks-clusters) können Sie einen bevorzugten Ansatz wählen und die in der folgenden Tabelle aufgeführten Schritte ausführen.
| **Bevorzugter Ansatz zur Verwaltung des GuardDuty Security Agents** | **Schritte** |
| --- | --- |
| Den Security Agent verwalten über GuardDuty (Alle EKS-Cluster überwachen) | Führen Sie die [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateDetector.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateDetector.html)-API aus, indem Sie Ihre eigene regionale Detektor-ID verwenden und den `features`-Objektnamen als `EKS_RUNTIME_MONITORING` und den Status als `ENABLED` übergeben. Stellen Sie den Status für `EKS_ADDON_MANAGEMENT` als `ENABLED` ein. GuardDuty verwaltet die Bereitstellung und Aktualisierung des Security Agents für alle Amazon EKS-Cluster in Ihrem Konto. Alternativ können Sie den AWS CLI Befehl verwenden, indem Sie Ihre eigene regionale Melder-ID verwenden. Um die `detectorId` für Ihr Konto und Ihre aktuelle Region geltenden Einstellungen zu finden, gehen Sie in der [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)Konsole auf die Seite **„Einstellungen**“ oder führen Sie die [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html)API aus. Das folgende Beispiel aktiviert sowohl `EKS_RUNTIME_MONITORING` als auch `EKS_ADDON_MANAGEMENT`: aws guardduty update-detector --detector-id 12abc34d567e8fa901bc2d34e56789f0 --features '[{"Name" : "EKS_RUNTIME_MONITORING", "Status" : "ENABLED", "AdditionalConfiguration" : [{"Name" : "EKS_ADDON_MANAGEMENT", "Status" : "ENABLED"}] }]' |
| Alle EKS-Cluster überwachen, jedoch einige davon ausschließen (mithilfe des Ausschluss-Tags) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
| Ausgewählte EKS-Cluster überwachen (mithilfe des Einschließen-Tags) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
| Den Sicherheitsagent manuell verwalten | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
## Automatische Aktivierung der EKS-Laufzeit-Überwachung für alle Mitgliedskonten
Dieser Abschnitt enthält Schritte zur Aktivierung von EKS Runtime Monitoring und zur Verwaltung des Security Agents für alle Mitgliedskonten. Dazu gehören das delegierte GuardDuty Administratorkonto, bestehende Mitgliedskonten und die neuen Konten, die der Organisation beitreten.
Auf der Grundlage von [Ansätze zur Verwaltung von GuardDuty Sicherheitsagenten in Amazon EKS-Clustern](how-runtime-monitoring-works-eks.md#eksrunmon-approach-to-monitor-eks-clusters) können Sie einen bevorzugten Ansatz wählen und die in der folgenden Tabelle aufgeführten Schritte ausführen.
| **Bevorzugter Ansatz zur Verwaltung des GuardDuty Security Agents** | **Schritte** |
| --- | --- |
| Den Security Agent verwalten über GuardDuty (Alle EKS-Cluster überwachen) | Um EKS Runtime Monitoring selektiv für Ihre Mitgliedskonten zu aktivieren, führen Sie den [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateMemberDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateMemberDetectors.html)API-Vorgang mit Ihrem eigenen *detector ID* aus. Stellen Sie den Status für `EKS_ADDON_MANAGEMENT` als `ENABLED` ein. GuardDuty verwaltet die Bereitstellung und Aktualisierung des Security Agents für alle Amazon EKS-Cluster in Ihrem Konto. Alternativ können Sie den AWS CLI Befehl verwenden, indem Sie Ihre eigene regionale Melder-ID verwenden. Um die `detectorId` für Ihr Konto und Ihre aktuelle Region geltenden Einstellungen zu finden, gehen Sie in der [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)Konsole auf die Seite **„Einstellungen**“ oder führen Sie die [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html)API aus. Das folgende Beispiel aktiviert sowohl `EKS_RUNTIME_MONITORING` als auch `EKS_ADDON_MANAGEMENT`: aws guardduty update-member-detectors --detector-id 12abc34d567e8fa901bc2d34e56789f0 --account-ids 111122223333 --features '[{"Name" : "EKS_RUNTIME_MONITORING", "Status" : "ENABLED", "AdditionalConfiguration" : [{"Name" : "EKS_ADDON_MANAGEMENT", "Status" : "ENABLED"}] }]' Sie können auch eine durch ein IDs Leerzeichen getrennte Liste von Konten übergeben. Wenn der Code erfolgreich ausgeführt wurde, gibt er eine leere Liste von `UnprocessedAccounts` zurück. Wenn beim Ändern der Detektor-Einstellungen für ein Konto Probleme aufgetreten sind, wird diese Konto-ID zusammen mit einer Zusammenfassung des Problems aufgeführt. |
| Alle EKS-Cluster überwachen, jedoch einige davon ausschließen (mithilfe des Ausschluss-Tags) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
| Ausgewählte EKS-Cluster überwachen (mithilfe des Einschließen-Tags) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
| Den Sicherheitsagent manuell verwalten | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
## Konfiguration der EKS-Laufzeit-Überwachung für alle vorhandenen aktiven Mitgliedskonten
Dieser Abschnitt enthält die Schritte zur Aktivierung von EKS Runtime Monitoring und zur Verwaltung des GuardDuty Security Agents für bestehende aktive Mitgliedskonten in Ihrer Organisation.
Auf der Grundlage von [Ansätze zur Verwaltung von GuardDuty Sicherheitsagenten in Amazon EKS-Clustern](how-runtime-monitoring-works-eks.md#eksrunmon-approach-to-monitor-eks-clusters) können Sie einen bevorzugten Ansatz wählen und die in der folgenden Tabelle aufgeführten Schritte ausführen.
| **Bevorzugter Ansatz zur Verwaltung des GuardDuty Security Agents** | **Schritte** |
| --- | --- |
| Den Security Agent verwalten über GuardDuty (Alle EKS-Cluster überwachen) | Um EKS Runtime Monitoring selektiv für Ihre Mitgliedskonten zu aktivieren, führen Sie den [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateMemberDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateMemberDetectors.html)API-Vorgang mit Ihrem eigenen *detector ID* aus. Stellen Sie den Status für `EKS_ADDON_MANAGEMENT` als `ENABLED` ein. GuardDuty verwaltet die Bereitstellung und Aktualisierung des Security Agents für alle Amazon EKS-Cluster in Ihrem Konto. Alternativ können Sie den AWS CLI Befehl verwenden, indem Sie Ihre eigene regionale Melder-ID verwenden. Um die `detectorId` für Ihr Konto und Ihre aktuelle Region geltenden Einstellungen zu finden, gehen Sie in der [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)Konsole auf die Seite **„Einstellungen**“ oder führen Sie die [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html)API aus. Das folgende Beispiel aktiviert sowohl `EKS_RUNTIME_MONITORING` als auch `EKS_ADDON_MANAGEMENT`: aws guardduty update-member-detectors --detector-id 12abc34d567e8fa901bc2d34e56789f0 --account-ids 111122223333 --features '[{"Name" : "EKS_RUNTIME_MONITORING", "Status" : "ENABLED", "AdditionalConfiguration" : [{"Name" : "EKS_ADDON_MANAGEMENT", "Status" : "ENABLED"}] }]' Sie können auch eine durch ein IDs Leerzeichen getrennte Liste von Konten übergeben. Wenn der Code erfolgreich ausgeführt wurde, gibt er eine leere Liste von `UnprocessedAccounts` zurück. Wenn beim Ändern der Detektor-Einstellungen für ein Konto Probleme aufgetreten sind, wird diese Konto-ID zusammen mit einer Zusammenfassung des Problems aufgeführt. |
| Alle EKS-Cluster überwachen, jedoch einige davon ausschließen (mithilfe des Ausschluss-Tags) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
| Ausgewählte EKS-Cluster überwachen (mithilfe des Einschließen-Tags) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
| Den Sicherheitsagent manuell verwalten | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
## EKS-Laufzeit-Überwachung für neue Mitglieder automatisch aktivieren
Das delegierte GuardDuty Administratorkonto kann EKS Runtime Monitoring automatisch aktivieren und einen Ansatz für die Verwaltung des GuardDuty Security Agents für neue Konten wählen, die Ihrer Organisation beitreten.
Auf der Grundlage von [Ansätze zur Verwaltung von GuardDuty Sicherheitsagenten in Amazon EKS-Clustern](how-runtime-monitoring-works-eks.md#eksrunmon-approach-to-monitor-eks-clusters) können Sie einen bevorzugten Ansatz wählen und die in der folgenden Tabelle aufgeführten Schritte ausführen.
| **Bevorzugter Ansatz zur Verwaltung des Security Agents GuardDuty** | **Schritte** |
| --- | --- |
| Den Security Agent verwalten über GuardDuty (Alle EKS-Cluster überwachen) | Um EKS Runtime Monitoring selektiv für Ihre neuen Konten zu aktivieren, rufen Sie den [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateOrganizationConfiguration.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateOrganizationConfiguration.html)API-Vorgang mit Ihrem eigenen auf. *detector ID* Stellen Sie den Status für `EKS_ADDON_MANAGEMENT` als `ENABLED` ein. GuardDuty verwaltet die Bereitstellung und Aktualisierung des Security Agents für alle Amazon EKS-Cluster in Ihrem Konto. Alternativ können Sie den AWS CLI Befehl verwenden, indem Sie Ihre eigene regionale Melder-ID verwenden. Um die `detectorId` für Ihr Konto und Ihre aktuelle Region geltenden Einstellungen zu finden, gehen Sie in der [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)Konsole auf die Seite **„Einstellungen**“ oder führen Sie die [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html)API aus. Im folgenden Beispiel werden beide Optionen `EKS_RUNTIME_MONITORING` und `EKS_ADDON_MANAGEMENT` für ein einzelnes Konto aktiviert. Sie können auch eine durch ein IDs Leerzeichen getrennte Liste von Konten übergeben. Informationen zu den Einstellungen `detectorId` für Ihr Konto und Ihre aktuelle Region finden Sie auf der Seite **„Einstellungen**“ in der [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)Konsole oder führen Sie die [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html)API aus. aws guardduty update-organization-configuration --detector-id 12abc34d567e8fa901bc2d34e56789f0 --autoEnable --features '[{"Name" : "EKS_RUNTIME_MONITORING", "AutoEnable": "NEW", "AdditionalConfiguration" : [{"Name" : "EKS_ADDON_MANAGEMENT", "AutoEnable": "NEW"}] }]' Wenn der Code erfolgreich ausgeführt wurde, gibt er eine leere Liste von `UnprocessedAccounts` zurück. Wenn beim Ändern der Detektor-Einstellungen für ein Konto Probleme aufgetreten sind, wird diese Konto-ID zusammen mit einer Zusammenfassung des Problems aufgeführt. |
| Alle EKS-Cluster überwachen, jedoch einige davon ausschließen (mithilfe des Ausschluss-Tags) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
| Ausgewählte EKS-Cluster überwachen (mithilfe des Einschließen-Tags) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
| Den Sicherheitsagent manuell verwalten | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
## EKS-Laufzeit-Überwachung für einzelne aktive Mitgliedskonten aktivieren
Dieser Abschnitt enthält die Schritte zur Konfiguration von EKS Runtime Monitoring und zur Verwaltung des Security Agents für einzelne aktive Mitgliedskonten.
Auf der Grundlage von [Ansätze zur Verwaltung von GuardDuty Sicherheitsagenten in Amazon EKS-Clustern](how-runtime-monitoring-works-eks.md#eksrunmon-approach-to-monitor-eks-clusters) können Sie einen bevorzugten Ansatz wählen und die in der folgenden Tabelle aufgeführten Schritte ausführen.
| **Bevorzugter Ansatz zur Verwaltung des GuardDuty Security Agents** | **Schritte** |
| --- | --- |
| Den Security Agent verwalten über GuardDuty (Alle EKS-Cluster überwachen) | Um EKS Runtime Monitoring selektiv für Ihre Mitgliedskonten zu aktivieren, führen Sie den [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateMemberDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateMemberDetectors.html)API-Vorgang mit Ihrem eigenen *detector ID* aus. Stellen Sie den Status für `EKS_ADDON_MANAGEMENT` als `ENABLED` ein. GuardDuty verwaltet die Bereitstellung und Aktualisierung des Security Agents für alle Amazon EKS-Cluster in Ihrem Konto. Alternativ können Sie den AWS CLI Befehl verwenden, indem Sie Ihre eigene regionale Melder-ID verwenden. Um die `detectorId` für Ihr Konto und Ihre aktuelle Region geltenden Einstellungen zu finden, gehen Sie in der [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)Konsole auf die Seite **„Einstellungen**“ oder führen Sie die [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html)API aus. Das folgende Beispiel aktiviert sowohl `EKS_RUNTIME_MONITORING` als auch `EKS_ADDON_MANAGEMENT`: aws guardduty update-member-detectors --detector-id 12abc34d567e8fa901bc2d34e56789f0 --account-ids 111122223333 --features '[{"Name" : "EKS_RUNTIME_MONITORING", "Status" : "ENABLED", "AdditionalConfiguration" : [{"Name" : "EKS_ADDON_MANAGEMENT", "Status" : "ENABLED"}] }]' Sie können auch eine durch ein IDs Leerzeichen getrennte Liste von Konten übergeben. Wenn der Code erfolgreich ausgeführt wurde, gibt er eine leere Liste von `UnprocessedAccounts` zurück. Wenn beim Ändern der Detektor-Einstellungen für ein Konto Probleme aufgetreten sind, wird diese Konto-ID zusammen mit einer Zusammenfassung des Problems aufgeführt. |
| Alle EKS-Cluster überwachen, jedoch einige davon ausschließen (mithilfe des Ausschluss-Tags) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
| Ausgewählte EKS-Cluster überwachen (mithilfe des Einschließen-Tags) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
| Den Sicherheitsagent manuell verwalten | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/eks-runtime-monitoring-configuration-multiple-accounts.html) |
# Konfiguration von EKS Runtime Monitoring für ein eigenständiges Konto (API)
Ein eigenständiges Konto hat die Entscheidung, einen Schutzplan AWS-Konto in einem bestimmten Bereich zu aktivieren oder zu deaktivieren AWS-Region.
Wenn Ihr Konto über oder über AWS Organizations die Einladungsmethode mit einem GuardDuty Administratorkonto verknüpft ist, gilt dieser Abschnitt nicht für Ihr Konto. Weitere Informationen finden Sie unter [Konfiguration von EKS Runtime Monitoring für Umgebungen mit mehreren Konten (API)](eks-runtime-monitoring-configuration-multiple-accounts.md).
Nachdem Sie Runtime Monitoring aktiviert haben, stellen Sie sicher, dass Sie den GuardDuty Security Agent durch automatische Konfiguration oder manuelle Installation installieren. Nachdem Sie alle im folgenden Verfahren aufgeführten Schritte ausgeführt haben, stellen Sie sicher, dass Sie den Security Agent installieren.
Auf der Grundlage von [Ansätze zur Verwaltung von GuardDuty Sicherheitsagenten in Amazon EKS-Clustern](how-runtime-monitoring-works-eks.md#eksrunmon-approach-to-monitor-eks-clusters) können Sie einen bevorzugten Ansatz wählen und die in der folgenden Tabelle aufgeführten Schritte ausführen.
| **Bevorzugter Ansatz zur Verwaltung des GuardDuty Security Agents** | **Schritte** |
| --- | --- |
| Den Security Agent verwalten über GuardDuty (Alle EKS-Cluster überwachen) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/eks-runtime-monitoring-configuration-standalone-acc.html) |
| Alle EKS-Cluster überwachen, jedoch einige davon ausschließen (mithilfe des Ausschluss-Tags) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/eks-runtime-monitoring-configuration-standalone-acc.html) |
| Ausgewählte EKS-Cluster überwachen (mithilfe des Einschließen-Tags) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/eks-runtime-monitoring-configuration-standalone-acc.html) |
| Den Sicherheitsagent manuell verwalten | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/eks-runtime-monitoring-configuration-standalone-acc.html) |
# Migration von EKS Runtime Monitoring zu Runtime Monitoring
Mit der Einführung von GuardDuty Runtime Monitoring wurde der Geltungsbereich der Bedrohungserkennung auf Amazon ECS-Container und Amazon EC2 EC2-Instances ausgeweitet. Die Erfahrung mit EKS Runtime Monitoring wurde nun in Runtime Monitoring zusammengefasst. Sie können Runtime Monitoring aktivieren und einzelne GuardDuty Security Agents für jeden Ressourcentyp (Amazon EC2 EC2-Instance, Amazon ECS-Cluster und Amazon EKS-Cluster) verwalten, für den Sie das Laufzeitverhalten überwachen möchten.
GuardDuty hat die Konsolenerfahrung für EKS Runtime Monitoring in Runtime Monitoring zusammengefasst. GuardDuty empfiehlt [Überprüfen Sie den Konfigurationsstatus von EKS Runtime Monitoring](checking-eks-runtime-monitoring-enable-status.md) und[Migration von EKS Runtime Monitoring zu Runtime Monitoring](#migrating-from-eksrunmon-to-runtime-monitoring).
Stellen Sie im Rahmen der Migration zu Runtime Monitoring sicher, dass Sie [Deaktivieren Sie die EKS-Laufzeitüberwachung](disabling-eks-runtime-monitoring.md) Dies ist wichtig, denn wenn Sie sich später dafür entscheiden, Runtime Monitoring zu deaktivieren und EKS Runtime Monitoring nicht zu deaktivieren, werden Ihnen weiterhin Nutzungskosten für EKS Runtime Monitoring entstehen.
**Um von EKS Runtime Monitoring zu Runtime Monitoring zu migrieren**
1. Die GuardDuty Konsole unterstützt EKS Runtime Monitoring als Teil von Runtime Monitoring.
Sie können damit beginnen, Runtime Monitoring [Überprüfen Sie den Konfigurationsstatus von EKS Runtime Monitoring](checking-eks-runtime-monitoring-enable-status.md) von Ihrer Organisation und Ihren Konten aus zu verwenden.
Stellen Sie sicher, dass Sie EKS Runtime Monitoring nicht deaktivieren, bevor Sie Runtime Monitoring aktivieren. Wenn Sie EKS Runtime Monitoring deaktivieren, wird auch die Amazon EKS Add-On-Verwaltung deaktiviert. Fahren Sie mit den folgenden Schritten in der angegebenen Reihenfolge fort.
1. Stellen Sie sicher, dass Sie alle erfüllen[Voraussetzungen für die Aktivierung von Runtime Monitoring](runtime-monitoring-prerequisites.md).
1. Aktivieren Sie die Laufzeit-Überwachung, indem Sie die gleichen Einstellungen der Organisationskonfiguration für die Laufzeit-überwachung replizieren wie für die EKS-Laufzeit-Überwachung. Weitere Informationen finden Sie unter [Laufzeitüberwachung aktivieren](runtime-monitoring-configuration.md).
+ Wenn Sie ein eigenständiges Konto haben, müssen Sie Runtime Monitoring aktivieren.
Wenn Ihr GuardDuty Security Agent bereits installiert ist, werden die entsprechenden Einstellungen automatisch repliziert und Sie müssen die Einstellungen nicht erneut konfigurieren.
+ Wenn Sie eine Organisation mit Einstellungen für die automatische Aktivierung haben, stellen Sie sicher, dass Sie dieselben Einstellungen für die automatische Aktivierung für Runtime Monitoring replizieren.
+ Wenn Sie ein Unternehmen haben, dessen Einstellungen für bestehende aktive Mitgliedskonten einzeln konfiguriert sind, stellen Sie sicher, dass Sie Runtime Monitoring aktivieren und den GuardDuty Security Agent für diese Mitglieder individuell konfigurieren.
1. Nachdem Sie sichergestellt haben, dass die Einstellungen für Runtime Monitoring und GuardDuty Security Agent korrekt sind, [deaktivieren Sie EKS Runtime Monitoring](https://docs.aws.amazon.com/guardduty/latest/ug/disabling-eks-runtime-monitoring.html), indem Sie entweder die API oder den AWS CLI Befehl verwenden.
1. (Optional) Wenn Sie alle mit dem GuardDuty Security Agent verknüpften Ressourcen säubern möchten, finden Sie weitere Informationen unter[Ressourcen in Runtime Monitoring deaktivieren, deinstallieren und bereinigen](runtime-monitoring-agent-resource-clean-up.md).
Wenn Sie EKS Runtime Monitoring weiterhin verwenden möchten, ohne Runtime Monitoring zu aktivieren, finden Sie weitere Informationen unter[EKS-Laufzeitüberwachung in GuardDuty](eks-runtime-monitoring-guardduty.md). Wählen Sie je nach Anwendungsfall die Schritte zur Konfiguration von EKS Runtime Monitoring für ein eigenständiges Konto oder für mehrere Mitgliedskonten aus.
# Überprüfen Sie den Konfigurationsstatus von EKS Runtime Monitoring
Verwenden Sie die folgenden AWS CLI Befehle APIs oder, um den bestehenden Konfigurationsstatus von EKS Runtime Monitoring zu überprüfen.
**Um den bestehenden EKS Runtime Monitoring-Konfigurationsstatus in Ihrem Konto zu überprüfen**
+ Führen Sie den Befehl aus [GetDetector](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_GetDetector.html), um den Konfigurationsstatus Ihres eigenen Kontos zu überprüfen.
+ Alternativ können Sie den folgenden Befehl ausführen, indem Sie Folgendes verwenden AWS CLI:
```
aws guardduty get-detector --detector-id 12abc34d567e8fa901bc2d34e56789f0 --region us-east-1
```
Achten Sie darauf, die Melder-ID Ihrer Region AWS-Konto und der aktuellen Region zu ersetzen. Die `detectorId` für Ihr Konto und Ihre aktuelle Region passende finden Sie auf der **Einstellungsseite** in der [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)Konsole oder führen Sie die [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html)API aus.
**So überprüfen Sie den aktuellen Konfigurationsstatus von EKS Runtime Monitoring für Ihr Unternehmen (nur als delegiertes GuardDuty Administratorkonto)**
+ Führen Sie das [DescribeOrganizationConfiguration](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_DescribeOrganizationConfiguration.html)Programm aus, um den Konfigurationsstatus Ihrer Organisation zu überprüfen.
Alternativ können Sie den folgenden Befehl ausführen mit AWS CLI:
```
aws guardduty describe-organization-configuration --detector-id 12abc34d567e8fa901bc2d34e56789f0 --region us-east-1
```
Achten Sie darauf, die Melder-ID durch die Melder-ID Ihres delegierten GuardDuty Administratorkontos und die Region durch Ihre aktuelle Region zu ersetzen. Informationen zu den Einstellungen `detectorId` für Ihr Konto und Ihre aktuelle Region finden Sie auf der Seite **„Einstellungen**“ in der [https://console.aws.amazon.com/guardduty/](https://console.aws.amazon.com/guardduty/)Konsole oder führen Sie die [https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_ListDetectors.html)API aus.
# Deaktivieren von EKS Runtime Monitoring nach der Migration zu Runtime Monitoring
Nachdem Sie sichergestellt haben, dass die vorhandenen Einstellungen für Ihr Konto oder Ihre Organisation in Runtime Monitoring repliziert wurden, können Sie EKS Runtime Monitoring deaktivieren.
**Um EKS Runtime Monitoring zu deaktivieren**
+ **Um EKS Runtime Monitoring in Ihrem eigenen Konto zu deaktivieren**
Führen Sie die [UpdateDetector](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateDetector.html)API mit Ihrer eigenen Region aus*detector-id*.
Alternativ können Sie den folgenden AWS CLI Befehl verwenden. *12abc34d567e8fa901bc2d34e56789f0*Ersetzen Sie es durch Ihre eigene Region*detector-id*.
```
aws guardduty update-detector --detector-id 12abc34d567e8fa901bc2d34e56789f0 --features '[{"Name" : "EKS_RUNTIME_MONITORING", "Status" : "DISABLED"}]'
```
+ **Um EKS Runtime Monitoring für Mitgliedskonten in Ihrer Organisation zu deaktivieren**
Führen Sie die [UpdateMemberDetectors](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateMemberDetectors.html)API mit der Region *detector-id* des delegierten GuardDuty Administratorkontos der Organisation aus.
Alternativ können Sie den folgenden AWS CLI Befehl verwenden. *12abc34d567e8fa901bc2d34e56789f0*Ersetzen Sie es durch die Region *detector-id* des delegierten GuardDuty Administratorkontos der Organisation und *111122223333* durch die AWS-Konto ID des Mitgliedskontos, für das Sie diese Funktion deaktivieren möchten.
```
aws guardduty update-member-detectors --detector-id 12abc34d567e8fa901bc2d34e56789f0 --account-ids 111122223333 --features '[{"Name" : "EKS_RUNTIME_MONITORING", "Status" : "DISABLED"}]'
```
+ **Um die Einstellungen für die automatische Aktivierung von EKS Runtime Monitoring für Ihre Organisation zu aktualisieren**
Führen Sie den folgenden Schritt nur aus, wenn Sie die Einstellungen für die automatische Aktivierung von EKS Runtime Monitoring entweder auf neue (`NEW`) oder alle (`ALL`) Mitgliedskonten in der Organisation konfiguriert haben. Wenn Sie es bereits als konfiguriert haben`NONE`, können Sie diesen Schritt überspringen.
**Anmerkung**
Wenn Sie die Konfiguration für die automatische Aktivierung von EKS Runtime `NONE` Monitoring auf einstellen, wird EKS Runtime Monitoring nicht automatisch für ein vorhandenes Mitgliedskonto aktiviert oder wenn ein neues Mitgliedskonto Ihrer Organisation beitritt.
Führen Sie die [UpdateOrganizationConfiguration](https://docs.aws.amazon.com/guardduty/latest/APIReference/API_UpdateOrganizationConfiguration.html)API mit der Region *detector-id* aus, in der sich das delegierte GuardDuty Administratorkonto der Organisation befindet.
Alternativ können Sie den folgenden AWS CLI Befehl verwenden. *12abc34d567e8fa901bc2d34e56789f0*Ersetzen Sie es durch das regionale Konto *detector-id* des delegierten GuardDuty Administratorkontos der Organisation. Ersetzen Sie die *EXISTING\$1VALUE* durch Ihre aktuelle Konfiguration, um sie automatisch zu aktivieren GuardDuty.
```
aws guardduty update-organization-configuration --detector-id 12abc34d567e8fa901bc2d34e56789f0 --auto-enable-organization-members EXISTING_VALUE --features '[{"Name" : "EKS_RUNTIME_MONITORING", "AutoEnable": "NONE"}]'
```
# GuardDuty Release-Versionen des Security Agents
GuardDuty veröffentlicht von Zeit zu Zeit eine aktualisierte Agentenversion. When GuardDuty verwaltet den Agenten automatisch und GuardDuty ist darauf ausgelegt, den Agenten in Ihrem Namen zu aktualisieren. Wenn Sie den Agenten manuell verwalten, sind Sie dafür verantwortlich, die Agentenversion für Ihre Ressourcentypen — Amazon EC2 EC2-Instances, Amazon ECS-Cluster und Amazon EKS-Cluster — zu aktualisieren.
Die folgenden Abschnitte enthalten Release-Versionen von GuardDuty Security Agents und zugehörige Versionshinweise für alle unterstützten Ressourcentypen.
**Topics**
+ [GuardDuty Security-Agent-Versionen für Amazon EC2 EC2-Instances](#ec2-gdu-agent-release-history)
+ [GuardDuty Security Agent-Versionen für AWS Fargate (nur Amazon ECS)](#ecs-gdu-agent-release-history)
+ [GuardDuty Security-Agent-Versionen für Amazon EKS-Ressourcen](#eks-runtime-monitoring-agent-release-history)
+ [Zusätzliche Ressourcen — nächste Schritte](#runtime-monitoring-related-agent-versions-next-steps)
## GuardDuty Security-Agent-Versionen für Amazon EC2 EC2-Instances
Die folgende Tabelle zeigt den Versionsverlauf der Versionen des GuardDuty Security Agents für Amazon EC2.
| Version des SSM-Vertriebspartners | Agent-Version | Versionshinweise | Datum der Verfügbarkeit |
| --- | --- | --- | --- |
| v1.9.2 | v1.9.2 | Unterstützung für Kernel 6.15, 6.16, 6.17, 6.18 hinzugefügt. Unterstützung für Alma Linux 9, Alma Linux 10 und SUSE Linux Enterprise Server 16 hinzugefügt. Eine Liste aller verifizierten Betriebssystemverteilungen für Amazon EC2 EC2-Ressourcen finden Sie unter. [Überprüfen Sie die architektonischen Anforderungen](prereq-runtime-monitoring-ec2-support.md#validating-architecture-req-ec2) | 24. Februar 2026 |
| v1.9.1 | v1.9.1 | Allgemeine Aktualisierungen der Leistungsoptimierung und der Sicherheitsfunktionen. | 10. November 2025 |
| v1.9.0 | v1.9.0 | Allgemeine Leistungsoptimierung und -verbesserungen. | 23. Oktober 2025 |
| v1.8.0 | v1.8.0 | Allgemeine Leistungsoptimierung und -verbesserungen. | 12. August 2025 |
| v1.7.2 | v1.7.1 | Verbesserte Unterstützung für die lokale Agenteninstallation für RPM-basierte Linux-Distributionen. | 23. Juli 2025 |
| v1.7.1 | 1.7.1 | Unterstützung für Fedora 40 und Fedora 41 hinzugefügt. Eine Liste aller verifizierten Betriebssystemverteilungen für Amazon EC2 EC2-Ressourcen finden Sie unter. [Überprüfen Sie die architektonischen Anforderungen](prereq-runtime-monitoring-ec2-support.md#validating-architecture-req-ec2) Allgemeine Leistungsoptimierung und -verbesserungen. | 03. Juni 2025 |
| v1.7.0 | v1.7.0 | Unterstützung für die Oracle Linux-Versionen 8.9 und 9.3 sowie für Rocky Linux Version 9.5 wurde hinzugefügt. Eine Liste aller verifizierten Betriebssystemverteilungen für Amazon EC2 EC2-Ressourcen finden Sie unter. [Überprüfen Sie die architektonischen Anforderungen](prereq-runtime-monitoring-ec2-support.md#validating-architecture-req-ec2) Die Container-ID-Auflösung wurde verbessert. Allgemeine Leistungsoptimierung und Verbesserungen. | 03. April 2025 |
| v1.6.0 | v1.6.0 | Allgemeine Leistungsoptimierung und -verbesserungen. | 6. Februar 2025 |
| v1.5.0 | v1.5.0 | Unterstützung für CentOS Stream 9.0, RedHat 9.4, Fedora 34.0 und Ubuntu 24.04 hinzugefügt. Support für ARM-Instanzen für `.../MetadataDNSRebind` Ergebnisse. Allgemeine Leistungsoptimierung und -verbesserungen. | 20. November 2024 |
| v1.3.1 | v1.3.1 | Support für benutzerdefinierte DNS-Resolver. | 12. September 2024 |
| v1.3.0 | v1.3.0 | Allgemeine Leistungsoptimierung und -verbesserungen. Beinhaltet Unterstützung für die Erfassung zusätzlicher Sicherheitssignale für die future[GuardDuty Runtime Monitoring: Typen finden](findings-runtime-monitoring.md). | 19. August 2024 |
| v1.2.0 | v1.2.0 | Unterstützt die Betriebssystem-Distributionen Ubuntu 20.04, Ubuntu 22.04, Debian 11 und Debian 12. Unterstützt Kernel 6.5 und 6.8. Allgemeine Leistungsoptimierung und -verbesserungen. | 13. Juni 2024 |
| v1.1.0 | v1.1.0 | Unterstützt die GuardDuty automatische Agentenkonfiguration in Runtime Monitoring für Amazon EC2 EC2-Instances. Unterstützt neue Sicherheitssignale und Erkenntnisse, die mit der Ankündigung der allgemeinen Verfügbarkeit von Runtime Monitoring für EC2-Instances veröffentlicht wurden. Allgemeine Leistungsoptimierung und -verbesserungen. | 26. März 2024 |
| v1.0.2 | v1.0.2 | Unterstützt das neueste Amazon ECS AMIs. | 2. Februar 2024 |
| v1.0.1 | v1.0.1 | Agentenversionen, die vor Version 1.0.2 veröffentlicht wurden, sind nicht mit Amazon ECS kompatibel, die nach dem 31. Januar 2024 AMIs veröffentlicht wurden. Allgemeine Leistungsoptimierung und -verbesserungen. | 23. Januar 2024 |
| v1.0.0 | v1.0.0 | Erste Version der RPM-Installation. Agentenversionen, die vor Version 1.0.2 veröffentlicht wurden, sind nicht mit Amazon ECS kompatibel, die nach dem 31. Januar 2024 AMIs veröffentlicht wurden. | 26. November 2023 |
## GuardDuty Security Agent-Versionen für AWS Fargate (nur Amazon ECS)
Die folgende Tabelle zeigt den Versionsverlauf der Versionen des GuardDuty Security Agents für Fargate (nur Amazon ECS).
| Agent-Version | Container-Bild | Versionshinweise | Datum der Verfügbarkeit |
| --- | --- | --- | --- |
| v1.9.0 | **x86\$164** (): AMD64 `sha256:fd9acaa2326f180f0ed0c5a25d8ff0a2d0498a6e900c34c68d4e973ea7fb26a8` **Graviton** (): ARM64 `sha256:0b04f8c28956684e752677bfd83dbc45afc8a43f7791fa44667b8078ba48a295` | Allgemeine Leistungsoptimierung und Sicherheitsverbesserungen. | 28. Oktober 2025 |
| v1.8.0 | **x86\$164** (): AMD64 `sha256:4425417f39e38b24c1be428bacad1dad53e0645530dcf4422436353bfe358e3a` **Graviton** (): ARM64 `sha256:aff069418fd6825846f8f575c49906a67c8a446d12d9ed0d21ab95bd0d05497b` | Allgemeine Leistungsoptimierung und -verbesserungen. | 12. August 2025 |
| v1.7.0 | **x86\$164** (): AMD64 `sha256:bf9197abdf853607e5fa392b4f97ccdd6ca56dd179be3ce8849e552d96582ac8` **Graviton** (): ARM64 `sha256:56c8683c948bcd82c0dbcebf755204365ac7285994693c11717bd45f86e279c2` | Verbesserte Container-ID-Auflösung. Allgemeine Leistungsoptimierung und Verbesserungen. | 04. April 2025 |
| v1.6.0 | **x86\$164 ()**: AMD64 `sha256:c8dea71d372bc47b2f236f7a091b9a9b06bc8193c1cfe4c9346eb50f89258897` **Graviton** (): ARM64 `sha256:f4032a566b90537646c2a987bef42eca1b498078ccc58a848603f877971a8dbe` | Allgemeine Leistungsoptimierung und -verbesserungen. | 6. Februar 2025 |
| v1.5.0 | **x86\$164** (): AMD64 `sha256:5e6fdc41f9eb748219d0498cd6c1dba6a19d875daec50167a0ac80e5028eac54` **Graviton** (): ARM64 `sha256:d56801ff6864d6014740103b70b1c38431851358d182613bede20fe21090e734` | Support für ARM-Aufgaben für `.../MetadataDNSRebind` Ergebnisse. Allgemeine Leistungsoptimierung und -verbesserungen. | 14. November 2024 |
| v1.4.1 | **x86\$164** (): AMD64 `sha256:ef36a11151ec2d3d7db22273bfb954750dee76f0ac7bec37a7ba7e74c3de1c78` **Graviton** (): ARM64 `sha256:a8844544a59d6b4cba98f8e528b513ac2d97432f208e3ad497cc16b331aa9faa` | Härtung von Container-Images. Allgemeine Leistungsoptimierung und -verbesserungen. | 24. Oktober 2024 |
| v1.3.1 | **x86\$164 ()**: AMD64 `sha256:a6e2307d796e2875907bc4c1c69622c906f3192ddc42ef27b99e0a8f0979f3e0` **Graviton** (): ARM64 `sha256:ad1b6539d806edb504f17e6bcfb8b4026c5e822300afc31c0d23c6a08f9b99e9` | Support für benutzerdefinierte DNS-Resolver. | 11. September 2024 |
| v1.3.0 | **x86\$164** (): AMD64 `sha256:f1ad3fb2dc55a1110c60eecf4453b9f9c02f29acb261df39814e7d29296bf831` **Graviton** (): ARM64 `sha256:ff81a755d46681e409f55a95beedae9ebbcf5336e1c0b1e6348af7c6518bdbb1` | Allgemeine Leistungsoptimierung und -verbesserungen. Beinhaltet Unterstützung für die Erfassung zusätzlicher Sicherheitssignale für die future GuardDuty [GuardDuty Runtime Monitoring: Typen finden](findings-runtime-monitoring.md). | 9. August 2024 |
| v1.2.0 | **x86\$164 ()**: AMD64 `sha256:1dbad20ac2dc66d52d00bb28dde4281fe0d3c5f261b1649b247c2369d9e26b93` **Graviton** (): ARM64 `sha256:91930f8446f5f95b93b8ccb18773992affa401eb3f42da89d68077a56bafa6cd` | Allgemeine Leistungsoptimierung und -verbesserungen. | 31. Mai 2024 |
| v1.1.0 | **x86\$164 ()**: AMD64 `sha256:83ce3cf2ef85a349ed1797a8cf30a008ac5d8c9f673f2835823957e9dcf71657` **Graviton** (): ARM64 `sha256:0d4b61648d7bdeab8ab8d94684f805498927c7d437d318204dcccfe8c9383dc7` | Unterstützt neue Sicherheitssignale und Erkenntnisse. Allgemeine Leistungsoptimierung und -verbesserungen. | 01. Mai 2024 |
| v1.0.1 | **x86\$164** (): AMD64 `sha256:9f8cd438fb66f62d09bfc641286439f7ed5177988a314a6021ef4ff880642e68` **Graviton** (): ARM64 `sha256:82c66bb615bd0d1e96db77b1f1fb51dc03220caa593b1962249571bf7147d1b7` | Allgemeine Leistungsoptimierung und -verbesserungen. | 26. Januar 2024 |
| v1.0.0 | **x86\$164 ()**: AMD64 `sha256:359b8b014e5076c625daa1056090e522631587a7afa3b2e055edda6bd1141017` **Graviton** (): ARM64 `sha256:b9438690fa8a86067180a11658bec0f4f838ae3fbd225d04b9306250648b3984` | Erste Version des GuardDuty Security Agents für AWS Fargate (nur Amazon ECS). | 26. November 2023 |
## GuardDuty Security-Agent-Versionen für Amazon EKS-Ressourcen
GuardDuty veröffentlicht von Zeit zu Zeit eine aktualisierte Agentenversion. Wenn der Agent automatisch GuardDuty verwaltet wird, ist er so konzipiert, dass er die Agenten-Updates in Ihrem Namen verwaltet. Wenn Sie den Agenten manuell verwalten, sind Sie dafür verantwortlich, die Agentenversion für Ihre Amazon EKS-Cluster zu aktualisieren.
Bevor Sie den Agenten auf eine bestimmte Version aktualisieren, fügen Sie die Image-Registrierung für GuardDuty `allowed-container-registries` in Ihrem Admission Controller hinzu. Weitere Informationen finden Sie unter [GuardDuty Hosting-Agent für Amazon ECR Repositorys](runtime-monitoring-ecr-repository-gdu-agent.md).
Die folgende Tabelle zeigt den Versionsverlauf des [Amazon GuardDuty EKS-Add-On-Agenten](https://docs.aws.amazon.com/eks/latest/userguide/eks-add-ons.html#add-ons-guard-duty).
| Agent-Version | Container-Bild | Versionshinweise | Datum der Verfügbarkeit | Ende der Standardunterstützung [1](#eks-security-agent-life-support-end) |
| --- | --- | --- | --- | --- |
| v1.12.1 | **x86\$164 ()**: AMD64 `sha256:f29a597745e5acff48809bebac7d8091bbc38229453dd26710c549b817362491` **Graviton** (): ARM64 `sha256:089cebdc7e891177e107a099c9a4e362d9d74b5362cd374b448a16078040f6c6` | Allgemeine Leistungsoptimierung und Updates der Sicherheitsfunktionen. | 17. November 2025 | – |
| v1.11.0 | **x86\$164 ()**: AMD64 `sha256:7c398fd50dee5fe493c361aa7fe191e094ddfa000c65b449a9ed6a5cd53610e7` **Graviton** (): ARM64 `sha256:98a547b47d4770f45e75eb9730c807d9265722ca2f391e0aa5cb19e487ab455f` | Unterstützung für die Betriebssystem-Distributionen Fedora 40 und Fedora 41 wurde hinzugefügt. Weitere Informationen finden Sie unter [Validierung der architektonischen Anforderungen](prereq-runtime-monitoring-eks-support.md#eksrunmon-supported-platform-concepts) (für EKS). Allgemeine Leistungsoptimierung und Sicherheitsverbesserungen. | 29. August 2025 | – |
| v1.10.0 | **x86\$164 ()**: AMD64 `sha256:6dcbe5b055e1ef0af903071ede0b08f755ad5b7e9774a67df5399efdaa1f3d7d` **Graviton** (): ARM64 `sha256:f05368822689610a4bab543abf93d3e070b1b559e62a2e67d82dfa9837600f72` | Verbesserte Container-ID-Auflösung. Allgemeine Leistungsoptimierung und Verbesserungen. | 04. April 2025 | – |
| v1.9.0 | **x86\$164** (): AMD64 `sha256:51c5789ef6570f9bec879ac48a8f4769718cbc31e45430032569917e219af63f` **Graviton** (): ARM64 `sha256:9c2f74e7ea0827b7e422ae4c91fffc6c2bc41a1cdb96c7191d05259d337154e1` | Allgemeine Leistungsoptimierung und -verbesserungen. | 02. März 2025 | – |
| v1.8.1 | **x86\$164 ()**: AMD64 `sha256:f2ce8cf89dbe17e3388cecb35053544dadf21af7770545f8d4b50384076aff47` **Graviton** (): ARM64 `sha256:30f586e4b694e704bcafadfa9081ab0aeff3cfbcde39743a0f1e24f77d79627f` | Unterstützung für CentOS Stream 9.0, RedHat 9.4, Fedora 34.0 und Ubuntu 24.04 hinzugefügt. Support für ARM-Instanzen zum `.../MetadataDNSRebind` Suchen. Allgemeine Leistungsoptimierung und -verbesserungen. | 23. November 2024 | – |
| v1.7.1 | **x86\$164 ()**: AMD64 `sha256:b8b86b5d0872c8b67fecf64ec3d172666360545435a1752447d510951a7fd749` **Graviton** (): ARM64 `sha256:40ac4cfc354fd430ba7897ca1632e9a500ed13eeb0c315c5bcad38680e76b6e9` | Allgemeine Leistungsoptimierung und -verbesserungen. Beinhaltet Unterstützung für die Erfassung zusätzlicher Sicherheitssignale für die future[GuardDuty Runtime Monitoring: Typen finden](findings-runtime-monitoring.md). Support für benutzerdefinierte DNS-Resolver. | 13. September 2024 | – |
| v1.7.0 | **x86\$164** (): AMD64 `sha256:f3a2a8806e6c2a7fd63a91cccf6f7dffcd7e68554a423d610cea8c7e8f2185ec` **Graviton** (): ARM64 `sha256:b1a6db35a072c0de3c695e5e909a03e6c4e1fdbe47ecfaeb2784435cf67ebe0a` | Allgemeine Leistungsoptimierung und -verbesserungen. Beinhaltet Unterstützung für die Erfassung zusätzlicher Sicherheitssignale für die future[GuardDuty Runtime Monitoring: Typen finden](findings-runtime-monitoring.md). | 17. August 2024 | – |
| v1.6.1 | **x86\$164** (): AMD64 `sha256:30650708a6601f6d6b9046f54b30f5fd65af296b1e40b8c24426b9bdb07c3ab1` **Graviton** (): ARM64 `sha256:5f637c42ffb306b20f776d9d83e1e0b4be40ce245be44afcf43a8902b4d71019` | Allgemeine Leistungsoptimierung und -verbesserungen. | 14. Mai 2024 | – |
| v1.6.0 | **x86\$164 ()**: AMD64 `sha256:7dabcbee30d8b053676752fbc19e89f77272d9a6a53cc93731f5872180ef9010` **Graviton** (): ARM64 `sha256:9710f53afccdf4f22b265a1a6fc27f1469403af1f7d5d08c4869a7269cdd2650` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/runtime-monitoring-agent-release-history.html) | 29. April 2024 | – |
| v1.5.0 | **x86\$164** (): AMD64 `sha256:e09a4e70af4058a212f172cc8eb3fc23ad9bed547ed609faa2bb82cf7cc5532d` **Graviton** (): ARM64 `sha256:afc9a3f8f17ae12499d76069efcf1b46271a5a4b2b3f6ba5de54637b8f55d5c6` | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/guardduty/latest/ug/runtime-monitoring-agent-release-history.html) | 07. März 2024 | – |
| v1.4.1 | **x86\$164** (): AMD64 `sha256:66d491927763742660faa87cc2c39bb97b7873039157ae8b90bc999cb73d0b9c` **Graviton** (): ARM64 `sha256:537a330b2dd82357024fb6daeb8761034b7defd43b10dffe0792c9e6d0778b40` | Allgemeine Leistungsoptimierung und -verbesserungen. | 16. Januar 2024 | – |
| v1.4.0 | **x86\$164** (): AMD64 `sha256:848ce13d9430bad554ac23d4699551505326ada2a88e1a721fe9f86b56b52c0f` **Graviton** (): ARM64 `sha256:0c650aeafeeb5f2bcb8b989ac849bedc1fae1a4de1cf6306ffdd9c6aebe67f8e` | Manifest Mount Point unterstützt eine bessere Datenerfassung AppArmor Konfiguration im Manifest Sammle das Befehlszeilenargument Allgemeine Leistungsoptimierung und -verbesserungen | 21. Dezember 2023 | – |
| v1.3.1 | **x86\$164 ()**: AMD64 `sha256:55578fcb7b73097ade5c8404390ef16cf76a7b568490abaae01ac75992b3ea29` **Graviton** (): ARM64 `sha256:e3ce8d66ac2121f8d476eb58f8bc50ab51336647615eb7cf514c21421cb818fd` | Wichtige Sicherheitspatches und Updates. | 23. Oktober 2023 | – |
| v1.3.0 | **x86\$164** (): AMD64 `sha256:6dace2337dfbb7609811be89fb4b23ae0b865f1027ad78fbe69530bfbd46c694` **Graviton** (): ARM64 `sha256:4928a7c6ef40e77c8ec95841323bb9a110db31f12c0ee7ab965e08b43efd01bb` | Unterstützt die Ubuntu-Plattform Unterstützt Kubernetes-Version 1.28 Allgemeine Leistungsverbesserungen und Stabilitätsverbesserungen. | 5. Oktober 2023 | – |
| v1.2.0 | **x86\$164** (): AMD64 `sha256:d610413d662ec042057f05d6942496d7f2c08e9f5a077ea307ffdb5d3f11bcc3` **Graviton** (): ARM64 `sha256:174d7ab28b2f95e5309da80d95b88ad26f602dfe72c2b351a0ef9297a1412bfa` | Zusätzlich zu AMD64 basierten Instances unterstützt v1.2.0 jetzt auch ARM64 basierte Instances. Unterstützung für Bottlerocket hinzugefügt und verifiziert Unterstützt Kubernetes-Version 1.27 Allgemeine Leistungsverbesserungen und Stabilitätsverbesserungen. | 16. Juni 2023 | – |
| v1.1.0 | `sha256:b19ba3a3c1a508d153263ae2fda891a7928b5ca9b3a5692db6c101829303281c` | Über [Kubernetes-Versionen, die vom Security Agent unterstützt werden GuardDuty](prereq-runtime-monitoring-eks-support.md#gdu-agent-supported-k8-version) hinaus unterstützt diese Agentenversion auch Kubernetes Version 1.26. Allgemeine Leistungsverbesserungen und Stabilitätsverbesserungen. | 2. Mai 2023 | 14. Mai 2024 |
| v1.0.0 | `sha256:e38bdd2b1323e89113f1a31bd4bc8e5a8098525dd98e6981a28b9906b1e4411e` | Erste Version des Amazon-EKS-Add-On-Agenten. | 30. März 2023 | 14. Mai 2024 |
**1** Informationen zur Aktualisierung Ihrer aktuellen Agentenversion, für die der Standardsupport bald ausläuft, finden Sie unter[Manuelles Aktualisieren des Security Agents für Amazon EKS-Ressourcen](eksrunmon-update-security-agent.md).
## Zusätzliche Ressourcen — nächste Schritte
Weitere Informationen zu den nächsten Schritten finden Sie in den folgenden Themen:
+ [Voraussetzungen für die Aktivierung von Runtime Monitoring](runtime-monitoring-prerequisites.md)— Bei neuen Agentenversionen gibt es möglicherweise ein Update für den Abschnitt mit den Voraussetzungen. Stellen Sie sicher, dass Ihre Ressourcen die neuesten Voraussetzungen erfüllen.
+ [Verwaltung von GuardDuty Security Agents](runtime-monitoring-managing-agents.md)- Wenn Sie den Agenten manuell verwalten, sind Sie für die Verwaltung der Updates der Agentenversion verantwortlich, die auf Ihren Ressourcen ausgeführt wird. Führen Sie je nach Ressourcentyp (Amazon EKS oder Amazon EC2-Amazon ECS) die Schritte zur Aktualisierung des Security Agents durch. Stellen Sie außerdem sicher, dass Sie Ihre [VPC-Endpunktkonfiguration](https://docs.aws.amazon.com/guardduty/latest/ug/validate-vpc-endpoint-config-runtime-monitoring.html) validieren.
+ [Überprüfung der Statistiken zur Laufzeitabdeckung und Behebung von Problemen](runtime-monitoring-assessing-coverage.md)- Nachdem Sie den Security Agent aktualisiert haben, können Sie die Laufzeitabdeckung Ihrer Ressource beurteilen. Wenn es ein Problem mit der Abdeckung gibt, führen Sie die entsprechenden Schritte zur Fehlerbehebung durch.
# Ressourcen in Runtime Monitoring deaktivieren, deinstallieren und bereinigen
Dieser Abschnitt bezieht sich darauf, AWS-Konto ob Sie die Laufzeitüberwachung oder nur die GuardDuty automatische Agentenkonfiguration für einen Ressourcentyp deaktivieren möchten.
**Deaktivierung der GuardDuty automatisierten Agentenkonfiguration**
GuardDuty entfernt den Security Agent, der auf Ihrer Ressource installiert ist, nicht. GuardDuty Beendet jedoch die Verwaltung der Updates für den Security Agent.
GuardDuty empfängt weiterhin die Runtime-Ereignisse von Ihrem Ressourcentyp. Um zu verhindern, dass Ihre Nutzungsstatistiken beeinträchtigt werden, stellen Sie sicher, dass der GuardDuty Security Agent aus Ihrer Ressource entfernt wird.
Unabhängig davon, ob ein gemeinsam genutzter VPC-Endpunkt AWS-Konto verwendet oder GuardDuty nicht, wird der VPC-Endpunkt nicht gelöscht. Falls erforderlich, müssen Sie den VPC-Endpunkt manuell löschen.
**Runtime Monitoring **und** EKS Runtime Monitoring deaktivieren**
Dieser Abschnitt gilt für Sie in den folgenden Szenarien:
+ Sie haben EKS Runtime Monitoring nie separat aktiviert und jetzt haben Sie Runtime Monitoring deaktiviert.
+ Sie deaktivieren sowohl Runtime Monitoring als auch EKS Runtime Monitoring. Wenn Sie sich über den Konfigurationsstatus von EKS Runtime Monitoring nicht sicher sind, finden Sie weitere Informationen unter[Überprüfen Sie den Konfigurationsstatus von EKS Runtime Monitoring](checking-eks-runtime-monitoring-enable-status.md).
**Runtime Monitoring deaktivieren, ohne EKS Runtime Monitoring zu deaktivieren**
In diesem Szenario haben Sie zu einem bestimmten Zeitpunkt EKS Runtime Monitoring aktiviert und später auch Runtime Monitoring aktiviert, ohne EKS Runtime Monitoring zu deaktivieren.
Wenn Sie jetzt Runtime Monitoring deaktivieren, müssen Sie auch EKS Runtime Monitoring deaktivieren. Andernfalls fallen weiterhin Nutzungskosten für EKS Runtime Monitoring an.
Wenn die zuvor aufgelisteten Szenarien auf Sie zutreffen, GuardDuty wird in Ihrem Konto die folgenden Maßnahmen ergriffen:
+ GuardDuty löscht den VPC-Endpunkt mit dem Tag`GuardDutyManaged`:`true`. Dies ist die VPC, die für die Verwaltung des automatisierten Security Agents erstellt GuardDuty wurde.
+ GuardDuty löscht die Sicherheitsgruppe, die als `GuardDutyManaged` gekennzeichnet wurde:. `true`
+ Bei einer gemeinsam genutzten VPC, die von mindestens einem Teilnehmerkonto verwendet wurde, werden GuardDuty weder der VPC-Endpunkt noch die Sicherheitsgruppe gelöscht, die der gemeinsam genutzten VPC-Ressource zugeordnet ist.
+ GuardDuty Löscht für eine Amazon EKS-Ressource den Security Agent. Dies ist unabhängig davon, ob die Verwaltung manuell oder über erfolgt GuardDuty.
Bei einer Amazon ECS-Ressource GuardDuty kann der Security Agent nicht von dieser Ressource deinstalliert werden, da eine ECS-Aufgabe unveränderlich ist. Dies ist unabhängig davon, wie Sie den Security Agent verwalten — manuell oder automatisch über GuardDuty. Nachdem Sie Runtime Monitoring deaktiviert haben, GuardDuty wird kein Sidecar-Container angehängt, wenn eine neue ECS-Task ausgeführt wird. Hinweise zur Arbeit mit Fargate-ECS-Aufgaben finden Sie unter. [So funktioniert Runtime Monitoring mit Fargate (nur Amazon ECS)](how-runtime-monitoring-works-ecs-fargate.md)
GuardDuty Deinstalliert für eine Amazon EC2 EC2-Ressource den Security Agent nur dann von allen Systems Manager (SSM) verwalteten Amazon EC2 EC2-Instances, wenn er die folgenden Bedingungen erfüllt:
+ Ihre Ressource ist **nicht mit `GuardDutyManaged` dem Tag: Exclusion-Tag** gekennzeichnet. `false`
+ GuardDuty muss über Berechtigungen für den Zugriff auf die Tags in den Instanzmetadaten verfügen. Für diese EC2-Ressource ist der **Zugriff auf Tags in Instanz-Metadaten** auf **Zulassen** gesetzt.
**Wenn Sie die manuelle Verwaltung des Security Agents beenden**
Unabhängig davon, welche Methode Sie für die Installation und Verwaltung des GuardDuty Security Agents verwenden, müssen Sie den Security Agent entfernen, um die Überwachung der GuardDuty Runtime-Ereignisse in Ihrer Ressource zu beenden. Wenn Sie die Überwachung der Laufzeitereignisse von einem Ressourcentyp in einem Konto beenden möchten, können Sie auch den Amazon VPC-Endpunkt löschen.
# Manuelles Deinstallieren des Security Agents für Amazon EC2 EC2-Ressourcen
In diesem Abschnitt finden Sie Methoden zur Deinstallation des GuardDuty Security Agents von Ihren Amazon EC2 EC2-Ressourcen. Wenn Sie den Security Agent manuell verwalten, sind Sie dafür verantwortlich, den Agenten aus den Ressourcen zu entfernen. GuardDuty ergreift keine Maßnahmen in Bezug auf die Ressourcen, die Sie verwalten.
Wenn Sie einen Amazon VPC-Endpunkt manuell erstellt haben, können Sie nach der Deinstallation des Security Agents auf allen überwachten Ressourcentypen in Ihrem Konto wählen, ob Sie den VPC-Endpunkt löschen möchten. Dies ist ein separater Schritt. Weitere Informationen finden Sie unter [To delete a VPC endpoint](clean-up-guardduty-agent-resources-process.md#runtime-monitoring-delete-vpc-endpoint).
Je nachdem, wie Sie den Security Agent in Ihrer Ressource installiert haben, wählen Sie eine der folgenden Methoden, um ihn zu deinstallieren.
**Topics**
+ [Methode 1 — Mit dem Befehl Ausführen](#remove-gdu-ec2-agent-run-command)
+ [Methode 2 — Mithilfe von Linux-Paketmanagern](#remove-gdu-ec2-agent-rpm-script)
## Methode 1 — Mit dem Befehl Ausführen
Wenn Sie den Security Agent mit installiert haben[Methode 1 — Verwenden AWS Systems Manager](installing-gdu-security-agent-ec2-manually.md#install-gdu-by-using-sys-runtime-monitoring), gehen Sie wie folgt vor, um den Agent zu deinstallieren:
**Um den GuardDuty Security Agent zu deinstallieren**
1. Sie können den GuardDuty Security Agent deinstallieren, indem Sie die im *AWS Systems Manager Benutzerhandbuch AWS Systems Manager * [unter Befehl ausführen](https://docs.aws.amazon.com/systems-manager/latest/userguide/run-command.html) angegebenen Schritte ausführen ausführen. Verwenden Sie die Aktion Deinstallieren in den Parametern, um den GuardDuty Security Agent zu deinstallieren.
Stellen Sie im Abschnitt **Ziele** sicher, dass sich die Auswirkungen nur auf die Amazon EC2 EC2-Instances auswirken, von denen Sie den Security Agent deinstallieren möchten.
Verwenden Sie das folgende GuardDuty Dokument und den folgenden Vertriebspartner:
+ Name des Dokuments: `AmazonGuardDuty-ConfigureRuntimeMonitoringSsmPlugin`
+ Vertriebspartner: `AmazonGuardDuty-RuntimeMonitoringSsmPlugin`
1. Nachdem Sie alle Details angegeben haben und **Ausführen** wählen, wird der Security Agent, den er auf den Ziel-Instances von Amazon EC2 installiert hat, entfernt.
Um die Amazon VPC-Endpunktkonfiguration zu entfernen, müssen Sie sowohl Runtime Monitoring als auch Amazon EKS Runtime Monitoring deaktivieren.
1. Wenn Sie auch den VPC-Endpunkt löschen möchten, der diesem Security Agent zugeordnet ist, finden Sie weitere Informationen unter[To delete a VPC endpoint](clean-up-guardduty-agent-resources-process.md#runtime-monitoring-delete-vpc-endpoint).
## Methode 2 — Mithilfe von Linux-Paketmanagern
Wenn Sie den Security Agent mit installiert haben[Methode 2 — Verwenden von Linux-Paketmanagern](installing-gdu-security-agent-ec2-manually.md#install-gdu-by-rpm-scripts-runtime-monitoring), gehen Sie wie folgt vor, um den Agent zu deinstallieren:
**Um den GuardDuty Security Agent zu deinstallieren**
1. Connect zu Ihrer Instance her. Eine Anleitung dazu finden Sie unter [Connect zu Ihrer Linux-Instance mithilfe eines SSH-Clients](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-ssh.html) im *Amazon EC2 EC2-Benutzerhandbuch*.
1.
**Befehl zur Deinstallation**
Mit dem folgenden Befehl wird der GuardDuty Security Agent von der Amazon EC2 EC2-Instance deinstalliert, zu der Sie eine Verbindung herstellen:
+ Für RPM:
```
sudo rpm -e amazon-guardduty-agent
```
+ Für Debian:
```
sudo dpkg --purge amazon-guardduty-agent
```
Nachdem Sie den Befehl ausgeführt haben, können Sie auch die mit dem Befehl verknüpften Protokolle überprüfen.
1. Wenn Sie auch den VPC-Endpunkt löschen möchten, der diesem Security Agent zugeordnet ist, finden Sie weitere Informationen unter[To delete a VPC endpoint](clean-up-guardduty-agent-resources-process.md#runtime-monitoring-delete-vpc-endpoint).
# Ressourcen des Security Agents bereinigen
In diesem Abschnitt wird erklärt, wie Sie die mit dem Security Agent verknüpften AWS Ressourcen bereinigen können. Wie unter aufgeführt[Deaktivieren, Deinstallieren und Bereinigen von Ressourcen](runtime-monitoring-agent-resource-clean-up.md), GuardDuty werden nicht alle Security Agent-Ressourcen gelöscht oder entfernt. Der folgende Abschnitt enthält Anweisungen, wie Sie die Security Agent-Ressourcen löschen können.
**So löschen Sie den Amazon VPC-Endpunkt**
Wenn Sie den Security Agent manuell verwalten, haben Sie möglicherweise manuell einen Amazon VPC-Endpunkt erstellt. Nachdem Sie den Security Agent für alle überwachten Ressourcen in Ihrem Konto deinstalliert haben, können Sie diesen VPC-Endpunkt löschen.
Die folgende Liste enthält Szenarien für die Verwendung einer gemeinsam genutzten VPC im Vergleich zur Nichtverwendung einer gemeinsam genutzten VPC.
+ Ohne gemeinsam genutzte VPC — Wenn Sie eine Ressource in einem Konto nicht mehr überwachen möchten, sollten Sie den Amazon VPC-Endpunkt löschen.
+ Mit einer gemeinsam genutzten VPC — Wenn ein gemeinsam genutztes VPC-Besitzerkonto die gemeinsam genutzte VPC-Ressource löscht, die noch verwendet wurde, kann der Deckungsstatus von Runtime Monitoring (und gegebenenfalls EKS Runtime Monitoring) für die Ressourcen in Ihrem gemeinsamen VPC-Eigentümerkonto und dem teilnehmenden Konto fehlerhaft werden. Informationen zum Deckungsstatus finden Sie unter. [Überprüfung der Statistiken zur Laufzeitabdeckung und Behebung von Problemen](runtime-monitoring-assessing-coverage.md)
Informationen zum Löschen des VPC-Endpunkts finden Sie im *AWS PrivateLink Handbuch* unter [Löschen eines Schnittstellenendpunkts](https://docs.aws.amazon.com/vpc/latest/privatelink/delete-interface-endpoint.html).
**Um die Sicherheitsgruppe zu löschen**
+ Ohne gemeinsam genutzte VPC — Wenn Sie einen Ressourcentyp in einem Konto nicht mehr überwachen möchten, sollten Sie erwägen, die mit der Amazon VPC verknüpfte Sicherheitsgruppe zu löschen.
+ Mit einer gemeinsam genutzten VPC — Wenn das gemeinsame VPC-Besitzerkonto die Sicherheitsgruppe löscht, können alle Teilnehmerkonten, die derzeit die mit der gemeinsam genutzten VPC verknüpfte Sicherheitsgruppe verwenden, der Runtime Monitoring-Abdeckungsstatus für die Ressourcen in Ihrem gemeinsamen VPC-Besitzerkonto und das teilnehmende Konto fehlerhaft werden. Weitere Informationen finden Sie unter [Überprüfung der Statistiken zur Laufzeitabdeckung und Behebung von Problemen](runtime-monitoring-assessing-coverage.md).
Informationen zu den einzelnen Schritten finden Sie unter [Löschen einer Amazon EC2-Sicherheitsgruppe](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/deleting-security-group.html) im *Amazon EC2 EC2-Benutzerhandbuch*.
**So entfernen Sie den GuardDuty Security Agent aus einem EKS-Cluster**
Informationen zum Entfernen des Security Agents aus Ihrem EKS-Cluster, den Sie nicht mehr überwachen möchten, finden Sie unter [Entfernen eines Amazon EKS-Add-ons aus einem Cluster](https://docs.aws.amazon.com/eks/latest/userguide/removing-an-add-on.html) im *Amazon EKS-Benutzerhandbuch*.
Durch das Entfernen des EKS-Add-On-Agenten wird der `amazon-guardduty`-Namespace nicht aus dem EKS-Cluster entfernt. Um einen `amazon-guardduty`-Namespace zu löschen, sehen Sie [Einen Namespace löschen](https://kubernetes.io/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace).
**So löschen Sie den `amazon-guardduty` Namespace (EKS-Cluster)**
Wenn Sie die automatische Agentenkonfiguration deaktivieren, wird der `amazon-guardduty` Namespace nicht automatisch aus Ihrem EKS-Cluster entfernt. Um einen `amazon-guardduty`-Namespace zu löschen, sehen Sie [Einen Namespace löschen](https://kubernetes.io/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace).