Einführung in BigQuery-Sicherheit auf Spaltenebene

BigQuery bietet mithilfe von Richtlinien-Tags oder der typbasierten Klassifizierung von Daten differenzierten Zugriff auf vertrauliche Spalten. 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. Eine Richtlinie kann beispielsweise Zugriffsprüfungen wie die folgende erzwingen:

• Sie müssen sich in group:high-access befinden, um die Spalten zu sehen, die TYPE_SSN enthalten.

Sicherheitsworkflow auf Spaltenebene

So schränken Sie den Datenzugriff auf Spaltenebene ein:

1. Definieren Sie Taxonomie und Datenrichtlinien-Tags. Mit Data Catalog können Sie eine Taxonomie und Richtlinien-Tags für Ihre Daten erstellen und verwalten. Weitere Informationen finden Sie unter Best Practices für Richtlinien-Tags.

2. Weisen Sie Ihren BigQuery-Spalten Richtlinien-Tags zu. Verwenden Sie in BigQuery Schemaanmerkungen, um jeder Spalte, auf die Sie den Zugriff einschränken möchten, ein Richtlinien-Tag zuzuweisen.

3. Verwalten Sie den Zugriff auf die Richtlinien-Tags. Mit IAM-Richtlinien (Identity and Access Management) können Sie den Zugriff auf die einzelnen Richtlinien-Tags einschränken. Die Richtlinie gilt für jede Spalte, die zum Richtlinien-Tag gehört.

Wenn ein Nutzer versucht, zum Abfragezeitpunkt auf Spaltendaten zuzugreifen, überprüft BigQuery anhand des Spaltenrichtlinien-Tags und der zugehörigen Richtlinie, ob der Nutzer berechtigt ist, auf die Daten zuzugreifen.

Hinweis: Die Sicherheit auf Spaltenebene wird neben vorhandenen Dataset-ACLs erzwungen. Ein Nutzer benötigt sowohl Dataset- als auch Richtlinien-Tag-Berechtigungen, um auf Daten zugreifen zu können, die durch die Sicherheit auf Spaltenebene geschützt sind.

Anwendungsbeispiel

Stellen Sie sich eine Organisation vor, die vertrauliche Daten in zwei Kategorien einteilen muss: Hoch und Mittel.

Zum Einrichten der Sicherheit auf Spaltenebene würde eine Datensicherung, die die entsprechenden Berechtigungen hat, die folgenden Schritte ausführen, um eine Hierarchie der Datenklassifizierung einzurichten.

1. Im Datenabgleich wird in Data Catalog eine Taxonomie namens "Geschäftskritisch" erstellt. Diese umfasst die Knoten oder Richtlinien-Tags Hoch und Mittel.

2. Die Richtlinie bestimmt, welche Richtlinie für den Knoten Hoch für die Gruppe high-tier-access übernommen wird.

3. Die Datensicherung erstellt mehr Knotenebenen in der Taxonomie unter Hoch und Mittel. Der niedrigste Knoten ist ein Blattknoten, z. B. der Blattknoten employee_ssn. Die Datensicherung kann für den Blattknoten employee_ssn eine andere Zugriffsrichtlinie erstellen.

4. Durch den Datenabgleich wird ein Richtlinien-Tag bestimmten Tabellenspalten zugewiesen. In diesem Beispiel weist die Datensicherung die Zugriffsrichtlinie High der Spalte employee_ssn in einer Tabelle zu.

5. Auf der Seite Aktuelles Schema der Konsole können den Datennutzer das Richtlinien-Tag sehen, das eine bestimmte Spalte regelt. In diesem Beispiel befindet sich die Spalte employee_ssn unter dem Richtlinien-Tag Hoch. Wenn Sie also das Schema für employee_ssn aufrufen, zeigt die Console den Namen der Taxonomie und das Richtlinien-Tag im Feld Policy tags an: Business criticality:High.

   

   Weitere Informationen zum Festlegen eines Richtlinien-Tags in der Console finden Sie unter Richtlinien-Tag für eine Spalte festlegen.

   Alternativ können Sie das Richtlinien-Tag mit dem Befehl bq update festlegen. Das Feld names von policyTags enthält die ID des Richtlinien-Tags Hoch, projects/project-id/locations/location/taxonomies/taxonomy-id/policyTags/policytag-id:

   [
    ...
    {
      "name": "ssn",
      "type": "STRING",
      "mode": "REQUIRED",
      "policyTags": {
        "names": ["projects/project-id/locations/location/taxonomies/taxonomy-id/policyTags/policytag-id"]
      }
    },
    ...
   ]
   

   Weitere Informationen zum Festlegen eines Richtlinien-Tags mit dem Befehl bq update finden Sie unter Richtlinien-Tag für eine Spalte festlegen.

   Hinweis: Sie können nur ein Richtlinien-Tag pro Spalte zuweisen.

