Parametrisierte Ansichten – Übersicht

In diesem Dokument werden parametrisierte Ansichten in Spanner beschrieben. Mit parametrisierten Ansichten können Sie Daten dynamisch anhand von Sitzungsparametern filtern, die mit Abfragen übergeben werden. Das ist besonders für agentische Anwendungen und Systeme nützlich, die Large Language Models (LLMs) verwenden.

Parametrisierte Ansichten erweitern die Funktionen von Datenbankansichten, indem Kontextparameter direkt in eine Ansichtsdefinition eingefügt werden. Parametrisierte Ansichten bieten Ihnen folgende Möglichkeiten:

  • Übergeben Sie Kontextparameter zur Abfragezeit, z. B. Nutzer- oder Mandantenidentität, an eine Ansichtsdefinition.
  • Abfrageergebnisse auf die Zeilen beschränken, die den angegebenen Parametern entsprechen.
  • Verhindern, dass Nutzer Datenfilter auf Anwendungsebene in generierten oder Ad-hoc-SQL-Abfragen umgehen.

Weitere Informationen finden Sie unter Parametrisierte Ansicht erstellen.

Funktionsweise parametrisierter Ansichten

Parametrisierte Ansichten verwenden Parameter, um Kontext auf Anwendungsebene, z. B. eine Nutzer-ID, sicher an die Datenbank zu übergeben. Wenn Ihre Anwendung eine Abfrage ausführt, sendet sie den Kontext mit der Abfrageanweisung. Spanner greift während der Ausführung auf diesen Kontext zu, aber weder die Abfrage noch der Anwendungsnutzer können ihn lesen oder ändern.

Die Funktion SECURE_CONTEXT() stellt die SQL-Schnittstelle für den Zugriff auf diese sicheren Parameter innerhalb einer Ansichtsdefinition bereit. Parametrisierte Ansichten erfordern das Sicherheitsmodell Ansicht mit den Rechten des Erstellers, bei dem die Ansicht SECURE_CONTEXT() verwendet, um auf Werte zuzugreifen und Ergebnisse zu filtern.

Wenn Sie Daten beispielsweise nach der ID des Nutzers filtern möchten, der die Abfrage stellt, können Sie Folgendes in die WHERE-Klausel Ihrer Ansicht einfügen:

CREATE VIEW MyUserData
SQL SECURITY DEFINER AS
(SELECT *
FROM AllUserData
WHERE UserID = CAST(SECURE_CONTEXT('user_id'), INT));

Dadurch kann die Anwendung die Daten des Nutzers sehen, aber nicht die Daten anderer Nutzer. Sie können auch eine Ansicht erstellen, mit der Moderatoren weniger sensible Daten von beliebigen Nutzern sehen können:

CREATE VIEW SafeUserData
SQL SECURITY DEFINER AS
(SELECT UserID, AccountCreationTime, PublicProfileText
FROM AllUserData
WHERE SECURE_CONTEXT('role') = 'Moderator');

Sie können SECURE_CONTEXT() zwar an einer beliebigen Stelle in einer Ansichtsabfragedefinition verwenden, aber aus Leistungsgründen empfiehlt es sich, die Funktion in der WHERE-Klausel zu verwenden, um nach den führenden Schlüsselspalten einer Tabelle oder eines Index zu filtern. So wird die Filterlogik von Spanner effizient an die Speicherebene weitergeleitet.

Standardmäßig schlägt die Abfrage der Funktion SECURE_CONTEXT() direkt in einer Ad-hoc-Abfrage fehl, es sei denn, die Datenbankrolle hat die Rolle spanner_secure_context_reader. Dadurch wird verhindert, dass nicht privilegierte Nutzer Parameterwerte direkt prüfen können.

Ein empfohlenes Muster ist die Kombination von parametrisierten Ansichten mit Ansichten mit Erstellerrechten und detaillierter Zugriffssteuerung (FGAC). So sorgen Sie dafür, dass Nutzer nur über die Ansicht Daten abfragen können:

  1. Aktivieren Sie die detaillierte Zugriffssteuerung und erstellen Sie eine Datenbankrolle für Ihre Anwendung.
  2. GRANT Sie der Rolle die Berechtigung SELECT für die Ansicht.
  3. Achten Sie darauf, dass der Systemrolle public keine Berechtigungen für die Basistabellen oder Ansichten gewährt werden.

Beispiel:

-- Create a role for the application user
CREATE ROLE pv_user;

-- Grant SELECT permission on the view to the role
GRANT SELECT ON VIEW MyUserData TO ROLE pv_user;

Nachdem Sie die parametrisierte Ansicht erstellt haben, sieht der Prozess für eine typische Anfrage so aus:

  1. Ihre Anwendung legt den sicheren Kontext für eine Abfrageanfrage fest. Der Kontext enthält Informationen, die den Anwendungsnutzer identifizieren, z. B. eine Nutzer-ID oder Rolle.
  2. Die Anwendung führt eine Abfrage für eine Ansicht mit den Rechten des Erstellers aus.
  3. In der Ansicht wird die Funktion SECURE_CONTEXT() in einer WHERE-Klausel verwendet, um Zeilen anhand der im sicheren Kontext angegebenen Werte zu filtern.
  4. Spanner gibt nur die Zeilen zurück, die dem Filter entsprechen. Dadurch werden die Abfrageergebnisse effektiv auf die Daten gefiltert, die mit dem Sitzungskontext des Nutzers verknüpft sind.

