Probleme mit der Zugriffssteuerung beheben

In diesem Dokument wird beschrieben, wie Sie BigQuery-Sicherheits- und Berechtigungsprobleme beheben, einschließlich IAM-Berechtigungen (Identity and Access Management), Zugriffssteuerung auf Spaltenebene, kundenverwaltete Verschlüsselungsschlüssel (CMEK) und Richtlinienverstöße. Fehler bei der Zugriffssteuerung führen in der Regel zu Access Denied- oder 403 Forbidden-Fehlern, wenn Hauptkonten Jobs ausführen oder auf Ressourcen zugreifen.

Häufige Fehler vom Typ „Zugriff verweigert“

Im Folgenden finden Sie Beispiele für häufige Fehler, die auftreten, wenn der Zugriff verweigert wird:

• 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

• Wenn Sie den Zugriff eines Hauptkontos auf eine BigQuery-Ressource beheben möchten, müssen Sie die erforderlichen IAM-Berechtigungen haben.

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 Google Cloud Console.

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

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 generisch 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 Google Cloud 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" OR "bigquery_project" OR "bigquery_dataset") AND
   logName=("projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fdata_access" OR
     "projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity") 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 maximieren Sie 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.

   

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 Google Cloud 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 add 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 add 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 benutzerdefinierten Rollen auflisten, die in Ihrem Projekt oder Ihrer Organisation erstellt wurden. In der Google Cloud Console können Sie beispielsweise auf der Seite Rollen die Liste nach Typ:Benutzerdefiniert filtern, um nur benutzerdefinierte Rollen zu sehen.

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.

Häufige Szenarien für „Zugriff verweigert“ beheben

Wenn ein Vorgang mit 403 accessDenied (Access Denied: RESOURCE_TYPE RESOURCE_ID: DETAILS) fehlschlägt, prüfen Sie zusätzlich zu den vorherigen allgemeinen IAM-Schritten die folgenden gängigen Szenarien:

• Nicht vorhandene Ressource oder Standortkonflikt (or perhaps it does not exist). Wenn eine Fehlermeldung mit or perhaps it does not exist endet, maskiert BigQuery, ob die Tabelle, Ansicht oder Routine vorhanden ist, da dem Hauptkonto die Berechtigungen für Dataset- oder Projektmetadaten (bigquery.tables.get oder bigquery.datasets.get) fehlen. Prüfen Sie, ob die Projekt-ID, die Dataset-ID und der Tabellenname richtig geschrieben sind, und bestätigen Sie, dass Ihre Abfrage am selben Standort wie das Dataset ausgeführt wird.

• Autorisierte Ansichten und Routinen Wenn ein Nutzer eine autorisierte Ansicht oder eine autorisierte Routine abfragt, benötigt er die Berechtigung zum Abfragen der Ansicht oder Routine. Außerdem muss die Ansicht oder Routine selbst in der Access Control List (ACL) des Quell-Datasets autorisiert sein. Wenn die Abfrage mit Access Denied für die zugrunde liegende Basistabelle fehlschlägt, fügen Sie die Ansicht oder Routine (oder das gesamte Dataset als autorisiertes Dataset) der Zugriffsliste des Quell-Datasets hinzu. Wenn eine Ansicht eine andere Ansicht abfragt, muss jede Ansicht in der Kette für das Dataset autorisiert sein, aus dem sie liest.

  Wenn eine autorisierte Ansicht oder ein autorisiertes Dataset gelöscht und eine andere Ansicht oder ein anderes Dataset mit demselben Namen erstellt wurde, können Abfragen mit Access Denied fehlschlagen. Dieser Fehler kann auch auftreten, wenn der Name noch in der Zugriffsliste des Quell-Datasets angezeigt wird, in der gelöschte Einträge bis zu 24 Stunden lang verbleiben können. Prüfen Sie in den Cloud-Audit-Logs, ob eine autorisierte Ansicht oder ein autorisiertes Dataset in der Kette seit der letzten erfolgreichen Abfrage gelöscht und ersetzt wurde. Wenn Sie den Zugriff wiederherstellen möchten, entfernen Sie zuerst den vorhandenen Eintrag aus der Zugriffsliste des Quell-Datasets und fügen Sie dann die neue Ansicht oder das neue Dataset wieder hinzu. Wenn Sie die neue Ansicht hinzufügen, bevor Sie den alten Eintrag entfernen, kann ein Duplicate authorized views-Fehler auftreten.

  Wenn Sie eine Ansicht ändern möchten, ohne die Autorisierung zu beeinträchtigen, aktualisieren Sie die SQL-Abfrage der Ansicht, anstatt die Ansicht zu löschen und neu zu erstellen. Wenn Sie jedoch eine autorisierte Routine mit einer CREATE OR REPLACE-Anweisung oder der Methode routines.update ändern, müssen Sie die Routine noch einmal autorisieren.

• VPC Service Controls. Wenn Ihre Organisation VPC Service Controls verwendet, schlagen Anfragen, die eine Dienstperimetergrenze überschreiten, mit 403 accessDenied oder policyViolation fehl. Suchen Sie in den Cloud-Audit-Logs um den Zeitpunkt des Fehlers nach dem Wert vpcServiceControlsUniqueIdentifier aus der Fehlermeldung und verwenden Sie den Violation Analyzer, um Regeln für eingehenden und ausgehenden Traffic zu prüfen. Die zu verwendende Log-Explorer-Abfrage finden Sie unter Anfrage ist gemäß der Richtlinie der Organisation unzulässig.

• Einfache Rollen (roles/owner, roles/editor, roles/viewer). Einfache Projektrollen enthalten keine Berechtigungen auf Organisationsebene, die für Ansichten wie INFORMATION_SCHEMA.TABLE_STORAGE_USAGE_TIMELINE_BY_ORGANIZATION erforderlich sind, oder spezielle Berechtigungen wie bigquery.rowAccessPolicies.overrideTimeTravelRestrictions, die für den Zugriff auf die Verlaufsdaten einer Tabelle erforderlich sind, die Zugriffsrichtlinien auf Zeilenebene hat oder hatte (siehe Zeitreise und Zugriff auf Zeilenebene). Weisen Sie vordefinierte BigQuery-IAM-Rollen zu, anstatt sich auf einfache Rollen zu verlassen.

• Vorübergehende Überschreibungen von IAM-Richtlinien (SetIamPolicy). Wenn Berechtigungen zeitweise funktionieren und dann fehlschlagen, suchen Sie in den Audit-Logs zur Administratoraktivität nach protoPayload.methodName=~"SetIamPolicy", um zu prüfen, ob ein automatisiertes Skript oder eine Infrastructure-as-Code-Pipeline vorhandene Richtlinienbindungen überschreibt, anstatt sie zusammenzuführen.

• Externe Datenquellen (Google Drive, Cloud Storage, BigLake):

  • Google Drive (Permission denied while getting Drive credentials). Gewähren Sie dem Nutzer oder Dienstkonto Lesezugriff auf die Google Drive-Datei oder das Google-Tabellendokument, achten Sie darauf, dass der Aufrufer den OAuth-Bereich https://www.googleapis.com/auth/drive angibt, oder aktualisieren Sie die Anmeldedaten für geplante Abfragen.
  • Cloud Storage- und BigLake-Tabellen Gewähren Sie dem Nutzer (für standardmäßige externe Tabellen) oder dem BigLake-Verbindungsdienstkonto (für BigLake-Tabellen) die Berechtigung roles/storage.objectViewer für den Cloud Storage-Bucket.

• Kundenverwaltete Verschlüsselungsschlüssel (CMEK) Wenn die Abfrage auf eine Tabelle verweist, die durch CMEK geschützt ist, muss der entsprechende Cloud KMS-Schlüssel vorhanden und aktiviert sein. Wenn ein Abfrage- oder Ladejob mit Cloud KMS Error: Permission 'cloudkms.cryptoKeyVersions.useToEncrypt' denied (oder useToDecrypt) fehlschlägt, weisen Sie dem BigQuery Encryption Service-Agent (bq-PROJECT_NUMBER@bigquery-encryption.iam.gserviceaccount.com) die Rolle roles/cloudkms.cryptoKeyEncrypterDecrypter für den Cloud Key Management Service-Schlüssel zu. Weitere Informationen finden Sie unter Berechtigungen zum Verschlüsseln und Entschlüsseln erteilen. Informationen zu anderen CMEK-Fehlern finden Sie unter Fehlerbehebung bei kundenverwalteten Verschlüsselungsschlüsseln.

• Identitätsübernahme des Dienstkontos Wenn eine Anfrage mit Identitätsübernahme des Dienstkontos mit Permission 'iam.serviceAccounts.getAccessToken' denied fehlschlägt, weisen Sie dem aufrufenden Hauptkonto roles/iam.serviceAccountTokenCreator für das Zieldienstkonto zu.

• Sicherheit auf Spaltenebene (Richtlinien-Tags) und Sicherheit auf Zeilenebene. Wenn eine Abfrage oder DML-Anweisung mit Requires fineGrainedGet permission on the read columns oder User does not have permission to access data protected by policy tag fehlschlägt, weisen Sie dem Hauptkonto die Data Catalog-Rolle Detaillierter Lesezugriff (roles/datacatalog.categoryFineGrainedReader) für das Richtlinien-Tag zu oder schließen Sie die geschützten Spalten aus Ihrer SELECT-Liste aus. Weitere Informationen finden Sie unter Unzureichende Berechtigungen für die Zugriffssteuerung auf Spaltenebene. Wenn die Tabelle die Sicherheit auf Zeilenebene verwendet, prüfen Sie die aktiven Zugriffsrichtlinien auf Zeilenebene in der Google Cloud Console oder durch Ausführen von bq ls --row_access_policies. Weitere Informationen finden Sie unter Zugriffsrichtlinien auf Tabellenzeilenebene auflisten.

• Verzögerungen bei der Weitergabe von IAM- und Metadaten. Neu gewährte IAM-Rollen und Aktualisierungen von Dataset-ACLs sind letztendlich konsistent und es dauert in der Regel einige Minuten, bis sie in den Caches übernommen werden. Wenn eine Berechtigung gerade erst gewährt wurde, warten Sie einige Minuten und versuchen Sie es dann noch einmal.

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 Google Cloud Console die Seite BigQuery auf.

   BigQuery aufrufen

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

Nachdem die Nutzungsbedingungen akzeptiert wurden, wiederholen Sie die Anfrage.

Fehler bei Richtlinienverstößen beheben

Wenn Sie in BigQuery einen HTTP-403 PERMISSION_DENIED-Fehler 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 bzw. der sich außerhalb des festgelegten VPC Service Controls-Perimeters befindet, 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 Google Cloud 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 dem vorhandenen Leitfaden 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 Google Cloud 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 mit Access Context Manager zugelassen ist. Für dieGoogle Cloud 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 Google Cloud Organisation ausdrücklich angefordert hat, dass Google Cloudeine strikte Blockierungskonfiguration für Ihr Projekt erzwingt, 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.

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 Google Cloud -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. blockiert durch constraints/bigquery.disableBQOmniAWS oder constraints/bigquery.disableBQOmniAzure).

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 denGoogle Cloud Administrator Ihrer Organisation, um die Organisationsrichtlinie auf Ordner- oder Organisationsebene zu prüfen. Weitere Informationen finden Sie unter Ressourcenstandorte strukturieren und definieren.

Fehler aufgrund fehlender Authentifizierung beheben

Wenn Sie in BigQuery einen HTTP-Fehler 401 Unauthorized (gRPC UNAUTHENTICATED) mit der Fehlerursache unauthenticated erhalten, fehlen der Anfrage gültige Authentifizierungsdaten, das OAuth 2.0-Zugriffstoken ist abgelaufen oder der Aufrufer kann sich nicht als die angegebene Identität authentifizieren.

In den folgenden Abschnitten werden die häufigsten unauthenticated-Szenarien, ihre Ursachen und ihre Behebung beschrieben.

Ungültige oder abgelaufene Anmeldedaten

Fehlerstrings:

• Invalid credential
• User credential was invalid.
• Credentials expired
• Credentials missing required scope.
• Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential.

Diagnose

Das Zugriffstoken, der Dienstkontoschlüssel oder die Standardanmeldedaten für Anwendungen (Application Default Credentials, ADC), die mit der Anfrage bereitgestellt wurden, sind abgelaufen, widerrufen oder es fehlen erforderliche OAuth 2.0-Bereiche. Dieser Fehler tritt auch auf, wenn die Anfrage mit einer Systemuhr signiert ist, die von der NTP-Zeit (Network Time Protocol) abweicht.

Lösung

• Aktualisieren Sie Ihre Anmeldedaten. Wenn Sie sich über eine lokale Entwicklungsumgebung authentifizieren, führen Sie gcloud auth application-default login (für ADC) oder gcloud auth login aus, um ein neues Token abzurufen.
• Dienstkontoschlüssel und OAuth-Bereiche prüfen Wenn Ihre Anwendung GOOGLE_APPLICATION_CREDENTIALS verwendet, prüfen Sie, ob die Variable auf eine gültige, nicht widerrufene JSON-Schlüsseldatei verweist, ob das Dienstkonto in derGoogle Cloud Console aktiviert ist und ob die Anmeldedaten den erforderlichen Bereich https://www.googleapis.com/auth/bigquery oder https://www.googleapis.com/auth/cloud-platform enthalten.
• Verwenden Sie aktuelle Clientbibliotheken und synchronisieren Sie die Systemuhren. Aktualisieren Sie Ihre BigQuery-Clientbibliothek oder Ihren ODBC- oder JDBC-Treiber auf die aktuelle Version, damit OAuth 2.0-Tokenaktualisierungen und föderierte Anmeldedaten automatisch verarbeitet werden. Achten Sie außerdem darauf, dass die Systemuhr des Hostcomputers über NTP synchronisiert wird.

Fehlende Nutzeranmeldedaten für das Google-Konto oder fehlende Berechtigung zur Identitätsübernahme des Dienstkontos

Fehlerstrings:

• Current user can not act as user for service account SERVICE_ACCOUNT_EMAIL
• No end user credentials found when accessing PROJECT_ID:DATASET_ID.TABLE_ID. Please use end user credentials to call BigQuery APIs.

Diagnose

Der Job oder die kontinuierliche Abfrage ist so konfiguriert, dass er bzw. sie als benutzerdefiniertes Dienstkonto ausgeführt wird, für das der Aufrufer keine Berechtigung hat, oder die Zieltabelle oder Sicherheitsrichtlinie erfordert Google-Konto-Nutzeranmeldedaten, damit BigQuery den Zugriff anhand einer interaktiven Nutzeridentität prüfen kann.

Lösung

• Berechtigungen für die Identitätsübernahme des Dienstkontos gewähren Wenn Sie eine kontinuierliche Abfrage oder einen Job ausführen, der mit einem benutzerdefinierten Dienstkonto konfiguriert ist, weisen Sie dem Aufrufer die Rolle „Dienstkontonutzer“ (roles/iam.serviceAccountUser, die die Berechtigung iam.serviceAccounts.actAs enthält) für dieses Dienstkonto zu. Wenn Sie die Identität eines Dienstkontos übernehmen oder föderierte Anmeldedaten gegen ein kurzlebiges Token austauschen, weisen Sie dem Aufrufer die Rolle „Ersteller von Dienstkonto-Tokens“ (roles/iam.serviceAccountTokenCreator) für das Zieldienstkonto zu.
• Authentifizierung mit den Anmeldedaten eines Google-Kontos Wenn für die Zielressource Nutzeranmeldedaten für ein Google-Konto erforderlich sind, authentifizieren Sie die Anfrage mit den OAuth 2.0-Anmeldedaten eines interaktiven Nutzers (z. B. durch Ausführen von gcloud auth application-default login oder Konfigurieren von Nutzer-OAuth in Ihrem BI-Tool) und nicht mit eigenständigen Dienstkonto-Anmeldedaten.
• Regeln für ein- und ausgehenden Traffic in VPC Service Controls prüfen Wenn die Anfrage eine VPC Service Controls-Grenze überschreitet, prüfen Sie, ob die Regeln für ein- und ausgehenden Traffic des Perimeters die Aufruferidentität und die Zielressource zulassen.

