Best Practices für die Sicherheit auf Zeilenebene in BigQuery
In diesem Dokument werden Best Practices für die Sicherheit auf Zeilenebene erläutert.
Bevor Sie dieses Dokument lesen, machen Sie sich mit dem Konzept der Sicherheit auf Zeilenebene vertraut, indem Sie Einführung in BigQuery-Sicherheit auf Zeilenebene und Mit Sicherheit auf Zeilenebene arbeiten lesen.
Nutzerberechtigungen beschränken, um Side-Channel Attacks zu begrenzen
Ein Side-Channel-Angriff ist ein Sicherheitsangriff, der auf vom System selbst gewonnenen Informationen basiert. Ein Angreifer mit umfassenderen Berechtigungen als erforderlich kann leichter Seitenkanalangriffe durchführen und vertrauliche Daten durch Beobachten oder Durchsuchen von Abrechnung, Logging oder Systemen herausfinden.
Um diese Möglichkeiten zu minimieren, blendet BigQuery sensible Statistiken für alle Abfragen auf Tabellen mit Sicherheit auf Zeilenebene aus. Zu diesen sensiblen Statistiken gehören die Anzahl der verarbeiteten Bytes und Partitionen, die Anzahl der abgerechneten Bytes und die Abfrageplanphasen.
Wir empfehlen Administratoren, folgende Berechtigungen Nutzern nicht zu gewähren, die nur gefilterte Daten sehen sollten, um den Zugriff auf vertrauliche Daten zu vermeiden.
| Berechtigungen | Sensible Daten |
|---|---|
| Rolle „Projektinhaber“ oder „Projektersteller“ | Projektinhaber können verarbeitete Byte prüfen und zugehörige Daten in Audit-Logs einsehen. Projektersteller können neue Projekte erstellen, deren Inhaber sie sind, und Abrechnungs- und Audit-Logs aufrufen. |
| Rollen "BigQuery Datenbearbeiter "-Inhaber" oder "-Betrachter" | Fehlermeldungen bei Abfragen ansehen. |
| Leseberechtigungen für Cloud Billing | BigQuery-Abrechnung ansehen. |
Beispiele
- Durch eine wiederholte Beobachtung der Abfragedauer beim Abfragen von Tabellen mit Zugriffsrichtlinien auf Zeilenebene kann ein Nutzer eventuell die Werte von Zeilen ableiten, die eigentlich durch die Zugriffsrichtlinien auf Zeilenebene geschützt sind. Diese Art von Angriff erfordert viele wiederholte Versuche für einen Bereich an Schlüsselwerten in Partitionierungs- oder Clustering-Spalten. Auch wenn bei der Beobachtung oder Messung der Abfragedauer bei wiederholten Versuchen Fehler auftreten, kann der Angreifer eine zuverlässige Schätzung erhalten. Wenn Sie dieses Schutzniveau gewährleisten möchten, empfehlen wir stattdessen die Verwendung separater Tabellen, um Zeilen mit unterschiedlichen Anforderungen an die Zugriffssteuerung zu isolieren.
- Ein Angreifer könnte nach den von einer Abfrage verarbeiteten Byte suchen. Dazu überwacht er die Fehler, die auftreten, wenn die Limits des Abfragejobs (z. B. maximale Anzahl abgerechneter Byte oder benutzerdefinierte Kostenkontrollen) überschritten werden. Dieser Angriff erfordert jedoch eine große Anzahl an Abfragen.
- Durch wiederkehrende Abfragen und das Beobachten des BigQuery-Abrechnungsbetrags in Cloud Billing kann ein Nutzer eventuell die Werte von Zeilen ableiten, die eigentlich durch Zugriffsrichtlinien auf Zeilenebene geschützt sind. Diese Art von Angriff erfordert viele wiederholte Versuche für einen Bereich an Schlüsselwerten in Partitionierungs- oder Clustering-Spalten. Wenn Sie dieses Schutzniveau gewährleisten, sollten Sie den Zugriff auf Abrechnungsdaten für Abfragen einschränken.
Wir empfehlen außerdem, Administratoren Cloud-Audit-Logs (/bigquery/docs/reference/auditlogs) auf verdächtige Aktivitäten bei Tabellen mit Sicherheit auf Zeilenebene zu überwachen, z. B. unerwartetes Hinzufügen, Ändern und Löschen von Zugriffsrichtlinien auf Zeilenebene.
Nutzerberechtigungen einschränken, um die Datenmanipulation zu erschweren
Nutzer mit Schreibberechtigungen für eine Tabelle können mit dem Befehl bq load oder mit der BigQuery Storage Write API Daten in die Tabelle einfügen. Dadurch kann der Nutzer mit Schreibberechtigungen die Abfrageergebnisse anderer Nutzer ändern.
Wir empfehlen Administratoren, separate Google-Gruppen für den Schreibzugriff auf Tabellen und die Zugriffsrichtlinien auf Zeilenebene zu erstellen. Nutzer, die nur Ergebnisse von gefilterten Tabellen sehen sollten, sollten keinen Schreibzugriff auf die gefilterte Tabelle haben.
Vermeiden Sie den unkontrollierten Zugriff beim neuen Erstellen der Zugriffsrichtlinien auf Zeilenebene
Wenn Sie zum ersten Mal eine Zeilenzugriffsrichtlinie für eine Tabelle hinzufügen, werden die Daten in den Abfrageergebnissen umgehend gefiltert. Wenn Sie die letzte Zugriffsrichtlinie auf Zeilenebene für eine Tabelle entfernen, können Sie unbeabsichtigt den ungefilterten Zugriff einem größeren Publikum gewähren, auch wenn Sie die Zugriffsrichtlinie auf Zeilenebene nur neu erstellen möchten.
Wir empfehlen Administratoren, wenn sie die letzte Zugriffsrichtlinie auf Zeilenebene für eine Tabelle neu erstellen folgende Richtlinien zu beachten:
- Entfernen Sie zuerst mit der Tabellenzugriffssteuerung den gesamten Zugriff auf die Tabelle.
- Entfernen Sie alle Zugriffsrichtlinien auf Zeilenebene.
- Erstellen Sie die gewünschten Zugriffsrichtlinien auf Zeilenebene neu.
- Aktivieren Sie den Zugriff auf die Tabelle wieder.
Alternativ können Sie zuerst neue Zugriffsrichtlinien auf Zeilenebene für die Tabelle erstellen und dann die älteren Zugriffsrichtlinien auf Zeilenebene löschen, die nicht mehr benötigt werden.
Verwenden Sie die Sicherheit auf Zeilenebene nur innerhalb von Organisationen, nicht organisationsübergreifend
Verwenden Sie das Feature für Sicherheit auf Zeilenebene nicht organisationsübergreifend, um Datenlecks durch Side-Channel Attacks zu verhindern und eine bessere Kontrolle über den Zugriff auf sensible Daten zu gewährleisten.
Erstellen und suchen Sie für Zugriffsrichtlinien auf Unterabfragezeilenebene Tabellen in Organisationen oder Projekten. Dies führt zu einer besseren Sicherheit und einer einfacheren ACL-Konfiguration, da die Empfänger die Berechtigung bigquery.tables.getData für die Ziel- und referenzierten Tabellen in Richtlinien sowie alle relevanten Berechtigungen für Sicherheitsfunktionen auf Spaltenebene haben müssen.
Wir empfehlen, die Sicherheitsfunktion auf Zeilenebene nur für Sicherheitsbeschränkungen innerhalb der Organisation, z. B. für die Freigabe von Daten innerhalb einer Organisation, eines Unternehmens oder eines Unternehmens, und nicht für eine organisationsübergreifende oder öffentliche Sicherheit zu verwenden.
Beispiel
Außerhalb Ihrer Organisation haben Sie weniger Kontrolle darüber, wer Zugriff auf Daten hat. In Ihrer Organisation können Sie mit Zugriffsrichtlinien auf Zeilenebene steuern, wer Zugriff auf Abrechnungsinformationen durch Abfrage von Tabellen hat. Abrechnungsinformationen sind ein Vektor für Nebenkanalangriffe.
Verwenden Sie die Rolle Filtered Data Viewer mit Vorsicht.
Wenn Sie eine Zugriffsrichtlinie auf Zeilenebene erstellen, erhalten die Hauptkonten in der Richtlinie automatisch die Rolle bigquery.filteredDataViewer. Sie können Hauptkonten nur mit einer DDL-Anweisung hinzufügen oder aus der Richtlinie entfernen.
Es ist jedoch möglich, der übergeordneten Ressource, beispielsweise einer Tabelle, einem Dataset oder einem Projekt die Rolle bigquery.filteredDataViewer über IAM zuzuweisen. Wenn Sie einem Nutzer die Rolle bigquery.filteredDataViewer zuweisen, kann er die Zeilen aufrufen, die durch alle Zugriffsrichtlinien auf Zeilenebene in dieser Tabelle, diesem Dataset oder diesem Projekt definiert werden.
Das Zuweisen der Rolle bigquery.filteredDataViewer für eine Tabelle bedeutet jedoch nicht unbedingt, dass der Nutzer alle Zeilen in der Tabelle sehen kann. Durch Vereinigung aller Filterausdrücke für Zeilenzugriffsrichtlinien auf Zeilenebene kann eventuell ein Abschluss für die gesamte Tabelle gebildet werden.
Wir empfehlen Ihnen, bei dem Gewähren der Rolle bigquery.filteredDataViewer für eine Ressource vorsichtig zu sein.
Filtern nach partitionierten Spalten wirkt sich auf die Leistung aus
Zugriffsrichtlinienfilter auf Zeilenebene wirken sich nicht auf die Bereinigung von partitionierten und geclusterten Tabellen aus.
Wenn Ihre Zugriffsrichtlinie auf Zeilenebene eine partitionierte Spalte benennt, erhält Ihre Abfrage nicht die Leistungsvorteile des Abfrage-Prunings.