Prácticas recomendadas para la seguridad a nivel de las filas en BigQuery
En este documento, se explican las prácticas recomendadas para usar la seguridad a nivel de las filas.
Antes de leer este documento, familiarízate con la seguridad a nivel de las filas mediante la lectura de la Introducción a la seguridad a nivel de las filas de BigQuery y de Trabaja con seguridad a nivel de las filas.
Consideraciones de diseño de políticas de acceso de fila
Cuando configures políticas de acceso de fila en una tabla, necesitarás al menos dos:
- Una política que otorgue acceso a la tabla. La primera política de acceso de fila debe otorgar acceso a los usuarios y grupos que requieren acceso completo a los datos de la tabla para el mantenimiento o la asistencia de datos. Por ejemplo, tus administradores de BigQuery y las cuentas de servicio que usan instrucciones DML para transformar los datos de la tabla.
- Una segunda política que usa filtros basados en la lógica empresarial y que se otorgan a grupos específicos.
Para obtener más información sobre la configuración de políticas de acceso de fila, consulta Crea o actualiza una política de acceso a nivel de fila.
Prueba cuentas de servicio con políticas de acceso de fila
Puedes usar la identidad temporal como cuenta de servicio para probar cómo se aplican las políticas de acceso de fila. Para probar tus políticas de acceso de fila con una cuenta de servicio, haz lo siguiente:
- Crea una cuenta de servicio.
- Actualiza la política de acceso de fila para otorgar acceso a la cuenta de servicio. Como alternativa, agrega la cuenta de servicio al grupo de Google al que la política de acceso de fila otorga acceso.
- Usa la identidad temporal como cuenta de servicio para validar que la política de acceso de fila funcione según lo previsto.
Restringe los permisos del usuario para limitar los ataques de canal lateral.
Un ataque de canal lateral es un ataque de seguridad basado en la información obtenida del sistema. Un atacante con permisos más amplios que los necesarios puede activar ataques de canales secundarios y aprender datos sensibles a través de la observación o la búsqueda de mensajes de registros, de facturación o del sistema.
Para mitigar estas oportunidades, BigQuery oculta las estadísticas sensibles en todas las consultas de tablas con seguridad a nivel de fila. Estas estadísticas sensibles incluyen la cantidad de bytes y particiones procesados, la cantidad de bytes facturados y las etapas del plan de consultas.
Recomendamos que los administradores se nieguen a otorgar los siguientes permisos a los usuarios que solo deberían ver los datos filtrados para evitar otorgar acceso a datos sensibles.
| Permisos | Datos sensibles |
|---|---|
| Propietario del proyecto | Los propietarios del proyecto pueden ver los bytes procesados y los datos relacionados solo en los registros de auditoría. Los metadatos de facturación no se pueden ver desde los detalles del trabajo. No hay un permiso o rol específico para otorgar acceso de visualizador a estos metadatos de facturación. |
| Funciones de edición, propietario o visualizador de datos de BigQuery | Visualiza mensajes de error en las consultas. |
| Permisos de visualizador de Facturación de Cloud | Visualiza la facturación de BigQuery. |
Ejemplos
- A través de la observación repetida de la duración de la consulta cuando se consultan tablas con políticas de acceso a nivel de fila, un usuario podría inferir los valores de las filas que, de lo contrario, estarían protegidas por políticas de acceso a nivel de fila. Este tipo de ataque necesita muchos intentos repetidos en un rango de valores clave en columnas de partición o agrupamiento en clústeres. Aunque haya un ruido inherente cuando se observa o mide la duración de la consulta, con intentos reiterados, un atacante podría obtener una estimación confiable. Si eres sensible a este nivel de protección, te recomendamos que uses tablas separadas para aislar las filas con diferentes requisitos de control de acceso.
- Un atacante podría buscar los bytes procesados por una consulta mediante la supervisión de los errores que ocurren cuando se superan los límites del trabajo de consulta (como la cantidad máxima de bytes facturados o los controles de costos personalizados). Sin embargo, este ataque requiere un gran volumen de consultas.
- A través de consultas repetidas y observando el importe de facturación de BigQuery en la Facturación de Cloud, un usuario podría inferir los valores de las filas que, de lo contrario, estarían protegidas por políticas de acceso a nivel de fila. Este tipo de ataque necesita muchos intentos repetidos en un rango de valores clave en columnas de partición o agrupamiento en clústeres. Si eres sensible a este nivel de protección, te recomendamos que limites el acceso a los datos de facturación para las consultas.
También recomendamos que los administradores supervisen los Registros de auditoría de Cloud(/bigquery/docs/reference/auditlogs) para detectar la actividad sospechosa en las tablas con seguridad a nivel de fila, como adiciones, modificaciones y eliminaciones inesperadas de políticas de acceso a nivel de fila.
Restringe los permisos del usuario para limitar la alteración de datos
Los usuarios con permisos de escritura en una tabla pueden insertar datos en la tabla con el
bq load comando o con
la API de escritura de BigQuery Storage (gRPC). Esto puede permitir que el usuario con permisos de escritura altere los resultados de las consultas de otros usuarios.
Recomendamos que los administradores creen grupos de Google separados para el acceso de escritura a la tabla y las políticas de acceso a nivel de fila. Los usuarios que solo deberían ver los resultados de la tabla filtrada no deberían tener acceso de escritura a la tabla filtrada.
Evita el acceso involuntario cuando vuelvas a crear políticas de acceso a nivel de fila
Cuando agregas una política de acceso de fila en una tabla por primera vez, comienzas de inmediato a filtrar datos en los resultados de la consulta. Cuando quitas la última política de acceso a nivel de la fila en una tabla, incluso si quieres solo volver a crear la política de acceso a nivel de fila, puedes otorgar de forma involuntaria acceso sin filtrar a una opción más amplia que el público objetivo.
Recomendamos que los administradores presten especial atención cuando vuelvan a crear la última política de acceso a nivel de fila en una tabla, mediante estos lineamientos:
- Primero, quita todo el acceso a la tabla mediante los controles de acceso a la tabla.
- Quita todas las políticas de acceso a nivel de fila.
- Vuelve a crear las políticas de acceso a nivel de fila.
- Vuelve a habilitar el acceso a la tabla.
Como alternativa, primero puedes crear nuevas políticas de acceso a nivel de fila en la tabla y, luego, borrar las políticas de acceso a nivel de fila anteriores que ya no sean necesarias.
Usa la seguridad a nivel de fila solo dentro de las organizaciones, no entre organizaciones
No uses la función de seguridad a nivel de la fila en todas las organizaciones, para evitar la filtración de datos a través de ataques de canales secundarios y mantener un mayor control sobre el acceso a los datos sensibles.
Para las políticas de acceso a nivel de las filas de subconsultas, crea y busca tablas dentro de organizaciones o proyectos. Esto conduce a una mejor seguridad y a una configuración de LCA más simple, ya que los beneficiarios deben tener el permiso bigquery.tables.getData en las tablas de destino y a las que se hace referencia en las políticas, así como cualquier seguridad a nivel de la columna relevante.
Recomendamos usar la función de seguridad a nivel de fila solo para las restricciones de seguridad dentro de la organización (como compartir datos dentro de una organización, empresa o empresa), y no para la seguridad organizacional o pública.
Ejemplo
Fuera de tu organización, tienes menos control sobre quién tiene acceso a los datos. Dentro de tu organización, puedes controlar quién tiene acceso a los datos de facturación de las consultas en las tablas con políticas de acceso a nivel de fila. Los datos de facturación son un vector de ataques de canales secundarios.
Administra el rol Filtered Data Viewer a través de políticas de acceso a nivel de fila
Cuando
creas una política de acceso a nivel de fila,
a las principales de la política se les otorga automáticamente el rol
bigquery.filteredDataViewer. Solo puedes agregar o quitar principales de
la política de acceso
con una declaración de DDL.
El rol bigquery.filteredDataViewer no se debe otorgar a través de
IAM a un recurso de nivel superior, como
una tabla, un conjunto de datos o un proyecto. Si otorgas el rol de esta manera, los usuarios pueden ver las filas definidas por todas las políticas de acceso a nivel de fila dentro de ese alcance, independientemente de las restricciones previstas. Si bien la unión de los filtros de la política de acceso a nivel de fila podría no abarcar toda la tabla, esta práctica plantea un riesgo de seguridad significativo y socava el propósito de la seguridad a nivel de fila.
Recomendamos administrar el rol bigquery.filteredDataViewer exclusivamente a través de políticas de acceso a nivel de fila. Este método garantiza que a las principales se les otorgue el rol bigquery.filteredDataViewer de forma implícita y correcta, respetando los predicados de filtro definidos para cada política.
Impacto en el rendimiento de los filtros en columnas particionadas
Los filtros de políticas de acceso a nivel de fila no participan en la reducción de consultas en tablas particionadas y agrupadas en clústeres.
Si tu política de acceso a nivel de fila nombra una columna particionada, la consulta no recibe los beneficios de rendimiento de la reducción de consultas.