PostgreSQL RLS en APIs: permisos por fila y prueba
Guía técnica para usar Row-Level Security con roles, JWT y PostgREST sin perder auditoría, costos, backup ni prueba de salida.
Una política RLS decide qué fila puede leer o cambiar cada usuario antes de que la API devuelva datos. En PostgreSQL 17, Row-Level Security suma reglas por rol, comando y expresión booleana; PostgREST puede autenticar pedidos y dejar que la base autorice acciones. Esta guía explica el flujo para padrones, cuotas, tickets o legajos con permisos por fila, auditoría y restauración probada.
Dónde aparece el permiso por fila
La cifra que ordena la decisión viene de Stack Overflow 2025: SQL aparece con 58,6 % entre lenguajes usados y PostgreSQL con 55,6 % entre bases de datos. Para una pyme o colegio profesional que ya guarda socios, cuotas o expedientes en tablas, el permiso puede vivir cerca del dato y reducir reglas duplicadas en la aplicación. La fila sensible necesita dueño escrito. PostgreSQL documenta que las políticas RLS restringen qué filas se devuelven o modifican por usuario. Al habilitar RLS en una tabla, el acceso normal debe pasar por una política; si no hay política, aplica denegación por defecto. Los roles administran usuarios, grupos, objetos y privilegios, y PostgREST autentica el pedido para que la base autorice la acción final.
Cómo funciona por dentro
El flujo empieza en identidad. Keycloak recibe usuario, contraseña o doble factor y entrega un token JWT con identificador, grupos y atributos. Keycloak administra realms, clientes y mapeos; si falla, la señal aparece como login rechazado o token sin grupo. El segundo paso entra por la API. PostgREST recibe el token, verifica firma y fecha, extrae el rol y se conecta a PostgreSQL con un rol autenticador de privilegios limitados. PostgREST entrega respuestas REST a partir de tablas, vistas y funciones; su trabajo es autenticar la solicitud y pasar contexto seguro a la base. El tercer paso autoriza en PostgreSQL. La base guarda registros estructurados, usuarios, estados y auditoría. Los roles llamados "matriculado", "administración" o "auditoría" reciben permisos sobre vistas y funciones. RLS agrega la condición por fila: un matriculado ve su legajo, administración ve su cartera asignada y auditoría lee sin editar. El cuarto paso registra cambios. Una función de escritura valida estado, usuario y motivo; después agrega evento en una tabla de auditoría. El quinto paso muestra consulta: la API devuelve sólo filas permitidas y oculta las demás. El sexto paso respalda: base, configuración de roles, políticas, migraciones y secretos se copian con una rutina documentada. La prueba restaura todo y ejecuta tres usuarios con resultados distintos.
Qué se instala o configura primero
La pila inicial usa PostgreSQL 17, migraciones SQL versionadas, PostgREST 14, Keycloak, proxy HTTPS, logs, backup con WAL y tablero de errores. Con dólar oficial vendedor de $ 1.495, un servidor de USD 22 a USD 55 por mes equivale a $ 32.890 a $ 82.225 mensuales. Una implementación de USD 900 a USD 1.900 queda entre $ 1,35 y $ 2,84 millones. Incluye dos tablas sensibles, tres roles, cuatro políticas, endpoint de lectura, endpoint de cambio controlado, auditoría y restauración. No incluye rediseño completo de la aplicación ni migración histórica masiva. UMSA suele empezar con una entidad concreta: cuotas de matriculados, tickets por cliente o legajos por sede. El primer entregable verificable es abrir la misma URL con tres usuarios y recibir tres conjuntos de filas. El objeto concreto es una credencial con matrícula impresa. Ese número debe llegar al token, entrar a la base y filtrar filas sin copiar reglas en cinco pantallas distintas. La capacitación termina con una prueba incómoda. Un usuario intenta leer un legajo ajeno, otro corrige un dato propio y auditoría revisa ambos eventos. El resultado esperado es rechazo, cambio registrado y consulta de auditoría sin permiso de edición. También conviene separar ambiente de prueba y producción. La señal de madurez aparece cuando una migración agrega una política, la prueba la ejecuta con usuarios ficticios y recién después se aplica sobre datos reales.
Dónde se rompe y cómo probarlo
El primer riesgo es usar el rol dueño de tabla desde la API. La señal aparece cuando una consulta salta políticas. La prueba conecta con el rol de aplicación, intenta leer una fila ajena y exige cero resultados. El segundo riesgo es token sin atributo útil. La señal aparece cuando todos los usuarios caen en el mismo rol. La prueba emite dos tokens con grupos distintos y revisa que PostgreSQL reciba variables separadas. El tercer riesgo es política incompleta para escritura. La señal aparece cuando un usuario puede editar una fila que no puede leer. La prueba ejecuta SELECT, UPDATE e INSERT con el mismo caso y compara resultado. El cuarto riesgo es backup sin migraciones. La prueba restaura base, políticas, roles, funciones, secretos rotados y configuración de PostgREST. Un permiso por fila funciona cuando el rechazo también deja evidencia.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.