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. # Einrichtung der Bearer-Token-Authentifizierung für Metrics **Anmerkung** Diese Seite behandelt die Bearer-Token-Authentifizierung für den CloudWatch Metrics OTLP-Endpunkt. *Informationen zur Authentifizierung mit CloudWatch Log-Träger-Tokens finden Sie unter [Einrichten der Bearer-Token-Authentifizierung für Logs im CloudWatch Logs-Benutzerhandbuch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL_HTTP_Endpoints_BearerTokenAuth.html).* Bevor Sie Metriken mithilfe der Bearer-Token-Authentifizierung mit dem CloudWatch OTLP-Endpunkt senden können, müssen Sie: + Erstellen Sie einen IAM-Benutzer mit Metrics-Berechtigungen CloudWatch + Generieren Sie dienstspezifische Anmeldeinformationen (API-Schlüssel) **Wichtig** Wir empfehlen, für alle Workloads, bei denen dies möglich ist, die SigV4-Authentifizierung mit kurzfristigen Anmeldeinformationen zu verwenden. SigV4 bietet die stärkste Sicherheitslage. Beschränken Sie die Verwendung von API-Schlüsseln (Bearer-Token) auf Szenarien, in denen eine kurzfristige Authentifizierung auf der Grundlage von Anmeldeinformationen nicht möglich ist, z. B. das Senden von Metriken aus AWS Umgebungen, von Drittanbietern oder Plattformen, die das SDK nicht unterstützen. AWS Wenn Sie bereit sind, CloudWatch Metriken in Anwendungen mit höheren Sicherheitsanforderungen zu integrieren, wechseln Sie zu kurzfristigen Anmeldeinformationen. Weitere Informationen finden Sie im *IAM-Benutzerhandbuch* unter [Alternativen zu langfristigen Zugriffsschlüsseln](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-workloads-use-roles). **Wichtig** Der CloudWatch OTLP-Endpunkt erfordert TLS (HTTPS). Bearer-Token-Anfragen, die über einfaches HTTP gesendet werden, werden zurückgewiesen. Verwenden Sie diese Option immer`https://monitoring.{{AWS Region}}.amazonaws.com/v1/metrics`, wenn Sie Ihren Client konfigurieren. ## Option 1: Schnellstart mit dem AWS Konsole Die AWS Management Console bietet einen optimierten Arbeitsablauf zur Generierung von API-Schlüsseln für den OTLP-Endpunktzugriff. **So richten Sie den OTLP-Endpunktzugriff mithilfe der Konsole ein** 1. Melden Sie sich bei der AWS Management Console an. 1. Navigieren Sie zu **CloudWatch**> **Einstellungen** > **Global**. 1. Wählen Sie im Abschnitt API-Schlüssel die Option **API-Schlüssel generieren** aus. 1. Für den **Ablauf des API-Schlüssels** haben Sie folgende Möglichkeiten: + Wählen Sie eine Ablaufdauer für den API-Schlüssel von **1**, **5**, **30**, **90** oder **365** Tagen aus. + Wählen Sie **Benutzerdefinierte Dauer** aus, um ein benutzerdefiniertes Ablaufdatum für den API-Schlüssel festzulegen. + Wählen Sie **Nie abläuft** aus (nicht empfohlen). 1. Wählen Sie **API-Schlüssel generieren** aus. Die Konsole automatisch: + Erstellt einen neuen IAM-Benutzer mit den entsprechenden Berechtigungen + Hängt die [CloudWatchAPIKeyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchAPIKeyAccess.html)verwaltete Richtlinie an (einschließlich `cloudwatch:PutMetricData` und `cloudwatch:CallWithBearerToken` Berechtigungen) + Generiert dienstspezifische Anmeldeinformationen (API-Schlüssel) **Um Ihren API-Schlüssel zu speichern und zu verifizieren** 1. Kopieren Sie die angezeigten Anmeldeinformationen und speichern Sie sie sicher: + **API-Schlüssel-ID** (Service-specificAnmeldeinformations-ID) + **Geheimer API-Schlüssel** (Inhaber-Token) Die Konsole bietet auch die Möglichkeit, Ihren API-Schlüssel während der Generierung direkt im [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) zu speichern. Wenn Sie sich für die Speicherung im Secrets Manager entscheiden, wird der Schlüssel beim Zurücksetzen automatisch aktualisiert und beim Löschen des Schlüssels gelöscht. **Wichtig** Speichern Sie das API-Schlüsselgeheimnis sofort. Sie können es später nicht mehr abrufen. Wenn Sie ihn verlieren, müssen Sie einen neuen API-Schlüssel generieren. 1. Senden Sie eine Testmetrik, um Ihr Setup zu überprüfen: ``` curl -X POST "https://monitoring.us-east-1.amazonaws.com/v1/metrics" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer {{YOUR_API_KEY}}" \ -d '{"resourceMetrics":[]}' ``` ## Option 2: Manuelle Einrichtung Wenn Sie mehr Kontrolle über die IAM-Konfiguration bevorzugen oder die Berechtigungen anpassen müssen, können Sie den OTLP-Endpunktzugriff manuell einrichten. ### Schritt 1: Erstellen Sie einen IAM-Benutzer Erstellen Sie einen IAM-Benutzer für die Erfassung von Metriken: **So erstellen Sie einen IAM-Benutzer für die Erfassung von Metriken** 1. Melden Sie sich bei der AWS Management Console an und navigieren Sie zu IAM. 1. Wählen Sie im linken Navigationsbereich **Benutzer** aus. 1. Wählen Sie **Create user** (Benutzer erstellen) aus. 1. Geben Sie einen Benutzernamen ein (z. B.**cloudwatch-metrics-api-key-user**). 1. Wählen Sie **Weiter** aus. 1. Hängen Sie eine der folgenden IAM-Richtlinien an: **Option A: Verwenden Sie die verwaltete Richtlinie (empfohlen)** Hängen Sie die [CloudWatchAPIKeyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchAPIKeyAccess.html)verwaltete Richtlinie an. **Option B: Erstellen Sie eine benutzerdefinierte Richtlinie** Erstellen Sie die folgende IAM-Richtlinie und fügen Sie sie an: ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "CloudWatchMetricsAPIs", "Effect": "Allow", "Action": [ "cloudwatch:CallWithBearerToken", "cloudwatch:PutMetricData" ], "Resource": "*" }, { "Sid": "KMSDecryptForCMKDatasets", "Effect": "Allow", "Action": [ "kms:Decrypt" ], "Condition": { "StringLike": { "kms:ViaService": "cloudwatch.*.amazonaws.com", "kms:EncryptionContext:aws:cloudwatch:arn": "arn:aws:cloudwatch:*:*:dataset/*" } }, "Resource": "arn:aws:kms:*:*:key/*" } ] } ``` 1. Wählen Sie **Weiter** und dann **Benutzer erstellen** aus. **Anmerkung** Die KMS-Berechtigungen sind erforderlich, wenn Sie Metriken an Datensätze senden möchten, die vom Kunden verwaltete KMS-Schlüssel (CMK) verwenden. Die Bedingungen beschränken den KMS-Zugriff nur auf Schlüssel, die über den CloudWatch Dienst für Datensatzressourcen verwendet werden. ### Schritt 2: Generieren Sie dienstspezifische Anmeldeinformationen (API-Schlüssel) Generieren Sie den CloudWatch Metrics-API-Schlüssel mithilfe der [CreateServiceSpecificCredential](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceSpecificCredential.html)API. Sie können auch den Befehl [create-service-specific-credential](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/create-service-specific-credential.html) AWS CLI verwenden. Für das Alter der Anmeldeinformationen können Sie einen Wert zwischen 1—36600 Tagen angeben. Wenn Sie kein Alter für die Anmeldeinformationen angeben, läuft der API-Schlüssel nicht ab. Um einen API-Schlüssel mit einem Ablauf von 30 Tagen zu generieren: ``` aws iam create-service-specific-credential \ --user-name cloudwatch-metrics-api-key-user \ --service-name cloudwatch.amazonaws.com \ --credential-age-days 30 ``` Die Antwort ist ein [ServiceSpecificCredential](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ServiceSpecificCredential.html)Objekt. Der `ServiceCredentialSecret` Wert ist Ihr CloudWatch Metrics-API-Schlüssel (Bearer-Token). **Wichtig** Speichern Sie den `ServiceCredentialSecret` Wert sicher. Sie können ihn später nicht mehr abrufen. Wenn Sie ihn verlieren, müssen Sie einen neuen API-Schlüssel generieren. ### Schritt 3: Metriken senden Mit Ihrem Bearer-Token können Sie sofort Metriken an den OTLP-Endpunkt senden: ``` curl -X POST "https://monitoring.us-east-1.amazonaws.com/v1/metrics" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer {{YOUR_API_KEY}}" \ -d '{"resourceMetrics":[]}' ``` Der Endpunkt akzeptiert sowohl Inhaltstypen als auch `application/json` `application/x-protobuf` Inhaltstypen. ## Steuern Sie die Berechtigungen für die Generierung und Verwendung von CloudWatch Metrics-API-Schlüsseln ### Steuerung der Generierung von CloudWatch Metrics-API-Schlüsseln Die [https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsidentityandaccessmanagementiam.html#awsidentityandaccessmanagementiam-actions-as-permissions](https://docs.aws.amazon.com/service-authorization/latest/reference/list_awsidentityandaccessmanagementiam.html#awsidentityandaccessmanagementiam-actions-as-permissions)Aktion steuert die Generierung eines dienstspezifischen Schlüssels (z. B. eines CloudWatch Metrics-API-Schlüssels). Sie können diese Aktion auf IAM-Benutzer als Ressource beschränken, um die Anzahl der Benutzer einzuschränken, für die ein Schlüssel generiert werden kann. Mit den folgenden Bedingungsschlüsseln können Sie Bedingungen mit der Berechtigung für die Aktion `iam:CreateServiceSpecificCredential` verknüpfen: + [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#ck_ServiceSpecificCredentialAgeDays](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#ck_ServiceSpecificCredentialAgeDays)— Ermöglicht es Ihnen, in der Bedingung die Ablaufzeit des Schlüssels in Tagen anzugeben. + [https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#ck_ServiceSpecificCredentialServiceName](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#ck_ServiceSpecificCredentialServiceName)— Ermöglicht es Ihnen, in der Bedingung den Namen eines Dienstes anzugeben. ### Steuerung der Verwendung von CloudWatch Metrics-API-Schlüsseln Die `cloudwatch:CallWithBearerToken` Aktion steuert die Verwendung eines CloudWatch Metrics-API-Schlüssels. Um zu verhindern, dass eine Identität CloudWatch Metrics-API-Schlüssel verwendet, fügen Sie eine Richtlinie hinzu, die dem IAM-Benutzer, der mit dem Schlüssel verknüpft ist, die `cloudwatch:CallWithBearerToken` Aktion verweigert. **Anmerkung** Trägertoken für CloudWatch Metriken können nur mit dem Endpunkt für die Erfassung von OTLP-Metriken () verwendet werden. `https://monitoring.{{AWS Region}}.amazonaws.com/v1/metrics` Sie können nicht verwendet werden, um andere CloudWatch APIs oder Endpunkte aufzurufen, einschließlich Abfrage-APIs (,,`DescribeAlarms`)`GetMetricData`, `ListMetrics` des PromQL-Abfrageendpunkts, des OTLP-Traces-Endpunkts oder des OTLP-Log-Endpunkts. ### Beispielrichtlinien **Verhindern Sie, dass eine Identität Metrik-API-Schlüssel generiert und verwendet CloudWatch:** ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyCWMetricsAPIKeys", "Effect": "Deny", "Action": [ "iam:CreateServiceSpecificCredential", "cloudwatch:CallWithBearerToken" ], "Resource": "*" } ] } ``` **Warnung** Diese Richtlinie verhindert die Erstellung von Anmeldeinformationen für alle AWS Dienste, die die Erstellung dienstspezifischer Anmeldeinformationen unterstützen. Weitere Informationen finden Sie unter [Service-specificAnmeldeinformationen für IAM-Benutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_service-specific-creds.html) im *IAM-Benutzerhandbuch*. **Verhindern Sie, dass eine Identität CloudWatch Metrics-API-Schlüssel verwendet:** ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "cloudwatch:CallWithBearerToken", "Resource": "*" } ] } ``` **Erlaube die Erstellung von CloudWatch Metrics-Schlüsseln nur, wenn sie innerhalb von 90 Tagen ablaufen:** ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iam:CreateServiceSpecificCredential", "Resource": "arn:aws:iam::123456789012:user/{{username}}", "Condition": { "StringEquals": { "iam:ServiceSpecificCredentialServiceName": "cloudwatch.amazonaws.com" }, "NumericLessThanEquals": { "iam:ServiceSpecificCredentialAgeDays": "90" } } } ] } ``` ## Verwendung von Inhaber-Tokens mit dem Collector OpenTelemetry Wenn Sie Inhaber-Token verwenden, benötigen Sie die `sigv4auth` Erweiterung nicht. Verwenden Sie die Erweiterung [bearertokenauth](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/extension/bearertokenauthextension), um Ihren API-Schlüssel sicher aus einer Datei oder Umgebungsvariablen bereitzustellen: ``` extensions: bearertokenauth: filename: "/etc/otel/cw-api-key" exporters: otlphttp: tls: insecure: false endpoint: https://monitoring.us-east-1.amazonaws.com/v1/metrics auth: authenticator: bearertokenauth receivers: otlp: protocols: http: endpoint: 0.0.0.0:4318 processors: batch: send_batch_size: 200 timeout: 10s service: extensions: [bearertokenauth] pipelines: metrics: receivers: [otlp] processors: [batch] exporters: [otlphttp] ``` Alternativ können Sie statt einer Datei auf eine Umgebungsvariable verweisen: ``` extensions: bearertokenauth: token: "${env:CW_API_KEY}" ``` **Wichtig** Kodieren Sie API-Schlüssel niemals direkt in den Collector-Konfigurationsdateien fest. Konfigurationsdateien werden häufig der Versionskontrolle übergeben oder in Bereitstellungsmanifesten gespeichert. Wird verwendet`filename`, um aus einem bereitgestellten geheimen Schlüssel oder aus einer Umgebungsvariablen `${env:VAR}` zu lesen, die von Ihrem Secrets-Manager eingegeben wurde. **Anmerkung** Bei der Bearer-Token-Authentifizierung benötigen Sie weder die `sigv4auth` Erweiterung noch die AWS Anmeldeinformationsdateien, die IAM-Rollen oder die IRSA-Konfiguration. Dadurch ist die Collector-Konfiguration in jeder Umgebung portabel — ob AWS lokal oder bei anderen Cloud-Anbietern. ## Rotierende API-Schlüssel Durch die regelmäßige Rotation Ihrer API-Schlüssel wird das Risiko eines unbefugten Zugriffs verringert. Wir empfehlen, einen Rotationsplan aufzustellen, der den Sicherheitsrichtlinien Ihres Unternehmens entspricht. ### Ablauf der Rotation Gehen Sie wie folgt vor, um einen API-Schlüssel zu rotieren, ohne die Bereitstellung von Metriken zu unterbrechen: **Um einen API-Schlüssel zu rotieren** 1. Erstellen Sie einen neuen (sekundären) Berechtigungsnachweis für den IAM-Benutzer: ``` aws iam create-service-specific-credential \ --user-name cloudwatch-metrics-api-key-user \ --service-name cloudwatch.amazonaws.com \ --credential-age-days 90 ``` **Anmerkung** IAM erlaubt maximal 2 dienstspezifische Anmeldeinformationen pro IAM-Benutzer pro Dienst. Löschen oder deaktivieren Sie alte Anmeldeinformationen, bevor Sie neue erstellen, wenn Sie dieses Limit erreicht haben. 1. (Optional) Speichern Sie die neuen Anmeldeinformationen in AWS Secrets Manager für einen sicheren Abruf und eine automatische Rotation. 1. Aktualisieren Sie Ihre OpenTelemetry Collector-Konfiguration oder -Anwendung, um den neuen API-Schlüssel zu verwenden. 1. Setzen Sie die ursprünglichen Anmeldeinformationen auf inaktiv: ``` aws iam update-service-specific-credential \ --user-name cloudwatch-metrics-api-key-user \ --service-specific-credential-id {{ACCA1234EXAMPLE1234}} \ --status Inactive ``` 1. Stellen Sie sicher, dass die Bereitstellung von Metriken nicht beeinträchtigt wird. Senden Sie eine Testanfrage mit dem neuen Schlüssel und bestätigen Sie, dass Sie eine HTTP 200-Antwort erhalten. Sie können auch die vorhandenen CloudWatch Messwerte Ihrer Anwendung überwachen, um sicherzustellen, dass weiterhin Daten eintreffen. 1. Nachdem Sie die erfolgreiche Bereitstellung mit dem neuen Schlüssel bestätigt haben, löschen Sie die vorherigen Anmeldeinformationen: ``` aws iam delete-service-specific-credential \ --service-specific-credential-id {{ACCA1234EXAMPLE1234}} ``` ### Ablauf des Schlüssels überwachen Verwenden Sie den Befehl [list-service-specific-credentials](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/iam/list-service-specific-credentials.html), um das Erstellungsdatum und den Status Ihrer vorhandenen API-Schlüssel zu überprüfen: ``` aws iam list-service-specific-credentials \ --user-name cloudwatch-metrics-api-key-user \ --service-name cloudwatch.amazonaws.com ``` Die Antwort beinhaltet `CreateDate` und für jeden Berechtigungsnachweis. `Status` Verwenden Sie diese Informationen, um Schlüssel zu identifizieren, die bald ablaufen oder die schon länger aktiv sind, als es Ihre Rotationsrichtlinie zulässt. ## Reaktion auf einen kompromittierten API-Schlüssel Wenn Sie vermuten, dass ein API-Schlüssel kompromittiert wurde, führen Sie sofort die folgenden Schritte durch: **Um auf einen kompromittierten API-Schlüssel zu reagieren** 1. **Deaktivieren Sie den Schlüssel sofort**, um eine weitere unbefugte Verwendung zu verhindern: ``` aws iam update-service-specific-credential \ --user-name cloudwatch-metrics-api-key-user \ --service-specific-credential-id {{ACCA1234EXAMPLE1234}} \ --status Inactive ``` 1. **Überprüfen Sie die CloudTrail Protokolle**, um den Umfang des unbefugten Zugriffs zu ermitteln. Weitere Informationen [Protokollierung der Verwendung von API-Schlüsseln mit CloudTrail](#CloudWatch-OTLP-MetricsBearerTokenAuth-CloudTrail) zur Aktivierung der Überwachung der API-Schlüsselnutzung finden Sie unter. 1. **Erstellen Sie nach dem unter beschriebenen Rotationsprozess einen Ersatzschlüssel**[Ablauf der Rotation](#CloudWatch-OTLP-MetricsBearerTokenAuth-Rotation-Process). 1. **Löschen Sie den kompromittierten Schlüssel**, nachdem der Ersatzschlüssel installiert wurde: ``` aws iam delete-service-specific-credential \ --service-specific-credential-id {{ACCA1234EXAMPLE1234}} ``` 1. **Fügen Sie eine Ablehnungsrichtlinie** hinzu, wenn Sie sofort den gesamten Zugriff auf Inhaber-Tokens für den IAM-Benutzer sperren müssen, während Sie die folgenden Untersuchungen durchführen: ``` { "Version": "2012-10-17", "Statement": { "Effect": "Deny", "Action": "cloudwatch:CallWithBearerToken", "Resource": "*" } } ``` **Anmerkung** Um diese Aktionen über die API auszuführen, müssen Sie sich mit AWS Anmeldeinformationen und nicht mit einem CloudWatch Metrics-API-Schlüssel authentifizieren. Bearer-Token können nur für die Erfassung von Metriken verwendet werden, nicht für IAM-Verwaltungsvorgänge. Sie können auch die folgenden IAM-API-Operationen verwenden, um kompromittierte Schlüssel zu verwalten: + [ResetServiceSpecificCredential](https://docs.aws.amazon.com/IAM/latest/APIReference/API_ResetServiceSpecificCredential.html)— Setzen Sie den Schlüssel zurück, um ein neues Passwort zu generieren, ohne die Anmeldeinformationen zu löschen. Der Schlüssel darf nicht abgelaufen sein. ## Bewährte Sicherheitsmethoden für API-Schlüssel Folgen Sie diesen bewährten Methoden, um Ihre CloudWatch Metrics-API-Schlüssel zu schützen: + **Betten Sie niemals API-Schlüssel in den Quellcode ein.** Codieren Sie API-Schlüssel nicht fest in Anwendungscode, Collector-Konfigurationsdateien oder Versionskontrollsystemen. Verwenden Sie die `bearertokenauth` Erweiterung zusammen mit `filename` oder`${env:VAR}`, um Geheimnisse zur Laufzeit einzufügen. + **Verwenden Sie einen Secrets-Manager.** Speichern Sie API-Schlüssel in [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) oder einer gleichwertigen Secrets-Management-Lösung. Dies ermöglicht eine zentrale Zugriffskontrolle, Auditprotokollierung und automatisierte Rotation. + **Legen Sie für alle Schlüssel ein Ablaufdatum fest.** Geben Sie bei der Erstellung von API-Schlüsseln immer einen `--credential-age-days` Wert an. Verwenden Sie den `iam:ServiceSpecificCredentialAgeDays` IAM-Bedingungsschlüssel, um eine maximale Gültigkeitsdauer von Schlüsseln in Ihrer Organisation durchzusetzen. + **Wenden Sie Berechtigungen mit den geringsten Rechten an.** Verwenden Sie die verwaltete [CloudWatchAPIKeyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/CloudWatchAPIKeyAccess.html)Richtlinie als Ausgangspunkt und schränken Sie sie bei Bedarf weiter ein. + **Aktivieren Sie die CloudTrail Protokollierung.** Überwachen Sie die Verwendung von API-Schlüsseln, indem Sie CloudTrail Datenereignisse für aktivieren`AWS::CloudWatch::Metric`. Siehe [Protokollierung der Verwendung von API-Schlüsseln mit CloudTrail](#CloudWatch-OTLP-MetricsBearerTokenAuth-CloudTrail). + **Überwachen Sie mit IAM Access Analyzer.** Verwenden Sie [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html), um ungenutzte Anmeldeinformationen und übermäßig freizügige Richtlinien im Zusammenhang mit Ihren API-Schlüssel-IAM-Benutzern zu identifizieren. + **Wechseln Sie die Schlüssel regelmäßig.** Legen Sie einen Rotationsplan fest und folgen Sie dem unter beschriebenen Verfahren[Rotierende API-Schlüssel](#CloudWatch-OTLP-MetricsBearerTokenAuth-Rotation). ## Protokollierung der Verwendung von API-Schlüsseln mit CloudTrail Sie können es verwenden AWS CloudTrail , um Datenereignisse für die OTLP-Erfassung von CloudWatch Metrics zu protokollieren. CloudWatch sendet `AWS::CloudWatch::Metric` Datenereignisse für Aufrufe an den OTLP-Endpunkt aus, sodass Sie die Aktivitäten zur Erfassung von Metriken, einschließlich der Verwendung von API-Schlüsseln, überprüfen können. **Anmerkung** Der S3-Bucket, den Sie für den Trail angeben, muss über eine Bucket-Richtlinie verfügen, die das Schreiben von CloudTrail Protokolldateien in ihn ermöglicht. Weitere Informationen finden Sie unter [Amazon S3 S3-Bucket-Richtlinie für CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/create-s3-bucket-policy-for-cloudtrail.html) im *AWS CloudTrail Benutzerhandbuch*. **Um die CloudTrail Protokollierung für die Verwendung von CloudWatch Metrics API-Schlüsseln zu aktivieren** 1. Erstellen Sie einen Trail: ``` aws cloudtrail create-trail \ --name cloudwatch-metrics-api-key-audit \ --s3-bucket-name {{my-cloudtrail-bucket}} \ --region us-east-1 ``` 1. Konfigurieren Sie erweiterte Event-Selektoren zur Erfassung von CloudWatch Metrik-Schreib- (Ingestions-) Datenereignissen: ``` aws cloudtrail put-event-selectors \ --region us-east-1 \ --trail-name cloudwatch-metrics-api-key-audit \ --advanced-event-selectors '[{ "Name": "CloudWatch Metrics write data events", "FieldSelectors": [ { "Field": "eventCategory", "Equals": ["Data"] }, { "Field": "resources.type", "Equals": ["AWS::CloudWatch::Metric"] }, { "Field": "readOnly", "Equals": ["false"] } ] }]' ``` 1. Starten Sie die Trail-Protokollierung: ``` aws cloudtrail start-logging \ --name cloudwatch-metrics-api-key-audit \ --region us-east-1 ``` Der `readOnly: false` Filter beschränkt die Protokollierung auf Schreiboperationen (PutMetricData), was alle OTLP-Aufnahmerufe einschließt. Um die Verwendung von Inhaber-Tokens unter diesen Ereignissen zu identifizieren, fragen Sie Ihre Trail-Logs ab (über Athena oder CloudTrail Lake) und filtern Sie nach dem IAM-Benutzernamen, der mit Ihrem API-Schlüssel verknüpft ist (z. B.). `cloudwatch-metrics-api-key-user` Ereignisse aus der OTLP-Erfassung sind `OTLP` in der Event-Payload auf `AdditionalEventData.protocol` festgelegt, was Sie in Post-hoc-Abfragen verwenden können, um sie von klassischen SDK-Aufrufen zu unterscheiden. PutMetricData