Übersicht über parametrisierte Ansichten

In Bigtable können Sie parametrisierte Ansichten verwenden, um Daten bereiche für logische Ansichten basierend auf dem Anwendungskontext dynamisch zu filtern. Dieser Ansatz schützt Ihre Anwendungen vor SQL-Injection und reduziert den Bedarf an mehreren statischen Ansichten.

Zur Verarbeitung vertraulicher Informationen verwenden parametrisierte Ansichten in Bigtable einen isolierten Kontext, der vom SQL-Abfragetext getrennt ist. Da die Datenbank diese Werte serverseitig bindet, können Nutzer und KI-Agents Abfrageparameter nicht manipulieren. Die Datenbank beschränkt den Datenzugriff automatisch auf Ihren spezifischen Kontext, unabhängig davon, wie Sie die Abfrage schreiben.

Vorteile von parametrisierten Ansichten

Parametrisierte Ansichten eignen sich gut für die Verwaltung des Datenbereichs auf Datenbankebene, insbesondere in Anwendungen, die Freiformabfragen verarbeiten, die aus natürlicher Sprache übersetzt wurden. Beim Datenbereich wird der Umfang der Abfrageergebnisse auf eine bestimmte Teilmenge von Daten beschränkt. Diese Ansichten bieten eine flexible Möglichkeit, Folgendes zu implementieren:

  • Identitätsweitergabe auf tieferen Ebenen: Erzwingen Sie detaillierte Datenberechtigungen auf Nutzerebene, die dafür sorgen, dass Nutzer nur auf ihren eigenen Daten kontext zugreifen können. Eine Anwendung kann beispielsweise dafür sorgen, dass Nutzer oder Mandanten nur Zeilen abrufen, die sich innerhalb ihrer festgelegten Grenzen befinden.
  • Vereinfachte Nutzerverwaltung: Verwenden Sie eine einzelne Datenbankrolle für alle Datenbank nutzer anstelle einer separaten Rolle für jeden Nutzer.
  • Parameterisolation: Parametrisierte Ansichten mindern Risiken, indem sie Werte als isolierten Kontext übergeben, der außerhalb der Kontrolle von LLM oder Endnutzern liegt. Da diese Werte vom Abfragetext getrennt sind, können sie von einem Nutzer oder einem KI-Agenten, der die Abfrage generiert, nicht manipuliert werden.
  • Minderung von SQL-Injection: Beim Erstellen von Anwendungen kann das Ersetzen von Parametern auf der Clientseite im Abfragetext zu einer Manipulation der Abfrage führen. Parametrisierte Ansichten mindern dieses Risiko, indem sie die Parameterbindung serverseitig durchführen, nachdem die Abfragestruktur geparst wurde. So wird SQL-Injection verhindert, da von Angreifern kontrollierte Werte die Struktur der Abfrage nicht ändern können.

Betrachten Sie beispielsweise eine Gesundheits-Tracking-Anwendung, in der medizinische Daten von Patienten gespeichert werden, einschließlich des Cholesterinspiegels. Wenn Patienten ihre eigenen Daten abfragen, kann ein böswilliger oder schlecht funktionierender Agent eine Abfrage generieren oder anfordern, mit der versucht wird, die Daten anderer Patienten abzurufen. Mit einer parametrisierten Ansicht erzwingt die Anwendung die Isolation von Patienten auf Datenbankebene. Die Ansicht wird mit einem Ansichtsparameter patient_id definiert:

CREATE VIEW patient_health_pv AS
(SELECT * FROM patient_health_records WHERE patient_id = CAST(VIEW_PARAMETERS('patient_id') AS BYTES))

Wenn der Client den cholesterol-Wert eines Patienten abfragen möchte:

SELECT readings['value'], readings['date']
FROM patient_health_pv
WHERE readings['test_name'] = 'cholesterol'

Da die Ansicht abgefragt wird, bindet und wendet Bigtable automatisch den Wert patient_id aus der isolierten Parameterzuordnung an. Das LLM oder der Endnutzer kann diesen Filter nicht ändern oder verwerfen. So wird eine robuste Bereichsbeschränkung auf Nutzerebene gewährleistet und SQL-Injection-Vektoren werden eliminiert.

Funktionsweise von parametrisierten Ansichten

Parametrisierte Ansichten verwenden einen Mechanismus namens Ansichtsparameter , um Kontext auf Anwendungsebene, z. B. eine Nutzer-ID, sicher an die Datenbank zu übergeben. Dazu werden die Werte der Ansichtsparameter als separater, isolierter Kontext mit der Abfrageanfrage übergeben. Bigtable kann während der Abfrageausführung auf diesen Kontext zugreifen, aber die Abfrage selbst kann den Kontext nicht lesen oder ändern.

Die Funktion VIEW_PARAMETERS() ist die SQL-Schnittstelle für den Zugriff auf diese Parameter in einer Ansichtsdefinition. Wenn Sie beispielsweise Daten nach der ID des Nutzers filtern möchten, der die Abfrage ausführt, können Sie Folgendes in die WHERE-Klausel Ihrer Ansicht aufnehmen:

CREATE VIEW purchase_history_pv AS
(SELECT * FROM purchases WHERE user_id = CAST(VIEW_PARAMETERS('user_id') AS BYTES))

Sie können VIEW_PARAMETERS() auch verwenden, um Spaltenqualifizierer zu parametrisieren. So kann die Ansicht bestimmte Felder dynamisch basierend auf dem bereitgestellten Anwendungskontext zurückgeben.

CREATE VIEW specific_test_result_pv AS
SELECT
  tests[VIEW_PARAMETERS('test_name')] AS reading,
  _timestamp AS reading_time
FROM patients

Unterschied zu Suchparametern

Ansichtsparameter funktionieren anders als Standardabfrageparameter:

  • Syntax und Kontext: Standardabfrageparameter werden mit der @param Syntax definiert und können nicht in einer Ansichtsdefinition, sondern nur in einer Abfrage deklariert werden. Auf Ansichtsparameter wird mit der VIEW_PARAMETERS('key') Funktion zugegriffen, die in jedem Abfrage- oder Ansichtskontext aufgerufen werden kann.
  • Fail-Closed-Verhalten: Wenn eine Ansichtsdefinition abgefragt wird, die einen VIEW_PARAMETERS('key') Verweis enthält, der entsprechende Wert aber nicht in der Zuordnung der Ansichtsparameter der Anfrage angegeben ist, schlägt die Abfrage sofort mit einem not found / missing parameter Fehler fehl. So wird verhindert, dass es zu einer versehentlichen Datenpanne kommt, wenn die Konfiguration falsch angewendet wird.

Beschränkungen

Für parametrisierte Ansichten gelten die folgenden Einschränkungen:

  • Sie können parametrisierte Ansichten nur aus logischen Ansichten erstellen. Sie erstellen eine neue parametrisierte logische Ansicht mit der Google Cloud CLI. Eine vorhandene logische Ansicht wird nicht geändert.
  • Ansichtsparameter unterstützen nur Werte vom Typ „String“. Wenn ein Parameter in der SQL-Definition Ihrer Ansicht einen anderen Datentyp darstellt, müssen Sie den Parameterwert als String übergeben und ihn in der Ansichtsdefinition umwandeln, z. B. CAST(VIEW_PARAMETERS('parameter_name') AS INT64).

Nächste Schritte