Überprüfen der Abdeckungsstatistiken Änderung des Deckungsstatus mit EventBridge Benachrichtigungen Behebung von Problemen mit der Runtime-Abdeckung von Amazon ECS — Fargate

Runtime-Abdeckung und Fehlerbehebung für ECS Amazon-Cluster

Die Laufzeitabdeckung für ECS Amazon-Cluster umfasst die Aufgaben, die auf AWS Fargate ECS Amazon-Container-Instances ausgeführt werden ¹.

Für einen ECS Amazon-Cluster, der auf Fargate läuft, wird die Laufzeitabdeckung auf Aufgabenebene bewertet. Die Runtime-Abdeckung des ECS Clusters umfasst die Fargate-Aufgaben, die gestartet wurden, nachdem Sie Runtime Monitoring und automatisierte Agentenkonfiguration für Fargate aktiviert haben (ECSnur). Standardmäßig ist eine Fargate-Aufgabe unveränderlich. GuardDuty wird nicht in der Lage sein, den Security Agent zur Überwachung von Containern bei bereits laufenden Aufgaben zu installieren. 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 zu ECS Amazon-Containern finden Sie unter Kapazitätserstellung.

Inhalt

Überprüfen der Abdeckungsstatistiken
Änderung des Deckungsstatus mit EventBridge Benachrichtigungen
Behebung von Problemen mit der Runtime-Abdeckung von Amazon ECS — Fargate

Überprüfen der Abdeckungsstatistiken

Die Deckungsstatistik für die ECS Amazon-Ressourcen, die mit Ihrem eigenen Konto oder Ihren Mitgliedskonten verknüpft sind, ist der Prozentsatz der fehlerfreien ECS Amazon-Cluster im Vergleich zu allen ECS Amazon-Clustern in den ausgewählten AWS-Region. Dies beinhaltet die Abdeckung für ECS Amazon-Cluster, die sowohl mit Fargate- als auch mit EC2 Amazon-Instances verknüpft sind. Die folgende Gleichung stellt dies wie folgt dar:

(Fehlerfreie Cluster/Alle Cluster)*100

Ü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 laufenden Zustand befinden oder kürzlich abgeschlossen wurden.
Auf der Registerkarte ECSClusters Runtime Coverage gibt das Feld Abgedeckte Container-Instances den Abdeckungsstatus der Container-Instances an, die Ihrem ECS Amazon-Cluster zugeordnet sind.

Wenn Ihr ECS Amazon-Cluster nur Fargate-Aufgaben enthält, wird die Anzahl als 0/0 angezeigt.
Wenn Ihr ECS Amazon-Cluster mit einer EC2 Amazon-Instance verknüpft ist, die keinen Sicherheitsagenten hat, hat der ECS Amazon-Cluster auch den Deckungsstatus Unhealthy.

Informationen zur Identifizierung und Behebung des Deckungsproblems für die zugehörige EC2 Amazon-Instance finden Sie unter Behebung von Problemen mit der Amazon EC2 Runtime Coverage Für EC2 Amazon-Instances.

Wählen Sie eine der Zugriffsmethoden, um die Abdeckungsstatistiken für Ihre Konten einzusehen.

Console

Melden Sie sich bei der an AWS Management Console und öffnen Sie die GuardDuty Konsole unter 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 ECSCluster-Laufzeitabdeckung können Sie die Deckungsstatistiken einsehen, die nach dem Abdeckungsstatus jedes ECS Amazon-Clusters zusammengefasst sind, der in der Cluster-Listentabelle verfügbar ist.
- Sie können die Tabelle mit der Cluster-Liste nach den folgenden Spalten filtern:
  - Konto-ID
  - Cluster-Name
  - Agentenverwaltungs-Typ
  - Abdeckungsstatus
Wenn einer Ihrer ECS Amazon-Cluster den Deckungsstatus „Ungesund“ hat, enthält die Spalte „Problem“ zusätzliche Informationen über den Grund für den Status „Fehlerhaft“.

Wenn Ihre ECS Amazon-Cluster mit einer EC2 Amazon-Instance verknüpft sind, navigieren Sie zur Registerkarte EC2Instance-Laufzeitabdeckung und filtern Sie nach dem Feld Clustername, um das zugehörige Problem anzuzeigen.

