Seguridad a nivel de fila para paneles de control: cómo funciona

La seguridad a nivel de fila (RLS) es un control de base de datos que determina qué filas de una tabla puede leer o modificar un usuario, en función de quién sea, de su rol o del contexto de su sesión. En el caso de un panel de control, esto significa que dos clientes pueden abrir el mismo gráfico y ver cifras diferentes, ya que la capa de datos solo muestra a cada uno de ellos sus propias filas. Esta guía explica qué es la RLS, cómo funciona en Postgres, SQL Server y BigQuery, en qué casos falla y cómo se adapta a los paneles de control internos y dirigidos a los clientes.

dashrendrapp.dashrendr.comCrea paneles de control para cada clienteCrea paneles de control orientados al cliente con tus datos, utilizando un editor de arrastrar y soltar para personalizar lo que muestra tu producto SaaS.Prueba el entorno de pruebas

En resumen

• RLS filtra las filas dentro de la base de datos mediante políticas, por lo que las reglas de acceso se aplican directamente sobre los datos en lugar de repetirse en cada consulta de la aplicación.
• Es ideal para SaaS multitenant (una tabla compartida, muchos clientes) y para cualquier caso en el que el nivel de confidencialidad varíe según la fila.
• Los errores más comunes son una tabla en la que nunca se ha habilitado RLS, un rol con privilegios que lo elude y políticas que nadie ha probado en casos de denegación.
• En el caso de los paneles de control integrados, el RLS en la base de datos es solo una capa. Sigue siendo necesaria la herramienta del panel de control para pasar la identidad correcta del inquilino en cada consulta.
• dashrendr es una plataforma de análisis para equipos de SaaS, con planes a partir de 6 $ al mes y una prueba gratuita de 14 días, sin necesidad de tarjeta de crédito.

Índice

• ¿Qué es realmente la seguridad a nivel de fila?
• Cómo funciona la RLS en segundo plano
• Cuándo utilizar la seguridad a nivel de fila
• RLS en PostgreSQL
• La RLS en SQL Server y BigQuery
• Cómo funciona la RLS en paneles de control y análisis integrados
• Errores comunes y limitaciones
• Nuestra perspectiva: la RLS es un piso, no todo el edificio
• Dónde encaja dashrendr
• El uso de RLS también en paneles de control internos
• Preguntas frecuentes
• Fuentes

¿Qué es realmente la seguridad a nivel de fila?

Un permiso normal dice: «este usuario puede leer la tabla de pedidos». La RLS va un paso más allá: «este usuario puede leer la tabla de pedidos, pero solo las filas en las que el ID de cliente sea el suyo».

Microsoft describe la RLS como el uso de la pertenencia a un grupo o del contexto de ejecución para controlar el acceso a las filas de una tabla de base de datos, mediante un control de acceso basado en predicados. Teradata lo explica de forma más sencilla: limita las filas que un usuario puede leer o modificar en función de su identidad, su rol o el contexto de la sesión.

Hay dos términos clave aquí. Un predicado es simplemente una condición que es verdadera o falsa para cada fila (por ejemplo, tenant_id = 42). La política es la regla que asocia un predicado a una tabla y establece cuándo se aplica.

El término también aparece en herramientas de BI como Power BI, donde significa filtrar el contenido de los informes según el rol del usuario. La idea es la misma, pero el punto de aplicación difiere: en una herramienta de BI, el filtro se encuentra en el modelo del informe, mientras que en una base de datos se encuentra en el motor y se aplica a todas las consultas que afectan a la tabla. Este artículo se centra en el tipo de base de datos, ya que es lo que te protege cuando los paneles de control están integrados en tu propio producto.

Cómo funciona RLS en segundo plano

Cuando RLS está activado, el motor añade su predicado a cada consulta, tanto si el usuario ha escrito una simple instrucción SELECT como si se trata de una unión entre cinco tablas. El usuario nunca ve la condición adicional.

La documentación de SQL Server de Microsoft describe dos tipos de predicados:

• Los predicados de filtro eliminan de forma silenciosa filas de las operaciones de lectura, como «select», «update» y «delete». La consulta se ejecuta con éxito, pero devuelve menos filas.
• Los predicados de bloqueo rechazan las operaciones de escritura que infringirían la regla; por ejemplo, un «insert» que intente crear una fila perteneciente a otro inquilino.

Ese filtrado silencioso es la razón por la que RLS resulta tan sencillo de usar en un panel de control. Una consulta para obtener los ingresos totales no necesita una cláusula WHERE customer_id = ... cláusula. La misma consulta devuelve el total correcto para cada usuario.

Microsoft también señala que RLS simplifica la seguridad de las aplicaciones al situar la lógica de restricción de acceso en el nivel de la base de datos, en lugar de en otra capa de la aplicación. En la práctica, esto significa que si un desarrollador se olvida de incluir un filtro en un punto final, ya no se producen fugas de datos.

Cuándo utilizar la seguridad a nivel de fila

La respuesta sincera a la pregunta «¿debería habilitarse la RLS?» es: sí, siempre que una tabla contenga filas que pertenezcan a diferentes personas y más de una de ellas pueda acceder a la base de datos, ya sea directamente o a través de una herramienta.

Casos típicos:

• SaaS multitenant. Teradata considera que la RLS resulta especialmente útil para aislar los datos de los clientes en entornos multitenant y para proporcionar un acceso más preciso cuando el nivel de confidencialidad varía según la fila.
• Datos regulados. AWS ofrece ejemplos como restringir el acceso a los datos de pacientes para cumplir con la HIPAA, o compartimentar las cuentas financieras de los clientes por asesor. Si la RLS por sí sola cumple con una normativa es una cuestión que debe consultar con su asesor de cumplimiento normativo, no con una herramienta de panel de control.
• Equipos internos. Un responsable regional de ventas ve su región, el equipo de asistencia técnica ve los tickets de las cuentas que gestiona y el departamento financiero lo ve todo.

Cuándo puede que no lo necesites: una base de datos de un solo inquilino en la que todos los usuarios tienen permiso para ver todo, o una configuración en la que cada cliente ya dispone de su propia base de datos independiente. Las bases de datos independientes ofrecen un mayor aislamiento, pero su funcionamiento y migración son más costosos. Analizamos las ventajas e inconvenientes en nuestra guía sobre paneles de control multitenant y aislamiento de datos.

RLS en PostgreSQL

Postgres es donde la mayoría de los equipos de SaaS se encuentran por primera vez con RLS. La documentación de PostgreSQL sobre políticas de seguridad de filas indica que la seguridad de filas se aplica al acceso normal a las tablas una vez que se habilita con ALTER TABLE ... ENABLE ROW LEVEL SECURITY. Hasta que no lo hagas, las políticas que crees no tendrán ningún efecto.

Una política mínima de inquilino tiene este aspecto:

ALTER TABLE orders ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON orders
  USING (tenant_id = current_setting('app.tenant_id')::int);

La aplicación (o la capa de conexión de la herramienta de paneles de control) establece app.tenant_id para la sesión, y se filtran todas las consultas en orders se filtra. Añade una WITH CHECK cláusula si también quieres impedir las escrituras en las filas de otro inquilino.

Hay tres detalles que suelen confundir a los usuarios:

1. Los propietarios de las tablas y los superusuarios eluden las políticas de forma predeterminada. Si tu panel de control se conecta como propietario, RLS no protege nada.
2. La ausencia de política implica denegación. Una vez activado RLS, un rol sin una política que coincida no verá ninguna fila. Esto es una medida de seguridad, pero puede parecer una interrupción del servicio.
3. Las políticas son código en la ruta principal. Un predicado que llama a una función lenta se ejecuta por cada fila. Indexa la columna de inquilino y mantén el predicado sencillo.

