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.
# 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)