Diese Seite wurde von der Cloud Translation API übersetzt.

Access Transparency-Logs verstehen und verwenden

Auf dieser Seite werden der Inhalt von Access Transparency-Logeinträgen und um sie anzuzeigen und zu verwenden.

Zugriffstransparenzlogs im Detail

Access Transparency-Logs können in Ihre Security Information and Event Management-Tools (SIEM) zur Automatisierung von Audits von Google-Mitarbeitern, wenn diese auf Ihre Inhalte zugreifen. Access Transparency-Logs sind neben Ihren Cloud-Audit-Logs in der Google Cloud Console verfügbar.

Access Transparency-Logeinträge umfassen folgende Informationen:

Die betroffene Ressource und Aktion
Die Zeit der Aktion
Die Gründe für die Aktion (z. B. die Fallnummer, die mit einer Kundensupportanfrage verknüpft ist)
Daten darüber, wer im Content handelt, z. B. der Standort des Google-Personals.

Zugriffstransparenz aktivieren

Informationen zum Aktivieren der Zugriffstransparenz für Ihre Google Cloud-Organisation finden Sie unter Access Transparency aktivieren.

Zugriffstransparenzlogs ansehen

Nachdem Sie Access Transparency für Google Cloud konfiguriert haben Organisation, können Sie festlegen, wer auf die Access Transparency-Logs zugreifen kann, Einem Nutzer oder einer Gruppe die Rolle Betrachter privater Logs zuweisen Weitere Informationen finden Sie in der Anleitung zur Zugriffssteuerung in Cloud Logging für Details.

Verwenden Sie den folgenden Google Cloud Observability-Logging-Filter, um Access Transparency-Logs aufzurufen.

logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Faccess_transparency"

Informationen zum Abrufen Ihrer Access Transparency-Logs im Log-Explorer finden Sie unter Log-Explorer verwenden.

Sie können die Logs auch mithilfe der Cloud Monitoring API oder von Cloud Run-Funktionen überwachen. Informationen zum Einstieg finden Sie in der Dokumentation zu Cloud Monitoring.

Optional: Erstellen Sie einen logbasierten Messwert und richten Sie dann eine Benachrichtigungsrichtlinie ein, um rechtzeitig auf Probleme aufmerksam zu machen, die von diesen Logs aufgedeckt werden.

Beispiel für einen Access Transparency-Logeintrag

Es folgt ein Beispiel für einen Eintrag im Zugriffstransparenzlog:

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  principalJobTitle: "Engineering"
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: bar123"
    type:  "CUSTOMER_INITIATED_SUPPORT"
  ]
  eventId: "asdfg12345asdfg12345asdfg12345"
  accesses: [
   0: {
    methodName: "GoogleInternal.Read"
    resourceName: "//googleapis.com/storage/buckets/BUCKET_NAME/objects/foo123"
    }
  ]
  accessApprovals: [
   0: "projects/123/approvalRequests/abcdef12345"
  ]
 }
 logName:  "projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Faccess_transparency"
 operation: {
  id:  "12345xyz"
 }
 receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"
 resource: {
  labels: {
   project_id:  "1234567890"
  }
  type:  "project"
 }
 severity:  "NOTICE"
 timestamp:  "2017-12-18T16:06:24.660001Z"
}

Logfeldbeschreibungen

