Informationen zum Audit-Logging in Compute Engine

In diesem Dokument werden die Audit-Logs beschrieben, die von Compute Engine im Rahmen von Cloud-Audit-Logs erstellt werden.

Überblick

Google Cloud-Dienste schreiben Audit-Logs, aus denen in Bezug auf Ihre Google Cloud-Ressourcen hervorgeht, wer was wo und wann getan hat.

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

Die folgenden Typen von Audit-Logs sind für Compute Engine verfügbar:

  • Audit-Logs zur Administratoraktivität

    Umfasst „Admin Write“-Vorgänge, die Metadaten oder Konfigurationsinformationen schreiben.

    Sie können Audit-Logs zu Administratoraktivitäten nicht deaktivieren.

  • Audit-Logs zum Datenzugriff

    Umfasst „Admin Read“-Vorgänge, die Metadaten oder Konfigurationsinformationen lesen. Umfasst auch „Data Read“- und „Data Write“-Vorgänge, die von Nutzern bereitgestellte Daten lesen oder schreiben.

    Um Datenzugriffs-Audit-Logs zu erhalten, müssen Sie sie explizit aktivieren.

  • Audit-Logs zu Systemereignissen

    Identifiziert automatisierte Google Cloud-Aktionen, die die Konfiguration von Ressourcen ändern.

    Audit-Logs zu Systemereignissen können nicht deaktiviert werden.

Ausführlichere Informationen zu den Audit-Logtypen finden Sie unter Arten von Audit-Logs.

Geprüfte Vorgänge

In der folgenden Tabelle finden Sie eine Zusammenstellung der API-Vorgänge mit dem entsprechenden jeweiligen Audit-Logtyp in Compute Engine:

Audit-Logkategorie Untertyp Compute Engine-Vorgänge Beispiele
Audit-Logs zur Administratoraktivität –
  • Ressourcen erstellen
  • Ressourcen aktualisieren/patchen
  • Metadaten festlegen/ändern
  • Tags festlegen/ändern
  • Label festlegen/ändern
  • Berechtigungen festlegen/ändern
  • Eigenschaften einer Ressource (einschließlich benutzerdefinierte Verben) festlegen/ändern
  • compute.instances.insert
  • compute.instanceGroups.removeInstances
  • compute.instances.setMetadata
  • compute.instances.setTags
  • compute.instances.setLabels
  • compute.instances.setIamPolicy
  • compute.instances.update
Audit-Logs zum Datenzugriff1 ADMIN_READ
  • Informationen über eine Ressource abrufen
  • Ressourcen auflisten
  • Ressourcen bereichsübergreifend auflisten (Gesamtlistenanfragen)
  • compute.images.get
  • compute.instances.list
  • compute.interconnectAttachments.aggregatedList
DATA_READ Inhalte der seriellen Port-Konsole abrufen compute.instance.getSerialPortOutput
Audit-Logs zu Systemereignissen –
  • Bei Host-Wartung
  • Instanzpräemption
  • Automatischer Neustart
  • Instanzzurücksetzung
  • Verbindung/Trennung serieller Ports 2
  • compute.instances.migrateOnHostMaintenance
  • compute.instances.automaticRestart
  • compute.instanceGroupManagers.resizeAdvanced
  • google.ssh-serialport.v1.connect

1Audit-Logs zum Datenzugriff: Im Gegensatz zu Audit-Logs für andere Dienste bietet Compute Engine nur ADMIN_READ-Datenzugriffslogs und stellt in der Regel keine DATA_READ- und DATA_WRITE-Logs bereit. Das liegt daran, dass DATA_READ- und DATA_WRITE-Logs nur für Dienste verwendet werden, die Nutzerdaten speichern und verwalten, wie z. B. Cloud Storage, Spanner und Cloud SQL. Auf Compute Engine trifft dies nicht zu. Eine Ausnahme hier ist, dass die Methode instance.getSerialPortOutput ein DATA_READ-Log erzeugt, da dies Methode Daten direkt aus der VM-Instanz liest.

2Verbindung/Trennung serieller Ports: Weitere Informationen zu Audit-Logs der seriellen Konsole finden Sie unter Audit-Logs der seriellen Konsole ansehen.

In Audit-Logs entfernte Daten

