Richtlinien-Tags für mehrere Standorte verwalten

In diesem Dokument wird beschrieben, wie Sie Richtlinien-Tags für regionale Standorte für die Sicherheit auf Spaltenebene und die dynamische Datenmaskierung in BigQuery verwalten.

BigQuery bietet mithilfe von Richtlinien-Tags eine detaillierte Zugriffssteuerung und eine dynamische Datenmaskierung für vertrauliche Tabellenspalten, die eine typbasierte Klassifizierung von Daten unterstützen.

Nachdem Sie eine Datenklassifizierungs-Taxonomie erstellt und Richtlinien-Tags auf Ihre Daten angewendet haben, können Sie die Richtlinien-Tags für verschiedene Standorte weiter verwalten.

Überlegungen zum Standort

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 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.

Taxonomien für mehrere Standorte verwenden

Sie können eine Taxonomie und ihre Richtlinien-Tag-Definitionen für zusätzliche Standorte kopieren (oder replizieren), ohne manuell eine neue Taxonomie an jedem Ort erstellen zu müssen. Wenn Sie Taxonomien replizieren, können Sie dieselben Richtlinien-Tags für die Sicherheit auf Spaltenebene an mehreren Standorten verwenden und so ihre Verwaltung vereinfachen.

Wenn Sie sie replizieren, behalten die Taxonomie und Richtlinien-Tags an jedem Standort dieselben IDs.

Die Taxonomie und Richtlinien-Tags können noch einmal synchronisiert werden, sodass sie an mehreren Standorten einheitlich sind. Die explizite Replikation einer Taxonomie wird durch einen Aufruf der Data Catalog API erzwungen. Bei zukünftigen Synchronisierungen der replizierten Taxonomie wird derselbe API-Befehl verwendet, mit dem die vorherige Taxonomie überschrieben wird.

Sie können Cloud Scheduler verwenden, um die Synchronisierung der Taxonomie zu vereinfachen, indem Sie die Taxonomie in verschiedenen Regionen regelmäßig synchronisieren. Dabei spielt es keine Rolle, ob es sich um einen festgelegten Zeitplan oder eine manuelle Schaltflächen-Betätigung handelt. Sie müssen ein Dienstkonto einrichten, um Cloud Scheduler verwenden zu können.

Taxonomie an einen neuen Standort replizieren

Erforderliche Berechtigungen

Die Nutzeranmeldedaten oder das Dienstkonto, das die Taxonomie repliziert, müssen die Rolle Administrator von Data Catalog-Richtlinien-Tags haben.

Weitere Informationen zum Gewähren der Rolle Richtlinien-Tag-Administrator finden Sie unter Zugriff mit BigQuery-Sicherheit auf Spaltenebene beschränken.

Weitere Informationen zu IAM-Rollen und Berechtigungen in BigQuery finden Sie unter Vordefinierte Rollen und Berechtigungen.

So replizieren Sie eine Taxonomie standortübergreifend:

API

Rufen Sie die Methode projects.locations.taxonomies.import der Data Catalog API auf. Stellen Sie dabei eine POST-Anfrage und den Namen des Zielprojekts sowie den Standort im HTTP-String bereit.

POST https://datacatalog.googleapis.com/{parent}/taxonomies:import

Der Pfadparameter parent ist das Zielprojekt und der Standort, an den Sie die Taxonomie kopieren möchten. Beispiel: projects/MyProject/locations/eu

Replizierte Taxonomie synchronisieren

Zum Synchronisieren einer Taxonomie, die bereits über mehrere Standorte hinweg repliziert wurde, wiederholen Sie den Data Catalog API-Aufruf wie unter Taxonomie an einen neuen Standort replizieren beschrieben.

Alternativ können Sie ein Dienstkonto und Cloud Scheduler zum Synchronisieren der Taxonomie nach einem festgelegten Zeitplan verwenden. Wenn Sie in Cloud Scheduler ein Dienstkonto einrichten, können Sie auch eine On-Demand-Synchronisierung (nicht geplant) über die Cloud Scheduler-Seite in der Google Cloud Console oder mit der Google Cloud CLI auslösen.

Replizierte Taxonomie mit Cloud Scheduler synchronisieren

Sie benötigen ein Dienstkonto, um eine replizierte Taxonomie standortübergreifend mit Cloud Scheduler zu synchronisieren.

Dienstkonten

