Privilegios de control de acceso pormenorizado

En esta página se describen los privilegios que puedes conceder a un rol de base de datos para tener un control de acceso pormenorizado. Esta información se aplica tanto a las bases de datos con dialecto GoogleSQL como a las bases de datos con dialecto PostgreSQL.

Para obtener información sobre los roles de base de datos y el control de acceso pormenorizado, consulta el artículo Introducción al control de acceso pormenorizado.

En la siguiente tabla se muestran los privilegios de control de acceso pormenorizado y los objetos de la base de datos a los que se pueden conceder.

En las siguientes secciones se proporciona información sobre cada privilegio.

SELECT

Permite que el rol lea o consulte una tabla, una vista, un flujo de cambios, una secuencia o un modelo.

• Si se especifica una lista de columnas para una tabla, el privilegio solo es válido para esas columnas. Si no se especifica ninguna lista de columnas, el privilegio es válido en todas las columnas de la tabla, incluidas las que se añadan posteriormente. No se permite una lista de columnas en una vista.

• Spanner admite vistas con derechos del invocador y vistas con derechos del definidor. Para obtener más información, consulta Introducción a las visualizaciones.

  Si creas una vista con derechos del invocador, para consultar la vista, el rol o el usuario de la base de datos necesita el privilegio SELECT en la vista y el privilegio SELECT en los objetos subyacentes a los que se hace referencia en la vista. Por ejemplo, supongamos que la vista SingerNames se crea en la tabla Singers.

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

  Supongamos que el rol de base de datos myRole realiza la consulta SELECT * FROM SingerNames. El rol debe tener el privilegio SELECT en la vista y el privilegio SELECT en las tres columnas a las que se hace referencia o en toda la tabla Singers.

  Si creas una vista con derechos del definidor, para consultar la vista, el rol o el usuario de la base de datos solo necesita el privilegio SELECT en la vista. Por ejemplo, supongamos que la vista AlbumsBudget se crea en la tabla Albums.

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

  Supongamos que el rol de base de datos Analyst realiza la consulta SELECT * FROM AlbumsBudget. El rol solo necesita el privilegio SELECT en la vista. No necesita el privilegio SELECT en las tres columnas a las que se hace referencia ni en la tabla Albums.

• Después de conceder SELECT en un subconjunto de columnas de una tabla, el usuario de FGAC ya no puede usar SELECT * en esa tabla. Las consultas en esa tabla deben incluir todos los nombres de las columnas.

• El SELECT concedido en una columna generada no concede SELECT en las columnas base subyacentes.

• En las tablas intercaladas, los SELECT concedidos en la tabla principal no se propagan a la tabla secundaria.

• Cuando concede SELECT en un flujo de cambios, también debe conceder EXECUTE en la función con valores de tabla del flujo de cambios. Para obtener más información, consulta EXECUTE.

• Cuando se usa SELECT con una función de agregado en columnas específicas, como SUM(col_a), el rol debe tener el privilegio SELECT en esas columnas. Si la función de agregación no especifica ninguna columna (por ejemplo, COUNT(*)), el rol debe tener el privilegio SELECT en al menos una columna de la tabla.

• Cuando usas SELECT con una secuencia, solo puedes ver las secuencias para las que tengas privilegios.

Ejemplos 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 el rol inserte filas en las tablas especificadas. Si se especifica una lista de columnas, el permiso solo es válido para esas columnas. Si no se especifica ninguna lista de columnas, el privilegio es válido en todas las columnas de la tabla.

• Si se especifican nombres de columna, cualquier columna que no se incluya obtendrá su valor predeterminado al insertarse.

• No se pueden conceder INSERT en columnas generadas.

Ejemplos 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 el rol actualice las filas de las tablas especificadas. Las actualizaciones se pueden restringir a un subconjunto de columnas de la tabla. Si la usas con secuencias, permite que el rol llame a la función get-next-sequence-value en la secuencia.

Además del privilegio UPDATE, el rol necesita el privilegio SELECT en todas las columnas consultadas. Las columnas consultadas incluyen las columnas de la cláusula WHERE.

No se pueden conceder UPDATE en columnas generadas.

Ejemplos 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 el rol elimine filas de las tablas especificadas.

• No se puede conceder DELETE a nivel de columna.

• El rol también necesita SELECT en las columnas que puedan incluirse en las cláusulas WHERE de la consulta.

• En las tablas intercaladas de las bases de datos con dialecto GoogleSQL, el privilegio DELETE solo es necesario en la tabla principal. Si una tabla secundaria especifica ON DELETE CASCADE, las filas de la tabla secundaria se eliminan aunque no se tenga el privilegio DELETE en la tabla secundaria.

Ejemplo 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

Cuando concede SELECT en un flujo de cambios, también debe conceder EXECUTE en la función de lectura del flujo de cambios. Para obtener más información, consulta Funciones de lectura de flujo de cambios y sintaxis de consulta.

Si la usas con modelos, el rol podrá usar el modelo en funciones de aprendizaje automático.

Ejemplo de uso de GRANT EXECUTE

En el siguiente ejemplo se muestra cómo conceder EXECUTE en la función de lectura del flujo de cambios llamado 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

Cuando concede USAGE a un esquema con nombre, se proporcionan privilegios para acceder a los objetos contenidos en el esquema con nombre. El privilegio USAGE se concede de forma predeterminada al esquema predeterminado.

Siguientes pasos

• Configurar el control de acceso granular
• Información general sobre el control de acceso granular
• Instrucciones GRANT y REVOKE (bases de datos de dialecto GoogleSQL)
• Instrucciones GRANT y REVOKE (bases de datos con dialecto PostgreSQL)