Privilèges de contrôle précis des accès

Cette page décrit les droits que vous pouvez accorder à un rôle de base de données pour un contrôle précis des accès.

Pour en savoir plus sur les rôles de base de données et le contrôle précis des accès, consultez la page À propos du contrôle précis des accès.

Le tableau suivant présente les droits de contrôle des accès précis et les objets de base de données auxquels ils peuvent être accordés.

SELECT INSERT UPDATE SUPPRIMER EXECUTE UTILISATION
Schéma ✓
Tableau ✓ ✓ ✓ ✓
Colonne ✓ ✓ ✓ ✓
Afficher ✓
Flux de modifications ✓
Modifier la fonction de lecture du flux ✓
Séquence ✓ ✓
Modèle ✓

Les sections suivantes fournissent des détails sur chaque privilège.

SELECT

Permet au rôle de lire ou d'interroger une table, une vue, un flux de modifications, une séquence ou un modèle.

  • Si une liste de colonnes est spécifiée pour une table, le privilège n'est valide que pour ces colonnes. Si aucune liste de colonnes n'est spécifiée, le privilège est valide pour toutes les colonnes de la table, y compris les colonnes ajoutées par la suite. Une liste de colonnes n'est pas autorisée pour une vue.

  • Spanner est compatible avec les vues des droits de l'appelant et les vues des droits du définisseur. Pour en savoir plus, consultez la page À propos des vues.

    Si vous créez une vue avec les droits de l'appelant, pour interroger la vue, le rôle de base de données ou l'utilisateur doit disposer du droit SELECT sur la vue, ainsi que du droit SELECT sur les objets sous-jacents référencés dans la vue. Par exemple, supposons que la vue SingerNames soit créée sur la table Singers.

    CREATE VIEW SingerNames SQL SECURITY INVOKER AS
  SELECT Singers.SingerId, Singers.FirstName, Singers.LastName FROM Singers;

    Supposons que le rôle de base de données myRole effectue la requête SELECT * FROM SingerNames. Le rôle doit disposer du droit SELECT sur la vue et du droit SELECT sur les trois colonnes référencées ou sur l'ensemble de la table Singers.

    Si vous créez une vue avec les droits du créateur, le rôle de base de données ou l'utilisateur n'a besoin que du droit SELECT sur la vue pour interroger la vue. Par exemple, supposons que la vue AlbumsBudget soit créée sur la table Albums.

    CREATE VIEW AlbumsBudget SQL SECURITY DEFINER AS
  SELECT Albums.Id, Albums.AlbumTitle, MarketingBudget FROM Albums;

    Supposons que le rôle de base de données Analyst effectue la requête SELECT * FROM AlbumsBudget. Le rôle n'a besoin que du privilège SELECT sur la vue. Il n'a pas besoin du droit SELECT sur les trois colonnes référencées ni sur la table Albums.

  • Après avoir accordé SELECT à un sous-ensemble de colonnes d'une table, l'utilisateur FGAC ne peut plus utiliser SELECT * sur cette table. Les requêtes sur cette table doivent nommer toutes les colonnes à inclure.

  • SELECT accordé sur une colonne générée n'accorde pas SELECT sur les colonnes de base sous-jacentes.

  • Pour les tables entrelacées, les SELECT accordées sur la table parente ne se propagent pas vers la table enfant.

  • Lorsque vous accordez SELECT sur un flux de modifications, vous devez également accorder EXECUTE sur la fonction de valeur de table pour le flux de modifications. Pour en savoir plus, consultez la section EXECUTE.

  • Lorsque SELECT est utilisé avec une fonction d'agrégation sur des colonnes spécifiques, par exemple SUM(col_a), le rôle doit disposer de l'autorisation SELECT sur ces colonnes. Si la fonction agrégative ne spécifie aucune colonne, par exemple COUNT(*), le rôle doit disposer du privilège SELECT sur au moins une colonne de la table.

  • Lorsque vous utilisez SELECT avec une séquence, vous ne pouvez afficher que les séquences pour lesquelles vous disposez des droits d'accès.

Examples

GoogleSQL 

GRANT SELECT ON TABLE employees TO ROLE hr_director;

GRANT SELECT ON TABLE customers, orders, items TO ROLE account_mgr;

GRANT SELECT(name, level, cost_center, location, manager) ON TABLE employees TO ROLE hr_manager;

GRANT SELECT(name, address, phone) ON TABLE employees, contractors TO ROLE hr_rep;

GRANT SELECT ON VIEW orders_view TO ROLE hr_manager;

