Cloud-Audit-Logs – Übersicht

Dieses Dokument bietet eine konzeptionelle Übersicht über Cloud-Audit-Logs.

Google Cloud Dienste schreiben Audit-Logs, in denen administrative Aktivitäten und Zugriffe in Ihren Google Cloud Ressourcen aufgezeichnet werden. Anhand von Audit-Logs können Sie herausfinden, wer was wo und wann in Ihren Ressourcen getan hat. Dabei haben Sie dieselbe Transparenz wie in lokalen Umgebungen. Google Cloud Wenn Sie Audit-Logs aktivieren, können Ihre Sicherheits-, Prüf- und Compliance-Teams Google Cloud Daten und Systeme auf mögliche Sicherheitslücken oder externen Datenmissbrauch hin überwachen.

Google Cloud Dienste, die Audit-Logs generieren

Eine Liste der Google Cloud Dienste, die Audit-Logs bereitstellen, finden Sie unter Google Cloud Dienste mit Audit-Logs. Es ist davon auszugehen, dass letztendlich alle Google Cloud Dienste Audit-Logs bereitstellen werden.

Google Cloud MCP-Server schreiben Audit-Logs zum Datenzugriff. Audit-Logs zum Datenzugriff , die von Google Cloud MCP-Servern geschrieben werden, sind dienstspezifisch und verwenden das Format SERVICE_NAME.googleapis.com/mcp. Sie können diese Audit-Logs zum Datenzugriff aktivieren , indem Sie das Audit-Logging für mcp.googleapis.com im Objekt IAM AuditConfig aktivieren. Weitere Informationen zum Audit-Logging für Google Cloud MCP-Server finden Sie unter Audit-Logging für Google Cloud MCP-Server.

Eine Übersicht über Audit-Logs von Google Workspace finden Sie unter Audit-Logs für Google Workspace.

Erforderliche Rollen

Zum Aufrufen von Audit-Logs benötigen Sie die entsprechenden IAM-Berechtigungen (Identity and Access Management) und -Rollen:

  • Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle „Log-Betrachter“ (roles/logging.viewer) für Ihr Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie für den schreibgeschützten Zugriff auf Audit-Logs zu Administratoraktivitäten, Richtlinienverstößen und Systemereignissen benötigen.

    Wenn Sie nur die Rolle „Log-Betrachter“ (roles/logging.viewer) haben, dann können Sie keine Audit-Logs zum Datenzugriff aufrufen, die sich im _Default Bucket befinden.

  • Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle „Betrachter privater Logs“ (roles/logging.privateLogViewer) für Ihr Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie für den Zugriff auf alle Logs in den _Required und _Default Buckets benötigen, einschließlich der Audit-Logs zum Datenzugriff.

    Die Rolle „Betrachter privater Logs“ (roles/logging.privateLogViewer) enthält die Berechtigungen, die in der Rolle „Log-Betrachter“ (roles/logging.viewer) enthalten sind, sowie die Berechtigungen, die zum Lesen von Audit-Logs zum Datenzugriff im Bucket _Default erforderlich sind.

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

Arten von Audit-Logs

Cloud-Audit-Logs erstellt für jedes Google Cloud Projekt, jeden Ordner und jede Organisation die folgenden Audit-Logs:

Audit-Logs zur Administratoraktivität

Audit-Logs zur Administratoraktivität sind Logeinträge, die von nutzergesteuerten API-Aufrufen oder anderen Aktionen geschrieben werden, mit denen die Konfiguration oder die Metadaten von Ressourcen geändert werden. In diesen Logs wird beispielsweise aufgezeichnet, wann Nutzer VM-Instanzen erstellen oder IAM-Berechtigungen (Identity and Access Management) ändern.

Audit-Logs für Administratoraktivitäten werden immer geschrieben. Sie können diese nicht konfigurieren, ausschließen oder deaktivieren. Selbst wenn Sie die Cloud Logging API deaktivieren, werden weiterhin Audit-Logs zur Administratoraktivität generiert.

Eine Liste der Dienste, die Audit-Logs zur Administratoraktivität schreiben, und detaillierte Informationen dazu, welche Aktivitäten diese Logs generieren, finden Sie unter Google Cloud Dienste mit Audit-Logs.

Audit-Logs zum Datenzugriff

Audit-Logs zum Datenzugriff sind Logeinträge, die von API-Aufrufen geschrieben werden, mit denen die Konfiguration oder Metadaten von Ressourcen gelesen werden. Sie werden auch von nutzergesteuerten API-Aufrufen geschrieben, die von Nutzern bereitgestellte Ressourcendaten erstellen, ändern oder lesen.

