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 mit derselben Transparenz wie in lokalen Umgebungen herausfinden, wer was wo und wann in Ihren Google Cloud-Ressourcen getan hat. Wenn Sie Audit-Logs aktivieren, können Ihre Sicherheits-, Audit- und Compliance-Teams Google Cloud-Daten und -Systeme auf mögliche Sicherheitslücken oder externen Datenmissbrauch prüfen.
Audit-Logs generierende Google Cloud-Dienste
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.
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:
-
Wenn Sie Lesezugriff auf die Audit-Logs zu Administratoraktivitäten, abgelehnten Richtlinien und Systemereignissen benötigen, bitten Sie Ihren Administrator, Ihnen die IAM-Rolle Log-Betrachter (
roles/logging.viewer
) für das Projekt zuzuweisen.Wenn Sie nur die Rolle „Log-Betrachter“
(roles/logging.viewer)
haben, können Sie keine Audit-Logs zum Datenzugriff aufrufen, die sich im Bucket_Default
befinden.
-
Bitten Sie Ihren Administrator, Ihnen die IAM-Rolle Betrachter privater Protokolle (
roles/logging.privateLogViewer
) für Ihr Projekt zu gewähren, um die Berechtigungen zu erhalten, die Sie zum Zugriff auf alle Protokolle in den_Required
- und_Default
-Buckets benötigen, einschließlich Protokolle 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 zum Datenzugriff
- Audit-Logs zu Systemereignissen
- Audit-Logs zu Richtlinienverstößen
Audit-Logs zur Administratoraktivität
Audit-Logs zur Administratoraktivität enthalten Logeinträge für API-Aufrufe oder andere Aktionen, die die Konfiguration oder Metadaten von Ressourcen ändern. In diesen Logs wird beispielsweise aufgezeichnet, wann Nutzer VM-Instanzen erstellen oder Berechtigungen von 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 zu Administratoraktivitäten 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 enthalten API-Aufrufe, die die Konfiguration oder Metadaten von Ressourcen lesen, sowie nutzergesteuerte API-Aufrufe, die von Nutzern bereitgestellte Ressourcendaten erstellen, ändern oder lesen.
Öffentlich verfügbare Ressourcen mit den IAM-Richtlinien allAuthenticatedUsers
oder allUsers
generieren keine Audit-Logs. Ressourcen, auf die ohne Anmeldung in Google Cloud, Google Workspace, Cloud Identity oder Drive Enterprise zugegriffen werden kann, generieren keine Audit-Logs. So werden Endnutzeridentitäten und -informationen geschützt.
Audit-Logs für den Datenzugriff sind – mit Ausnahme von BigQuery-Audit-Logs für den Datenzugriff – standardmäßig deaktiviert, da sie relativ groß sein können. Wenn Audit-Logs zum Datenzugriff für andere Google Cloud-Dienste als BigQuery geschrieben werden sollen, müssen Sie sie explizit aktivieren. Durch das Aktivieren der 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 für den Datenzugriff schreiben, und detaillierte Informationen dazu, welche Aktivitäten diese Logs generieren, finden Sie unter Google Cloud-Dienste mit Audit-Logs.
Audit-Logs für den Datenzugriff werden im Log-Bucket _Default
gespeichert, sofern Sie sie nicht an eine andere Stelle weitergeleitet haben. Weitere Informationen finden Sie im Abschnitt Audit-Logs speichern und weiterleiten auf dieser Seite.
Audit-Logs zu Systemereignissen
Audit-Logs zu Systemereignissen enthalten Logeinträge für Google Cloud-Aktionen, die Ressourcenkonfigurationen ändern. Audit-Logs zu Systemereignissen werden von Google Cloud-Systemen generiert und nicht durch direkte Nutzeraktionen bedingt.
Audit-Logs zu Systemereignissen werden immer geschrieben. Sie können sie nicht konfigurieren, ausschließen oder deaktivieren.
Eine Liste der Dienste, die Audit-Logs für Systemereignisse schreiben, sowie 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 werden aufgezeichnet, wenn ein Google Cloud-Dienst den Zugriff auf einen Nutzer oder ein Dienstkonto aufgrund eines Verstoßes gegen eine Sicherheitsrichtlinie verweigert.
Audit-Logs über Richtlinien verweigert 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 für abgelehnte Richtlinien schreiben, sowie 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 Logeinträgen durch das Feld protoPayload
. 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.
Logname
Beispiele für Lognamen von Cloud-Audit-Logs:
Ressourcenkennungen, die das Google Cloud-Projekt oder eine andere Google Cloud-Entität angeben, die Inhaber der Audit-Logs ist.
Der String
cloudaudit.googleapis.com
.Ein String, der angibt, ob das Log Audit-Logging-Daten zur Administratoraktivität, zum Datenzugriff, zu abgelehnten Richtlinien oder zu 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
Audit-Logs zeichnen die Identität auf, die die protokollierten Vorgänge für die Google Cloud-Ressource durchgeführt hat. Die Identität des Aufrufers wird im Feld AuthenticationInfo
von AuditLog
-Objekten gespeichert.
Bei der Audit-Protokollierung wird die primäre E-Mail-Adresse des Aufrufers nicht für erfolgreiche Zugriffe oder Schreibvorgänge entfernt.
Bei schreibgeschützten Vorgängen, die mit dem Fehler „Berechtigung verweigert“ fehlschlagen, wird die primäre E-Mail-Adresse des Aufrufers möglicherweise aus den Audit-Logs entfernt, es sei denn, der Aufrufer ist ein Dienstkonto.
Zusätzlich zu den oben aufgeführten Bedingungen gilt Folgendes für bestimmte Google Cloud-Dienste:
- Legacy App Engine API: Es werden keine Identitäten erfasst.
BigQuery: Aufruferidentitä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 werden die folgenden Daten entfernt:
Teile der E-Mail-Adressen des Anrufers werden möglicherweise entfernt und durch drei Punkte
...
ersetzt.Einige E-Mail-Adressen von Anrufern, die zur Domain
google.com
gehören, werden entfernt und durchgoogle-internal
ersetzt.
- Organisationsrichtlinie: Teile der E-Mail-Adressen der Anrufer 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 AuditLog
-Objekts gespeichert:
- Bei einem Anrufer 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 die
callerIp
zu „privat“ entfernt. - Bei einem Anrufer von einer Compute Engine-VM mit einer externen IP-Adresse ist
callerIp
die externe Adresse der VM. - Wenn ein Aufrufer von einer Compute Engine-VM ohne externe IP-Adresse aus derselben Organisation oder demselben Projekt wie die aufgerufene Ressource stammt, ist
callerIp
die interne IPv4-Adresse der VM. Andernfalls wird diecallerIp
zu „gce-internal-ip“ geändert. Weitere Informationen finden Sie unter VPC-Netzwerk (Virtual Private Cloud) – Übersicht.
Audit-Logs ansehen
Sie können nach allen Audit-Logs oder nach dem Namen des Audit-Logs abfragen. Der Name des Audit-Logs 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.
Sie können in Ihren Abfragen indexierte LogEntry
-Felder angeben.
Weitere Informationen zum Abfragen von Protokollen finden Sie unter Abfragen im Log-Explorer erstellen.
Im Log-Explorer können Sie einzelne Logeinträge aufrufen und filtern. Wenn Sie Gruppen von Logeinträgen mit SQL analysieren möchten, verwenden Sie die Seite Log Analytics. Weitere Informationen finden Sie unter:
- Logs in Log Analytics abfragen und ansehen
- Beispielabfragen für Sicherheitsinformationen.
- Abfrageergebnisse in Diagrammen darstellen
Die meisten Audit-Logs können in Cloud Logging mithilfe der Google Cloud Console, der Google Cloud CLI oder der 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 Google Cloud-Projekt, Ihren Ordner oder Ihre Organisation abrufen:
-
Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.
Wenn Sie diese Seite über die Suchleiste suchen, wählen Sie das Ergebnis aus, dessen Zwischenüberschrift Logging ist.
Wählen Sie ein vorhandenes Google Cloud-Projekt, einen Ordner oder eine Organisation aus.
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"
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.
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
.
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 ausgewählte Google Cloud-Projekt beziehen.
So können Sie beispielsweise mit der Logging API Ihre Audit-Logeinträge auf Projektebene aufrufen:
Rufen Sie den Abschnitt Diese API testen in der Dokumentation für die Methode
entries.list
auf.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" }
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, jedes Google Cloud-Projekt, jeden Ordner und jede Organisation erstellt Logging automatisch zwei Log-Buckets, _Required
und _Default
, und entsprechend benannte Senken.
Cloud Logging-_Required
-Buckets speichern Audit-Logs zu Administratoraktivitäten und Audit-Logs zu Systemereignissen. Sie können nicht verhindern, dass Audit-Logs zu Administratoraktivitäten oder Systemereignissen gespeichert werden. Außerdem können Sie die Senke nicht konfigurieren, die Logeinträge an die _Required
-Buckets weiterleitet.
Audit-Logs zur Administratoraktivität und zu Systemereignissen werden immer im Bucket _Required
im Projekt gespeichert, in dem die Logs generiert wurden.
Wenn Sie Audit-Logs zur Administratoraktivität und Audit-Logs zu Systemereignissen an ein anderes Projekt weiterleiten, werden diese Logs nicht über den _Default
- oder _Required
-Sink des Zielprojekts geleitet. Daher werden diese Logs nicht im _Default
-Log-Bucket oder im _Required
-Log-Bucket 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.
Die _Default
-Buckets speichern standardmäßig alle aktivierten Audit-Logs zum Datenzugriff sowie zu Richtlinienverstößen. Wenn Sie verhindern möchten, dass Audit-Logs zum Datenzugriff in den _Default
-Buckets gespeichert werden, können Sie sie deaktivieren. Wenn Sie verhindern möchten, dass Audit-Logs zu Richtlinienverstößen in den _Default
-Buckets gespeichert werden, können Sie sie ausschließen. Ändern Sie dazu die Filter der Senken.
Sie können Ihre Audit-Logeinträge auch mithilfe von Senken an benutzerdefinierte Cloud Logging-Buckets auf Google Cloud-Projektebene oder an unterstützte Ziele außerhalb von Logging weiterleiten. 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 Google Cloud-Ordner oder ein Google Cloud-Rechnungskonto finden Sie unter Logs auf Organisationsebene sortieren und an unterstützte Ziele weiterleiten.
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 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
Beim Weiterleiten von Logs an ein unterstütztes Ziel fallen für Cloud Logging keine Gebühren an. Es können aber Gebühren am Ziel erhoben werden.
Mit Ausnahme des _Required
-Log-Buckets fallen in Cloud Logging Kosten für das Streamen von Logs in Log-Buckets und für die Speicherung über die standardmäßige Aufbewahrungsdauer des Log-Buckets hinaus an.
Für das Kopieren von Logs, das Definieren von Log-Bereichen oder das Ausführen von Abfragen über die Seiten Log-Explorer oder Log Analytics fallen in Cloud Logging keine Gebühren an.
Weitere Informationen finden Sie in folgenden Dokumenten:
- Preisübersicht für Cloud Logging
Kosten für Zielvorhaben:
- Gebühren für die Erzeugung von VPC-Flusslogs werden berechnet, wenn Sie Ihre Virtual Private Cloud-Flusslogs senden und dann von Cloud Logging ausschließen.
Nächste Schritte
- Weitere Informationen zum Lesen und Verstehen von Audit-Logs
- Weitere Informationen zum Aktivieren von Audit-Logs zum Datenzugriff
- Beachten Sie die Best Practices für Cloud-Audit-Logs.
- Informationen zu Access Transparency: Mit dieser Funktion erhalten Sie Logs von Aktionen, die Google Cloud-Mitarbeiter beim Zugriff auf Ihre Google Cloud-Inhalte ausgeführt haben.