Amazon Redshift ne prendra plus en charge la création de nouveaux Python à UDFs partir du patch 198. UDFs Le Python existant continuera de fonctionner jusqu'au 30 juin 2026. Pour plus d’informations, consultez le [ billet de blog ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
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é au niveau des lignes
Grâce à la sécurité au niveau des lignes (RLS) d’Amazon Redshift, vous pouvez bénéficier d’un contrôle précis des accès à vos données sensibles. Vous pouvez décider quels utilisateurs ou rôles peuvent accéder à des enregistrements de données spécifiques au sein de schémas ou de tables, en fonction des politiques de sécurité définies au niveau des objets de base de données. En plus de la sécurité au niveau des colonnes, où vous pouvez accorder aux utilisateurs des autorisations pour un sous-ensemble de colonnes, utilisez des politiques RLS pour restreindre davantage l’accès à certaines lignes des colonnes visibles. Pour plus d’informations sur la sécurité au niveau des colonnes, consultez [Notes d’utilisation pour le contrôle d’accès de niveau colonne](r_GRANT-usage-notes.md#r_GRANT-usage-notes-clp).
Lorsque vous appliquez des politiques RLS sur des tables, vous pouvez restreindre les ensembles de résultats renvoyés lorsque les utilisateurs exécutent des requêtes.
Lorsque vous créez des politiques RLS, vous pouvez spécifier des expressions qui déterminent si Amazon Redshift renvoie toutes lignes existantes dans une table dans une requête. En créant des politiques RLS pour limiter l’accès, vous n’avez pas besoin d’ajouter ou d’externaliser des conditions supplémentaires dans vos requêtes.
Lorsque vous créez des politiques RLS, nous vous recommandons de créer des politiques simples et d’éviter les instructions complexes dans les politiques. Lorsque vous définissez des politiques RLS, n’utilisez pas trop de jointures de tables basées sur des politiques dans la définition de stratégie.
Lorsqu’une politique fait référence à une table de recherche, Amazon Redshift analyse la table supplémentaire en plus de la table sur laquelle la politique existe. Il y aura des différences de performances entre la même requête pour un utilisateur auquel une politique RLS est attachée et un utilisateur sans politique attachée.
# Utilisation des politiques RLS dans les instructions SQL
Lorsque vous utilisez des politiques RLS dans des instructions SQL, Amazon Redshift applique les règles suivantes :
+ Amazon Redshift applique par défaut les politiques RLS aux instructions SELECT, UPDATE et DELETE.
+ Pour SELECT et UNLOAD, Amazon Redshift filtre les lignes en fonction de la politique que vous avez définie.
+ Pour UPDATE, Amazon Redshift ne met à jour que les lignes que vous voyez. Si une politique restreint un sous-ensemble des lignes d’une table, vous ne pouvez pas les mettre à jour.
+ Pour DELETE, vous ne pouvez supprimer que les lignes que vous voyez. Si une politique restreint un sous-ensemble des lignes d’une table, vous ne pouvez pas les supprimer. Pour TRUNCATE, vous pouvez toujours tronquer la table.
+ Pour CREATE TABLE LIKE, les tables créées avec les options LIKE n’héritent pas des paramètres d’autorisation de la table source. De même, la table cible n’hérite pas des politiques RLS de la table source.
# Association de plusieurs politiques par utilisateur
Dans Amazon Redshift, RLS prend en charge l’association de plusieurs politiques par utilisateur et par objet. Lorsque plusieurs politiques sont définies pour un utilisateur, Amazon Redshift applique toutes les politiques avec la syntaxe AND ou OR en fonction du paramètre RLS CONJUNCTION TYPE défini pour la table. Pour plus d’informations sur les types de conjonction, consultez [ALTER TABLE](r_ALTER_TABLE.md).
Plusieurs politiques d’une même table peuvent vous être associées. Soit plusieurs politiques vous sont directement attachées, soit vous appartenez à plusieurs rôles, et les rôles ont différentes politiques qui leur sont attachées.
Lorsque les différentes politiques doivent restreindre l’accès aux lignes dans une relation donnée, vous pouvez définir l’élément RLS CONJUNCTION TYPE de la relation à AND. Prenez l’exemple de code suivant. Alice ne peut voir que les événements sportifs dont le « catname » est NBA, conformément à la politique spécifiée.
```
-- Create an analyst role and grant it to a user named Alice.
CREATE ROLE analyst;
CREATE USER alice WITH PASSWORD 'Name_is_alice_1';
GRANT ROLE analyst TO alice;
-- Create an RLS policy that only lets the user see sports.
CREATE RLS POLICY policy_sports
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Sports');
-- Create an RLS policy that only lets the user see NBA.
CREATE RLS POLICY policy_nba
WITH (catname VARCHAR(10))
USING (catname = 'NBA');
-- Attach both to the analyst role.
ATTACH RLS POLICY policy_sports ON category TO ROLE analyst;
ATTACH RLS POLICY policy_nba ON category TO ROLE analyst;
-- Activate RLS on the category table with AND CONJUNCTION TYPE.
ALTER TABLE category ROW LEVEL SECURITY ON CONJUNCTION TYPE AND;
-- Change session to Alice.
SET SESSION AUTHORIZATION alice;
-- Select all from the category table.
SELECT catgroup, catname
FROM category;
catgroup | catname
---------+---------
Sports | NBA
(1 row)
```
Lorsque les différentes politiques doivent permettre aux utilisateurs de voir davantage de lignes dans une relation donnée, l’utilisateur peut définir l’élément RLS CONJUNCTION TYPE de la relation à OR. Prenez l’exemple de code suivant. Alice ne peut voir que « Concerts » et « Sports » conformément à la politique spécifiée.
```
-- Create an analyst role and grant it to a user named Alice.
CREATE ROLE analyst;
CREATE USER alice WITH PASSWORD 'Name_is_alice_1';
GRANT ROLE analyst TO alice;
-- Create an RLS policy that only lets the user see concerts.
CREATE RLS POLICY policy_concerts
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Concerts');
-- Create an RLS policy that only lets the user see sports.
CREATE RLS POLICY policy_sports
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Sports');
-- Attach both to the analyst role.
ATTACH RLS POLICY policy_concerts ON category TO ROLE analyst;
ATTACH RLS POLICY policy_sports ON category TO ROLE analyst;
-- Activate RLS on the category table with OR CONJUNCTION TYPE.
ALTER TABLE category ROW LEVEL SECURITY ON CONJUNCTION TYPE OR;
-- Change session to Alice.
SET SESSION AUTHORIZATION alice;
-- Select all from the category table.
SELECT catgroup, count(*)
FROM category
GROUP BY catgroup ORDER BY catgroup;
catgroup | count
---------+-------
Concerts | 3
Sports | 5
(2 rows)
```
# Propriété et gestion des politiques RLS
En tant que super-utilisateur, administrateur de sécurité ou utilisateur disposant du rôle sys:secadmin, vous pouvez créer, modifier, attacher et détacher des politiques RLS. Les politiques RLS peuvent être attachées à des tables, à des vues, à des vues à liaison tardive (LBVs) et à des vues matérialisées (MVs). Au niveau de l’objet, vous pouvez activer ou désactiver la sécurité au niveau des lignes sans modifier la définition du schéma pour les tables.
Pour commencer à utiliser la sécurité au niveau des lignes, vous pouvez utiliser les instructions SQL suivantes :
+ Utilisez l’instruction ALTER TABLE pour activer ou désactiver RLS sur une table, une vue ou une vue à liaison tardive. Pour plus d’informations, consultez [ALTER TABLE](r_ALTER_TABLE.md).
+ Utilisez l’instruction ALTER MATERIALIZED VIEW pour activer ou désactiver RLS sur une vue matérialisée (MV). Pour plus d’informations, consultez [ALTER MATERIALIZED VIEW](r_ALTER_MATERIALIZED_VIEW.md).
+ Utilisez l’instruction CREATE RLS POLICY pour créer une politique de sécurité pour une ou plusieurs tables et spécifier un ou plusieurs utilisateurs ou rôles dans la stratégie.
Pour plus d’informations, consultez [CREATE RLS POLICY](r_CREATE_RLS_POLICY.md).
+ Utilisez l’instruction ALTER RLS POLICY pour modifier la politique, par exemple en modifiant la définition de la politique. Vous pouvez utiliser la même politique pour plusieurs tables ou vues.
Pour plus d’informations, consultez [ALTER RLS POLICY](r_ALTER_RLS_POLICY.md).
+ Utilisez l’instruction ATTACH RLS POLICY pour attacher une politique à une ou plusieurs relations, à un ou plusieurs utilisateurs, ou à des rôles.
Pour plus d’informations, consultez [ATTACH RLS POLICY](r_ATTACH_RLS_POLICY.md).
+ Utilisez l’instruction DETACH RLS POLICY pour détacher une politique d’une ou de plusieurs relations, d’un ou de plusieurs utilisateurs, ou de rôles.
Pour plus d’informations, consultez [DETACH RLS POLICY](r_DETACH_RLS_POLICY.md).
+ Utilisez l’instruction DROP RLS POLICY pour supprimer une stratégie.
Pour plus d’informations, consultez [DROP RLS POLICY](r_DROP_RLS_POLICY.md).
+ Utilisez les instructions GRANT et REVOKE pour accorder et révoquer explicitement les autorisations SELECT aux politiques RLS qui font référence à des tables de recherche. Pour plus d’informations, consultez [GRANT](r_GRANT.md) et [REVOKE](r_REVOKE.md).
Pour surveiller les politiques créées, les utilisateurs disposant du rôle sys:secadmin peuvent consulter [SVV\$1RLS\$1POLICY](r_SVV_RLS_POLICY.md) et [SVV\$1RLS\$1ATTACHED\$1POLICY](r_SVV_RLS_ATTACHED_POLICY.md).
Pour répertorier les relations protégées par RLS, les utilisateurs disposant du rôle sys:secadmin peuvent afficher [SVV\$1RLS\$1RELATION](r_SVV_RLS_RELATION.md).
Pour suivre l’application des politiques RLS sur les requêtes qui font référence à des relations protégées par RLS, un super-utilisateur, un utilisateur disposant du rôle sys:operator ou tout autre utilisateur disposant de l’autorisation système ACCESS SYSTEM TABLE peut consulter [SVV\$1RLS\$1APPLIED\$1POLICY](r_SVV_RLS_APPLIED_POLICY.md). Remarquez que les utilisateurs disposant du rôle sys:secadmin ne disposent pas de ces autorisations par défaut.
Pour permettre aux utilisateurs d’accéder pleinement à une relation protégée par RLS, vous pouvez accorder l’autorisation IGNORE RLS. Les super-utilisateurs ou les utilisateurs disposant du rôle sys:secadmin reçoivent automatiquement l’autorisation IGNORE RLS. Pour plus d’informations, consultez [GRANT](r_GRANT.md).
Pour expliquer les filtres de politique RLS d’une requête dans le plan EXPLAIN afin de dépanner les requêtes liées à RLS, vous pouvez accorder l’autorisation EXPLAIN RLS à n’importe quel utilisateur. Pour plus d’informations, consultez [GRANT](r_GRANT.md) et [EXPLAIN](r_EXPLAIN.md).
# Objets et principes dépendants des politiques
Afin de garantir la sécurité de toutes les applications et pour éviter que les objets de politique ne deviennent obsolètes ou non valides, Amazon Redshift ne permet pas de supprimer ou de modifier des objets référencés par les politiques RLS.
La liste suivante répertorie les dépendances d’objets de schéma qu’Amazon Redshift suit pour les politiques RLS.
+ Lors du suivi de la dépendance des objets de schéma pour la table cible, Amazon Redshift suit les règles suivantes :
+ Amazon Redshift détache la politique d’une relation, d’un utilisateur, d’un rôle ou d’un public lorsque vous supprimez une table cible.
+ Lorsque vous modifiez le nom d’une table cible, cela n’a aucun impact sur les politiques attachées.
+ Vous ne pouvez supprimer les colonnes de la table cible référencée dans la définition de la politique que si vous supprimez ou détachez d’abord la stratégie. Cela s’applique également lorsque l’option CASCADE est spécifiée. Vous pouvez supprimer d’autres colonnes dans la table cible.
+ Vous ne pouvez pas renommer les colonnes référencées de la table cible. Pour renommer des colonnes référencées, détachez d’abord la stratégie. Cela s’applique également lorsque l’option CASCADE est spécifiée.
+ Vous ne pouvez pas modifier le type de la colonne référencée, même lorsque vous spécifiez l’option CASCADE.
+ Lors du suivi de la dépendance des objets de schéma pour la table de recherche, Amazon Redshift suit les règles suivantes :
+ Vous ne pouvez pas supprimer une table de recherche. Pour supprimer une table de recherche, supprimez d’abord la politique dans laquelle elle est référencée.
+ Vous ne pouvez pas renommer une table de recherche. Pour renommer une table de recherche, supprimez d’abord la politique dans laquelle elle est référencée. Cela s’applique également lorsque l’option CASCADE est spécifiée.
+ Vous ne pouvez pas supprimer les colonnes de la table de recherche utilisées dans la définition de la stratégie. Pour supprimer les colonnes de la table de recherche utilisées dans la définition de la stratégie, supprimez d’abord la politique dans laquelle la table de recherche est référencée. Cela s’applique également lorsque l’option CASCADE est spécifiée dans l’instruction ALTER TABLE DROP COLUMN. Vous pouvez supprimer d’autres colonnes dans la table de recherche.
+ Vous ne pouvez pas renommer les colonnes référencées de la table de recherche. Pour renommer des colonnes référencées, supprimez d’abord la politique dans laquelle la table de recherche est référencée. Cela s’applique également lorsque l’option CASCADE est spécifiée.
+ Vous ne pouvez pas modifier le type de la colonne référencée.
+ Lorsqu’un utilisateur ou un rôle est supprimé, Amazon Redshift détache automatiquement toutes les politiques attachées à l’utilisateur ou au rôle.
+ Lorsque vous utilisez l’option CASCADE dans l’instruction DROP SCHEMA, Amazon Redshift supprime également les relations dans le schéma. Amazon Redshift supprime également les relations dans tous les autres schémas qui dépendent des relations du schéma supprimé. Pour une relation qui est une table de recherche dans une stratégie, Amazon Redshift ne parvient pas à exécuter l’instruction DROP SCHEMA DDL. Pour toutes les relations supprimées par l’instruction DROP SCHEMA, Amazon Redshift détache toutes les politiques attachées à ces relations.
+ Vous ne pouvez supprimer une fonction de recherche (une fonction qui est référencée dans une définition de stratégie) que si vous supprimez également la stratégie. Cela s’applique également lorsque l’option CASCADE est spécifiée.
+ Lorsqu’une politique est attachée à une table, Amazon Redshift vérifie si cette table est une table de recherche dans une autre stratégie. Si c’est le cas, Amazon Redshift ne permet pas d’attacher une politique à cette table.
+ Lors de la création d’une politique RLS, Amazon Redshift vérifie si cette table est une table cible pour une autre politique RLS. Si c’est le cas, Amazon Redshift ne permet pas de créer une politique sur cette table.
## Exemple
L’exemple suivant illustre comment la dépendance des schémas est suivie.
```
-- The CREATE and ATTACH policy statements for `policy_events` references some
-- target and lookup tables.
-- Target tables are tickit_event_redshift and target_schema.target_event_table.
-- Lookup table is tickit_sales_redshift.
-- Policy `policy_events` has following dependencies:
-- table tickit_sales_redshift column eventid, qtysold
-- table tickit_event_redshift column eventid
-- table target_event_table column eventid
-- schema public and target_schema
CREATE RLS POLICY policy_events
WITH (eventid INTEGER)
USING (
eventid IN (SELECT eventid FROM tickit_sales_redshift WHERE qtysold <3)
);
ATTACH RLS POLICY policy_events ON tickit_event_redshift TO ROLE analyst;
ATTACH RLS POLICY policy_events ON target_schema.target_event_table TO ROLE consumer;
```
# Considérations et limitations relatives à l’utilisation des politiques RLS
## Considérations
Voici des éléments à prendre en compte pour travailler avec 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 d’informations sur la façon de définir et de récupérer des variables de contexte de session personnalisées, consultez [SET](r_SET.md), [SET\$1CONFIG](r_SET_CONFIG.md), [MONTRER](r_SHOW.md), [CURRENT\$1SETTING](r_CURRENT_SETTING.md) et [RESET](r_RESET.md). Pour plus d’informations sur la modification de la configuration du serveur en général, consultez [Modification de la configuration du serveur](cm_chap_ConfigurationRef.md#t_Modifying_the_default_settings).
**Important**
Lorsque vous utilisez des variables de contexte de session dans des politiques RLS, la politique de sécurité dépend de l’utilisateur ou du rôle qui invoque la politique. Veillez à éviter les failles de sécurité lorsque vous utilisez des variables de contexte de session dans les politiques RLS.
+ 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.
## Limitations
Voici les limites lorsque vous travaillez avec des politiques RLS :
+ Les politiques RLS ne peuvent pas être attachées à des tables externes ni à plusieurs autres types de relations. Pour plus d’informations, consultez [ATTACH RLS POLICY](r_ATTACH_RLS_POLICY.md).
+ 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 RLS pour les unités de partage des 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](r_ALTER_TABLE.md).
+ 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\$1predicate\$1exp). 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 :
+ `enable_case_sensitive_super_attribute`
+ `enable_case_sensitive_identifier`
+ `downcase_delimited_identifier`
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 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](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-parameter-groups.html) dans le *Guide de gestion Amazon Redshift*. Pour en savoir plus sur la commande ALTER USER, consultez [ALTER USER](r_ALTER_USER.md).
+ 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](r_CREATE_VIEW.md). 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.
# Bonnes pratiques pour la performance de la sécurité RLS
Voici les bonnes pratiques pour garantir de meilleures performances d’Amazon Redshift sur les tables protégées par RLS.
## Sécurité des opérateurs et des fonctions
Lors de l’interrogation de tables protégées par RLS, l’utilisation de certains opérateurs ou de certaines fonctions peut entraîner une dégradation des performances. Amazon Redshift classe les opérateurs et les fonctions comme sécurisés ou non sécurisés pour interroger les tables protégées par RLS. Une fonction ou un opérateur est classé comme étant sécurisé par RLS lorsqu’il ne présente aucun effet secondaire observable en fonction des entrées. En particulier, une fonction ou un opérateur sécurisé par RLS ne peut pas correspondre à l’un des cas suivants :
+ Fournit une valeur d’entrée, ou toute valeur qui dépend de la valeur d’entrée, avec ou sans message d’erreur.
+ Echoue ou renvoie des erreurs qui dépendent de la valeur d’entrée.
Les opérateurs non sécurisés par RLS comprennent :
+ Les opérateurs arithmétiques — \$1, -, /, \$1, %.
+ Les opérateurs de texte – LIKE et SIMILAR TO.
+ Les opérateurs de distribution.
+ UDFs.
Utilisez l’instruction SELECT suivante pour vérifier la sécurité des opérateurs et des fonctions.
```
SELECT proname, proc_is_rls_safe(oid) FROM pg_proc;
```
Amazon Redshift impose des restrictions sur l’ordre d’évaluation des prédicats de l’utilisateur contenant des opérateurs et des fonctions non sécurisés par RLS lors de la planification de requêtes sur des tables protégées par RLS. Les requêtes faisant référence à des opérateurs ou des fonctions non sécurisés par RLS peuvent entraîner une dégradation des performances lors de l’interrogation de tables protégées par RLS. Les performances peuvent se dégrader de manière significative lorsqu’Amazon Redshift ne parvient pas à déléguer les prédicats non sécurisés par RLS aux analyses de la table de base pour tirer parti des clés de tri. Pour de meilleures performances, évitez les requêtes utilisant des prédicats non sécurisés par RLS qui tirent parti d’une clé de tri. Pour vérifier qu’Amazon Redshift est capable de déléguer des opérateurs et des fonctions, vous pouvez utiliser des instructions EXPLAIN en association avec l’autorisation système EXPLAIN RLS.
## Mise en cache du résultat
Pour raccourcir le temps d’exécution des requêtes et améliorer les performances du système, Amazon Redshift met en cache les résultats de certains types de requêtes dans la mémoire du nœud principal.
Amazon Redshift utilise les résultats mis en cache pour une nouvelle requête analysant les tables protégées par RLS si l’ensemble des conditions pour les tables non protégées et les éléments suivants sont satisfaits :
+ Les tables ou les vues incluses dans la politique n’ont pas été modifiées.
+ La politique n’utilise pas une fonction qui nécessite une évaluation à chaque exécution telle que GETDATE ou CURRENT\$1USER.
Pour de meilleures performances, évitez d’utiliser des prédicats de politique qui ne satisfont pas les conditions ci-dessus.
Pour plus d’informations sur la mise en cache des résultats dans Amazon Redshift, consultez [Mise en cache du résultat](c_challenges_achieving_high_performance_queries.md#result-caching).
## politiques complexes
Pour de meilleures performances, évitez d’utiliser des politiques complexes avec des sous-requêtes qui rejoignent plusieurs tables.
# Exemple de sécurité au niveau des lignes end-to-end
L' end-to-endexemple suivant illustre la façon dont un superutilisateur crée des utilisateurs et des rôles. Ensuite, un utilisateur disposant du rôle secadmin crée, attache, détache et supprime les politiques RLS. Cet exemple utilise l’exemple de base données tickit. Pour plus d’informations, consultez [Charger les données d’Amazon S3 vers Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-create-sample-db.html) dans le *Guide de démarrage d’Amazon Redshift*.
```
-- Create users and roles referenced in the policy statements.
CREATE ROLE analyst;
CREATE ROLE consumer;
CREATE ROLE dbadmin;
CREATE ROLE auditor;
CREATE USER bob WITH PASSWORD 'Name_is_bob_1';
CREATE USER alice WITH PASSWORD 'Name_is_alice_1';
CREATE USER joe WITH PASSWORD 'Name_is_joe_1';
CREATE USER molly WITH PASSWORD 'Name_is_molly_1';
CREATE USER bruce WITH PASSWORD 'Name_is_bruce_1';
GRANT ROLE sys:secadmin TO bob;
GRANT ROLE analyst TO alice;
GRANT ROLE consumer TO joe;
GRANT ROLE dbadmin TO molly;
GRANT ROLE auditor TO bruce;
GRANT ALL ON TABLE tickit_category_redshift TO PUBLIC;
GRANT ALL ON TABLE tickit_sales_redshift TO PUBLIC;
GRANT ALL ON TABLE tickit_event_redshift TO PUBLIC;
-- Create table and schema referenced in the policy statements.
CREATE SCHEMA target_schema;
GRANT ALL ON SCHEMA target_schema TO PUBLIC;
CREATE TABLE target_schema.target_event_table (LIKE tickit_event_redshift);
GRANT ALL ON TABLE target_schema.target_event_table TO PUBLIC;
-- Change session to analyst alice.
SET SESSION AUTHORIZATION alice;
-- Check the tuples visible to analyst alice.
-- Should contain all 3 categories.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
CREATE RLS POLICY policy_concerts
WITH (catgroup VARCHAR(10))
USING (catgroup = 'Concerts');
SELECT poldb, polname, polalias, polatts, polqual, polenabled, polmodifiedby FROM svv_rls_policy WHERE poldb = CURRENT_DATABASE();
ATTACH RLS POLICY policy_concerts ON tickit_category_redshift TO ROLE analyst, ROLE dbadmin;
ALTER TABLE tickit_category_redshift ROW LEVEL SECURITY ON;
SELECT * FROM svv_rls_attached_policy;
-- Change session to analyst alice.
SET SESSION AUTHORIZATION alice;
-- Check that tuples with only `Concert` category will be visible to analyst alice.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to consumer joe.
SET SESSION AUTHORIZATION joe;
-- Although the policy is attached to a different role, no tuples will be
-- visible to consumer joe because the default deny all policy is applied.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to dbadmin molly.
SET SESSION AUTHORIZATION molly;
-- Check that tuples with only `Concert` category will be visible to dbadmin molly.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Check that EXPLAIN output contains RLS SecureScan to prevent disclosure of
-- sensitive information such as RLS filters.
EXPLAIN SELECT catgroup, count(*) FROM tickit_category_redshift GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
-- Grant IGNORE RLS permission so that RLS policies do not get applicable to role dbadmin.
GRANT IGNORE RLS TO ROLE dbadmin;
-- Grant EXPLAIN RLS permission so that anyone in role auditor can view complete EXPLAIN output.
GRANT EXPLAIN RLS TO ROLE auditor;
-- Change session to dbadmin molly.
SET SESSION AUTHORIZATION molly;
-- Check that all tuples are visible to dbadmin molly because `IGNORE RLS` is granted to role dbadmin.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to auditor bruce.
SET SESSION AUTHORIZATION bruce;
-- Check explain plan is visible to auditor bruce because `EXPLAIN RLS` is granted to role auditor.
EXPLAIN SELECT catgroup, count(*) FROM tickit_category_redshift GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
DETACH RLS POLICY policy_concerts ON tickit_category_redshift FROM ROLE analyst, ROLE dbadmin;
-- Change session to analyst alice.
SET SESSION AUTHORIZATION alice;
-- Check that no tuples are visible to analyst alice.
-- Although the policy is detached, no tuples will be visible to analyst alice
-- because of default deny all policy is applied if the table has RLS on.
SELECT catgroup, count(*)
FROM tickit_category_redshift
GROUP BY catgroup ORDER BY catgroup;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
CREATE RLS POLICY policy_events
WITH (eventid INTEGER) AS ev
USING (
ev.eventid IN (SELECT eventid FROM tickit_sales_redshift WHERE qtysold <3)
);
ATTACH RLS POLICY policy_events ON tickit_event_redshift TO ROLE analyst;
ATTACH RLS POLICY policy_events ON target_schema.target_event_table TO ROLE consumer;
RESET SESSION AUTHORIZATION;
-- Can not cannot alter type of dependent column.
ALTER TABLE target_schema.target_event_table ALTER COLUMN eventid TYPE float;
ALTER TABLE tickit_event_redshift ALTER COLUMN eventid TYPE float;
ALTER TABLE tickit_sales_redshift ALTER COLUMN eventid TYPE float;
ALTER TABLE tickit_sales_redshift ALTER COLUMN qtysold TYPE float;
-- Can not cannot rename dependent column.
ALTER TABLE target_schema.target_event_table RENAME COLUMN eventid TO renamed_eventid;
ALTER TABLE tickit_event_redshift RENAME COLUMN eventid TO renamed_eventid;
ALTER TABLE tickit_sales_redshift RENAME COLUMN eventid TO renamed_eventid;
ALTER TABLE tickit_sales_redshift RENAME COLUMN qtysold TO renamed_qtysold;
-- Can not drop dependent column.
ALTER TABLE target_schema.target_event_table DROP COLUMN eventid CASCADE;
ALTER TABLE tickit_event_redshift DROP COLUMN eventid CASCADE;
ALTER TABLE tickit_sales_redshift DROP COLUMN eventid CASCADE;
ALTER TABLE tickit_sales_redshift DROP COLUMN qtysold CASCADE;
-- Can not drop lookup table.
DROP TABLE tickit_sales_redshift CASCADE;
-- Change session to security administrator bob.
SET SESSION AUTHORIZATION bob;
DROP RLS POLICY policy_concerts;
DROP RLS POLICY IF EXISTS policy_events;
ALTER TABLE tickit_category_redshift ROW LEVEL SECURITY OFF;
RESET SESSION AUTHORIZATION;
-- Drop users and roles.
DROP USER bob;
DROP USER alice;
DROP USER joe;
DROP USER molly;
DROP USER bruce;
DROP ROLE analyst;
DROP ROLE consumer;
DROP ROLE auditor FORCE;
DROP ROLE dbadmin FORCE;
```