Feld	Beschreibung
`insertId`	Eindeutige Kennzeichnung für das Log
`@type`	Zugriffstransparenzlog-ID
`principalOfficeCountry`	ISO 3166-1: Alpha-2-Code des Landes, in dem die zugreifende Person einen dauerhaften Sitz hat, `??` wenn kein Standort verfügbar ist, oder 3-stellige Kontinent-ID für Google-Mitarbeiter in einem Land mit geringem Bevölkerungsanteil.
`principalEmployingEntity`	Die Entität, die den zugreifenden Google-Mitarbeiter beschäftigt (z. B. `Google LLC`).
`principalPhysicalLocationCountry`	ISO 3166-1 Alpha-2-Code des Landes, aus dem der Zugriff erfolgte, `??` falls kein Standort verfügbar ist oder 3-stellige Kontinent-ID für Google-Mitarbeiter in einem Land mit geringem Bevölkerungsanteil
`principalJobTitle`	Die Berufsgruppe des Google-Mitarbeiters, der den Zugriff ausübt.
`product`	Google Cloud-Produkt des Kunden, auf das zugegriffen wurde.
`reason:detail`	Details zum Grund, z. B. eine Support-Ticket-ID
`reason:type`	Typ des Grundes für den Zugriff, z. B. `CUSTOMER_INITIATED_SUPPORT)`
`accesses:methodName`	Die Art des Zugriffs. Beispiel: `GoogleInternal.Read`. Weitere Informationen zu den Methoden, die im Feld `methodName` erscheinen können, finden Sie unter Werte für das Feld `accesses: methodName`.
`accesses:resourceName`	Name der Ressource, auf die zugegriffen wurde
`accessApprovals`	Enthält die Ressourcennamen von Zugriffsanfragen, für die der Zugriff genehmigt wurde. Diese Anfragen unterliegen Ausschlüsse und unterstützten Diensten. Dieses Feld wird nur ausgefüllt, wenn die Zugriffsgenehmigung für die Ressourcen, auf die zugegriffen wurde. In Access Transparency-Logs, die vor dem 24. März 2021 veröffentlicht wurden, ist dieses Feld leer.
`logName`	Name des Logspeicherorts
`operation:id`	Logcluster-ID
`receiveTimestamp`	Zeitpunkt, zu dem der Zugriff von der Logpipeline empfangen wurde.
`project_id`	Der Ressource zugeordnetes Projekt, auf das zugegriffen wurde.
`type`	Typ der Ressource, auf die zugegriffen wurde (z. B. `project`)
`eventId`	Eindeutige Ereignis-ID, die mit einer einzelnen Begründung für ein Zugriffsereignis verknüpft ist (z. B. ein einzelner Supportfall). Alle Zugriffe, die mit derselben Begründung protokolliert wurden, haben denselben `event_id`-Wert.
`severity`	Logschweregrad
`timestamp`	Zeit, zu der das Log geschrieben wurde

Werte für das Feld „`accesses:methodNames`“

Die folgenden Methoden können im Feld accesses:methodNames in Access Transparency-Logs angezeigt werden:

Standardmethoden: Dazu gehören List, Get, Create, Update und Delete. Weitere Informationen finden Sie unter Standardmethoden.
Benutzerdefinierte Methoden: Benutzerdefinierte Methoden beziehen sich neben den fünf Standardmethoden auf die anderen API-Methoden. Gängige benutzerdefinierte Methoden sind Cancel, BatchGet, Move, Search und Undelete. Weitere Informationen finden Sie unter Benutzerdefinierte Methoden.
Interne Google-Methoden: Die folgenden GoogleInternal-Methoden können im Feld accesses:methodNames angezeigt werden:

Methodenname	Beschreibung	Beispiele
`GoogleInternal.Read`	Gibt eine Leseaktion an, die mit einer gültigen geschäftlichen Begründung auf Kundeninhalte ausgeführt wurde. Die Leseaktion erfolgt mithilfe einer internen API, die speziell für die Verwaltung von Google Cloud-Diensten entwickelt wurde. Kundeninhalte werden mit dieser Methode nicht mutiert.	IAM-Berechtigungen lesen.
`GoogleInternal.Write`	Gibt eine Schreibaktion an, die für Kundeninhalte mit einer gültigen geschäftlichen Begründung ausgeführt wird. Die Schreibaktion erfolgt über eine interne API, die speziell für die Verwaltung von Google Cloud-Diensten entwickelt wurde. Mit dieser Methode können Kundeninhalte und/oder ‐konfigurationen aktualisiert werden.	IAM-Berechtigungen für eine Ressource festlegen Eine Compute Engine-Instanz pausieren
`GoogleInternal.Create`	Gibt eine Erstellungsaktion an, die mit einer gültigen geschäftlichen Begründung auf Kundeninhalte angewendet wurde. Die Erstellung erfolgt über eine interne API, die speziell für die Verwaltung von Google Cloud-Diensten entwickelt wurde. Mit dieser Methode werden neue Kundeninhalte erstellt.	Cloud Storage-Bucket erstellen Pub/Sub-Thema erstellen
`GoogleInternal.Delete`	Zeigt eine Löschaktion an, die mit einer internen API speziell für die Verwaltung von Google Cloud-Diensten für Kundeninhalte ausgeführt wird. Mit dieser Methode werden Kundeninhalte und/oder -konfigurationen geändert.	Löschen eines Cloud Storage-Objekts BigQuery-Tabelle löschen
`GoogleInternal.List`	Gibt eine Listenaktion an, die für Kundeninhalte mit einer gültigen geschäftlichen Begründung ausgeführt wird. Die Listenaktion erfolgt über eine interne API, die speziell für die Verwaltung von Google Cloud-Diensten entwickelt wurde. Bei dieser Methode werden keine Kundeninhalte oder -konfigurationen verändert.	Compute Engine-Instanzen eines Kunden auflisten Dataflow-Jobs eines Kunden auflisten
`GoogleInternal.SSH`	Gibt eine SSH-Aktion an, die mit einer gültigen geschäftlichen Begründung auf der virtuellen Maschine eines Kunden ausgeführt wurde. Der SSH-Zugriff erfolgt über eine interne API, die speziell für die Verwaltung von Google Cloud-Diensten entwickelt wurde. Mit dieser Methode können Kundeninhalte und -konfigurationen geändert werden.	Notfallzugriff zur Wiederherstellung nach einem Ausfall in der Compute Engine oder der Google Distributed Cloud.
`GoogleInternal.Update`	Gibt eine Änderung an, die an Kundeninhalten mit einer gültigen geschäftlichen Begründung vorgenommen wurde. Die Aktualisierung erfolgt über eine interne API, die speziell für die Verwaltung von Google Cloud-Diensten entwickelt wurde. Bei dieser Methode werden Kundeninhalte und/oder -konfigurationen verändert.	HMAC-Schlüssel in Cloud Storage aktualisieren
`GoogleInternal.Get`	Gibt an, dass eine get-Aktion für Kundeninhalte mit einer gültigen geschäftlichen Begründung ausgeführt wird. Die get-Aktion erfolgt mithilfe einer internen API, die speziell für die Verwaltung von Google Cloud-Diensten entwickelt wurde. Kundeninhalte oder -konfigurationen werden mit dieser Methode nicht mutiert.	IAM-Richtlinie für eine Ressource abrufen Abrufen des Dataflow-Jobs eines Kunden
`GoogleInternal.Query`	Gibt eine Abfrageaktion an, die für Kundeninhalte mit einer gültigen geschäftlichen Begründung ausgeführt wird. Die Abfrageaktion erfolgt mithilfe einer internen API, die speziell für die Verwaltung von Google Cloud-Diensten entwickelt wurde. Kundeninhalte oder -konfigurationen werden mit dieser Methode nicht mutiert.	Eine BigQuery-Abfrage ausführen. AI Platform-Debugging-Konsolensuche für Kundeninhalte

Der Zugriff auf GoogleInternal ist streng auf autorisiertes Personal beschränkt, das einen begründeten und überprüfbaren Zugriff hat. Das Vorhandensein einer Methode weist nicht auf die Verfügbarkeit für alle Rollen hin. Organisationen, die erweiterte Kontrollen für den Administratorzugriff auf ein Projekt oder eine Organisation wünschen, können die Zugriffsgenehmigung aktivieren, um Zugriffsberechtigungen basierend auf den Zugriffsdetails zu genehmigen oder abzulehnen. Access Approval-Nutzer können beispielsweise nur Anfragen mit der Begründung CUSTOMER_INITIATED_SUPPORT für Anfragen von Google-Mitarbeitern mit der Rolle Customer Support zulassen. Weitere Informationen finden Sie unter Zugriffsfreigabe.

