Amazon Redshift ne prendra plus en charge la création de nouveaux UDFs Python à partir du patch 198. Les fonctions Python définies par l’utilisateur existantes continueront de fonctionner normalement 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.

# Considérations et limitations relatives à l’utilisation des politiques RLS
<a name="t_rls_usage"></a>

## Considérations
<a name="t_rls_considerations"></a>

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 (LBV) et à des vues matérialisées (MV).
+ Row-level la sécurité 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\_CONFIG](r_SET_CONFIG.md), [MONTRER](r_SHOW.md), [CURRENT\_SETTING](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 RLS-protected tables.
+ Lorsque les objets de base d'un objet de vue le sont RLS-protected, 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 visualiser les RLS-protected relations d'une requête dans la 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.
+  Row-level la sécurité peut limiter l'optimisation des requêtes. Nous vous recommandons d'évaluer soigneusement les performances des requêtes avant de déployer des RLS-protected vues sur de grands ensembles de données. 
+  Row-level les politiques de sécurité appliquées aux vues à liaison tardive peuvent être transférées dans des tables fédérées. Ces politiques RLS peuvent être visibles dans les journaux des moteurs de traitement externes. 

## Limitations
<a name="t_rls_limitations"></a>

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 RLS-protected des relations. 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 à la RLS-protected relation par le biais d'une requête entre bases de données, l'erreur suivante apparaît :

  ```
  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 :
  +  `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 <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](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 les vues ou les LBV par des politiques RLS, commencez par détacher toutes les politiques RLS qui leur sont associées, remplacez les vues ou les LBV, puis attachez les politiques à nouveau. Les super-utilisateurs et les utilisateurs disposant de l’autorisation `sys:secadmin permission` peuvent utiliser CREATE VIEW sur les vues ou les LBV ayant 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. 
+  RLS-protected les relations et les données imbriquées provenant des lacs de données ne sont pas accessibles dans la même requête.