Sélectionner vos préférences de cookies

Nous utilisons des cookies essentiels et des outils similaires qui sont nécessaires au fonctionnement de notre site et à la fourniture de nos services. Nous utilisons des cookies de performance pour collecter des statistiques anonymes afin de comprendre comment les clients utilisent notre site et d’apporter des améliorations. Les cookies essentiels ne peuvent pas être désactivés, mais vous pouvez cliquer sur « Personnaliser » ou « Refuser » pour refuser les cookies de performance.

Si vous êtes d’accord, AWS et les tiers approuvés utiliseront également des cookies pour fournir des fonctionnalités utiles au site, mémoriser vos préférences et afficher du contenu pertinent, y compris des publicités pertinentes. Pour accepter ou refuser tous les cookies non essentiels, cliquez sur « Accepter » ou « Refuser ». Pour effectuer des choix plus détaillés, cliquez sur « Personnaliser ».

Sécurité et privilèges des procédures stockées - Amazon Redshift

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Sécurité et privilèges des procédures stockées

Cette rubrique décrit les informations d'identification de base de données nécessaires pour créer et exécuter des procédures stockées.

Par défaut, tous les utilisateurs disposent des privilèges nécessaires pour créer une procédure. Pour créer une procédure, vous devez disposer du privilège USAGE sur la langue PL/pgSQL, which is granted to PUBLIC by default. Only superusers and owners have the privilege to call a procedure by default. Superusers can run REVOKE USAGE on PL/pgSQL d'un utilisateur s'il souhaite empêcher l'utilisateur de créer une procédure stockée.

Pour appeler une procédure, vous devez disposer du privilège EXECUTE sur la procédure. Par défaut, le privilège EXECUTE pour les nouvelles procédures est accordé au propriétaire de la procédure et aux super-utilisateurs. Pour de plus amples informations, veuillez consulter GRANT.

L’utilisateur qui crée une procédure est le propriétaire par défaut. Par défaut, le propriétaire possède les privilèges CREATE, DROP et EXECUTE sur la procédure. Les super-utilisateurs disposent de tous les privilèges.

L’attribut SECURITY contrôle les privilèges d’une procédure relatifs à l’accès aux objets de base de données. Lorsque vous créez une procédure stockée, vous pouvez définir l’attribut SECURITY sur DEFINER ou INVOKER. Si vous spécifiez SECURITY INVOKER, la procédure utilise les privilèges de l’utilisateur invoquant la procédure. Si vous spécifiez SECURITY DEFINER, la procédure utilise les privilèges du propriétaire de la procédure. INVOKER est la valeur par défaut.

Parce qu’une procédure SECURITY DEFINER s’exécute avec les privilèges de l’utilisateur qui la possède, vous devez vous assurer que la procédure ne peut pas être utilisée à mauvais escient. Pour vous assurer que les procédures SECURITY DEFINER ne peuvent pas être utilisées à mauvais escient, procédez comme suit :

  • Accordez l’autorisation EXECUTE sur les procédures définies avec SECURITY DEFINER à des utilisateurs spécifiques, et non à PUBLIC.

  • Qualifiez tous les objets de base de données dont la procédure a besoin pour accéder à l’aide des noms de schéma. Par exemple, utilisez myschema.mytable plutôt que mytable.

  • Si vous ne pouvez pas qualifier un nom d’objet par son schéma, lors de la création de la procédure, définissez search_path à l’aide de l’option SET. Définissez search_path de façon à exclure tout schéma accessible en écriture par des utilisateurs non fiables. Cette approche empêche tout appelant de la procédure de créer des objets (tels que des tables ou des vues) qui masquent les objets destinés à être utilisés par la procédure. Pour plus d’informations sur l’option SET, consultez CREATE PROCEDURE.

L’exemple suivant définit search_path sur admin pour s’assurer que la table user_creds est accessible depuis le schéma admin et non depuis le schéma public ou autre défini dans le search_path de l’appelant.

CREATE OR REPLACE PROCEDURE sp_get_credentials(userid int, o_creds OUT varchar) AS $$ BEGIN SELECT creds INTO o_creds FROM user_creds WHERE user_id = $1; END; $$ LANGUAGE plpgsql SECURITY DEFINER -- Set a secure search_path SET search_path = admin;
ConfidentialitéConditions d'utilisation du sitePréférences de cookies
© 2025, Amazon Web Services, Inc. ou ses affiliés. Tous droits réservés.