Wenn ein Ereignis strenge Kriterien für den Notfallzugriff erfüllt, kann die Zugriffsgenehmigung diesen Notfallzugriff mit dem Status auto approved protokollieren. Access Transparency und die Zugriffsgenehmigung sind speziell für die kontinuierliche Protokollierung bei Notfallzugriffen konzipiert.

Wenn Sie mehr Kontrolle über die Datensicherheit Ihrer Arbeitslasten benötigen, empfehlen wir die Verwendung von Assured Workloads. Assured Workloads-Projekte bieten erweiterte Funktionalitäten wie Datenstandort, Datenhoheitskontrolle und Zugriff auf Features wie Confidential Computing in Compute Engine. Dabei werden Begründungen für den Schlüsselzugriff für extern verwaltete Verschlüsselungsschlüssel verwendet.

Begründungscodes

Grund	Beschreibung
`CUSTOMER_INITIATED_SUPPORT`	Durch den Kunden initiierter Support, z. B. "Case Number: ####".
`GOOGLE_INITIATED_SERVICE`	Bezieht sich auf den von Google initiierten Zugriff zur Systemverwaltung und Fehlerbehebung. Google-Mitarbeiter können diese Art von Zugriff folgenden Gründen: Um eine technische Fehlerbehebung für eine komplexe Supportanfrage durchzuführen oder Ermittlungen. Behebung technischer Probleme wie Speicherfehler oder Datenschäden
`THIRD_PARTY_DATA_REQUEST`	Von Google initiierter Zugriff als Reaktion auf ein rechtliches Ersuchen oder ein gerichtliches Verfahren, einschließlich der Beantwortung eines gerichtlichen Verfahrens des Kunden, bei dem Google auf seine eigenen Daten zugreifen muss.
`GOOGLE_INITIATED_REVIEW`	Von Google initiierte Zugriffe im Zusammenhang mit Sicherheitsaspekten, Betrugs-, Missbrauchsfällen oder zu Compliance-Zwecken, einschließlich: Gewährleistung der Sicherheit von Kundenkonten und -daten Bestätigung, ob Daten von einem Ereignis betroffen sind, das sich auf Kontosicherheit (z. B. Malware-Infektion) Bestätigung, ob der Kunde Google-Dienste konform verwendet mit den Google-Nutzungsbedingungen. Prüfung von Beschwerden anderer Nutzer und Kunden oder anderer Hinweise auf missbräuchliche Aktivitäten Prüfen, ob Google-Dienste konsistent mit relevante Compliance-Regelungen (z. B. Geldwäschebekämpfung) Verordnungen.
`GOOGLE_RESPONSE_TO_PRODUCTION_ALERT`	Bezieht sich auf den von Google eingeleiteten Zugriff zur Aufrechterhaltung der Systemzuverlässigkeit. Google-Mitarbeiter können aus folgenden Gründen auf Ihre Daten zugreifen: Prüfung und Bestätigung, dass ein mutmaßlicher Dienstausfall den Kunden nicht betrifft. Sicherung und Wiederherstellung nach Ausfällen und Systemfehlern

Access Transparency-Logs überwachen

Sie können Access Transparency-Logs mithilfe der Cloud Monitoring API überwachen. Informationen zum Einstieg finden Sie in der Cloud Monitoring-Dokumentation.

Sie können einen logbasierten Messwert und dann eine Benachrichtigungsrichtlinie einrichten, um rechtzeitig auf Probleme aufmerksam zu werden, die von diesen Logs aufgedeckt werden. Sie können beispielsweise einen logbasierten Messwert erstellen, der Zugriffe von Google-Mitarbeitern auf Ihre Inhalte erfasst, und dann eine Benachrichtigungsrichtlinie in Monitoring erstellen, die Sie benachrichtigt, wenn die Anzahl der Zugriffe in einem bestimmten Zeitraum einen bestimmten Grenzwert überschreitet.

Nächste Schritte

Informationen zum Aufrufen und Verstehen von Access Transparency-Logs für Google Workspace-Dienste