Présentation des vues sécurisées paramétrées

Ce document décrit les vues sécurisées paramétrées dans AlloyDB pour PostgreSQL, qui offrent la sécurité des données d'application et le contrôle des accès aux lignes tout en prenant en charge SQL. Ces vues sont compatibles avec l'extraction de valeurs de données (processus de récupération de données spécifiques à partir de colonnes) et aident à se protéger contre les attaques par injection de requête. Les vues sécurisées paramétrées permettent de s'assurer que les utilisateurs finaux ne peuvent voir que les données auxquelles ils sont censés accéder.

Les vues paramétrées sont une extension des vues PostgreSQL, qui vous permettent d'utiliser des paramètres de vue nommés spécifiques à l'application dans les définitions de vue. Cette fonctionnalité fournit une interface qui reçoit une requête et des valeurs pour les paramètres nommés. Les vues exécutent la requête avec ces valeurs, qui sont utilisées tout au long de l'exécution de cette requête.

Voici un exemple de vue sécurisée paramétrée:

CREATE VIEW secure_checked_items WITH (security_barrier) AS
       SELECT bag_id, timestamp, location
       FROM checked_items t
       WHERE customer_id = $@app_end_userid;

Vous pouvez interroger les vues à l'aide de la procédure stockée execute_parameterized_query ou en exécutant l'instruction EXECUTE .. WITH VIEW PARAMETERS.

Cas d'utilisation

Les vues sécurisées paramétrées sont particulièrement adaptées à l'administration de la sécurité des données au niveau de la base de données contre les requêtes ad hoc provenant de sources non approuvées, telles que les requêtes traduites à partir de requêtes en langage naturel. Prenons l'exemple d'une application dont la base de données suit les bagages enregistrés des clients en voyage. Ces clients peuvent envoyer des requêtes à l'application. Par exemple, un client dont l'ID utilisateur de l'application est 12345 peut saisir une requête dans l'application, par exemple "Où est mon sac ?".

Vous pouvez utiliser des vues sécurisées paramétrées pour appliquer les exigences suivantes à la manière dont AlloyDB exécute cette requête:

  • La requête ne peut lire que les objets et les colonnes de base de données que vous avez listés dans les vues sécurisées paramétrées de votre base de données.
  • La requête ne peut lire que les lignes de la base de données associées à l'utilisateur qui a envoyé la requête. Les lignes renvoyées ont une relation de données avec la ligne de tableau de l'utilisateur dont la valeur de la colonne d'ID est 12345.

Pour en savoir plus sur la configuration de la sécurité et du contrôle des accès, consultez la section Sécuriser et contrôler l'accès aux données de l'application à l'aide de vues sécurisées paramétrées.

Les vues sécurisées paramétrées permettent de réduire les risques de sécurité qui surviennent lorsque les utilisateurs finaux sont autorisés à exécuter des requêtes non approuvées, comme des requêtes en langage naturel, sur la table de la base de données. Voici quelques exemples de risques de sécurité:

  • Les utilisateurs peuvent envoyer des attaques par injection de requêtes et tenter de manipuler le modèle sous-jacent pour révéler toutes les données auxquelles l'application a accès.
  • Le LLM peut générer des requêtes SQL dont la portée est plus large que nécessaire pour des raisons de sécurité des données. Ce risque de sécurité peut exposer des données sensibles en réponse à des requêtes d'utilisateurs, même bien intentionnées.

Les vues sécurisées paramétrées vous permettent de définir les tables et les colonnes à partir desquelles les requêtes non approuvées peuvent extraire des données. Ces vues vous permettent de limiter la plage de lignes disponibles pour un utilisateur d'application spécifique. Ces restrictions vous permettent également de contrôler étroitement les données que les utilisateurs de l'application peuvent afficher à l'aide de requêtes en langage naturel, quelle que soit la formulation de ces requêtes.

Mécanisme de sécurité

Les vues sécurisées paramétrées offrent aux développeurs d'applications la sécurité des données et le contrôle des accès aux lignes à l'aide des méthodes suivantes:

  • Les vues créées à l'aide de l'option WITH (security barrier) offrent une sécurité au niveau des lignes en empêchant les fonctions et les opérateurs choisis de manière malveillante de transmettre des valeurs à partir des lignes avant que la vue n'ait terminé son travail. Pour en savoir plus sur la clause WITH (security barrier), consultez la section Règles et droits d'accès.
  • La paramétrisation à l'aide de paramètres de vue nommés permet d'afficher une vue limitée de la base de données paramétrée par des valeurs fournies par l'application en fonction de la sécurité au niveau de l'application, comme l'authentification de l'utilisateur final. Pour en savoir plus, consultez
  • Application de restrictions supplémentaires sur les requêtes accédant aux vues paramétrées, ce qui empêche les attaques visant à contourner les vérifications dans les vues en fonction des valeurs de paramètre données. Pour en savoir plus, consultez la section Restrictions appliquées aux requêtes.

Limites

  • Si une vue paramétrée est référencée dans une fonction définie par l'utilisateur appelée à l'aide de l'une des API utilisées dans les vues sécurisées paramétrées, une erreur se produit. Vous devez référencer directement la vue paramétrée dans la requête parente.

  • Vous devez activer l'indicateur de vue paramétrée séparément pour chaque instance d'AlloyDB. Les objets de vue paramétrés créés sur l'instance principale sont propagés aux réplications en lecture seule et aux réplications interrégionales. Toutefois, le paramètre d'indicateur parameterized_views.enabled n'est pas répliqué automatiquement et doit être répliqué manuellement sur chaque instance. Pour en savoir plus, consultez la section Avant de commencer. Vous ne pouvez pas interroger des vues paramétrées sur le réplica avant d'activer l'indicateur parameterized_views.enabled sur chaque instance de réplica. Cette limitation ne s'applique pas à l'instance de secours.

Étape suivante