6. Der Administrator führt ähnliche Schritte für das Richtlinien-Tag Mittel aus.

Mit nur wenigen Richtlinien-Tags für die Datenklassifizierung lässt sich so ein detaillierter Zugriff auf viele Spalten verwalten.

Weitere Informationen zu diesen Schritten finden Sie unter Zugriff mit BigQuery-Sicherheit auf Spaltenebene beschränken.

Rollen mit Sicherheit auf Spaltenebene

Die folgenden Data Catalog-Rollen werden für die BigQuery-Sicherheit auf Spaltenebene verwendet.

Rollenname und -ID	Enthaltene Berechtigungen	Gilt für	Beschreibung
Richtlinien-Tag-Administrator
datacatalog.categoryAdmin	datacatalog.categories.getIamPolicy datacatalog.categories.setIamPolicy datacatalog.taxonomies.create datacatalog.taxonomies.delete datacatalog.taxonomies.get datacatalog.taxonomies.getIamPolicy datacatalog.taxonomies.list datacatalog.taxonomies.setIamPolicy datacatalog.taxonomies.update resourcemanager.projects.get resourcemanager.projects.list	Projekt	Diese Rolle hat folgende Berechtigungen: Taxonomien erstellen, lesen, aktualisieren und löschen IAM-Richtlinien für Richtlinien-Tags festlegen In der Regel ist ein Nutzer mit dieser Rolle für das Festlegen von Data Governance-Richtlinien für die Organisation verantwortlich. Wichtiger Hinweis: Diese Rolle beinhaltet nicht die Berechtigung zum Zugriff auf den Inhalt in BigQuery-Spalten, die durch ein Richtlinien-Tag eingeschränkt sind. Projektinhaber können die Rolle Detaillierter Lesezugriff oder anderen Nutzern zuweisen, damit sie eingeschränkte Spalteninhalte sehen können.
Detaillierter Lesezugriff
datacatalog.categoryFineGrainedReader	datacatalog.categories.fineGrainedGet	Richtlinien-Tag	Diese Rolle hat Zugriff auf den Inhalt von BigQuery-Spalten, die durch ein Richtlinien-Tag eingeschränkt sind. In der Regel fragt ein Nutzer mit dieser Rolle die Daten ab.

Weitere Informationen zu Data Catalog-Rollen finden Sie unter Data Catalog Identity and Access Management (IAM).

Schreibvorgänge und ihre Auswirkungen

Zum Lesen der Daten einer Spalte, die durch die Sicherheit auf Spaltenebene geschützt ist, benötigt der Nutzer immer die Leseberechtigung der Richtlinien-Tags für die Spalte, die über den detaillierten Lesezugriff bereit gestellt wird.

Das gilt für:

• Tabellen, einschließlich Platzhaltertabellen
• Ansichten
• Tabellen kopieren

Wenn ein Nutzer Daten in die Zeile einer Spalte schreiben möchte, die durch die Sicherheit auf Spaltenebene geschützt ist, hängt es von der Art des Schreibvorgangs ab, welche Berechtigung er benötigt.

Wenn der Schreibvorgang das Einfügen beinhaltet, ist kein detaillierter Lesezugriff erforderlich. Der Nutzer hat in diesem Fall jedoch keinen Lesezugriff auf die eingefügten Daten, es sei denn, er verfügt über einen detaillierten Lesezugriff.

Wenn der Schreibvorgang ein Aktualisieren, ein Löschen oder ein Zusammenführen umfasst, kann der Nutzer den Vorgang nur ausführen, wenn er detaillierten Lesezugriff hat.

Ein Nutzer kann keine Daten aus lokalen Dateien oder aus Cloud Storage laden, es sei denn, er hat detaillierten Lesezugriff. Ein Nutzer kann jedoch Daten aus Streams laden, da Richtlinien-Tags von den Streaming-Ladevorgängen nicht überprüft werden. Der Nutzer hat keinen Lesezugriff auf Daten, die aus einem Stream geladen wurden, es sei denn, er verfügt über detaillierten Lesezugriff.

