Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Datensicherheit und Data Governance

Was ist Data Governance?

Dieses Dokument hilft Ihnen, das Konzept der Data Governance zu verstehen, und welche Kontrollen Sie möglicherweise benötigen, um BigQuery-Ressourcen zu sichern.

Einführung

Die Data Governance ist ein wesentlicher Ansatz zur Verwaltung von Daten während ihres Lebenszyklus, von der Erfassung über die Verwendung bis zur Vernichtung. In Ihrem Data Governance-Programm werden Richtlinien, Verfahren, Verantwortlichkeiten und Kontrollen für die Datenaktivitäten klar festgelegt. Mit diesem Programm wird sichergestellt, dass Informationen gemäß den Datenintegritäts- und Sicherheitsanforderungen Ihres Unternehmens gesammelt, verwaltet, verwendet und weitergegeben werden. Außerdem ermöglicht es Ihren Mitarbeitern, Daten leichter zu finden und optimal zu nutzen.

Die Verwaltung und Governance von Daten sollte für jedes Unternehmen von größter Bedeutung sein – von der Aufnahme der Daten bis hin zu deren Nutzung, um wertvolle Einblicke und Informationen zu erhalten.

Wir empfehlen, Ihren Data Governance-Ansatz auf den folgenden drei Schlüsselkomponenten aufzubauen:

  • Ein Framework, das es Menschen ermöglicht, Datenrichtlinien zu definieren, ihnen zuzustimmen und sie durchzusetzen
  • Effektive Prozesse zur Steuerung, Überwachung und Verwaltung aller Datenressourcen in lokalen Systemen, Cloudspeichern und auf Data-Warehouse-Plattformen
  • Die richtigen Tools und Technologien zum Überwachen und Verwalten der Einhaltung von Datenrichtlinien

In den nächsten Abschnitten wird ein Data Governance-Framework vorgestellt, das auf der Gartner-Studie Data Governance Across the Data Lake Reference Architecture basiert. Außerdem werden die Tools und Technologien beschrieben, die diese Implementierung ermöglichen. Im Whitepaper Principles and Best Practices for Data Governance in the Cloud finden Sie eine Erläuterung der Geschäftsanforderungen, die mit Data Governance erfüllt werden, und der Prozesse zur Operationalisierung von Data Governance.

Datenzugriffsverwaltung

Unternehmen haben bisher auf die Perimetersicherheit vertraut, um ihre internen Ressourcen zu schützen. Die Perimetersicherheit, die auch als Eggshell Security oder Castle-and-Moat Security bezeichnet wird, basiert auf der Annahme, dass Bedrohungen nur außerhalb des eigenen Netzwerks bestehen, das Netzwerk selbst jedoch vertrauenswürdig ist. Diese Annahme hat sich als falsch erwiesen – mit kostspieligen Folgen für Unternehmen. Wenn ein Angreifer Zugriff auf das interne Netzwerk erhält, kann er zu anderen Systemen wechseln und wertvolle Datenressourcen nahezu ungehindert entdecken.

Angreifer erhalten Zugriff auf interne Netzwerke durch Sicherheitslücken, von Mitarbeitern installierte Malware, Social Engineering und auf anderen Wegen. Schädliche externe Angreifer, die Lücken im Perimetersicherheitsmodell verursachen, sind jedoch nicht die einzige Bedrohung. Vertrauenswürdige Mitarbeiter können wissentlich oder unwissentlich Daten ändern, löschen oder exfiltrieren, wenn die Ressourcen im internen Netzwerk nicht ordnungsgemäß geschützt sind.

Hinzu kommt, dass die Perimetersicherheit aufgrund der Weiterentwicklung des Unternehmensnetzwerks immer komplexer geworden ist. Ein Perimeter kann beispielsweise in den folgenden Situationen nur schwer erzwungen werden:

  • Wenn Mitarbeiter remote von nicht vertrauenswürdigen Netzwerken aus arbeiten müssen, z. B. an Kundenstandorten, an Flughäfen oder zu Hause
  • Wenn Anbieter, Partner und Auftragnehmer mehr direkten Zugriff auf Ihre Datenressourcen benötigen
  • Wenn sich einige der Unternehmenssysteme jetzt in der Cloud befinden

Wenn Sie ein bestehendes lokales Enterprise Data Warehouse migrieren möchten, ist davon auszugehen, dass Ihr aktueller Ansatz, der Nutzern den Zugriff auf das Abfragen oder Anzeigen von Daten ermöglicht, entweder nicht umfassend genug oder mit einem komplexen und kostenintensiven Verwaltungsaufwand verbunden ist, möglicherweise auch beides. Der Wechsel zu einem Cloud Data Warehouse wie BigQuery bietet Ihnen das gewünschte Maß an Sicherheit und ist für Sie mit einem geringen Wartungsaufwand verbunden, da das Sicherheits-Framework Teil des verwalteten Dienstangebots ist.

Im weiteren Verlauf dieses Dokuments wird erläutert, wie Sie die Datenzugriffsverwaltung in Google Cloud und BigQuery einrichten. Ziel ist es, Ihnen einen Überblick über die Vorteile dieses Sicherheits-Frameworks bei der Migration Ihres Enterprise Data Warehouse zu geben. Dieselben Prinzipien gelten auch, wenn Sie von einer anderen Cloud migrieren oder Ihre BigQuery-Ressourcen von Grund auf neu erstellen.

Ressourcenverwaltung

Beim Einrichten Ihrer Arbeitslasten in Google Cloud müssen Sie die Struktur einhalten, die für alle Ressourcen in Google Cloud gilt, und die spezifischen Richtlinien für die einzelnen Produkte befolgen.

Alle Ressourcen in Google Cloud sind in einer Hierarchie organisiert. Auf der untersten Ebene befinden sich grundlegende Komponenten wie BigQuery-Datasets, Cloud Storage-Buckets und Compute Engine-VMs. Diese untergeordneten Ressourcen werden in logischen Containern, sogenannten Projekten, zusammengefasst. Projekte bilden die Grundlage für die Nutzung aller Google Cloud-Dienste, die Verwaltung der Abrechnung und die Zuweisung von Rollen und Berechtigungen für die Projektressourcen. Projekte werden wiederum in Ordnern gruppiert, die verschiedenen Abteilungen oder Teams innerhalb eines Unternehmens entsprechen können. Ganz oben in der Hierarchie befindet sich der Organisationsknoten, der mehrere Ordner enthält und das Unternehmen darstellt, zu dem er gehört. Weitere Informationen finden Sie in der Dokumentation zur Ressourcenhierarchie.

Aus Sicht von Google Cloud befinden sich BigQuery-Datasets auf der untersten Ebene der Ressourcenhierarchie. Aus BigQuery-Sicht sind Datasets Container auf oberster Ebene, mit denen Sie den Zugriff auf Tabellen und Ansichten organisieren und steuern können. Sie sind im Prinzip vergleichbar mit Datenbanken oder Namespaces in traditionellen OLTP-Umgebungen (Online Transactional Processing) und OLAP-Umgebungen (Online Analytical Processing). Während der Erstellung wählen Sie einen Standort für das Dataset aus. Eine Abfrage kann nur auf Datasets am selben Standort verweisen. Daher ist es wichtig, den Standort zu berücksichtigen, wenn Sie Datasets erstellen und Abfragen entwerfen.

Sicherheitsframework

BeyondCorp von Google ist ein Sicherheitsframework, das auf Zero Trust basiert. In diesem Framework verlangt der Grundsatz dynamischer Zugriffssteuerungen von jedem Nutzer und Gerät Folgendes, um Zugriff auf eine Ressource zu erhalten:

  1. Muss sich mit seinen Anmeldedaten authentifizieren
  2. Muss für den Zugriff auf die jeweilige Ressource berechtigt sein
  3. Muss verschlüsselt kommunizieren

Diese Anforderungen müssen unabhängig vom Standort des Nutzer- oder Gerätenetzwerks erfüllt werden, unabhängig davon, ob dieser sich innerhalb des Firmenintranets, in einem öffentlichen WLAN oder auf einer Ebene befindet.

In den folgenden Abschnitten dieses Artikels werden Konzepte und Best Practices für die Verwaltung des Zugriffs auf Datenressourcen behandelt, einschließlich der in BeyondCorp dargelegten Grundsätze. In diesem Artikel wird auch erläutert, wie Sie einen Sicherheitsperimeter als Schutzmaßnahme gegen Exfiltration implementieren können.

Authentifizierung und Autorisierung

Bei der Authentifizierung wird die Identität eines Clients, der mit BigQuery interagiert, ermittelt und geprüft. Während der Autorisierung wird festgestellt, welche Berechtigungen die authentifizierte Identität für die Interaktion mit BigQuery und den zugehörigen Datasets hat. Mit der Authentifizierung wird also ermittelt, wer Sie sind, und die Autorisierung bestimmt, was Sie tun dürfen.

Identität

In Google Cloud ist Cloud Identity der integrierte Identitätsanbieter. Wenn Sie Ihr lokales Data Warehouse migrieren, sollten Sie Ihren bestehenden Identitätsanbieter (z. B. Microsoft Active Directory) mit Cloud Identity verbinden. Die folgenden Aufgaben können dann weiterhin von Ihrem bisherigen Identitätsanbieter ausgeführt werden:

  • Nutzer und Gruppen bereitstellen und verwalten
  • Einmalanmeldung (SSO) einrichten
  • Multi-Faktor-Authentifizierung konfigurieren

Nutzer von BigQuery können sowohl Personen als auch Anwendungen sein, die über eine BigQuery-Clientbibliothek oder die REST API kommunizieren. Diese Anwendungen müssen sich selbst über ein Dienstkonto identifizieren. Ein Dienstkonto ist eine spezielle Art von Google-Identität, die für einen maschinellen Nutzer steht.

Cloud Identity ist die erste Hälfte eines größeren Produkts, das Identitäts- und Zugriffsverwaltung (IAM) heißt.

Nachdem der Nutzer authentifiziert wurde, müssen Sie noch bestimmen, ob er die erforderlichen Rechte zum Interagieren mit BigQuery und den zugehörigen Datasets hat.

Zugriffsmanagement

Zusätzlich zur Authentifizierung bietet IAM eine zentrale Steuerung für die Autorisierung von Identitäten mit bestimmten Berechtigungen für BigQuery und die zugehörigen Datasets. Mit IAM können Sie die Sicherheitsrichtlinie für BigQuery in der gesamten Organisation verwalten und Zugriff auf Cloudressourcen weit über den Zugriff auf Projektebene hinaus detailliert steuern.

