Row-Level Security, o RLS, permite aplicar reglas de acceso a nivel de fila en PostgreSQL. En entornos empresariales, su valor no depende solo de activar la funcionalidad y definir pol\u00edticas, sino de controlar que cada rol solo pueda consultar, insertar, actualizar o eliminar las filas que le corresponden.<\/p>\n\n\n\n
Despu\u00e9s de implementar RLS, comienza una fase cr\u00edtica: la validaci\u00f3n operativa. Esta revisi\u00f3n debe confirmar que las pol\u00edticas funcionan como se espera, que no existen permisos demasiado amplios, que los accesos quedan auditados y que los cambios futuros no degradan el modelo de seguridad.<\/p>\n\n\n\n
Para equipos de datos, seguridad, infraestructura y desarrollo, comprobar el RLS no deber\u00eda ser una tarea puntual. Debe formar parte del ciclo de vida de la base de datos, especialmente cuando PostgreSQL se utiliza en aplicaciones multiusuario, plataformas SaaS, entornos multi-tenant o sistemas con informaci\u00f3n sensible.<\/p>\n\n\n\n
RLS act\u00faa dentro del motor de base de datos y puede reducir la dependencia de controles aplicados exclusivamente desde la aplicaci\u00f3n. Sin embargo, esto no elimina la necesidad de revisar permisos, roles, consultas y pol\u00edticas. Una pol\u00edtica mal definida puede bloquear operaciones leg\u00edtimas o, en el escenario contrario, permitir el acceso a filas que deber\u00edan permanecer restringidas.<\/p>\n\n\n\n
En PostgreSQL, las tablas no tienen pol\u00edticas RLS por defecto. Cuando se habilita la seguridad por fila en una tabla, el acceso normal a las filas debe estar permitido por pol\u00edticas. Si no existe ninguna pol\u00edtica aplicable, el comportamiento esperado para los usuarios sujetos a RLS es restrictivo. Por este motivo, la validaci\u00f3n debe comprobar tanto los accesos permitidos como los accesos denegados.<\/p>\n\n\n\n
Adem\u00e1s, determinados perfiles pueden no quedar sujetos a RLS en condiciones espec\u00edficas, como ocurre con superusuarios, roles con atributo BYPASSRLS o propietarios de tabla salvo que se fuerce la aplicaci\u00f3n de RLS. Este punto es especialmente relevante en auditor\u00edas de seguridad, porque una prueba realizada con un rol inadecuado puede ofrecer una falsa sensaci\u00f3n de control.<\/p>\n\n\n\n
Antes de ejecutar pruebas, conviene construir un inventario claro de los elementos que intervienen en el modelo de seguridad. Este inventario debe servir como referencia para las pruebas, para la revisi\u00f3n peri\u00f3dica y para cualquier auditor\u00eda posterior.<\/p>\n\n\n\n
La revisi\u00f3n debe incluir las tablas con RLS habilitado, las pol\u00edticas asociadas, los roles a los que aplican, los permisos SQL concedidos y la relaci\u00f3n entre usuarios de aplicaci\u00f3n, roles de base de datos y atributos de sesi\u00f3n. En entornos con varios equipos o aplicaciones, este inventario evita que las reglas de seguridad queden dispersas o dependan de conocimiento no documentado.<\/p>\n\n\n\n
La prueba de RLS debe reproducir escenarios reales de acceso. No basta con ejecutar una consulta como administrador ni con comprobar un \u00fanico caso positivo. Cada pol\u00edtica debe probarse con datos representativos, roles diferenciados y casos de borde.<\/p>\n\n\n\n
Una buena pr\u00e1ctica consiste en definir una matriz de pruebas que cruce roles, operaciones y conjuntos de datos. Esta matriz permite comprobar qu\u00e9 debe poder hacer cada perfil y qu\u00e9 debe quedar bloqueado. Tambi\u00e9n ayuda a detectar diferencias entre lo que se ha definido en la pol\u00edtica y lo que realmente necesita la aplicaci\u00f3n.<\/p>\n\n\n\n
Las pruebas positivas verifican que un rol puede acceder a las filas autorizadas y ejecutar las operaciones previstas. Las pruebas negativas validan lo contrario: que ese mismo rol no puede ver, insertar, modificar o eliminar filas fuera de su \u00e1mbito.<\/p>\n\n\n\n
Ambos tipos de prueba son necesarios. En RLS, un resultado vac\u00edo puede ser correcto o puede ocultar una pol\u00edtica demasiado restrictiva. Del mismo modo, una consulta que devuelve datos puede ser leg\u00edtima o indicar un exceso de exposici\u00f3n. Por eso, cada prueba debe tener un resultado esperado documentado.<\/p>\n\n\n\n
Las pruebas deben ejecutarse con roles equivalentes a los utilizados por la aplicaci\u00f3n y por los equipos internos. Esto incluye usuarios de negocio, perfiles operativos, cuentas de servicio, administradores funcionales y roles t\u00e9cnicos con privilegios diferenciados.<\/p>\n\n\n\n
En PostgreSQL, current_user representa el identificador aplicable para la comprobaci\u00f3n de permisos. Esta diferencia es importante cuando se utilizan cambios de rol, seguridad basada en funciones o patrones en los que la aplicaci\u00f3n establece contexto de sesi\u00f3n. La validaci\u00f3n debe reflejar estos patrones para evitar resultados que no coincidan con la ejecuci\u00f3n real en producci\u00f3n.<\/p>\n\n\n\n
Los datos de prueba deben cubrir las combinaciones relevantes para la pol\u00edtica. En un modelo multi-tenant, por ejemplo, no basta con probar un tenant. Deben probarse varios tenants, usuarios sin asignaci\u00f3n, registros compartidos si existen, datos hist\u00f3ricos, cambios de estado y casos con valores nulos si la pol\u00edtica depende de columnas que pueden no estar informadas.<\/p>\n\n\n\n
Tambi\u00e9n conviene incluir escenarios de transici\u00f3n: altas de usuarios, cambios de departamento, reasignaci\u00f3n de clientes, baja de permisos, cambios de propietario l\u00f3gico y migraciones de datos. Muchos errores de RLS aparecen cuando el dato cambia de estado, no \u00fanicamente cuando se consulta en condiciones normales.<\/p>\n\n\n\n
La validaci\u00f3n posterior a la implementaci\u00f3n debe prestar atenci\u00f3n a errores habituales que pueden pasar desapercibidos en una revisi\u00f3n superficial. Algunos afectan a la disponibilidad de la aplicaci\u00f3n y otros a la confidencialidad de los datos.<\/p>\n\n\n\n
Una pol\u00edtica dise\u00f1ada para lectura no garantiza por s\u00ed sola el comportamiento correcto en inserciones o actualizaciones. Las operaciones de escritura requieren revisar cuidadosamente las condiciones USING y WITH CHECK. En particular, WITH CHECK se eval\u00faa sobre la nueva versi\u00f3n de la fila propuesta, por lo que resulta esencial para evitar que un usuario inserte o actualice datos fuera de su \u00e1mbito.}<\/p>\n\n\n\n
Los roles con privilegios elevados deben revisarse de forma separada. Superusuarios, propietarios de tabla y roles con BYPASSRLS pueden no comportarse igual que los usuarios ordinarios. En producci\u00f3n, estas cuentas deber\u00edan estar justificadas, documentadas y separadas de los roles de aplicaci\u00f3n cuando sea posible.<\/p>\n\n\n\n
RLS no sustituye al modelo de privilegios de PostgreSQL. Para que un usuario pueda ejecutar una operaci\u00f3n, necesita permisos SQL sobre el objeto y, adem\u00e1s, cumplir las pol\u00edticas de seguridad por fila aplicables. La auditor\u00eda debe revisar ambos niveles para evitar configuraciones incoherentes.<\/p>\n\n\n\n
Muchas implementaciones de RLS se apoyan en variables de sesi\u00f3n, funciones auxiliares o atributos establecidos por la aplicaci\u00f3n. Este enfoque puede ser v\u00e1lido, pero debe validarse cuidadosamente. Es necesario comprobar qu\u00e9 ocurre si el contexto no se establece, si se establece con valores incorrectos o si una conexi\u00f3n reutilizada conserva informaci\u00f3n inesperada.<\/p>\n\n\n\n
Auditar RLS implica reunir evidencias sobre las pol\u00edticas definidas, los permisos efectivos, los accesos ejecutados y los cambios realizados. El objetivo no es solo detectar incidentes, sino demostrar que el modelo de seguridad est\u00e1 bajo control y puede revisarse de forma peri\u00f3dica.<\/p>\n\n\n\n
PostgreSQL permite configurar distintos destinos y niveles de logging. En funci\u00f3n de las necesidades de la organizaci\u00f3n, estos registros pueden complementarse con mecanismos de auditor\u00eda corporativos, herramientas de observabilidad, SIEM o extensiones especializadas, siempre que est\u00e9n alineados con las pol\u00edticas internas de seguridad y privacidad.<\/p>\n\n\n\n
La vista pg_policies proporciona informaci\u00f3n \u00fatil sobre las pol\u00edticas de seguridad por fila definidas en la base de datos. Esta revisi\u00f3n puede utilizarse para comparar el estado real de PostgreSQL con la documentaci\u00f3n interna, detectar pol\u00edticas no esperadas o confirmar que las definiciones aplicadas coinciden con lo aprobado.<\/p>\n\n\n\n
Para auditor\u00eda operativa, conviene revisar qu\u00e9 operaciones deben registrarse, durante cu\u00e1nto tiempo y con qu\u00e9 nivel de detalle. Registrar todo sin criterio puede generar ruido y costes innecesarios; registrar demasiado poco puede impedir reconstruir un incidente. La decisi\u00f3n debe equilibrar seguridad, rendimiento, privacidad y requisitos regulatorios.<\/p>\n\n\n\n
En organizaciones con varios equipos, aplicaciones o unidades de negocio, la validaci\u00f3n de RLS debe contemplar la complejidad real del modelo de permisos. No siempre existe una correspondencia directa entre un usuario humano y un rol de base de datos. Puede haber roles heredados, cuentas compartidas de aplicaci\u00f3n, perfiles de soporte, administradores funcionales y servicios automatizados.<\/p>\n\n\n\n
Por este motivo, la validaci\u00f3n debe documentar qui\u00e9n act\u00faa, con qu\u00e9 rol, bajo qu\u00e9 contexto y sobre qu\u00e9 datos. Tambi\u00e9n debe identificar qu\u00e9 controles se aplican en la aplicaci\u00f3n, cu\u00e1les se aplican en PostgreSQL y qu\u00e9 ocurre si una capa no act\u00faa como se esperaba.<\/p>\n\n\n\n
Cuando RLS protege datos cr\u00edticos, las pruebas no deber\u00edan depender \u00fanicamente de comprobaciones manuales. Es recomendable incorporar validaciones automatizadas en los procesos de integraci\u00f3n, despliegue y revisi\u00f3n de cambios de base de datos.<\/p>\n\n\n\n
Estas pruebas pueden ejecutarse tras cambios en pol\u00edticas, migraciones, modificaciones de roles, nuevas funcionalidades de la aplicaci\u00f3n o cambios en la l\u00f3gica de pertenencia de usuarios y datos. La automatizaci\u00f3n ayuda a detectar regresiones antes de que lleguen a producci\u00f3n.<\/p>\n\n\n\n
Las pol\u00edticas RLS deben gestionarse como parte del gobierno de cambios de la base de datos. Cada modificaci\u00f3n deber\u00eda tener una justificaci\u00f3n funcional, una revisi\u00f3n t\u00e9cnica y una prueba asociada. Esto es especialmente importante cuando se a\u00f1aden columnas utilizadas en pol\u00edticas, se modifican relaciones entre tablas o se cambian reglas de segmentaci\u00f3n de datos.<\/p>\n\n\n\n
La documentaci\u00f3n debe mantenerse sincronizada con el estado real de PostgreSQL. Una pol\u00edtica obsoleta puede ser tan problem\u00e1tica como una pol\u00edtica ausente, porque dificulta la auditor\u00eda y aumenta el riesgo de decisiones incorrectas durante futuras modificaciones.<\/p>\n\n\n\n
Una operaci\u00f3n segura de RLS combina dise\u00f1o, pruebas, auditor\u00eda y disciplina de mantenimiento. En producci\u00f3n, las siguientes pr\u00e1cticas ayudan a reducir errores y a mantener la trazabilidad del modelo de seguridad.<\/p>\n\n\n\n
RLS en PostgreSQL puede ser una pieza muy relevante dentro de una estrategia de seguridad de datos, pero su eficacia depende de una validaci\u00f3n rigurosa despu\u00e9s de la implementaci\u00f3n. Probar solo los casos b\u00e1sicos no es suficiente cuando existen distintos roles, permisos heredados, cuentas t\u00e9cnicas y reglas de negocio cambiantes.<\/p>\n\n\n\n
La combinaci\u00f3n de inventario, matriz de pruebas, auditor\u00eda de accesos, revisi\u00f3n de pol\u00edticas, automatizaci\u00f3n y gobierno del cambio permite mantener un modelo de seguridad por fila m\u00e1s controlado y sostenible. Para entornos empresariales, este enfoque reduce el riesgo de errores de configuraci\u00f3n y facilita demostrar que los accesos a los datos se gestionan con criterios verificables.<\/p>\n\n\n\n