Audit-Logs erfassen die Anfrage- und Antwortdaten der ausgeführten API-Aktionen. Unter den folgenden Umständen sind die Anfrage- oder Antwortdaten jedoch nicht verfügbar oder werden entfernt:

  • Bei den API-Anfragen instance.setMetadata und project.setCommonInstanceMetadata wird der Metadatenteil des Anfragetexts entfernt, um zu verhindern, dass vertrauliche Informationen geloggt und in den Metadaten gesendet werden.
  • Felder mit vertraulichen Daten werden aus Anfragen entfernt, z. B. private Schlüssel für SSL-Zertifikate und vom Kunden angegebene Verschlüsselungsschlüssel für Laufwerke.
  • Bei Antworten auf "get" und "list" wird der Antworttext entfernt, damit keine vertraulichen Informationen geloggt werden.

Audit-Log-Format

Audit-Logeinträge umfassen folgende Komponenten:

  • Den Logeintrag selbst. Dabei handelt es sich um ein Objekt vom Typ LogEntry. 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 dienstspezifische Auditinformationen. Das Objekt ist dienstspezifisch. Bei früheren Integrationen befindet sich dieses Objekt im Feld serviceData des AuditLog-Objekts. Spätere Integrationen verwenden das Feld metadata.

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 der Inhaber der Audit-Logs ist. Außerdem zeigen sie an, ob das Log Audit-Logging-Daten zu Administratoraktivitäten, Datenzugriff, Richtlinienverweigerung oder Audit-Systemereignissen 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
   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fsystem_event
   projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fpolicy

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

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

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

Dienstname

Compute Engine-Audit-Logs verwenden die folgenden Dienstnamen:

  • compute.googleapis.com
  • ssh-serialport.googleapis.com
  • oslogin.googleapis.com

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

Ressourcentypen

Compute Engine-Audit-Logs verwenden die folgenden Ressourcentypen für Audit-Logs:

Ressourcentypkategorie Beschreibung Beispiele
API-Ressource Diese Ressource erfasst API-Vorgänge. api
Geprüfte Ressource Diese Ressource loggt Google Cloud-Vorgänge. Der Typ der geprüften Ressource wird hauptsächlich für neue Vorgänge verwendet, die nicht in die anderen Kategorien passen. audited_resource
Autoscaler Diese Ressource protokolliert Autoscaling-Vorgänge. autoscaler
Deployment-Ressource Diese Ressource erfasst Deployment-Vorgänge. deployment
Cloud Deployment Manager-Ressourcen (deployment_manager_*)

Diese Ressource erfasst Cloud Deployment Manager-Vorgänge.

Die Ressourcentypen deployment_manager_* werden den Cloud Deployment Manager-Ressourcen zugeordnet. Eine vollständige Liste der Cloud Deployment Manager-Ressourcen finden Sie in der Übersicht zur Cloud Deployment Manager API.
  • deployment_manager_manifest
  • deployment_manager_operation
  • deployment_manager_resource
  • deployment_manager_type
Compute Engine-Ressourcen (gce_*)

Diese Ressource erfasst Compute Engine-Vorgänge.

Die gce_*-Ressourcentypen sind den Compute Engine-Ressourcen zugeordnet. Eine vollständige Liste der Compute Engine-Ressourcen finden Sie in der Übersicht zur Compute Engine API.
  • gce_instance
  • gce_backend_service
  • gce_operation
  • gce_instance_group
  • gce_firewall_rule
  • gce_snapshot
  • gce_route
  • gce_disk
  • gce_health_check
Netzwerksicherheitsressource Diese Ressource erfasst Vorgänge in Netzwerksicherheitsrichtlinien. network_security_policy
Cloud VPN-Ressourcen (vpn_*) Diese Ressource erfasst Cloud VPN-Vorgänge.
  • vpn_gateway
  • vpn_tunnel

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

Aufruferidentitäten

Die IP-Adresse des Aufrufers wird im Feld RequestMetadata.caller_ip des AuditLog-Objekts gespeichert. In Logging können bestimmte Aufruferidentitäten und IP-Adressen entfernt werden.

Informationen dazu, welche Informationen in Audit-Logs entfernt werden, finden Sie unter Aufruferidentitäten in Audit-Logs.

Audit-Logging aktivieren

Audit-Logs zu Systemereignissen sind immer aktiviert und können nicht deaktiviert werden.

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 sie explizit aktiviert werden. Eine Ausnahme bilden die Audit-Logs zum Datenzugriff für BigQuery, die nicht deaktiviert werden können.

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

