Cloud-Audit-Logs mit Cloud Storage

Auf dieser Seite erhalten Sie zusätzliche Informationen zur Verwendung von Cloud-Audit-Logging in Verbindung mit Cloud Storage. Mit Cloud-Audit-Logs können Sie Logs für API-Vorgänge generieren, die in Cloud Storage ausgeführt werden.

Hinweis: Cloud-Audit-Logs unterscheiden sich von Nutzungslogs für Cloud Storage. Mit beiden Funktionen können Sie den Zugriff auf Ihre Cloud Storage-Ressourcen steuern. Cloud-Audit-Logging ist jedoch die empfohlene Methode.

Übersicht

Google Cloud-Dienste schreiben Audit-Logs, aus denen in Bezug auf Ihre Google Cloud-Ressourcen hervorgeht, wer was wo und wann getan hat. Sie können Audit-Logs auch benutzerdefinierte Informationen hinzufügen, um detailliertere Informationen darüber zu erhalten, wie auf Ihre Ressourcen zugegriffen wird.

Ihre Google Cloud-Projekte enthalten nur die Audit-Logs für Ressourcen, die sich direkt im Google Cloud-Projekt befinden. Andere Google Cloud-Ressourcen wie Ordner, Organisationen und Rechnungskonten enthalten jeweils eigene Audit-Logs.

Eine allgemeine Übersicht über Cloud-Audit-Logs finden Sie unter Cloud-Audit-Logs. Detaillierte Informationen zum Format von Audit-Logs finden Sie unter Audit-Logs verstehen.

Verfügbare Audit-Logs

Für Cloud Storage sind die folgenden Arten von Audit-Logs verfügbar:

• Audit-Logs für Administratoraktivitäten: Einträge für Vorgänge, die den Zugriff auf Cloud Storage-Ressourcen ändern, sowie Einträge für Vorgänge zum Erstellen, Löschen oder Ändern von Buckets, verwalteten Ordnern oder Inventarberichten }Konfigurationen haben. Sie können Audit-Logs zu Administratoraktivitäten nicht deaktivieren.

• Audit-Logs zum Datenzugriff: Protokollieren Vorgänge, die in den Audit-Logs für Administratoraktivitäten nicht erfasst werden. Es gibt mehrere Untertypen von Audit-Logs zum Datenzugriff:

  • ADMIN_READ: Protokolliert Vorgänge, die Zugriffskonfigurationen oder Bucket-Metadaten lesen oder Buckets innerhalb eines Projekts auflisten.

  • DATA_READ: Protokolliert Vorgänge, bei denen andere Cloud Storage-Ressourcen als Buckets gelesen oder aufgelistet wurden.

  • DATA_WRITE: Protokolliert Vorgänge, bei denen Objekte erstellt, geändert, gelöscht oder wiederhergestellt oder mehrteilige XML API-Uploads erstellt, geändert oder gelöscht wurden.

  Um Audit-Logs zum Datenzugriff zu erhalten, müssen Sie diese explizit aktivieren.

Zusätzlich zu den Audit-Logs für Cloud Storage können von Cloud-Audit-Logs Audit-Logs für Storage Insights erstellt werden. Audit-Logs zu Storage Insights werden immer dann generiert, wenn Konfigurationen für Inventarberichte erstellt, aktualisiert und abgerufen werden und wenn Inventarberichte abgerufen werden.

Ausführlichere Beschreibungen der Audit-Logtypen finden Sie unter Arten von Audit-Logs.

Geprüfte Vorgänge

In folgender Tabelle wird zusammengefasst, welche Cloud Storage-Vorgänge den einzelnen Audit-Logtypen entsprechen:

Audit-Log-Typ	Untertyp	Cloud Storage-Vorgänge
Administratoraktivität	ADMIN_WRITE	IAM-Richtlinien festlegen/ändern Objekt-ACLs ändern^1 Buckets erstellen Buckets löschen Bucket-Metadaten aktualisieren Verwaltete Ordner erstellen Verwaltete Ordner löschen Konfigurationen für Inventarberichte erstellen Konfigurationen von Inventarberichten aktualisieren Konfigurationen von Inventarberichten löschen
Datenzugriff	ADMIN_READ	IAM-Richtlinien abrufen Objekt-ACLs abrufen Bucket-Metadaten abrufen Buckets auflisten
Datenzugriff	DATA_READ	Objektdaten abrufen Objektmetadaten abrufen Objekte auflisten Metadaten des verwalteten Ordners abrufen Verwaltete Ordner auflisten Objekte kopieren^2 Objekte zusammensetzen ^2 Laufende mehrteilige XML API-Uploads auflisten XML-Teilen mehrerer Teile von Uploads Konfigurationen für Inventarberichten abrufen Konfigurationen für Inventarberichte auflisten Inventarberichte abrufen Inventarberichte auflisten
Datenzugriff	DATA_WRITE	Objekte erstellen Objekte löschen Vorläufig gelöschte Objekte wiederherstellen Nicht-ACL-Objektmetadaten aktualisieren Objekte kopieren^1 Objekte zusammensetzen^1 Mehrteilige XML-API-Uploads initiieren Teile in einem mehrteiligen XML API-Upload erstellen Mehrteilige XML API-Uploads abbrechen Mehrteilige XML API-Uploads durchführen

¹ Audit-Logs für Administratoraktivitäten werden nicht generiert, wenn ACLs bereits bei der Objekterstellung festgelegt werden. Wenn eine Objekt-ACL auf "öffentlich" eingestellt ist, werden für Lese- oder Schreibvorgänge in diesem Objekt oder der ACL außerdem keine Audit-Logs erstellt.

² Bei diesen Vorgängen werden Daten gelesen und geschrieben. Daher generieren diese Aktionen jeweils zwei Logeinträge.

Beschränkungen

Die folgenden Einschränkungen gelten für Cloud-Audit-Logging in Verbindung mit Cloud Storage:

• Cloud-Audit-Logging erfasst nicht den Zugriff auf öffentliche Objekte.
• Cloud-Audit-Logging erfasst keine Änderungen, die von den Funktionen Verwaltung des Objektlebenszyklus und Autoclass ausgeführt werden.
• Datenzugriffslogs führen dazu, dass authentifizierte Browser-Downloads fehlschlagen, wenn Sie versuchen, nicht öffentliche Objekte außerhalb der Google Cloud Console herunterzuladen.

Wenn Sie in einem dieser Fälle Logging-Funktionen benötigen, können Sie Cloud Storage-Nutzungslogs verwenden.

Audit-Logformat

Audit-Logeinträge umfassen folgende Komponenten:

• Den Logeintrag selbst, bei dem es sich um ein LogEntry-Objekt handelt. Interessante Felder sind unter anderem:

  • logName enthält die Ressourcen-ID und den Audit-Logtyp.
  • resource enthält das Ziel zum geprüften Vorgang
  • timestamp enthält die Uhrzeit des geprüften Vorgangs
  • protoPayload enthält die geprüften Informationen

• Die Audit-Logdaten, bei denen es sich um ein AuditLog-Objekt handelt, das sich im Feld protoPayload des Logeintrags befindet

• Optionale Cloud Storage-spezifische Audit-Informationen, einschließlich detaillierter Anfrage- und Antwortinformationen. Weitere Informationen finden Sie unter Detaillierter Audit-Logging-Modus. Sie müssen kein detailliertes Audit-Logging erzwingen, um benutzerdefinierte Informationen an Audit-Logs anzuhängen.

Informationen zu anderen Feldern in diesen Objekten sowie zu deren Interpretation finden Sie unter Audit-Logs verstehen.

Logname