Konto eingeschränkt, gesperrt oder gelöscht

Fehlerstrings:

• The account was restricted due to REASON
• Account deleted

Diagnose

Das Google-Konto oder Google Workspace-Konto, von dem die Anfrage stammt, wurde von einem Administrator oder einer Kontosicherheitsrichtlinie gesperrt, deaktiviert, eingeschränkt oder gelöscht.

Lösung

Wenden Sie sich an Ihren Google Workspace- oder Cloud Identity-Administrator, um den Kontostatus in der Admin-Konsole zu prüfen und das Nutzerkonto wiederherzustellen oder die Sperrung aufzuheben. Alternativ können Sie die Arbeitslast aktualisieren, um sich mit einem aktiven Dienstkonto zu authentifizieren.

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 derGoogle Cloud 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, deaktivieren Sie den Abfragecache mit dem Flag --nouse_cache. 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 Google Cloud -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 Google Cloud 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 Google Cloud -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 Data-Governance-Tags

In den folgenden Abschnitten wird beschrieben, wie Sie häufige Probleme beheben, die beim Steuern des Zugriffs auf Spalten mit Data Governance-Tags auftreten können.

Falsch formatierte Tag-Namen

Wenn Sie Tags erstellen, definieren Sie einen Kurznamen (z. B. ssn). Wenn Sie jedoch Tags an Spalten in Ihrem Schema anhängen oder in Bedingungen verwenden, muss der Tag-Schlüssel das Namespace-Format (PROJECT_ID/TAG_KEY oder ORGANIZATION_ID/TAG_KEY) verwenden, während der Tag-Wert weiterhin den Kurznamen verwendet. Wenn Sie nur den Kurznamen für den Tag-Schlüssel angeben, wird ein Invalid tagKey- oder Invalid tagValue-Fehler erzeugt.

Projektübergreifende Richtlinienanwendung

Standardmäßig werden nur die Datenrichtlinien des Projekts der Tabelle ausgewertet. Richtlinien aus anderen Projekten gelten nur, wenn auf Organisationsebene ein Standardprojekt für Datenrichtlinien konfiguriert ist. Weitere Informationen zum Konfigurieren und Auswerten projektübergreifender Richtlinien finden Sie unter Standardprojekt für Datenrichtlinien konfigurieren.

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 zur Behebung des 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. Sie beheben das Problem, indem Sie einen Schlüssel aus einer Region wählen, der mit Ihrem Dataset übereinstimmt, oder Daten in ein Dataset laden, 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

• Eine Liste aller BigQuery-IAM-Rollen und -Berechtigungen finden Sie unter BigQuery-IAM-Rollen und -Berechtigungen.
• Weitere Informationen zur Sicherheit auf Spaltenebene finden Sie unter Zugriff mit Zugriffssteuerung auf Spaltenebene einschränken.
• Weitere Informationen zu kundenverwalteten Verschlüsselungsschlüsseln finden Sie unter Daten mit Cloud KMS-Schlüsseln schützen.
• Weitere Informationen zur Fehlerbehebung bei Zulassungs- und Ablehnungsrichtlinien in IAM finden Sie unter Fehlerbehebung bei Richtlinien.
• Weitere Informationen zum Policy Analyzer von Policy Intelligence finden Sie unter Policy Analyzer für Zulassungsrichtlinien.
• Weitere Informationen zur Policy Troubleshooter finden Sie unter Policy Troubleshooter verwenden.