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.

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 de USAGE privilèges sur le langage PL/pGSQL, qui est accordé PUBLIC par défaut. Seuls les super-utilisateurs et les propriétaires disposent par défaut du privilège d’appeler une procédure. Les superutilisateurs peuvent exécuter REVOKE USAGE Pl/pg SQL depuis un utilisateur s'ils veulent empêcher ce dernier de créer une procédure stockée.

Pour appeler une procédure, vous devez disposer d'un EXECUTE privilège sur cette procédure. Par défaut, EXECUTE le privilège relatif aux nouvelles procédures est accordé au propriétaire de la procédure et aux superutilisateurs. Pour de plus amples informations, veuillez consulter GRANT.

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

L'SECURITYattribut contrôle les privilèges d'une procédure pour accéder aux objets de base de données. Lorsque vous créez une procédure stockée, vous pouvez définir l'SECURITYattribut sur DEFINER ouINVOKER. Si vous le spécifiez SECURITYINVOKER, la procédure utilise les privilèges de l'utilisateur qui l'appelle. Si vous le spécifiez SECURITYDEFINER, la procédure utilise les privilèges du propriétaire de la procédure. INVOKERest la valeur par défaut.

Comme une SECURITY DEFINER procédure s'exécute avec les privilèges de l'utilisateur qui en est le propriétaire, vous devez vous assurer qu'elle ne peut pas être utilisée à mauvais escient. Pour vous assurer que SECURITY DEFINER les procédures ne peuvent pas être utilisées à mauvais escient, procédez comme suit :

  • EXECUTEAccordez SECURITY DEFINER des procédures à 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, définissez-le search_path lors de la création de la procédure à l'aide de l'SEToption. 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 SET cette option, consultezCREATE 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;