In Cloud IAM bestimmen Berechtigungen die Vorgänge, die für eine Ressource zulässig sind. Sie können diese Berechtigungen jedoch nicht direkt Google-Identitäten (Nutzern, Dienstkonten, Google-Gruppen, G Suite- oder Cloud Identity-Domains) zuweisen. Stattdessen weisen Sie Google-Identitäten Rollen (Sammlungen von Berechtigungen) zu und verwenden eine Richtlinie (in einer JSON- oder YAML-Datei deklariert), um diese Bindungen auf jeder der folgenden Ebenen für Google Cloud-Ressourcen zu erzwingen:

  • Organisation
  • Ordner
  • Projekt
  • Ressourcenebene (BigQuery-Datasets)

BigQuery-Rollen können auf jeder der zuvor aufgeführten Ressourcenebenen gebunden werden. Beispiele:

  • Auf Projektebene kann ein Nutzer die Rolle admin, metadataViewer oder jobUser haben.
  • Auf der BigQuery-Dataset-Ressourcenebene kann ein Nutzer (oder eine Ansicht) die Rolle dataEditor, dataOwner oder dataViewer haben.
IAM für Tabellen und Ansichten

Mit BigQuery können Sie bestimmten Ressourcentypen in Datasets, z. B. Tabellen und Ansichten, Rollen zuweisen, ohne vollständigen Zugriff auf die Ressourcen des Datasets zu gewähren. Berechtigungen auf Tabellenebene bestimmen, welche Nutzer, Gruppen und Dienstkonten auf eine Tabelle oder Ansicht zugreifen können.

Weitere Informationen zur Tabellen- und Lesezugriffssteuerung finden Sie unter Einführung in die Tabellenzugriffssteuerung.

Rollen können nicht auf die folgenden einzelnen Ressourcen angewendet werden: Routinen oder Modelle.

Alternativ können Sie eine autorisierte Ansicht verwenden, um bestimmten Nutzern Zugriff auf Abfrageergebnisse zu gewähren, ohne ihnen Zugriff auf die zugrunde liegenden Tabellen zu geben. Verwenden Sie autorisierte Ansichten, um den Zugriff auf einer niedrigeren Ressourcenebene einzuschränken, wie zum Beispiel auf Tabellen-m Spalten-, Zeilen- oderZellebene. Sicherheit auf Spaltenebene undSicherheit auf Zeilenebene, die beide Arten der Datenklassifizierung sind, werden gegenüber autorisierten Ansichten empfohlen. Ihre Anforderungen und Umstände bestimmen jedoch, welche Methoden am besten verwendet werden können.

IAM für Endpunkte

Mit IAM können Sie die Authentifizierung und Autorisierung basierend auf Identitäten verwalten. Außerdem können Sie damit einen sicheren Perimeter um Dienste mit öffentlichen Endpunkten wie BigQuery erstellen. Weitere Informationen zu dieser Zugriffssteuerungsmethode finden Sie im Abschnitt Netzwerksicherheit.

Implementierungsmethoden

Im Verlauf der Migration kann es erforderlich sein, eine lokale Anwendung mit BigQuery zu verbinden. Beispiele für Fälle, in denen dieser Zugriff erforderlich ist:

  • Lokale Datenpipelines, die Daten in BigQuery laden
  • Lokale Berichterstellung, Analysen oder andere Geschäftsanwendungen, die Daten aus BigQuery abfragen oder extrahieren

Für den Zugriff auf Daten aus BigQuery muss eine Anwendung Anmeldedaten abrufen und zusammen mit API-Anfragen senden. Für die Interaktion mit der BigQuery API über eine lokale Anwendung oder eine andere öffentliche Cloud können entweder kurzlebige oder langlebige Anmeldedaten verwendet werden.

Ein BigQuery-Client muss über ein Dienstkonto oder die Anmeldedaten eines Nutzers authentifiziert werden. Nachdem der Client authentifiziert wurde, muss ein Zugriffstoken oder ein Schlüssel an die BigQuery API übergeben werden. Diese Anmeldedaten werden dann auf ordnungsgemäße Autorisierung geprüft, um sicherzugehen, dass der Client über ausreichende IAM-Berechtigungen für alle Interaktionen mit BigQuery verfügt.

Kurzlebige Anmeldedaten

Kurzlebige Anmeldedaten laufen nach einer kurzen Dauer automatisch ab (maximale Lebensdauer von 1 Stunde für OAuth 2.0 und OpenID sowie 12 Stunden für JWT). Dieser Wert wird bei der Erstellung angegeben. Wenn Sie keine Dienstkontoschlüssel verwalten oder Berechtigungen mit Ablaufdatum für Google Cloud-Dienste erteilen möchten, verwenden Sie kurzlebige Anmeldedaten.

Die folgenden Typen von Anmeldedaten können als kurzlebig angefordert werden:

  • OAuth 2.0-Zugriffstoken
  • OpenID Connect-ID-Token
  • Selbstsignierte JSON Web Tokens (JWTs)
  • Selbstsignierte binäre Objekte (Blobs)

Lokale Dienste können kurzlebige Anmeldedaten verwenden, um ohne Google Cloud Identity mit BigQuery zu kommunizieren. Die kurzlebigen Anmeldedaten müssen zwar von einer Google Cloud Identity abgerufen werden, die Anwendung oder der Dienst, der das Token verwendet, benötigt jedoch keine Google Cloud Identity.

Langlebige Anmeldedaten

Langlebige Anmeldedaten (z. B. private Dienstkontoschlüssel oder OAuth 2.0-Zugriffstokens mit Aktualisierungstokens) ermöglichen den Zugriff auf BigQuery, bis sie entweder gelöscht oder widerrufen werden. Private Dienstkontoschlüssel bleiben bestehen, nachdem sie erstellt wurden, und müssen nicht aktualisiert werden. OAuth 2.0-Zugriffstokens laufen ab, können aber mit einem zugehörigen Aktualisierungstoken als langlebig verwendet werden. Mit diesem Aktualisierungstoken können Sie neue Zugriffstokens anfordern, solange das Aktualisierungstoken aktiv ist. Dabei ist keine neue Authentifizierung erforderlich. Dieser Vorgang wird in OAuth 2.0 Playground von Google veranschaulicht.

Angesichts der langen Lebensdauer sollten Sie langlebige Anmeldedaten auf Remote-Clientcomputern oder Worker-Knoten mit Bedacht verwalten. Es wird empfohlen, langlebige Anmeldedaten an einem sicheren Ort aufzubewahren, bei dem der Zugriff auf autorisierte Nutzer beschränkt ist. Speichern Sie Anmeldedaten niemals in einem Code-Repository: Jeder, der Zugriff auf Ihren Code hat, hat auch Zugriff auf Ihren Schlüssel und damit auf Ihre Daten. Im Fall von gehackten Anmeldedaten können Sie Dienstperimeter verwenden, um das Risiko dieses unerwünschten Zugriffs von außen zu minimieren.

Empfohlene Strategien zum Speichern langlebiger Anmeldedaten:

  • Cloud Storage mit oder ohne Key Management Service (KMS)
  • Sichere lokale Speicherung
  • Drittanbieterlösung zur Verwaltung von Secrets

Der private Schlüssel eines Dienstkontos ist ein kryptografisch signiertes JWT, das zu einem einzelnen Dienstkonto gehört. Das signierte JWT wird direkt als Inhaber-Token verwendet, sodass keine Netzwerkanfrage an den Autorisierungsserver von Google erforderlich ist. Einmal bekannt geworden laufen die Schlüssel nicht automatisch ab, noch werden sie widerrufen. Daher ist es eine für die Sicherheit wichtig, Schlüssel regelmäßig zu rotieren. Dabei müssen Sie einen neuen Schlüssel generieren, dafür sorgen, dass alle autorisierten Nutzer und Dienste Zugriff auf diesen neuen Schlüssel haben, und den alten Schlüssel löschen. Die Schlüsselrotation sorgt dafür, dass der Zugriff eines bekannt gewordenen Schlüssels auf BigQuery automatisch widerrufen wird, selbst wenn das Datenleck nicht erkannt wurde.

Nicht anonyme BigQuery-Anfragen

Sowohl private Dienstkontoschlüssel als auch Aktualisierungstokens unterstützen die Authentifizierung über Dienstkonten. Diese Anfragen sind anonym, da mehrere Nutzer und Anwendungen Zugriff auf dasselbe Dienstkonto haben können und es daher nicht möglich ist, den Nutzer oder die Anwendung zu identifizieren. Viele Unternehmenskunden fordern, dass der Zugriff auf Google Cloud-Ressourcen wie BigQuery dem Nutzer zugeordnet werden kann, der die Anfrage initiiert hat. In diesem Fall können Sie den dreibeinigen OAuth 2.0-Ablauf (3LO) verwenden, um sich im Namen eines Endnutzers anstelle eines Dienstkontos zu authentifizieren.

In einem zweibeinigen Ablauf verfügt die Anwendung direkt über die Anmeldedaten eines Dienstkontos und ruft die BigQuery API im Namen dieses Dienstkontos auf. In einem dreibeinigen Ablauf hingegen gewährt der Ressourceninhaber einem Client Zugriff auf die BigQuery-Ressourcen, ohne die Anmeldedaten direkt freizugeben. Anfragen werden im Namen des Nutzers gestellt. In einigen Fällen ist die Zustimmung des Nutzers erforderlich. Nach der Authentifizierung eines Nutzers kann ein Autorisierungscode gegen ein Zugriffstoken und ein Aktualisierungstoken eingetauscht werden.

Netzwerksicherheit

Ein Virtual Private Cloud-Netzwerk ähnelt einem physischen Netzwerk, ist jedoch in Google Cloud virtualisiert. Firewallregeln werden auf Netzwerkebene definiert, um den Traffic zu und von Ihren VM-Instanzen zu steuern. Sie können jedoch keine Firewallregeln für API-basierte Dienste wie BigQuery oder Cloud Storage definieren. Für diese Arten von Diensten können Sie die VPC Service Controls (Virtual Private Cloud) von Google verwenden, um den Traffic einzuschränken.