API/CLI

Führen Sie den ListCoverageAPImit Ihrer eigenen gültigen Melder-ID, Ihrer aktuellen Region und Ihrem Service-Endpunkt aus. Damit können Sie die Instanzliste filtern und sortierenAPI.
- 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 ECS Amazon-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/Konsole oder führen Sie den ListDetectors API.
```
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 den aus GetCoverageStatisticsAPI, 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 Deckungsstatus 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/Konsole oder führen Sie den ListDetectors API.
```
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 Problemen mit der Netzabdeckung finden Sie unterBehebung von Problemen mit der Runtime-Abdeckung von Amazon ECS — Fargate.

Änderung des Deckungsstatus mit EventBridge Benachrichtigungen

Der Abdeckungsstatus Ihres ECS Amazon-Clusters wird möglicherweise als Ungesund angezeigt. Um zu wissen, wann sich der Deckungsstatus ändert, empfehlen wir Ihnen, den Deckungsstatus regelmäßig zu überprüfen 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 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 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 ECS Amazon-Clusters von Healthy zu ändertUnhealthy, detail-type sollte dies der Fall seinGuardDuty Runtime Protection Unhealthy. Um benachrichtigt zu werden, wenn sich der Deckungsstatus von Unhealthy auf ändertHealthy, ersetzen Sie den Wert von detail-type durchGuardDuty 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 Runtime-Abdeckung von Amazon ECS — Fargate

Wenn der Abdeckungsstatus Ihres ECS Amazon-Clusters fehlerhaft ist, können Sie den Grund in der Spalte Problem einsehen.

Die folgende Tabelle enthält die empfohlenen Schritte zur Fehlerbehebung bei Problemen mit Fargate (ECSnur Amazon). Informationen zu Problemen mit der Abdeckung von EC2 Amazon-Instances finden Sie unter Behebung von Problemen mit der Amazon EC2 Runtime Coverage Für EC2 Amazon-Instances.

Art des Problems	Zusatzinformation	Empfohlene Schritte zur Fehlerbehebung
Der Agent meldet sich nicht	Der Agent meldet sich nicht für Aufgaben in `TaskDefinition - 'TASK_DEFINITION'`	Stellen Sie sicher, dass der VPC Endpunkt für die Aufgabe Ihres ECS Amazon-Clusters korrekt konfiguriert ist. Weitere Informationen finden Sie unter Endpunktkonfiguration wird validiert VPC. Wenn Ihre Organisation über eine Richtlinie zur Servicekontrolle (SCP) verfügt, überprüfen Sie, ob die Zugriffsrechte nicht durch die Grenze der `guardduty:SendSecurityTelemetry` Berechtigungen eingeschränkt werden. Weitere Informationen finden Sie unter Validierung der Service-Control-Richtlinie Ihres Unternehmens.
Der Agent meldet sich nicht	`VPC_ISSUE; for task in TaskDefinition - 'TASK_DEFINITION'`	Die VPC Problemdetails finden Sie in den zusätzlichen Informationen.
Der Agent wurde beendet	ExitCode: `EXIT_CODE` für Aufgaben in `TaskDefinition - 'TASK_DEFINITION'`	Die Problemdetails finden Sie in den zusätzlichen Informationen.
	Grund: `REASON` für Aufgaben in `TaskDefinition - 'TASK_DEFINITION'`
	ExitCode: `EXIT_CODE` mit Grund: '`EXIT_CODE`' für Aufgaben in `TaskDefinition - 'TASK_DEFINITION'`
	Der Agent wurde beendet: Grund:: Das Abrufen des Image-Manifests wurde erneut versucht... `CannotPullContainerError`	Die Aufgabenausführungsrolle muss über die folgenden Amazon Elastic Container Registry (AmazonECR) -Berechtigungen verfügen: `... "ecr:GetAuthorizationToken", "ecr:BatchCheckLayerAvailability", "ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage", ...` Weitere Informationen finden Sie unter Geben Sie die ECR Berechtigungen und Subnetzdetails an. Nachdem Sie die ECR Amazon-Berechtigungen hinzugefügt haben, müssen Sie die Aufgabe neu starten. Wenn das Problem weiterhin besteht, finden Sie weitere Informationen unterMein AWS Step Functions Workflow schlägt unerwartet fehl.
