Présentation des vues paramétrées

Dans Bigtable, vous pouvez utiliser des vues paramétrées pour filtrer dynamiquement les plages de données des vues logiques en fonction du contexte de l'application. Cette approche protège vos applications contre l'injection SQL et réduit le besoin de plusieurs vues statiques.

Pour gérer les informations sensibles, les vues paramétrées Bigtable utilisent un contexte isolé distinct du texte de la requête SQL. Étant donné que la base de données lie ces valeurs côté serveur, les utilisateurs et les agents d'IA ne peuvent pas manipuler les paramètres de requête. La base de données limite automatiquement l'accès aux données à votre contexte spécifique, quelle que soit la façon dont vous écrivez la requête.

Avantages des vues paramétrées

Les vues paramétrées sont bien adaptées à la gestion de la délimitation des données au niveau de la base de données, en particulier dans les applications qui traitent des requêtes de forme libre traduites à partir du langage naturel. La délimitation des données consiste à limiter les résultats de la requête à un sous-ensemble spécifique de données. Ces vues offrent un moyen flexible d'implémenter les éléments suivants :

  • Propagation d'identité de niveau profond : appliquez des autorisations de données précises au niveau de l'utilisateur, ce qui garantit que les utilisateurs ne peuvent accéder qu'à leur propre contexte de données. Par exemple, une application peut s'assurer que les utilisateurs ou les locataires ne récupèrent que les lignes qui se trouvent dans leur limite désignée.
  • Gestion simplifiée des utilisateurs : utilisez un seul rôle de base de données pour tous les utilisateurs de la base de données au lieu d'un rôle distinct pour chaque utilisateur.
  • Isolation des paramètres : les vues paramétrées atténuent les risques en transmettant les valeurs en tant que contexte isolé qui reste en dehors du contrôle du LLM ou de l'utilisateur final. Étant donné que ces valeurs sont conservées séparément du texte de la requête, un utilisateur ou un agent d'IA qui génère la requête ne peut pas les manipuler.
  • Atténuation de l'injection SQL : lors de la création d'applications, la substitution de paramètres côté client dans le texte de la requête peut entraîner une manipulation de la requête. Les vues paramétrées atténuent ce risque en effectuant la liaison des paramètres côté serveur après l'analyse de la structure de la requête. Cela empêche l'injection SQL, car les valeurs contrôlées par l'attaquant ne peuvent pas modifier la structure de la requête.

Prenons l'exemple d'une application de suivi de la santé qui stocke les dossiers médicaux des patients, y compris leur taux de cholestérol. Si les patients interrogent leurs propres données, un agent malveillant ou malveillant peut générer ou demander une requête qui tente de récupérer les dossiers d'autres patients. À l'aide d'une vue paramétrée, l'application applique l'isolation des patients au niveau de la base de données. La vue est définie avec un paramètre de vue patient_id :

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

Lorsque le client souhaite interroger la lecture du cholesterol d'un patient :

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

Étant donné que la vue est interrogée, Bigtable lie et applique automatiquement la valeur patient_id à partir de la carte de paramètres isolée. Le LLM ou l'utilisateur final n'a pas la possibilité de modifier ou de supprimer ce filtre, ce qui garantit une délimitation robuste au niveau de l'utilisateur et élimine les vecteurs d'injection SQL.

Fonctionnement des vues paramétrées

Les vues paramétrées utilisent un mécanisme appelé paramètres de vue pour transmettre en toute sécurité le contexte au niveau de l'application, tel qu'un ID utilisateur, à la base de données. Pour ce faire, les vues paramétrées transmettent les valeurs des paramètres de la vue en tant que contexte distinct et isolé avec la requête. Bigtable peut ensuite accéder à ce contexte lors de l'exécution de la requête, mais la requête elle-même ne peut pas lire ni modifier le contexte.

La fonction VIEW_PARAMETERS() est l'interface SQL permettant d'accéder à ces paramètres dans une définition de vue. 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 purchase_history_pv AS
(SELECT * FROM purchases WHERE user_id = CAST(VIEW_PARAMETERS('user_id') AS BYTES))

Vous pouvez également utiliser VIEW_PARAMETERS() pour paramétrer les qualificatifs de colonne. Cela permet à la vue de renvoyer des champs spécifiques de manière dynamique en fonction du contexte d'application fourni.

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

Différence par rapport aux paramètres de requête standards

Les paramètres de vue fonctionnent différemment des paramètres de requête standards :

  • Syntaxe et contexte : les paramètres de requête standards sont définis à l'aide de la @param syntaxe et ne peuvent pas être déclarés dans une définition de vue, mais uniquement dans une requête. Les paramètres de vue sont accessibles à l'aide de la fonction VIEW_PARAMETERS('key'), qui peut être appelée dans n'importe quel contexte de requête ou de vue.
  • Comportement en cas d'échec : si une définition de vue contenant une référence VIEW_PARAMETERS('key') est interrogée, mais que la valeur correspondante n'est pas fournie dans la carte des paramètres de vue de la requête, la requête échoue immédiatement avec une erreur not found / missing parameter. Cela empêche l'exposition accidentelle des données si la configuration est mal appliquée.

Limites

Les limites suivantes s'appliquent aux vues paramétrées :

  • Vous ne pouvez créer des vues paramétrées qu'à partir de vues logiques. Vous créez une vue logique paramétrée à l'aide de Google Cloud CLI. Vous ne modifiez pas une vue logique existante.
  • Les paramètres de vue n'acceptent que les valeurs de type chaîne. Si un paramètre représente un type de données différent dans la définition SQL de votre vue, vous devez transmettre la valeur de paramètre sous forme de chaîne et la caster dans la définition de la vue, par exemple CAST(VIEW_PARAMETERS('parameter_name') AS INT64).

Étape suivante