¿Qué es la seguridad a nivel de fila?

La seguridad a nivel de fila (RLS) es un control de acceso a la base de datos 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.

En lugar de restringir el acceso a tablas completas o columnas específicas, RLS filtra los datos fila por fila. El motor de la base de datos aplica el filtro automáticamente al realizar la consulta, por lo que se aplica la misma regla independientemente de la herramienta que utilice el usuario para acceder a los datos.

RLS forma parte del control de acceso detallado, junto con:

• Seguridad a nivel de columna
• Enmascaramiento de datos
• Permisos a nivel de tabla

Por ejemplo, un vendedor puede consultar la tabla de pedidos de la empresa pero solo ver los pedidos de su región asignada, aunque la tabla contenga los datos de todas las regiones. El usuario escribe una instrucción SELECT normal y el motor devuelve solo las filas que tiene permitido ver.

RLS es ahora un componente fundamental para SaaS multiinquilino, segregación de datos regionales y casos de uso de cumplimiento normativo. Este artículo explica cómo funciona RLS, en qué ayuda, cuáles son sus limitaciones y cómo funciona en la plataforma Databricks.

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

La seguridad a nivel de fila funciona aplicando una regla de filtrado, a menudo llamada política o predicado, a una tabla. Cuando un usuario ejecuta una consulta, el motor de la base de datos aplica automáticamente ese filtro y devuelve solo las filas que el usuario tiene permitido ver.

En la práctica, RLS suele funcionar en tres pasos:

1. El usuario ejecuta una consulta: El usuario escribe una consulta estándar sin añadir ningún filtro de seguridad por su cuenta.
2. La base de datos comprueba la identidad del usuario: El motor evalúa al usuario a través de una función integrada como CURRENT_USER, una variable de sesión establecida por la aplicación o una tabla de asignación que conecta a los usuarios y grupos con los datos permitidos.
3. El motor filtra el resultado: El predicado RLS devuelve TRUE para las filas que el usuario puede ver y FALSE para todo lo demás. Solo se devuelven las filas que superan el predicado.

Dado que la aplicación de la seguridad se realiza en la capa de la base de datos, la misma regla se aplica de forma coherente en todas las vías de acceso, incluidos los paneles de BI, los notebooks, las consultas SQL ad-hoc, las API y las herramientas de terceros. Esa coherencia es lo que hace que RLS sea potente: una sola regla, aplicada en todas partes y ejecutada por el motor.

La mayoría de los motores también distinguen entre la aplicación de reglas de lectura y de escritura. Un predicado de lectura controla lo que devuelve una consulta SELECT. Un predicado de escritura, a menudo definido por separado con una cláusula WITH CHECK, controla qué filas puede insertar, actualizar o eliminar un usuario.

Ambos predicados pueden ser iguales, pero no tienen por qué serlo. Por ejemplo, a un usuario se le puede permitir leer filas de todas las regiones, pero solo insertar filas de su propia región. Definir ambos aspectos es importante cuando una tabla acepta escrituras, ya que omitir la comprobación de escritura es una de las formas más comunes en que los equipos configuran incorrectamente RLS en producción.

Seguridad a nivel de fila frente a seguridad a nivel de columna y otros controles de acceso

RLS es uno de los diversos controles de acceso detallados y, en producción, casi siempre se combina con otros. La siguiente tabla muestra cómo encaja cada control.

Estos controles están diseñados para aplicarse en capas. Una configuración típica utiliza permisos a nivel de tabla para controlar quién puede acceder a ella, RLS para definir qué filas son visibles y seguridad a nivel de columna o enmascaramiento de datos para proteger los campos confidenciales dentro de esas filas. Tratarlos como una pila en lugar de un menú de alternativas hace que la gobernanza sea tanto auditable como resiliente. Una configuración incorrecta en una capa no compromete a las demás.

Casos de uso comunes de la seguridad a nivel de fila

RLS es la forma estándar de controlar quién puede ver qué dentro de una tabla compartida, filtrando las filas en función de los atributos de un usuario frente a una columna clave como la región, el inquilino o la clasificación. La mayoría de los equipos recurren a ella cuando un único conjunto de datos debe dar servicio a múltiples audiencias con diferentes reglas de visibilidad.