Öffentlich verfügbare Ressourcen mit Identity and Access Management-Richtlinien allAuthenticatedUsers oder allUsers generieren keine Audit-Logs. Ressourcen , auf die ohne Anmeldung in einem Google Cloud, Google Cloud-, Google Workspace-, Cloud Identity- oder Drive Enterprise-Konto zugegriffen werden kann, generieren keine Audit-Logs. So werden Endnutzeridentitäten und -informationen geschützt.

Audit-Logs zum Datenzugriff sind – außer bei BigQuery – standardmäßig deaktiviert, da sie sehr groß sein können. Wenn Audit-Logs zum Daten Zugriff für andere Dienste als Google Cloud BigQuery geschrieben werden sollen, müssen Sie sie explizit aktivieren. Audit-Logs zum Datenzugriff werden in das Google Cloud Projekt geschrieben, auf dessen Daten zugegriffen wird. Durch die Aktivierung dieser Logs können Gebühren für die zusätzliche Lognutzung im Google Cloud Projekt anfallen. Eine Anleitung zum Aktivieren und Konfigurieren von Audit-Logs zum Datenzugriff finden Sie unter Audit-Logs zum Datenzugriff aktivieren.

Eine Liste der Dienste, die Audit-Logs zum Datenzugriff schreiben, und detaillierte Informationen dazu, welche Aktivitäten diese Logs generieren, finden Sie unter Google Cloud Dienste mit Audit-Logs.

Audit-Logs zum Datenzugriff werden im _Default Log-Bucket gespeichert, sofern Sie sie nicht an einen anderen Ort weitergeleitet haben. Weitere Informationen finden Sie im Abschnitt Audit-Logs speichern und weiterleiten auf dieser Seite.

Audit-Logs zu Systemereignissen

Audit-Logs zu Systemereignissen sind Logeinträge, die von Google Cloud Systemen geschrieben werden, mit denen die Konfiguration von Ressourcen geändert wird. Audit-Logs zu Systemereignissen werden nicht durch direkte Nutzeraktionen gesteuert. Ein Audit-Log zu Systemereignissen wird beispielsweise geschrieben, wenn VMs aufgrund von Autoscaling automatisch zu verwalteten Instanzgruppen (MIGs) hinzugefügt oder daraus entfernt werden.

Audit-Logs zu Systemereignissen werden immer geschrieben. Sie können sie nicht konfigurieren, ausschließen oder deaktivieren.

Eine Liste der Dienste, die Audit-Logs zu Systemereignissen schreiben, und detaillierte Informationen dazu, welche Aktivitäten diese Logs generieren, finden Sie unter Google Cloud Dienste mit Audit-Logs.

Audit-Logs zu Richtlinienverstößen

Audit-Logs zu Richtlinienverstößen sind Logeinträge, die geschrieben werden, wenn ein Google Cloud Dienst den Zugriff auf einen Nutzer oder ein Dienstkonto aufgrund eines Verstoßes gegen eine Sicherheitsrichtlinie verweigert.

Audit-Logs zu Richtlinienverstößen werden standardmäßig generiert und Ihrem Google Cloud Projekt wird der Logspeicher in Rechnung gestellt. Sie können die Audit-Logs zu Richtlinienverstößen nicht deaktivieren, können jedoch Ausschlussfilter nutzen, um zu verhindern, dass Audit-Logs zu Richtlinienverstößen in Cloud Logging gespeichert werden.

Eine Liste der Dienste, die Audit-Logs zu Richtlinienverstößen schreiben, und detaillierte Informationen dazu, welche Aktivitäten diese Logs generieren, finden Sie unter Google Cloud Dienste mit Audit-Logs.

Struktur von Audit-Logeinträgen

Jeder Audit-Logeintrag in Cloud Logging ist ein Objekt vom Typ LogEntry. Ein Audit-Logeintrag unterscheidet sich von anderen Log einträgen durch das protoPayload Feld. Dieses Feld enthält ein AuditLog Objekt, das die Audit-Logging-Daten speichert.

Informationen zum Lesen und Interpretieren von Audit-Logeinträgen sowie ein Beispiel für einen Audit-Logeintrag finden Sie unter Audit-Logs verstehen.

Log name

Lognamen von Cloud-Audit-Logs enthalten Folgendes:

  • Ressourcenkennungen, die das Google Cloud Projekt oder andere Google Cloud Entität vonangeben, die der Inhaber der Audit-Logs ist.

  • Den String cloudaudit.googleapis.com.

  • Einen String, der angibt, ob das Log Audit-Logging-Daten zu Administratoraktivitäten, Datenzugriff, Richtlinienverstößen oder 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

Aufruferidentitäten in Audit-Logs

In Audit-Logs wird die Identität des Nutzers aufgezeichnet, der die erfassten Aktionen für die Google Cloud Ressource ausgeführt hat. Die Identität des Aufrufers wird im AuthenticationInfo Feld von AuditLog Objekten gespeichert.

