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.

Restringe los permisos del usuario para limitar los ataques a un canal lateral

Un ataque a un canal lateral es un ataque de seguridad basado en la información obtenida del propio sistema. Un atacante con permisos más amplios de lo necesario podría aprender datos sensibles mediante la observación o la búsqueda a través de la facturación, el registro o los mensajes del sistema.

Para mitigar estas oportunidades, BigQuery oculta las estadísticas sensibles en todas las consultas sobre las 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
Función de propietario o de creador del proyecto Los propietarios del proyecto pueden ver los bytes procesados y los datos relacionados en los registros de auditoría. Los creadores de proyectos pueden crear proyectos nuevos de los que son propietarios y ver los registros de facturación y de auditoría.
Funciones de edición, propietario o visualizador de datos de BigQuery Visualiza mensajes de error en las consultas.
Funciones de visualizador de Monitoring y métricas de Stackdriver para BigQuery Visualiza métricas sobre las consultas, incluidos los bytes procesados y los datos relacionados.
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.
  • Mediante consultas repetidas y cuidadosamente elaboradas, es posible que un usuario malicioso aprenda información sensible mediante la observación de los mensajes de error resultantes. En particular, un usuario malicioso con acceso a la tabla subyacente puede derivar valores de fila protegidos cuando la consulta muestra una excepción de división por cero, aunque haya una Predicado de seguridad para evitar que el usuario consulte directamente los mismos datos. Este tipo de ataque suele necesitar muchos intentos repetidos en una tabla con seguridad a nivel de fila.
  • 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.

Evita abrir de forma involuntaria el acceso cuando vuelves a crear políticas de acceso a nivel de la 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:

  1. Primero, quita todo el acceso a la tabla mediante los controles de acceso a la tabla.
  2. Quita todas las políticas de acceso a nivel de fila.
  3. Vuelve a crear las políticas de acceso a nivel de fila deseadas.
  4. Vuelve a habilitar el acceso a la tabla con los controles de acceso de tabla.

De forma alternativa, primero puedes crear políticas de acceso a nivel de fila nuevas en la tabla y, luego, borrar las políticas de acceso a nivel de fila anteriores que ya no son 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.

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.

Usa la función Filtered Data Viewer con precaución

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 con una declaración de DDL.

Sin embargo, es posible otorgar la función bigquery.filteredDataViewer a través de IAM a un recurso de nivel superior, como una tabla, un conjunto de datos o un proyecto. Si se otorga la función bigquery.filteredDataViewer a un usuario, este puede ver las filas que definen todas las políticas de acceso a nivel de fila en esa tabla, conjunto de datos o proyecto.

Sin embargo, otorgar la función bigquery.filteredDataViewer en una tabla no siempre implica que el usuario pueda ver todas las filas de la tabla. La unión de todas las expresiones de filtro de las políticas de acceso a nivel de fila puede o no formar un cierre en toda la tabla.

Te recomendamos que tengas cuidado antes de otorgar la función bigquery.filteredDataViewer en cualquier recurso.

El filtrado de columnas particionadas afecta el rendimiento

Los filtros de políticas de acceso a nivel de las filas no participan en la reducción de 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.