GRANT SELECT ON CHANGE STREAM ordersChangeStream TO ROLE hr_analyst;

GRANT SELECT ON SEQUENCE sequence_name TO ROLE role_name;

PostgreSQL 

GRANT SELECT ON TABLE employees TO hr_director;

GRANT SELECT ON TABLE customers, orders, items TO account_mgr;

GRANT SELECT(name, level, cost_center, location, manager) ON TABLE employees TO hr_manager;

GRANT SELECT(name, address, phone) ON TABLE employees, contractors TO hr_rep;

GRANT SELECT ON TABLE orders_view TO hr_manager; // orders_view is an invoker rights view

GRANT SELECT ON CHANGE STREAM orders_change_stream TO hr_analyst;

GRANT SELECT ON SEQUENCE sequence_name TO hr_package;

INSERT

Permet au rôle d'insérer des lignes dans les tables spécifiées. Si une liste de colonnes est spécifiée, l'autorisation n'est valide que pour ces colonnes. Si aucune liste de colonnes n'est spécifiée, le privilège est valide pour toutes les colonnes du tableau.

  • Si des noms de colonnes sont spécifiés, toute colonne non incluse reçoit sa valeur par défaut lors de l'insertion.

  • INSERT ne peut pas être accordé sur les colonnes générées.

Examples

GoogleSQL 

GRANT INSERT ON TABLE employees, contractors TO ROLE hr_manager;

GRANT INSERT(name, address, phone) ON TABLE employees TO ROLE hr_rep;

PostgreSQL 

GRANT INSERT ON TABLE employees, contractors TO hr_manager;

GRANT INSERT(name, address, phone) ON TABLE employees TO hr_rep;

UPDATE

Permet au rôle de mettre à jour les lignes des tables spécifiées. Les mises à jour peuvent être limitées à un sous-ensemble de colonnes de table. Lorsque vous l'utilisez avec des séquences, le rôle peut appeler la fonction get-next-sequence-value sur la séquence.

En plus du droit UPDATE, le rôle doit disposer du droit SELECT sur toutes les colonnes interrogées. Les colonnes interrogées incluent les colonnes de la clause WHERE.

UPDATE ne peut pas être accordé sur les colonnes générées.

Examples

GoogleSQL 

GRANT UPDATE ON TABLE employees, contractors TO ROLE hr_manager;

GRANT UPDATE(name, address, phone) ON TABLE employees TO ROLE hr_rep;

PostgreSQL 

GRANT UPDATE ON TABLE employees, contractors TO hr_manager;

GRANT UPDATE(name, address, phone) ON TABLE employees TO hr_rep;

DELETE

Permet au rôle de supprimer des lignes des tables spécifiées.

  • DELETE ne peut pas être accordé au niveau de la colonne.

  • Le rôle nécessite également SELECT pour toutes les colonnes pouvant être incluses dans les clauses WHERE de la requête.

  • Pour les tables entrelacées dans les bases de données en dialecte GoogleSQL, le privilège DELETE n'est requis que sur la table parente. Si une table enfant spécifie ON DELETE CASCADE, les lignes de la table enfant sont supprimées, même sans l'autorisation DELETE sur la table enfant.

Exemple

GoogleSQL 

GRANT DELETE ON TABLE employees, contractors TO ROLE hr_admin;

PostgreSQL 

GRANT DELETE ON TABLE employees, contractors TO hr_admin;

EXECUTE

Lorsque vous accordez SELECT sur un flux de modifications, vous devez également accorder EXECUTE sur la fonction de lecture du flux de modifications. Pour en savoir plus, consultez la section Fonctions de lecture du flux de modifications et syntaxe des requêtes.

Lorsque vous l'utilisez avec des modèles, le rôle peut utiliser le modèle dans des fonctions de machine learning.

Exemple

L'exemple suivant montre comment accorder EXECUTE à la fonction de lecture pour le flux de modifications nommé my_change_stream.

GoogleSQL 

GRANT EXECUTE ON TABLE FUNCTION READ_my_change_stream TO ROLE hr_analyst;

PostgreSQL 

GRANT EXECUTE ON FUNCTION spanner.read_json_my_change_stream TO hr_analyst;

UTILISATION

Lorsque vous accordez USAGE à un schéma nommé, il fournit des droits d'accès aux objets contenus dans le schéma nommé. Le droit USAGE est accordé par défaut au schéma par défaut.

Étape suivante

Pour en savoir plus, consultez les pages suivantes :