Descripción general del control de acceso detallado

El control de acceso detallado de Spanner combina los beneficios de Identity and Access Management (IAM) con el control de acceso basado en roles de SQL. Con el control de acceso detallado, defines roles de base de datos, otorgas privilegios a los roles y creas políticas de IAM para otorgar permisos sobre los roles de base de datos a los principales de IAM. En esta página, se describe cómo usar el control de acceso detallado con Spanner para bases de datos con dialecto de GoogleSQL y bases de datos con dialecto de PostgreSQL.

Como administrador, debes habilitar el control de acceso detallado para los principales de IAM individuales. Los principales para los que está habilitado el control de acceso detallado ("usuarios del control de acceso detallado") deben asumir un rol de base de datos para acceder a los recursos de Spanner.

El acceso a los recursos para los usuarios que no utilizan el control de acceso detallado se rige por los roles de IAM a nivel de la base de datos. El control de acceso detallado es totalmente compatible y puede coexistir con el control de acceso existente a nivel de la base de datos de IAM. Puedes usarlo para acceder a objetos de bases de datos individuales. Para controlar el acceso a toda la base de datos, usa roles de IAM.

Con el control de acceso detallado, puedes controlar el acceso a tablas, columnas, vistas y flujos de cambios.

Para administrar el control de acceso detallado, usa las siguientes instrucciones de DDL:

  • Instrucciones CREATE y DROP para crear y descartar roles de base de datos. Los roles de base de datos son colecciones de privilegios. Puedes crear hasta 100 roles para una base de datos.

  • Instrucciones GRANT y REVOKE para otorgar y revocar privilegios a roles de base de datos. Los privilegios incluyen SELECT, INSERT, UPDATE, DELETE y EXECUTE. Los nombres de los privilegios corresponden a las instrucciones de SQL con el mismo nombre. Por ejemplo, un rol con el privilegio INSERT puede ejecutar la instrucción de SQL INSERT en las tablas que se especifican en la sentencia GRANT.

    Las siguientes instrucciones DDL otorgan SELECT en la tabla employees al rol de base de datos hr_rep.

    GoogleSQL 

    CREATE ROLE hr_rep;
GRANT SELECT ON TABLE employees TO ROLE hr_rep;

    PostgreSQL 

    CREATE ROLE hr_rep;
GRANT SELECT ON TABLE employees TO hr_rep;

    Para obtener más información sobre los privilegios, consulta Referencia de privilegios de control de acceso detallado.

  • Sentencias GRANT para otorgar roles a otros roles y crear jerarquías de roles, con herencia de privilegios.

Casos de uso

A continuación, se muestran ejemplos de casos de uso del control de acceso detallado:

  • Un sistema de información de RR.HH. que tiene roles para el analista de compensación de ventas, la administración de ventas y el analista de RR.HH., cada uno con diferentes niveles de acceso a los datos Por ejemplo, los analistas de compensación y la administración de ventas no deberían ver los números de seguridad social.
  • Una aplicación de viajes compartidos con diferentes cuentas de servicio y privilegios para pasajeros y conductores.
  • Un libro de contabilidad que permite operaciones de SELECT y INSERT, pero no de UPDATE y DELETE.

Recursos de Spanner y sus privilegios

A continuación, se incluye una lista de los recursos de Spanner y los privilegios de control de acceso detallado que puedes otorgar para ellos.

Esquemas
Puedes otorgar el privilegio USAGE en esquemas a roles de base de datos específicos. En el caso de un esquema no predeterminado, los roles de base de datos deben tener el privilegio USAGE para acceder a los objetos de la base de datos. La verificación de privilegios se ve de la siguiente manera:

¿Tienes USAGE en el esquema?

No: Rechaza el acceso.

Sí: ¿También tienes los derechos adecuados sobre la tabla?

No: Rechaza el acceso.

Sí: Puedes acceder a la tabla.

