Probleme mit der Zugriffssteuerung beheben

In diesem Dokument wird beschrieben, wie Sie Sicherheitsprobleme mit IAM-Berechtigungen (Identity and Access Management), der Zugriffssteuerung auf Spaltenebene und kundenverwalteten Verschlüsselungsschlüsseln (CMEK) in BigQuery beheben. Probleme mit IAM-Berechtigungen führen in der Regel zu Access Denied-Fehlern wie den folgenden:

  • Access Denied: Project PROJECT_ID: User does not have bigquery.jobs.create permission in project PROJECT_ID.
  • Access Denied: Project PROJECT_ID: User does not have bigquery.datasets.get permission on dataset DATASET.
  • User does not have permission to query table PROJECT_ID:DATASET.TABLE.
  • Access Denied: Table PROJECT_ID:DATASET.TABLE: User does not have permission to query table PROJECT_ID:DATASET.TABLE, or perhaps it does not exist.
  • Access Denied: User PRINCIPAL does not have permission to perform bigquery.tables.getData on resource 'projects/PROJECT_ID/datasets/DATASET/tables/TABLE'.

Hinweis

Informationen zum Problem sammeln

Der erste Schritt bei der Fehlerbehebung eines Problems mit dem Ressourcenzugriff besteht darin, die fehlende Berechtigung, das IAM-Hauptkonto, dem der Zugriff verweigert wurde, und die Ressource, auf die das Hauptkonto zugreifen wollte, zu ermitteln.

Informationen aus dem Fehler- oder Jobverlauf abrufen

Informationen zum Hauptkonto, zur Ressource und zu den Berechtigungen finden Sie in der Ausgabe des bq-Befehlszeilentools, in der API-Antwort oder in BigQuery in der Cloud de Confiance Console.

Wenn Sie beispielsweise versuchen, eine Abfrage mit unzureichenden Berechtigungen auszuführen, wird auf dem Tab Jobinformationen im Abschnitt Abfrageergebnisse der Cloud de Confiance Console ein Fehler wie der folgende angezeigt.

Ein Fehler „Zugriff verweigert“ auf dem Tab „Jobinformationen“ im Abschnitt „Abfrageergebnisse“.

Prüfen Sie den Fehler, um das Hauptkonto, die Ressource und die Berechtigungen zu ermitteln.

In einigen Fällen können Sie fehlende Berechtigungen direkt über die Fehlermeldung anfordern. Weitere Informationen finden Sie in der IAM-Dokumentation unter Fehlermeldungen zu Berechtigungen.

Informationen aus den Cloud-Audit-Logs abrufen

Wenn die Fehlermeldung allgemein ist, Informationen fehlen oder die Aktion in einem Hintergrundprozess fehlgeschlagen ist, können Sie den Log-Explorer von Cloud-Audit-Logs verwenden, um Informationen zum Fehler zu erhalten.

  1. Rufen Sie in der Cloud de Confiance Console die Seite Log-Explorer auf.

    Zum Log-Explorer

    Alternativ können Sie im Navigationsmenü Monitoring > Log-Explorer auswählen.

  2. Wählen Sie im Log-Explorer für den Logbereich Projektlogs aus.

  3. Geben Sie im Abfragefenster die folgende Abfrage ein, um berechtigungsbezogene Fehler aus den BigQuery-Datenzugriffslogs abzurufen:

    resource.type="bigquery_resource" AND
logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access" AND
protoPayload.status.message:"Access Denied" OR
protoPayload.status.message:"Permission denied" OR
protoPayload.status.code=7

    Ersetzen Sie PROJECT_ID durch Ihre Projekt-ID.

  4. Maximieren Sie in den Abfrageergebnissen den Logeintrag, der dem fehlgeschlagenen Vorgang entspricht.

  5. Maximieren Sie im Abschnitt protoPayload das Array authorizationInfo und dann jeden Knoten im Array authorizationInfo.

    Das Array authorizationInfo zeigt jede Berechtigungsprüfung, die während des API-Aufrufs durchgeführt wurde.

  6. Suchen Sie nach dem Eintrag granted: false, um die Ursache des Fehlers zu ermitteln. Der Eintrag granted: false enthält die folgenden Informationen:

    • permission: Der IAM-Berechtigungsstring, der geprüft wurde. Beispiel: bigquery.tables.getData.
    • resource: Der vollständig qualifizierte Name der Ressource, auf die das Hauptkonto zugreifen wollte. Beispiel: projects/myproject/datasets/mydataset/tables/mytable
    • principalEmail (falls verfügbar): Wird in protoPayload.authenticationInfo referenziert. Dies ist das Hauptkonto, das die Aktion versucht hat.

    Der Abschnitt „authorizationInfo“ der protoPayload, in dem die Berechtigung, die Ressource und die principalEmail angezeigt werden.

Policy Analyzer für Zulassungsrichtlinien verwenden

Mit Policy Analyzer für Zulassungsrichtlinien können Sie herausfinden, welche IAM-Hauptkonten basierend auf Ihren IAM-Zulassungsrichtlinien Zugriff auf welche BigQuery-Ressourcen haben.

Nachdem Sie Informationen zum Berechtigungsfehler erfasst haben, können Sie mit dem Policy Analyzer herausfinden, warum das Hauptkonto nicht den erforderlichen Zugriff hat. Dieses Tool analysiert alle relevanten Richtlinien, Mitgliedschaften in Google Groups und die Übernahme von übergeordneten Ressourcen wie einem Projekt, einem Ordner und Ihrer Organisation.

Wenn Sie Policy Analyzer für Zulassungsrichtlinien verwenden möchten, erstellen Sie eine Analyseabfrage, geben einen Bereich für die Analyse an und führen die Abfrage dann aus.

  1. Rufen Sie in der Cloud de Confiance Console die Seite Policy Analyzer auf.

    Policy Analyzer aufrufen

    Alternativ können Sie im Navigationsmenü IAM und Verwaltung > Policy Analyzer auswählen.

  2. Klicken Sie auf Benutzerdefinierte Abfrage erstellen.

  3. Geben Sie auf der Seite Abfrage konfigurieren die zuvor erfassten Informationen ein:

    1. Prüfen Sie im Abschnitt Bereich auswählen im Feld Abfragebereich auswählen, ob Ihr aktuelles Projekt angezeigt wird, oder klicken Sie auf Durchsuchen, um eine andere Ressource auszuwählen.

    2. Wählen Sie im Abschnitt Abfrageparameter festlegen für Parameter 1 die Option Hauptkonto aus und geben Sie im Feld Hauptkonto die E-Mail-Adresse des Nutzers, der Gruppe oder des Dienstkontos ein.

    3. Klicken Sie auf Parameter hinzufügen.

    4. Wählen Sie für Parameter 2 die Option Berechtigung aus. Klicken Sie im Feld Berechtigung auf Auswählen, wählen Sie die BigQuery-Berechtigung aus und klicken Sie dann auf Hinzufügen. Wählen Sie beispielsweise bigquery.tables.getData aus.

    5. Klicken Sie auf Parameter hinzufügen.

    6. Wählen Sie für Parameter 3 die Option Ressource aus und geben Sie im Feld Ressource den vollständig qualifizierten Ressourcennamen ein. Der Ressourcenname muss das Dienstpräfix enthalten, wie in den folgenden Beispielen:

      • BigQuery-Projekt: //cloudresourcemanager.googleapis.com/projects/PROJECT_ID
      • BigQuery-Dataset: //bigquery.googleapis.com/projects/PROJECT_ID/datasets/DATASET
      • BigQuery-Tabelle: //bigquery.googleapis.com/projects/PROJECT/datasets/DATASET/tables/TABLE

  4. Klicken Sie im Bereich Benutzerdefinierte Abfrage auf Analysieren > Abfrage ausführen.

  5. Sehen Sie sich die Abfrageergebnisse an. Folgende Ergebnisse sind möglich:

    • Eine leere Liste: Wenn keine Ergebnisse angezeigt werden, hat das Hauptkonto nicht die erforderliche Berechtigung. Sie müssen dem Hauptkonto eine Rolle zuweisen, die die richtigen Berechtigungen bietet.
    • Ein oder mehrere Ergebnisse. Wenn der Analyzer eine Zulassungsrichtlinie findet, ist eine Form von Zugriff vorhanden. Klicken Sie bei jedem Ergebnis auf Bindung ansehen, um die Rollen aufzurufen, die Zugriff auf die Ressource gewähren, zu der das Hauptkonto gehört. Die Richtlinienbindung zeigt, ob der Zugriff über eine Gruppenmitgliedschaft oder Übernahme gewährt wird oder ob der Zugriff durch eine IAM-Bedingung oder eine IAM-Ablehnungsrichtlinie verweigert wird.

