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.
# Notes d’utilisation
Pour retirer les privilèges à un objet, vous devez répondre à l’un des critères suivants :
+ Être le propriétaire de l’objet.
+ Être un super-utilisateur.
+ Avoir un privilège accordé pour cet objet et ce privilège.
Par exemple, la commande suivante autorise l’utilisateur HR à exécuter des commandes SELECT sur la table des employés et à accorder et révoquer le même privilège aux autres utilisateurs.
```
grant select on table employees to HR with grant option;
```
HR ne peut pas révoquer de privilèges pour une opération autre que SELECT, ou sur toute autre table que celle des employés.
Les super-utilisateurs peuvent accéder à tous les objets, quelle que soit les commandes GRANT et REVOKE qui définissent les privilèges d’objet.
PUBLIC représente un groupe qui inclut toujours tous les utilisateurs. Par défaut, tous les membres de PUBLIC disposent des privilèges CREATE et USAGE sur le schéma PUBLIC. Pour limiter toutes les autorisations d’un utilisateur sur le schéma PUBLIC, vous devez d’abord révoquer toutes les autorisations de PUBLIC sur le schéma PUBLIC, puis accorder des privilèges à des utilisateurs ou des groupes spécifiques. L’exemple suivant contrôle les privilèges de création de table du schéma PUBLIC.
```
revoke create on schema public from public;
```
Pour supprimer des privilèges d’une table Lake Formation, le rôle IAM associé au schéma externe de la table doit avoir l’autorisation d’accorder des privilèges à la table externe. L’exemple suivant crée un schéma externe avec un rôle IAM `myGrantor` associé. Le rôle IAM `myGrantor` a l’autorisation de supprimer des autorisations. La commande REVOKE utilise l’autorisation du rôle IAM `myGrantor` associé au schéma externe pour supprimer des autorisations du rôle IAM `myGrantee`.
```
create external schema mySchema
from data catalog
database 'spectrum_db'
iam_role 'arn:aws:iam::123456789012:role/myGrantor'
create external database if not exists;
```
```
revoke select
on external table mySchema.mytable
from iam_role 'arn:aws:iam::123456789012:role/myGrantee';
```
**Note**
Si le rôle IAM dispose également d'une `ALL` AWS Glue Data Catalog autorisation activée pour Lake Formation, l'`ALL`autorisation n'est pas révoquée. Seule l’autorisation `SELECT` est supprimée. Vous pouvez afficher les autorisations Lake Formation dans la console Lake Formation.
## Notes d’utilisation pour la révocation de l’autorisation ASSUMEROLE
Les notes d’utilisation suivantes s’appliquent à la révocation du privilège ASSUMEROLE dans Amazon Redshift.
Seul un super-utilisateur de base de données peut révoquer le privilège ASSUMEROLE pour les utilisateurs et les groupes. Un super-utilisateur conserve toujours le privilège ASSUMEROLE.
Pour activer l’utilisation du privilège ASSUMEROLE pour les utilisateurs et les groupes, un super-utilisateur exécute l’instruction suivante une fois sur le cluster. Avant d’accorder le privilège ASSUMEROLE aux utilisateurs et aux groupes, un super-utilisateur doit exécuter l’instruction suivante une fois sur le cluster.
```
revoke assumerole on all from public for all;
```
## Notes d’utilisation pour la révocation des autorisations de machine learning
Vous ne pouvez pas accorder ou révoquer directement les autorisations liées à une fonction ML. Une fonction ML appartient à un modèle ML et les autorisations sont contrôlées par le biais du modèle. En revanche, vous pouvez révoquer les autorisations liées au modèle ML. L’exemple suivant montre comment révoquer l’autorisation d’exécution de tous les utilisateurs associés au modèle `customer_churn`.
```
REVOKE EXECUTE ON MODEL customer_churn FROM PUBLIC;
```
Vous pouvez également révoquer toutes les autorisations d’un utilisateur pour le modèle ML `customer_churn`.
```
REVOKE ALL on MODEL customer_churn FROM ml_user;
```
L’octroi ou la révocation de l’autorisation `EXECUTE` liée à une fonction de ML échouera s’il existe une fonction de ML dans le schéma, même si cette fonction de ML dispose déjà de l’autorisation `EXECUTE` par le biais de `GRANT EXECUTE ON MODEL`. Nous vous recommandons d’utiliser un schéma distinct lorsque vous utilisez la commande `CREATE MODEL` afin de conserver les fonctions ML dans un schéma distinct. L’exemple suivant vous montre comment procéder.
```
CREATE MODEL ml_schema.customer_churn
FROM customer_data
TARGET churn
FUNCTION ml_schema.customer_churn_prediction
IAM_ROLE default
SETTINGS (
S3_BUCKET 'amzn-s3-demo-bucket'
);
```