Row Level Security (RLS)

En una plataforma que atiende a muchas organizaciones sobre infraestructura común, lo que impide que los datos de una lleguen a otra no debería ser que la aplicación se acuerde de agregar un filtro. Ese modelo funciona hasta el día en que alguien escribe un endpoint nuevo y omite una cláusula, que es un error humano ordinario con una consecuencia desproporcionada.

RLS mueve la garantía al motor. Cada tabla lleva políticas que el propio motor evalúa antes de devolver una fila. En modo forzado —la variante que importa— ni siquiera el propietario de la tabla evade esas políticas, lo que obliga a una condición que suele olvidarse: el rol con el que la aplicación se conecta no debe ser propietario de ninguna tabla, y las migraciones deben correr con un rol distinto. Sin esa separación, el modo forzado no protege nada.

Dos detalles de implementación deciden si el control es real. Las políticas se definen por operación, con verificación explícita en las de escritura: sin eso se puede insertar una fila atribuida a otra organización, con la lectura protegida y la escritura no. Y el identificador de organización se fija por transacción, como parámetro y nunca por interpolación de texto, de modo que una consulta sin ese contexto devuelva cero filas en lugar de todas.

El comportamiento por defecto es lo que hace verificable el diseño: un olvido produce un resultado vacío, no una fuga. Una batería de pruebas dedicada a intentar cruzar la separación —dos organizaciones sintéticas recorriendo cada punto de acceso— es lo que confirma que sigue siendo cierto después de cada cambio.