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 que los necesarios puede activar con mayor facilidad ataques de canales secundarios y aprender datos sensibles mediante 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 |
|---|---|
| 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. |
| 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 comando bq load o la API de escritura de BigQuery Storage. 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 diferentes para el acceso de escritura de las tablas y las políticas de acceso a nivel de las filas. Los usuarios que solo deben ver los resultados filtrados de la tabla no deben 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 deseadas.
- Vuelve a habilitar el acceso a la 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.
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.
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.