Die richtige IAM-Rolle finden, die die erforderlichen Berechtigungen gewährt

Nachdem Sie bestätigt haben, dass das Hauptkonto nicht über ausreichende Zugriffsrechte verfügt, müssen Sie im nächsten Schritt die entsprechende vordefinierte oder benutzerdefinierte IAM-Rolle finden, die die erforderlichen Berechtigungen gewährt. Die von Ihnen ausgewählte Rolle sollte dem Prinzip der geringsten Berechtigung entsprechen.

Wenn Ihre Organisation benutzerdefinierte Rollen verwendet, können Sie die richtige Rolle finden, indem Sie alle in Ihrem Projekt oder Ihrer Organisation erstellten benutzerdefinierten Rollen auflisten. In der Cloud de Confiance Console können Sie beispielsweise auf der Seite Rollen die Liste nach Typ:Benutzerdefiniert filtern, um nur benutzerdefinierte Rollen anzuzeigen.

So finden Sie die richtige vordefinierte IAM-Rolle:

  1. Öffnen Sie den Abschnitt „BigQuery-Berechtigungen“ auf der Seite „IAM-Rollen und -Berechtigungen für BigQuery“.

  2. Geben Sie in der Suchleiste Berechtigung eingeben die Berechtigung ein, die Sie aus der Fehlermeldung, dem Jobverlauf oder den Audit-Logs abgerufen haben. Beispiel: bigquery.tables.getData

    In den Suchergebnissen werden alle vordefinierten BigQuery-Rollen angezeigt, die die Berechtigung gewähren.

  3. Wenden Sie das Prinzip der geringsten Berechtigung an: Wählen Sie in der Liste der Rollen die Rolle mit den geringsten Berechtigungen aus, die die erforderlichen Berechtigungen gewährt. Wenn Sie beispielsweise nach bigquery.tables.getData gesucht haben, um die Möglichkeit zum Abfragen von Tabellendaten zu gewähren, ist BigQuery-Datenbetrachter die Rolle mit den geringsten Berechtigungen, die diese Berechtigung gewährt.

  4. Weisen Sie dem Hauptkonto die entsprechende Rolle zu. Informationen zum Zuweisen einer IAM-Rolle zu einer BigQuery-Ressource finden Sie unter Zugriff auf Ressourcen mit IAM steuern.

BigQuery-Nutzungsbedingungen nicht akzeptiert

Fehlerstring: BigQuery Terms of Service have not been accepted

Dieser HTTP-403 Forbidden-Fehler (reason: termsOfServiceNotAccepted) tritt auf, wenn die BigQuery-Nutzungsbedingungen nicht akzeptiert wurden. Der Fehler wird nicht durch fehlende IAM-Berechtigungen verursacht. Er kann für Anfragen wie das Erstellen eines Datasets oder das Laden von Daten zurückgegeben werden.