Sie können einem vorhandenen Dienstkonto Berechtigungen für die Replikationssynchronisierung erteilen oder ein neues Dienstkonto erstellen.

Informationen zum Erstellen eines neuen Dienstkontos finden Sie unter Dienstkonten erstellen.

Erforderliche Berechtigungen

  1. Das Dienstkonto, das die Taxonomie synchronisiert, muss die Rolle Administrator von Data Catalog-Richtlinien-Tags haben. Weitere Informationen finden Sie unter Rolle "Administrator von Richtlinien-Tags" zuweisen.

  2. Cloud Scheduler API aktivieren

Synchronisierung der Taxonomie mit Cloud Scheduler einrichten

So synchronisieren Sie eine replizierte Taxonomie standortübergreifend mit Cloud Scheduler:

Console

Erstellen Sie zuerst den Synchronisierungsjob und den zugehörigen Zeitplan.

  1. Folgen Sie der Anleitung Job in Cloud Scheduler erstellen.

  2. Geben Sie unter Häufigkeit das Intervall ein, das Sie zwischen automatischen Synchronisierungen wünschen.

  3. Informationen zu Ziel finden Sie in der Anleitung unter Scheduler-Job mit Authentifizierung erstellen.

    Scheduler-Job erstellen (Teil 2)

Fügen Sie als Nächstes die Authentifizierung hinzu, die für die geplante Synchronisierung benötigt wird.

  1. Klicken Sie auf Mehr anzeigen, um die Authentifizierungsfelder aufzurufen.

  2. Wählen Sie für Auth-Header die Option "OAuth-Token hinzufügen" aus.

  3. Fügen Sie die Informationen für Ihr Dienstkonto hinzu.

  4. Geben Sie als Bereich "https://www.googleapis.com/auth/cloud-platform" ein.

  5. Klicken Sie auf Erstellen, um die geplante Synchronisierung zu speichern.

    Scheduler-Job erstellen (Teil 2)

Testen Sie nun, ob der Job ordnungsgemäß konfiguriert ist.

  1. Klicken Sie nach dem Erstellen des Jobs auf Jetzt ausführen, um zu testen, ob der Job ordnungsgemäß konfiguriert wurde. Anschließend löst Cloud Scheduler die HTTP-Anfrage basierend auf dem von Ihnen angegebenen Zeitplan aus.

    Scheduler-Job testen

gcloud

Syntax:

  gcloud scheduler jobs create http "JOB_ID" --schedule="FREQUENCY" --uri="URI" --oath-service-account-email="CLIENT_SERVICE_ACCOUNT_EMAIL" --time-zone="TIME_ZONE" --message-body-from-file="MESSAGE_BODY"

Dabei gilt:

  1. ${JOB_ID} ist ein Name des Jobs. Er muss im Projekt eindeutig sein. Sie können Jobnamen in einem Projekt nicht wiederverwenden, auch wenn Sie den zugehörigen Job gelöscht haben.
  2. ${FREQUENCY} ist der Zeitplan (auch Jobintervall genannt) zur Häufigkeit, mit der der Job ausgeführt werden soll. Beispiel: "alle 3 Stunden". Hier kann jeder beliebige mit Crontab kompatible String angegeben werden. Entwickler, die mit dem alten Cron-Format von App Engine vertraut sind, können alternativ auch die Cron-Syntax von App Engine verwenden.
  3. ${URI} ist die vollständig qualifizierte URL des Endpunkts.
  4. --oauth-service-account-email definiert den Tokentyp. Beachten Sie, dass Google APIs, die auf *.googleapis.com gehostet werden, ein OAuth-Token erwarten.
  5. ${CLIENT_SERVICE_ACCOUNT_EMAIL} ist die E-Mail-Adresse des Clientdienstkontos.
  6. ${MESSAGE_BODY} ist der Pfad zur Datei, die den POST-Anfragetext enthält.

Weitere Optionsparameter sind verfügbar und werden in der Referenz zur Google Cloud CLI beschrieben.

Beispiel:

  gcloud scheduler jobs create http cross_regional_copy_to_eu_scheduler --schedule="0 0 1 * *" --uri="https://datacatalog.googleapis.com/v1/projects/my-project/locations/eu/taxonomies:import" --oauth-service-account-email="policytag-manager-service-acou@my-project.iam.gserviceaccount.com" --time-zone="America/Los_Angeles" --message-body-from-file=request_body.json

Nächste Schritte