Si utilizas Supabase, sus recomendaciones son claras y vale la pena seguirlas. Su documentación sobre seguridad a nivel de fila indica que se debe habilitar RLS en todas las tablas de un esquema expuesto, mantener la service_role clave en el lado del servidor, ya que esta elude el RLS, y revocar las anon y authenticated antes de conceder únicamente lo necesario.

En cuanto a la conexión, consulta nuestra guía paso a paso sobre un panel de control seguro de PostgreSQL a través de la API REST.

RLS en SQL Server y BigQuery

SQL Server implementa RLS mediante políticas de seguridad y predicados escritos como funciones en línea con valores de tabla. La función devuelve una fila cuando se permite el acceso, y la política vincula esa función a una tabla como filtro o predicado de bloqueo.

BigQuery utiliza políticas de acceso a nivel de fila. La documentación de Google indica que estas pueden coexistir con la seguridad a nivel de columna y con los controles de acceso a nivel de proyecto, conjunto de datos y tabla, por lo que se pueden combinar en lugar de tener que elegir una sola opción.

BigQuery incluye una advertencia importante para el SaaS. Google recomienda utilizar la seguridad a nivel de fila únicamente dentro de una misma organización, y no entre organizaciones, para ayudar a prevenir la fuga de datos a través de ataques de canal lateral. Si tus «usuarios» son tus clientes externos, eso es una señal de que debes filtrar por inquilino en una capa controlada delante de BigQuery, en lugar de facilitar a los clientes identidades de la base de datos. Nuestra guía de análisis integrado de BigQuery repasa ese patrón, y el artículo sobre optimización de costes de BigQuery explica cómo afectan a tu factura las consultas por inquilino.

MySQL no cuenta con una función RLS nativa. Los equipos suelen emularla mediante vistas que filtran por una variable de sesión o por usuario, tal y como muestra el artículo de AWS sobre Aurora MySQL y RDS para MySQL. Si utilizas MySQL como base de datos, lee nuestras notas sobre un panel de control integrado de MySQL seguro antes de exponerlo.

Cómo funciona RLS en los paneles de control y el análisis integrado

Esta es la parte que la mayoría de las guías omiten. Un panel de control añade un intermediario entre el usuario y la base de datos, y ese intermediario decide qué identidad ve la base de datos.

Existen tres patrones habituales:

Patrón	Cómo se aplica el control de acceso por inquilino	Ventajas	A tener en cuenta
RLS de base de datos con contexto por sesión	La herramienta establece un valor de sesión (como el ID de inquilino) antes de cada consulta; las políticas filtran las filas	Se aplica en el motor, por lo que una consulta errónea no puede escapar	El uso compartido de conexiones puede provocar fugas de contexto si no se restablece el valor
Usuarios de la base de datos por cliente	Cada cliente se asigna a un rol de base de datos con sus propias políticas	Separación rigurosa	Difícil de gestionar a partir de unas pocas docenas de clientes
Filtro de inquilino aplicado por la capa del panel de control	La herramienta incorpora la condición de inquilino en cada consulta procedente de una identidad autenticada	Funciona en bases de datos sin RLS nativo	La herramienta se convierte en el límite de seguridad, por lo que debe ser fiable y haber sido sometida a pruebas

La regla que se aplica a los tres casos: la identidad del inquilino debe proceder de tu servidor, nunca del navegador. Si la incrustación acepta un ID de cliente que el usuario puede editar en una URL o en un script, no tienes seguridad, solo tienes una sugerencia.

Una segunda regla: la conexión al panel de control debe utilizar un rol con el mínimo de privilegios, nunca el del propietario de la tabla ni el de superusuario. Esa única elección determina si el RLS de Postgres te protege realmente.

El patrón que se describe en nuestra propia guía sobre cómo proporcionar a cada cliente sus propios datos sin alterar la base de datos explica paso a paso el enfoque de las tablas compartidas.

Errores comunes y limitaciones

La mayoría de los incidentes relacionados con RLS son aburridos. Se deben a la configuración, no a ataques ingeniosos.

