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 mehr 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 Zeilenebene zu erstellen. Nutzer, die nur Ergebnisse aus gefilterten Tabellen sehen sollen, benötigen keinen Schreibzugriff auf die gefilterte Tabelle.

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:

  1. Entfernen Sie zuerst mit der Tabellenzugriffssteuerung den gesamten Zugriff auf die Tabelle.
  2. Entfernen Sie alle Zugriffsrichtlinien auf Zeilenebene.
  3. Erstellen Sie die Zugriffsrichtlinien auf Zeilenebene neu.
  4. 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 die Sicherheitsfunktion auf Zeilenebene nicht organisationsübergreifend, um Datenlecks durch Side-Channel-Angriffe zu verhindern und eine bessere Kontrolle über den Zugriff auf sensible Daten zu gewährleisten.

Erstellen und durchsuchen Sie für Unterabfragen auf Zeilenebene 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.

Rolle Filtered Data Viewer über Zugriffsrichtlinien auf Zeilenebene verwalten

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

Die Rolle bigquery.filteredDataViewer darf nicht über IAM einer Ressource auf höherer Ebene wie einer Tabelle, einem Datensatz oder einem Projekt zugewiesen werden. Wenn Sie die Rolle auf diese Weise gewähren, können Nutzer Zeilen aufrufen, die durch alle Zugriffsrichtlinien auf Zeilenebene in diesem Bereich definiert sind, unabhängig von den beabsichtigten Einschränkungen. Auch wenn die Vereinigung der Filter für Zugriffsrichtlinien auf Zeilenebene nicht die gesamte Tabelle umfasst, stellt diese Vorgehensweise ein erhebliches Sicherheitsrisiko dar und untergräbt den Zweck der Sicherheit auf Zeilenebene.

Wir empfehlen, die Rolle bigquery.filteredDataViewer ausschließlich über Zugriffsrichtlinien auf Zeilenebene zu verwalten. Mit dieser Methode wird sichergestellt, dass Hauptkonten die Rolle bigquery.filteredDataViewer implizit und korrekt zugewiesen wird, wobei die für jede Richtlinie definierten Filterprädikate berücksichtigt werden.

Leistungsauswirkungen von Filtern auf partitionierte Spalten

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.