Lognamen von Cloud-Audit-Logs enthalten Ressourcenkennungen, die das Google Cloud-Projekt oder eine andere Google Cloud-Entität angeben, die Inhaber der Audit-Logs ist. Außerdem wird angegeben, ob das Log Audit-Logging-Daten zur Administratoraktivität oder zum Datenzugriff enthält.

Im Folgenden finden Sie die Namen der Audit-Logs, einschließlich Variablen für die Ressourcenkennungen:

   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity
   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access

   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Factivity
   folders/FOLDER_ID/logs/cloudaudit.googleapis.com%2Fdata_access

   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Factivity
   billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com%2Fdata_access

   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity
   organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access

Hinweis: Der Teil des Lognamens nach /logs/ muss URL-codiert sein. Der Schrägstrich / muss als %2F geschrieben werden.

Dienstname

Für Audit-Logs von Cloud Storage wird der Dienstname storage.googleapis.com verwendet.

Für Audit-Logs von Storage Insights wird der Dienstname storageinsights.googleapis.com verwendet.

Eine vollständige Liste aller Cloud Logging API-Dienstnamen und des jeweiligen überwachten Ressourcentyps finden Sie unter Dienste Ressourcen zuordnen.

Ressourcentypen

Für Audit-Logs von Cloud Storage wird der Ressourcentyp gcs_bucket verwendet.

Eine Liste aller überwachten Cloud Logging-Ressourcentypen und beschreibende Informationen finden Sie unter Überwachte Ressourcentypen.

Audit-Logging aktivieren

Audit-Logs zu Administratoraktivitäten sind immer aktiviert. Sie können sie nicht deaktivieren.

Audit-Logs zum Datenzugriff sind standardmäßig deaktiviert und werden nur geschrieben, wenn explizit aktiviert.

Informationen zum Aktivieren einiger oder aller Audit-Logs zum Datenzugriff finden Sie unter Audit-Logs zum Datenzugriff konfigurieren.

Berechtigungen und Rollen

IAM bestimmen Ihre Fähigkeit, auf Audit-Logdaten in Google Cloud-Ressourcen zuzugreifen.

Berücksichtigen Sie Folgendes bei der Entscheidung, welche Logging-spezifischen Berechtigungen und Rollen für Ihren Anwendungsfall gelten:

• Die Rolle „Log-Betrachter“ (roles/logging.viewer) bietet Ihnen Lesezugriff auf die Audit-Logs zu Administratoraktivitäten, abgelehnten Richtlinien und Systemereignissen. Wenn Sie nur diese Rolle haben, können Sie keine Audit-Logs zum Datenzugriff aufrufen, die sich in den Buckets _Required und _Default befinden.

