Seguridad a nivel de fila explicada, sin código

La seguridad a nivel de fila (RLS) es una función de la base de datos que filtra automáticamente cada consulta para que cada cliente solo pueda ver sus propios datos, incluso si el código de tu aplicación tiene fallos. Defines la regla una vez, en la base de datos, y no se puede eludir. Es, sinceramente, la razón por la que duermo tranquilo.

Si estás construyendo un SaaS con IA y no eres técnico, RLS es el único concepto de seguridad que merece la pena entender de verdad. Aquí tienes qué es, por qué supera a cualquier alternativa y la lista de comprobación para dársela a tu IA.

Seguridad a nivel de fila explicada: la analogía del portero

Imagina que tu base de datos es un archivo y los registros de cada cliente son carpetas dentro de él. Sin RLS, la puerta del archivo está abierta y dependes de que cada empleado (cada pieza del código de tu aplicación) se acuerde, cada vez, de sacar solo las carpetas del cliente correcto. Un momento de despiste y alguien sale con los archivos de un competidor.

RLS pone un portero dentro del propio archivo. El portero comprueba el documento de identidad de quien pide y solo entrega físicamente las carpetas que pertenecen a su organización. Da igual que el empleado se olvide de pedir bien o que pida todo: el portero filtra lo que vuelve. Cada petición. Automáticamente. Sin excepciones.

Técnicamente: en lugar de que sea tu aplicación la que filtre los datos («muestra solo las filas de este cliente»), defines esa regla una sola vez, dentro de la base de datos, como una política. Desde ese momento, cada consulta se filtra antes de que salga ningún dato de la base de datos. Está integrada en PostgreSQL, y plataformas como Supabase la convierten en una función de primera clase.

Por qué filtrar en el código de tu app no basta

Esta es la verdad incómoda sobre la alternativa. Sin RLS, el aislamiento de datos depende de que una persona, o una IA, se acuerde de añadir «solo para este cliente» en absolutamente cada sitio donde tu producto toca datos. Cientos de sitios. Para siempre. Cada función nueva, cada arreglo rápido, cada cambio de madrugada.

Las personas se olvidan. La IA también se olvida: pídele una función de informes un martes cansado y puede consultar alegremente todo. Un ejemplo real sobre el terreno: un desarrollador olvidó filtrar por organización en un endpoint de informes. Sin RLS, habría filtrado datos de clientes a la competencia. Con RLS, la base de datos bloqueó el acceso no autorizado automáticamente. Nadie se enteró hasta la revisión de código, porque no pasó nada malo.

En seguridad esto se llama defensa en profundidad: no confíes en que una sola capa sea perfecta. El código de tu app filtra los datos (primera capa) y RLS lo hace cumplir en la base de datos (segunda capa). Si la primera capa falla (un bug, un mal prompt, una alucinación de la IA), la segunda aguanta. Esto importa el doble cuando la IA escribe la mayor parte de tu código, porque el código generado por IA falla de formas que no verás hasta que sale caro.

12 semanasTu carrera corporativa nunca fue el planSolicita plaza en el Solopreneur Accelerator.Solicitar ahora →

Los cuatro permisos que necesita cada tabla

Las políticas RLS vienen en cuatro sabores, uno por cada cosa que un usuario puede hacer con los datos. Piensa en ellas como cuatro preguntas que hace el portero:

Toda tabla que contiene datos de clientes recibe las cuatro. Ese es todo el sistema: la etiqueta organization_id en cada tabla dice quién es el propietario de cada fila; las cuatro políticas hacen que la base de datos lo imponga.

Cómo aprendí RLS (de Claude)

Seré sincero: no aprendí RLS en un curso de seguridad. Lo aprendí de Claude. Cuando empecé con Supabase, pregunté: «¿Cómo me aseguro de que los usuarios solo vean los datos de su propia organización?» Claude me explicó las políticas RLS. Las implementé en cada tabla. Ahora es automático.

Ese es el punto para los fundadores no técnicos: no escribes estas políticas a mano. Entiendes el concepto (portero en el archivo, cuatro permisos por tabla) y le das la instrucción a tu IA: «Activa la seguridad a nivel de fila en todas las tablas, con políticas para ver, crear, actualizar y eliminar, limitadas a la organización del usuario.» La IA produce las políticas; la base de datos las hace cumplir para siempre.

Mi plataforma, FIKR Space, tiene 964 tablas. Todas están protegidas de esta manera. Sin excepciones. Esa escala solo es manejable porque la regla la impone la base de datos, no mi memoria: la misma razón por la que defiendo diseñar la base de datos antes de escribir ninguna función.

La lista de comprobación de RLS del fundador

No necesitas escribir ni una línea de SQL. Necesitas insistir en cinco cosas:

1. RLS activado en cada tabla con datos de clientes. Pregúntaselo directamente a tu IA: «¿Está activada la seguridad a nivel de fila en todas las tablas? Enumera las que no.»
2. Los cuatro tipos de política por tabla: ver, crear, cambiar, eliminar. Una tabla con solo una política de lectura sigue filtrando a través de las escrituras.
3. Políticas limitadas por organización, en línea con tu configuración multi-tenant.
4. Prueba con dos cuentas. Crea dos organizaciones de prueba. Inicia sesión en una e intenta leer y editar los datos de la otra. Si te devuelve algo, para y arréglalo antes de lanzar.
5. Vuelve a comprobar tras cada tabla nueva. Haz de «activa RLS con las cuatro políticas estándar» una regla permanente que tu IA aplique a cada tabla que cree, no algo que recuerdes función por función.

El código de la app más simple es el extra: una vez que la base de datos impone el aislamiento, tus funciones no necesitan lógica de filtrado por cliente repartida por todas partes. Seguridad por defecto, menos código y dejas de preocuparte por esa consulta que alguien olvidó.

El libroThe Solopreneur RevolutionLuis Gonçalves sobre cómo crear un negocio de solopreneur con IA sin dejar tu empleo.Consigue el libro →

Preguntas frecuentes

¿Qué es la seguridad a nivel de fila en palabras sencillas?

Es una regla que defines una vez dentro de la base de datos y que filtra automáticamente cada consulta, de modo que cada usuario solo ve filas que pertenecen a su organización. Como un portero dentro del archivo: no importa quién pida ni cómo, solo salen las carpetas correctas.

¿Necesito RLS si mi aplicación ya filtra los datos?

Sí. El filtrado en la aplicación depende de que cada pieza de código, escrita por una persona o por una IA, recuerde el filtro, para siempre. RLS es la red de seguridad cuando algo se olvida: un bug en tu app ya no puede convertirse en una brecha de datos, porque la base de datos bloquea la fuga por sí misma.

¿Puedo configurar RLS sin saber SQL?

Sí. Entiende el concepto y luego dale la instrucción a tu IA: «Activa la seguridad a nivel de fila en todas las tablas, con políticas para ver, crear, actualizar y eliminar, limitadas a la organización del usuario.» Después verifica con dos cuentas de prueba que intentan leer los datos de la otra. La IA escribe las políticas; tú te quedas con la lista de comprobación.

¿RLS ralentiza mi producto?

No de forma significativa, si tus tablas están bien configuradas: la clave es tener un índice en la columna de organización que comprueban las políticas (algo que conviene incluir en las instrucciones permanentes de tu IA). Plataformas con miles de tablas protegidas funcionan exactamente con este patrón; FIKR Space ejecuta 964.