Access Transparency-Logs verstehen und verwenden

Auf dieser Seite werden der Inhalt von Access Transparency-Logeinträgen und deren Aufruf und Verwendung beschrieben.

Zugriffstransparenzlogs im Detail

Access Transparency-Logs können in Ihre vorhandenen SIEM-Tools (Security Information and Event Management) eingebunden werden, um Ihre Audits von Google-Mitarbeitern zu automatisieren, wenn diese auf Ihre Inhalte zugreifen. Access Transparency-Logs sind in der Google Cloud Console zusammen mit Ihren Cloud-Audit-Logs 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 von Access Transparency für Ihre Google Cloud-Organisation finden Sie unter Access Transparency aktivieren.

Zugriffstransparenzlogs ansehen

Nachdem Sie Access Transparency für Ihre Google Cloud-Organisation konfiguriert haben, können Sie steuern, wer auf die Access Transparency-Logs zugreifen kann. Dazu weisen Sie einem Nutzer oder einer Gruppe die Rolle Betrachter privater Logs zu. Weitere Informationen finden Sie in der Anleitung für die Cloud Logging-Zugriffssteuerung.

Verwenden Sie den folgenden Google Cloud-Logging-Filter für die Beobachtbarkeit, 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 mit Cloud Functions ü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.

Beispieleintrag im Access Transparency-Log

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 Jobfamilie der Google-Mitarbeiter, die den Zugriff vornehmen.
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 angezeigt werden 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 Access Approval-Anfragen, die den Zugriff genehmigt haben. Diese Anfragen unterliegen Ausschlüssen und unterstützten Diensten.

Dieses Feld wird nur gefüllt, wenn die Zugriffsgenehmigung für die Ressourcen aktiviert ist, auf die zugegriffen wird. Dieses Feld wird in Access Transparency-Logs, die vor dem 24. März 2021 veröffentlicht wurden, nicht ausgefüllt.
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 Begründung für ein Zugriffsereignis verknüpft ist (z. B. eine einzelne Supportanfrage). Alle Zugriffe, die mit derselben Begründung protokolliert werden, 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: Diese Methoden sind List, Get, Create, Update und Delete. Weitere Informationen finden Sie unter Standardmethoden.
  • Benutzerdefinierte Methoden: Benutzerdefinierte Methoden beziehen sich neben den fünf Standardmethoden auch auf andere API-Methoden. Zu den gängigen benutzerdefinierten Methoden gehören Cancel, BatchGet, Move, Search und Undelete. Weitere Informationen finden Sie unter Benutzerdefinierte Methoden.
  • GoogleInternal-Methoden: Die folgenden GoogleInternal-Methoden können im Feld accesses:methodNames angezeigt werden:
Methodenname Beschreibung Beispiele
GoogleInternal.Read Gibt eine Leseaktion an, die für Kundeninhalte mit einer gültigen geschäftlichen Begründung ausgeführt wurde. Die Leseaktion erfolgt über eine interne API, die speziell für die Verwaltung von Google Cloud-Diensten entwickelt wurde. Mit dieser Methode werden keine Änderungen an Kundeninhalten vorgenommen. IAM-Berechtigungen werden gelesen.
GoogleInternal.Write Gibt eine Schreibaktion an, die für Kundeninhalte mit einer gültigen geschäftlichen Begründung ausgeführt wurde. Die Schreibaktion erfolgt mit einer internen 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
  • Compute Engine-Instanz anhalten
GoogleInternal.Create Bezeichnet eine Erstellungsaktion, die für Kundeninhalte mit einer gültigen geschäftlichen Begründung ausgeführt wurde. Die Erstellung erfolgt mit einer internen 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 Bezeichnet eine Löschaktion, die für Kundeninhalte mithilfe einer internen API ausgeführt wird, die speziell für die Verwaltung von Google Cloud-Diensten entwickelt wurde. Mit dieser Methode lassen sich Kundeninhalte und/oder Konfigurationen ändern.
  • Cloud Storage-Objekt löschen
  • Eine BigQuery-Tabelle löschen.
GoogleInternal.List Eine Listenaktion, die für Kundeninhalte mit einer gültigen geschäftlichen Begründung ausgeführt wurde. Die Listenaktion erfolgt über eine interne API, die speziell für die Verwaltung von Google Cloud-Diensten entwickelt wurde. Mit dieser Methode werden keine Änderungen an Kundeninhalten oder Konfigurationen vorgenommen.
  • Compute Engine-Instanzen eines Kunden auflisten.
  • Dataflow-Jobs eines Kunden auflisten.
GoogleInternal.SSH Bezeichnet eine SSH-Aktion, die auf der virtuellen Maschine eines Kunden mit einer gültigen geschäftlichen Begründung 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 lassen sich Kundeninhalte und Konfigurationen ändern. Notfallzugriff zur Wiederherstellung nach einem Ausfall in Compute Engine oder GKE on VMware.
GoogleInternal.Update Bezeichnet eine Änderung, die an Kundeninhalten mit einer gültigen geschäftlichen Begründung vorgenommen wurde. Die Aktualisierung erfolgt mithilfe einer internen API, die speziell für die Verwaltung von Google Cloud-Diensten entwickelt wurde. Mit dieser Methode lassen sich Kundeninhalte und/oder Konfigurationen ändern. HMAC-Schlüssel in Cloud Storage aktualisieren
GoogleInternal.Get Gibt eine Abrufaktion für Kundeninhalte mit einer gültigen geschäftlichen Begründung an. Die get-Aktion wird mit einer internen API ausgeführt, die speziell für die Verwaltung von Google Cloud-Diensten entwickelt wurde. Mit dieser Methode werden keine Änderungen an Kundeninhalten oder Konfigurationen vorgenommen.
  • IAM-Richtlinie für eine Ressource abrufen.
  • Dataflow-Job eines Kunden abrufen
