Les vues sécurisées paramétrées dans AlloyDB pour PostgreSQL vous permettent de limiter l'accès aux lignes en fonction de paramètres nommés spécifiques à l'application, tels que les identifiants des utilisateurs de l'application. Ces vues étendent les vues PostgreSQL pour protéger votre base de données lors de l'exécution de requêtes non fiables en appliquant automatiquement des restrictions à chaque requête.
Pour en savoir plus, consultez Présentation des vues sécurisées paramétrées et Sécuriser et contrôler l'accès aux données d'application à l'aide de vues sécurisées paramétrées.
Avant de commencer
Cette page suppose que vous avez créé un cluster et une instance AlloyDB. Pour en savoir plus, consultez Créer une base de données.
Avant d'utiliser des vues sécurisées paramétrées, vous devez effectuer les opérations suivantes :
Activez l'indicateur de base de données
parameterized_views.enabled, qui charge les bibliothèques d'extensions requises. Vous devez activer cette option, même si elle a déjà été activée par l'équipe AlloyDB. Pour en savoir plus sur l'activation de l'indicateur de base de données, consultez Configurer les indicateurs de base de données d'une instance.Utilisez AlloyDB Studio ou
psqlpour créer l'extensionparameterized_viewsdans n'importe quelle base de données où vous souhaitez créer une vue paramétrée :-- Requires parameterized_views.enabled set to true CREATE EXTENSION parameterized_views;Lorsque l'extension est créée, un schéma nommé
parameterized_viewsest également créé par le système afin que les API soient contenues dans l'espace de noms de ce schéma et qu'elles n'entrent pas en conflit avec les API existantes.
Créer une vue sécurisée paramétrée
Pour créer une vue sécurisée paramétrée, procédez comme suit :
Exécutez la commande LDD
CREATE VIEW, comme illustré dans l'exemple suivant :CREATE VIEW secure_checked_items WITH (security_barrier) AS SELECT bag_id, timestamp, location FROM checked_items t WHERE customer_id = $@app_end_userid;Dans l'exemple précédent, la vue sécurisée paramétrée permet d'accéder à trois colonnes d'une table nommée
checked_items. La vue limite les résultats aux lignes oùchecked_items.customer_idcorrespond à un paramètre obligatoire.Utilisez les attributs suivants :
- Créez la vue à l'aide de l'option
security_barrier. - Pour limiter les utilisateurs de l'application afin qu'ils ne puissent afficher que les lignes auxquelles ils sont autorisés à accéder, ajoutez les paramètres requis dans la définition de la vue à l'aide de la syntaxe
$@PARAMETER_NAME. Un cas d'utilisation courant consiste à vérifier la valeur d'une colonne dans la clauseWHEREà l'aide deCOLUMN = $@PARAMETER_NAME. $@PARAMETER_NAMEindique un paramètre de vue nommé. Sa valeur est fournie lorsque vous utilisez l'APIexecute_parameterized_query. Les paramètres de vue nommés doivent respecter les exigences suivantes :- Les paramètres de vue nommée doivent commencer par une lettre (a-z).
- Vous pouvez utiliser des lettres avec des signes diacritiques et des lettres non latines, ainsi qu'un trait de soulignement (
_). - Les caractères suivants peuvent être des lettres, des traits de soulignement ou des chiffres (
0-9). - Les paramètres de vue nommés ne peuvent pas contenir
$. - Les paramètres de vue nommée sont sensibles à la casse. Par exemple,
$@PARAMETER_NAMEest interprété différemment de$@parameter_name.
- Créez la vue à l'aide de l'option
Accordez l'autorisation
SELECTsur la vue à tout utilisateur de base de données autorisé à interroger la vue.Accordez l'autorisation
USAGEsur le schéma contenant les tables définies dans la vue à tout utilisateur de base de données autorisé à interroger la vue.
Pour en savoir plus, consultez Sécuriser et contrôler l'accès aux données d'application à l'aide de vues sécurisées paramétrées.
Configurer la sécurité de votre application
Pour configurer la sécurité de vos applications à l'aide de vues sécurisées paramétrées, procédez comme suit :
Créez les vues paramétrées sécurisées en tant qu'utilisateur avec accès administrateur. Cet utilisateur est un utilisateur de base de données AlloyDB qui effectue des opérations d'administration pour l'application, y compris la configuration de la base de données et l'administration de la sécurité.
Créez un rôle de base de données pour exécuter des requêtes sur des vues sécurisées paramétrées. Il s'agit d'un rôle de base de données AlloyDB que l'application utilise pour se connecter à la base de données et s'y connecter, ainsi que pour exécuter des requêtes sur des vues paramétrées.
Accordez les autorisations du nouveau rôle aux vues sécurisées, ce qui inclut généralement les droits
SELECTsur les vues etUSAGEsur les schémas.Limitez les objets auxquels ce rôle peut accéder à l'ensemble minimal requis de fonctions et d'objets publics dont l'application a besoin. Évitez de fournir l'accès à des schémas et des tables qui ne sont pas publics.
Pour limiter les risques de sécurité, révoquez l'accès de ce rôle à tous les schémas ou objets sensibles qui ne sont pas strictement requis par le rôle.
Lorsque vous interrogez les vues, l'application fournit les valeurs des paramètres de vue requis, qui sont liés à l'identité de l'utilisateur de l'application.
Pour en savoir plus sur la création d'utilisateurs de base de données, consultez Créer un utilisateur de base de données.
Interroger une vue sécurisée paramétrée
Pour interroger une vue sécurisée paramétrée, utilisez l'une des options suivantes qui correspond le mieux à votre cas d'utilisation :
Basée sur JSON : utilisez cette API pour exécuter la requête en une seule fois et renvoyer des lignes JSON.
Basée sur CURSOR : utilisez cette API lorsque vous avez des requêtes plus longues ou lorsque vous avez des requêtes volumineuses et que vous souhaitez récupérer le résultat par lots. La fonction
execute_parameterized_queryfournie par l'extensionparameterized_viewsaccepte un nom de curseur.Instruction
PREPARE EXECUTE: utilisez-la pour les instructions préparées qui peuvent être exécutées plusieurs fois avec différentes valeurs de paramètre.
Pour interroger des vues sécurisées paramétrées, vous utilisez la fonction execute_parameterized_query() fournie par l'extension parameterized_views.
API JSON
Exécutez la fonction execute_parameterized_query(), qui utilise la syntaxe suivante :
SELECT * FROM
parameterized_views.execute_parameterized_query(
query => SQL_QUERY,
param_names => ARRAY [PARAMETER_NAMES],
param_values => ARRAY [PARAMETER_VALUES]
)
Remplacez les éléments suivants :
SQL_QUERY: requête SQL dont la clauseFROMfait référence à une ou plusieurs vues sécurisées paramétrées.PARAMETER_NAMES: liste de noms de paramètres à transmettre sous forme de chaînes.PARAMETER_VALUES: liste des valeurs de paramètres à transmettre.Cette liste doit avoir la même taille que la liste
param_names, où l'ordre des valeurs correspond à l'ordre des noms.Le type exact des valeurs est déduit de la requête et de la définition de la vue paramétrée. Les conversions de type sont effectuées si nécessaire et lorsque cela est possible pour la valeur de paramètre donnée. En cas de non-concordance des types, une erreur est générée.
La fonction renvoie une table d'objets JSON. Chaque ligne de la table équivaut à la valeur ROW_TO_JSON() de la ligne de résultat de la requête d'origine.
Utilisez l'exemple suivant pour interroger une vue sécurisée paramétrée :
SELECT * FROM
parameterized_views.execute_parameterized_query(
query => 'SELECT * FROM secure_checked_items',
param_names => ARRAY ['app_end_userid'],
param_values => ARRAY ['40']
)
L'utilisation de cette API limite la taille de l'ensemble de résultats en fonction de la taille exprimée en kilo-octets (ko) des résultats et du nombre de lignes. Vous pouvez configurer ces limites à l'aide des options parameterized_views.json_results_max_size et parameterized_views.json_results_max_rows.
API CURSOR
Cette API présente des limites, car elle déclare un curseur pour la requête donnée. Par conséquent, la requête doit être compatible avec les curseurs PostgreSQL.
Par exemple, l'API CURSOR n'est pas compatible avec les instructions DO ou SHOW.
Cette API ne limite pas non plus les résultats en fonction de la taille ou du nombre de lignes renvoyées.
Exécutez la fonction execute_parameterized_query(), qui crée et renvoie un CURSOR limité à la transaction que vous utilisez pour récupérer les résultats de la requête :
SELECT * FROM
parameterized_views.execute_parameterized_query(
query => SQL_QUERY,
cursor_name => CURSOR_NAME,
param_names => ARRAY [PARAMETER_NAMES],
param_values => ARRAY [PARAMETER_VALUES]
)
Remplacez les éléments suivants :
SQL_QUERY: requête SQL dont la clauseFROMfait référence à une ou plusieurs vues sécurisées paramétrées.CURSOR_NAME: nom du curseur à déclarer.PARAMETER_NAMES: liste de noms de paramètres à transmettre sous forme de chaînes.PARAMETER_VALUES: liste des valeurs de paramètres à transmettre. Cette liste doit avoir la même taille que la listeparam_names, où l'ordre des valeurs correspond à l'ordre des noms. Le type exact des valeurs est déduit de la requête et de la définition de la vue paramétrée. Les conversions de type sont effectuées si nécessaire et lorsque cela est possible pour la valeur de paramètre donnée. En cas d'incompatibilité de type, une erreur est générée.
Utilisez l'exemple suivant pour interroger une vue sécurisée paramétrée :
-- Start a transaction, which is the default lifetime of a CURSOR
BEGIN;
-- Create a cursor called 'mycursor'
SELECT * FROM parameterized_views.execute_parameterized_query(
query => 'SELECT * FROM secure_checked_items',
cursor_name => 'mycursor',
param_names => ARRAY ['app_end_userid'],
param_values => ARRAY ['40']
);
-- Fetch the results
FETCH ALL FROM mycursor;
-- End the transaction, which cleans up the cursor
END;
Le curseur renvoyé est un curseur NO SCROLL WITHOUT HOLD. Vous ne pouvez pas utiliser le curseur pour récupérer des lignes de manière non séquentielle, par exemple dans le sens inverse. Vous ne pouvez pas utiliser le curseur en dehors de la transaction qui l'a créé.
Instruction PREPARE
Utilisez la commande PREPARE .. AS RESTRICTED pour créer une instruction préparée qui référence des vues paramétrées. Ces instructions préparées acceptent les paramètres positionnels et appliquent diverses restrictions lorsque vous les exécutez.
Pour en savoir plus sur la façon dont les vues sécurisées paramétrées appliquent la sécurité, consultez Mécanisme de sécurité.
Cette fonctionnalité étend les commandes PREPARE et EXECUTE pour accepter les paramètres de vue nommés. Utilisez des instructions préparées pour éviter la surcharge liée à l'analyse et à la réécriture à chaque exécution de l'instruction, ce qui peut entraîner des gains de performances significatifs, en particulier pour les requêtes complexes ou fréquemment exécutées. Une instruction préparée est un objet côté serveur qui peut optimiser les performances en précompilant et en stockant une instruction SQL paramétrée pour une exécution ultérieure.
Cette API présente des limites, car l'instruction doit être autorisée dans une instruction PREPARE, ce qui signifie que seules les instructions SELECT et VALUES sont acceptées.
Cette API ne limite pas non plus les résultats en fonction de la taille ou du nombre de lignes renvoyées.
Pour créer une instruction préparée qui référence des vues paramétrées, exécutez la commande PREPARE .. AS RESTRICTED :
PREPARE pquery (POSITIONAL_PARAM_TYPES)
AS RESTRICTED SQL_QUERY;
EXECUTE pquery (POSITIONAL_PARAM_VALUES)
WITH VIEW PARAMETERS (VIEW_PARAM_NAME1 = VIEW_PARAM_VALUE1[, ...]);
Remplacez les éléments suivants :
POSITIONAL_PARAM_TYPES: un ou plusieurs types de données de paramètres positionnels utilisés dans la requêteRESTRICTED.SQL_QUERY: requête SQL pouvant faire référence à des vues paramétrées.POSITIONAL_PARAM_VALUES: valeurs réelles qui remplacent les paramètres positionnels définis dans l'instructionPREPARE.VIEW_PARAM_NAME: nom du paramètre attendu par les vues paramétrées référencées dans la requêteRESTRICTED.VIEW_PARAM_VALUE: valeurs réelles transmises aux paramètresVIEW_PARAM_NAMEcorrespondants des vues paramétrées.
Pour inclure des paramètres dans une instruction préparée, vous devez fournir une liste de types de données dans l'instruction PREPARE. Dans l'instruction que vous préparez, vous faites référence aux paramètres par position en utilisant, par exemple, $1 et $2.
Utilisez la commande EXECUTE .. WITH VIEW PARAMETERS pour exécuter une instruction préparée précédemment que vous avez créée à l'aide de la commande PREPARE .. AS RESTRICTED.
Si l'instruction PREPARE qui a créé l'instruction a spécifié des paramètres positionnels, vous devez transmettre un ensemble de paramètres compatible à l'instruction EXECUTE. Vous devez transmettre tous les paramètres de vue nommés requis par les vues paramétrées dans la clause WITH VIEW PARAMETERS.
Utilisez l'exemple suivant pour interroger une vue sécurisée paramétrée :
PREPARE pquery (timestamp) AS RESTRICTED SELECT * FROM secure_checked_items WHERE timestamp > $1;
EXECUTE pquery (current_date - 1) WITH VIEW PARAMETERS (app_end_userid = 40);
EXECUTE pquery (current_date - 30) WITH VIEW PARAMETERS (app_end_userid = 40);
Restrictions appliquées aux requêtes
Voici la liste des opérations limitées pour les requêtes que vous exécutez à l'aide des options décrites dans Interroger une vue sécurisée paramétrée :
Toute invocation récursive d'API (
execute_parameterized_queryou à l'aide deEXECUTE .. WITH VIEW PARAMETERS) est interdite, de sorte que seules les valeurs spécifiées par l'application sont utilisées. Cette restriction empêche également l'utilisation de la requête pour contourner l'enveloppe de sécurité de l'ensemble de valeurs de paramètres donné.Certaines extensions qui démarrent une nouvelle session en arrière-plan ne sont pas autorisées, y compris les extensions
dblink,pg_cronetpg_background.Les constructions de requête suivantes sont autorisées ou limitées :
Les instructions
SELECTen lecture seule sont autorisées.Les instructions
SHOW,CALLetDOen lecture seule sont autorisées.Les instructions LMD telles que
INSERT,UPDATEetDELETEne sont pas autorisées.Les instructions LDD telles que
CREATE TABLEetALTER TABLEne sont pas autorisées.Les autres types d'instructions tels que
LOAD,SET,CLUSTER,LOCK,CHECKPOINTetEXPLAINne sont pas autorisés.
Les instructions
EXPLAINsont interdites par défaut pour éviter les attaques par canal caché utilisant des plans de requête. Pour en savoir plus, consultez Canal caché. Toutefois, pour exécuter des instructionsEXPLAIN, tout utilisateur de base de données disposant de droits de super-utilisateur AlloyDB peut définir le GUCparameterized_views.enable_explainau niveau de la session suron.Les vues sécurisées paramétrées fournissent des paramètres pour vous aider à gérer les ressources utilisées par les API pour interroger les vues paramétrées, telles que
parameterized_views.statement_timeout. Pour en savoir plus, consultez Indicateurs de base de données compatibles.
Répertorier toutes les vues paramétrées
Utilisez l'extension parameterized_views pour lister toutes les vues paramétrées de la base de données à l'aide de la vue all_parameterized_views. Le résultat de cette vue est identique à celui de la vue de catalogue pg_views, mais all_parameterized_views ne liste que les vues avec des paramètres de vue nommés.
Pour lister les vues paramétrées, exécutez la requête suivante :
SELECT * FROM parameterized_views.all_parameterized_views;
Le résultat ressemble à ce qui suit :
schemaname | viewname | viewowner | definition
-----------+----------------------+-----------+---------------------------------------------------------
public | secure_checked_items | postgres | SELECT checked_items.bag_id, +
| | | checked_items."timestamp", +
| | | checked_items.location +
| | | FROM checked_items +
| | | WHERE (checked_items.customer_id = $@app_end_userid);
Pour lister une vue paramétrée dans all_parameterized_views, assurez-vous qu'elle contient au moins un paramètre de vue nommé dans sa définition.
Étapes suivantes
- En savoir plus sur les vues sécurisées paramétrées
- Découvrez comment sécuriser et contrôler l'accès aux données d'application à l'aide de vues sécurisées paramétrées.