• Habilitar políticas pero no RLS. En Postgres, la política existe, pero la tabla está totalmente abierta.
• Un rol de elusión en el lugar equivocado. Las claves de servicio y los roles de propietario eluden el RLS. Manténlos en el lado del servidor y fuera de cualquier conexión al panel de control.
• Probar solo el caso más sencillo. La recomendación de Supabase es escribir pruebas que comprueben tanto el permiso como la denegación para las operaciones SELECT, INSERT, UPDATE y DELETE, con una política para cada operación. Prueba cómo el inquilino A intenta leer los datos del inquilino B, no solo cómo el inquilino A lee sus propios datos.
• Olvidarse de las uniones y las vistas. Una vista puede ejecutarse con los derechos de su propietario y eludir la política de la tabla subyacente. Comprueba cómo trata tu motor las vistas.
• Cruzar los límites organizativos. El consejo de Google sobre la fuga por canal lateral, mencionado anteriormente, se aplica a cualquier motor en el que una parte externa pueda ejecutar consultas arbitrarias.
• Considerar el RLS como la solución definitiva. Controla las filas. No oculta columnas, no limita la frecuencia de las consultas ni impide que alguien exporte lo que tiene permiso para ver.

Una lista de comprobación rápida previa al lanzamiento

1. RLS habilitado en todas las tablas que contienen datos de los usuarios.
2. El panel de control se conecta con un rol que no puede eludir el RLS.
3. La identidad del cliente procede de un valor firmado creado en el lado del servidor.
4. La columna del cliente está indexada.
5. Las pruebas automatizadas demuestran que el cliente A no puede leer ni escribir en las filas del cliente B.
6. Las exportaciones y los correos electrónicos programados siguen la misma ruta filtrada que el panel de control en tiempo real.

Este último punto suele pasarse por alto. Un PDF enviado por correo electrónico el lunes por la mañana supone una divulgación de datos igual de grave que un gráfico en tiempo real.

Nuestra perspectiva: RLS es un piso, no todo el edificio

Desarrollamos dashrendr para equipos de SaaS, por lo que vemos este mismo patrón a menudo. Un equipo empieza con una biblioteca de gráficos y luego descubre que los gráficos eran la parte fácil. Los diseños, la separación de inquilinos y las exportaciones son lo que realmente da trabajo.

Nuestra opinión es sencilla: sitúa el aislamiento lo más cerca posible de los datos, dentro de lo que permita tu pila tecnológica, y no dependas de una única capa. Si tu base de datos es compatible con RLS, utilízalo. Si no lo es, como en el caso de MySQL, o si no puedes asignar a la capa del panel de control un rol de base de datos por cliente, asegúrate de que el filtro de clientes se aplique mediante una capa que obtenga la identidad de tu servidor y de ningún otro sitio.

También nos opondríamos a una práctica habitual: copiar los datos de cada cliente a una base de datos independiente solo por sentirse seguro. A veces es lo correcto, sobre todo para clientes sujetos a regulación. A menudo supone un coste elevado para un problema que se resuelve con una política bien probada.

Elijas lo que elijas, pruébalo como lo haría un atacante y comprueba también las exportaciones.

— Paloma

Dónde encaja dashrendr

dashrendr es una plataforma de análisis para equipos de SaaS. Conectas tus fuentes de datos (Google Analytics, BigQuery, PostgreSQL, MySQL, MongoDB, Google Sheets) o envías tus propios datos a través de la API REST, y luego creas paneles de control en un editor de arrastrar y soltar. Los paneles de control se pueden integrar en tu producto para que cada cliente vea sus propios datos, utilizarse internamente para realizar un seguimiento de tus propias métricas o enviarse por correo electrónico de forma programada como informes diarios, semanales o mensuales.

La seguridad multitenant forma parte del producto y está pensada para complementar tus propios controles de base de datos, no para sustituirlos. Aplica tus políticas de tenant, conéctate con un rol de privilegios mínimos y deja que la capa del panel de control se encargue del diseño, la imagen de marca y las exportaciones.