• SaaS multiinquilino: Aísle los datos de cada cliente dentro de tablas compartidas utilizando una columna tenant_id y el contexto de sesión. Esto evita el coste operativo de tener un esquema o una base de datos por inquilino, al tiempo que mantiene los datos de cada cliente totalmente separados en el momento de la consulta.
• Segregación regional: Restrinja los datos de ventas, HR o pedidos para que los usuarios solo vean los registros de su país o región, sin dividir la tabla subyacente por geografía.
• Acceso departamental: Proporcione a los equipos de finanzas, marketing y operaciones acceso a la misma tabla pero a diferentes filas, asignadas mediante una columna de departamento o centro de costes.
• Cumplimiento normativo: Aplique reglas de residencia de datos, por ejemplo, haciendo que los registros de la EU solo sean visibles para el personal con sede en la EU en virtud del GDPR, o restringiendo las categorías protegidas según HIPAA, CCPA o normativas específicas del sector.
• Datos clínicos y sanitarios: Permita que los médicos compartan una tabla de pacientes viendo únicamente a sus propios pacientes, lo que respalda el acceso mínimo necesario según HIPAA sin duplicar registros en diferentes silos.
• Portales de socios y proveedores: Comparta un único conjunto de datos entre socios externos filtrando cada uno de ellos para que solo vea sus propios registros, de modo que una única tabla de fuente de verdad pueda alimentar docenas de vistas orientadas a los socios.

Cómo implementar la seguridad a nivel de fila: 4 pasos

El patrón general es coherente en todas las plataformas, y la sintaxis específica del proveedor se completa donde es necesario.

1. Identificar la lógica de filtrado: Decida qué determina el acceso: ID de usuario, pertenencia a un grupo, región, ID de inquilino o una tabla de asignación. La lógica de filtrado debe poder derivarse del contexto de la sesión o de una búsqueda estable, no de valores que el usuario controle en el momento de la consulta.
2. Añadir o confirmar la columna clave: Asegúrese de que la tabla tenga una columna que el filtro pueda utilizar, como tenant_id, region o owner_id. Si aún no existe dicha columna, planifique un llenado retrospectivo antes de que la política se active y considere indexar la columna para que el coste del predicado sea bajo.
3. Definir la política o el filtro de fila: Escriba el predicado que devuelva TRUE para las filas que el usuario tiene permitido ver, y una comprobación independiente para las escrituras si la tabla las acepta. Mantenga la lógica en SQL siempre que sea posible. La mayoría de los motores optimizan los predicados SQL mejor que las llamadas a funciones en otros lenguajes.
4. Probar con múltiples identidades de usuario: Ejecute consultas con diferentes roles y confirme que aparecen las filas correctas y que no se filtra nada entre inquilinos. Incluya una prueba negativa: un usuario sin filas coincidentes debería ver un resultado vacío, no un error, y un usuario con privilegios debería probarse por separado para confirmar el comportamiento de omisión del propietario.

Beneficios de la seguridad a nivel de fila

Llevar la lógica de acceso a la capa de datos ofrece varias ventajas prácticas. En resumen, la base de datos se convierte en la fuente de verdad para el acceso, en lugar de cada aplicación que interactúa con los datos.

• Lógica centralizada: Las reglas de acceso residen con los datos, no dispersas en el código de la aplicación o en las herramientas de BI.
• Aplicación coherente: Se aplica la misma regla independientemente de si el usuario realiza la consulta desde un notebook, un panel o una API.
• Defensa en profundidad: RLS añade una segunda capa de protección si se omiten las comprobaciones de la capa de aplicación o si estas contienen errores.
• Código de aplicación más sencillo: Los desarrolladores no necesitan añadir cláusulas WHERE manuales en cada consulta.
• Auditorías más sencillas: Los equipos de cumplimiento pueden revisar una sola política en lugar de rastrear la lógica de acceso en múltiples sistemas.
• Incorporación más rápida de nuevas herramientas: Una nueva herramienta de BI o entorno de notebook hereda las reglas de nivel de fila existentes sin necesidad de un trabajo de integración personalizado.

Limitaciones y riesgos de la seguridad a nivel de fila

La RLS es potente, pero tiene inconvenientes conocidos que los equipos deben planificar. La mayoría de estos surgen solo en producción o durante una auditoría, por lo que vale la pena conocerlos de antemano.

Omisión de administradores y propietarios

En muchas bases de datos, los propietarios de tablas y los administradores con privilegios elevados omiten la RLS de forma predeterminada. PostgreSQL, por ejemplo, requiere la configuración FORCE ROW LEVEL SECURITY para aplicar políticas al propietario de la tabla, y existen configuraciones similares en otros motores. Este es un hallazgo de auditoría común: asuma que los usuarios con privilegios ven todas las filas a menos que su configuración fuerce explícitamente la aplicación de la política a ellos. Pruebe la política desde una sesión con privilegios, no solo desde una normal, antes de aprobarla.

Sin ocultación de columnas ni de resúmenes

La RLS filtra filas, pero no oculta columnas ni bloquea resultados agregados. Un analista que tenga bloqueada la visualización de registros individuales de la EU aún puede ejecutar SELECT COUNT(*) sobre la tabla sin filtrar si la RLS no se combina con restricciones de columna o de agregación. Combine la RLS con la seguridad a nivel de columna o el enmascaramiento de datos para cerrar esa brecha, y considere si las propias consultas agregadas deben gobernarse para las tablas más sensibles.

Sobrecarga de rendimiento