Berechtigungen und Rollen

IAM-Berechtigungen und -Rollen 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 im Bucket _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 im Bucket _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.

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:

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:

  1. Wählen Sie im Navigationsbereich der Google Cloud Console Logging und anschließend Log-Explorer aus:

    Zum Log-Explorer

  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 Duet AI finden Sie unter Logeinträge mit Duet AI-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 Execute.

Beispielabfragen

Verwenden Sie die folgenden Abfragen im Log-Explorer, um Audit-Logs für Compute Engine zu finden:

Name der Abfrage Ausdruck
Hostfehler 
resource.type="gce_instance"
protoPayload.serviceName="compute.googleapis.com"
(protoPayload.methodName:"compute.instances.hostError" OR
  operation.producer:"compute.instances.hostError")
log_id("cloudaudit.googleapis.com/system_event")
resource.labels.instance_id="INSTANCE_ID"
severity="INFO"
Hostwartung 
resource.type="gce_instance"
protoPayload.serviceName="compute.googleapis.com"
(protoPayload.methodName:"OnHostMaintenance" OR
  operation.producer:"OnHostMaintenance")
log_id("cloudaudit.googleapis.com/system_event")
resource.labels.instance_id="INSTANCE_ID"
severity=INFO
Host migriert 
resource.type="gce_instance"
protoPayload.serviceName="compute.googleapis.com"
(protoPayload.methodName:"compute.instances.migrateOnHostMaintenance" OR
  operation.producer:"compute.instances.migrateOnHostMaintenance")
log_id("cloudaudit.googleapis.com/system_event")
resource.labels.instance_id="INSTANCE_ID"
severity=INFO
Instanz beendet oder vorzeitig beendet 
resource.type="gce_instance"
protoPayload.methodName=~"compute.instances.(guestTerminate|preempted)"
log_id("cloudaudit.googleapis.com/activity")
resource.labels.instance_id="INSTANCE_ID"
Instanz durch Gastbetriebssystem beendet 
resource.type="gce_instance"
protoPayload.serviceName="compute.googleapis.com"
(protoPayload.methodName:"compute.instances.guestTerminate" OR
  operation.producer:"compute.instances.guestTerminate")
log_id("cloudaudit.googleapis.com/system_event")
resource.labels.instance_id="INSTANCE_ID"
severity=INFO
Instanz bei Hostwartung beendet 
resource.type="gce_instance"
protoPayload.serviceName="compute.googleapis.com"
(protoPayload.methodName:"compute.instances.terminateOnHostMaintenance" OR
  operation.producer:"compute.instances.terminateOnHostMaintenance")
log_id("cloudaudit.googleapis.com/system_event")
resource.labels.instance_id="INSTANCE_ID"
severity=INFO
Instanz erstellt 
resource.type="gce_instance"
protoPayload.methodName:"compute.instances.insert"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.request.name="INSTANCE_NAME"
Instanzname gelöscht 
resource.type="gce_instance"
protoPayload.methodName:"compute.instances.delete"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.resourceName:"INSTANCE_NAME"
Instanz-ID gelöscht 
resource.type="gce_instance"
protoPayload.methodName:"compute.instances.delete"
log_id("cloudaudit.googleapis.com/activity")
resource.labels.instance_id="INSTANCE_ID"
Instanz neu gestartet 
resource.type="gce_instance"
protoPayload.methodName=~
  "compute.instances.(stop|reset|automaticRestart|
  guestTerminate|instanceManagerHaltForRestart)"
(log_id("cloudaudit.googleapis.com/activity")
  OR log_id("cloudaudit.googleapis.com/system_event"))
resource.labels.instance_id="INSTANCE_ID"
Nichtflüchtiger Speicher erstellt 
resource.type="gce_disk"
protoPayload.methodName:"compute.disks.insert"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.request.name="PD_NAME"
Nichtflüchtiger Speicher gelöscht 
resource.type="gce_disk"
protoPayload.methodName:"compute.disks.delete"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.resourceName="PD_NAME"
Knoten zu Knoten für einzelne Mandanten hinzugefügt 
resource.type="gce_node_group"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.methodName=~("compute.nodeGroups.addNodes" OR
  "compute.nodeGroups.insert")