Eine VPC definiert Dienstperimeter für Google API-basierte Dienste, die einen öffentlichen Endpunkt wie BigQuery oder Cloud Storage haben. Dienstperimeter verringern das Risiko der Datenexfiltration, indem sie den Ein- und Austritt von Daten zwischen Ressourcen innerhalb des Perimeters und Ressourcen außerhalb des Perimeters einschränken. Wenn diese Steuerelemente richtig implementiert wurden, haben nicht autorisierte Netzwerke keinen Zugriff auf Daten und Dienste. Außerdem wird das Kopieren von Daten in nicht autorisierte Google Cloud-Projekte verhindert. Innerhalb des Perimeters ist eine freie Kommunikation möglich. Über die Grenzen des Perimeters hinaus ist sie jedoch eingeschränkt.

Wir empfehlen, VPC Service Controls zusammen mit der IAM-Zugriffssteuerungen zu verwenden. IAM bietet eine detaillierte identitätsbasierte Zugriffssteuerung. VPC Service Controls ermöglichen eine breitere kontextbasierte Perimetersicherheit.

Kontextsensitive Zugriffssteuerung

API-Anfragen aus dem öffentlichen Internet wird der Zugriff auf Ressourcen, die sich innerhalb eines Dienstperimeters befinden, basierend auf den Zugriffsebenen dieses Perimeters gewährt oder verweigert. Anfragen werden entsprechend dem Clientkontext klassifiziert, wie z. B. IP-Bereiche und Nutzer-/Dienstkontoidentitäten. Wenn beispielsweise eine BigQuery API-Anfrage eingeht, die zwar gültige Anmeldedaten hat, aber aus einem nicht vertrauenswürdigen Netzwerk stammt, wird ihr der Zugriff auf das VPC-Netzwerk und den Dienstperimeter möglicherweise verweigert. Im folgenden Diagramm wird dies veranschaulicht:

Einer BigQuery API-Anfrage, die zwar gültige Anmeldedaten hat, aber aus einem nicht vertrauenswürdigen Netzwerk stammt, kann der Zugriff auf das VPC-Netzwerk und den Dienstperimeter verweigert werden.

Dienstperimeter

VPC-Dienstperimeter werden auf einer Google Cloud-Organisationsebene konfiguriert, sodass Sicherheitsrichtlinien zentral verwaltet werden können. Mehrere Projekte innerhalb dieser Organisation und Dienste (z. B. BigQuery API) können dann jedem Perimeter zugewiesen werden. Projekte und Daten im selben Dienstperimeter können flexibel Daten verarbeiten, transformieren und kopieren – sofern alle diese Aktionen innerhalb des Perimeters erfolgen. Das folgende Diagramm veranschaulicht die Verwendung von Dienstperimetern.

Daten im selben Dienstperimeter verarbeiten, umwandeln und kopieren.

Wenn Google Cloud-Ressourcen in unterschiedlichen Dienstperimetern miteinander kommunizieren müssen (z. B. BigQuery in einem bestimmten Projekt und Dienstperimeter und Compute Engine in einem anderen Projekt), können Sie eine Perimeter-Bridge auf Organisationsebene erstellen. Eine Perimeter-Bridge ermöglicht die Kommunikation zwischen Google Cloud-Ressourcen über mehrere Dienstperimeter hinweg. Ein Projekt kann immer nur einem Dienstperimeter zugeordnet sein; es kann jedoch mehreren Perimeter-Bridges zugehörig sein.

Datenzugriff in hybriden Umgebungen

Bei hybriden lokalen Umgebungen und Cloud-Umgebungen können Sie den privaten Google-Zugriff für lokale Netzwerke konfigurieren, um eine private Kommunikation zwischen dem Dienstperimeter und lokalen Umgebungen zu ermöglichen. Dadurch können lokale Umgebungen auf BigQuery-Datasets zugreifen. Diese Anfragen müssen über eine private Verbindung mit Google Cloud gesendet werden. Dabei kann es sich um ein routenbasiertes VPN oder eine Cloud Interconnect-Verbindung handeln. Anfragen durchlaufen nicht das öffentliche Internet.

Durch diese Konfiguration wird der Dienstperimeter von den lokalen Netzwerken auf Dienste erweitert, die in Google Cloud-Diensten gespeichert sind. Auf diese Weise wird sichergestellt, dass sensible Daten privat bleiben. Unter restricted.googleapis.com können Sie diese Konfiguration der privaten Kommunikation nur für APIs verwenden. Das folgende Diagramm zeigt ein Beispiel für diese Konfiguration:

Den Dienstperimeter von lokalen Netzwerken auf die in Google Cloud-Diensten gespeicherten Daten erweitern.

Verschlüsselung

Wenn Sie die Speicherung und Übertragung von Daten in Google Cloud und BigQuery mit Ihrem lokalen Enterprise Data Warehouse vergleichen, rufen Sie sich noch einmal dieses Sicherheitsframework ins Gedächtnis.

Das Prinzip der dynamischen Zugriffssteuerung von BeyondCorp beruht darauf, dass jeder Zugriff verschlüsselt sein muss. Daher ist es wichtig, die Verschlüsselung als Datenschutzmethode einzuführen, damit Daten selbst im unwahrscheinlichen Fall einer Datenoffenlegung sowohl im inaktiven Zustand als auch während der Übertragung nicht lesbar sind. Durch die Verschlüsselung werden Daten zusätzlich geschützt.

Verschlüsselung inaktiver Daten

Google Cloud verschlüsselt inaktive Daten standardmäßig, ohne dass ein Eingreifen Ihrerseits erforderlich ist. Zum Verschlüsseln inaktiver Daten wird der AES-Algorithmus (Advanced Encryption Standard) verwendet, wie vom National Institute of Standards and Technology empfohlen.

Daten in einem BigQuery-Dataset werden in mehrere Blöcke unterteilt, bevor sie auf ein Laufwerk geschrieben werden. Jeder Block ist mit einem einmaligen Datenverschlüsselungsschlüssel (Data Encryption Key, DEK) verschlüsselt. Durch die Verwendung mehrerer Schlüssel bleibt die Auswirkung eines (unwahrscheinlichen) beschädigten DEKs nur auf diesen Datenblock beschränkt. Diese Schlüssel werden dann mit einmaligen Schlüsselverschlüsselungsschlüsseln (Key Encryption Keys, KEK) verschlüsselt. Verschlüsselte DEKs werden in der Nähe ihrer verknüpften Daten aufbewahrt, KEKs hingegen werden zentral in Cloud Key Management Service (KMS) gespeichert. Diese hierarchische Methode zur Schlüsselverwaltung wird als Umschlagverschlüsselung bezeichnet. Weitere Informationen finden Sie im Artikel "Inaktive Daten in Google Cloud verschlüsseln" im Abschnitt "Schlüsselverwaltung".

Das folgende Diagramm zeigt die Verschlüsselung inaktiver Daten:

Verschlüsselung inaktiver Daten.

Standardmäßig werden alle Schlüssel von Google verwaltet. Sie können die Schlüssel jedoch auch selbst verwalten. Dieses Verfahren wird als vom Kunden verwaltete Verschlüsselungsschlüssel (Customer-Managed Encryption Keys, CMEK) bezeichnet. Dieses Verfahren nutzt Cloud KMS. Mit Cloud KMS können Sie symmetrische Verschlüsselungsschlüssel erstellen, verwenden, rotieren, automatisch rotieren und dauerhaft löschen. Weitere Informationen zur Verwendung von CMEK mit BigQuery finden Sie unter Daten mit Cloud KMS-Schlüsseln schützen.

Verschlüsselung während der Übertragung

In Google Cloud werden alle Daten bei der Übertragung verschlüsselt und authentifiziert, wenn sie sich außerhalb der physischen Grenzen bewegen, die von Google oder im Auftrag von Google kontrolliert werden. Innerhalb dieser Grenzen werden Daten bei der Übertragung im Allgemeinen authentifiziert, aber nicht unbedingt verschlüsselt.

Durch die Verschlüsselung sind Ihre Daten während der Übertragung gegen potenzielle Angreifer geschützt, nachdem eine Verbindung hergestellt und authentifiziert wurde:

  • Es ist nicht mehr erforderlich, den unteren Ebenen des Netzwerks zu vertrauen, die in der Regel von Dritten bereitgestellt werden.
  • Der Zugriff von Angreifern auf Daten wird verhindert, wenn die Kommunikation abgefangen wird.

Auf übergeordneter Ebene erfolgt die Verschlüsselung inaktiver Daten so: Die Daten werden vor der Übertragung verschlüsselt. Daraufhin werden die Endpunkte authentifiziert. Anschließend, wenn die Daten ihr Ziel erreicht haben, werden die Daten entschlüsselt und verifiziert. Die dabei verwendeten Sicherheitsmethoden hängen jedoch vom Typ der Verbindung ab, die gesichert wird. In diesem Abschnitt wird die Verschlüsselung zum Sichern von Verbindungen zu und von BigQuery beschrieben.

BigQuery ist ein Google Cloud-Dienst. Wenn ein Nutzer oder eine Anwendung eine Anfrage sendet, erreicht die Anfrage zuerst ein global verteiltes System namens Google Front End (GFE). GFE beendet Traffic für eingehenden HTTP(S)-, TCP- und TLS-Proxytraffic, bietet Gegenmaßnahmen bei DDoS-Angriffen und leitet den Traffic nach Durchführung eines Load-Balancing an den jeweiligen Dienst weiter.

Beachten Sie, dass für den Traffic zu oder von einem Google Cloud-Dienst möglicherweise zusätzliche Sicherheitsmaßnahmen eingerichtet werden müssen. Diese Maßnahmen sind relevant, wenn Sie Ihre vor- und nachgelagerten Prozesse migrieren. Beispielsweise gibt es mehrere Möglichkeiten, um Anfragen zwischen einem Nutzer oder einer Anwendung an eine auf Google Cloud gehostete benutzerdefinierte Anwendung weiterzuleiten. Im Allgemeinen wird der Traffic bei Verwendung von Cloud Load Balancing über das GFE weitergeleitet; diese Route fällt also in die vorherige Kategorie. Wenn Sie Cloud VPN verwenden, ist die Verbindung durch IPsec geschützt. Wenn Sie hingegen über eine externe IP-Adresse, die Adresse eines Netzwerk-Load-Balancers oder über Cloud Dedicated Interconnect eine direkte Verbindung zu einer VM herstellen, wird die Verbindung standardmäßig nicht verschlüsselt. Daher empfehlen wir dringend, ein Sicherheitsprotokoll wie TLS zu verwenden.