Eine Anwendung kann beispielsweise die ID des aktuellen Nutzers im sicheren Kontext mithilfe einer der Spanner-Clientbibliotheken übergeben. Im folgenden Beispiel wird die C++-Clientbibliothek verwendet, um den sicheren Parameter user_id festzulegen:

(*request.mutable_secure_context())["user_id"] = "ca6095c4-1a68-44a8-9562-dd9e897326f0";

Die Anwendung führt dann eine Standard-SQL-Abfrage für die Ansicht aus. Die Ansicht verwendet diese user_id in ihrer WHERE-Klausel, um nur die Datensätze zurückzugeben, die zu diesem Nutzer gehören:

--Query executed by the application
SELECT * FROM MyUserData;

Vorteile parametrisierter Ansichten

Mit Parametern können Sie folgende Ziele erreichen:

  • Mandantendaten in mandantenfähigen Anwendungen isolieren: Verwenden Sie Parameter, damit Abfragen nur Daten für einen bestimmten Mandanten zurückgeben.

  • Abfragen an agentische KI einschränken: Abfragen in natürlicher Sprache auf die Daten eines Nutzers oder Mandanten beschränken.

  • Daten mit sitzungsspezifischen Anmeldedaten filtern: Beschränken Sie den Datenzugriff basierend auf einer Nutzer- oder Mandanten-ID, die in Identity and Access Management (IAM) nicht vorhanden ist.

  • Private Anmeldedaten zum Filtern verwenden: Daten werden mit Werten gefiltert, die für die Abfrage erforderlich sind, aber nicht an den Endnutzer zurückgegeben werden sollen.

Sicherheitsrisiken minimieren

Parametrisierte Ansichten helfen, Sicherheitsrisiken zu minimieren, wenn Endnutzer nicht vertrauenswürdige Abfragen wie Abfragen in natürlicher Sprache für Ihre Datenbank ausführen. Zu diesen Risiken gehören:

  • Böswillige Prompts: Nutzer versuchen möglicherweise, das zugrunde liegende Modell zu manipulieren, um auf alle Anwendungsdaten zuzugreifen.
  • Breit gefasste SQL-Abfragen: Large Language Models (LLMs) können SQL-Abfragen generieren, die sensible Daten offenlegen, selbst bei gut gemeinten Nutzeranfragen.

Mit parametrisierten Ansichten können Sie den Bereich der Zeilen einschränken, die an einzelne Anwendungsnutzer zurückgegeben werden, unabhängig davon, wie Nutzer ihre Abfragen formulieren.

Best Practices

Beachten Sie die folgenden Best Practices, um parametrisierte Ansichten effektiv zu implementieren.

  • Mit Ansichten mit Erstellerrechten und detaillierter Zugriffssteuerung kombinieren: Verwenden Sie Parameter als Teil eines umfassenden Sicherheitsmodells, das Ansichten mit Erstellerrechten und Rollen für die detaillierte Zugriffssteuerung umfasst. Gewähren Sie der Rolle SELECT nur Berechtigungen für die Ansichten und achten Sie darauf, dass die Rolle und die Systemrolle public keine Berechtigungen für die zugrunde liegenden Basistabellen haben.

  • JSON für komplexen Kontext verwenden: Wenn Sie strukturierten Kontext übergeben möchten, z. B. einen Nutzer mit mehreren Rollen, serialisieren Sie die Daten als JSON-String. Übergeben Sie den JSON-String als einzelnen Parameter. Verwenden Sie die integrierten JSON- oder JSONB-Funktionen von Spanner, um Werte in der Ansicht zu extrahieren.

  • Zugriff mit SQL-UDFs vereinfachen: Wenn Sie häufig auf Felder in einem strukturierten JSON-Kontext zugreifen, erstellen Sie benutzerdefinierte SQL-Funktionen (UDFs), um die Extraktionslogik zu kapseln. Die Verwendung von UDFs in Ihren Ansichten verbessert die Lesbarkeit und Wartbarkeit.

  • Mit Model Armor vor Prompt Injection schützen: Wenn Sie Abfragen mit LLMs mit nicht vertrauenswürdigen Nutzereingaben generieren, verwenden Sie Model Armor, um Prompt Injection- und Jailbreaking-Versuche proaktiv zu erkennen und zu blockieren.

Beschränkungen

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

  • Argumenttypen: Die Funktion SECURE_CONTEXT() erfordert ein Stringliteral-Argument.
  • Ergebnistypen: Die Funktion SECURE_CONTEXT() gibt einen String zurück.
  • Interaktionen mit Spanner-Features: Sie können SECURE_CONTEXT() nicht in generierten Spalten, Standardspaltenwertausdrücken oder in benutzerdefinierten Funktionen (UDFs) verwenden.
  • Sicherheitsbarrieren: Parametrisierte Ansichten in Spanner enthalten keine Sicherheitsbarriere. Alle Filter werden angewendet, bevor Abfrageergebnisse zurückgegeben werden. Sie schränken jedoch möglicherweise nicht ein, auf welche Daten während der internen Abfrageverarbeitung zugegriffen wird.

Nächste Schritte