GoogleInternal.Query Bezeichnet eine Abfrageaktion, die für Kundeninhalte mit einer gültigen geschäftlichen Begründung ausgeführt wurde. Die Abfrageaktion erfolgt mit einer internen API, die speziell für die Verwaltung von Google Cloud-Diensten entwickelt wurde. Mit dieser Methode werden keine Änderungen an Kundeninhalten oder Konfigurationen vorgenommen.
  • BigQuery-Abfrage ausführen
  • Lookup von Kundeninhalten in der AI Platform-Debugging-Konsole

Die GoogleInternal-Zugriffe sind für berechtigte und prüfbare Zugriffe streng auf autorisierte Mitarbeiter beschränkt. Das Vorhandensein einer Methode zeigt nicht die Verfügbarkeit für alle Rollen an. Organisationen, die erweiterte Kontrollen für den Administratorzugriff auf ein Projekt oder eine Organisation wünschen, können die Zugriffsgenehmigung aktivieren, um Zugriffe basierend auf den Details genehmigen oder ablehnen zu können. Nutzer von Access Approval können beispielsweise nur Anfragen mit der Begründung CUSTOMER_INITIATED_SUPPORT für Anfragen zulassen, die von Google-Mitarbeitern mit der Rolle Customer Support gestellt wurden. Weitere Informationen finden Sie unter Übersicht über die Zugriffsgenehmigung.

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 Access Approval wurden speziell dafür entwickelt, eine unterbrechungsfreie Protokollierung für Notfallzugriffsszenarien zu ermöglichen.

Wenn Sie mehr Kontrolle über die Datensicherheit für Ihre Arbeitslasten haben möchten, empfehlen wir die Verwendung von Assured Workloads. Assured Workloads-Projekte bieten erweiterte Funktionen wie Datenstandort, Datenhoheitskontrollen und Zugriff auf Features wie Confidential Computing in Compute Engine. Dabei werden Key Access Justifications für extern verwaltete Verschlüsselungsschlüssel genutzt.

Begründungscodes

Grund Beschreibung
CUSTOMER_INITIATED_SUPPORT Vom Kunden eingeleitete Supportanfrage, z. B. „Fallnummer: ####“.
GOOGLE_INITIATED_SERVICE

Bezieht sich auf den von Google initiierten Zugriff zur Systemverwaltung und Fehlerbehebung. Google-Mitarbeiter können diese Art von Zugriff aus folgenden Gründen vornehmen:

  • Zur Durchführung der technischen Fehlerbehebung, die für eine komplexe Supportanfrage oder Prüfung erforderlich ist
  • Zur Behebung technischer Probleme wie Speicherfehler oder Datenschäden.
THIRD_PARTY_DATA_REQUEST Von Google eingeleitete Zugriffe als Reaktion auf ein rechtliches Ersuchen oder ein gerichtliches Verfahren, auch wenn auf ein gerichtliches Verfahren des Kunden reagiert wird, bei dem Google auf die eigenen Daten des Kunden zugreifen muss
GOOGLE_INITIATED_REVIEW Von Google eingeleitete Zugriffe im Zusammenhang mit Sicherheitsaspekten, Betrugs- und Missbrauchsfällen oder zu Compliance-Zwecken, einschließlich:
  • Gewährleistung der Sicherheit von Kundenkonten und Kundendaten
  • Bestätigung, ob Daten von einem Ereignis betroffen sind, das die Kontosicherheit beeinträchtigen könnte (z. B. Malware-Infektionen)
  • Bestätigung, ob der Kunde Google-Dienste gemäß den Google-Nutzungsbedingungen verwendet.
  • Prüfung von Beschwerden anderer Nutzer und Kunden oder anderer Hinweise auf missbräuchliche Aktivitäten
  • Überprüfung, ob Google-Dienste in Übereinstimmung mit relevanten Compliance-Regelungen (z. B. Anti-Geldwäsche-Bestimmungen) verwendet werden.
GOOGLE_RESPONSE_TO_PRODUCTION_ALERT

Bezieht sich auf einen von Google initiierten Zugriff zur Aufrechterhaltung der Systemzuverlässigkeit. Google-Mitarbeiter können diese Art von Zugriff aus folgenden Gründen vornehmen:

  • Untersuchung und Bestätigung, dass ein vermuteter Dienstausfall keine Auswirkungen auf den Kunden hat.
  • Um die Sicherung und Wiederherstellung nach Ausfällen und Systemausfällen sicherzustellen.

Access Transparency-Logs überwachen

Mit der Cloud Monitoring API können Sie Access Transparency-Logs ü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 machen, 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 in Monitoring eine Benachrichtigungsrichtlinie erstellen, die Sie darüber informiert, ob die Anzahl der Zugriffe in einem bestimmten Zeitraum einen bestimmten Grenzwert überschreitet.

Nächste Schritte