Se usó la API de Cloud Translation para traducir esta página.

Descripción general del control de acceso detallado

El control de acceso detallado de Spanner combina los beneficios Identity and Access Management (IAM) con Control de acceso basado en roles de SQL. Con el control de acceso detallado, puedes definir roles de base de datos, otorgar privilegios a los roles y crear Políticas de IAM para otorgar permisos sobre roles de bases de datos a Principales de IAM.

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

Se rige el acceso a los recursos para los usuarios que no son usuarios de control de acceso detallados por roles a nivel de base de datos de IAM. El control de acceso detallado es totalmente compatible y puede coexistir con el control de acceso a nivel de la base de datos de IAM existente. Puedes usarla para acceder objetos de base 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 el siguiente DDL declaraciones:

Sentencias CREATE y DROP para crear y descartar roles de base de datos Los roles de la base de datos son colecciones de privilegios. Puedes crear hasta 100 roles para una base de datos.
Sentencias GRANT y REVOKE para otorgar y revocar privilegios a roles de base de datos y desde ellos Los privilegios incluyen SELECT, INSERT, UPDATE, DELETE y EXECUTE. Los nombres de los privilegios corresponden a las instrucciones de SQL con nombres similares. Por ejemplo, un rol con el El privilegio INSERT puede ejecutar la instrucción de SQL INSERT en las tablas que se especifican en la sentencia GRANT.

Las siguientes declaraciones DDL otorgan SELECT en la tabla employees. para el 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 la 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

Los siguientes son casos de uso de muestra para un control de acceso detallado:

Un sistema de información de RR.HH. que tiene roles de analista de compensación de ventas, la gestión de ventas y el analista de RR.HH., cada uno con diferentes niveles de acceso a los datos. Por ejemplo, los analistas de compensaciones y la administración de ventas no deberían ver tus números de seguridad.
Una aplicación de transporte privado con conductor con diferentes privilegios y cuentas de servicio para pasajeros y conductores.
Un libro mayor que permita operaciones SELECT y INSERT, pero no operaciones UPDATE ni DELETE

Recursos de Spanner y sus privilegios

A continuación, se presenta una lista de los recursos de Spanner y el control de acceso detallado privilegios que puedes otorgarle.

Esquemas: Puedes otorgar el privilegio USAGE en esquemas a roles específicos de la base de datos. Para un esquema que no sea predeterminado, los roles de la base de datos deben tener el privilegio USAGE para acceder a los objetos de la base de datos. La verificación de privilegios tiene el siguiente aspecto:

¿Tienes USAGE en el esquema?

No: Rechaza el acceso.

Sí: ¿También tienes los derechos correspondientes sobre la mesa?

No: Rechaza el acceso.

Sí: Puedes acceder a la tabla.

Tablas: Puedes otorgar los privilegios SELECT, INSERT, UPDATE y DELETE en desde tablas hacia roles de bases de datos. En el caso de las tablas intercaladas, un privilegio otorgado en la tabla superior no se propaga a la tabla secundaria.
Columnas: Puedes otorgar SELECT, INSERT y UPDATE en un subconjunto de columnas de una tabla. El privilegio solo es válido para esas columnas. DELETE no es permitidos a nivel de la columna.
Vistas: Puedes otorgar el privilegio SELECT en una vista. Solo se admite SELECT para vistas. Spanner admite tanto las vistas de derechos del invocador como las vistas vistas de derechos. Si creas una vista con derechos de invocador, para consultarla, El usuario o rol de la base de datos necesita el privilegio SELECT en la vista, además del El privilegio SELECT en los objetos subyacentes a los que se hace referencia en la vista Si crear una vista con derechos de definidor, para consultar la vista, el rol de base de datos o el usuario solo necesita el privilegio SELECT en la vista. Para obtener más información, consulta Descripción general de las vistas.
Cambiar transmisiones: 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 información, consulta Control de acceso detallado para los flujos de cambios.
Secuencias: Puedes otorgar SELECT y UPDATE en secuencias. Para obtener información, consulta Control de acceso detallado para secuencias.
Modelos: Puedes otorgar EXECUTE a los modelos. Para obtener 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 de control de acceso detallado se le debe otorgar el rol del sistema spanner_sys_reader para acceder al Visualizador de claves y el rol del sistema spanner_info_reader para poder ver resultados sin filtrar cuando se consultan 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 bases de datos, donde los roles secundarios heredarán los privilegios de los roles superiores. Los roles secundarios se conocen como miembros del rol superior.

Por ejemplo, considera las siguientes sentencias 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, que tendrán hereda 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 degradarse 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, los roles de la base de datos se recrean con sus 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 restablecida.

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

Estos son los pasos de alto nivel que debes seguir para comenzar para proteger los datos con un control de acceso detallado. Para obtener más información, consulta Configura el control de acceso detallado.

Debes tener los permisos de roles/spanner.admin o roles/spanner.databaseAdmin roles de IAM para realizar estas tareas.

Crea roles de base de datos y otorga privilegios a los roles.
Opcional: Crea jerarquías de roles con herencia otorgando roles a otros roles.
Realiza estos pasos para cada principal que será un usuario de control de acceso detallado:
1. Habilita el control de acceso detallado para el principal. Luego, se le otorga automáticamente al principal el rol de la base de datos public, que no tiene privilegios de forma predeterminada. Esta es una operación única para cada principal.
2. Otorga permisos de IAM en uno o más roles de base de datos a la principal.
3. Después de que la principal recibe todos los roles de base de datos necesarios, 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 a través de un solo método.

Limitaciones

Las operaciones de exportación no exportan roles ni privilegios de la base de datos, y las operaciones de importación no pueden importarlos. Debes configurar los roles y privilegios de forma manual una vez finalizada la importación.
La pestaña Datos de la página TABLA de la consola de Google Cloud no está disponible para los usuarios del control de acceso detallado.

¿Qué sigue?

Consulta los siguientes temas para obtener más información: