Droits 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 des accès ultraprécis. Ces informations s'appliquent aux bases de données utilisant les dialectes GoogleSQL et PostgreSQL.

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

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

SELECT INSERT UPDATE SUPPRIMER EXECUTE UTILISATION
Schéma
Table
Colonne
Afficher
Flux de modifications
Fonction de lecture du flux de modifications
Séquence
Modèle

Les sections suivantes fournissent des informations détaillées sur chaque droit.

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 droit n'est valide que pour ces colonnes. Si aucune liste de colonnes n'est spécifiée, le droit est valide pour toutes les colonnes de la table, y compris celles ajoutées par la suite. Une liste de colonnes n'est pas autorisée pour une vue.

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

    Si vous créez une vue avec les droits de l'appelant, pour interroger la vue, le rôle ou l'utilisateur de la base de données a besoin du droit SELECT sur la vue, ainsi que du droit SELECT sur les objets sous-jacents référencés dans la vue. Supposons, par exemple, 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 exécute 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 définisseur, pour interroger la vue, le rôle ou l'utilisateur de la base de données n'a besoin que du droit SELECT sur la vue. Supposons, par exemple, 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 exécute la requête SELECT * FROM AlbumsBudget. Le rôle n'a besoin que du droit 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é le droit SELECT sur un sous-ensemble de colonnes pour 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.

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

  • Pour les tables entrelacées, le droit SELECT accordé sur la table parente ne se propage pas à la table enfant.

  • Lorsque vous accordez le droit SELECT sur un flux de modifications, vous devez également accorder le droit EXECUTE sur la fonction table du 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 du droit SELECT sur ces colonnes. Si la fonction d'agrégation ne spécifie aucune colonne, par exemple COUNT(*), le rôle doit disposer du droit 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'affichage.

Exemples d'utilisation de GRANT SELECT

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 droit est valide pour toutes les colonnes de la table.

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

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

Exemples d'utilisation de GRANT INSERT

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