Privilégios de controle de acesso granular

Esta página descreve os privilégios que podem ser concedidos a um papel de banco de dados para controle de acesso detalhado. Essas informações se aplicam a bancos de dados com dialeto GoogleSQL e PostgreSQL.

Para saber mais sobre papéis de banco de dados e controle de acesso detalhado, consulte Visão geral do controle de acesso detalhado.

A tabela a seguir mostra os privilégios de controle de acesso refinado e os objetos de banco de dados em que eles podem ser concedidos.

As seções a seguir fornecem detalhes sobre cada privilégio.

SELECT

Permite que a função leia ou consulte uma tabela, visualização, fluxo de alterações, sequência ou modelo.

• Se uma lista de colunas for especificada para uma tabela, o privilégio será válido apenas para essas colunas. Se nenhuma lista de colunas for especificada, o privilégio será válido em todas as colunas da tabela, incluindo as colunas adicionadas posteriormente. Uma lista de colunas não é permitida para uma visualização.

• O Spanner oferece suporte às visualizações de direitos do autor e do definidor. Para mais informações, consulte Visão geral das visualizações.

  Se você criar uma visualização com direitos de invocação, para consultar a visualização, o usuário ou a função do banco de dados precisa do privilégio SELECT na visualização e também do privilégio SELECT nos objetos de origem referenciados na visualização. Por exemplo, suponha que a visualização SingerNames seja criada na tabela Singers.

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

  Suponha que o papel do banco de dados myRole execute a consulta SELECT * FROM SingerNames. A função precisa ter o privilégio SELECT na visualização e o privilégio SELECT nas três colunas referenciadas ou em toda a tabela Singers.

  Se você criar uma visualização com direitos de definição, para consultar a visualização, o usuário ou a função do banco de dados só precisará do privilégio SELECT na visualização. Por exemplo, suponha que a visualização AlbumsBudget seja criada na tabela Albums.

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

  Suponha que o papel do banco de dados Analyst execute a consulta SELECT * FROM AlbumsBudget. O papel só precisa do privilégio SELECT na visualização. Não é necessário ter o privilégio SELECT nas três colunas referenciadas ou na tabela Albums.

• Depois de conceder SELECT a um subconjunto de colunas de uma tabela, o usuário do FGAC não poderá mais usar SELECT * nessa tabela. As consultas nessa tabela precisam nomear todas as colunas que serão incluídas.

• O SELECT concedido em uma coluna gerada não concede SELECT nas colunas de base.

• Para tabelas intercaladas, o SELECT concedido na tabela mãe não é propagado para a tabela filha.

• Ao conceder SELECT em um fluxo de alterações, você também precisa conceder EXECUTE na função com valor de tabela para o fluxo de alterações. Para mais informações, consulte EXECUTE.

• Quando SELECT é usado com uma função de agregação em colunas específicas, por exemplo, SUM(col_a), o papel precisa ter o privilégio SELECT nessas colunas. Se a função de agregação não especificar nenhuma coluna, por exemplo, COUNT(*), o papel precisa ter o privilégio SELECT em pelo menos uma coluna na tabela.

• Quando você usa SELECT com uma sequência, só é possível acessar as sequências que você tem privilégios para acessar.

Exemplos de uso de GRANT SELECT

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;

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

Permite que a função insira linhas nas tabelas especificadas. Se uma lista de colunas for especificada, a permissão será válida apenas para essas colunas. Se nenhuma lista de colunas for especificada, o privilégio será válido em todas as colunas da tabela.

• Se os nomes das colunas forem especificados, qualquer coluna não incluída vai receber o valor padrão na inserção.

• Não é possível conceder INSERT em colunas geradas.

Exemplos de uso de GRANT INSERT

GRANT INSERT ON TABLE employees, contractors TO ROLE hr_manager;

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

GRANT INSERT ON TABLE employees, contractors TO hr_manager;

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

UPDATE

Permite que a função atualize linhas nas tabelas especificadas. As atualizações podem ser restringidas a um subconjunto de colunas de tabela. Quando você usa isso com sequências, o papel pode chamar a função get-next-sequence-value na sequência.

Além do privilégio UPDATE, a função precisa do privilégio SELECT em todas as colunas consultadas. As colunas consultadas incluem as colunas na cláusula WHERE.

Não é possível conceder UPDATE em colunas geradas.

Exemplos de uso de GRANT UPDATE

GRANT UPDATE ON TABLE employees, contractors TO ROLE hr_manager;

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

GRANT UPDATE ON TABLE employees, contractors TO hr_manager;

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

DELETE

Permite que a função exclua linhas das tabelas especificadas.

• DELETE não pode ser concedido no nível da coluna.

• O papel também precisa de SELECT em todas as colunas que podem ser incluídas nas cláusulas WHERE da consulta.

• Para tabelas intercaladas em bancos de dados com dialeto GoogleSQL, o privilégio DELETE é necessário apenas na tabela pai. Se uma tabela filha especificar ON DELETE CASCADE, as linhas da tabela filha serão excluídas mesmo sem o privilégio DELETE na tabela filha.

Exemplo de uso de GRANT DELETE

GRANT DELETE ON TABLE employees, contractors TO ROLE hr_admin;

GRANT DELETE ON TABLE employees, contractors TO hr_admin;

EXECUTE

Ao conceder SELECT em um fluxo de alterações, você também precisa conceder EXECUTE na função de leitura do fluxo de alterações. Para mais informações, consulte Funções de leitura de fluxo de mudança e sintaxe de consulta.

Quando você usa isso com modelos, permite que o papel use o modelo em funções de aprendizado de máquina.

Exemplo de uso de GRANT EXECUTE

O exemplo a seguir mostra como conceder EXECUTE na função de leitura para o fluxo de mudanças chamado my_change_stream.

GRANT EXECUTE ON TABLE FUNCTION READ_my_change_stream TO ROLE hr_analyst;

GRANT EXECUTE ON FUNCTION spanner.read_json_my_change_stream TO hr_analyst;

USO

Quando você concede USAGE a um esquema nomeado, ele fornece privilégios para acessar objetos contidos no esquema nomeado. O privilégio USAGE é concedido, por padrão, ao esquema padrão.

A seguir

• Configurar o controle de acesso granular
• Visão geral do controle de acesso granular
• Instruções GRANT e REVOKE (bancos de dados do dialeto GoogleSQL)
• Instruções GRANT e REVOKE (bancos de dados do dialeto do PostgreSQL)