Présentation des vues paramétrées

Ce document décrit les vues paramétrées dans Spanner. Les vues paramétrées vous permettent de filtrer dynamiquement les données en fonction des paramètres de session transmis avec les requêtes, en particulier pour les applications et les systèmes agentiques qui utilisent des grands modèles de langage (LLM).

Les vues paramétrées étendent les fonctionnalités des vues de base de données en injectant des paramètres de contexte directement dans une définition de vue. Les vues paramétrées vous aident à :

  • Transmettez des paramètres de contexte au moment de la requête, tels que l'identité de l'utilisateur ou du locataire, dans une définition de vue.
  • Limitez les résultats de la requête aux lignes correspondant aux paramètres fournis.
  • Empêchez les utilisateurs de contourner les filtres de données au niveau de l'application dans les requêtes SQL générées ou ad hoc.

Pour en savoir plus, consultez Créer une vue paramétrée.

Fonctionnement des vues paramétrées

Les vues paramétrées utilisent des paramètres pour transmettre de manière sécurisée le contexte au niveau de l'application, tel qu'un ID utilisateur, à la base de données. Lorsque votre application exécute une requête, elle envoie le contexte avec l'instruction de requête. Spanner accède à ce contexte pendant l'exécution, mais ni la requête, ni l'utilisateur de l'application ne peuvent le lire ou le modifier.

La fonction SECURE_CONTEXT() fournit l'interface SQL permettant d'accéder à ces paramètres sécurisés dans une définition de vue. Les vues paramétrées nécessitent le modèle de sécurité Vue des droits du définisseur, dans lequel la vue utilise SECURE_CONTEXT() pour accéder aux valeurs et filtrer les résultats.

Par exemple, pour filtrer les données en fonction de l'ID de l'utilisateur qui effectue la requête, vous pouvez inclure les éléments suivants dans la clause WHERE de votre vue :

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

Cela permet à l'application de voir ses données, mais pas celles des autres. Vous pouvez également créer une vue permettant aux modérateurs d'afficher des données moins sensibles de n'importe quel utilisateur :

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

Bien que vous puissiez utiliser SECURE_CONTEXT() n'importe où dans une définition de requête de vue, la bonne pratique pour les performances consiste à l'utiliser dans la clause WHERE pour filtrer sur la ou les colonnes de clé principales d'une table ou d'un index. Cela garantit que Spanner transmet efficacement la logique de filtre à la couche de stockage.

Par défaut, l'interrogation de la fonction SECURE_CONTEXT() directement dans une requête ad hoc échoue, sauf si le rôle de base de données dispose du rôle spanner_secure_context_reader. Cela empêche les utilisateurs non privilégiés d'inspecter directement les valeurs des paramètres.

Un modèle recommandé consiste à combiner des vues paramétrées avec des vues de droits de l'auteur et un contrôle ultraprécis des accès. Pour vous assurer que les utilisateurs ne peuvent interroger les données que via la vue :

  1. Activez le contrôle des accès précis et créez un rôle de base de données pour votre application.
  2. GRANT le droit SELECT sur la vue au rôle.
  3. Assurez-vous que le rôle système public ne dispose d'aucun droit sur les tables ou vues de base.

Exemple :

-- 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;

Une fois la vue paramétrée créée, le processus d'une requête type est le suivant :

  1. Votre application définit le contexte sécurisé sur une requête. Le contexte contient des informations qui identifient l'utilisateur de l'application, telles qu'un ID utilisateur ou un rôle.
  2. L'application exécute une requête sur une vue des droits du définisseur.
  3. La vue utilise la fonction SECURE_CONTEXT() dans une clause WHERE pour filtrer les lignes en fonction des valeurs fournies dans le contexte sécurisé.
  4. Spanner ne renvoie que les lignes correspondant au filtre, ce qui permet de filtrer efficacement les résultats de la requête en fonction des données associées au contexte de session de l'utilisateur.

Par exemple, une application peut transmettre l'ID de l'utilisateur actuel dans le contexte sécurisé à l'aide de l'une des bibliothèques clientes Spanner. L'exemple suivant utilise la bibliothèque cliente C++ pour définir le paramètre sécurisé user_id :

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

