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.
# Behebung der Ergebnisse des EKS-Schutzes
Amazon GuardDuty generiert [Ergebnisse](guardduty_findings.md), die auf potenzielle Kubernetes-Sicherheitsprobleme hinweisen, wenn EKS-Schutz für Ihr Konto aktiviert ist. Weitere Informationen finden Sie unter [EKS-Schutz](kubernetes-protection.md). In den folgenden Abschnitten werden die empfohlenen Schritte zur Behebung für alle Szenarien beschrieben. Spezifische Behebungsmaßnahmen werden im Eintrag für diesen spezifischen Erkenntnistyp beschrieben. Sie können auf die vollständigen Informationen zu einem Erkenntnistyp zugreifen, indem Sie ihn aus der [Tabelle für aktive Erkenntnistypen](guardduty_finding-types-active.md) auswählen.
Wenn einer der EKS-Schutzerkennungstypen erwartungsgemäß generiert wurde, können Sie erwägen, ihn hinzuzufügen, [Unterdrückungsregeln in GuardDuty](findings_suppression-rule.md) um future Warnmeldungen zu verhindern.
Verschiedene Arten von Angriffen und Konfigurationsprobleme können zu Ergebnissen von GuardDuty EKS Protection führen. Dieser Leitfaden hilft Ihnen dabei, die Hauptursachen der GuardDuty Probleme in Ihrem Cluster zu ermitteln, und enthält entsprechende Anleitungen zur Problembehebung. Im Folgenden sind die Hauptursachen aufgeführt, die zu den Ergebnissen von GuardDuty Kubernetes geführt haben:
+ [Mögliche Konfigurationsprobleme](#compromised-kubernetes-config)
+ [Behebung potenziell gefährdeter Kubernetes-Benutzer](#compromised-kubernetes-user)
+ [Behebung potenziell gefährdeter Kubernetes-Pods](#compromised-kubernetes-pod)
+ [Behebung potenziell gefährdeter Kubernetes-Knoten](#compromised-kubernetes-node)
+ [Behebung potenziell gefährdeter Container-Images](#compromised-kubernetes-image)
**Anmerkung**
Vor Kubernetes Version 1.14 war die `system:unauthenticated` Gruppe standardmäßig mit und verknüpft. `system:discovery` `system:basic-user` **ClusterRoles** Dies könnte unbeabsichtigten Zugriff durch anonyme Benutzer ermöglichen. Durch Cluster-Updates werden diese Berechtigungen nicht aufgehoben. Das bedeutet, dass diese Berechtigungen auch dann noch gültig sind, wenn Sie Ihren Cluster auf Version 1.14 oder höher aktualisiert haben. Wir empfehlen, dass Sie die Zuordnung dieser Berechtigungen zu der `system:unauthenticated`-Gruppe aufheben.
Weitere Informationen zum Entfernen dieser Berechtigungen finden Sie unter [Sichern von Amazon EKS-Clustern mit bewährten Methoden](https://docs.aws.amazon.com/eks/latest/userguide/security-best-practices.html) im **Amazon EKS-Benutzerhandbuch**.
## Mögliche Konfigurationsprobleme
Wenn eine Erkenntnis auf ein Konfigurationsproblem hindeutet, finden Sie im Abschnitt zur Behebung dieses Fehlers Anleitungen zur Lösung dieses speziellen Problems. Weitere Informationen finden Sie unter den folgenden Erkenntnistypen, die auf Konfigurationsprobleme hinweisen:
+ [Policy:Kubernetes/AnonymousAccessGranted](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-anonymousaccessgranted)
+ [Policy:Kubernetes/ExposedDashboard](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-exposeddashboard)
+ [Policy:Kubernetes/AdminAccessToDefaultServiceAccount](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-adminaccesstodefaultserviceaccount)
+ [Policy:Kubernetes/KubeflowDashboardExposed](guardduty-finding-types-eks-audit-logs.md#policy-kubernetes-kubeflowdashboardexposed)
+ Jeder Befund, der endet in **SuccessfulAnonymousAccess**
## Behebung potenziell gefährdeter Kubernetes-Benutzer
Ein GuardDuty Befund kann auf einen kompromittierten Kubernetes-Benutzer hinweisen, wenn ein im Ergebnis identifizierter Benutzer eine unerwartete API-Aktion ausgeführt hat. Sie können den Benutzer im Bereich **Kubernetes-Benutzerdetails** im Erkenntnisfenster der Konsole oder in der `resource.kubernetesDetails.kubernetesUserDetails` der JSON-Datei mit den Erkenntnissen identifizieren. Zu diesen Benutzerdetails gehören `user name`, `uid` und die Kubernetes-Gruppen, zu denen der Benutzer gehört.
Wenn der Benutzer mit einer IAM-Entität auf den Workload zugegriffen hat, können Sie den `Access Key details`-Abschnitt verwenden, um die Details einer IAM-Rolle oder eines IAM-Benutzers zu identifizieren. Sehen Sie sich die folgenden Benutzertypen und deren Anleitungen zur Problembehebung an.
**Anmerkung**
Sie können Amazon Detective verwenden, um die in der Erkenntnis identifizierte IAM-Rolle oder den IAM-Benutzer genauer zu untersuchen. Wählen Sie beim Anzeigen der Ergebnisdetails in der GuardDuty Konsole **Investigate in Detective** aus. Wählen Sie dann einen AWS Benutzer oder eine Rolle aus den aufgelisteten Elementen aus, um sie in Detective zu untersuchen.
**Integrierter Kubernetes-Admin** – Der Standardbenutzer, der von Amazon EKS der IAM-Identität zugewiesen wurde, die den Cluster erstellt hat. Dieser Benutzertyp wird durch den Benutzernamen identifiziert `kubernetes-admin`.
**Wie Sie einem integrierten Kubernetes-Administrator den Zugriff entziehen:**
+ Identifizieren Sie den `userType` aus dem `Access Key details`-Abschnitt.
+ Wenn der `userType` **Rolle** ist und die Rolle zu einer EC2-Instance-Rolle gehört:
+ Identifizieren Sie diese Instance und folgen Sie dann den Anweisungen unter [Behebung einer potenziell gefährdeten Amazon EC2 EC2-Instance](compromised-ec2.md).
+ Wenn es sich bei `userType` um einen **Benutzer** handelt oder um eine **Rolle**, die von einem Benutzer übernommen wurde:
1. [Rotieren Sie den Zugriffsschlüssel](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) dieses Benutzers.
1. Rotieren Sie alle Geheimnisse, auf die der Benutzer Zugriff hatte.
1. Weitere Informationen finden Sie in den Informationen in [My AWS-Konto may be compromitted](https://repost.aws/knowledge-center/potential-account-compromise).
**OIDC-authentifizierter Benutzer** – Ein Benutzer, dem der Zugriff über einen OIDC-Anbieter gewährt wurde. In der Regel hat ein OIDC-Benutzer eine E-Mail-Adresse als Benutzernamen. Sie können mit den folgenden Befehl überprüfen, ob Ihr Cluster OIDC verwendet: `aws eks list-identity-provider-configs --cluster-name your-cluster-name `
**Um einem OIDC-authentifizierten Benutzer den Zugriff zu entziehen:**
1. Rotieren Sie die Anmeldeinformationen dieses Benutzers im OIDC-Anbieter.
1. Rotieren Sie alle Geheimnisse, auf die der Benutzer Zugriff hatte.
**AWS ConfigMap -Auth-definierter Benutzer** — Ein IAM-Benutzer, dem über ein -auth Zugriff gewährt wurde. AWS ConfigMap Weitere Informationen finden Sie unter [Verwalten von Benutzern oder IAM-Rollen für Ihren Cluster](https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html) im **Amazon EKS-Benutzerhandbuch**. Sie können ihre Berechtigungen überprüfen, indem Sie den folgenden Befehl verwenden: `kubectl edit configmaps aws-auth --namespace kube-system`
**Um einem AWS ConfigMap Benutzer den Zugriff zu entziehen:**
1. Verwenden Sie den folgenden Befehl, um das zu öffnen ConfigMap.
```
kubectl edit configmaps aws-auth --namespace kube-system
```
1. Identifizieren Sie die Rolle oder den Benutzereintrag im Abschnitt **MapRoles** oder **MapUsers** mit demselben Benutzernamen wie im Abschnitt Kubernetes-Benutzerdetails Ihres Ergebnisses. GuardDuty Sehen Sie sich das folgende Beispiel an, in dem der Admin-Benutzer in einer Erkenntnis identifiziert wurde.
```
apiVersion: v1
data:
mapRoles: |
- rolearn: arn:aws:iam::444455556666:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
user name: system:node:EC2_PrivateDNSName
groups:
- system:bootstrappers
- system:nodes
mapUsers: |
- userarn: arn:aws:iam::123456789012:user/admin
username: admin
groups:
- system:masters
- userarn: arn:aws:iam::111122223333:user/ops-user
username: ops-user
groups:
- system:masters
```
1. Entfernen Sie diesen Benutzer aus dem. ConfigMap Sehen Sie sich das folgende Beispiel an, in dem der Admin-Benutzer entfernt wurde.
```
apiVersion: v1
data:
mapRoles: |
- rolearn: arn:aws:iam::111122223333:role/eksctl-my-cluster-nodegroup-standard-wo-NodeInstanceRole-1WP3NUE3O6UCF
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
mapUsers: |
- userarn: arn:aws:iam::111122223333:user/ops-user
username: ops-user
groups:
- system:masters
```
1. Wenn es sich bei `userType` um einen **Benutzer** handelt oder um eine **Rolle**, die von einem Benutzer übernommen wurde:
1. [Rotieren Sie den Zugriffsschlüssel](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_credentials_access-keys.html#Using_RotateAccessKey) dieses Benutzers.
1. Rotieren Sie alle Geheimnisse, auf die der Benutzer Zugriff hatte.
1. Weitere Informationen finden Sie in den Informationen [AWS unter Mein Konto ist möglicherweise gefährdet](https://aws.amazon.com//premiumsupport/knowledge-center/potential-account-compromise/).
Wenn die Erkenntnis keinen `resource.accessKeyDetails`-Abschnitt enthält, handelt es sich bei dem Benutzer um ein Kubernetes-Servicekonto.
**Servicekonto** – Das Servicekonto stellt eine Identität für Pods bereit und kann anhand eines Benutzernamens mit dem folgenden Format identifiziert werden: `system:serviceaccount:namespace:service_account_name`.
**Um den Zugriff auf ein Servicekonto zu widerrufen:**
1. Rotieren Sie die Anmeldeinformationen für das Servicekonto.
1. Lesen Sie die Hinweise zur Pod-Kompromittierung im folgenden Abschnitt.
## Behebung potenziell gefährdeter Kubernetes-Pods
Wenn in dem `resource.kubernetesDetails.kubernetesWorkloadDetails` Abschnitt Details zu einer Pod- oder Workload-Ressource GuardDuty angegeben sind, wurde diese Pod- oder Workload-Ressource potenziell kompromittiert. Ein GuardDuty Ergebnis kann darauf hinweisen, dass ein einzelner Pod kompromittiert wurde oder dass mehrere Pods durch eine Ressource auf höherer Ebene kompromittiert wurden. In den folgenden Kompromissszenarien finden Sie Anleitungen zur Identifizierung des oder der Pods, die kompromittiert wurden.
**Kompromittierung einzelner Pods**
Wenn es sich bei dem `type`-Feld innerhalb des `resource.kubernetesDetails.kubernetesWorkloadDetails`-Abschnitts um **Pods** handelt, identifiziert die Erkenntnis einzelne Pods. Das Namensfeld ist der `name` der Pods und das `namespace`-Feld ist sein Namespace.
Informationen zur Identifizierung des Worker-Knotens, auf dem die Pods ausgeführt werden, finden Sie unter [Identifizieren der problematischen Pods und des Worker-Knotens](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pod_and_worker_node) im *Amazon EKS Best Practices Guide*.
**Pods wurden über die Workload-Ressource kompromittiert**
Wenn das `type`-Feld innerhalb des `resource.kubernetesDetails.kubernetesWorkloadDetails`-Abschnitts eine **Workload-Ressource** identifiziert, z. B. eine `Deployment`, ist es wahrscheinlich, dass alle Pods innerhalb dieser Workload-Ressource kompromittiert wurden.
Informationen zur Identifizierung aller Pods der Workload-Ressource und der Knoten, auf denen sie ausgeführt werden, finden Sie unter [Identifizieren der problematischen Pods und Worker-Knoten anhand des Workload-Namens](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pods_and_worker_nodes_using_workload_name) im *Amazon EKS Best Practices Guide*.
**Pods wurden über das Servicekonto kompromittiert**
Wenn aufgrund eines GuardDuty Fundes ein Servicekonto in dem `resource.kubernetesDetails.kubernetesUserDetails` Abschnitt identifiziert wird, ist es wahrscheinlich, dass Pods, die das identifizierte Servicekonto verwenden, kompromittiert wurden. Der durch eine Erkenntnis gemeldete Benutzername ist ein Servicekonto, wenn er das folgende Format hat: `system:serviceaccount:namespace:service_account_name`.
Informationen zur Identifizierung aller Pods, die das Dienstkonto verwenden, und der Knoten, auf denen sie ausgeführt werden, finden Sie unter [Identifizieren der problematischen Pods und Worker-Knoten anhand des Dienstkontonamens](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_the_offending_pods_and_worker_nodes_using_service_account_name) im *Amazon EKS Best Practices Guide*.
Nachdem Sie alle gefährdeten Pods und die Knoten, auf denen sie ausgeführt werden, identifiziert haben, finden Sie im *Amazon EKS* [Best Practices Guide weitere Informationen unter Isolieren des Pods durch Erstellen einer Netzwerkrichtlinie, die jeglichen eingehenden und ausgehenden Datenverkehr zum Pod verweigert](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod).
**So beheben Sie einen potenziell kompromittierten Pod:**
1. Identifizieren Sie die Schwachstelle, durch die die Pods gefährdet wurden.
1. Implementieren Sie das Update für diese Schwachstelle und starten Sie neue Ersatz-Pods.
1. Löschen Sie die anfälligen Pods.
Weitere Informationen finden Sie unter [Kompromittierte Pod- oder Workload-Ressource erneut bereitstellen](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_redeploy_compromised_pod_or_workload_resource) im *Amazon EKS Best Practices Guide*.
Wenn dem Worker-Knoten eine IAM-Rolle zugewiesen wurde, die es Pods ermöglicht, auf andere AWS Ressourcen zuzugreifen, entfernen Sie diese Rollen aus der Instance, um weiteren Schaden durch den Angriff zu verhindern. Wenn dem Pod eine IAM-Rolle zugewiesen wurde, sollten Sie ebenfalls prüfen, ob Sie die IAM-Richtlinien sicher aus der Rolle entfernen können, ohne andere Workloads zu beeinträchtigen.
## Behebung potenziell gefährdeter Container-Images
Wenn ein GuardDuty Ergebnis auf eine Pod-Kompromittierung hindeutet, könnte das Image, das zum Starten des Pods verwendet wurde, potenziell bösartig oder kompromittiert sein. GuardDuty Die Ergebnisse identifizieren das Container-Image innerhalb des `resource.kubernetesDetails.kubernetesWorkloadDetails.containers.image` Feldes. Sie können feststellen, ob das Image bösartig ist, indem Sie es auf Malware scannen.
**So beheben Sie ein potenziell kompromittiertes Container-Image:**
1. Beenden Sie sofort die Verwendung des Images und entfernen Sie es aus Ihrem Image-Repository.
1. Identifizieren Sie alle Pods, die das potenziell kompromittierte Image verwenden.
Weitere Informationen finden Sie unter [Identifizieren von Pods mit anfälligen oder gefährdeten Images und Worker-Knoten](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_identify_pods_with_vulnerable_or_compromised_images_and_worker_nodes) im *Amazon EKS Best Practices Guide*.
1. Isolieren Sie die potenziell gefährdeten Pods, wechseln Sie die Anmeldeinformationen ab und sammeln Sie Daten für die Analyse. Weitere Informationen finden Sie [im *Amazon EKS Best* Practices Guide unter Isolieren des Pods durch Erstellen einer Netzwerkrichtlinie, die den gesamten eingehenden und ausgehenden Datenverkehr zum Pod verweigert](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod).
1. Löschen Sie alle Pods, die das potenziell kompromittierte Image verwenden.
## Behebung potenziell gefährdeter Kubernetes-Knoten
Ein GuardDuty Befund kann auf eine Kompromittierung eines Knotens hinweisen, wenn der im Befund identifizierte Benutzer eine Knotenidentität darstellt oder wenn das Ergebnis auf die Verwendung eines privilegierten Containers hindeutet.
Die Benutzeridentität ist ein Worker-Knoten, wenn das Feld für den **Benutzernamen** das folgende Format hat: `system:node:node name`. Beispiel, `system:node:ip-192-168-3-201.ec2.internal`. Dies weist darauf hin, dass der Angreifer Zugriff auf den Knoten erhalten hat und die Anmeldeinformationen des Knotens verwendet, um mit dem Kubernetes-API-Endpunkt zu kommunizieren.
Eine Erkenntnis weist auf die Verwendung eines privilegierten Containers hin, wenn für einen oder mehrere der in der Erkenntnis aufgelisteten Container das Erkenntnisfeld `resource.kubernetesDetails.kubernetesWorkloadDetails.containers.securityContext.privileged` auf `True` gesetzt ist.
**Gehen Sie wie folgt vor, um einen potenziell kompromittierten Knoten zu beheben:**
1. Isolieren Sie den Pod, wechseln Sie seine Anmeldeinformationen ab und sammeln Sie Daten für forensische Analysen.
Weitere Informationen finden Sie [im *Amazon EKS Best* Practices Guide unter Isolieren des Pods durch Erstellen einer Netzwerkrichtlinie, die den gesamten eingehenden und ausgehenden Datenverkehr zum Pod verweigert](https://docs.aws.amazon.com/eks/latest/best-practices/incident-response-and-forensics.html#_isolate_the_pod_by_creating_a_network_policy_that_denies_all_ingress_and_egress_traffic_to_the_pod).
1. Identifizieren Sie die Dienstkonten, die von allen Pods verwendet werden, die auf dem potenziell gefährdeten Knoten ausgeführt werden. Überprüfen Sie ihre Berechtigungen und rotieren Sie die Servicekonten bei Bedarf.
1. Beenden Sie den potenziell gefährdeten Knoten.