Weitere Informationen finden Sie unter Auswirkungen auf Schreibvorgänge mit der BigQuery-Sicherheit auf Spaltenebene.

Tabellen abfragen

Wenn ein Nutzer Zugriff auf Datasets und die Rolle "Detaillierter Lesezugriff für Data Catalog" hat, sind die Spaltendaten für den Nutzer verfügbar. Der Nutzer führt dann wie gewohnt eine Abfrage aus.

Wenn ein Nutzer Zugriff auf Datasets hat, aber nicht die Data Catalog-Rolle "Detaillierter Lesezugriff", sind die Spaltendaten für den Nutzer nicht verfügbar. Wenn ein solcher Nutzer SELECT * ausführt, wird eine Fehlermeldung zurückgegeben, in der die Spalten aufgelistet sind, auf die er nicht zugreifen kann. Diesen Fehler können Sie so beheben:

• Ändern Sie die Abfrage so, dass die Spalten ausgeschlossen sind, auf die der Nutzer nicht zugreifen kann. Wenn der Nutzer beispielsweise keinen Zugriff auf die Spalte ssn, aber Zugriff auf die übrigen Spalten hat, kann er folgende Abfrage ausführen:

  SELECT * EXCEPT (ssn) FROM ...
  

  Im obigen Beispiel wird mit der Klausel EXCEPT die Spalte ssn ausgeschlossen.

• Bitten Sie einen Data Catalog-Administrator, den Nutzer zusammen mit der Data Catalog-Rolle "Detaillierter Lesezugriff" der entsprechenden Datenklasse hinzuzufügen. Die Fehlermeldung enthält den vollständigen Namen des Richtlinien-Tags, für das der Nutzer Zugriffsrechte benötigt.

Ansichten abfragen

Die Auswirkung der Sicherheit auf Spaltenebene im Hinblick auf eine Datenansicht ist unabhängig davon, ob es sich dabei um eine autorisierte Datenansicht handelt. In beiden Fällen wird die Sicherheit auf Spaltenebene transparent erzwungen.

Keine autorisierte Ansicht:

Wenn der Nutzer auf Spaltenebene Zugriff auf die Spalten in den zugrunde liegenden Tabellen der Ansicht hat, kann er die Spalten in der Ansicht abfragen. Andernfalls kann er die Spalten in der Ansicht nicht abfragen.

Autorisierte Ansicht:

Der Zugriff wird nur durch die Sicherheit auf Spaltenebene für die Spalten in den zugrunde liegenden Tabellen der Ansicht gesteuert. IAM-Richtlinien auf Tabellen- und Dataset-Ebene werden nicht zum Prüfen des Zugriffs verwendet. Wenn der Nutzer Zugriff auf die Richtlinien-Tags hat, die in den zugrunde liegenden Tabellen der autorisierten Ansicht verwendet werden, kann er die Spalten in der autorisierten Ansicht abfragen.

Das folgende Diagramm zeigt, wie der Zugriff auf eine Ansicht bewertet und entschieden wird.

Snapshots und ihre Auswirkungen

Mit BigQuery können Nutzer eine Tabelle in einem früheren Zustand abfragen. Mit dieser Funktion können Sie die Zeilen aus einem vorherigen Snapshot der Tabelle abfragen. Außerdem können Sie damit die Tabelle auf das Datum zurücksetzen, an dem der Snapshot erstellt wurde.

In Legacy-SQL fragen Sie einen Snapshot ab, indem Sie Snapshot Decorators für den Tabellennamen verwenden. In Standard-SQL fragen Sie einen Snapshot mit der Klausel FOR SYSTEM_TIME AS OF für die Tabelle ab.

Für die Abfrage eines Snapshots gilt das jeweils aktuellste Zeitlimit aus dieser Auswahl:

• Die vergangenen 7 Tage
• Die Erstellungszeit der Tabelle

Sie können eine frühere Tabelle nicht abfragen, wenn die Tabelle gelöscht und mit dem gleichen Tabellennamen neu erstellt wurde.

Nachfolgend wird gezeigt, wie Snapshots mit der Sicherheit auf Spaltenebene funktionieren. Es wird davon ausgegangen, dass folgende Voraussetzungen vorliegen:

• Sie haben einen Ursprungspunkt, der eine vorhandene Tabelle zum aktuellen Zeitpunkt ist.

• Sie haben einen Snapshot derselben Tabelle.

