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

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

Les vues sécurisées paramétrées sont une extension de 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 de mettre en œuvre un contrôle pré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 bagage ?". Dans ce scénario, les vues sécurisées paramétrées garantissent les points 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 de réduire 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 :

Invites 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 é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 individuels de l'application. Ce contrôle garantit la sécurité des données, 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 des accès aux données pour un nombre d'utilisateurs important et croissant.

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 (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 stratégies 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 stratégies de sécurité au niveau des lignes (RLS), consultez Stratégies 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' WITH (security barrier) option 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 de lignes jusqu'à ce que la vue ait terminé son travail. Pour en savoir plus sur la WITH (security barrier) clause, 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 aux requêtes accédant à des 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 de langage naturel vers SQL basée sur l'IA. Cela empêche de contourner 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ée 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 de l'indicateur 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'indicateur parameterized_views.enabled sur chaque instance.