Prácticas recomendadas para la seguridad a nivel de fila en BigQuery
En este documento se explican las prácticas recomendadas para usar la seguridad a nivel de fila.
Antes de leer este documento, familiarícese con la seguridad a nivel de fila leyendo los artículos Introducción a la seguridad a nivel de fila de BigQuery y Trabajar con la seguridad a nivel de fila.
Restringir los permisos de 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 propio sistema. Un atacante con más permisos de los necesarios puede lanzar ataques de canal lateral y obtener datos sensibles observando o buscando mensajes de facturación, registro o del sistema.
Para reducir estas oportunidades, BigQuery oculta las estadísticas sensibles de todas las consultas en tablas con seguridad a nivel de fila. Estas estadísticas sensibles incluyen el número de bytes y particiones procesados, el número de bytes facturados y las fases del plan de consulta.
Recomendamos que los administradores no concedan los siguientes permisos a los usuarios que solo deban ver datos filtrados para evitar que accedan a datos sensibles.
| Permisos | Datos sensibles |
|---|---|
| Propietario del proyecto | Los propietarios de proyectos solo pueden ver los bytes procesados y los datos relacionados en los registros de auditoría. Los metadatos de facturación no se pueden ver en los detalles del trabajo. No hay ningún permiso ni rol específico para conceder acceso de lectura a estos metadatos de facturación. |
| Roles Editor, Propietario o Lector de datos de BigQuery | Ver mensajes de error en las consultas. |
| Permisos de lector de facturación de Cloud | Consulta la facturación de BigQuery. |
Ejemplos
- Mediante la observación repetida de la duración de las consultas al consultar tablas con políticas de acceso a nivel de fila, un usuario podría inferir los valores de las filas que, de lo contrario, podrían estar protegidas por políticas de acceso a nivel de fila. Este tipo de ataque requiere muchos intentos repetidos en un intervalo de valores de clave en columnas de partición o de clúster. Aunque hay ruido inherente al observar o medir la duración de las consultas, con intentos repetidos, un atacante podría obtener una estimación fiable. Si te preocupa este nivel de protección, te recomendamos que uses tablas independientes para aislar las filas con diferentes requisitos de control de acceso.
- Un atacante podría buscar los bytes procesados por una consulta monitorizando los errores que se producen cuando se superan los límites de la tarea de consulta (como el máximo de bytes facturados o los controles de costes personalizados). Sin embargo, este ataque requiere un gran volumen de consultas.
- Mediante consultas repetidas y observando el importe de facturación de BigQuery en Facturación de Cloud, un usuario podría inferir los valores de las filas que, de otro modo, podrían estar protegidas por políticas de acceso a nivel de fila. Este tipo de ataque requiere muchos intentos repetidos en un intervalo de valores de clave en columnas de partición o de clúster. Si te preocupa 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 monitoricen los registros de auditoría de Cloud(/bigquery/docs/reference/auditlogs) para detectar actividad sospechosa en las tablas con seguridad a nivel de las filas, como adiciones, modificaciones y eliminaciones inesperadas de políticas de acceso a nivel de las filas.
Restringir los permisos de usuario para limitar la manipulación de datos
Los usuarios con permisos de escritura en una tabla pueden insertar datos en ella con el comando bq load o con la API Storage Write de BigQuery. 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 independientes para el acceso de escritura a tablas 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 ella.
Evitar el acceso accidental al volver a crear políticas de acceso a nivel de fila
Cuando añades una política de acceso a filas a una tabla por primera vez, empiezas a filtrar datos inmediatamente en los resultados de las consultas. Cuando eliminas la última política de acceso a nivel de fila de una tabla, aunque solo tengas intención de volver a crearla, puedes conceder por error acceso sin filtros a un público más amplio de lo que pretendías.
Recomendamos que los administradores presten especial atención al recrear la última política de acceso a nivel de fila de una tabla siguiendo estas directrices:
- Primero, elimina todo el acceso a la tabla mediante los controles de acceso a la tabla.
- Elimina 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.
También puedes crear primero políticas de acceso a nivel de fila en la tabla y, a continuación, eliminar las políticas de acceso a nivel de fila anteriores que ya no necesites.
Usar la seguridad a nivel de fila solo en organizaciones, no entre organizaciones
No uses la función de seguridad a nivel de fila en varias organizaciones para evitar fugas de datos mediante ataques de canal lateral y para mantener un mayor control sobre el acceso a los datos sensibles.
En el caso de las políticas de acceso a nivel de fila de subconsultas, crea y busca tablas en organizaciones o proyectos. De esta forma, se mejora la seguridad y se simplifica la configuración de las listas de control de acceso, ya que los beneficiarios deben tener el permiso bigquery.tables.getData en las tablas de destino y de referencia de las políticas, así como los permisos de seguridad a nivel de columna pertinentes.
Recomendamos usar la función de seguridad a nivel de fila solo para las restricciones de seguridad dentro de la organización (por ejemplo, para compartir datos dentro de una organización, una empresa o una compañía) y no para la seguridad pública o entre organizaciones.
Ejemplo
Fuera de tu organización, tienes menos control sobre quién tiene acceso a los datos. En tu organización, puedes controlar quién tiene acceso a la información de facturación de las consultas en tablas con políticas de acceso a nivel de fila. La información de facturación es un vector de ataques de canal lateral.
Gestionar el rol Filtered Data Viewer mediante políticas de acceso a nivel de fila
Cuando creas una política de acceso a nivel de fila, se asigna automáticamente el rol bigquery.filteredDataViewer a las entidades de la política. Solo puedes añadir o quitar entidades principales de la política de acceso con una instrucción DDL.
El rol bigquery.filteredDataViewer no debe concederse a través de gestión de identidades y accesos a un recurso de nivel superior, como una tabla, un conjunto de datos o un proyecto. Si asignas el rol de esta forma, los usuarios podrán ver las filas definidas por todas las políticas de acceso a nivel de fila de ese ámbito, con independencia de las restricciones previstas. Aunque la unión de los filtros de la política de acceso a nivel de fila no abarque toda la tabla, esta práctica supone un riesgo de seguridad importante y menoscaba el propósito de la seguridad a nivel de fila.
Te recomendamos que gestiones el rol bigquery.filteredDataViewer exclusivamente mediante políticas de acceso a nivel de fila. Este método asegura que se conceda el rol bigquery.filteredDataViewer a las entidades principales 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 con particiones
Los filtros de las políticas de acceso a nivel de fila no participan en la poda de consultas en tablas con particiones y agrupadas en clústeres.
Si tu política de acceso a nivel de fila incluye el nombre de una columna particionada, tu consulta no se beneficiará de la optimización de consultas.