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

Les vues sécurisées paramétrées dans AlloyDB pour PostgreSQL vous permettent d'appliquer un contrôle des accès aux lignes au niveau de l'application afin que les utilisateurs ne puissent afficher que les données auxquelles ils sont autorisés à accéder. Conçues comme une extension des vues sécurisées PostgreSQL, ces vues vous permettent d'inclure des paramètres nommés spécifiques à l'application dans les définitions de vue et de transmettre des valeurs de paramètre qui s'appliquent tout au long de l'exécution de la 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 des vues sécurisées paramétrées à l'aide de la fonction execute_parameterized_query ou en exécutant l'instruction EXECUTE .. WITH VIEW PARAMETERS. Pour en savoir plus, consultez Gérer la sécurité des données d'application à l'aide des vues sécurisées paramétrées AlloyDB.

Avantages des vues sécurisées paramétrées

Les vues sécurisées paramétrées sont bien adaptées à la gestion de la sécurité des données au niveau de la base de données, en particulier lorsque vous traitez des requêtes ad hoc provenant de sources non fiables, telles que celles traduites à partir du langage naturel. Ces vues offrent un moyen flexible de mettre en œuvre un contrôle ultraprécis des accès.

Prenons l'exemple d'une application qui suit les bagages enregistrés des clients. Un client dont l'ID utilisateur est 12345 demande : "Où est mon sac ?" Dans ce scénario, les vues sécurisées paramétrées garantissent que la requête ne renvoie que les lignes accessibles à l'utilisateur qui l'a envoyée (par exemple, les lignes associées à l'ID utilisateur 12345).

Atténuation des risques de sécurité

Les vues sécurisées 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 sont les suivants :

  • Requêtes malveillantes : 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 sécurisées paramétrées, vous pouvez limiter la plage de lignes disponibles pour les utilisateurs d'applications individuelles. Ce contrôle permet de protéger les données de l'application, quelle que soit la formulation des requêtes des utilisateurs.

Gestion des accès aux données

Les vues sécurisées paramétrées répondent aux défis courants liés à la gestion de l'accès aux données pour un nombre important et croissant d'utilisateurs.

  • Gestion simplifiée des utilisateurs : avec les vues sécurisées paramétrées, vous pouvez utiliser un seul rôle de base de données pour tous les utilisateurs finaux, au lieu d'utiliser des méthodes qui peuvent vous obliger à créer un utilisateur ou un rôle de base de données distinct pour chaque utilisateur final. Les vues sécurisées paramétrées permettent de simplifier la gestion des utilisateurs et des connexions pour les applications où chaque utilisateur final n'a besoin d'accéder qu'à ses données.

    Par exemple, dans une application de compagnie aérienne où les clients ne doivent voir que leurs propres réservations, vous pouvez définir une seule vue sécurisée paramétrée par l'identifiant de l'utilisateur final. Cette vue permet à un seul rôle de base de données (ayant accès à la vue, et non à la table sous-jacente) de servir tous les utilisateurs, ce qui simplifie la gestion des utilisateurs et les connexions à la base de données.

  • Application simplifiée de la sécurité : les vues sécurisées paramétrées intègrent intrinsèquement des contrôles d'accès. Lorsqu'une vue est interrogée, les paramètres de sécurité définis sont appliqués de manière cohérente, quel que soit l'utilisateur qui accède à la vue. Cette approche contraste avec les situations où les règles de sécurité sous-jacentes des tables de base ne s'appliquent pas automatiquement aux vues sans configuration supplémentaire.

Pour en savoir plus sur les mécanismes de sécurité existants dans PostgreSQL, tels que les règles de sécurité au niveau des lignes (RLS), consultez Règles de sécurité au niveau des lignes.

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) assurent la sécurité au niveau des lignes en empêchant les fonctions et les opérateurs choisis de manière malveillante de recevoir des valeurs de lignes avant que la vue n'ait terminé son travail. Pour en savoir plus sur la clause WITH (security_barrier), consultez Règles et droits.
  • La paramétrisation à l'aide de paramètres de vue nommés permet d'obtenir une vue restreinte 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, telle que l'authentification de l'utilisateur final.
  • L'application de restrictions supplémentaires sur les requêtes accédant aux vues paramétrées est utile pour les applications qui exécutent des requêtes non fiables d'utilisateurs finaux, comme celles générées par la génération de langage naturel vers SQL par IA. Cette application empêche les requêtes d'échapper à l'enveloppe de sécurité fournie par les vues sécurisées paramétrées et permet de gérer l'utilisation des ressources. Pour en savoir plus sur les restrictions de requête, consultez Restrictions appliquées aux requêtes.

Limites

  • Vous devez activer l'option de vue paramétrée séparément sur chaque instance d'AlloyDB. Les objets de vue paramétrés créés sur l'instance principale sont propagés aux instances de pool de lecture et aux instances répliquées interrégionales. Toutefois, le paramètre d'option parameterized_views.enabled n'est pas appliqué automatiquement et doit être défini manuellement sur chaque instance. Pour plus d'informations, consultez la section Avant de commencer.

    Vous ne pouvez pas interroger des vues paramétrées sur une instance de pool de lecture ou sur une instance répliquée interrégionale avant d'activer l'option parameterized_views.enabled sur chaque instance.

Étapes suivantes