So beheben Sie das Problem:

  1. Rufen Sie in der Cloud de Confiance Console die Seite BigQuery auf.

    BigQuery aufrufen

  2. Wenn die Willkommensseite angezeigt wird, wählen Sie Ihr Land aus, aktivieren Sie das Kästchen Nutzungsbedingungen und klicken Sie dann auf Zustimmen und fortfahren. Weitere Informationen finden Sie unter BigQuery-Sandbox aktivieren.

Nachdem die Nutzungsbedingungen akzeptiert wurden, versuchen Sie es noch einmal.

Fehler bei Richtlinienverstößen beheben

Wenn Sie in BigQuery einen HTTP-Fehler 403 PERMISSION_DENIED mit der Fehlerursache policyViolation erhalten, deutet dies auf einen Fehler hin, der durch Organisationsrichtlinien, Datenperimeter oder VPC Service Controls verursacht wurde.

In den folgenden Abschnitten werden die häufigsten Fehlermeldungen im Zusammenhang mit dieser Fehlerursache, ihre Ursachen und ihre Behebung beschrieben.

Die Anfrage ist gemäß der Richtlinie der Organisation untersagt

Fehlerstring: VPC Service Controls: Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: VPC_SERVICE_CONTROLS_UNIQUE_IDENTIFIER

Diagnose

Ihre Anfrage stammt von einer Netzwerkadresse oder einem Client, die sich außerhalb des festgelegten VPC Service Controls-Perimeters befinden, oder die Anfrage hat gegen die definierten Regeln für eingehenden und ausgehenden Traffic für Ihren Arbeitsbereich verstoßen. Dies ist häufig der Fall, wenn sich Ihre Abfrage über mehrere Projekte erstreckt. Das Abrechnungsprojekt für die Abfrage befindet sich beispielsweise außerhalb des sicheren Perimeters des Datenprojekts.

Lösung

  1. Eindeutige ID finden Rufen Sie die vpcServiceControlsUniqueIdentifier aus der Fehlermeldung ab. Verwenden Sie diese ID, um im Cloud de Confiance by S3NS Log-Explorer nach dem entsprechenden VPC Service Controls-Log mit den Details zum Grund zu filtern:

    protoPayload.metadata.@type="type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata"
protoPayload.metadata.vpcServiceControlsUniqueId="VPC_SERVICE_CONTROLS_UNIQUE_IDENTIFIER"

    Suchen Sie unter protoPayload.metadata.violationReason nach dem Wert violationReason. Sehen Sie sich nach der Identifizierung die zusätzlichen Details im Logeintrag an und folgen Sie der vorhandenen Anleitung zur Fehlerbehebung bei VPC Service Controls. Ziehen Sie außerdem die Verwendung des Verstoßanalysetools in Betracht.

  2. Projektübergreifende Abrechnung korrigieren. Achten Sie bei projektübergreifenden Abfragen darauf, dass sich das Abrechnungsprojekt, das die Abfrage ausführt, im selben Perimeter wie die abgefragten Daten innerhalb des Perimeters befindet. Geben Sie bei Bedarf manuell ein konformes Abrechnungsprojekt an. Verwenden Sie dazu die Projektauswahl in der Cloud de Confiance Console, das Flag --project_id im bq-Befehlszeilentool oder Ihre API- oder Clientbibliotheksanfrage.

  3. Zugriffsebenen überprüfen Achten Sie darauf, dass Ihr Clientnetzwerk, Ihre IP-Adresse oder Ihr Nutzerkonto über Access Context Manager zugelassen ist. Für dieCloud de Confiance Console sind Regeln für eingehenden Traffic erforderlich, die speziell so konfiguriert sind, dass Nutzer auf geschützte Umgebungen zugreifen können.

Der Export nach Google Drive ist für Projekte mit aktivierten VPC Service Controls blockiert.

Fehlerstring: Export to Google Drive is blocked for projects with VPC-SC enabled

Diagnose

Google Drive unterstützt VPC Service Controls nicht. Da Google Drive den Sicherheitsbereich nicht erzwingen kann, deaktiviert BigQuery automatisch den Export von API-Extrakten nach Google Drive für alle Anfragen, die innerhalb einer VPC Service Controls-Grenze stammen, um eine Daten-Exfiltration zu verhindern.

Lösung

Anstatt direkt nach Google Drive zu exportieren, extrahieren Sie Ihre Abfrageergebnisse in einen Cloud Storage-Bucket, der sich im selben VPC Service Controls-Perimeter befindet, oder speichern Sie die Ergebnisse als lokale Datei.

Externe Google Drive-Tabellen sind für Projekte mit aktivierten VPC Service Controls blockiert

Fehlerstring: Google Drive external tables are blocked for projects with VPC-SC enabled

Diagnose

Standardmäßig blockiert VPC Service Controls keine Abfragen von externen Google Drive-Tabellen (z. B. Verbundene Tabellenblätter). Dieser Fehler wird jedoch angezeigt, weil Ihre Organisation in Cloud de Confiance by S3NS ausdrücklich eine strikte Blockierungskonfiguration für Ihr Projekt angefordert hat, um das standardmäßige zulässige Verhalten zu überschreiben. Dadurch werden alle eingehenden Abfragen an Google Drive-Daten innerhalb eines VPC Service Controls-Perimeters verhindert. Cloud de Confiance by S3NS

Lösung

Importieren Sie die Daten aus der Google-Tabelle oder Google Drive-Datei direkt in eine BigQuery-Standardtabelle innerhalb Ihres VPC Service Controls-Perimeters, anstatt sie dynamisch als externe föderierte Tabelle abzufragen. Alternativ können Sie sich an Ihren internen Cloud-Administrator wenden, um die Grenzen für den Datenexport Ihrer Organisation zu besprechen.

Der Export nach Google Drive ist für Ihr Projekt blockiert

Fehlerstring: Export to Google Drive is blocked for your project.

Diagnose

Auch ohne VPC Service Controls-Perimeter haben Ihre Cloud de Confiance by S3NS -Administratoren eine bestimmte, strenge Organisationskonfiguration für Ihr Projekt angefordert, die alle Datenextraktionsfunktionen für Google Drive ablehnt.

Lösung

Wählen Sie ein alternatives Extraktionsziel aus, z. B. einen Cloud Storage-Bucket oder eine lokale Datei, oder wenden Sie sich an Ihren internen Cloud-Administrator, um die Grenzen für den Datenexport Ihrer Organisation zu besprechen.

Standort verstößt gegen Einschränkung der Organisationsrichtlinie

Fehlerstring: LOCATION violates constraint CONSTRAINT_NAME on the resource projects/PROJECT_ID oder LOCATION violates constraint CONSTRAINT_NAME on the resource projects/PROJECT_ID/datasets/DATASET_ID

Diagnose

Ihr Cloud-Administrator hat eine Einschränkung für Organisationsrichtlinien konfiguriert, um genau festzulegen, wo Ressourcen erstellt oder analysiert werden können. Dieser Fehler tritt häufig in folgenden Fällen auf:

  • Erstellen eines Datasets in einer nicht autorisierten geografischen Region (z. B. durch constraints/gcp.resourceLocations eingeschränkt).
  • Versuch, BigQuery Omni über externe Clouds hinweg zu verwenden, wenn dies nicht zulässig ist (z. B. durch constraints/bigquery.disableBQOmniAWS oder constraints/bigquery.disableBQOmniAzure blockiert).