L'application exécute ensuite une requête SQL standard sur la vue. La vue utilise ce user_id dans sa clause WHERE pour ne renvoyer que les enregistrements appartenant à cet utilisateur :

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

Avantages des vues paramétrées

Les paramètres vous aident à atteindre les objectifs suivants :

  • Isoler les données des locataires dans les applications mutualisées : utilisez des paramètres pour vous assurer que les requêtes ne renvoient que les données d'un locataire spécifique.

  • Limiter les requêtes d'IA agentique : limitez les requêtes en langage naturel aux données d'un utilisateur ou d'un locataire.

  • Filtrer les données avec des identifiants éphémères : limitez l'accès aux données en fonction d'un ID utilisateur ou d'un ID de locataire qui n'existe pas dans Identity and Access Management (IAM).

  • Utiliser des identifiants privés pour le filtrage : filtrez les données à l'aide des valeurs requises pour la requête qui ne doivent pas être renvoyées à l'utilisateur final.

Atténuation des risques de sécurité

Les vues paramétrées permettent de limiter les risques de sécurité lorsque les utilisateurs finaux exécutent des requêtes non fiables (comme des requêtes en langage naturel) sur votre base de données. Ces risques incluent les suivants :

  • Prompts malveillants : les utilisateurs peuvent tenter de manipuler le modèle sous-jacent pour accéder à toutes les données de l'application.
  • Requêtes SQL à portée générale : les grands modèles de langage (LLM) peuvent générer des requêtes SQL qui exposent des données sensibles, même à partir de requêtes utilisateur bien intentionnées.

En utilisant des vues paramétrées, vous pouvez limiter la plage de lignes renvoyées aux utilisateurs d'applications individuelles, quelle que soit la manière dont les utilisateurs formulent leurs requêtes.

Bonnes pratiques

Suivez ces pratiques pour implémenter efficacement les vues paramétrées.

  • Combiner avec des vues de droits du créateur et le contrôle ultraprécis des accès : utilisez des paramètres dans le cadre d'un modèle de sécurité complet qui inclut des vues de droits du créateur et des rôles de contrôle ultraprécis des accès. N'accordez les droits du rôle SELECT que sur les vues, et assurez-vous que le rôle et le rôle système public ne disposent d'aucun droit sur les tables de base sous-jacentes.

  • Utilisez JSON pour les contextes complexes : pour transmettre un contexte structuré, tel qu'un utilisateur ayant plusieurs rôles, sérialisez les données sous forme de chaîne JSON. Transmettez la chaîne JSON en tant que paramètre unique. Utilisez les types JSON ou JSONB intégrés de Spanner pour extraire les valeurs de la vue.

  • Simplifiez l'accès avec les UDF SQL : si vous accédez fréquemment à des champs dans un contexte JSON structuré, créez des fonctions SQL définies par l'utilisateur (UDF) pour encapsuler la logique d'extraction. L'utilisation de fonctions définies par l'utilisateur dans vos vues améliore la lisibilité et la facilité de maintenance.

  • Se protéger contre l'injection de prompt avec Model Armor : lorsque vous générez des requêtes à l'aide de LLM avec des entrées utilisateur non fiables, utilisez Model Armor pour identifier et bloquer de manière proactive les tentatives d'injection de prompt et de jailbreak.

Limites

Les vues paramétrées présentent les limites suivantes :

  • Types d'arguments : la fonction SECURE_CONTEXT() nécessite un argument de chaîne littérale.
  • Types de résultats : la fonction SECURE_CONTEXT() renvoie une chaîne.
  • Interactions avec les fonctionnalités Spanner : vous ne pouvez pas utiliser SECURE_CONTEXT() dans les colonnes générées, les expressions de valeur de colonne par défaut ni dans les fonctions définies par l'utilisateur (UDF).
  • Barrières de sécurité : les vues paramétrées dans Spanner n'incluent pas de barrière de sécurité. Bien que tous les filtres soient appliqués avant de renvoyer les résultats de la requête, ils ne limitent pas nécessairement les données auxquelles on accède lors du traitement interne de la requête.

Étapes suivantes