A cada consulta se le aplica el predicado de RLS, lo que puede ralentizar el rendimiento si la lógica del filtro es compleja o si la columna de clave no está indexada. Indexe las columnas a las que hace referencia la política y mantenga el predicado lo más simple posible. Prefiera expresiones CASE directas en lugar de subconsultas o búsquedas en tablas de mapeo dentro del filtro. Si el motor lo admite, materialice el mapeo de usuarios a filas en una tabla pequeña y bien indexada en lugar de calcularlo sobre la marcha.

Complejidad de depuración

Los conjuntos de resultados vacíos causados por la RLS se ven idénticos a "no hay datos coincidentes". Los desarrolladores que buscan una fila que falta a menudo pasan horas antes de darse cuenta de que la política la filtró. Registre la identidad del usuario efectivo y la versión de la política durante el desarrollo, ofrezca a los ingenieros una forma de confirmar si la RLS está activa cuando los resultados parezcan incorrectos y documente la política en el mismo lugar que el esquema de la tabla para que sea fácil de encontrar.

Reglas de escritura mal configuradas

Las políticas de RLS a menudo tienen dos lados: una cláusula USING que filtra lo que los usuarios pueden leer y una cláusula WITH CHECK que controla lo que pueden insertar o actualizar. Definir una sin la otra es un error clásico: el filtrado de lectura sin verificación de escritura permite a los usuarios insertar o actualizar filas que no deberían poseer. Defina siempre ambos lados cuando la tabla acepte escrituras y ejecute una prueba del lado de la escritura como parte de la revisión de la política.

Seguridad a nivel de fila en la plataforma Databricks

En la plataforma Databricks, la seguridad a nivel de fila se gestiona a través de filtros de fila en Unity Catalog, la capa de gobernanza unificada de Databricks para datos e AI. El patrón es sencillo: defina una función definida por el usuario de SQL que devuelva verdadero para las filas que un usuario determinado tiene permitido ver, luego adjúntela a la tabla de destino. El filtro se ejecuta automáticamente en el momento de la consulta, utilizando la identidad del usuario actual o el contexto de la sesión para determinar qué filas devolver.

Los filtros de fila se aplican de manera consistente en Databricks SQL, notebooks, trabajos y herramientas de BI conectadas, sin necesidad de lógica personalizada por interfaz. Funcionan junto con las máscaras de columna para un control de acceso detallado completo, y cada consulta que toca una tabla filtrada se registra en el linaje y los logs de auditoría de Unity Catalog, de modo que los equipos de gobernanza y seguridad puedan ver exactamente qué políticas se aplican a qué tablas y qué usuarios han consultado qué.

Preguntas frecuentes

¿Qué es la seguridad dinámica a nivel de fila? La RLS dinámica evalúa la regla de acceso en el momento de la consulta utilizando la identidad del usuario actual o el contexto de la sesión, por lo que la misma política devuelve resultados diferentes para diferentes usuarios. Todas las implementaciones modernas de RLS funcionan de esta manera, incluidas las políticas ABAC de Databricks, los filtros de fila y las vistas dinámicas.

¿Cuál es la diferencia entre la seguridad a nivel de fila y la seguridad a nivel de columna? La RLS restringe qué filas puede ver un usuario; la seguridad a nivel de columna restringe qué columnas, normalmente para ocultar campos sensibles como el salario o los números de Seguro Social. La mayoría de las implementaciones de producción utilizan ambas de forma conjunta.

¿Es suficiente la seguridad a nivel de fila por sí sola para proteger los datos sensibles? No. La RLS gestiona la visibilidad de las filas, pero no enmascara los valores de las columnas, no bloquea las consultas agregadas ni reemplaza la gestión de identidad y acceso. Combínela con la seguridad a nivel de columna, los permisos a nivel de tabla y el registro de auditoría como parte de una estrategia de defensa en profundidad.

How does Databricks implement row-level security? A través de Unity Catalog, con tres opciones: políticas ABAC, filtros de fila a nivel de tabla y vistas dinámicas. Se recomienda ABAC para la gobernanza a escala; los filtros de fila y las vistas dinámicas están disponibles para necesidades más personalizadas.

¿Afecta la seguridad a nivel de fila al rendimiento de las consultas? Sí, pero el impacto suele ser manejable. Mantenga la lógica de la política simple, indexe las columnas a las que hace referencia la política y prefiera las UDF de SQL sobre las UDF de Python. Analice el perfil de las consultas antes y después de los cambios en las políticas para detectar regresiones de forma temprana.

Comience con el control de acceso detallado en Databricks

La seguridad a nivel de fila es más efectiva como parte de un modelo de gobernanza más amplio que también cubre columnas, enmascaramiento, linaje y auditoría. Vea cómo Unity Catalog une la seguridad a nivel de fila, el enmascaramiento de columnas y la gobernanza unificada en la plataforma Databricks.

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original