Beim Audit-Logging wird die primäre E-Mail-Adresse des Aufrufers für jeden erfolgreichen Zugriff oder jeden Schreibvorgang nicht entfernt.

Bei schreibgeschützten Vorgängen, die mit dem Fehler „Berechtigung verweigert“ fehlschlagen, kann die primäre E-Mail-Adresse des Aufrufers entfernt werden, es sei denn, der Aufrufer ist ein Dienstkonto.

Zusätzlich zu den oben aufgeführten Bedingungen gilt für bestimmte Google Cloud Dienste Folgendes:

  • BigQuery: Aufrufer identitäten und IP-Adressen sowie einige Ressourcennamen werden aus den Audit-Logs entfernt , sofern nicht bestimmte Bedingungen erfüllt sind.

  • Cloud Storage: Wenn Cloud Storage Nutzungslogs aktiviert sind, schreibt Cloud Storage Nutzungsdaten in den Cloud Storage-Bucket, der Audit-Logs zum Datenzugriff für den Bucket generiert. Die Aufrufer-ID des Datenzugriffs-Audit-Logs wurde entfernt.

  • Firestore: Wurde ein JSON Web Token (JWT) für die Authentifizierung von Drittanbietern verwendet, enthält das thirdPartyPrincipal Feld den Header und die Nutzlast des Tokens. Beispiel: Audit-Logs für Anfragen, die mit Firebase Authentication authentifiziert wurden, enthalten das Authentifizierungstoken dieser Anfrage.
  • VPC Service Controls: Bei Audit-Logs zu Richtlinienverstößen erfolgt die folgende Entfernung:

    • Teile der E‑Mail-Adressen des Aufrufers werden möglicherweise entfernt und durch drei Punkte (...) ersetzt.

    • Einige E‑Mail-Adressen des Aufrufers, die zur Domain google.com gehören, werden entfernt und durch google-internal ersetzt.

  • Organisationsrichtlinie: Teile der E‑Mail-Adressen des Aufrufers werden möglicherweise entfernt und durch drei Punkte ...ersetzt.

IP-Adresse des Aufrufers in Audit-Logs

Die IP-Adresse des Aufrufers wird im Feld RequestMetadata.callerIp des Objekts AuditLog gespeichert:

  • Für Aufrufer aus dem Internet ist die Adresse eine öffentliche IPv4- oder IPv6-Adresse.
  • Bei Aufrufen, die innerhalb des internen Produktionsnetzwerks von einem Google Cloud Dienst zu einem anderen erfolgen, wird callerIp durch "private" ersetzt.
  • Für Aufrufer von einer Compute Engine-VM mit einer externen IP-Adresse ist callerIp die externe Adresse der VM.
  • Für Aufrufer von einer Compute Engine-VM ohne externe IP-Adresse gilt: Wenn sich die VM in derselben Organisation oder demselben Projekt wie die aufgerufene Ressource befindet, ist callerIp die interne IPv4-Adresse der VM. Andernfalls wird callerIp durch „gce-internal-ip“ ersetzt. Weitere Informationen finden Sie unter VPC-Netzwerk (Virtual Private Cloud) – Übersicht.

Audit-Logs ansehen

Sie können alle Audit-Logs oder Audit-Lognamen abfragen. Der Audit-Logname enthält die Ressourcenkennung des Projekts, Ordners, Rechnungskontos oder der Organisation in Google Cloud , für die Sie Audit-Logging-Informationen aufrufen möchten. In Ihren Abfragen können Sie indexierte Felder des Typs LogEntry angeben. Weitere Informationen zum Abfragen von Logs finden Sie auf der Seite zum Erstellen von Abfragen im Log-Explorer.

Mit dem Log-Explorer können Sie einzelne Logeinträge filtern. Wenn Sie SQL nutzen möchten, um Gruppen von Logeinträgen zu analysieren, verwenden Sie die Seite Loganalysen. Weitere Informationen finden Sie unter:

Die meisten Audit-Logs können in Cloud Logging über dieGoogle Cloud Console, die Google Cloud CLI oder die Logging API aufgerufen werden. Für Audit-Logs im Zusammenhang mit der Abrechnung können Sie jedoch nur die Google Cloud CLI oder die Logging API verwenden.

Console

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

  1. Rufen Sie in der Google Cloud Console das Segment und 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 Projekt, einen Ordner oder eine Organisation in Google Cloud aus.

  3. Wenn Sie alle Audit-Logs aufrufen möchten, geben Sie eine der folgenden Abfragen in das Feld des Abfrageeditors ein und klicken Sie 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 Typ von Audit-Log 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 Projekt, im Ordner oder in der Organisation in Google Cloud 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 auf der Seite zum Erstellen von Abfragen im Log-Explorer.

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 inGoogle Cloud ausgewählte Projekt beziehen.