• Das Schema des Snapshots ist identisch mit dem Schema des Ursprungs oder ist ein Teil davon. Das heißt, dass alle Spalten des Snapshots im Ursprung enthalten sind.

Diese Annahmen vorausgesetzt, stimmen die geprüften Berechtigungen mit der neuesten Sicherheit auf Spaltenebene für die ursprüngliche (aktuelle) Tabelle überein. Wenn der Nutzer die aktuellen Spalten lesen darf, kann er einen Snapshot dieser Spalten abfragen.

Wenn sich das Schema des Ursprungs und des Snapshots für die Spalten in der Abfrage unterscheiden, schlägt eine Anfrage zum Abrufen eines Snapshots fehl.

Überlegungen zum Standort

Beachten Sie die folgenden Einschränkungen, wenn Sie einen Standort für Ihre Taxonomie auswählen.

Richtlinien-Tags

Taxonomien sind regionale Ressourcen wie BigQuery-Datasets und -Tabellen. Wenn Sie eine Taxonomie erstellen, geben Sie die Region oder den Standort für die Taxonomie an.

Sie können eine Taxonomie erstellen und Richtlinien-Tags auf Tabellen in allen Regionen anwenden, in denen BigQuery verfügbar ist. Wenn Sie jedoch Richtlinien-Tags aus einer Taxonomie auf eine Tabellenspalte anwenden möchten, muss sich die Taxonomie selbst und die Tabelle am selben regionalen Standort befinden.

Sie können zwar kein Richtlinien-Tag auf eine Tabellenspalte anwenden, die sich an einem anderen Standort befindet, aber Sie können die Taxonomie an einen anderen Standort kopieren, indem Sie sie dort explizit replizieren.

Wenn Sie dieselbe Taxonomie und Richtlinien-Tags für mehrere regionale Standorte verwenden möchten, finden Sie weitere Informationen zum Replizieren von Taxonomien unter Richtlinien für verschiedene Standorte verwalten.

Organisationen

Referenzen können nicht organisationsübergreifend verwendet werden. Eine Tabelle und alle Richtlinien-Tags, die Sie auf Spalten anwenden möchten, müssen in derselben Organisation vorhanden sein.

Beschränkungen

• Wenn Sie in eine Zieltabelle überschreiben, werden alle vorhandenen Richtlinien-Tags aus der Tabelle entfernt, es sei denn, Sie verwenden das Flag --destination_schema, um ein Schema mit Richtlinien-Tags anzugeben. Das folgende Beispiel zeigt, wie --destination_schema verwendet wird.

  bq query --destination_table mydataset.mytable2 \
    --use_legacy_sql=false --destination_schema=schema.json \
    'SELECT * FROM mydataset.mytable1'
  

• Eine Spalte kann nur ein Richtlinien-Tag haben.

• Eine Tabelle kann höchstens 1.000 einzelne Richtlinien-Tags enthalten.

• Sie können Legacy-SQL nicht verwenden, wenn Sie die Sicherheit auf Spaltenebene aktiviert haben. Alle Legacy-SQL-Abfragen werden abgelehnt, wenn die Zieltabellen Richtlinien-Tags enthalten.

Preise

Für die Sicherheit auf Spaltenebene ist sowohl BigQuery als auch Data Catalog erforderlich.Preisinformationen zu diesen Produkten finden Sie in den folgenden Themen:

• BigQuery-Preise
• Data Catalog-Preise

Audit-Logging

Wenn Tabellendaten mit Richtlinien-Tags gelesen werden, speichern wir die referenzierten Richtlinien-Tags in Cloud Logging. Die Prüfung der Richtlinien-Tags ist jedoch nicht mit der Abfrage verknüpft, die die Prüfung ausgelöst hat.

Mit Cloud Logging können Prüfer nachvollziehen, wer welche Art von Zugriff auf welche Kategorien sensibler Daten hat. Weitere Informationen finden Sie unter Richtlinien-Tags prüfen.

Weitere Informationen zum Logging in BigQuery finden Sie unter Einführung in BigQuery-Monitoring.

Weitere Informationen zum Logging in Google Cloud finden Sie unter Cloud Logging.

Nächste Schritte

• Weitere Informationen zur Verwendung der Sicherheit auf Spaltenebene finden Sie unter Zugriff mit BigQuery-Sicherheit auf Spaltenebene beschränken.

• Informationen zu Best Practices für Richtlinien-Tags finden Sie unter BigQuery: Best Practices für die Verwendung von Richtlinien-Tags.