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

Cette page décrit les vues sécurisées paramétrées dans AlloyDB pour PostgreSQL, qui assurent la sécurité des données des applications et le contrôle de l'accès aux lignes à l'aide de vues SQL. Elles permettent de s'assurer que les utilisateurs des applications ne peuvent consulter que les données auxquelles ils sont censés avoir accès.

Les vues sécurisées paramétrées sont une extension des vues sécurisées 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 accepte une requête et des valeurs pour les paramètres nommés. L'interface exécute la requête avec ces valeurs, qui sont utilisées 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 procédure stockée 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 de 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 idéales pour gérer 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 d'implémenter un contrôle d'accès précis.

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 les éléments suivants :

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).

Réduction des risques associés à la sécurité

Les vues sécurisées paramétrées permettent d'atténuer 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. Voici quelques exemples de risques :

  • Requêtes malveillantes : les utilisateurs peuvent essayer de manipuler le modèle sous-jacent pour accéder à toutes les données de l'application.
  • Requêtes SQL à portée étendue : 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 individuels. Ce contrôle assure la sécurité des données, quelle que soit la façon dont les utilisateurs formulent leurs requêtes.

Gestion des accès aux données

Les vues sécurisées paramétrées permettent de relever les défis courants liés à la gestion de l'accès aux données pour un nombre d'utilisateurs important et en constante augmentation.

  • 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 dans lesquelles 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 (avec 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 sur les tables de base peuvent ne pas s'appliquer 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, consultez Règles de sécurité 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 de l'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 tant que la vue n'a pas terminé son travail. Pour en savoir plus sur la clause WITH (security barrier), consultez Règles et droits d'accès.
  • 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, comme l'authentification de l'utilisateur final.
  • L'application de restrictions supplémentaires aux requêtes accédant aux vues paramétrées est utile pour les applications qui exécutent des requêtes non fiables provenant d'utilisateurs finaux, comme celles générées par une génération d'IA du langage naturel vers SQL. Cela empêche de sortir de l'enveloppe de sécurité fournie par les vues sécurisées paramétrées et de gérer l'utilisation des ressources. Pour en savoir plus, consultez Restrictions appliquées aux requêtes.

Limites

  • Vous devez activer l'indicateur 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 répliques interrégionales. Toutefois, le paramètre de l'option parameterized_views.enabled n'est pas appliqué automatiquement et doit être défini manuellement sur chaque instance. Pour en savoir plus, consultez Avant de commencer.

    Vous ne pouvez pas interroger des vues paramétrées sur une instance de pool de lecture ni sur un réplica multirégional avant d'activer l'indicateur parameterized_views.enabled sur chaque instance.

Étapes suivantes