Los planes empiezan en 6 $ al mes (Hobby), con el plan Starter a 15 $ al mes, el Grow a 39 $ al mes y el Premium a 99 $ al mes. Cada miembro adicional del equipo cuesta 3 $ al mes. Hay una prueba gratuita de 14 días y no se requiere tarjeta de crédito. Consulta la página de precios para ver qué incluye cada plan. Si estás creando un portal para clientes, el portal de marca blanca es el punto de partida ideal.

Uso de RLS también para paneles de control internos

RLS no sirve solo para el trabajo de cara al cliente. Los paneles de control internos tienen el mismo problema, aunque con nombres diferentes: el equipo de asistencia técnica debe ver las cuentas de su responsabilidad, un director regional debe ver su región y el departamento de finanzas lo ve todo.

Un único panel de control interno con filtrado por filas es mejor que cinco copias casi idénticas. Las copias se van desajustando y siempre hay alguien que se olvida de actualizar la que nadie se hace cargo. Si estás configurando vistas operativas, nuestra página sobre paneles de control para equipos de operaciones y de asistencia técnica muestra el tipo de diseños que crean los equipos, y los informes automáticos por correo electrónico cubren la parte de los resúmenes semanales.

Preguntas frecuentes

¿Se debe habilitar la seguridad a nivel de fila?

Sí, en cualquier tabla que mezcle datos de diferentes clientes o usuarios y a la que se pueda acceder a través de un panel de control, una API o una conexión directa. En Postgres, habilitarla es un paso independiente de la redacción de políticas, así que comprueba ambos. Comprueba que un usuario de un inquilino no pueda leer ni escribir en las filas de otro inquilino.

¿Qué significa RLS en el ámbito de la seguridad?

Son las siglas de «seguridad a nivel de fila»: un control de acceso que limita qué filas de una tabla puede leer o modificar un usuario, en función de su identidad, rol o contexto de sesión. La base de datos lo aplica en cada consulta, por lo que la aplicación no tiene que acordarse de filtrar.

¿Cómo funciona la seguridad a nivel de fila en PostgreSQL?

Se habilita en una tabla con ALTER TABLE ... ENABLE ROW LEVEL SECURITY, y a continuación se crean políticas con una USING condición para las lecturas y, opcionalmente, WITH CHECK para las escrituras. Los propietarios de las tablas y los superusuarios eluden las políticas por defecto, así que conecta los paneles de control con un rol limitado. El contexto del inquilino suele pasarse como un parámetro de sesión.

¿La seguridad a nivel de fila ralentiza las consultas?

Puede hacerlo, ya que el predicado de la política se ejecuta como parte de cada consulta en esa tabla. Mantén los predicados sencillos, indexa la columna por la que filtran y evita las llamadas a funciones lentas en su interior. Realiza mediciones con y sin la política aplicada a tus propios datos antes de dar por sentado que supone un coste.

¿Es suficiente la RLS para proteger los paneles de control orientados al cliente?

No. Solo controla las filas. También necesitas una identidad de inquilino emitida por el servidor, un rol de conexión con privilegios mínimos, comprobaciones de casos de denegación y el mismo filtrado en las exportaciones y los correos electrónicos programados.

Fuentes

• Seguridad a nivel de fila, SQL Server (Microsoft Learn)
• Documentación de PostgreSQL: Políticas de seguridad a nivel de fila
• Supabase: Seguridad a nivel de fila
• Introducción a la seguridad a nivel de fila en BigQuery (Google Cloud)
• Prácticas recomendadas para la seguridad a nivel de fila en BigQuery (Google Cloud)
• ¿Qué es la seguridad a nivel de fila? (Teradata)
• Implementación de la seguridad a nivel de fila en Amazon Aurora MySQL y RDS para MySQL (AWS)

Recomendado

• Cuadros de mando multitenant: guía de aislamiento de datos
• Panel de control integrado de MySQL seguro: guía para desarrolladores
• Aislamiento de datos de inquilinos en bases de datos compartidas
• Paneles integrados: guía práctica para equipos de SaaS