Lösung

  1. Prüfen Sie die genaue CONSTRAINT_NAME in der Fehlermeldung, um zu erfahren, welche Aktion blockiert wird.
  2. Wählen Sie eine andere, nicht blockierte Region für Ihre Daten aus oder wenden Sie sich an denCloud de Confiance by S3NS Administrator Ihrer Organisation, um die Organisationsrichtlinie auf Ordner- oder Organisationsebene zu prüfen. Weitere Informationen finden Sie unter Ressourcenstandorte strukturieren und definieren.

Fehlerbehebung bei der Zugriffssteuerung auf Spaltenebene

In den folgenden Abschnitten wird erläutert, wie Sie Probleme mit der Zugriffssteuerung auf Spaltenebene und Data Catalog-Richtlinien-Tags beheben.

Es werden keine Data Catalog-Rollen angezeigt.

Wenn Sie Rollen wie „Data Catalog: Detaillierter Lesezugriff“ nicht sehen, haben Sie die Data Catalog API in Ihrem Projekt möglicherweise nicht aktiviert. Unter Vorbereitung ist angegeben, wie Sie die Data Catalog API aktivieren. Die Data Catalog-Rollen werden einige Minuten nach der Aktivierung der Data Catalog API angezeigt.

Ich kann die Seite für die Taxonomien nicht aufrufen.

Sie benötigen zusätzliche Berechtigungen, um die Seite Richtlinien-Tag-Taxonomien in derCloud de Confiance Console aufzurufen. Die Data Catalog-Rolle Richtlinien-Tag-Administrator hat beispielsweise Zugriff auf die Seite Taxonomien.

Ich habe Richtlinien-Tags erzwungen, aber es scheint nicht zu funktionieren.

Wenn Sie weiterhin Abfrageergebnisse für ein Konto erhalten, das keinen Zugriff haben sollte, erhält das Konto möglicherweise im Cache gespeicherte Ergebnisse. Wenn Sie die Abfrage zuvor erfolgreich ausgeführt und dann Richtlinien-Tags erzwungen haben, erhalten Sie möglicherweise Ergebnisse aus dem Abfrageergebnis-Cache. Standardmäßig werden Abfrageergebnisse 24 Stunden lang im Cache gespeichert. Die Abfrage schlägt sofort fehl, wenn Sie den Ergebnis-Cache deaktivieren. Weitere Informationen zum Caching finden Sie unter Auswirkungen der Zugriffssteuerung auf Spaltenebene.

Im Allgemeinen dauert es etwa 30 Sekunden, bis Aktualisierungen für IAM ausgeführt werden. Änderungen an der Richtlinien-Tag-Hierarchie müssten nach maximal 30 Minuten wirksam werden.

Ich habe nicht die Berechtigung, aus einer Tabelle mit Sicherheit auf Spaltenebene zu lesen.

Sie benötigen entweder die Rolle „Detaillierter Leser“ oder die Rolle „Maskierter Leser“ auf verschiedenen Ebenen, z. B. Organisations-, Ordner-, Projekt- und Richtlinien-Tag. Die Rolle „Detaillierter Leser“ gewährt Zugriff auf Rohdaten, während die Rolle „Maskierter Leser“ Zugriff auf maskierte Daten gewährt. Sie können die IAM Policy Troubleshooter verwenden, um diese Berechtigung auf Projektebene zu prüfen.

Ich habe eine detaillierte Zugriffssteuerung in der Richtlinien-Tag-Taxonomie festgelegt, aber Nutzer sehen geschützte Daten

Prüfen Sie Folgendes, um das Problem zu beheben:

  • Prüfen Sie auf der Seite Richtlinien-Tag-Taxonomien des BigQuery-Sicherheitscenters, ob die Ein/Aus-Schaltfläche Zugriffssteuerung erzwingen auf Ein steht.

  • Achten Sie darauf, dass Ihre Abfragen keine im Cache gespeicherten Abfrageergebnisse verwenden. Wenn Sie das bq-Befehlszeilentool zum Testen Ihrer Abfragen verwenden, verwenden Sie das Flag --nouse_cache, um den Abfragecache zu deaktivieren. Beispiel:

    bq query --nouse_cache --use_legacy_sql=false "SELECT * EXCEPT (customer_pii) FROM my_table;"