Weitere Informationen dazu, wie Daten auf Google Cloud während der Übertragung verschlüsselt werden, finden Sie unter Verschlüsselung bei der Übertragung in Google Cloud.

Crypto-Deletion

Zusätzlich zur standardmäßig von Google bereitgestellten Verschlüsselung kann Ihre Anwendung bei Bedarf eine eigene Verschlüsselung verwenden, z. B. wenn bestimmte Spalten in einer Tabelle oder Crypto-Deletion maskiert werden müssen.

Crypto-Deletion bzw. Crypto-Shredding ist der Vorgang, der Daten unwiederbringlich löscht, indem der zur Verschlüsselung verwendete Schlüssel gelöscht wird. Da die Daten nicht mehr entschlüsselt werden können, gelten sie als gelöscht.

Da anstelle aller verschlüsselten Daten nur der Schlüssel gelöscht wird, ist diese Löschmethode schnell und dauerhaft; sie wird in der Regel in folgenden Fällen verwendet:

  • Die verschlüsselten Daten sind viel größer als der Schlüssel, z. B. in verschlüsselten Laufwerken, Telefonen oder Datenbankeinträgen.
  • Das Löschen der verschlüsselten Daten ist zu teuer, komplex oder nicht durchführbar, z. B. bei Daten, die über viele Repositories verteilt sind, oder bei nicht änderbaren Speichern.

BigQuery bietet Funktionen zum Erstellen von Schlüsseln und zum Verschlüsseln und Entschlüsseln von Daten in Ihren Abfragen mithilfe der AEAD-Verschlüsselungskonzepte.

Datenerkennung

In Organisationen aller Größen steigen das Datenvolumen, die Vielfalt und die Geschwindigkeit zunehmend an. Diese Datenverbreitung kann mehrere Herausforderungen bedingen, zum Beispiel:

  • Die benötigten Daten sind schwer zu finden, da sie verteilt und nicht organisiert oder über mehrere Daten-Repositories dupliziert sind.
  • Selbst wenn Sie einige Daten finden, ist nicht klar, woher die Daten stammen, ob sie das darstellen, wonach Sie suchen, und ob sie zuverlässig genug sind, um eine Geschäftsentscheidung zu informieren.
  • Die Daten sind schwierig zu verwalten. Es ist unklar, wer der Inhaber eines Datenelements ist, wer Zugriff auf die Daten hat und wie der Zugriff auf die Daten erfolgt.

Metadaten bestehen aus Attributen zur Beschreibung der Daten und helfen bei der Bewältigung der vorhergehenden Herausforderungen. Das Erfassen von Metadaten ist mit dem Erstellen eines Zettelkatalogs für eine Bibliothek vergleichbar, in dem jedes Buch einen Zettel mit Informationen wie Autor, Veröffentlichungsjahr, Ausgabe und Thema hat. Wie bei einem Buch können einem Datenelement Attribute hinzugefügt werden, z. B. Inhaber, Herkunft, Verarbeitungsdatum oder Qualitätsbewertung.

In der Vergangenheit haben Unternehmen Metadaten mithilfe verschiedener Methoden zu erfassen und zu organisieren versucht, darunter Tabellen, Wiki-Seiten, selbst entwickelte Systeme und Software von Drittanbietern. Zu den häufigen Problemen gehören die Notwendigkeit der manuellen Eingabe, Bereinigung und Wartung sowie Systemkompatibilität und Umfang. Ein weiteres Problem besteht darin, dass die Datenerkennung und die Erfassung von Metadaten oftmals organische Prozesse sind, die auf persönlichen Erfahrungen basieren, das von Person zu Person weitergegeben wird. Dieses Wissen ist in einer wachsenden Organisation nicht skalierbar. Ein Analytiker, der keinen Zugang zu diesen persönlichen Erfahrungen hat, kann in diesem Kontext nur schwer Daten erheben, abfragen und analysieren.

Zusätzlich zu diesen internen Herausforderungen müssen Unternehmen immer mehr gesetzliche und Complianceanforderungen erfüllen, wie beispielsweise die EU-Datenschutz-Grundverordnung (DSGVO), die Richtlinie des Basler Ausschusses für Bankenaufsicht 239 (BCBS239) und das US-Gesetz zur Übertragbarkeit von Krankenversicherungen und Verantwortlichkeit von Versicherern (Health Insurance Portability and Accountability Act – HIPAA). Dazu müssen sie ihre Daten nachverfolgen, sichern und in Berichte einbetten.

Die Google Cloud-Antwort auf diese Kundenbedürfnisse ist Data Catalog, ein vollständig verwalteter und skalierbarer Dienst zur Metadatenverwaltung. Mit Data Catalog können Sie Ihre Daten in Google Cloud ermitteln, klassifizieren und analysieren.

Die Data Catalog-Architektur basiert auf folgenden Komponenten:

  • Metadatenspeicher: Auf Cloud Spanner basierende, global verteilte, strikt konsistente Datenbank zum Speichern aller Metadateneinträge
  • Echtzeit- und Batch-Syncers: Für die automatische Aufnahme technischer Metadaten
  • Google-Suchindex: Skalierbares und leistungsfähiges System mit Zugriff auf integrierte Access Control Lists (ACLs), das die gleiche Technologie verwendet, die auch bei Suchvorgängen in Gmail und Google Drive zum Einsatz kommt.

Data Catalog bietet eine einheitliche Ansicht aller Datenressourcen. Daher können Sie Data Catalog als Grundlage für das Erstellen eines soliden Data Governance-Prozesses verwenden.

Das folgende Diagramm zeigt eine vereinfachte Architektur, in der Data Catalog die Metadaten, Suchfunktionen und DLP-Funktionen für BigQuery, Pub/Sub und Cloud Storage bereitstellt. Diese Funktionen werden in späteren Abschnitten erläutert.

Vereinfachte Architektur mit Data Catalog zur Bereitstellung von Metadaten, zur Ermöglichung von Suchvorgängen und zum Schutz vor Datenverlust.

Metadata

Die erfolgreiche Suche nach relevanten Daten für fundierte Entscheidungen steht im Mittelpunkt des Datenerkennungsprozesses. So, wie Sie Metadaten zu verfügbaren Büchern benötigen, um ein Buch in einer Bibliothek zu finden, benötigen Sie auch Metadaten zu Ihren Datenassets, um diese in einer Big-Data-Umgebung zu finden.

Data Catalog kann automatisch Metadaten aus BigQuery, Pub/Sub und Cloud Storage aufnehmen. Dabei wird zwischen zwei verschiedenen Arten von Metadatentypen unterschieden: technische und geschäftliche.

Technische Metadaten enthalten Informationen wie Tabellennamen, Spaltennamen, Beschreibungen und Datum der Erstellung. Diese Art von Metadaten ist bereits im Quellsystem vorhanden. Data Catalog nimmt automatisch technische Metadaten in den Index auf, wenn diese erstellt werden, ohne dass Sie manuell neue Datenressourcen registrieren müssen.

Datenressourcen sind aber auch mit einem impliziten Geschäftskontext verknüpft, beispielsweise, ob eine Spalte personenbezogene Daten enthält, wer der Inhaber der Datenressourcen ist, ein Datum für "Löschen am" oder "Aufbewahren am" sowie einen Datenqualitätsfaktor. Diese Art von Metadaten wird als geschäftliche Metadaten bezeichnet.

Geschäftliche Metadaten sind komplexer als technische Metadaten, da Nutzer in unterschiedlichen Rollen an unterschiedlichen Teilbereichen des Geschäftskontexts interessiert sind. Beispiel: Ein Data Analyst kann am Status eines ETL-Jobs interessiert sein – wurde er erfolgreich ausgeführt, wie viele Zeilen wurden verarbeitet, gab es Fehler oder Warnungen? Ein Produktmanager möchte möglicherweise wissen, ob die Datenklassifizierung öffentlich oder privat ist, wo sich die Daten im Lebenszyklus (Produktion, Test oder QA) befinden, oder ob die Daten Qualitätsdaten und vollständig sind.

Zum Bewältigen dieser Komplexität können Sie in Data Catalog geschäftliche Metadaten in Vorlagen gruppieren. Eine Vorlage ist eine Gruppe von Schlüssel/Wert-Paaren in Form von Metadaten, die als Attribute bezeichnet werden. Ein Satz Vorlagen ist mit einem Datenbankschema für Ihre Metadaten vergleichbar.

Metadatentags sind Instanzen Ihrer Vorlagen, die sowohl auf Tabellen als auch auf Spalten angewendet werden können. Wenn diese Tags auf Spalten angewendet werden, können Nutzer ermitteln, ob eine bestimmte Spalte personenidentifizierbare Informationen enthält, ob die Spalte veraltet ist und welche Formel zur Berechnung einer bestimmten Menge verwendet wurde. Im Wesentlichen stellen geschäftliche Metadaten den notwendigen Kontext für eine sinnvolle Verwendung Ihrer Daten bereit.

Das folgende Diagramm zeigt eine Beispielkundentabelle (cust_tbl) und mehrere Tags geschäftlicher Metadaten, die an die Tabellen und deren Spalten angehängt sind.

Beispiel für eine Kundentabelle.

Neben einer intuitiven Benutzeroberfläche bietet Data Catalog auch eine API für technische Nutzer, um Metadaten in großen Mengen zu annotieren oder abzurufen. Die unterstützten Sprachen sind Python, Java und NodeJS. Mit der API können Sie nicht nur Ihre Metadatenaufgaben skalieren, sondern auch programmatisch in Data Catalog einbinden. Auf diese Weise können Sie benutzerdefinierte Unternehmensanwendungen erstellen, die Data Catalog als Teil ihres Back-Ends verwenden.

Das Hinzufügen von Metadaten zu Datenressourcen bildet die Grundlage für die Datenerkennung, doch dabei bleibt es nicht. Genauso wichtig ist die Fähigkeit, Inhalte mithilfe einer robusten Suchfunktion zu finden, die sowohl technische Metadaten als auch geschäftliche Metadaten verwendet, damit relevante Ergebnisse zurückgegeben werden können.

