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é des bases de données
Vous pouvez gérer de la sécurité de la base de données en contrôlant les utilisateurs ayant accès aux objets qu’elle contient. Les utilisateurs peuvent se voir attribuer des rôles ou des groupes, et les autorisations que vous accordez aux utilisateurs, aux rôles ou aux groupes déterminent les objets de base de données auxquels ils peuvent accéder.
**Topics**
+ [Présentation de la sécurité d’Amazon Redshift](c_security-overview.md)
+ [Autorisations par défaut des utilisateurs de base de données](r_Privileges.md)
+ [superuser](r_superusers.md)
+ [Utilisateurs](r_Users.md)
+ [Groupes](r_Groups.md)
+ [Schémas](r_Schemas_and_tables.md)
+ [Contrôle d’accès basé sur les rôles (RBAC)](t_Roles.md)
+ [Sécurité au niveau des lignes](t_rls.md)
+ [Sécurité des métadonnées](t_metadata_security.md)
+ [Masquage dynamique des données](t_ddm.md)
+ [Autorisations délimitées](t_scoped-permissions.md)
L’accès aux objets de la base de données s’appuie sur les autorisations que vous accordez aux utilisateurs ou aux rôles. Les consignes suivantes résument le fonctionnement de la sécurité de la base de données :
+ Par défaut, les autorisations sont accordées uniquement au propriétaire de l’objet.
+ Les utilisateurs de la base de données Amazon Redshift sont appelés des utilisateurs qui peuvent se connecter à une base de données. Un utilisateur bénéficie des autorisations de deux façons : de manière explicite, en affectant ces autorisations directement au compte, ou implicitement, en étant membre d’un groupe qui bénéficie d’autorisations.
+ Les groupes sont des ensembles d’utilisateurs qui peuvent bénéficier collectivement d’autorisations à des fins de maintenance de sécurité rationalisée.
+ Les schémas sont des ensembles de tables de base de données et d’autres objets de base de données. Les schémas sont similaires aux répertoires de système de fichiers, sauf qu’ils ne peuvent pas s’imbriquer. Les utilisateurs peuvent bénéficier d’un accès à un seul schéma ou à plusieurs schémas.
En outre, Amazon Redshift utilise les fonctionnalités suivantes pour vous permettre de contrôler plus finement quels utilisateurs ont accès à quels objets de la base de données :
+ Le contrôle d’accès basé sur les rôles (RBAC) vous permet d’attribuer des autorisations à des rôles que vous pouvez ensuite appliquer à des utilisateurs, ce qui vous permet de contrôler les autorisations pour de grands groupes d’utilisateurs. Contrairement aux groupes, les rôles peuvent hériter des autorisations d’autres rôles.
La sécurité au niveau des lignes (RLS) vous permet de définir des stratégies qui restreignent l’accès aux lignes de votre choix, puis d’appliquer ces stratégies à des utilisateurs ou à des groupes.
Le masquage dynamique des données (DDM) protège davantage vos données en les transformant au moment de l’exécution de la requête, de sorte que vous puissiez permettre aux utilisateurs d’accéder aux données sans exposer de détails sensibles.
Pour obtenir des exemples d’implémentation de la sécurité, consultez [Exemple de contrôle d’accès utilisateur et de groupe](t_user_group_examples.md).
Pour plus d’informations sur la protection de vos données, consultez [Sécurité d’Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/iam-redshift-user-mgmt.html) du *Guide de la gestion du cluster Amazon Redshift*.
# Présentation de la sécurité d’Amazon Redshift
La sécurité de base de données Amazon Redshift est distincte des autres types de sécurité Amazon Redshift. Outre la sécurité de la base de données, décrite dans cette section, Amazon Redshift fournit les fonctions de gestion de la sécurité suivantes :
+ Informations de **connexion** : l'accès à votre console de gestion Amazon AWS Redshift est contrôlé par les autorisations de AWS votre compte. Pour plus d’informations, consultez [Informations d’identification de connexion](https://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html).
+ **Gestion des accès** : pour contrôler l'accès à des ressources Amazon Redshift spécifiques, vous devez définir des comptes Gestion des identités et des accès AWS (IAM). Pour plus d’informations, consultez [Contrôle de l’accès aux ressources Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/iam-redshift-user-mgmt.html).
+ **Groupes de sécurité du cluster** : pour accorder à d’autres utilisateurs l’accès entrant à un cluster Amazon Redshift, vous devez définir un groupe de sécurité du cluster et l’associer à un cluster. Pour de plus amples informations, consultez [Groupes de sécurité du cluster Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-security-groups.html).
+ **VPC** : pour protéger l’accès à votre cluster à l’aide d’un environnement de réseau virtuel, vous pouvez lancer votre cluster dans un cloud privé virtuel (VPC) Amazon. Pour plus d’informations, consultez [Gestion des clusters dans un cloud privé virtuel (VPC)](https://docs.aws.amazon.com/redshift/latest/mgmt/managing-clusters-vpc.html).
+ **Chiffrement du cluster** : pour chiffrer les données de toutes vos tables créées par l’utilisateur, vous pouvez activer le chiffrement du cluster au lancement de celui-ci. Pour plus d’informations, consultez [Clusters Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/mgmt/working-with-clusters.html).
+ **Connexions SSL** : pour chiffrer la connexion entre votre client SQL et votre cluster, vous pouvez utiliser le chiffrement SSL (Secure Sockets Layer). Pour plus d’informations, consultez [Connexion à votre cluster à l’aide de SSL](https://docs.aws.amazon.com/redshift/latest/mgmt/connecting-ssl-support.html).
+ **Chiffrement des données de chargement** : pour chiffrer les fichiers de données de chargement de votre table lorsque vous les chargez dans Amazon S3, vous pouvez utiliser le chiffrement côté serveur ou chiffrement côté client. Lorsque vous chargez des données chiffrées côté serveur, Amazon S3 gère le déchiffrement de manière transparente. Lorsque vous chargez des données chiffrées côté client, la commande COPY Amazon Redshift déchiffre les données à mesure qu’elle charge la table. Pour de plus amples informations, veuillez consulter [Chargement de données chiffrées sur Amazon S3](t_uploading-encrypted-data.md).
+ **Données en transit** : pour protéger vos données en transit dans le AWS cloud, Amazon Redshift utilise le protocole SSL à accélération matérielle pour communiquer avec Amazon S3 ou Amazon DynamoDB pour les opérations de copie, de déchargement, de sauvegarde et de restauration.
+ **Contrôle d’accès de niveau colonne** : pour bénéficier d’un contrôle d’accès de niveau colonne pour les données dans Amazon Redshift, utilisez des instructions d’autorisation et de révocation de niveau colonne sans avoir à implémenter un contrôle d’accès basé sur les vues ou utiliser un autre système.
+ **Contrôle de sécurité au niveau des lignes** : pour contrôler la sécurité des données au niveau des lignes dans Amazon Redshift, créez et associez des politiques aux rôles ou aux utilisateurs qui limitent l’accès aux lignes définies dans la politique.
# Autorisations par défaut des utilisateurs de base de données
Lorsque vous créez un objet de base de données, vous en êtes le propriétaire. Par défaut, seul un super-utilisateur ou le propriétaire d’un objet peut exécuter une requête, apporter des modifications ou accorder des autorisations sur cet objet. Pour qu’un utilisateur puisse utiliser un objet, vous devez accorder les autorisations nécessaires à cet utilisateur ou au groupe auquel il appartient. Les super-utilisateurs de base de données disposent des mêmes autorisations que les propriétaires de base de données.
Amazon Redshift prend en charge les autorisations suivantes : SELECT, INSERT, UPDATE, DELETE, REFERENCES, CREATE, TEMPORARY et USAGE. Des autorisations distinctes sont associées à différents types d’objets. Pour en savoir plus sur les autorisations d’objet de base de données prises en charge par Amazon Redshift, consultez la commande [GRANT](r_GRANT.md).
Seul le propriétaire a le droit de modifier ou de détruire un objet.
Par défaut, tous les utilisateurs disposent des autorisations CREATE et USAGE sur le schéma PUBLIC d’une base de données. Pour interdire aux utilisateurs de créer des objets dans le schéma PUBLIC d’une base de données, utilisez la commande REVOKE pour supprimer cette autorisation.
Pour annuler une autorisation qui a déjà été accordée, utilisez la commande [REVOKE](r_REVOKE.md). Les autorisations du propriétaire de l’objet, telles que les autorisations DROP, GRANT et REVOKE, sont implicites et ne peuvent pas être accordées ou révoquées. Les propriétaires d’objets peuvent révoquer leurs propres autorisations ordinaires, par exemple, pour passer une table en lecture seule pour eux-mêmes et les autres. Les super-utilisateurs conservent toutes les autorisations, indépendamment des commandes GRANT et REVOKE.
# Super-utilisateurs
Les super-utilisateurs de base de données disposent d’autorisations identiques à celles des propriétaires de base de données pour toutes les bases de données.
L’*administrateur*, qui est l’utilisateur que vous avez créé lorsque vous avez lancé le cluster, est un super-utilisateur.
Vous devez être un super-utilisateur pour créer un super-utilisateur.
Les tables et vues système Amazon Redshift sont visibles des super-utilisateurs ou de tous les utilisateurs. Seuls les super-utilisateurs peuvent interroger les tables et les vues système qui sont désignées comme « visibles des super-utilisateurs ». Pour plus d'informations, consultez [Vues de surveillance SYS](serverless_views-monitoring.md).
Les super-utilisateurs peuvent afficher toutes les tables de catalogue. Pour plus d'informations, consultez [Tables catalogue système](c_intro_catalog_views.md).
Un super-utilisateur de base de données contourne toutes les vérifications d’autorisations. Les super-utilisateurs conservent toutes les autorisations, indépendamment des commandes GRANT et REVOKE. Soyez prudent lorsque vous utilisez un rôle de super-utilisateur. Nous vous recommandons d’utiliser un rôle autre que celui de super-utilisateur lorsque cela est possible. Vous pouvez créer un rôle d’administrateur avec des autorisations plus restrictives. Pour plus d’informations sur la création de rôles, consultez [Contrôle d’accès basé sur les rôles (RBAC)](t_Roles.md).
Pour créer un nouveau super-utilisateur de base de données, connectez-vous à la base de données en tant que super-utilisateur et exécutez une commande CREATE USER ou ALTER USER avec l’autorisation CREATEUSER.
```
CREATE USER adminuser CREATEUSER PASSWORD '1234Admin';
ALTER USER adminuser CREATEUSER;
```
Pour créer, modifier ou supprimer un super-utilisateur, vous pouvez utiliser les commandes de gestion classiques des utilisateurs. Pour plus d’informations, consultez [Création, modification et suppression d’utilisateurs](r_Users-creatingaltering-and-deleting-users.md).
# Utilisateurs
Vous pouvez créer et gérer des utilisateurs de base de données à l’aide des commandes SQL Amazon Redshift CREATE USER et ALTER USER. Ou bien, vous pouvez configurer votre client SQL avec des pilotes personnalisés Amazon Redshift JDBC ou ODBC. Ces derniers gèrent la création d’utilisateurs de base de données et de mots de passe temporaires dans le cadre du processus de connexion à une base de données.
Les pilotes authentifient les utilisateurs de la base de données sur la base de l'authentification Gestion des identités et des accès AWS (IAM). Si vous gérez déjà les identités des utilisateurs en dehors de AWS, vous pouvez utiliser un fournisseur d'identité (IdP) compatible SAML 2.0 pour gérer l'accès aux ressources Amazon Redshift. Vous utilisez un rôle IAM pour configurer votre IdP AWS et pour permettre à vos utilisateurs fédérés de générer des informations d'identification temporaires et de se connecter aux bases de données Amazon Redshift. Pour plus d’informations, consultez [Utilisation de l’authentification IAM pour générer des informations d’identification de l’utilisateur de base de données](https://docs.aws.amazon.com/redshift/latest/mgmt/generating-user-credentials.html).
Les utilisateurs Amazon Redshift peuvent uniquement être créés et supprimés par un super-utilisateur de base de données. Les utilisateurs sont authentifiés lorsqu’ils se connectent à Amazon Redshift. Ils peuvent posséder des bases de données et des objets de base de données (par exemple, des tables). Ils peuvent également accorder à des utilisateurs, des groupes et des schémas des autorisations sur ces objets afin de contrôler l’accès aux objets. Les utilisateurs disposant de droits CREATE DATABASE peuvent créer des bases de données et accorder des autorisations concernant ces bases de données. Les super-utilisateurs disposent d’autorisations de propriétaires de bases de données pour toutes les bases de données.
# Création, modification et suppression d’utilisateurs
Les utilisateurs de base de données appartiennent à un cluster d’entrepôt des données ; ils n’appartiennent pas à une base de données spécifique.
+ Pour créer un utilisateur, utilisez la commande [CREATE USER](r_CREATE_USER.md).
+ Pour créer un super-utilisateur, utilisez la commande [CREATE USER](r_CREATE_USER.md) avec l’option CREATEUSER.
+ Pour supprimer un utilisateur existant, utilisez la commande [DROP USER](r_DROP_USER.md).
+ Pour modifier un utilisateur, par exemple modifier un mot de passe, utilisez la commande [ALTER USER](r_ALTER_USER.md).
+ Pour afficher une liste d’utilisateurs, interrogez la table de catalogue PG\$1USER.
```
select * from pg_user;
usename | usesysid | usecreatedb | usesuper | usecatupd | passwd | valuntil | useconfig
------------+----------+-------------+----------+-----------+----------+----------+-----------
rdsdb | 1 | t | t | t | ******** | |
masteruser | 100 | t | t | f | ******** | |
dwuser | 101 | f | f | f | ******** | |
simpleuser | 102 | f | f | f | ******** | |
poweruser | 103 | f | t | f | ******** | |
dbuser | 104 | t | f | f | ******** | |
(6 rows)
```
# Groupes
Les groupes sont des ensembles d’utilisateurs qui bénéficient tous des autorisations qui sont associées au groupe. Vous pouvez utiliser des groupes pour attribuer des autorisations. Par exemple, vous pouvez créer différents groupes pour les ventes, l’administration et le support et accorder aux utilisateurs de chaque groupe l’accès correspondant aux données qu’ils ont besoin d’utiliser. Vous pouvez accorder ou révoquer des autorisations au niveau du groupe, et ces modifications s’appliqueront à tous les membres du groupe, à l’exception des super-utilisateurs.
Pour afficher tous les groupes d’utilisateurs, interrogez la table catalogue système PG\$1GROUP :
```
select * from pg_group;
```
Par exemple, pour répertorier tous les utilisateurs d’une base de données par groupe, exécutez la requête SQL suivante.
```
SELECT u.usesysid
,g.groname
,u.usename
FROM pg_user u
LEFT JOIN pg_group g ON u.usesysid = ANY (g.grolist)
```
# Création, modification et suppression de groupes
Seul un super-utilisateur peut créer, modifier ou supprimer des groupes.
Vous pouvez effectuer les opérations suivantes :
+ Pour créer un groupe, utilisez la commande [CREATE GROUP](r_CREATE_GROUP.md).
+ Pour ajouter ou supprimer des utilisateurs d’un groupe existant, utilisez la commande [ALTER GROUP](r_ALTER_GROUP.md).
+ Pour supprimer un groupe, utilisez la commande [DROP GROUP](r_DROP_GROUP.md). Cette commande supprime uniquement le groupe, pas les utilisateurs qui en sont membres.
# Exemple de contrôle d’accès utilisateur et de groupe
Cet exemple crée des groupes d’utilisateurs et des utilisateurs, puis leur accorde différentes autorisations concernant une base de données Amazon Redshift qui se connecte à un client d’application web. Cet exemple suppose qu’il existe trois groupes d’utilisateurs : les utilisateurs habituels d’une application web, les utilisateurs avancés d’une application web et les développeurs web.
Pour plus d’informations sur la suppression d’un utilisateur d’un groupe, consultez [ALTER GROUP](r_ALTER_GROUP.md).
1. Créez les groupes dans lesquels les utilisateurs seront affectés. L’ensemble de commandes suivant crée trois groupes d’utilisateurs différents :
```
create group webappusers;
create group webpowerusers;
create group webdevusers;
```
1. Créez plusieurs utilisateurs de base de données avec différentes autorisations et ajoutez-les aux groupes.
1. Créez deux utilisateurs et ajoutez-les au groupe WEBAPPUSERS :
```
create user webappuser1 password 'webAppuser1pass'
in group webappusers;
create user webappuser2 password 'webAppuser2pass'
in group webappusers;
```
1. Créez un utilisateur développeur web et ajoutez-le au groupe WEBDEVUSERS :
```
create user webdevuser1 password 'webDevuser2pass'
in group webdevusers;
```
1. Créez un super-utilisateur. Cet utilisateur disposera de droits d’administration lui permettant de créer d’autres utilisateurs :
```
create user webappadmin password 'webAppadminpass1'
createuser;
```
1. Créez un schéma à associer aux tables de base de données utilisées par l’application web et accordez aux différents groupes d’utilisateurs l’accès à ce schéma :
1. Créez le schéma WEBAPP :
```
create schema webapp;
```
1. Accordez les autorisations USAGE au groupe WEBAPPUSERS :
```
grant usage on schema webapp to group webappusers;
```
1. Accordez les autorisations USAGE au groupe WEBPOWERUSERS :
```
grant usage on schema webapp to group webpowerusers;
```
1. Accordez les autorisations ALL au groupe WEBDEVUSERS :
```
grant all on schema webapp to group webdevusers;
```
Les utilisateurs et les groupes de base sont maintenant configurés. Vous pouvez à présent apporter des modifications aux utilisateurs et aux groupes.
1. Par exemple, la commande suivante modifie le paramètre search\$1path pour le. WEBAPPUSER1
```
alter user webappuser1 set search_path to webapp, public;
```
Le paramètre SEARCH\$1PATH spécifie l’ordre de recherche de schéma des objets de base de données, tels que les tables et les fonctions, lorsque l’objet est référencé par un nom simple sans schéma spécifié.
1. Vous pouvez également ajouter des utilisateurs à un groupe après l'avoir créé, par exemple en les ajoutant WEBAPPUSER2 au groupe WEBPOWERUSERS :
```
alter group webpowerusers add user webappuser2;
```
# Schémas
Une base de données contient un ou plusieurs schémas désignés. Chaque schéma dans une base de données contient des tables et d’autres types d’objets nommés. Par défaut, une base de données se compose d’un schéma unique, qui est appelé PUBLIC. Vous pouvez utiliser des schémas pour regrouper des objets de base de données sous un nom commun. Les schémas sont similaires aux répertoires de système de fichiers, sauf qu’ils ne peuvent pas s’imbriquer.
Des noms d’objet de base de données identiques peuvent être utilisés dans des schémas distincts de la même base de données sans que cela entraîne de conflits. Par exemple, MY\$1SCHEMA et YOUR\$1SCHEMA peuvent contenir une table nommée MYTABLE. Les utilisateurs disposant des autorisations nécessaires peuvent accéder aux objets sur plusieurs schémas dans une base de données.
Par défaut, un objet est créé dans le premier schéma du chemin d’accès de la base de données. Pour plus d’informations, consultez [Chemin de recherche](#c_Search_path) plus loin dans cette section.
Les schémas permettent de résoudre les problèmes d’organisation et de simultanéité dans un environnement multi-utilisateur comme suit :
+ Pour permettre à de nombreux développeurs d’utiliser la même base de données sans interférer dans leurs travaux respectifs.
+ Pour organiser les objets de base de données en groupes logiques afin de les rendre plus faciles à gérer.
+ Pour fournir à des applications la possibilité de placer leurs objets dans des schémas distincts, afin que leurs noms ne créent pas de conflits avec les noms des objets utilisés par d’autres applications.
## Chemin de recherche
Le chemin de recherche est défini dans le paramètre search\$1path avec une liste séparée par des virgules de noms de schémas. Le chemin d’accès spécifie l’ordre dans lequel les schémas sont recherchés lorsqu’un objet, comme une table ou une fonction, est référencé par un nom simple qui n’inclut pas de qualificateur de schéma.
Si un objet est créé sans spécifier de schéma cible, l’objet est ajouté au premier schéma qui est répertorié dans le chemin de recherche. Lorsqu’il existe des objets avec des noms identiques dans des schémas distincts, un nom d’objet qui ne spécifie pas de schéma fera référence au premier schéma du chemin d’accès qui contient un objet portant ce nom.
Pour modifier le schéma par défaut de la session en cours, utilisez la commande [SET](r_SET.md).
Pour plus d’informations, consultez la description de [search\$1path](r_search_path.md) dans la Référence de configuration.
# Création, modification et suppression de schémas
N’importe quel utilisateur peut créer des schémas et modifier ou supprimer ceux qu’il possède.
Vous pouvez effectuer les opérations suivantes :
+ Pour créer un schéma, utilisez la commande [CREATE SCHEMA](r_CREATE_SCHEMA.md).
+ Pour modifier le propriétaire d’un schéma, utilisez la commande [ALTER SCHEMA](r_ALTER_SCHEMA.md).
+ Pour supprimer un schéma et ses objets, utilisez la commande [DROP SCHEMA](r_DROP_SCHEMA.md).
+ Pour créer une table dans un schéma, créez-la au format *schema\$1name.table\$1name*.
Pour afficher une liste de tous les schémas, interrogez la table catalogue système PG\$1NAMESPACE :
```
select * from pg_namespace;
```
Pour afficher la liste des tables qui font partie d’un schéma, interrogez la table catalogue système PG\$1TABLE\$1DEF. Par exemple, la requête suivante renvoie une liste de tables dans le schéma PG\$1CATALOG.
```
select distinct(tablename) from pg_table_def
where schemaname = 'pg_catalog';
```
# Autorisations basées un schéma
Les autorisations basées sur un schéma sont déterminées par le propriétaire du schéma :
+ Par défaut, tous les utilisateurs disposent des autorisations CREATE et USAGE sur le schéma PUBLIC d’une base de données. Pour interdire aux utilisateurs de créer des objets dans le schéma PUBLIC d’une base de données, utilisez la commande [REVOKE](r_REVOKE.md) pour supprimer cette autorisation.
+ Les utilisateurs ne peuvent accéder à aucun objet des schémas qui ne leur appartiennent pas, sauf s’ils bénéficient de l’autorisation USAGE accordée par le propriétaire de l’objet.
+ Si les utilisateurs bénéficient de l’autorisation CREATE pour un schéma créé par un autre utilisateur, ils peuvent créer des objets dans ce schéma.
# Contrôle d’accès basé sur les rôles (RBAC)
En utilisant le contrôle d’accès basé sur les rôles (RBAC) afin de gérer les autorisations de base de données dans Amazon Redshift, vous pouvez simplifier la gestion des autorisations de sécurité dans Amazon Redshift. Vous pouvez sécuriser l’accès aux données sensibles en contrôlant ce que les utilisateurs peuvent faire à un niveau étendu ou plus précis. Vous pouvez également contrôler l’accès des utilisateurs aux tâches normalement limitées aux super-utilisateurs. En attribuant différentes autorisations à différents rôles et en les attribuant à différents utilisateurs, vous pouvez bénéficier d’un contrôle plus précis de l’accès des utilisateurs.
Les utilisateurs dotés d’un rôle assigné peuvent uniquement effectuer les tâches spécifiées par le rôle assigné auquel ils sont autorisés. Par exemple, un utilisateur doté du rôle assigné ayant les autorisations CREATE TABLE et DROP TABLE est uniquement autorisé à effectuer ces tâches. Vous pouvez contrôler l’accès des utilisateurs en accordant différents niveaux d’autorisations de sécurité à différents utilisateurs afin qu’ils puissent accéder aux données dont ils ont besoin pour leur travail.
Le RBAC applique le principe des moindres autorisations aux utilisateurs en fonction de leurs exigences de rôle, quels que soient les types d’objets concernés. L’octroi et la révocation des autorisations s’effectuent au niveau du rôle, sans qu’il soit nécessaire de mettre à jour les autorisations sur des objets de base de données individuels.
Avec le RBAC, vous pouvez créer des rôles dotés d’autorisations permettant d’exécuter des commandes qui nécessitaient auparavant des autorisations de super-utilisateur. Les utilisateurs peuvent exécuter ces commandes tant qu’un rôle incluant ces autorisations leur est autorisé. De même, vous pouvez également créer des rôles afin de limiter l’accès à certaines commandes et attribuer le rôle à des super-utilisateurs ou à des utilisateurs pour lesquels le rôle a été autorisé.
Pour découvrir comment fonctionne le contrôle d’accès basé sur les rôles (RBAC) Amazon Redshift, regardez la vidéo suivante.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/IhHQ7mZ-tp4)
# Hiérarchie des rôles
Les *rôles* sont des ensembles d’autorisations que vous pouvez attribuer à un utilisateur ou à un autre rôle. Vous pouvez attribuer des autorisations système ou de base de données à un rôle. Un utilisateur hérite des autorisations d’un rôle assigné.
Dans le RBAC, les utilisateurs peuvent disposer de rôles imbriqués. Vous pouvez attribuer des rôles à la fois à des utilisateurs et à des rôles. Lorsque vous accordez un rôle à un utilisateur, vous autorisez l’utilisateur à disposer de toutes les autorisations incluses dans ce rôle. Lorsque vous accordez un rôle r1 à un utilisateur, vous autorisez l’utilisateur à disposer des autorisations de r1. L’utilisateur dispose désormais des autorisations de r1 et de toutes les autorisations existantes qu’il possède déjà.
Lorsque vous accordez un rôle (r1) à un autre rôle (r2), vous autorisez r2 à disposer de toutes les autorisations de r1. En outre, lors de l’octroi de r2 à un autre rôle (r3), les autorisations de r3 équivalent à la combinaison des autorisations de r1 et de r2. La hiérarchie des rôles sous-entend que r2 hérite des autorisations de r1. Amazon Redshift propage les autorisations à chaque autorisation de rôle. L’octroi de r1 à r2, puis de r2 à r3 a pour effet d’autoriser r3 à disposer de toutes les autorisations des trois rôles. Ainsi, en accordant r3 à un utilisateur, l’utilisateur dispose de toutes les autorisations des trois rôles.
Amazon Redshift n’autorise pas la création d’un cycle d’autorisation des rôles. Un cycle d’autorisation des rôles se crée lorsqu’un rôle imbriqué est réaffecté à un rôle se trouvant plus avant dans la hiérarchie des rôles, tel que le fait de réassigner r3 à r1. Pour plus d’informations sur la création de rôles et la gestion des affectations de rôles, consultez [Gestion des rôles dans le RBAC](r_roles-managing.md).
# Attribution des rôles
Les super-utilisateurs et les utilisateurs standard disposant des autorisations CREATE ROLE peuvent utiliser l’instruction CREATE ROLE afin de créer des rôles. Les super-utilisateurs et les administrateurs de rôle peuvent utiliser l’instruction GRANT ROLE pour accorder un rôle aux autres. Ils peuvent utiliser l’instruction REVOKE ROLE pour révoquer un rôle assigné à d’autres, et l’instruction DROP ROLE pour supprimer des rôles. Les administrateurs de rôles incluent les propriétaires de rôles et les utilisateurs auxquels le rôle a été accordé avec l’autorisation ADMIN OPTION.
Seuls les super-utilisateurs ou les administrateurs de rôle peuvent accorder et révoquer des rôles. Vous pouvez accorder un ou plusieurs rôles à un ou plusieurs rôles ou utilisateurs, ou révoquer un ou plusieurs rôles assignés à un ou plusieurs rôles ou utilisateurs. Utilisez l’option WITH ADMIN OPTION de l’instruction GRANT ROLE afin de fournir les options d’administration de tous les rôles accordés à tous les bénéficiaires.
Amazon Redshift prend en charge différentes combinaisons d’attributions de rôles, telles que l’octroi de plusieurs rôles ou l’assignation de plusieurs bénéficiaires. L’option WITH ADMIN OPTION s’applique uniquement aux utilisateurs, et non aux rôles. De même, utilisez l’option WITH ADMIN OPTION de l’instruction REVOKE ROLE pour supprimer le rôle et l’autorisation administrative du bénéficiaire. Lorsqu’elle est utilisée avec l’option ADMIN OPTION, seule l’autorisation administrative est révoquée pour le rôle.
L’exemple suivant révoque l’autorisation administrative du rôle `sample_role2` pour `user2`.
```
REVOKE ADMIN OPTION FOR sample_role2 FROM user2;
```
Pour plus d’informations sur la création de rôles et la gestion des affectations de rôles, consultez [Gestion des rôles dans le RBAC](r_roles-managing.md).
# Rôles définis par le système Amazon Redshift
Amazon Redshift fournit quelques rôles définis par le système qui sont définis au moyen d’autorisations spécifiques. Les rôles propres au système commencent par un préfixe `sys:`. Seuls les utilisateurs disposant d’un accès approprié peuvent modifier des rôles définis par le système ou créer des rôles personnalisés définis par le système. Vous ne pouvez pas utiliser le préfixe `sys:` pour un rôle personnalisé défini par le système.
Le tableau suivant résume les rôles et leurs autorisations.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/r_roles-default.html)
## Rôles et utilisateurs définis par le système pour le partage de données
Amazon Redshift crée des rôles et des utilisateurs à usage interne qui correspondent aux unités de partage des données et aux consommateurs des unités de partages des données. Chaque nom de rôle et nom d’utilisateur interne possède le préfixe `ds:` d’espace de noms réservé. Ils sont au format suivant :
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/r_roles-default.html)
Un rôle de partage de données est créé pour chaque unité de partage des données. Il contient toutes les autorisations actuellement accordées à l’unité de partage des données. Un utilisateur de partage de données est créé pour chaque consommateur d’unité de partage des données. Il est autorisé à utiliser un seul rôle de partage de données. Un consommateur ajouté à plusieurs unités de partage des données aura un utilisateur de partage de données créé pour chaque unité de partage des données.
Ces utilisateurs et rôles sont nécessaires au bon fonctionnement du partage de données. Ils ne peuvent pas être modifiés ou supprimés et ne peuvent être accédés ou utilisés pour aucune tâche exécutée par les clients. Vous pouvez les ignorer sans risque. Pour plus d’informations sur le partage de données, consultez [Partager des données entre plusieurs clusters dans Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/dg/datashare-overview.html).
**Note**
Vous ne pouvez pas utiliser le préfixe `ds:` pour créer des rôles ou des utilisateurs définis par l’utilisateur.
# Autorisations système pour le RBAC
Vous trouverez ci-dessous une liste d’autorisations système que vous pouvez accorder à un rôle ou révoquer pour celui-ci.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/redshift/latest/dg/r_roles-system-privileges.html)
# Autorisations d’objet de base de données
Outre les autorisations système, Amazon Redshift comprend des autorisations d’objet de base de données qui définissent les options d’accès. Celles-ci incluent des options telles que la faculté de lire les données des tables et des vues, écrire des données, créer et supprimer des tables. Pour plus d’informations, consultez [GRANT](r_GRANT.md).
En utilisant le RBAC, vous pouvez attribuer des autorisations d’objet de base de données à des rôles, de la même manière qu’avec les autorisations système. Vous pouvez ensuite attribuer des rôles à des utilisateurs, autoriser des utilisateurs disposant d’autorisations système et autoriser des utilisateurs disposant d’autorisations de base de données.
# Instruction ALTER DEFAULT PRIVILEGES pour le RBAC
Utilisez l’instruction ALTER DEFAULT PRIVILEGES pour définir le groupe d’autorisations d’accès par défaut à appliquer sur des objets qui seront créés à l’avenir par l’utilisateur spécifié. Par défaut, les utilisateurs peuvent ne modifier que leurs propres autorisations d’accès par défaut. Avec le RBAC, vous pouvez définir les autorisations d’accès par défaut pour les rôles. Pour plus d’informations, consultez la commande [ALTER DEFAULT PRIVILEGES](r_ALTER_DEFAULT_PRIVILEGES.md).
Le RBAC vous permet d’attribuer des autorisations d’objet de base de données à des rôles, de la même manière qu’avec les autorisations système. Vous pouvez ensuite attribuer des rôles à des utilisateurs, autoriser des utilisateurs disposant d’autorisations système et/ou de base de données.
# Considérations concernant l’utilisation des rôles dans le RBAC
Lorsque vous travaillez avec des rôles RBAC, tenez compte des points suivants :
+ Amazon Redshift n’autorise pas les cycles d’autorisations des rôles. Vous ne pouvez pas accorder r1 à r2, puis accorder r2 à r1.
+ Le RBAC fonctionne à la fois pour les objets Amazon Redshift natifs et les tables Amazon Redshift Spectrum.
+ En tant qu’administrateur Amazon Redshift, vous pouvez activer le RBAC en mettant à niveau votre cluster vers le dernier correctif de maintenance pour commencer.
+ Seuls les super-utilisateurs et les utilisateurs disposant de l’autorisation système CREATE ROLE peuvent créer des rôles.
+ Seuls les super-utilisateurs et les administrateurs de rôle peuvent modifier ou supprimer des rôles.
+ Un nom de rôle ne peut pas être identique à un nom d’utilisateur.
+ Un nom de rôle ne peut pas contenir de caractères non valides, tels que « :/\$1n ».
+ Un nom de rôle ne peut pas être un mot réservé, tel que PUBLIC.
+ Le nom du rôle ne peut pas commencer par le préfixe réservé pour les rôles par défaut, à savoir `sys:`.
+ Vous ne pouvez pas supprimer un rôle qui possède le paramètre RESTRICT lorsqu’il est accordé à un autre rôle. Le paramètre par défaut est RESTRICT. Amazon Redshift génère une erreur lorsque vous tentez de supprimer un rôle qui a hérité d’un autre rôle.
+ Les utilisateurs qui ne disposent pas d’autorisations d’administrateur sur un rôle ne peuvent pas accorder ou révoquer un rôle.
+ Le RBAC n’est pas entièrement pris en charge pour les tables et les vues système. Les autorisations RBAC pour les tables et les vues système ne sont pas conservées lors des mises à niveau, des rétrogradations ou des redimensionnements. Nous vous recommandons d’utiliser [Rôles définis par le système Amazon RedshiftRôles et utilisateurs définis par le système pour le partage de données](r_roles-default.md) pour gérer la table système et afficher les autorisations. Pour plus d’informations sur les tables système, consultez [Informations de référence sur les tables et les vues système](cm_chap_system-tables.md).
# Gestion des rôles dans le RBAC
Pour effectuer les actions suivantes, utilisez les commandes suivantes :
+ Pour créer un rôle, utilisez la commande [CREATE ROLE](r_CREATE_ROLE.md).
+ Pour renommer un rôle ou modifier le propriétaire du rôle, utilisez la commande [ALTER ROLE](r_ALTER_ROLE.md).
+ Pour supprimer un rôle, utilisez la commande [DROP ROLE](r_DROP_ROLE.md).
+ Pour attribuer un rôle à un utilisateur, utilisez la commande [GRANT](r_GRANT.md).
+ Pour révoquer un rôle d’un utilisateur, utilisez la commande [REVOKE](r_REVOKE.md).
+ Pour accorder des autorisations système à un rôle, utilisez la commande [GRANT](r_GRANT.md).
+ Pour révoquer des autorisations système pour un rôle, utilisez la commande [REVOKE](r_REVOKE.md).
Pour afficher la liste des rôles de votre cluster ou de votre groupe de travail, consultez [SVV\$1ROLES](r_SVV_ROLES.md).
# Didacticiel : Création de rôles et interrogation avec RBAC
Avec le RBAC, vous pouvez créer des rôles dotés d’autorisations permettant d’exécuter des commandes qui nécessitaient auparavant des autorisations de super-utilisateur. Les utilisateurs peuvent exécuter ces commandes tant qu’un rôle incluant ces autorisations leur est autorisé.
Dans ce didacticiel, vous utilisez le contrôle d’accès basé sur les rôles (RBAC) pour gérer les autorisations dans la base de données que vous créez. Vous vous connectez ensuite à la base de données et l’interrogez à partir de deux rôles différents pour tester les fonctionnalités du RBAC.
Les deux rôles que vous créez et utilisez pour interroger la base de données sont `sales_ro` et `sales_rw`. Vous créez le rôle `sales_ro` et interrogez les données en tant qu’utilisateur avec le rôle `sales_ro`. L’utilisateur `sales_ro` peut uniquement utiliser la commande SELECT, mais ne peut pas utiliser la commande UPDATE. Vous créez ensuite le rôle `sales_rw` et interrogez les données en tant qu’utilisateur avec le rôle `sales_rw`. L’utilisateur `sales_rw` peut utiliser les commandes SELECT et UPDATE.
De plus, vous pouvez également créer des rôles afin de limiter l’accès à certaines commandes et attribuer le rôle à des super-utilisateurs ou à des utilisateurs.
**Tâches**
+ [Conditions préalables](#tutorial-rbac-prereqs)
+ [Étape 1 : Créer un utilisateur administrateur](#tutorial-rbac-step1)
+ [Étape 2 : Configuration des schémas](#tutorial-rbac-step2)
+ [Étape 3 : Créer un utilisateur en lecture seule](#tutorial-rbac-step3)
+ [Étape 4 : Interroger les données en tant qu’utilisateur en lecture seule](#tutorial-rbac-step4)
+ [Étape 5 : Créer un utilisateur en lecture-écriture](#tutorial-rbac-step5)
+ [Étape 6 : Interroger les données en tant qu’utilisateur avec le rôle en lecture seule hérité](#tutorial-rbac-step6)
+ [Étape 7 : Accorder des autorisations de mise à jour et d’insertion pour le rôle en lecture-écriture](#tutorial-rbac-step7)
+ [Étape 8 : Interroger les données en tant qu’utilisateur en lecture-écriture](#tutorial-rbac-step8)
+ [Étape 9 : Analyser et vider les tables d’une base de données en tant qu’utilisateur administrateur](#tutorial-rbac-step9)
+ [Étape 10 : Tronquer les tables en tant qu’utilisateur en lecture-écriture](#tutorial-rbac-step10)
+ [Fonctions système pour le RBAC (en option)](#tutorial-rbac-system-functions)
+ [Vues système pour le RBAC (facultatif)](#tutorial-rbac-system-views)
+ [Utiliser la sécurité au niveau des lignes avec le RBAC (facultatif)](#tutorial-rbac-rls)
## Conditions préalables
+ Créez un cluster Amazon Redshift ou un groupe de travail sans serveur chargé avec la base de données d’exemples TICKIT. Pour créer un groupe de travail sans serveur, consultez [Commencer avec les entrepôts de données Redshift sans serveur](https://docs.aws.amazon.com/redshift/latest/gsg/new-user-serverless.html). Pour créer un cluster, consultez [Créer un exemple de cluster Amazon Redshift](https://docs.aws.amazon.com/redshift/latest/gsg/rs-gsg-launch-sample-cluster.html). Pour plus d’informations sur l’exemple de base de données TICKIT, consultez [Exemple de base de données](c_sampledb.md).
+ Accédez à un utilisateur doté d’autorisations de super-utilisateur ou d’administrateur de rôles. Seuls les super-utilisateurs ou les administrateurs de rôle peuvent accorder ou révoquer des rôles. Pour plus d’informations sur les autorisations requises pour le RBAC, consultez [Autorisations système pour le RBAC](r_roles-system-privileges.md).
+ Prenez connaissance des [Considérations concernant l’utilisation des rôles dans le RBAC](r_role-usage-notes.md).
## Étape 1 : Créer un utilisateur administrateur
Pour ce didacticiel, vous devez créer un rôle d’administrateur de base de données et l’attacher à un utilisateur administrateur de base de données au cours de cette étape. Vous devez créer l’administrateur de base de données en tant que super-utilisateur ou administrateur de rôles.
Exécutez toutes les requêtes dans [Amazon Redshift Query Editor v2](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-using.html).
1. Pour créer le rôle d’administrateur db\$1admin, utilisez l’exemple suivant.
```
CREATE ROLE db_admin;
```
1. Pour créer un utilisateur de base de données nommé dbadmin, utilisez l’exemple suivant.
```
CREATE USER dbadmin PASSWORD 'Test12345';
```
1. Pour attribuer le rôle défini par le système nommé sys:dba au rôle db\$1admin, utilisez l’exemple suivant. Lorsque le rôle sys:dba est attribué, l’utilisateur dbadmin peut créer des schémas et des tables. Pour plus d’informations, consultez [Rôles définis par le système Amazon RedshiftRôles et utilisateurs définis par le système pour le partage de données](r_roles-default.md).
## Étape 2 : Configuration des schémas
Au cours de cette étape, vous vous connectez à votre base de données en tant qu’administrateur de base de données. Ensuite, vous créez deux schémas et vous y ajoutez des données.
1. Établissez une connexion à la base de données dev en tant qu’utilisateur dbadmin à l’aide de l’éditeur de requête v2. Pour plus d’informations sur la connexion à une base de données, consultez [Utilisation de l’éditeur de requête v2](https://docs.aws.amazon.com/redshift/latest/mgmt/query-editor-v2-using.html).
1. Pour créer les schémas de la base de données de vente et de marketing, utilisez l’exemple suivant.
```
CREATE SCHEMA sales;
CREATE SCHEMA marketing;
```
1. Pour créer et insérer des valeurs dans les tables du schéma de vente, utilisez l’exemple suivant.
```
CREATE TABLE sales.cat(
catid smallint,
catgroup varchar(10),
catname varchar(10),
catdesc varchar(50)
);
INSERT INTO sales.cat(SELECT * FROM category);
CREATE TABLE sales.dates(
dateid smallint,
caldate date,
day char(3),
week smallint,
month char(5),
qtr char(5),
year smallint,
holiday boolean
);
INSERT INTO sales.dates(SELECT * FROM date);
CREATE TABLE sales.events(
eventid integer,
venueid smallint,
catid smallint,
dateid smallint,
eventname varchar(200),
starttime timestamp
);
INSERT INTO sales.events(SELECT * FROM event);
CREATE TABLE sales.sale(
salesid integer,
listid integer,
sellerid integer,
buyerid integer,
eventid integer,
dateid smallint,
qtysold smallint,
pricepaid decimal(8,2),
commission decimal(8,2),
saletime timestamp
);
INSERT INTO sales.sale(SELECT * FROM sales);
```
1. Pour créer et insérer des valeurs dans les tables du schéma de marketing, utilisez l’exemple suivant.
```
CREATE TABLE marketing.cat(
catid smallint,
catgroup varchar(10),
catname varchar(10),
catdesc varchar(50)
);
INSERT INTO marketing.cat(SELECT * FROM category);
CREATE TABLE marketing.dates(
dateid smallint,
caldate date,
day char(3),
week smallint,
month char(5),
qtr char(5),
year smallint,
holiday boolean
);
INSERT INTO marketing.dates(SELECT * FROM date);
CREATE TABLE marketing.events(
eventid integer,
venueid smallint,
catid smallint,
dateid smallint,
eventname varchar(200),
starttime timestamp
);
INSERT INTO marketing.events(SELECT * FROM event);
CREATE TABLE marketing.sale(
marketingid integer,
listid integer,
sellerid integer,
buyerid integer,
eventid integer,
dateid smallint,
qtysold smallint,
pricepaid decimal(8,2),
commission decimal(8,2),
saletime timestamp
);
INSERT INTO marketing.sale(SELECT * FROM marketing);
```
## Étape 3 : Créer un utilisateur en lecture seule
Au cours de cette étape, vous créez un rôle en lecture seule et un utilisateur salesanalyst pour le rôle en lecture seule. L’analyste des ventes n’a besoin que d’un accès en lecture seule aux tables du schéma des ventes pour accomplir la tâche qui lui est assignée, à savoir trouver les événements qui ont généré les commissions les plus importantes.
1. Établissez une connexion à la base de données en tant qu’utilisateur dbadmin.
1. Pour créer le rôle sales\$1ro, utilisez l’exemple suivant.
```
CREATE ROLE sales_ro;
```
1. Pour créer l’utilisateur salesanalyst, utilisez l’exemple suivant.
```
CREATE USER salesanalyst PASSWORD 'Test12345';
```
1. Pour accorder au rôle sales\$1ro l’accès d’utilisation et de sélection des objets du schéma de vente, utilisez l’exemple suivant.
```
GRANT USAGE ON SCHEMA sales TO ROLE sales_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA sales TO ROLE sales_ro;
```
1. Pour attribuer le rôle sales\$1ro à l’utilisateur salesanalyst, utilisez l’exemple suivant.
```
GRANT ROLE sales_ro TO salesanalyst;
```
## Étape 4 : Interroger les données en tant qu’utilisateur en lecture seule
Au cours de cette étape, l’utilisateur salesanalyst interroge les données du schéma de vente. L’utilisateur salesanalyst tente ensuite de mettre à jour une table et de lire des tables dans le schéma de marketing.
1. Établissez une connexion à la base de données en tant qu’utilisateur salesanalyst.
1. Pour trouver les 10 ventes avec les commissions les plus élevées, utilisez l’exemple suivant.
```
SET SEARCH_PATH TO sales;
SELECT DISTINCT events.dateid, sale.commission, cat.catname
FROM sale, events, dates, cat
WHERE events.dateid=dates.dateid AND events.dateid=sale.dateid AND events.catid = cat.catid
ORDER BY 2 DESC LIMIT 10;
+--------+------------+----------+
| dateid | commission | catname |
+--------+------------+----------+
| 1880 | 1893.6 | Pop |
| 1880 | 1893.6 | Opera |
| 1880 | 1893.6 | Plays |
| 1880 | 1893.6 | Musicals |
| 1861 | 1500 | Plays |
| 2003 | 1500 | Pop |
| 1861 | 1500 | Opera |
| 2003 | 1500 | Plays |
| 1861 | 1500 | Musicals |
| 1861 | 1500 | Pop |
+--------+------------+----------+
```
1. Pour sélectionner 10 événements dans la table des événements du schéma de vente, utilisez l’exemple suivant.
```
SELECT * FROM sales.events LIMIT 10;
+---------+---------+-------+--------+--------------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+--------------------+---------------------+
| 4836 | 73 | 9 | 1871 | Soulfest | 2008-02-14 19:30:00 |
| 5739 | 41 | 9 | 1871 | Fab Faux | 2008-02-14 19:30:00 |
| 627 | 229 | 6 | 1872 | High Society | 2008-02-15 14:00:00 |
| 2563 | 246 | 7 | 1872 | Hamlet | 2008-02-15 20:00:00 |
| 7703 | 78 | 9 | 1872 | Feist | 2008-02-15 14:00:00 |
| 7903 | 90 | 9 | 1872 | Little Big Town | 2008-02-15 19:30:00 |
| 7925 | 101 | 9 | 1872 | Spoon | 2008-02-15 19:00:00 |
| 8113 | 17 | 9 | 1872 | Santana | 2008-02-15 15:00:00 |
| 463 | 303 | 8 | 1873 | Tristan und Isolde | 2008-02-16 19:00:00 |
| 613 | 236 | 6 | 1873 | Pal Joey | 2008-02-16 15:00:00 |
+---------+---------+-------+--------+--------------------+---------------------+
```
1. Pour tenter de mettre à jour le nom de l’événement avec eventid 1, exécutez l’exemple suivant. Cet exemple provoquera une erreur de refus d’autorisation car l’utilisateur salesanalyst ne dispose que des autorisations SELECT sur la table des événements du schéma de vente. Pour mettre à jour la table des événements, vous devez donner l’autorisation UPDATE au rôle sales\$1ro. Pour plus d’informations sur la manière de donner l’autorisation de mettre à jour une table, consultez le paramètre UPDATE pour [GRANT](r_GRANT.md). Pour plus d’informations sur la commande UPDATE, consultez [UPDATE](r_UPDATE.md).
```
UPDATE sales.events
SET eventname = 'Comment event'
WHERE eventid = 1;
ERROR: permission denied for relation events
```
1. Pour essayer de tout sélectionner dans la table des événements du schéma de marketing, utilisez l’exemple suivant. Cet exemple provoquera une erreur de refus d’autorisation car l’utilisateur salesanalyst ne dispose que des autorisations SELECT sur la table des événements du schéma de vente. Pour sélectionner des données dans la table des événements du schéma de marketing, vous devez accorder au rôle sales\$1ro les autorisations SELECT sur la table des événements du schéma de marketing.
```
SELECT * FROM marketing.events;
ERROR: permission denied for schema marketing
```
## Étape 5 : Créer un utilisateur en lecture-écriture
Au cours de cette étape, l’ingénieur des ventes chargé de créer le pipeline d’extraction, de transformation et de chargement (ETL) pour le traitement des données dans le schéma de vente bénéficiera d’un accès en lecture seule, puis d’un accès en lecture-écriture pour effectuer ses tâches.
1. Établissez une connexion à la base de données en tant qu’utilisateur dbadmin.
1. Pour créer le rôle sales\$1rw dans le schéma de vente, utilisez l’exemple suivant.
```
CREATE ROLE sales_rw;
```
1. Pour créer l’utilisateur salesengineer, utilisez l’exemple suivant.
```
CREATE USER salesengineer PASSWORD 'Test12345';
```
1. Pour accorder au rôle sales\$1rw l’accès d’utilisation et de sélection des objets du schéma de vente en lui attribuant le rôle sales\$1ro, utilisez l’exemple suivant. Pour plus d’informations sur la façon dont les rôles héritent des autorisations dans Amazon Redshift, consultez [Hiérarchie des rôles](t_role_hierarchy.md).
```
GRANT ROLE sales_ro TO ROLE sales_rw;
```
1. Pour attribuer le rôle sales\$1rw à l’utilisateur salesengineer, utilisez l’exemple suivant.
```
GRANT ROLE sales_rw TO salesengineer;
```
## Étape 6 : Interroger les données en tant qu’utilisateur avec le rôle en lecture seule hérité
Au cours de cette étape, l’utilisateur salesengineer tente de mettre à jour la table des événements avant de recevoir des autorisations de lecture.
1. Établissez une connexion à la base de données en tant qu’utilisateur salesengineer.
1. L’utilisateur salesengineer peut lire avec succès les données de la table des événements du schéma de vente. Pour sélectionner l’événement eventid1 dans la table des événements du schéma de vente, utilisez l’exemple suivant.
```
SELECT * FROM sales.events where eventid=1;
+---------+---------+-------+--------+-----------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+-----------------+---------------------+
| 1 | 305 | 8 | 1851 | Gotterdammerung | 2008-01-25 14:30:00 |
+---------+---------+-------+--------+-----------------+---------------------+
```
1. Pour essayer de tout sélectionner dans la table des événements du schéma de marketing, utilisez l’exemple suivant. L’utilisateur salesengineer n’étant pas autorisé à accéder aux tables du schéma de marketing, cette requête provoquera une erreur de refus d’autorisation. Pour sélectionner des données dans la table des événements du schéma de marketing, vous devez accorder au rôle sales\$1rw les autorisations SELECT sur la table des événements du schéma de marketing.
```
SELECT * FROM marketing.events;
ERROR: permission denied for schema marketing
```
1. Pour tenter de mettre à jour le nom de l’événement avec eventid 1, exécutez l’exemple suivant. Cet exemple provoquera une erreur de refus d’autorisation car l’utilisateur salesengineer ne dispose que des autorisations SELECT sur la table des événements du schéma de vente. Pour mettre à jour la table des événements, vous devez donner l’autorisation UPDATE au rôle sales\$1rw.
```
UPDATE sales.events
SET eventname = 'Comment event'
WHERE eventid = 1;
ERROR: permission denied for relation events
```
## Étape 7 : Accorder des autorisations de mise à jour et d’insertion pour le rôle en lecture-écriture
Au cours de cette étape, vous accordez des autorisations de mise à jour et d’insertion au rôle sales\$1rw.
1. Établissez une connexion à la base de données en tant qu’utilisateur dbadmin.
1. Pour accorder les autorisations UPDATE, INSERT et DELETE au rôle sales\$1rw, utilisez l’exemple suivant.
```
GRANT UPDATE, INSERT, ON ALL TABLES IN SCHEMA sales TO role sales_rw;
```
## Étape 8 : Interroger les données en tant qu’utilisateur en lecture-écriture
Au cours de cette étape, l’ingénieur de vente met à jour la table avec succès une fois que son rôle a obtenu les autorisations d’insertion et de mise à jour. Ensuite, l’ingénieur de vente tente d’analyser et de vider la table des événements, mais n’y parvient pas.
1. Établissez une connexion à la base de données en tant qu’utilisateur salesengineer.
1. Pour mettre à jour le nom de l’événement avec eventid 1, exécutez l’exemple suivant.
```
UPDATE sales.events
SET eventname = 'Comment event'
WHERE eventid = 1;
```
1. Pour afficher la modification apportée dans la requête précédente, utilisez l’exemple suivant pour sélectionner l’événement eventid 1 dans la table des événements du schéma de vente.
```
SELECT * FROM sales.events WHERE eventid=1;
+---------+---------+-------+--------+---------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+---------------+---------------------+
| 1 | 305 | 8 | 1851 | Comment event | 2008-01-25 14:30:00 |
+---------+---------+-------+--------+---------------+---------------------+
```
1. Pour analyser la table d’événements mise à jour dans le schéma de vente, utilisez l’exemple suivant. Cet exemple provoquera une erreur de refus d’autorisation car l’utilisateur salesengineer ne dispose pas des autorisations nécessaires et n’est pas le propriétaire de la table des événements dans le schéma de vente. Pour analyser la table des événements, vous devez accorder au rôle sales\$1rw l’autorisation ANALYZE à l’aide de la commande GRANT. Pour plus d’informations sur la commande ANALYZE, consultez [ANALYSE](r_ANALYZE.md).
```
ANALYZE sales.events;
ERROR: skipping "events" --- only table or database owner can analyze
```
1. Pour vider la table des événements mise à jour, utilisez l’exemple suivant. Cet exemple provoquera une erreur de refus d’autorisation car l’utilisateur salesengineer ne dispose pas des autorisations nécessaires et n’est pas le propriétaire de la table des événements dans le schéma de vente. Pour vider la table des événements, vous devez accorder au rôle sales\$1rw les autorisations VACUUM à l’aide de la commande GRANT. Pour plus d’informations sur la commande VACUUM, consultez [VACUUM](r_VACUUM_command.md).
```
VACUUM sales.events;
ERROR: skipping "events" --- only table or database owner can vacuum it
```
## Étape 9 : Analyser et vider les tables d’une base de données en tant qu’utilisateur administrateur
Au cours de cette étape, l’utilisateur dbadmin analyse et vide toutes les tables. L’utilisateur dispose d’autorisations d’administrateur sur cette base de données, ce qui lui permet d’exécuter ces commandes.
1. Établissez une connexion à la base de données en tant qu’utilisateur dbadmin.
1. Pour analyser la table des événements dans le schéma de vente, utilisez l’exemple suivant.
```
ANALYZE sales.events;
```
1. Pour vider la table des événements dans le schéma de vente, utilisez l’exemple suivant.
```
VACUUM sales.events;
```
1. Pour analyser la table des événements dans le schéma de marketing, utilisez l’exemple suivant.
```
ANALYZE marketing.events;
```
1. Pour vider la table des événements dans le schéma de marketing, utilisez l’exemple suivant.
```
VACUUM marketing.events;
```
## Étape 10 : Tronquer les tables en tant qu’utilisateur en lecture-écriture
Au cours de cette étape, l’utilisateur salesengineer tente de tronquer la table des événements dans le schéma de vente, mais n’y parvient que lorsque l’utilisateur dbadmin lui accorde des autorisations de troncature.
1. Établissez une connexion à la base de données en tant qu’utilisateur salesengineer.
1. Pour essayer de supprimer toutes les lignes de la table des événements dans le schéma de vente, utilisez l’exemple suivant. Cet exemple provoquera une erreur car l’utilisateur salesengineer ne dispose pas des autorisations nécessaires et n’est pas le propriétaire de la table des événements dans le schéma de vente. Pour tronquer la table des événements, vous devez accorder au rôle sales\$1rw l’autorisation TRUNCATE à l’aide de la commande GRANT. Pour plus d’informations sur la commande TRUNCATE, consultez [TRUNCATE](r_TRUNCATE.md).
```
TRUNCATE sales.events;
ERROR: must be owner of relation events
```
1. Établissez une connexion à la base de données en tant qu’utilisateur dbadmin.
1. Pour accorder les privilèges de tronquer les tables au rôle sales\$1rw, utilisez l’exemple suivant.
```
GRANT TRUNCATE TABLE TO role sales_rw;
```
1. Établissez une connexion à la base de données en tant qu’utilisateur salesengineer à l’aide de query editor v2.
1. Pour lire les 10 premiers événements dans la table des événements du schéma de vente, utilisez l’exemple suivant.
```
SELECT * FROM sales.events ORDER BY eventid LIMIT 10;
+---------+---------+-------+--------+-----------------------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+-----------------------------+---------------------+
| 1 | 305 | 8 | 1851 | Comment event | 2008-01-25 14:30:00 |
| 2 | 306 | 8 | 2114 | Boris Godunov | 2008-10-15 20:00:00 |
| 3 | 302 | 8 | 1935 | Salome | 2008-04-19 14:30:00 |
| 4 | 309 | 8 | 2090 | La Cenerentola (Cinderella) | 2008-09-21 14:30:00 |
| 5 | 302 | 8 | 1982 | Il Trovatore | 2008-06-05 19:00:00 |
| 6 | 308 | 8 | 2109 | L Elisir d Amore | 2008-10-10 19:30:00 |
| 7 | 309 | 8 | 1891 | Doctor Atomic | 2008-03-06 14:00:00 |
| 8 | 302 | 8 | 1832 | The Magic Flute | 2008-01-06 20:00:00 |
| 9 | 308 | 8 | 2087 | The Fly | 2008-09-18 19:30:00 |
| 10 | 305 | 8 | 2079 | Rigoletto | 2008-09-10 15:00:00 |
+---------+---------+-------+--------+-----------------------------+---------------------+
```
1. Pour tronquer la table des événements dans le schéma de vente, utilisez l’exemple suivant.
```
TRUNCATE sales.events;
```
1. Pour lire les données de la table d’événements mise à jour dans le schéma de vente, utilisez l’exemple suivant.
```
SELECT * FROM sales.events ORDER BY eventid LIMIT 10;
+---------+---------+-------+--------+-----------------------------+---------------------+
| eventid | venueid | catid | dateid | eventname | starttime |
+---------+---------+-------+--------+-----------------------------+---------------------+
```
### Créer des rôles en lecture seule et en lecture-écriture pour le schéma de marketing (facultatif)
Au cours de cette étape, vous créez des rôles en lecture seule et en lecture-écriture pour le schéma de marketing.
1. Établissez une connexion à la base de données en tant qu’utilisateur dbadmin.
1. Pour créer des rôles en lecture seule et en lecture-écriture pour le schéma de marketing, utilisez l’exemple suivant.
```
CREATE ROLE marketing_ro;
CREATE ROLE marketing_rw;
GRANT USAGE ON SCHEMA marketing TO ROLE marketing_ro, ROLE marketing_rw;
GRANT SELECT ON ALL TABLES IN SCHEMA marketing TO ROLE marketing_ro;
GRANT ROLE marketing_ro TO ROLE marketing_rw;
GRANT INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA marketing TO ROLE marketing_rw;
CREATE USER marketinganalyst PASSWORD 'Test12345';
CREATE USER marketingengineer PASSWORD 'Test12345';
GRANT ROLE marketing_ro TO marketinganalyst;
GRANT ROLE marketing_rw TO marketingengineer;
```
## Fonctions système pour le RBAC (en option)
Amazon Redshift dispose de deux fonctions pour fournir des informations système sur l’appartenance des utilisateurs et des rôles à des groupes ou rôles supplémentaires : role\$1is\$1member\$1of et user\$1is\$1member\$1of. Ces fonctions sont disponibles pour les super-utilisateurs et les utilisateurs standards. Les super-utilisateurs peuvent vérifier l’appartenance de tous les rôles. Les utilisateurs standards ne peuvent vérifier l’appartenance que pour les rôles auxquels ils ont été autorisés à accéder.
Pour utiliser la fonction role\$1is\$1member\$1of
1. Établissez une connexion à la base de données en tant qu’utilisateur salesengineer.
1. Pour vérifier si le rôle sales\$1rw est membre du rôle sales\$1ro, utilisez l’exemple suivant.
```
SELECT role_is_member_of('sales_rw', 'sales_ro');
+-------------------+
| role_is_member_of |
+-------------------+
| true |
+-------------------+
```
1. Pour vérifier si le rôle sales\$1ro est membre du rôle sales\$1rw, utilisez l’exemple suivant.
```
SELECT role_is_member_of('sales_ro', 'sales_rw');
+-------------------+
| role_is_member_of |
+-------------------+
| false |
+-------------------+
```
Pour utiliser la fonction user\$1is\$1member\$1of
1. Établissez une connexion à la base de données en tant qu’utilisateur salesengineer.
1. L’exemple suivant tente de vérifier l’appartenance de l’utilisateur salesanalyst. Cette requête génère une erreur car salesengineer n’a pas accès à salesanalyst. Pour exécuter correctement cette commande, connectez-vous à la base de données en tant qu’utilisateur salesanalyst et utilisez l’exemple.
```
SELECT user_is_member_of('salesanalyst', 'sales_ro');
ERROR
```
1. Établissez une connexion à la base de données en tant que super-utilisateur.
1. Pour vérifier l’appartenance de l’utilisateur salesanalyst lorsqu’il est connecté en tant que super-utilisateur, utilisez l’exemple suivant.
```
SELECT user_is_member_of('salesanalyst', 'sales_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| true |
+-------------------+
```
1. Établissez une connexion à la base de données en tant qu’utilisateur dbadmin.
1. Pour vérifier l’appartenance de l’utilisateur salesengineer, utilisez l’exemple suivant.
```
SELECT user_is_member_of('salesengineer', 'sales_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| true |
+-------------------+
SELECT user_is_member_of('salesengineer', 'marketing_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| false |
+-------------------+
SELECT user_is_member_of('marketinganalyst', 'sales_ro');
+-------------------+
| user_is_member_of |
+-------------------+
| false |
+-------------------+
```
## Vues système pour le RBAC (facultatif)
Pour consulter les rôles, l’attribution des rôles aux utilisateurs, la hiérarchie des rôles et les privilèges pour les objets de base de données via des rôles, utilisez les vues système d’Amazon Redshift. Ces vues sont accessibles aux super-utilisateurs et aux utilisateurs standards. Les super-utilisateurs peuvent vérifier tous les détails des rôles. Les utilisateurs standards peuvent uniquement vérifier les détails des rôles auxquels ils ont été autorisés à accéder.
1. Pour afficher la liste des utilisateurs auxquels des rôles sont explicitement accordés dans le cluster, utilisez l’exemple suivant.
```
SELECT * FROM svv_user_grants;
```
1. Pour afficher la liste des rôles auxquels des rôles sont explicitement accordés dans le cluster, utilisez l’exemple suivant.
```
SELECT * FROM svv_role_grants;
```
Pour obtenir la liste complète des vues système, consultez [Vues de métadonnées SVV](svv_views.md).
## Utiliser la sécurité au niveau des lignes avec le RBAC (facultatif)
Pour bénéficier d’un contrôle précis des accès à vos données sensibles, utilisez la sécurité au niveau des lignes (RLS). Pour plus d’informations sur RLS, consultez [Sécurité au niveau des lignes](t_rls.md).
Dans cette section, vous créez une politique RLS qui autorise l’utilisateur `salesengineer` à afficher uniquement les lignes de la table `cat` qui ont la valeur `catdesc` de la Major League Baseball. Vous interrogez ensuite la base de données en tant qu’utilisateur `salesengineer`.
1. Établissez une connexion à la base de données en tant qu’utilisateur `salesengineer`.
1. Pour afficher les 5 premières entrées de la table `cat`, utilisez l’exemple suivant.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+---------------------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+---------------------------------+
| 1 | Sports | MLB | Major League Baseball |
| 2 | Sports | NHL | National Hockey League |
| 3 | Sports | NFL | National Football League |
| 4 | Sports | NBA | National Basketball Association |
| 5 | Sports | MLS | Major League Soccer |
+-------+----------+---------+---------------------------------+
```
1. Établissez une connexion à la base de données en tant qu’utilisateur `dbadmin`.
1. Pour créer une politique RLS pour la colonne `catdesc` de la table `cat`, utilisez l’exemple suivant.
```
CREATE RLS POLICY policy_mlb_engineer
WITH (catdesc VARCHAR(50))
USING (catdesc = 'Major League Baseball');
```
1. Pour attacher la politique RLS au rôle `sales_rw`, utilisez l’exemple suivant.
```
ATTACH RLS POLICY policy_mlb_engineer ON sales.cat TO ROLE sales_rw;
```
1. Pour modifier la table afin d’activer la politique RLS, utilisez l’exemple suivant.
```
ALTER TABLE sales.cat ROW LEVEL SECURITY ON;
```
1. Établissez une connexion à la base de données en tant qu’utilisateur `salesengineer`.
1. Pour tenter d’afficher les 5 premières entrées de la table `cat`, utilisez l’exemple suivant. Notez que seules les entrées apparaissent uniquement lorsque la colonne `catdesc` est `Major League Baseball`.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+-----------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+-----------------------+
| 1 | Sports | MLB | Major League Baseball |
+-------+----------+---------+-----------------------+
```
1. Établissez une connexion à la base de données en tant qu’utilisateur `salesanalyst`.
1. Pour tenter d’afficher les 5 premières entrées de la table `cat`, utilisez l’exemple suivant. Notez qu’aucune entrée n’apparaît car la politique par défaut de tout refuser est appliquée.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+-----------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+-----------------------+
```
1. Établissez une connexion à la base de données en tant qu’utilisateur `dbadmin`.
1. Pour accorder l’autorisation IGNORE RLS au rôle `sales_ro`, utilisez l’exemple suivant. Cela donne à l’utilisateur `salesanalyst` l’autorisation d’ignorer les politiques RLS puisqu’il est membre du rôle `sales_ro`.
```
GRANT IGNORE RLS TO ROLE sales_ro;
```
1. Établissez une connexion à la base de données en tant qu’utilisateur `salesanalyst`.
1. Pour afficher les 5 premières entrées de la table `cat`, utilisez l’exemple suivant.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+---------------------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+---------------------------------+
| 1 | Sports | MLB | Major League Baseball |
| 2 | Sports | NHL | National Hockey League |
| 3 | Sports | NFL | National Football League |
| 4 | Sports | NBA | National Basketball Association |
| 5 | Sports | MLS | Major League Soccer |
+-------+----------+---------+---------------------------------+
```
1. Établissez une connexion à la base de données en tant qu’utilisateur `dbadmin`.
1. Pour révoquer l’autorisation IGNORE RLS du rôle `sales_ro`, utilisez l’exemple suivant.
```
REVOKE IGNORE RLS FROM ROLE sales_ro;
```
1. Établissez une connexion à la base de données en tant qu’utilisateur `salesanalyst`.
1. Pour tenter d’afficher les 5 premières entrées de la table `cat`, utilisez l’exemple suivant. Notez qu’aucune entrée n’apparaît car la politique par défaut de tout refuser est appliquée.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+-----------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+-----------------------+
```
1. Établissez une connexion à la base de données en tant qu’utilisateur `dbadmin`.
1. Pour détacher la politique RLS de la table `cat`, utilisez l’exemple suivant.
```
DETACH RLS POLICY policy_mlb_engineer ON cat FROM ROLE sales_rw;
```
1. Établissez une connexion à la base de données en tant qu’utilisateur `salesanalyst`.
1. Pour tenter d’afficher les 5 premières entrées de la table `cat`, utilisez l’exemple suivant. Notez qu’aucune entrée n’apparaît car la politique par défaut de tout refuser est appliquée.
```
SELECT *
FROM sales.cat
ORDER BY catid ASC
LIMIT 5;
+-------+----------+---------+---------------------------------+
| catid | catgroup | catname | catdesc |
+-------+----------+---------+---------------------------------+
| 1 | Sports | MLB | Major League Baseball |
| 2 | Sports | NHL | National Hockey League |
| 3 | Sports | NFL | National Football League |
| 4 | Sports | NBA | National Basketball Association |
| 5 | Sports | MLS | Major League Soccer |
+-------+----------+---------+---------------------------------+
```
1. Établissez une connexion à la base de données en tant qu’utilisateur `dbadmin`.
1. Pour supprimer la politique RLS, utilisez l’exemple suivant.
```
DROP RLS POLICY policy_mlb_engineer;
```
1. Pour retirer RLS, utilisez l’exemple suivant.
```
ALTER TABLE cat ROW LEVEL SECURITY OFF;
```
## Rubriques en relation
Pour plus d’information sur le RBAC, consultez la documentation suivante.
+ [Hiérarchie des rôles](t_role_hierarchy.md)
+ [Attribution des rôles](t_role_assignment.md)
+ [Autorisations d’objet de base de données](r_roles-database-privileges.md)
+ [Instruction ALTER DEFAULT PRIVILEGES pour le RBAC](r_roles-alter-default-privileges.md)
# 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;
```
# Sécurité des métadonnées
À l’instar de la sécurité au niveau des lignes d’Amazon Redshift, la sécurité des métadonnées vous permet de contrôler plus précisément vos métadonnées. Si la sécurité des métadonnées est activée pour votre cluster provisionné ou votre groupe de travail sans serveur, les utilisateurs peuvent consulter les métadonnées des objets auxquels ils ont accès. La sécurité des métadonnées permet de séparer la visibilité en fonction des besoins. Par exemple, vous pouvez utiliser un seul entrepôt des données pour centraliser l’ensemble de votre stockage de données. Toutefois, si vous stockez des données pour plusieurs secteurs, la gestion de la sécurité peut s’avérer difficile. Lorsque la sécurité des métadonnées est activée, vous pouvez configurer la visibilité. Les utilisateurs d’un secteur peuvent avoir une meilleure visibilité sur leurs objets, tandis que vous limitez l’accès à l’affichage pour les utilisateurs d’un autre secteur. La sécurité des métadonnées prend en charge tous les types d’objets, comme les schémas, les tables, les vues, les vues matérialisées, les procédures stockées, les fonctions définies par l’utilisateur et les modèles de machine learning.
Les utilisateurs peuvent consulter les métadonnées des objets dans les circonstances suivantes :
+ Si l’accès aux objets est accordé à l’utilisateur.
+ Si l’accès aux objets est accordé à un groupe ou à un rôle dont l’utilisateur fait partie.
+ Si l’objet est public.
+ Si l’utilisateur est le propriétaire de l’objet de base de données.
Pour activer la sécurité des métadonnées, utilisez la commande [ALTER SYSTEM](https://docs.aws.amazon.com/redshift/latest/dg/r_ALTER_SYSTEM.html). La syntaxe suivante montre comment utiliser la commande ALTER SYSTEM avec la sécurité des métadonnées.
```
ALTER SYSTEM SET metadata_security=[true|t|on|false|f|off];
```
Lorsque vous activez la sécurité des métadonnées, tous les utilisateurs disposant des autorisations nécessaires peuvent voir les métadonnées pertinentes des objets auxquels ils ont accès. Si vous souhaitez que seuls certains utilisateurs puissent accéder à la sécurité des métadonnées, accordez l’autorisation `ACCESS CATALOG` à un rôle, puis attribuez le rôle à l’utilisateur. Pour plus d’informations sur l’utilisation des rôles pour mieux contrôler la sécurité, consultez [Contrôle d’accès basé sur les rôles](https://docs.aws.amazon.com/redshift/latest/dg/t_Roles.html).
L’exemple suivant montre comment accorder l’autorisation `ACCESS CATALOG` à un rôle, puis comment attribuer le rôle à un utilisateur. Pour plus d’informations sur l’octroi d’autorisations, consultez la commande [GRANT](https://docs.aws.amazon.com/redshift/latest/dg/r_GRANT.html).
```
CREATE ROLE sample_metadata_viewer;
GRANT ACCESS CATALOG TO ROLE sample_metadata_viewer;
GRANT ROLE sample_metadata_viewer to salesadmin;
```
Si vous préférez utiliser des rôles déjà définis, les [rôles définis par le système](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html) `operator`, `secadmin`, `dba` et `superuser` disposent tous des autorisations nécessaires pour afficher les métadonnées des objets. Par défaut, les super-utilisateurs peuvent consulter le catalogue complet.
```
GRANT ROLE operator to sample_user;
```
Si vous utilisez des rôles pour contrôler la sécurité des métadonnées, vous avez accès à toutes les vues et fonctions du système associées au contrôle d’accès basé sur les rôles. Par exemple, vous pouvez interroger la vue [ SVV\$1ROLES](https://docs.aws.amazon.com/redshift/latest/dg/r_SVV_ROLES.html) pour voir tous les rôles. Pour savoir si un utilisateur est membre d’un rôle ou d’un groupe, utilisez la fonction [USER\$1IS\$1MEMBER\$1OF](https://docs.aws.amazon.com/redshift/latest/dg/r_USER_IS_MEMBER_OF.html). Pour une liste complète des vues SVV, consultez [Vues de métadonnées SVV](https://docs.aws.amazon.com/redshift/latest/dg/svv_views.html). Pour obtenir la liste des fonctions relatives aux informations système, consultez [Fonctions d’informations système](https://docs.aws.amazon.com/redshift/latest/dg/r_System_information_functions.html).
# Masquage dynamique des données
**Note**
Amazon Redshift masque automatiquement certaines colonnes de la table système lors de la journalisation des informations relatives aux requêtes effectuées dans les vues du Catalogue de données afin d’empêcher la divulgation de métadonnées sensibles. Pour plus d’informations, consultez [ Journalisation sécurisée](https://docs.aws.amazon.com/redshift/latest/mgmt/db-auditing-secure-logging.html) dans le *Guide de gestion Amazon Redshift*.
Grâce au masquage des données (DDM) dans Amazon Redshift, vous pouvez protéger les données sensibles dans votre entrepôt des données. Vous pouvez modifier la façon dont Amazon Redshift montre les données sensibles à l’utilisateur au moment de la requête, sans les transformer dans la base de données. Vous contrôlez l’accès aux données par le biais de politiques de masquage qui appliquent des règles de masquage personnalisées à un utilisateur ou à un rôle donné. Vous pouvez ainsi répondre à l’évolution des exigences de confidentialité sans modifier les données sous-jacentes ni modifier les requêtes SQL.
Les politiques de masquage dynamique des données cachent, masquent ou pseudonymisent les données qui correspondent à un format donné. Lorsqu’elle est attachée à une table, l’expression de masquage est appliquée à une ou plusieurs de ses colonnes. Vous pouvez modifier davantage les politiques de masquage pour ne les appliquer qu’à certains utilisateurs ou à des rôles définis par l’utilisateur que vous pouvez créer avec [Contrôle d’accès basé sur les rôles (RBAC)](t_Roles.md). En outre, vous pouvez appliquer le DDM au niveau de la cellule en utilisant des colonnes conditionnelles lors de la création de votre politique de masquage. Pour plus d’informations sur le masquage conditionnel, consultez [Masquage conditionnel des données dynamiques](t_ddm-conditional.md).
Vous pouvez appliquer plusieurs politiques de masquage avec différents niveaux de masquage à la même colonne d’une table et les attribuer à différents rôles. Pour éviter les conflits lorsque vous avez des rôles différents et que des politiques différentes s’appliquent à une colonne, vous pouvez définir des priorités pour chaque application. Vous pouvez ainsi contrôler les données auxquelles un utilisateur ou un rôle donné peut accéder. Les politiques DDM peuvent supprimer partiellement ou complètement des données, ou les hacher à l’aide de fonctions définies par l’utilisateur écrites en SQL, Python ou avec AWS Lambda. En masquant les données à l’aide de hachages, vous pouvez appliquer des jointures à ces données sans accéder à des informations potentiellement sensibles.
# Commandes SQL pour la gestion des politiques de masquage dynamique des données
Vous pouvez effectuer les actions suivantes pour créer, attacher, détacher et supprimer des politiques de masquage dynamique des données :
+ Pour créer une politique DDM, utilisez la commande [CREATE MASKING POLICY](r_CREATE_MASKING_POLICY.md).
Voici un exemple de création d’une politique de masquage à l’aide d’une fonction de hachage SHA-2.
```
CREATE MASKING POLICY hash_credit
WITH (credit_card varchar(256))
USING (sha2(credit_card + 'testSalt', 256));
```
+ Pour modifier une politique DDM existante, utilisez la commande [MODIFIER LA POLITIQUE DE MASQUAGE](r_ALTER_MASKING_POLICY.md).
Voici un exemple de modification d’une politique de masquage existante.
```
ALTER MASKING POLICY hash_credit
USING (sha2(credit_card + 'otherTestSalt', 256));
```
+ Pour attacher une politique DDM sur une table à un ou plusieurs utilisateurs ou rôles, utilisez la commande [ATTACH MASKING POLICY](r_ATTACH_MASKING_POLICY.md).
Voici un exemple d'association d'une politique de masquage à une column/role paire.
```
ATTACH MASKING POLICY hash_credit
ON credit_cards (credit_card)
TO ROLE science_role
PRIORITY 30;
```
La clause PRIORITY détermine quelle politique de masquage s’applique à une session utilisateur lorsque plusieurs politiques sont attachées à la même colonne. Par exemple, si l’utilisateur de l’exemple précédent a une autre politique de masquage attachée à la même colonne de carte de crédit avec une priorité de 20, la politique de science\$1role est celle qui s’applique, car elle possède la priorité la plus élevée (30).
+ Pour détacher une politique DDM sur une table d’un ou de plusieurs utilisateurs ou rôles, utilisez la commande [DETACH MASKING POLICY](r_DETACH_MASKING_POLICY.md).
Voici un exemple de détachement d'une politique de masquage d'une column/role paire.
```
DETACH MASKING POLICY hash_credit
ON credit_cards(credit_card)
FROM ROLE science_role;
```
+ Pour supprimer une politique DDM de toutes les bases de données, utilisez la commande [DROP MASKING POLICY](r_DROP_MASKING_POLICY.md).
Voici un exemple de suppression d’une politique de masquage de toutes les bases de données.
```
DROP MASKING POLICY hash_credit;
```
# Hiérarchie des politiques de masquage dynamique des données
Tenez compte des éléments suivants lorsque vous attachez plusieurs politiques de masquage :
+ Vous pouvez attacher plusieurs politiques de masquage à une seule colonne.
+ Lorsque plusieurs politiques de masquage sont applicables à une requête, la politique de priorité la plus élevée attachée à chaque colonne respective s’applique. Prenez l’exemple de code suivant.
```
ATTACH MASKING POLICY partial_hash
ON credit_cards(address, credit_card)
TO ROLE analytics_role
PRIORITY 20;
ATTACH MASKING POLICY full_hash
ON credit_cards(credit_card, ssn)
TO ROLE auditor_role
PRIORITY 30;
SELECT address, credit_card, ssn
FROM credit_cards;
```
Lors de l’exécution de l’instruction SELECT, un utilisateur ayant à la fois les rôles d’analyste et d’auditeur voit la colonne d’adresse dans laquelle la politique de masquage `partial_hash` appliquée. Il voit les colonnes relatives aux cartes de crédit et au SSN auxquelles la politique de masquage `full_hash` est appliquée, car la politique `full_hash` a la priorité la plus élevée sur la colonne des cartes de crédit.
+ Si vous ne spécifiez pas de priorité quand vous attachez une politique de masquage, la priorité par défaut est de 0.
+ Vous ne pouvez pas attacher deux politiques à la même colonne avec la même priorité.
+ Vous ne pouvez pas attacher deux politiques à la même combinaison d’utilisateur et de colonne, ou de rôle et de colonne.
+ Lorsque plusieurs politiques de masquage sont applicables le long du même chemin SUPER alors qu’elles sont attachées au même utilisateur ou rôle, seul l’attachement ayant la plus haute priorité prend effet. Considérez les exemples suivants.
Le premier exemple montre deux politiques de masquage attachées au même chemin, celle ayant la priorité la plus élevée prenant effet.
```
ATTACH MASKING POLICY hide_name
ON employees(col_person.name)
TO PUBLIC
PRIORITY 20;
ATTACH MASKING POLICY hide_last_name
ON employees(col_person.name.last)
TO PUBLIC
PRIORITY 30;
--Only the hide_last_name policy takes effect.
SELECT employees.col_person.name FROM employees;
```
Le deuxième exemple montre deux politiques de masquage attachées à différents chemins dans le même objet SUPER, sans conflit entre les politiques. Les deux attachements s’appliqueront en même temps.
```
ATTACH MASKING POLICY hide_first_name
ON employees(col_person.name.first)
TO PUBLIC
PRIORITY 20;
ATTACH MASKING POLICY hide_last_name
ON employees(col_person.name.last)
TO PUBLIC
PRIORITY 20;
--Both col_person.name.first and col_person.name.last are masked.
SELECT employees.col_person.name FROM employees;
```
Pour confirmer quelle politique de masquage s'applique à un utilisateur donné et à une colonne ou à une combinaison rôle-colonne, les utilisateurs dotés du [https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html)rôle peuvent rechercher la column/role paire colonne/utilisateur dans la [SVV\$1ATTACHED\$1MASKING\$1POLICY](r_SVV_ATTACHED_MASKING_POLICY.md) vue système. Pour de plus amples informations, veuillez consulter [Vues système pour le masquage dynamique des données](r_ddm-svv.md).
# Utilisation du masquage dynamique des données avec des chemins de type de données SUPER
Amazon Redshift permet d’attacher des politiques de masquage dynamique des données aux chemins des colonnes de type SUPER. Pour plus d’informations sur le type de données SUPER, consultez [Données semi-structurées dans Amazon Redshift](super-overview.md).
Lorsque vous associez des politiques de masquage aux chemins de colonnes de type SUPER, tenez compte des points suivants.
+ Lorsque vous associez une politique de masquage à un chemin dans une colonne, cette colonne doit être définie comme type de données SUPER. Vous ne pouvez appliquer des politiques de masquage qu’aux valeurs *scalaires* du chemin SUPER. Vous ne pouvez pas appliquer de politiques de masquage à des structures ou à des tableaux complexes.
+ Vous pouvez appliquer différentes politiques de masquage à plusieurs valeurs scalaires sur une seule colonne SUPER, à condition que les chemins SUPER ne soient pas en conflit. Par exemple, les chemins SUPER `a.b` et `a.b.c` entrent en conflit parce qu’ils se trouvent sur le même chemin, `a.b` étant le parent de `a.b.c`. Les chemins SUPER `a.b.c` et `a.b.d` ne sont pas en conflit.
+ Amazon Redshift ne peut pas vérifier que les chemins auxquels s’attache une politique de masquage existent dans les données et sont du type attendu, tant que la politique n’est pas appliquée à l’exécution de la requête utilisateur. Par exemple, lorsque vous attachez une politique de masquage qui masque les valeurs TEXT à un chemin SUPER contenant une valeur INT, Amazon Redshift essaie de convertir le type de valeur sur le chemin.
Dans de telles situations, le comportement d’Amazon Redshift au moment de l’exécution dépend de vos paramètres de configuration pour interroger les objets SUPER. Par défaut, Amazon Redshift est en mode laxiste et résoudra les chemins manquants et les conversions non valides comme `NULL` pour le chemin SUPER indiqué. Pour plus d’informations sur les paramètres de configuration concernant SUPER, consultez [Configurations SUPER](super-configurations.md).
+ SUPER est un type sans schéma, ce qui signifie qu’Amazon Redshift ne peut pas confirmer l’existence de la valeur sur un chemin SUPER donné. Si vous attachez une politique de masquage à un chemin SUPER qui n’existe pas et qu’Amazon Redshift est en mode laxiste, Amazon Redshift résoudra le chemin à une valeur `NULL`. Nous vous recommandons de tenir compte du format attendu des objets SUPER et de la probabilité qu’ils présentent des attributs inattendus lorsque vous attachez des politiques de masquage aux chemins des colonnes SUPER. Si vous pensez qu’il existe un schéma inattendu dans votre colonne SUPER, pensez à attacher vos politiques de masquage directement à la colonne SUPER. Vous pouvez utiliser les fonctions d’information de type SUPER pour vérifier les attributs et les types, et utiliser `OBJECT_TRANSFORM` pour masquer les valeurs. Pour plus d’informations sur les fonctions d’information de type SUPER, consultez [Fonctions d’informations sur le type SUPER](c_Type_Info_Functions.md).
## Exemples
**Association de politiques de masquage aux chemins SUPER**
L’exemple suivant attache plusieurs politiques de masquage à plusieurs chemins de type SUPER dans une colonne.
```
CREATE TABLE employees (
col_person SUPER
);
INSERT INTO employees
VALUES
(
json_parse('
{
"name": {
"first": "John",
"last": "Doe"
},
"age": 25,
"ssn": "111-22-3333",
"company": "Company Inc."
}
')
),
(
json_parse('
{
"name": {
"first": "Jane",
"last": "Appleseed"
},
"age": 34,
"ssn": "444-55-7777",
"company": "Organization Org."
}
')
)
;
GRANT ALL ON ALL TABLES IN SCHEMA "public" TO PUBLIC;
-- Create the masking policies.
-- This policy converts the given name to all uppercase letters.
CREATE MASKING POLICY mask_first_name
WITH(first_name TEXT)
USING ( UPPER(first_name) );
-- This policy replaces the given name with the fixed string 'XXXX'.
CREATE MASKING POLICY mask_last_name
WITH(last_name TEXT)
USING ( 'XXXX'::TEXT );
-- This policy rounds down the given age to the nearest 10.
CREATE MASKING POLICY mask_age
WITH(age INT)
USING ( (FLOOR(age::FLOAT / 10) * 10)::INT );
-- This policy converts the first five digits of the given SSN to 'XXX-XX'.
CREATE MASKING POLICY mask_ssn
WITH(ssn TEXT)
USING ( 'XXX-XX-'::TEXT || SUBSTRING(ssn::TEXT FROM 8 FOR 4) );
-- Attach the masking policies to the employees table.
ATTACH MASKING POLICY mask_first_name
ON employees(col_person.name.first)
TO PUBLIC;
ATTACH MASKING POLICY mask_last_name
ON employees(col_person.name.last)
TO PUBLIC;
ATTACH MASKING POLICY mask_age
ON employees(col_person.age)
TO PUBLIC;
ATTACH MASKING POLICY mask_ssn
ON employees(col_person.ssn)
TO PUBLIC;
-- Verify that your masking policies are attached.
SELECT
policy_name,
TABLE_NAME,
priority,
input_columns,
output_columns
FROM
svv_attached_masking_policy;
policy_name | table_name | priority | input_columns | output_columns
-----------------+------------+----------+-----------------------------------+-----------------------------------
mask_age | employees | 0 | ["col_person.\"age\""] | ["col_person.\"age\""]
mask_first_name | employees | 0 | ["col_person.\"name\".\"first\""] | ["col_person.\"name\".\"first\""]
mask_last_name | employees | 0 | ["col_person.\"name\".\"last\""] | ["col_person.\"name\".\"last\""]
mask_ssn | employees | 0 | ["col_person.\"ssn\""] | ["col_person.\"ssn\""]
(4 rows)
-- Observe the masking policies taking effect.
SELECT col_person FROM employees ORDER BY col_person.age;
-- This result is formatted for ease of reading.
col_person
--------------------------------
{
"name": {
"first": "JOHN",
"last": "XXXX"
},
"age": 20,
"ssn": "XXX-XX-3333",
"company": "Company Inc."
}
{
"name": {
"first": "JANE",
"last": "XXXX"
},
"age": 30,
"ssn": "XXX-XX-7777",
"company": "Organization Org."
}
```
Voici quelques exemples d’attachements non valides de politique de masquage à des chemins SUPER.
```
-- This attachment fails because there is already a policy
-- with equal priority attached to employees.name.last, which is
-- on the same SUPER path as employees.name.
ATTACH MASKING POLICY mask_ssn
ON employees(col_person.name)
TO PUBLIC;
ERROR: DDM policy "mask_last_name" is already attached on relation "employees" column "col_person."name"."last"" with same priority
-- Create a masking policy that masks DATETIME objects.
CREATE MASKING POLICY mask_date
WITH(INPUT DATETIME)
USING ( INPUT );
-- This attachment fails because SUPER type columns can't contain DATETIME objects.
ATTACH MASKING POLICY mask_date
ON employees(col_person.company)
TO PUBLIC;
ERROR: cannot attach masking policy for output of type "timestamp without time zone" to column "col_person."company"" of type "super
```
Voici un exemple d’attachement d’une politique de masquage à un chemin SUPER qui n’existe pas. Par défaut, Amazon Redshift résoudra le chemin à la valeur `NULL`.
```
ATTACH MASKING POLICY mask_first_name
ON employees(col_person.not_exists)
TO PUBLIC;
SELECT col_person FROM employees LIMIT 1;
-- This result is formatted for ease of reading.
col_person
-----------------------------------
{
"name": {
"first": "JOHN",
"last": "XXXX"
},
"age": 20,
"ssn": "XXX-XX-3333",
"company": "Company Inc.",
"not_exists": null
}
```
# Masquage conditionnel des données dynamiques
Vous pouvez masquer les données au niveau de la cellule en créant des politiques de masquage avec des expressions conditionnelles dans l’expression de masquage. Par exemple, vous pouvez créer une politique de masquage qui applique différents masques à une valeur, en fonction de la valeur d’une autre colonne de cette ligne.
Voici un exemple d’utilisation du masquage conditionnel des données pour créer et attacher une politique de masquage qui supprime partiellement les numéros de carte de crédit impliqués dans des fraudes, tout en masquant complètement tous les autres numéros de carte de crédit. Vous devez être un super-utilisateur ou avoir le rôle [https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html) requis pour exécuter cet exemple.
```
--Create an analyst role.
CREATE ROLE analyst;
--Create a credit card table. The table contains an is_fraud boolean column,
--which is TRUE if the credit card number in that row was involved in a fraudulent transaction.
CREATE TABLE credit_cards (id INT, is_fraud BOOLEAN, credit_card_number VARCHAR(16));
--Create a function that partially redacts credit card numbers.
CREATE FUNCTION REDACT_CREDIT_CARD (credit_card VARCHAR(16))
RETURNS VARCHAR(16) IMMUTABLE
AS $$
import re
regexp = re.compile("^([0-9]{6})[0-9]{5,6}([0-9]{4})")
match = regexp.search(credit_card)
if match != None:
first = match.group(1)
last = match.group(2)
else:
first = "000000"
last = "0000"
return "{}XXXXX{}".format(first, last)
$$ LANGUAGE plpythonu;
--Create a masking policy that partially redacts credit card numbers if the is_fraud value for that row is TRUE,
--and otherwise blanks out the credit card number completely.
CREATE MASKING POLICY card_number_conditional_mask
WITH (fraudulent BOOLEAN, pan varchar(16))
USING (CASE WHEN fraudulent THEN REDACT_CREDIT_CARD(pan)
ELSE Null
END);
--Attach the masking policy to the credit_cards/analyst table/role pair.
ATTACH MASKING POLICY card_number_conditional_mask ON credit_cards (credit_card_number)
USING (is_fraud, credit_card_number)
TO ROLE analyst PRIORITY 100;
```
# Vues système pour le masquage dynamique des données
Les super-utilisateurs, les utilisateurs dotés du rôle `sys:operator` et les utilisateurs dotés de l’autorisation ACCESS SYSTEM TABLE peuvent accéder aux vues système relatives au DDM suivantes.
+ [SVV\$1MASKING\$1POLICY](r_SVV_MASKING_POLICY.md)
Utilisez SVV\$1MASKING\$1POLICY pour afficher toutes les politiques de masquage créées sur le cluster ou le groupe de travail.
+ [SVV\$1ATTACHED\$1MASKING\$1POLICY](r_SVV_ATTACHED_MASKING_POLICY.md)
Utilisez SVV\$1ATTACHED\$1MASKING\$1POLICY pour afficher toutes les relations et tous les utilisateurs ou rôles qui disposent de politiques attachées à la base de données actuellement connectée.
+ [SYS\$1APPLIED\$1MASKING\$1POLICY\$1LOG](SYS_APPLIED_MASKING_POLICY_LOG.md)
Utilisez SYS\$1APPLIED\$1MASKING\$1POLICY\$1LOG pour suivre l’application des politiques de masquage sur les requêtes qui font référence à des relations protégées par le DDM.
Voici quelques exemples d’informations que vous pouvez trouver à l’aide des vues système.
```
--Select all policies associated with specific users, as opposed to roles
SELECT policy_name,
schema_name,
table_name,
grantee
FROM svv_attached_masking_policy
WHERE grantee_type = 'user';
--Select all policies attached to a specific user
SELECT policy_name,
schema_name,
table_name,
grantee
FROM svv_attached_masking_policy
WHERE grantee = 'target_grantee_name'
--Select all policies attached to a given table
SELECT policy_name,
schema_name,
table_name,
grantee
FROM svv_attached_masking_policy
WHERE table_name = 'target_table_name'
AND schema_name = 'target_schema_name';
--Select the highest priority policy attachment for a given role
SELECT samp.policy_name,
samp.priority,
samp.grantee,
smp.policy_expression
FROM svv_masking_policy AS smp
JOIN svv_attached_masking_policy AS samp
ON samp.policy_name = smp.policy_name
WHERE
samp.grantee_type = 'role' AND
samp.policy_name = mask_get_policy_for_role_on_column(
'target_schema_name',
'target_table_name',
'target_column_name',
'target_role_name')
ORDER BY samp.priority desc
LIMIT 1;
--See which policy a specific user will see on a specific column in a given relation
SELECT samp.policy_name,
samp.priority,
samp.grantee,
smp.policy_expression
FROM svv_masking_policy AS smp
JOIN svv_attached_masking_policy AS samp
ON samp.policy_name = smp.policy_name
WHERE
samp.grantee_type = 'role' AND
samp.policy_name = mask_get_policy_for_user_on_column(
'target_schema_name',
'target_table_name',
'target_column_name',
'target_user_name')
ORDER BY samp.priority desc;
--Select all policies attached to a given relation.
SELECT policy_name,
schema_name,
relation_name,
database_name
FROM sys_applied_masking_policy_log
WHERE relation_name = 'relation_name'
AND schema_name = 'schema_name';
```
# Considérations relatives à l’utilisation du masquage dynamique des données
Considérez ce qui suit quand vous utilisez le masquage dynamique des données :
+ Lorsqu’ils interrogent des objets créés à partir de tables, tels que des vues, les utilisateurs voient les résultats en fonction de leurs propres politiques de masquage, et non celles de l’utilisateur qui a créé les objets. Par exemple, un utilisateur ayant le rôle d’analyste interrogeant une vue créée par un secadmin obtiendrait des résultats avec des politiques de masquage associées au rôle d’analyste.
+ Pour éviter que la commande EXPLAIN n’expose potentiellement des filtres de politique de masquage sensibles, seuls les utilisateurs disposant de l’autorisation SYS\$1EXPLAIN\$1DDM peuvent voir les politiques de masquage appliquées dans les sorties EXPLAIN. Les utilisateurs ne disposent pas de l’autorisation SYS\$1EXPLAIN\$1DDM par défaut.
La syntaxe suivante permet de donner une autorisation à un rôle.
```
GRANT EXPLAIN MASKING TO ROLE rolename
```
Pour plus d’informations sur la commande EXPLAIN, consultez [EXPLAIN](r_EXPLAIN.md).
+ Les utilisateurs ayant des rôles différents peuvent voir des résultats différents en fonction des conditions de filtre ou des conditions de jointure utilisées. Par exemple, l’exécution d’une commande SELECT sur une table à l’aide d’une valeur de colonne spécifique échouera si l’utilisateur exécutant la commande applique une politique de masquage qui masque cette colonne.
+ Les politiques DDM doivent être appliquées avant toute opération de prédicat ou toute projection. Les politiques de masquage peuvent inclure les éléments suivants :
+ Opérations constantes à faible coût, telles que la conversion d’une valeur en valeur nulle
+ Opérations à coût modéré telles que le hachage HMAC
+ Opérations coûteuses telles que les appels à des fonctions Lambda externes définies par l’utilisateur
À ce titre, nous vous recommandons d’utiliser des expressions de masquage simples lorsque cela est possible.
+ Vous pouvez utiliser des politiques DDM pour des rôles dotés de politiques de sécurité au niveau des lignes, mais notez que les politiques RLS sont appliquées avant le DDM. Une expression de masquage dynamique des données ne pourra pas lire une ligne protégée par RLS. Pour plus d’informations sur RLS, consultez [Sécurité au niveau des lignes](t_rls.md).
+ Lorsque vous utilisez la commande [COPY](r_COPY.md) pour copier des tables parquet vers des tables cible protégées, vous devez spécifier explicitement les colonnes dans l’instruction COPY. Pour plus d’informations sur le mappage de colonnes avec COPY, consultez [Options de mappage de colonnes](copy-parameters-column-mapping.md).
+ Il n’est pas possible d’attacher les politiques de DDM aux relations suivantes :
+ Tables et catalogues du système
+ Tables externes
+ Tables d’unités de partage des données
+ Relations entre bases de données
+ Tables temporaires
+ Requêtes corrélées
+ Les politiques de DDM peuvent contenir des tables de recherche. Des tables de recherche peuvent être présentes dans la clause USING. Les types de relations suivants ne peuvent pas être utilisés comme tables de recherche :
+ Tables et catalogues du système
+ Tables externes
+ Tables d’unités de partage des données
+ Vues, vues matérialisées et vues à liaison tardive
+ Relations entre bases de données
+ Tables temporaires
+ Requêtes corrélées
Vous trouverez ci-dessous un exemple d’association d’une politique de masquage à une table de recherche.
```
--Create a masking policy referencing a lookup table
CREATE MASKING POLICY lookup_mask_credit_card WITH (credit_card TEXT) USING (
CASE
WHEN
credit_card IN (SELECT credit_card_lookup FROM credit_cards_lookup)
THEN '000000XXXX0000'
ELSE REDACT_CREDIT_CARD(credit_card)
END
);
--Provides access to the lookup table via a policy attached to a role
GRANT SELECT ON TABLE credit_cards_lookup TO MASKING POLICY lookup_mask_credit_card;
```
+ Vous ne pouvez pas attacher de politique de masquage qui produirait une sortie incompatible avec le type et la taille de la colonne cible. Par exemple, vous ne pouvez pas attacher une politique de masquage qui génère une chaîne de 12 caractères dans une colonne VARCHAR(10). Amazon Redshift prend en charge les exceptions suivantes :
+ Une politique de masquage avec le type d'entrée INTN peut être attachée à une politique de taille INTM tant que M < N. Par exemple, une politique d'entrée BIGINT (INT8) peut être attachée à une colonne smallint (). INT4
+ Une politique de masquage avec le type d’entrée NUMERIC ou DECIMAL peut toujours être attachée à une colonne FLOAT.
+ Vous ne pouvez pas utiliser les politiques DDM avec le partage de données. Si le producteur de données de l’unité de partage des données associe une politique DDM à une table de l’unité de partage des données, la table devient inaccessible aux utilisateurs du consommateur de données qui tentent d’interroger la table. La tentative d’ajout de la relation à une unité de partage des données échoue sur le cluster ou l’espace de noms côté producteur avec l’erreur suivante :
```
or a relation dependent on it is protected by a masking policy and cannot be added to a datashare
```
Si vous associez une politique de masquage à une relation côté producteur et que la relation est déjà incluse dans une unité de partage des données, la tentative d’interrogation de la relation côté consommateur échoue avec l’erreur suivante :
```
cross-cluster query of the masked relation is not supported.
```
Vous pouvez désactiver le DDM pour les unités de partage des données à l’aide de la commande ALTER TABLE avec le paramètre MASKING OFF FOR DATASHARES. Pour plus d’informations, consultez [ALTER TABLE](r_ALTER_TABLE.md).
+ Vous ne pouvez pas interroger les relations auxquelles des politiques DDM sont attachées si la valeur de l’une de vos options de configuration suivantes ne correspond 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 à laquelle une politique DDM est attachée et que vous voyez le message « La relation protégée DDM 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 masquage dynamique des données, 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 DDM, 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) associées à des politiques de DDM 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 DDM, détachez d'abord toutes les politiques DDM qui leur sont associées, remplacez les vues ou LBVs attachez à nouveau les politiques. Les superutilisateurs et les utilisateurs `sys:secadmin` autorisés peuvent utiliser CREATE VIEW sur des vues ou LBVs avec des politiques DDM sans détacher les politiques.
+ Les vues attachées à des politiques de DDM ne peuvent pas référencer les tables et les vues système. Les vues à liaison tardive peuvent faire référence à des tables et à des vues système.
+ Les vues à liaison tardive attachées à des politiques de DDM ne peuvent pas faire référence à des données imbriquées dans des lacs de données, comme des documents JSON.
+ Une vue à liaison tardive ne peut pas être attachée à des politiques de DDM si elle est référencée par n’importe quelle vue.
+ Les politiques de DDM attachées aux vues à liaison tardive sont jointes par nom de colonne. Au moment de la requête, Amazon Redshift valide que toutes les politiques de masquage attachées à la vue à liaison tardive ont été appliquées correctement, et que le type de colonne de sortie de la vue à liaison tardive correspond aux types des politiques de masquage attachées. Si la validation échoue, Amazon Redshift renvoie une erreur pour la requête.
+ Vous pouvez utiliser des variables de contexte de session personnalisées lors de la création de politiques DDM. L’exemple suivant définit des variables de contexte de session pour une politique DDM.
```
-- Set a customized context variable.
SELECT set_config('app.city', 'XXXX', FALSE);
-- Create a MASKING policy using current_setting() to get the value of a customized context variable.
CREATE MASKING POLICY city_mask
WITH (city VARCHAR(30))
USING (current_setting('app.city')::VARCHAR(30));
-- Attach the policy on the target table to one or more roles.
ATTACH MASKING POLICY city_mask
ON tickit_users_redshift(city)
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 DDM, 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 DDM.
# Exemple de masquage end-to-end dynamique de données
L' end-to-endexemple suivant montre comment créer et associer des politiques de masquage à une colonne. Ces règles permettent aux utilisateurs d’accéder à une colonne et de voir différentes valeurs, en fonction du degré de masquage des politiques associées à leurs rôles. Vous devez être un super-utilisateur ou avoir le rôle [https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html](https://docs.aws.amazon.com/redshift/latest/dg/r_roles-default.html) requis pour exécuter cet exemple.
## Création d’une politique de masquage
D’abord, créez une table et remplissez-la avec les valeurs des cartes de crédit.
```
--create the table
CREATE TABLE credit_cards (
customer_id INT,
credit_card TEXT
);
--populate the table with sample values
INSERT INTO credit_cards
VALUES
(100, '4532993817514842'),
(100, '4716002041425888'),
(102, '5243112427642649'),
(102, '6011720771834675'),
(102, '6011378662059710'),
(103, '373611968625635')
;
--run GRANT to grant permission to use the SELECT statement on the table
GRANT SELECT ON credit_cards TO PUBLIC;
--create two users
CREATE USER regular_user WITH PASSWORD '1234Test!';
CREATE USER analytics_user WITH PASSWORD '1234Test!';
--create the analytics_role role and grant it to analytics_user
--regular_user does not have a role
CREATE ROLE analytics_role;
GRANT ROLE analytics_role TO analytics_user;
```
Créez ensuite une politique de masquage à appliquer au rôle d’analyse.
```
--create a masking policy that fully masks the credit card number
CREATE MASKING POLICY mask_credit_card_full
WITH (credit_card VARCHAR(256))
USING ('000000XXXX0000'::TEXT);
--create a user-defined function that partially obfuscates credit card data
CREATE FUNCTION REDACT_CREDIT_CARD (credit_card TEXT)
RETURNS TEXT IMMUTABLE
AS $$
import re
regexp = re.compile("^([0-9]{6})[0-9]{5,6}([0-9]{4})")
match = regexp.search(credit_card)
if match != None:
first = match.group(1)
last = match.group(2)
else:
first = "000000"
last = "0000"
return "{}XXXXX{}".format(first, last)
$$ LANGUAGE plpythonu;
--create a masking policy that applies the REDACT_CREDIT_CARD function
CREATE MASKING POLICY mask_credit_card_partial
WITH (credit_card VARCHAR(256))
USING (REDACT_CREDIT_CARD(credit_card));
--confirm the masking policies using the associated system views
SELECT * FROM svv_masking_policy;
SELECT * FROM svv_attached_masking_policy;
```
## Attachement d’une politique de masquage
Attachez les politiques de masquage à la table des cartes de crédit.
```
--attach mask_credit_card_full to the credit card table as the default policy
--all users will see this masking policy unless a higher priority masking policy is attached to them or their role
ATTACH MASKING POLICY mask_credit_card_full
ON credit_cards(credit_card)
TO PUBLIC;
--attach mask_credit_card_partial to the analytics role
--users with the analytics role can see partial credit card information
ATTACH MASKING POLICY mask_credit_card_partial
ON credit_cards(credit_card)
TO ROLE analytics_role
PRIORITY 10;
--confirm the masking policies are applied to the table and role in the associated system view
SELECT * FROM svv_attached_masking_policy;
--confirm the full masking policy is in place for normal users by selecting from the credit card table as regular_user
SET SESSION AUTHORIZATION regular_user;
SELECT * FROM credit_cards;
--confirm the partial masking policy is in place for users with the analytics role by selecting from the credit card table as analytics_user
SET SESSION AUTHORIZATION analytics_user;
SELECT * FROM credit_cards;
```
## Modification d’une politique de masquage
La section suivante montre comment modifier une politique de masquage dynamique des données.
```
--reset session authorization to the default
RESET SESSION AUTHORIZATION;
--alter the mask_credit_card_full policy
ALTER MASKING POLICY mask_credit_card_full
USING ('00000000000000'::TEXT);
--confirm the full masking policy is in place after altering the policy, and that results are altered from '000000XXXX0000' to '00000000000000'
SELECT * FROM credit_cards;
```
## Détachement et suppression d’une politique de masquage
La section suivante explique comment détacher et supprimer les politiques de masquage en supprimant toutes les politiques de masquage dynamique des données de la table.
```
--reset session authorization to the default
RESET SESSION AUTHORIZATION;
--detach both masking policies from the credit_cards table
DETACH MASKING POLICY mask_credit_card_full
ON credit_cards(credit_card)
FROM PUBLIC;
DETACH MASKING POLICY mask_credit_card_partial
ON credit_cards(credit_card)
FROM ROLE analytics_role;
--drop both masking policies
DROP MASKING POLICY mask_credit_card_full;
DROP MASKING POLICY mask_credit_card_partial;
```
# Autorisations délimitées
Les autorisations étendues vous permettent d’accorder des autorisations à un utilisateur ou à un rôle sur tous les objets d’un type au sein d’une base de données ou d’un schéma. Les utilisateurs et les rôles dotés d’autorisations étendues ont les autorisations spécifiées sur tous les objets actuels et futurs de la base de données ou du schéma.
Vous pouvez consulter l’étendue des autorisations délimitées au niveau de la base de données dans [SVV\$1DATABASE\$1PRIVILEGES](r_SVV_DATABASE_PRIVILEGES.md). Vous pouvez consulter l’étendue des autorisations délimitées au niveau du schéma dans [SVV\$1SCHEMA\$1PRIVILEGES](r_SVV_SCHEMA_PRIVILEGES.md).
Pour plus d’informations sur l’application d’autorisations étendues, consultez [GRANT](r_GRANT.md) et [REVOKE](r_REVOKE.md).
# Considérations relatives à l’utilisation d’autorisations étendues
Tenez compte des éléments suivants lorsque vous utilisez des autorisations étendues :
+ Vous pouvez utiliser des autorisations étendues pour accorder ou révoquer des autorisations sur une étendue d’une base de données ou d’un schéma à un utilisateur ou à un rôle choisi, ou à partir de ceux-ci.
+ Vous ne pouvez pas accorder d’autorisations étendues à des groupes d’utilisateurs.
+ L’octroi ou la révocation d’autorisations étendues modifie les autorisations pour tous les objets actuels et futurs du champ d’application.
+ Les autorisations étendues et les autorisations de niveau objet s’appliquent indépendamment les unes des autres. Par exemple, un utilisateur conservera les autorisations sur une table dans les deux cas suivants.
+ L’utilisateur dispose de l’autorisation SELECT sur la table schema1.table1 et de l’autorisation SELECT étendue sur schema1. L’utilisateur a alors l’autorisation SELECT révoquée pour toutes les tables du schéma schema1. L’utilisateur conserve l’autorisation SELECT sur schema1.table1.
+ L’utilisateur dispose de l’autorisation SELECT sur la table schema1.table1 et de l’autorisation SELECT étendue sur schema1. L’utilisateur a alors l’autorisation SELECT révoquée pour schema1.table1. L’utilisateur conserve l’autorisation SELECT sur schema1.table1.
+ Pour accorder ou révoquer des autorisations étendues, vous devez répondre à l’un des critères suivants :
+ Super-utilisateurs
+ Utilisateurs disposant de l’option d’octroi de cette autorisation Pour plus d’informations sur les options d’octroi, consultez le paramètre WITH GRANT OPTION dans [GRANT](r_GRANT.md).
+ Les autorisations étendues ne peuvent être accordées ou révoquées que pour des objets de la base de données connectée, ou à partir de bases de données importées depuis une unité de partage des données.
+ Vous pouvez utiliser des autorisations étendues pour définir les autorisations par défaut sur une base de données créée à partir d’une unité de partage des données. Un utilisateur d’unité de partage des données côté consommateur disposant d’autorisations étendues sur une base de données partagée obtiendra automatiquement ces autorisations pour tout nouvel objet ajouté à l’unité de partage des données côté producteur.
+ Les producteurs peuvent accorder des autorisations étendues sur les objets d’un schéma à une unité de partage des données. (aperçu)