resource.labels.node_group_id="NODE_GROUP_ID"
Autoscaling von Ereignissen zu Knoten für einzelne Mandanten 
resource.type="gce_node_group"
log_id("cloudaudit.googleapis.com/system_event")
protoPayload.methodName=~("compute.nodeGroups.deleteNodes" OR
  "compute.nodeGroups.addNodes")
resource.labels.node_group_id="NODE_GROUP_ID"
Snapshot manuell erstellt 
resource.type="gce_disk"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.methodName:"compute.disks.createSnapshot"
protoPayload.request.sourceDisk:"PD_NAME"
protoPayload.request.name="SNAPSHOT_NAME"
Geplanter Snapshot erstellt 
resource.type="gce_disk"
log_id("cloudaudit.googleapis.com/system_event")
protoPayload.methodName="ScheduledSnapshots"
protoPayload.response.operationType="createSnapshot"
protoPayload.response.targetLink="PD_NAME"
Snapshot manuell gelöscht 
resource.type="gce_snapshot"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.methodName:"compute.snapshots.delete"
protoPayload.resourceName:"SNAPSHOT_NAME"
Snapshot-Zeitplan erstellt 
resource.type="gce_resource_policy"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.methodName:"compute.resourcePolicies.insert"
protoPayload.request.name="SCHEDULE_NAME"
Snapshot-Zeitplan gelöscht 
resource.type="gce_resource_policy"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.methodName:"compute.resourcePolicies.delete"
protoPayload.request.name="SCHEDULE_NAME"
Snapshot-Zeitplan angehängt 
resource.type="gce_disk"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.methodName:"compute.disks.addResourcePolicies"
protoPayload.request.resourcePolicys:"SCHEDULE_NAME"
protoPayload.resourceName:"PD_NAME"
Snapshot-Zeitplan getrennt 
resource.type="gce_disk"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.methodName:"compute.disks.removeResourcePolicies"
protoPayload.request.resourcePolicys:"SCHEDULE_NAME"
protoPayload.resourceName:"PD_NAME"
Instanz entfernt oder aus Instanzgruppe hinzugefügt 
resource.type="gce_instance_group"
protoPayload.methodName:"compute.instanceGroups.*"
log_id("cloudaudit.googleapis.com/activity")
resource.labels.instance_group_name="INSTANCE_GROUP_NAME"
Instanzvorlage für eine verwaltete Instanzgruppe festgelegt oder aktualisiert 
resource.type="gce_instance_group_manager"
log_id("cloudaudit.googleapis.com/activity")
protoPayload.methodName="v1.compute.instanceGroupManagers.setInstanceTemplate"
resource.labels.instance_group_manager_name="INSTANCE_GROUP_NAME"
Autoscaling für verwaltete Instanzgruppen skalieren 
resource.type="autoscaler"
resource.labels.project_id="PROJECT"
resource.labels.autoscaler_name="AUTOSCALER_NAME"
Firewallregel wurde gelöscht 
resource.type="gce_firewall_rule" AND
log_id("cloudaudit.googleapis.com/activity") AND
protoPayload.methodName:"firewalls.delete"

So verwenden Sie die Beispielabfragen:

  1. Ersetzen Sie die Variablen durch Ihre eigenen Projektinformationen und kopieren Sie den Ausdruck dann mit dem Symbol der Zwischenablage .

  2. Wählen Sie im Navigationsbereich der Google Cloud Console Logging und anschließend Log-Explorer aus:

    Zum Log-Explorer

  3. Aktivieren Sie Abfrage anzeigen, um das Feld „Query Editor” zu öffnen, und fügen Sie den Ausdruck dann in das Feld des Query Editor ein:

    Der Query Editor, in dem Sie Beispielabfragen eingeben.

  4. Klicken Sie auf Abfrage ausführen. Logs, die Ihrer Abfrage entsprechen, werden im Bereich Abfrageergebnisse aufgeführt.

Audit-Logs weiterleiten

Sie können Audit-Logs auf dieselbe Weise wie andere Arten von Logs an unterstützte Ziele weiterleiten. Im Folgenden erfahren Sie, warum es sinnvoll sein kann, Ihre 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 Google Cloud-Projekte Ihre Logkontingente überschreiten, können Sie Senken erstellen, die die Audit-Logs zum Datenzugriff aus Logging ausschließen.

Eine Anleitung zum Weiterleiten von Logs finden Sie unter Logs an unterstützte Ziele weiterleiten.

Preise

Weitere Informationen zu Preisen finden Sie in der Preisübersicht für Cloud Logging.