Data Catalog indexiert alle Metadaten aus den zugehörigen Quellen und stellt sie sowohl über eine nutzerfreundliche UI als auch über eine API bereit, damit sie programmatisch eingebunden werden können. Data Catalog nutzt das Suchformat von Google, bei dem Suchbegriffe mit den Metadaten abgeglichen werden. Für Poweruser steht außerdem die Facettensuche zur Verfügung. Dank der intuitiven Filter und qualifizierten Prädikate der Facettensuche können Nutzer die Ergebnisse eingrenzen. Sie können beispielsweise nur nach Tabellen, Datasets oder Dateien bzw. nur innerhalb eines Projekts, einer Organisation oder eines bestimmten Google Cloud-Produkts suchen.

Auf der Benutzeroberfläche von Data Catalog wird außerdem eine Liste von BigQuery-Tabellen angezeigt, nach denen häufig gesucht wird. Diese Funktionen ermöglichen praktischen Schnellzugriff auf die Tabellendetails, das Schema und die BigQuery-Konsole.

Zugriffssteuerung

Wenn Nutzer die Möglichkeit haben, in Metadaten zu suchen und Datenressourcen zu erkennen, sind sie produktiver, unabhängiger und motivierter. Allerdings sollte nicht jeder Nutzer Zugriff auf jedes Metadatenelement haben. Wenn die richtigen Personen Zugriff auf die richtigen Daten haben, können sich Ihre Mitarbeiter auf diejenigen Datenressourcen konzentrieren, die für ihre Rollen relevant sind. Außerdem hilft dieser Ansatz, die Exfiltration von Metadaten oder Daten zu verhindern.

Data Catalog ist in IAM integriert. Somit können Sie steuern, welche Nutzer Zugriff auf ausgewählte Datenressourcen in ihren Suchvorgängen haben oder geschäftliche Metadaten für die Datenressourcen erstellen.

Bei technischen Metadaten wendet die automatische Aufnahme zur Vereinfachung der Zugriffsverwaltung dieselben Berechtigungen wie auf die getaggten Daten auch auf die Metadaten an. Wenn ein Nutzer Zugriff auf die Daten hat, kann er auch auf die extrahierten technischen Metadaten zugreifen und Datenassets über eine Data Catalog-Suche finden. Bei dieser Methode wird ein sinnvoller Standardwert verwendet, der kein manuelles Eingreifen erfordert. Sie müssen also nicht warten, bis eine Datenressource registriert und ein separater Satz Berechtigungen gewährt wurden.

Bei geschäftlichen Metadaten können Sie selbst definieren, welche Nutzer oder Nutzergruppen Zugriff auf die Metadaten haben. Einige dieser Nutzer haben möglicherweise Zugriff auf Metadaten und Daten, nur auf die Metadaten, nur auf die Daten oder auf keines von beiden.

  • Wenn die Nutzer keinen Zugriff auf die Metadaten haben, können sie die Datenassets nicht über Data Catalog-Suchen finden.
  • Wenn sie Zugriff auf die Metadaten, aber nicht auf die Daten haben, können sie Datenassets zwar finden, die Daten aber nicht lesen. Mit diesem Feature können Nutzer nützliche Datasets ohne Offenlegung der zugrunde liegenden Daten finden. Dadurch wird die Nutzbarkeit der Datenressourcen eines Unternehmens verbessert, ohne die Sicherheit zu gefährden. Nutzer können dann Zugriffsanfragen an die Dateninhaber richten, die je nach geschäftlichem Anwendungsfall, Vertraulichkeit der Daten und anderen Faktoren genehmigt oder verweigert werden können.

In diesem Abschnitt wurde die Einbindung von Data Catalog in IAM erläutert, um die Zugriffssteuerung für Metadaten zu erzwingen. Außerdem können Sie Ihren Nutzern Data Catalog-Rollen gewähren, um den Zugriff auf das Data Catalog-Produkt selbst zu steuern. Verwenden Sie zur Steuerung des Zugriffs auf Datenressourcen eine Kombination aus IAM und VPC Service Controls. Weitere Informationen finden Sie in der Dokumentation zu Data Catalog IAM.

Lineage

Im Kontext von Data Warehouse bezieht sich Lineage auf den Weg, den eine Datenressource von ihrer Herkunft bis zum Ziel zurücklegen muss. Die Herkunft einer Datenressource kann eine externe Quelle sein (beispielsweise von einem Drittanbieter bereitgestellte Marktdaten) oder eine interne Quelle (beispielsweise eine relationale Datenbank, in der Kundentransaktionen gespeichert werden). Das Ziel der Datenressource kann ein Dashboard, ein Bericht oder ein Datenfeed sein, der als API bereitgestellt wird.

In allen diesen Fällen ist zu beachten, dass die am Zielort angezeigten Daten genau die Transformationen widerspiegeln, die auf die Originaldaten angewendet wurden. Dabei ist es wichtig, dass Datennutzer den Daten vertrauen können, die sie erhalten, Aufsichtsbehörden die gemeldeten Daten überprüfen und interpretieren sowie interne Stakeholder Lücken in den Geschäftsprozessen und Zusammenhänge in den Pipelines zur Datenverarbeitung erkennen können.

Welche Daten erfasst werden müssen, hängt vom Umfang des jeweiligen Anwendungsfalls ab. Es können Metadaten wie die ursprüngliche Datenquelle, die Dateninhaber, der Geschäftsprozess, in den die Datenressource umgewandelt wird, oder die Anwendungen und Dienste sein, die an den Transformationen beteiligt sind.

Die manuelle Erfassung dieser Informationen ist fehleranfällig und in nicht trivialen Geschäftsfällen nicht skalierbar. Daher empfehlen wir, Data-Lineage aus einer programmatischen Perspektive zu betrachten:

  • Bestimmen Sie die Metadatenattribute, die Sie erfassen müssen, um die geschäftlichen oder gesetzlichen Anforderungen zu erfüllen.
  • Erstellen Sie Vorlagen, um diese geschäftlichen Metadaten zu erfassen. Data Catalog unterstützt fünf Datentypen, die Sie zum Erstellen von Rich Text-Tags kombinieren können: double, string, boolean, datetime und enum. Dieser letzte Typ kann eine Reihe von benutzerdefinierten Werten verwenden, um eine Phase in der Datentransformation oder ähnliche Aufzählungswerte zu beschreiben.
  • Verwenden Sie die Data Catalog API, um die relevanten Lineage-Metadaten für jeden relevanten Schritt Ihrer Datenpipeline aufzuzeichnen.

Als Alternative zu Data Catalog können Sie Cloud Data Fusion, die von Google verwaltete Version von CDAP, zur Implementierung der Datentransformation verwenden. Cloud Data Fusion fasst die Datenverarbeitungsumgebung in einer einzigen kontrollierten Umgebung zusammen, sodass Lineage automatisch auf Dataset- und Feldebene aufgezeichnet werden kann. Weitere Informationen finden Sie in der Open-Source-CDAP-Dokumentation zu Data-Lineage.

Datenklassifizierung und -verwaltung

In einem Enterprise Data Warehouse können die aufgenommene Datenmenge, Geschwindigkeit und Vielfalt Herausforderungen bei der Datenklassifizierung und -verwaltung darstellen.

Bei der Datenklassifizierung werden Daten anhand ihrer unterschiedlichen Merkmale in Typen, Formulare oder Kategorien unterteilt. Die richtige Klassifizierung der Daten ist für die Anwendung geeigneter Governance-Richtlinien auf verschiedene Datentypen unerlässlich.

Geschäftsdokumente können beispielsweise abhängig von ihrem Inhalt mit einer Vertraulichkeitsstufe wie „ungesichert“ oder „vertraulich“ klassifiziert werden. Für jeden dieser Datentypen können dann spezifische Verwaltungsrichtlinien definiert werden. Vertrauliche Dokumente sind beispielsweise nur für eine bestimmte Gruppe von Nutzern zugänglich und werden sieben Jahre lang aufbewahrt.

Berücksichtigen Sie bei der Datenverwaltung die folgenden Aspekte:

  • Datenänderungen verwalten: Die Auswirkungen von Änderungen an Datendimensionen steuern. Diese Art von Änderungen ist zwar sehr selten, kann aber einen Welleneffekt auslösen, da die in Faktentabellen enthaltenen Daten für die aktualisierten Dimensionen möglicherweise nicht mehr zutreffen.
  • Referenzdaten verwalten: Dafür sorgen, dass alle Systeme in Ihrer Organisation eine präzise und konsistente Ansicht Ihrer Referenzdaten haben.
  • Aufbewahren und löschen: Nutzer am Ändern oder Löschen von Daten hindern und einen automatischen Ablauf von Daten einrichten.

Nutzen Sie bei der Migration zu BigQuery die automatischen Features zur Datenklassifizierung, wie z. B. Cloud Data Loss Prevention (DLP). In den folgenden Abschnitten werden Features und Methoden vorgestellt, mit denen Sie diese Herausforderungen der Datenklassifizierung und -verwaltung in Google Cloud bewältigen können.

Schutz vor Datenverlust

Cloud Data Loss Prevention ist ein Google Cloud-Dienst, der die Data Governance erleichtert, indem Sie damit Ihre Daten klassifizieren können, um den richtigen Nutzern den richtigen Zugriff zu gewähren. Cloud DLP bietet eine Plattform für die Prüfung, Klassifizierung und De-Identifikation von Daten. Es enthält über 150 vordefinierte Detektoren für die Erkennung von Mustern, Formaten und Prüfsummen. Sie können auch benutzerdefinierte Detektoren mithilfe eines Wörterbuchs oder eines regulären Ausdrucks erstellen. Sie können Hotword-Regeln hinzufügen, um die Genauigkeit der Ergebnisse zu erhöhen, und Ausschlussregeln festlegen, um die Anzahl falsch positiver Ergebnisse zu reduzieren.

In diesem Abschnitt werden Cloud DLP-Features beschrieben, mit denen Sie sensible Daten klassifizieren und verschleiern können.

Datenprofil erstellen:

Cloud DLP kann automatisch Profile für BigQuery-Daten generieren, die organisations-, ordner- oder Projektübergreifend sind. Datenprofile enthalten Messwerte und Metadaten zu Ihren Tabellen und helfen Ihnen zu ermitteln, wo sich sensible und hoch riskante Daten befinden. Cloud DLP meldet diese Messwerte auf Projekt-, Dataset-, Tabellen- und Spaltenebene.

Mit der Profilerstellung können Sie mit dem Wachstum von Daten in Ihrem Unternehmen Schritt halten. Standardmäßig erstellt Cloud DLP automatisch Profile neuer Tabellen und aktualisiert die profile von Tabellen mit Schemaaktualisierungen automatisch. Bei Bedarf können Sie die Auswahl der Daten, für die ein Profil erstellt werden soll feinabstimmen, und den Profilerstellung-kadenz feinabstimmen.

