Considérations et limites relatives à l'utilisation des politiques RLS

Amazon Redshift applique les politiques RLS aux instructions SELECT, UPDATE ou DELETE.

Amazon Redshift n’applique pas les politiques RLS aux instructions INSERT, COPY, ALTER TABLE APPEND.

Les politiques RLS peuvent être attachées à des tables, à des vues, à des vues à liaison tardive (LBVs) et à des vues matérialisées (MVs).

La sécurité au niveau des lignes fonctionne avec la sécurité au niveau des colonnes pour protéger vos données.

Lorsque RLS est activé pour la relation source, Amazon Redshift prend en charge l’instruction ALTER TABLE APPEND pour les super-utilisateurs, les utilisateurs auxquels le privilège système IGNORE RLS a été explicitement accordé ou le rôle sys:secadmin. Dans ce cas, vous pouvez exécuter l’instruction ALTER TABLE APPEND pour ajouter des lignes à une table cible en déplaçant les données à partir d’une table source existante. Amazon Redshift déplace tous les tuples de la relation source vers la relation cible. L’état RLS de la relation cible n’affecte pas l’instruction ALTER TABLE APPEND.

Pour faciliter la migration à partir d’autres systèmes d’entrepôts des données, vous pouvez définir et récupérer des variables de contexte de session personnalisées pour une connexion en spécifiant le nom et la valeur de la variable.

L’exemple suivant définit les variables de contexte de session pour une politique de sécurité au niveau des lignes (RLS).

-- Set a customized context variable.
SELECT set_config(‘app.category’, ‘Concerts’, FALSE);

-- Create a RLS policy using current_setting() to get the value of a customized context variable.
CREATE RLS POLICY policy_categories
WITH (catgroup VARCHAR(10)) 
USING (catgroup = current_setting('app.category', FALSE));

-- Set correct roles and attach the policy on the target table to one or more roles.
ATTACH RLS POLICY policy_categories ON tickit_category_redshift TO ROLE analyst, ROLE dbadmin;

Pour plus de détails sur la façon de définir et de récupérer des variables de contexte de session personnalisées SETSET_CONFIG, reportez-vous àMONTRER,CURRENT_SETTING, etRESET. Pour plus d'informations sur la modification de la configuration du serveur en général, rendez-vous surModification de la configuration du serveur.

Le changement d’utilisateur de session à l’aide de SET SESSION AUTHORIZATION entre DECLARE et FETCH ou entre les instructions FETCH suivantes n’actualisera pas le plan déjà préparé en fonction des politiques utilisateur au moment de DECLARE. Évitez de changer d’utilisateur de session lorsque des curseurs sont utilisés avec des tables protégées par RLS.

Lorsque les objets de base contenus dans un objet de vue sont protégés par RLS, les politiques associées à l’utilisateur exécutant la requête sont appliquées aux objets de base respectifs. Ceci est différent des contrôles d’autorisation au niveau des objets, où les autorisations du propriétaire de la vue sont comparées aux objets de base de la vue. Vous pouvez consulter les relations protégées par RLS d’une requête dans sa sortie du plan EXPLAIN.

Lorsqu’une fonction définie par l’utilisateur (UDF) est référencée dans une politique RLS d’une relation attachée à un utilisateur, l’utilisateur doit disposer de l’autorisation EXECUTE sur la fonction UDF pour interroger la relation.

La sécurité au niveau des lignes peut limiter l’optimisation des requêtes. Nous vous recommandons d’évaluer soigneusement les performances des requêtes avant de déployer des vues protégées par RLS sur de grands jeux de données.

Les politiques de sécurité au niveau des lignes appliquées aux vues à liaison tardive peuvent être intégrées dans des tables fédérées. Ces politiques RLS peuvent être visibles dans les journaux des moteurs de traitement externes.

Les politiques RLS ne peuvent pas être attachées à des tables externes et à plusieurs autres types de relations. Pour de plus amples informations, veuillez consulter ATTACH RLS POLICY.

Amazon Redshift prend en charge les instructions SELECT pour certaines politiques RLS avec des recherches comportant des jointures complexes, mais ne prend pas en charge les instructions UPDATE ou DELETE. Dans les cas où des instructions UPDATE ou DELETE sont utilisées, Amazon Redshift renvoie le message d’erreur suivant :