VPCDie Endpunkterstellung ist fehlgeschlagen	DNSUm privat zu aktivieren, müssen beide `enableDnsHostnames` VPC Attribute `enableDnsSupport` und die Attribute auf `true` for gesetzt sein `vpcId` (Service:EC2, Statuscode: 400, Anforderungs-ID:`a1b2c3d4-5678-90ab-cdef-EXAMPLE11111`).	Stellen Sie sicher, dass die folgenden VPC Attribute auf `true` — `enableDnsSupport` und `enableDnsHostnames` gesetzt sind. Weitere Informationen finden Sie unter DNSAttribute in Ihrem VPC. Wenn Sie Amazon VPC Console unter verwenden, https://console.aws.amazon.com/vpc/um Amazon zu erstellen, stellen Sie sicherVPC, dass Sie sowohl DNSHostnamen aktivieren als auch DNSAuflösung aktivieren auswählen. Weitere Informationen finden Sie unter VPCKonfigurationsoptionen.
Der Agent wurde nicht bereitgestellt	Der Aufruf von `SERVICE` for Task (n) in wird nicht unterstützt `TaskDefinition - 'TASK_DEFINITION'`	Diese Aufgabe wurde von einem aufgerufen`SERVICE`, der nicht unterstützt wird.
	Die CPU Architektur '`TYPE`' für Aufgabe (n) in wird nicht unterstützt `TaskDefinition - 'TASK_DEFINITION'`	Diese Aufgabe wird auf einer nicht unterstützten CPU Architektur ausgeführt. Hinweise zu unterstützten CPU Architekturen finden Sie unter. Validierung der architektonischen Anforderungen
	`TaskExecutionRole`fehlt bei `TaskDefinition - 'TASK_DEFINITION'`	Die Rolle zur ECS Aufgabenausführung fehlt. Informationen zur Bereitstellung der Aufgabenausführungsrolle und der erforderlichen Berechtigungen finden Sie unterGeben Sie die ECR Berechtigungen und Subnetzdetails an.
	Fehlende Netzwerkkonfiguration `CONFIGURATION_DETAILS` '' für Aufgaben in `TaskDefinition - 'TASK_DEFINITION'`	Probleme mit der Netzwerkkonfiguration können aufgrund fehlender VPC Konfiguration oder fehlender oder leerer Subnetze auftreten. Stellen Sie sicher, dass Ihre Netzwerkkonfiguration korrekt ist. Weitere Informationen finden Sie unter Geben Sie die ECR Berechtigungen und Subnetzdetails an. Weitere Informationen finden Sie unter ECSAmazon-Aufgabendefinitionsparametern im Amazon Elastic Container Service Developer Guide.
	Aufgaben, die gestartet wurden, als Cluster über ein Ausschluss-Tag verfügten, werden von Runtime Monitoring ausgeschlossen. ID (s) der betroffenen Aufgabe: '`TASK_ID`	Wenn Sie das vordefinierte GuardDuty Tag von `GuardDutyManaged` - `true` auf `GuardDutyManaged` - ändern`false`, GuardDuty werden die Runtime-Ereignisse für diesen ECS Amazon-Cluster nicht empfangen. Aktualisieren Sie das Tag auf `GuardDutyManaged` - `true` und starten Sie die Aufgabe dann erneut.
	Dienste, die bereitgestellt wurden, als Cluster noch ein Ausschluss-Tag hatten, sind von Runtime Monitoring ausgeschlossen. Name (n) der betroffenen Dienste: '' `SERVICE_NAME`	Wenn Dienste mit dem Ausschluss-Tag `GuardDutyManaged` - bereitgestellt GuardDuty werden`false`, empfangen sie keine Laufzeitereignisse für diesen ECS Amazon-Cluster. Aktualisieren Sie das Tag auf `GuardDutyManaged` - `true` und stellen Sie den Service dann erneut bereit.
	Aufgaben, die vor der Aktivierung der automatischen Agentenkonfiguration gestartet wurden, werden nicht behandelt. ID (s) der betroffenen Aufgabe: '' `TASK_ID`	Wenn der Cluster eine Aufgabe enthält, die vor der Aktivierung der automatisierten Agentenkonfiguration für Amazon gestartet wurdeECS, kann diese Aufgabe nicht geschützt werden. GuardDuty Starten Sie die Aufgabe erneut, damit sie überwacht werden GuardDuty kann.
	Dienste, die vor der Aktivierung der automatischen Agentenkonfiguration bereitgestellt wurden, sind nicht abgedeckt. Name (n) der betroffenen Dienste: '' `SERVICE_NAME`	Wenn Dienste bereitgestellt werden, bevor die automatische Agentenkonfiguration für Amazon aktiviert wurdeECS, GuardDuty werden keine Laufzeitereignisse für ECS Cluster empfangen.
	Für den Service `SERVICE_NAME` '' ist eine neue Bereitstellung zur Reparatur/Fehlerbehebung erforderlich. Weitere Informationen finden Sie in der Dokumentation, Name (n) der betroffenen Dienste: '' `SERVICE_NAME`	Ein Dienst, der vor der Aktivierung von Runtime Monitoring gestartet wurde, wird nicht unterstützt. Sie können den Service entweder neu starten oder den Service mit der `forceNewDeployment` Option aktualisieren, indem Sie die Schritte unter Aktualisieren eines ECS Amazon-Service mithilfe der Konsole im Amazon Elastic Container Service Developer Guide befolgen. Alternativ können Sie auch die Schritte unter UpdateServiceAmazon Elastic Container Service API Reference verwenden.
	Aufgaben, die vor der Aktivierung von Runtime Monitoring gestartet wurden, erfordern einen Relaunch. ID (s) der betroffenen Aufgabe: '' `TASK_ID_1`	In Amazon sind ECS die Aufgaben unveränderlich. Um das Laufzeitverhalten oder eine laufende AWS Fargate Aufgabe zu beurteilen, stellen Sie sicher, dass Runtime Monitoring bereits aktiviert ist, und starten Sie dann die Aufgabe neu, GuardDuty um den Container-Sidecar hinzuzufügen.