Weitere Informationen finden Sie unter Datenprofile für BigQuery-Daten.

Spaltendatenprofile

Einzelne Tabelle prüfen

Die Datenprofilierung verweist Sie auf bestimmte Tabellen und Spalten, die möglicherweise sensible Daten enthalten. Weitere Informationen zu diesen Tabellen erhalten Sie, wenn Sie sie inspizieren. Wenn Sie einen Inspektionsjob für eine einzelne Tabelle ausführen, können Sie Details wie die folgenden abrufen:

  • Anzahl der Ergebnisse
  • Arten der gefundenen vertraulichen Informationen wie E-Mail-Adressen und Kreditkartennummern.
  • Wahrscheinlichkeit, dass ein Ergebnis mit der Art von sensiblen Daten übereinstimmt, nach der Sie suchen.
  • Exakte Speicherort jedes Ergebnisses.
  • Der String, der jedes Ergebnis ausgelöst hat.

Identifizierung von sensiblen Daten aufheben

Cloud DLP bietet eine Reihe von Tools zur De-Identifikation Ihrer Daten, einschließlich Maskierung, Tokenisierung, Pseudonymisierung und Datumsverschiebung.

Daten automatisch taggen

Die DLP API kann Data Catalog-Tags automatisch erstellen, um die sensiblen Daten zu klassifizieren. Sie können diesen Workflow auf Ihre vorhandenen BigQuery-Tabellen, Cloud Storage-Buckets oder auf Datenstreams anwenden.

Die automatische Klassifizierung von Daten in einer Pipeline erleichtern

Cloud DLP scannt Ihre Daten und meldet die Ergebnisse mit einer Wahrscheinlichkeitsstufe. Wenn beispielsweise die Wahrscheinlichkeitsstufe Ihrer Daten hoch ist, können Sie große Datenmengen automatisch verarbeiten. Führen Sie die folgenden Schritte aus, um die Erkennung personenidentifizierbarer Informationen in Ihrer ETL-/ELT-Pipeline zu optimieren:

  1. Nehmen Sie Daten in einen Quarantäne-Bucket auf.
  2. Führen Sie Cloud DLP aus, um personenidentifizierbare Informationen in den Daten zu identifizieren. Dies kann durch Scannen des gesamten Datasets oder durch Sampling der Daten erfolgen. Die DLP API kann aus den Transformationsschritten Ihrer Pipeline oder aus eigenständigen Skripts wie Cloud Functions aufgerufen werden. In der Anleitung Klassifizierung der in Cloud Storage hochgeladenen Daten automatisieren finden Sie ein Beispiel für die Verwendung von Letzterem.
  3. Verschieben Sie die Daten in das Warehouse.

Sicherheit auf Spaltenebene

Basierend auf dem Konzept der Datenklassifizierung bietet BigQuery einen detailierten Zugriff auf sensible Spalten mithilfe von Richtlinien-Tags, einer typbasierten Klassifizierung der Daten. Mit der BigQuery-Sicherheit auf Spaltenebene können Sie Richtlinien erstellen, mit denen zum Zeitpunkt der Abfrage überprüft wird, ob ein Nutzer den entsprechenden Zugriff hat.

Weitere Informationen zur Verwendung von Richtlinien-Tags für die Sicherheit auf Spaltenebene finden Sie unter Einführung in BigQuery-Sicherheit auf Spaltenebene.

Sicherheit auf Zeilenebene

Mit der Sicherheit auf Zeilenebene können Sie Daten filtern und den Zugriff auf bestimmte Zeilen in einer Tabelle anhand bestimmter Nutzerbedingungen ermöglichen. Die Sicherheit auf Zeilenebene erweitert das Prinzip der geringsten Berechtigung. Dazu wird eine detaillierte Zugriffssteuerung für eine Teilmenge der Daten in einer BigQuery-Tabelle mithilfe von Zugriffsrichtlinien auf Zeilenebene aktiviert. Zugriffsrichtlinien auf Zeilenebene können für eine Tabelle mit Sicherheit auf Spaltenebene gleichzeitig vorhanden sein.

Weitere Informationen zur Verwendung von Zeilenzugriffsrichtlinien für die Sicherheit auf Zeilenebene finden Sie unter Einführung in die BigQuery-Sicherheit auf Zeilenebene.

Stammdatenmanagement

Stammdaten, auch als Referenzdaten bezeichnet, sind Daten, die in der gesamten Organisation verwendet werden. Gängige Beispiele für Stammdatenressourcen sind Kunden, Produkte, Lieferanten, Standorte und Konten. Stammdatenmanagement (Master Data Management, MDM) bezieht sich auf eine Reihe von Verfahren, die zur Beibehaltung von Genauigkeit und Konsistenz der Stammdaten in einer Organisation verwendet werden.

Die Genauigkeit und Konsistenz der Daten in einer Organisation sind von entscheidender Bedeutung, damit die einzelnen Abteilungen ordnungsgemäß funktionieren und interagieren können. Andernfalls haben die verschiedenen Abteilungen einer Organisation möglicherweise unterschiedliche Datensätze für dieselbe Entität, was zu kostspieligen Fehlern führen kann. Wenn ein Kunde beispielsweise seine Adresse auf der Unternehmenswebsite aktualisiert und die Rechnungsabteilung aus einem anderen Kunden-Repository liest, gelangen zukünftige Rechnungen nicht mehr zu diesem Kunden.

In MDM wird ein führendes System als "Source of Truth" für bestimmte Stammdatenressourcen verwendet. Im Idealfall beziehen andere Systeme in der Organisation die Stammdaten aus dem führenden System für die jeweilige Stammdatenressource. Dies ist jedoch nicht immer möglich, wie in den folgenden Szenarien zu sehen ist.

Direkte Kommunikation mit dem führenden System

In diesem Szenario kommunizieren die Systeme direkt mit dem führenden System, das für ein bestimmtes Stammdatenobjekt verantwortlich ist. Die Stammdaten werden im führenden System erstellt und aktualisiert. Die anderen Systeme in der Organisation beziehen die Stammdaten aus dem jeweiligen führenden System.

Ein PIM-System (Product Information Management, Produktinformationsmanagement), das im gesamten Unternehmen als führendes System für Produkte verwendet wird.

In diesem Diagramm ist beispielsweise das PIM-System (Product Information Management, Produktinformationsmanagement) das führende System für Produkte im Unternehmen. Wenn andere Systeme, wie beispielsweise das CRM-System (Customer Relationship Management) Stammdaten benötigt, ruft es die Daten aus dem PIM ab. Das CRM-System selbst kann für ein anderes Datenobjekt (z. B. die Kunden des Unternehmens) ebenfalls ein führendes System sein.

Dieses Szenario ist ideal, da die Stammdatenobjekte in ihren jeweiligen führenden Systemen gespeichert bleiben, ohne dass komplexe Transformationspipelines erforderlich sind. Wenn das empfangende System nur eine bestimmte Teilmenge der Stammdaten oder Daten in einem anderen Format benötigt, liegt es in der Verantwortung des Systems, diese zu filtern oder zu konvertieren.

"Golden Copy" aus einer einzigen Quelle

In diesem Szenario kann das empfangende System nicht direkt mit dem führenden System kommunizieren. Für diese Einschränkungen kann es verschiedene Gründe geben:

  • Die Kapazitäten und Verfügbarkeiten dieses Systems sind möglicherweise nicht ausreichend, um alle Anfragen aus der gesamten Organisation verarbeiten zu können.
  • Die Kommunikation zwischen den Systemen kann durch Sicherheitsrichtlinien eingeschränkt oder aufgrund von Einschränkungen der Infrastruktur nicht durchführbar sein.

Mit Ihrem Data Warehouse können Sie diese Einschränkungen überwinden, indem Sie die Stammdaten für empfangende Systeme verfügbar machen. Bei der Migration in die Cloud erhalten Sie von BigQuery ein hochverfügbares Repository, mit dem ein hohes Maß an Gleichzeitigkeit gemäß den IAM-Regeln verarbeitet werden kann. Daher eignet sich BigQuery optimal zum Hosten Ihrer Golden Copy.

Wir empfehlen das Erstellen einer ELT-Datenpipeline, um Stammdaten aus dem führenden System zu lesen, in das Data Warehouse zu laden und dann an die empfangenden Systeme zu verteilen. Wir bevorzugen ELT-Pipelines gegenüber ETL-Pipelines, da verschiedene Endnutzer unterschiedliche Anforderungen an dieselben Stammdaten haben können. Sie können das Asset also zuerst unverändert in das Data Warehouse laden und dann spezielle Transformationen für Nutzer erstellen. In Google Cloud können Sie mit Dataflow Pipelines erstellen, die nativ eine Verbindung zu BigQuery herstellen können. Anschließend können Sie diese Pipelines mithilfe von Cloud Composer orchestrieren.

Das führende System bleibt die zentrale Informationsquelle für den Datenbestand. Dabei werden die in das Data Warehouse kopierten Stammdaten als Golden Copy bezeichnet. Ihr Data Warehouse wird nicht zu einem führenden System.

Das führende System bleibt die "Source of Truth" für die Datenressource.

In diesem Diagramm kann das CRM-System beispielsweise keine Produktdaten direkt über das PIM-System anfragen. Sie erstellen eine ETL-Pipeline, die die Daten aus dem PIM-System extrahiert, in das Data Warehouse kopiert, Transformationen vornimmt und die Daten dann an andere Systeme verteilt; eines davon ist das CRM-System.

Wenn Ihre Systeme Stammdaten in Batches oder für analytische Zwecke abrufen, ist BigQuery der ideale Aufbewahrungsort für die "Golden Copy". Wenn die meisten Zugriffe auf die Stammdaten jedoch über Systeme erfolgen, die einzeilige Suchvorgänge nutzen, sollten Sie ein anderes für diese Bedingungen optimiertes Repository verwenden (z. B. Cloud Bigtable). Sie können auch eine Kombination aus beiden Repositories verwenden. Dabei enthält das Repository mit dem meisten Traffic die "Golden Copy". Wir empfehlen, die Daten immer aus dem System mit der "Golden Copy" zu extrahieren und mit dem anderen Repository zu synchronisieren. Dazu können Sie eine Datenpipeline verwenden.

"Golden Copy" aus mehreren Quellen

In den vorherigen Szenarien wurde ein einziges führendes System für ein bestimmtes Stammdatenobjekt verwendet. In der Praxis können jedoch mehrere Systeme in einer Organisation verwendet werden, um unterschiedliche Merkmale derselben Datenressource vorzuhalten. Beispielsweise kann ein PIM-System die "Source of Truth" für technische und logistische Produktinformationen wie Abmessungen, Gewicht und Herkunft sein. Ein Product Catalog-Managementsystem hingegen könnte die "Source of Truth" für umsatzbezogene Produktinformationen wie Farben, Vertriebskanäle, Preise und Saisonabhängigkeit sein. Es ist auch üblich, verschiedene Systeme mit sich überschneidenden Attributen für dieselbe Datenressource zu verwenden, beispielsweise aus Systemen, die vorher nicht Teil des MDM waren oder durch Akquisitionen und Fusionen in die Organisation eingebunden wurden.

In diesen Fällen ist eine komplexere Pipeline erforderlich, um die Stammdaten aus mehreren Quellen in einer einzigen "Golden Copy" zusammenzuführen, die im Data Warehouse gespeichert wird, wie im folgenden Diagramm dargestellt. Die Daten werden dann ähnlich wie im vorherigen Abschnitt an empfangende Systeme verteilt. Das Data Warehouse ist nach wie vor nicht das führende System, sondern einfach nur ein Repository für die "Golden Copy" der Stammdaten.

Eine komplexe Pipeline, bei der die Stammdaten aus mehreren Quellen zu einer einzigen "Golden Copy" zusammengeführt werden, die im Data Warehouse gespeichert wird.

In Google Cloud können mit Dataflow komplexe Pipelines erstellt werden, die durch einen gerichteten azyklischen Graphen (Directed Acyclic Graph, DAG) dargestellt werden. Diese Pipelines lesen aus mehreren Quellen und schreiben die zusammengeführten Ergebnisse in BigQuery. Eine weitere Option ist die Verwendung eines visuellen Tools wie Cloud Data Fusion zum Erstellen der Pipeline. Cloud Data Fusion bietet auch viele Plug-ins für Datenquellen und Senken.

Sich langsam verändernde Dimensionen

In Dimensionstabellen wird davon ausgegangen, dass sich die Attribute in einem Sternschema oder Schneeflockenschema nie oder nur selten ändern. Attribute, die sich niemals ändern, werden als beständige Attribute bezeichnet. Dazu zählen beispielsweise Geburtsdatum und ursprüngliches Guthaben. Attribute, die sich nur selten ändern, werden der Dimension Sich langsam verändernde Dimensionen (Slowly Changing Dimension, SCD) zugeordnet. Wenn sich eine SCD ändert, müssen sich die in der Faktentabelle enthaltenen Daten auf die vorherige Version der SCD beziehen. Daher benötigen Sie eine Methode, um den Verlauf von SCDs zu speichern.

Berücksichtigen Sie bei der Migration Ihres Data Warehouse die Möglichkeit, eine SCD-Verarbeitungsmethode einzubinden oder vorhandene Methoden zu verbessern:

  • Wenn Sie Ihr Schema in der Schema- und Datenübertragungsphase weiterentwickeln, um SCDs zu berücksichtigen
  • In der Phase der Pipeline-Migration, um den SCD-Verlauf beizubehalten und in reproduzierbarer Weise in Szenarien wie der Neuberechnung von Ausgaben für Backfills, der Neuverarbeitung aufgrund von Logikänderungen und der Verfolgung der Lineage zu verwenden

Herkömmliche SCD-Verarbeitungsmethoden

Die herkömmlichen Methoden zur Handhabung von SCD-Änderungen werden als SCD-Typen 0 bis 6 bezeichnet. Die gängigste Methode ist der SCD-Typ 2, bei dem Verlaufsdaten durch Erstellen zusätzlicher Spalten in der Dimensionstabelle erfasst werden. Die hinzugefügten Spalten sind ein Ersatzschlüssel und einer der folgenden Werte: eine Version, das Start-/Enddatum der Gültigkeit oder ein aktuelles Datum sowie ein Flag, das anzeigt, welche der Zeilen aktuell ist. Weitere Informationen zum Anwenden dieser und anderer Methoden in BigQuery finden Sie unter Änderungen verarbeiten.

Funktionales Data Engineering

Eine weitere Methode zum Verarbeiten von SCDs wurde von Maxime Beauchemin, dem Entwickler von Apache Airflow, im Artikel Functional Data Engineering beschrieben. In diesem Artikel wird ein Paradigma vorgeschlagen, bei dem eine Datenpipeline aus einer Sammlung deterministischer und idempotenter Aufgaben besteht, die in einem DAG organisiert sind, um ihre direktionalen Interdependenzen widerzuspiegeln.

Eine Aufgabe ist deterministisch, wenn ihre Ausgabe nur von ihren Eingaben und nicht von einem lokalen oder globalen Zustand abhängt, also den Konzepten der funktionalen Programmierung folgt. Eine Aufgabe wird als idempotent betrachtet, wenn sie mehrmals mit denselben Eingabeparametern ausgeführt werden kann und immer dieselbe Ausgabe liefert. Dies hat also keine zusätzlichen Nebenwirkungen. (Ein Beispiel hierfür ist der REST PUT-Vorgang.) Die Ausführung einer Aufgabe wird als Instanz der Aufgabe bezeichnet. Aufgabeninstanzen mit unterschiedlichen Eingaben schreiben Daten in verschiedene Partitionen derselben Ausgabetabelle.

Da eine der Eingaben für Aufgaben Dimensionen sind, empfiehlt Beauchemin das Erstellen von Dimensions-Snapshots bei jeder Auslösung eines ETL-Laufs. Ein Dimensions-Snapshot dupliziert alle für den ETL-Lauf erforderlichen Dimensionszeilen zusammen mit einem Zeitstempel. Die Dimensionstabellen werden zu unterschiedlichen Zeiten zu einer Sammlung von Snapshots. Diese Snapshots enthalten den Verlauf der Änderungen an SCDs und ermöglichen das erneute Ausführen einer beliebigen Aufgabeninstanz sowie das Erzielen konsistenter reproduzierbarer Ausgaben.

Diese Methode ist eine Abkehr von der herkömmlichen Verarbeitung von SCDs wie SCD-Typ 2. Mit dieser Methode entfällt die komplexe Verwaltung von Ersatzschlüsseln und zusätzlichen Spalten, wodurch die Entwicklungszeit auf Kosten eines relativ günstigen Speichers reduziert werden kann. Dieser Artikel bestätigt, dass beide Methoden nebeneinander bestehen können.

SCDs in BigQuery verarbeiten

BigQuery unterstützt Stern- und Schneeflockenschemas, einschließlich ihrer Dimensionstabellen. Daher sind die oben beschriebenen Methoden beide anwendbar.

BigQuery geht noch einen Schritt weiter und unterstützt die Denormalisierung von Schemas mit der nativen Unterstützung verschachtelter und wiederholter Felder. Diese Felder können in Faktentabellen verwendet werden, wenn das Attribut zum Zeitpunkt des Ereignisses von Bedeutung ist. Die Felder können auch in Dimensionstabellen verwendet werden, um Verlaufswerte mit einem Typ-2- oder Snapshot-Ansatz nur für die veränderlichen Attribute aufzuzeichnen, nicht für die gesamte Dimensionszeile.

Daten aufbewahren und löschen

In bestimmten Situationen kann es erforderlich sein, Nutzer am Ändern oder Löschen von Daten in BigQuery zu hindern. Um diese Einschränkung zu erzwingen, entfernen Sie die betreffenden Nutzer aus den Rollen mit Berechtigungen, die diese Vorgänge zulassen. Diese Rollen sind roles/bigquery.dataOwner, roles/bigquery.dataEditor und roles/bigquery.admin. Eine weitere Möglichkeit besteht darin, benutzerdefinierte IAM-Rollen zu erstellen, die nicht die spezifischen Berechtigungen zum Bearbeiten und Löschen enthalten.

Wenn Sie Vorschriften für die elektronische Aufbewahrung von Datensätzen erfüllen müssen, empfehlen wir stattdessen, die Daten in Cloud Storage zu exportieren und deren Bucket-Sperre zu verwenden, die Sie bei der Einhaltung bestimmter Aufbewahrungsvorschriften für Aufzeichnungen unterstützen kann.

In anderen Situationen müssen Daten möglicherweise nach einem bestimmten Zeitraum automatisch gelöscht werden. In BigQuery kann ein Ablaufdatum konfiguriert werden, um diese Anforderung zu erfüllen. Sie können das Ablaufdatum auf ein Dataset, eine Tabelle oder bestimmte Tabellenpartitionen anwenden. Nicht benötigte Daten mit einem Ablaufdatum zu versehen, ist eine Möglichkeit der Kostenkontrolle und Speicheroptimierung. Weitere Informationen finden Sie in den Best Practices für BigQuery. Einen umfassenden Überblick über das Löschen von Daten in Google Cloud finden Sie auf dieser Dokumentationsseite.

Wenn ein Google Cloud-Kunde feststellt, dass eine bestimmte Vorschrift auf ihn zutrifft, sollte er selbst eine Complianceprüfung anhand der spezifischen Anforderungen unter Aufsicht seines Rechtsbeistands und der entsprechenden Aufsichtsbehörde vornehmen.

Datenqualitätsmanagement

Das Datenqualitätsmanagement umfasst die folgenden Prozesse:

  • Steuerelemente für die Validierung erstellen
  • Qualitätsüberwachung und -berichte implementieren
  • Verfahren zur Ermittlung des Schweregrads von Vorfällen unterstützen
  • Ursachenanalyse und Empfehlung von Korrekturmaßnahmen bei Datenproblemen ermöglichen
  • Datenvorfälle verfolgen

Unterschiedliche Datennutzer haben möglicherweise unterschiedliche Anforderungen an die Datenqualität. Deshalb ist es wichtig, die Erwartungen an die Datenqualität sowie Techniken und Tools zur Unterstützung des Prozesses zur Datenvalidierung und -überwachung zu dokumentieren. Durch die Implementierung effektiver Prozesse für das Datenqualitätsmanagement können zuverlässige Daten für die Analyse bereitgestellt werden.

Hochwertige Metadaten