ERROR: One of the RLS policies on target relation is not supported in UPDATE/DELETE.

Chaque fois qu’une fonction UDF est référencée dans une politique RLS d’une relation attachée à un utilisateur, l’utilisateur doit disposer de l’autorisation EXECUTE sur la fonction UDF pour interroger la relation.

Les sous-requêtes corrélées ne sont pas prises en charge. Amazon Redshift renvoie l’erreur suivante :

ERROR: RLS policy could not be rewritten.

Amazon Redshift ne prend pas en charge l’unité de partage des données avec RLS. Si, dans le cadre d’une relation, RLS n’est pas désactivé pour les unités de partage des données, la requête échoue sur le cluster consommateur avec l’erreur suivante :

RLS-protected relation "rls_protected_table" cannot be accessed via datasharing query.

Vous pouvez désactiver le protocole RLS pour les partages de données à l'aide de la commande ALTER TABLE avec le paramètre ROW LEVEL SECURITY OFF FOR DATASHARES. Pour plus d'informations sur l'utilisation d'ALTER TABLE pour activer ou désactiver RLS, consultez. ALTER TABLE

Dans les requêtes entre bases de données, Amazon Redshift bloque les lectures vers des relations protégées par RLS. Les utilisateurs disposant de l’autorisation IGNORE RLS peuvent accéder à la relation protégée à l’aide de requêtes entre bases de données. Lorsqu’un utilisateur ne disposant pas de l’autorisation IGNORE RLS accède à une relation protégée par RLS via une requête entre bases de données, l’erreur suivante s’affiche :

RLS-protected relation "rls_protected_table" cannot be accessed via cross-database query.

ALTER RLS POLICY prend uniquement en charge la modification d’une politique RLS à l’aide de la clause USING (using_predicate_exp). Vous ne pouvez pas modifier une politique RLS à l’aide d’une clause WITH lorsque vous exécutez ALTER RLS POLICY.

Vous ne pouvez pas interroger les relations dont la sécurité au niveau des lignes est activée si les valeurs de l’une des options de configuration suivantes ne correspondent pas à la valeur par défaut de la session :

Envisagez de réinitialiser les options de configuration de votre session si vous tentez d’interroger une relation avec sécurité au niveau des lignes et que vous voyez le message « La relation protégée RLS ne prend pas en charge la configuration au niveau de la session si la sensibilité à la casse est différente de sa valeur par défaut ».

Lorsque votre cluster ou votre espace de noms sans serveur mis en service est soumis à des politiques de sécurité au niveau des lignes, les commandes suivantes sont bloquées pour les utilisateurs standard :

ALTER <current_user> SET enable_case_sensitive_super_attribute/enable_case_sensitive_identifier/downcase_delimited_identifier

Lorsque vous créez des politiques RLS, nous vous recommandons de modifier les paramètres des options de configuration par défaut pour les utilisateurs standard afin qu’ils correspondent aux paramètres des options de configuration de la session au moment où la politique a été créée. Les super-utilisateurs et les utilisateurs dotés du privilège ALTER USER peuvent faire cela en utilisant les paramètres de groupe de paramètres ou la commande ALTER USER. Pour en savoir plus sur les groupes de paramètres, consultez Groupes de paramètres Amazon Redshift dans le Guide de gestion Amazon Redshift. Pour en savoir plus sur la commande ALTER USER, consultez ALTER USER.

Les vues et les vues à liaison tardive (LBV) disposant de politiques de sécurité au niveau des lignes ne peuvent pas être remplacées par des utilisateurs ordinaires utilisant la commande CREATE VIEW. Pour remplacer des vues ou par LBVs des politiques RLS, détachez d'abord toutes les politiques RLS qui leur sont associées, remplacez les vues ou LBVs attachez à nouveau les politiques. Les superutilisateurs et les utilisateurs dotés du sys:secadmin permission peuvent utiliser CREATE VIEW sur des vues ou LBVs avec des politiques RLS sans détacher les politiques.

Les vues disposant de politiques de sécurité au niveau des lignes ne peuvent pas référencer les tables système ni les vues système.

Une vue à liaison tardive référencée par une vue normale ne peut pas être protégée par RLS.

Les relations protégées par RLS et les données imbriquées provenant de lacs de données ne sont pas accessibles dans la même requête.