Tablas
Puedes otorgar los privilegios SELECT, INSERT, UPDATE y DELETE en las tablas a los roles de la base de datos. En el caso de las tablas intercaladas, un privilegio otorgado en la tabla principal no se propaga a la tabla secundaria.
Columnas
Puedes otorgar SELECT, INSERT y UPDATE en un subconjunto de columnas de una tabla. Luego, el privilegio solo será válido para esas columnas. DELETE no se permite a nivel de la columna.
Vistas
Puedes otorgar privilegios de SELECT en una vista. Solo se admite SELECT para las vistas. Spanner admite vistas de derechos del invocador y vistas de derechos del definidor. 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 también el privilegio SELECT en los objetos subyacentes a los que se hace referencia en la vista. Si creas una vista con derechos del definidor, para consultarla, el rol o el usuario de la base de datos solo necesitan el privilegio SELECT en la vista. Para obtener más información, consulta Descripción general de las vistas.
Flujos de cambios
Puedes otorgar SELECT en los flujos de cambios. También debes otorgar EXECUTE en la función de lectura asociada con un flujo de cambios. Para obtener más información, consulta Control de acceso detallado para los flujos de cambios.
Secuencias
Puedes otorgar SELECT y UPDATE en secuencias. Para obtener más información, consulta Control de acceso detallado para secuencias.
Modelos
Puedes otorgar EXECUTE en los modelos. Para obtener más información, consulta Control de acceso detallado para modelos.

Roles del sistema de control de acceso detallado

El control de acceso detallado tiene roles del sistema predefinidos para cada base de datos. Al igual que los roles de base de datos definidos por el usuario, los roles del sistema pueden controlar el acceso a los recursos de Spanner.

Por ejemplo, a un usuario con control de acceso detallado se le debe otorgar el rol del sistema spanner_sys_reader para acceder a Key Visualizer y el rol del sistema spanner_info_reader para poder ver los resultados sin filtrar cuando consulta las tablas INFORMATION_SCHEMA.

Para obtener más información, consulta Roles del sistema de control de acceso detallado.

Jerarquías y herencia de roles de bases de datos

Puedes crear jerarquías de roles de base de datos, en las que los roles secundarios heredan los privilegios de los roles principales. Los roles secundarios se conocen como miembros del rol principal.

Por ejemplo, considera las siguientes instrucciones GRANT:

GoogleSQL 

GRANT SELECT ON TABLE employees TO ROLE pii_access;
GRANT ROLE pii_access TO ROLE hr_manager, hr_director;

PostgreSQL 

GRANT SELECT ON TABLE employees TO pii_access;
GRANT pii_access TO hr_manager, hr_director;

hr_manager y hr_director son miembros del rol pii_access y heredan el privilegio SELECT en la tabla employees.

Herencia de privilegios

hr_manager y hr_director también pueden tener miembros, y esos miembros heredarían el privilegio SELECT en employees.

No hay límites en la profundidad de las jerarquías de roles, pero el rendimiento de las consultas podría disminuir con estructuras de jerarquía de roles profundas y amplias.

Copia de seguridad y restablecimiento

Las copias de seguridad de Spanner incluyen definiciones de roles de base de datos. Cuando se restablece una base de datos a partir de una copia de seguridad, se vuelven a crear los roles de la base de datos con los privilegios otorgados. Sin embargo, las políticas de IAM no forman parte de las copias de seguridad de la base de datos, por lo que debes volver a otorgar acceso a los roles de la base de datos a los principales en la base de datos restaurada.

Descripción general de la configuración del control de acceso detallado

A continuación, se indican los pasos generales que debes seguir para comenzar a proteger los datos con un control de acceso detallado. Para obtener más información, consulta Configura el control de acceso detallado.

Para realizar estas tareas, debes tener los roles de IAM roles/spanner.admin o roles/spanner.databaseAdmin.

  1. Crear roles de base de datos y otorgar privilegios a los roles
  2. Opcional: Crea jerarquías de roles con herencia otorgando roles a otros roles.
  3. Sigue estos pasos para cada principal que será usuario del control de acceso detallado:
    1. Habilita el control de acceso detallado para la principal. Luego, se le otorga automáticamente al principal el rol de base de datos public, que no tiene privilegios de forma predeterminada. Esta es una operación que se realiza una sola vez para cada principal.
    2. Otorga permisos de IAM en uno o más roles de base de datos a la entidad.
    3. Después de que se le otorgan a la principal todos los roles de base de datos requeridos, si la principal tiene roles de IAM a nivel de la base de datos, considera revocar los roles a nivel de la base de datos para que el control de acceso de la principal se administre con un solo método.

Limitaciones

  • Las operaciones de exportación no exportan roles ni privilegios de bases de datos, y las operaciones de importación no pueden importarlos. Debes configurar manualmente los roles y privilegios después de que se complete la importación.
  • La pestaña Datos de la página TABLA de la consola de Google Cloud no está disponible para los usuarios con control de acceso detallado.

¿Qué sigue?