• Die Rolle „Betrachter privater Logs“ ((roles/logging.privateLogViewer) enthält die Berechtigungen, die in roles/logging.viewer enthalten sind, sowie die Möglichkeit, Audit-Logs zum Datenzugriff in den Buckets _Required und _Default zu lesen.

  Wenn diese privaten Logs in benutzerdefinierten Buckets gespeichert sind, kann jeder Nutzer, der Berechtigungen zum Lesen von Logs in diesen Buckets hat, die privaten Logs lesen. Weitere Informationen zu Log-Buckets finden Sie unter Routing und Speicher.

Weitere Informationen zu den IAM-Berechtigungen und -Rollen, die für Audit-Logdaten gelten, finden Sie unter Zugriffssteuerung mit IAM.

Hinweis: Mit Access Control Lists (ACLs) kann Nutzern nicht der Zugriff auf Audit-Logs für Administratoraktivitäten oder für Datenzugriffe gewährt werden.

Logs ansehen

Sie können nach allen Audit-Logs oder nach dem Namen des Audit-Logs abfragen. Der Audit-Logname enthält die Ressourcenkennung des Google Cloud-Projekts, des Ordners, des Rechnungskontos oder der Organisation, für die Sie Audit-Logging-Informationen aufrufen möchten. Für Abfragen können indexierte LogEntry-Felder angegeben werden. Wenn Sie die Seite Log Analytics verwenden, die SQL-Abfragen unterstützt, haben Sie die Möglichkeit, Abfrageergebnisse als Diagramm anzeigen zu lassen.

Weitere Informationen zum Abfragen Ihrer Logs finden Sie auf den folgenden Seiten:

• Abfragen im Log-Explorer erstellen.
• Logs in Log Analytics abfragen und ansehen
• Beispielabfragen für Sicherheitsinformationen.

Sie können Audit-Logs in Cloud Logging mithilfe der Google Cloud Console, der Google Cloud CLI oder der Logging API aufrufen.

Console

In der Google Cloud Console können Sie mit dem Log-Explorer die Audit-Logeinträge für Ihr Google Cloud-Projekt, Ihren Ordner oder Ihre Organisation abrufen:

Hinweis: Sie können keine Audit-Logs für Cloud-Rechnungskonten in der Google Cloud Console aufrufen. Sie müssen die API oder die gcloud CLI verwenden.

1. Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.

   Zum Log-Explorer

   Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Logging ist.

2. Wählen Sie ein vorhandenes Google Cloud-Projekt, einen Ordner oder eine Organisation aus.

3. Wenn Sie alle Audit-Logs aufrufen möchten, geben Sie eine der folgenden Abfragen in das Feld des Abfrageeditors ein und klicken dann auf Abfrage ausführen:

   logName:"cloudaudit.googleapis.com"
   

   protoPayload."@type"="type.googleapis.com/google.cloud.audit.AuditLog"
   

4. So rufen Sie im Bereich Query Builder die Audit-Logs für eine bestimmte Ressource und einen bestimmten Audit-Logtyp auf:

   • Wählen Sie unter Ressourcentyp die Google Cloud-Ressource aus, deren Audit-Logs angezeigt werden sollen.

   • Wählen Sie unter Logname den Audit-Logtyp aus, den Sie sehen möchten:

     • Wählen Sie für Audit-Logs zu Administratoraktivitäten die Option activity aus.
     • Wählen Sie für Audit-Logs zum Datenzugriff die Option data_access aus.
     • Wählen Sie für Audit-Logs zu Systemereignissen die Option system_event aus.
     • Wählen Sie für Audit-Logs zu Richtlinienverstößen die Option policy aus.

   • Klicken Sie auf Abfrage ausführen.

   Wenn diese Optionen nicht angezeigt werden, sind im Google Cloud-Projekt, im Ordner oder in der Organisation keine Audit-Logs dieses Typs verfügbar.

   Wenn beim Aufrufen von Logs im Log-Explorer Probleme auftreten, lesen Sie die Informationen zur Fehlerbehebung.

   Weitere Informationen zu Abfragen mit dem Log-Explorer finden Sie unter Abfragen im Log-Explorer erstellen. Informationen zum Zusammenfassen von Logeinträgen im Log-Explorer mithilfe von Gemini finden Sie unter Logeinträge mit Gemini-Unterstützung zusammenfassen.

gcloud

Die Google Cloud CLI bietet eine Befehlszeile für die Logging API. Geben Sie in jedem Lognamen eine gültige Ressourcenkennung an. Wenn die Abfrage beispielsweise eine PROJECT_ID enthält, muss sich die von Ihnen angegebene Projekt-ID auf das aktuell ausgewählte Google Cloud-Projekt beziehen.

Führen Sie den folgenden Befehl aus, um Ihre Audit-Logeinträge auf Google Cloud-Projektebene zu lesen:

gcloud logging read "logName : projects/PROJECT_ID/logs/cloudaudit.googleapis.com" \
    --project=PROJECT_ID

Führen Sie den folgenden Befehl aus, um Ihre Audit-Logeinträge auf Ordnerebene zu lesen:

gcloud logging read "logName : folders/FOLDER_ID/logs/cloudaudit.googleapis.com" \
    --folder=FOLDER_ID

Führen Sie den folgenden Befehl aus, um Ihre Audit-Logeinträge auf Organisationsebene zu lesen:

gcloud logging read "logName : organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com" \
    --organization=ORGANIZATION_ID

Führen Sie den folgenden Befehl aus, um Ihre Audit-Logeinträge auf Cloud-Rechnungskontoebene zu lesen:

gcloud logging read "logName : billingAccounts/BILLING_ACCOUNT_ID/logs/cloudaudit.googleapis.com" \
    --billing-account=BILLING_ACCOUNT_ID

Fügen Sie Ihrem Befehl das Flag --freshness hinzu, um Logs zu lesen, die mehr als einen Tag alt sind.

Weitere Informationen zur Verwendung der gcloud CLI erhalten Sie unter gcloud logging read.

API

Geben Sie beim Erstellen von Abfragen in jedem Lognamen eine gültige Ressourcenkennung an. Wenn die Abfrage beispielsweise eine PROJECT_ID enthält, muss sich die von Ihnen angegebene Projekt-ID auf das aktuell ausgewählte Google Cloud-Projekt beziehen.

So können Sie beispielsweise mit der Logging API Ihre Audit-Logeinträge auf Projektebene aufrufen:

1. Rufen Sie den Abschnitt Diese API testen in der Dokumentation für die Methode entries.list auf.

2. Geben Sie im Teil Anfragetext des Formulars Diese API testen Folgendes ein. Wenn Sie auf dieses vorausgefüllte Formular klicken, wird der Anfragetext automatisch übernommen. Sie müssen jedoch in jedem der Lognamen eine gültige PROJECT_ID angeben.

   {
     "resourceNames": [
       "projects/PROJECT_ID"
     ],
     "pageSize": 5,
     "filter": "logName : projects/PROJECT_ID/logs/cloudaudit.googleapis.com"
   }
   

3. Klicken Sie auf Ausführen.

Audit-Logs zu benutzerdefinierten Informationen hinzufügen

Sie können benutzerdefinierte Informationen an Audit-Logs an Anfragen anhängen. Fügen Sie dazu den Header x-goog-custom-audit-KEY: VALUE in Ihre Anfrage ein. XML API-Anfragen unterstützen außerdem die Verwendung eines Abfrageparameters x-goog-custom-audit-KEY=VALUE. Benutzerdefinierte Informationen werden dem Feld metadata von protoPayload im Audit-Logeintrag hinzugefügt.

Beachten Sie beim Hinzufügen von benutzerdefinierten Audit-Informationen die folgenden Hinweise:

• Jeder KEY kann bis zu 64 Zeichen enthalten, jedef VALUE kann bis zu 1.200 Zeichen enthalten.

• Jede Anfrage kann bis zu vier Header- oder Parametereinträge zusammen enthalten.

Beispiele für Header-Einträge

Die folgende Liste enthält Beispiele für Schlüssel/Wert-Paare, die Sie in Header-Einträge aufnehmen können:

• x-goog-custom-audit-job: test-job-id-here
• x-goog-custom-audit-user: user ID test 1
• x-goog-custom-audit-internal-user-id: MATR2022-11
• x-goog-custom-audit-tracking-ticket: TT/1516512851
• x-goog-custom-audit-justification: Removed customer identity record at customer request
• x-goog-custom-audit-customer-id: USCU12315154

Beispielanfragen

Befehlszeile

gcloud storage hash gs://example_bucket/example_object.jpeg --additional-headers=x-goog-custom-audit-job="job name",x-goog-custom-audit-user="test user"

Clientbibliotheken

C++

Informationen zum Hinzufügen benutzerdefinierter Header zu Anfragen finden Sie unter Benutzerdefinierte Header hinzufügen.

C#

Informationen zum Hinzufügen benutzerdefinierter Header zu Anfragen finden Sie unter Benutzerdefinierte Header hinzufügen.

Go

Informationen zum Hinzufügen benutzerdefinierter Header zu Anfragen finden Sie unter Benutzerdefinierte Header hinzufügen.

Java

Informationen zum Hinzufügen benutzerdefinierter Header zu Anfragen finden Sie unter Benutzerdefinierte Header hinzufügen.

Node.js

Informationen zum Hinzufügen benutzerdefinierter Header zu Anfragen finden Sie unter Benutzerdefinierte Header hinzufügen.

PHP

Informationen zum Hinzufügen benutzerdefinierter Header zu Anfragen finden Sie unter Benutzerdefinierte Header hinzufügen.

Python

Informationen zum Hinzufügen benutzerdefinierter Header zu Anfragen finden Sie unter Benutzerdefinierte Header hinzufügen.

Ruby

Informationen zum Hinzufügen benutzerdefinierter Header zu Anfragen finden Sie unter Benutzerdefinierte Header hinzufügen.

REST APIs

JSON API

curl -X GET "https://storage.googleapis.com/storage/v1/b/example_bucket/o/example_object" \
-H "Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg" \
-H "x-goog-custom-audit-job: job name" \
-H "x-goog-custom-audit-user: test user"

XML API

curl -X GET "https://storage.googleapis.com/example_bucket/example_object" \
-H "Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg" \
-H "x-goog-custom-audit-job: job name" \
-H "x-goog-custom-audit-user: test user"

Signierte URL-Anfragen

curl -X GET 'storage.googleapis.com/example_bucket?X-Goog-Algorithm=GOOG4-RSA-SHA256&X-Goog-Credential=example%40example-project.iam.gserviceaccount.com%2F20181026%2Fus-central1%2Fstorage%2Fgoog4_request&X-Goog-Date=20181026T181309Z&X-Goog-Expires=900&X-Goog-SignedHeaders=host,x-goog-custom-audit-job,x-goog-custom-audit-user&X-Goog-Signature=247a2aa45f169edf4d187d54e7cc46e4731b1e6273242c4f4c39a1d2507a0e58706e25e3a85a7dbb891d62afa8496def8e260c1db863d9ace85ff0a184b894b117fe46d1225c82f2aa19efd52cf21d3e2022b3b868dcc1aca2741951ed5bf3bb25a34f5e9316a2841e8ff4c530b22ceaa1c5ce09c7cbb5732631510c20580e61723f5594de3aea497f195456a2ff2bdd0d13bad47289d8611b6f9cfeef0c46c91a455b94e90a66924f722292d21e24d31dcfb38ce0c0f353ffa5a9756fc2a9f2b40bc2113206a81e324fc4fd6823a29163fa845c8ae7eca1fcf6e5bb48b3200983c56c5ca81fffb151cca7402beddfc4a76b133447032ea7abedc098d2eb14a7' \
-H "x-goog-custom-audit-job: job name" \
-H "x-goog-custom-audit-user: test user"

Beachten Sie, dass die benutzerdefinierten Audit-Header auch in X-Goog-SignedHeaders enthalten sein müssen.

Um eine signierte URL-Anfrage zu erstellen, die das Hinzufügen von benutzerdefinierten Audit-Headern unterstützt, müssen die benutzerdefinierten Audit-Header, die Sie in der Anfrage verwenden möchten, ebenfalls enthalten sein, wenn Sie die signierte URL erzeugen. Beispiel:

gcloud storage sign-url gs://example_bucket/example_object.jpeg --private-key-file=example-key.json --duration=10m --headers=x-goog-custom-audit-job:"job name",x-goog-custom-audit-user="test user"

Sie können die signierte URL auch mit Clientbibliotheken generieren, wenn Sie benutzerdefinierte Header festlegen.

Als Alternative zu signierten Headern können Sie Abfrageparameter verwenden, um benutzerdefinierte Audit-Einträge zu übergeben.

curl -X GET 'storage.googleapis.com/example_bucket?X-Goog-Custom-Audit-Key=Value&X-Goog-Algorithm=GOOG4-RSA-SHA256&X-Goog-Credential=example%40example-project.iam.gserviceaccount.com%2F20181026%2Fus-central1%2Fstorage%2Fgoog4_request&X-Goog-Date=20181026T181309Z&X-Goog-Expires=900&X-Goog-SignedHeaders=host&X-Goog-Signature=247a2aa45f169edf4d187d54e7cc46e4731b1e6273242c4f4c39a1d2507a0e58706e25e3a85a7dbb891d62afa8496def8e260c1db863d9ace85ff0a184b894b117fe46d1225c82f2aa19efd52cf21d3e2022b3b868dcc1aca2741951ed5bf3bb25a34f5e9316a2841e8ff4c530b22ceaa1c5ce09c7cbb5732631510c20580e61723f5594de3aea497f195456a2ff2bdd0d13bad47289d8611b6f9cfeef0c46c91a455b94e90a66924f722292d21e24d31dcfb38ce0c0f353ffa5a9756fc2a9f2b40bc2113206a81e324fc4fd6823a29163fa845c8ae7eca1fcf6e5bb48b3200983c56c5ca81fffb151cca7402beddfc4a76b133447032ea7abedc098d2eb14a7'

Diese Abfrageparameter müssen beim Generieren der signierten URL einbezogen werden. Beispiel:

gcloud storage sign-url gs://example_bucket/example_object.jpeg --private-key-file=example-key.json --duration=10m --query-params=x-goog-custom-audit-job=job_name,x-goog-custom-audit-user=test_user

Beispiel für einen Logeintrag

protoPayload: {
  @type: "type.googleapis.com/google.cloud.audit.Auditlog",
  ...
  metadata: {
    audit_context: {
      app_context: "EXTERNAL",
      audit_info: {
        x-goog-custom-audit-job: "job name",
        x-goog-custom-audit-user: "test user"
      }
    }
  }
}

Weitere Informationen zu den im Objekt protoPayload enthaltenen Feldern mit dem Typ type.googleapis.com/google.cloud.audit.Auditlog finden Sie in der Referenzdokumentation AuditLog.

Audit-Logs weiterleiten

Sie können Audit-Logs auf dieselbe Weise wie andere Arten von Logs an unterstützte Ziele weiterleiten. Aus diesen Gründen kann es sinnvoll sein, Audit-Logs weiterzuleiten:

• Sie können Kopien Ihrer Audit-Logs an Cloud Storage, BigQuery oder Pub/Sub weiterleiten, um Audit-Logs für einen längeren Zeitraum aufzubewahren oder leistungsfähigere Suchfunktionen zu nutzen. Mit Pub/Sub haben Sie die Möglichkeit, die Logs an andere Anwendungen, andere Repositories und Dritte weiterzuleiten.
• Zum organisationsübergreifenden Verwalten Ihrer Audit-Logs erstellen Sie aggregierte Senken, mit denen sich Logs aus beliebigen oder allen Google Cloud-Projekten in der Organisation weiterleiten lassen.
• Wenn die aktivierten Audit-Logs zum Datenzugriff dazu führen, dass Ihre Cloud-Projekte Ihr zugewiesenes kostenloses Kontingent überschreiten, können Sie Senken erstellen, die die Audit-Logs zum Datenzugriff aus Logging ausschließen.

Eine Anleitung zum Routing von Logs finden Sie unter Senken konfigurieren und verwalten.

Preise

Informationen zu den Preisen für Cloud Logging finden Sie unter Preise für Google Cloud Observability: Cloud Logging.

Nächste Schritte

• Szenarien für das Exportieren mit Stackdriver Logging: Complianceanforderungen