Ein Data Warehouse bietet Entscheidungsträgern Zugriff auf eine große Menge an kuratierten Daten. Allerdings sollten nicht alle Daten in einem Data Warehouse gleich behandelt werden:

  • Im Rahmen der Entscheidungsfindung sollten qualitativ hochwertige Daten einen größeren Einfluss auf Ihre Entscheidungen haben. Weniger hochwertige Daten sollten weniger Einfluss haben.
  • Im Rahmen der Datenqualitätsüberwachung können Daten niedriger Qualität verwendet werden, um automatisierte oder manuelle Warnungen zur Überprüfung der Prozesse auszulösen, von denen diese Warnungen erzeugt werden, noch bevor die Daten das Data Warehouse erreichen.

Darüber hinaus können unterschiedliche Bereiche der Organisation unterschiedliche Grenzwerte für die Datenqualität festlegen. Beispielsweise können minderwertige Daten für die Entwicklung und das Testen durchaus geeignet sein, aber für Finanzen oder Compliance als unbrauchbar erachtet werden.

In diesem Abschnitt werden Metadaten als ein Mechanismus dargestellt, mit dem Entscheidungsträger und Prozesse den erforderlichen Kontext zur Bewertung der ihnen bereitgestellten Daten erhalten.

Struktur und Format

Metadaten sind strukturierte Informationen, die zur Qualifizierung an ein Datenelement angehängt werden. Im Kontext der Datenqualität können Sie mithilfe von Metadaten relevante Attribute wie Genauigkeit, Aktualität und Vollständigkeit erfassen.

Die Semantik und die spezifischen Attribute, die in Datenqualitätsmetadaten (DQM) erfasst werden, hängen vom Geschäftskontext ab, für den sie gelten. Wir empfehlen dringend die Verwendung eines Standardsatzes von Attributen im gesamten Unternehmen, um die Kommunikation und Verwaltung zu vereinfachen. Die von Ihnen ausgewählten Attribute können aus Branchenstandards wie dem Datenqualitätsmodell ISO/IEC 25012:2008 oder aus Empfehlungen von professionellen Organisationen wie der DAMA-Community (Data Management) abgeleitet werden.

Das Format, in dem Sie das DQM speichern und Entscheidungsträgern vorlegen, ist ebenfalls ein wichtiger Aspekt. Für unterschiedliche Aufgaben der Entscheidungsfindung können unterschiedliche Formate geeignet sein. Moges, et al. hat beispielsweise die folgende Liste geeigneter Formate für DQM zusammengestellt:

  • N-level Ordinale (Ordinalzahl): Ein endlicher Satz Werte wie "Sehr gut", "Gut" und "Befriedigend"
  • Range (Bereich): Eine numerische Skala mit Unter- und Obergrenzen, wie z. B. 0–100, um das Qualitätsniveau flexibler als bei einer Ordinalzahl darzustellen
  • Probability (Wahrscheinlichkeit): Die Datenqualität auf einer Skala von 0–1, mit der die Wahrscheinlichkeit angegeben wird, dass die Daten korrekt sind
  • Graphical (Grafisch): Visuelle Hinweise wie Farben zur Angabe des Qualitätsniveaus

Hochwertige Metadaten in der Cloud

In der Vergangenheit haben Unternehmen kein konsistentes DQM-Repository verwaltet, sondern sich auf persönliche Erfahrungen verlassen. Dieses Wissen wird manchmal in nicht zusammenhängenden Repositories wie Tabellen, Intranetseiten und Ad-hoc-Datenbanktabellen erfasst. Der mit dem Erkennen, Durchsuchen, Analysieren und Verwalten dieser DQM-Quellen verbundene Aufwand behindert die Zusammenarbeit und überwiegt oftmals dem gewonnenen Nutzen zur Entscheidungsfindung.

Mit Data Catalog können Sie Ihre Metadaten zentral verwalten:

  • Benutzerdefinierte Metadatentags, auch als geschäftliche Metadaten bezeichnet, unterstützen alle Datenqualitätsattribute, die Sie den Standarddefinitionen hinzufügen möchten, und gruppieren diese in logische Vorlagen, die Sie für jeden Geschäftskontext anpassen können.
  • Data Catalog unterstützt benutzerdefinierte Enum-Typen zur Darstellung von Ordinalattributen sowie Doppel- und Zeichenfolgetypen zur Darstellung von Bereichen, Wahrscheinlichkeiten und numerischen Werten, die für verschiedene grafische Darstellungen verwendet werden können. Der Zugriff auf diese Metadatenwerte erfolgt über die Data Catalog-Benutzeroberfläche oder über die zugehörige API und die Clientbibliotheken, mit denen Sie benutzerdefinierte Anwendungen für Ihre Entscheidungsträger erstellen können.
  • Sie können die Data Catalog API in nachgelagerten Prozessen verwenden. Wenn die Datenqualität für eine bestimmte Quelle unterhalb des Schwellenwerts liegt, taggt der Prozess die minderwertigen Daten als solche und löst eine Benachrichtigung aus, bevor die Daten BigQuery erreichen. Die Daten selbst können zur Überprüfung und gegebenenfalls zur Korrektur und Neuverarbeitung in einen Quarantäne-Bucket in Cloud Storage verschoben werden.

Überlegungen zu DQM

Die Annahme liegt nahe, dass Entscheidungsträger ohne DQM dazu tendieren, Daten minderer Qualität zu nutzen und somit schlechtere Entscheidungen treffen. In der Praxis sind Entscheidungsträger oftmals durch den Einsatz von DQM überfordert, da sie große Mengen an Informationen aufnehmen müssen, um Alternativen zu generieren. Wenn Sie zu viele Informationen haben, kann dies sowohl die Aktualität als auch die Qualität von Entscheidungen negativ beeinflussen.

Daher ist es von größter Bedeutung, Entscheidungsträger in Bezug auf die Semantik und Best Practices von DQM zu schulen. Moges et al. empfiehlt die Bereitstellung von DQM und Schulungen für wichtige Aufgaben, bei denen die Verwendung von Daten minderer Qualität negative Auswirkungen hat. DQM kann jedoch kontraproduktiv für Aufgaben sein, die eine hohe Effizienz erfordern, oder wenn das Personal nicht ausreichend geschult ist.

Auditing

Organisationen müssen in der Lage sein, die ordnungsgemäße Funktionsweise ihrer Systeme zu prüfen. Durch Überwachung, Prüfung und Verfolgung können Sicherheitsteams Daten erfassen, Bedrohungen erkennen und auf diese reagieren, bevor sie dem Unternehmen schaden oder zu Verlusten führen. Es ist wichtig, regelmäßige Prüfungen durchzuführen, da hierbei die Effektivität der Kontrollen überprüft wird, um Bedrohungen schnell zu minimieren und den allgemeinen Sicherheitszustand zu bewerten. Prüfungen können auch erforderlich sein, um die Einhaltung der Vorschriften durch externe Prüfer nachzuweisen.

Ein erster Schritt zur Gewährleistung gesunder Datenzugriffskontrollen besteht darin, die mit Ihrem Google Cloud-Projekt und einzelnen BigQuery-Datasets verknüpften Nutzer und Gruppen regelmäßig zu prüfen. Müssen diese Nutzer Inhaber oder Administratoren sein oder wäre eine restriktivere Rolle für ihre Aufgabenbereiche ausreichend? Auch muss geprüft werden, wer die IAM-Richtlinien für Ihre Projekte ändern kann.

Ein zweiter Schritt beim Analysieren von Logs ist die Beantwortung folgender Fragen in Bezug auf BigQuery-Daten und -Metadaten: "Wer hat was, wo und wann gemacht?

  • BigQuery unterstützt standardmäßig zwei unveränderliche Logstreams in Cloud Logging für Ihre Daten: Audit-Logs für die Administratoraktivität und den Datenzugriff.
  • Für Metadaten unterstützt Data Catalog auch beide Audit-Logging-Streams. Im Gegensatz zu BigQuery müssen Logs für den Datenzugriff manuell aktiviert werden.

Logs zu Administratoraktivitäten enthalten Logeinträge für Logaufrufe oder andere Verwaltungsaktionen, mit denen die Konfiguration oder die Metadaten von Ressourcen geändert werden. Neu erstellte Dienstkonten oder Änderungen an IAM-Berechtigungen wie die Erteilung von Lesezugriff auf BigQuery-Datasets für neue Nutzer werden in Logs zur Administratoraktivität aufgezeichnet.

In Logs zum Datenzugriff werden nutzerauthentifizierte API-Aufrufe zum Erstellen, Ändern oder Lesen der von Nutzern bereitgestellten Daten erfasst. In Datenzugriffslogs wird beispielsweise aufgezeichnet, ob ein Nutzer ein BigQuery-Dataset abgefragt oder die Abfrageergebnisse angefordert hat. Das Zuordnen von Abfragen zu einem Nutzer statt zu einem Dienstkonto vereinfacht die Überwachung des Datenzugriffs.

Für beide Logtypen können Sie Cloud Monitoring-Benachrichtigungen erstellen, die unter bestimmten von Ihnen festgelegten Bedingungen ausgelöst werden. Bei Auslösung dieser Benachrichtigungen können Benachrichtigungen über verschiedene Kanäle gesendet werden, darunter E-Mail, SMS, Drittanbieterdienste und sogar Webhooks an eine benutzerdefinierte URL.

Beachten Sie, dass Audit-Logs vertrauliche Informationen enthalten können. Daher müssen Sie den Zugriff auf die Logs möglicherweise einschränken. Der Zugriff auf Audit-Logs kann durch die Verwendung von IAM-Rollen eingeschränkt werden.

Wir empfehlen aus folgenden Gründen, BigQuery-Audit-Logs aus Cloud Logging in ein BigQuery-Dataset zu exportieren:

  • Cloud Logging speichert Audit-Logs nur für einen begrenzten Log-Aufbewahrungszeitraum. Der Export an einen anderen sicheren Speicherort wie BigQuery oder Cloud Storage ermöglicht eine längerfristige Aufbewahrung.
  • In BigQuery können Sie SQL-Abfragen für Logs ausführen, um eine komplexe Filterung für Analysen zu ermöglichen.
  • Darüber hinaus können Sie Dashboards mithilfe von Visualisierungstools wie Looker Studio erstellen.

Weitere Informationen finden Sie im Blogpost Best Practices for Working with Google Cloud Audit Logging.

Nächste Schritte