Hinweise zur Projektmigration

Richtlinien-Tags und Taxonomien befinden sich in einer bestimmten Cloud de Confiance by S3NS -Organisation und werden nicht automatisch neu verknüpft, wenn ein Projekt zu einer neuen Organisation migriert wird. Wenn Sie ein Projekt, das Richtlinien-Tags für die Zugriffssteuerung auf Spaltenebene verwendet, in eine andere Organisation migrieren, treten die folgenden Probleme auf:

  • Die Richtlinien-Tags können in der Cloud de Confiance Console im migrierten Projekt nicht mehr verwaltet werden.
  • Sie können diese Richtlinien-Tags nicht auf neue Spalten im migrierten Projekt anwenden.
  • Vorhandene Zugriffssteuerungen auf Spaltenebene sind möglicherweise noch vorhanden, aber der Link zur Quelltaxonomie in der ursprünglichen Organisation ist für Verwaltungszwecke unterbrochen.

Zur Behebung dieses Problems ist ein manueller Eingriff durch den Cloud de Confiance -Support erforderlich, um die Taxonomie wieder mit der neuen Organisation zu verknüpfen. Wenn Sie ein Projekt mit Richtlinien-Tags migriert haben und diese Probleme auftreten, wenden Sie sich an Cloud Customer Care.

Fehlerbehebung bei kundenverwalteten Verschlüsselungsschlüsseln

In der folgenden Liste werden häufige Fehler und empfohlene Lösungen beschrieben, wenn Sie kundenverwaltete Verschlüsselungsschlüssel (CMEK) mit Cloud Key Management Service verwenden:

Fehler: Please grant Cloud KMS CryptoKey Encrypter/Decrypter role
Lösung: Das mit Ihrem Projekt verknüpfte BigQuery-Dienstkonto hat nicht die erforderlichen IAM-Berechtigungen, um den angegebenen Cloud KMS-Schlüssel zu verwenden. Folgen Sie der Anleitung in der Fehlermeldung oder unter Berechtigungen zum Verschlüsseln und Entschlüsseln erteilen, um die erforderliche IAM-Berechtigung zu gewähren.
Fehler: Existing table encryption settings don't match encryption settings specified in the request
Lösung: Dieser Fehler kann auftreten, wenn die Verschlüsselungseinstellungen für die Zieltabelle von den Verschlüsselungseinstellungen in Ihrer Abfrage abweichen. Verwenden Sie zum Beheben dieses Problems die Schreibanordnung TRUNCATE, um die Tabelle zu ersetzen, oder geben Sie eine andere Zieltabelle an.
Fehler: This region is not supported
Lösung: Die Region des Cloud KMS-Schlüssels stimmt nicht mit der Region des BigQuery-Datasets für die Zieltabelle überein. Wählen Sie zur Behebung dieses Problems einen Schlüssel aus einer Region aus, die mit Ihrem Dataset übereinstimmt, oder laden Sie Daten in ein Dataset, das mit der Schlüsselregion übereinstimmt.
Fehler: Your administrator requires that you specify an encryption key for queries in project PROJECT_ID.
Lösung: Eine Organisationsrichtlinie hat das Erstellen einer Ressource oder das Ausführen einer Abfrage verhindert. Weitere Informationen zu dieser Richtlinie finden Sie unter CMEKs für alle Ressourcen erzwingen.
Fehler: Your administrator prevents using KMS keys from project KMS_PROJECT_ID to protect resources in project PROJECT_ID.
Lösung: Eine Organisationsrichtlinie hat das Erstellen einer Ressource oder das Ausführen einer Abfrage verhindert. Weitere Informationen zu dieser Richtlinie finden Sie unter Cloud KMS-Schlüssel für ein BigQuery-Projekt einschränken.

Nächste Schritte