Führen Sie den folgenden Befehl aus, um Audit-Logeinträge auf Ebene des Projekts in Google Cloud zu lesen:

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

Führen Sie den folgenden Befehl aus, um 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 finden Sie unter gcloud logging read.

REST

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 inGoogle Cloud ausgewählte Projekt beziehen.

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

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

  2. Geben Sie im Teil Anfragetext des Formulars Diese API testen Folgendes ein. Wenn Sie auf dieses vorab ausgefü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 speichern und weiterleiten

Cloud Logging verwendet Log-Buckets als Container. Diese speichern und organisieren Ihre Logdaten. Für jedes Rechnungskonto, Google Cloud Projekt, jeden Ordner und jede Organisation erstellt Logging automatisch zwei Log-Buckets, _Required und _Default, und entsprechend benannte Senken.

In Cloud Logging-Buckets vom Typ _Required werden Audit-Logs zur Administratoraktivität und Audit-Logs zu Systemereignissen gespeichert. Sie können nicht verhindern, dass Audit-Logs zu Administratoraktivitäten oder zu Systemereignissen gespeichert werden. Außerdem können Sie die Senke, die Logeinträge an die Buckets vom Typ _Required weiterleitet, nicht konfigurieren.

Audit-Logs zu Administratoraktivitäten und Audit-Logs zu Systemereignissen werden immer im Bucket _Required des Projekts gespeichert, in dem die Logs generiert wurden.

Wenn Sie Audit-Logs zu Administratoraktivitäten und Audit-Logs zu Systemereignissen an ein anderes Projekt weiterleiten, werden diese Logs nicht über die Senke _Default oder _Required des Zielprojekts weitergeleitet. Daher werden diese Logs nicht im Log-Bucket _Default oder im Log-Bucket _Required des Zielprojekts gespeichert. Wenn Sie diese Logs speichern möchten, erstellen Sie eine Logsenke im Zielprojekt. Weitere Informationen finden Sie unter Logs an unterstützte Ziele weiterleiten.

In den Buckets vom Typ _Default werden standardmäßig alle aktivierten Audit-Logs zum Datenzugriff sowie zu Richtlinienverstößen gespeichert. Wenn Sie verhindern möchten, dass Audit-Logs zum Datenzugriff in den Buckets vom Typ _Default gespeichert werden, können Sie sie deaktivieren. Wenn Sie verhindern möchten, dass Audit-Logs zu Richtlinienverstößen in den Buckets vom Typ _Default gespeichert werden, können Sie sie ausschließen. Ändern Sie dazu die Filter der Senken.

Sie können Ihre Audit-Logeinträge auch auf Projektebene an benutzerdefinierte Cloud Logging-Buckets oder mithilfe von Senken an unterstützte Ziele außerhalb von Logging weiterleiten. Google Cloud Eine Anleitung zum Weiterleiten von Logs finden Sie unter Logs an unterstützte Ziele weiterleiten.

Beim Konfigurieren der Filter Ihrer Logsenken müssen Sie die Audit-Log Typen angeben, die Sie weiterleiten möchten. Beispiele zum Filtern finden Sie unter Sicherheits-Logging-Abfragen.

Informationen zum Weiterleiten von Audit-Logeinträgen für eine Google Cloud Organisation, einen Ordner oder ein Rechnungskonto und deren untergeordnete Elemente finden Sie unter Aggregierte Senken – Übersicht.

Audit-Log-Aufbewahrung

Ausführliche Informationen zur Aufbewahrungsdauer der Logeinträge in Logging finden Sie unter Kontingente und Limits: Aufbewahrungsdauer für Logs.

Zugriffssteuerung

IAM-Berechtigungen und -Rollen bestimmen Ihre Fähigkeit, auf Audit Logdaten in der Logging API, dem Log-Explorer und der Google Cloud CLI zuzugreifen.

Ausführliche Informationen zu den erforderlichen IAM-Berechtigungen und -Rollen, die Sie benötigen, finden Sie unter Zugriffssteuerung mit IAM.

Kontingente und Limits

Einzelheiten zu den Nutzungslimits für Logging, einschließlich der maximalen Größe von Audit-Logs, finden Sie unter Kontingente und Limits.

Preise

Preisinformationen finden Sie auf der Seite Preise für Google Cloud Observability. Wenn Sie Logdaten an andere Google Cloud Dienste weiterleiten, finden Sie weitere Informationen in den folgenden Dokumenten:

Nächste Schritte

  • Informationen zu Access Transparency, das Protokolle der Aktionen bereitstellt, die von Mitarbeitern beim Zugriff auf Ihre Inhalte ausgeführt wurden Google Cloud Google Cloud