Weitere	Unbekanntes Problem, für Aufgaben in `TaskDefinition - 'TASK_DEFINITION'`	Ermitteln Sie anhand der folgenden Fragen die Ursache des Problems: Wurde die Aufgabe gestartet, bevor Sie Runtime Monitoring aktiviert haben? In Amazon sind ECS die Aufgaben unveränderlich. Um das Laufzeitverhalten einer laufenden Fargate-Aufgabe zu beurteilen, stellen Sie sicher, dass Runtime Monitoring bereits aktiviert ist, und starten Sie dann die Aufgabe neu, GuardDuty um den Container-Sidecar hinzuzufügen. Ist diese Aufgabe Teil einer Servicebereitstellung, die gestartet wurde, bevor Sie Runtime Monitoring aktiviert haben? Falls ja, können Sie den Dienst entweder neu starten oder den Dienst mit aktualisieren, `forceNewDeployment` indem Sie die Schritte unter Dienst aktualisieren ausführen. Sie können auch UpdateServiceoder verwenden AWS CLI. Wurde die Aufgabe gestartet, nachdem der ECS Cluster von Runtime Monitoring ausgeschlossen wurde? Wenn Sie das vordefinierte GuardDuty Tag von `GuardDutyManaged` - in - `true` ändern`false`, GuardDuty werden die Runtime-Ereignisse für den ECS Cluster nicht empfangen. `GuardDutyManaged` Enthält Ihr Service eine Aufgabe, die das alte Format von `taskArn` hat? GuardDuty Runtime Monitoring unterstützt die Abdeckung von Aufgaben nicht, die das alte Format von haben`taskArn`. Informationen zu Amazon Resource Names (ARNs) für ECS Amazon-Ressourcen finden Sie unter Amazon Resource Names (ARNs) und IDs.

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Deckung und Problembehebung für EC2 Amazon-Ressourcen

Abdeckung und Problembehebung für EKS Amazon-Cluster