RLS en PostgreSQL: cómo probar, auditar y validar políticas de seguridad por fila

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íticas, sino de controlar que cada rol solo pueda consultar, insertar, actualizar o eliminar las filas que le corresponden.

Después de implementar RLS, comienza una fase crítica: la validación operativa. Esta revisión debe confirmar que las políticas 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.

Para equipos de datos, seguridad, infraestructura y desarrollo, comprobar el RLS no debería 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ón sensible.

Por qué validar RLS después de la implementación

RLS actúa dentro del motor de base de datos y puede reducir la dependencia de controles aplicados exclusivamente desde la aplicación. Sin embargo, esto no elimina la necesidad de revisar permisos, roles, consultas y políticas. Una política mal definida puede bloquear operaciones legítimas o, en el escenario contrario, permitir el acceso a filas que deberían permanecer restringidas.

En PostgreSQL, las tablas no tienen políticas RLS por defecto. Cuando se habilita la seguridad por fila en una tabla, el acceso normal a las filas debe estar permitido por políticas. Si no existe ninguna política aplicable, el comportamiento esperado para los usuarios sujetos a RLS es restrictivo. Por este motivo, la validación debe comprobar tanto los accesos permitidos como los accesos denegados.

Además, determinados perfiles pueden no quedar sujetos a RLS en condiciones específicas, como ocurre con superusuarios, roles con atributo BYPASSRLS o propietarios de tabla salvo que se fuerce la aplicación de RLS. Este punto es especialmente relevante en auditorías de seguridad, porque una prueba realizada con un rol inadecuado puede ofrecer una falsa sensación de control.

Objetivos de una validación empresarial de RLS

• Confirmar que cada rol accede solo a las filas previstas.
• Validar por separado las operaciones SELECT, INSERT, UPDATE y DELETE.
• Detectar políticas demasiado permisivas, contradictorias o incompletas.
• Comprobar que los propietarios, roles técnicos y cuentas de servicio no introducen excepciones no documentadas.
• Revisar que las políticas siguen siendo coherentes tras cambios de esquema, nuevas columnas, nuevas tablas o cambios en la lógica de negocio.
• Asegurar que existen evidencias suficientes para auditoría y cumplimiento interno.

Inventario inicial: tablas, roles, políticas y permisos

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ón periódica y para cualquier auditoría posterior.

La revisión debe incluir las tablas con RLS habilitado, las políticas asociadas, los roles a los que aplican, los permisos SQL concedidos y la relación entre usuarios de aplicación, roles de base de datos y atributos de sesión. En entornos con varios equipos o aplicaciones, este inventario evita que las reglas de seguridad queden dispersas o dependan de conocimiento no documentado.

Elementos que conviene revisar

• Tablas con RLS habilitado y tablas que deberían tenerlo habilitado.
• Políticas definidas mediante CREATE POLICY o modificadas posteriormente.
• Uso de expresiones USING para controlar qué filas pueden consultarse o modificarse.
• Uso de expresiones WITH CHECK para validar las filas nuevas o modificadas en operaciones INSERT y UPDATE.
• Roles incluidos explícitamente en cada política y roles que acceden a través de herencia o membresía.
• Privilegios concedidos sobre tablas, vistas, secuencias y funciones relacionadas.
• Cuentas técnicas, propietarios de objetos y usuarios con privilegios elevados.

Cómo probar políticas RLS de forma sistemática

La prueba de RLS debe reproducir escenarios reales de acceso. No basta con ejecutar una consulta como administrador ni con comprobar un único caso positivo. Cada política debe probarse con datos representativos, roles diferenciados y casos de borde.

Una buena práctica consiste en definir una matriz de pruebas que cruce roles, operaciones y conjuntos de datos. Esta matriz permite comprobar qué debe poder hacer cada perfil y qué debe quedar bloqueado. También ayuda a detectar diferencias entre lo que se ha definido en la política y lo que realmente necesita la aplicación.

Pruebas positivas y negativas

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 ámbito.

Ambos tipos de prueba son necesarios. En RLS, un resultado vacío puede ser correcto o puede ocultar una política demasiado restrictiva. Del mismo modo, una consulta que devuelve datos puede ser legítima o indicar un exceso de exposición. Por eso, cada prueba debe tener un resultado esperado documentado.

• SELECT: comprobar qué filas son visibles para cada rol.
• INSERT: validar que el rol solo puede crear filas dentro de su ámbito autorizado.
• UPDATE: comprobar tanto la selección de filas modificables como las condiciones aplicadas a los nuevos valores.
• DELETE: verificar que solo pueden eliminarse las filas permitidas por la política correspondiente.

Uso de roles de prueba representativos

Las pruebas deben ejecutarse con roles equivalentes a los utilizados por la aplicación y por los equipos internos. Esto incluye usuarios de negocio, perfiles operativos, cuentas de servicio, administradores funcionales y roles técnicos con privilegios diferenciados.

En PostgreSQL, current_user representa el identificador aplicable para la comprobación de permisos. Esta diferencia es importante cuando se utilizan cambios de rol, seguridad basada en funciones o patrones en los que la aplicación establece contexto de sesión. La validación debe reflejar estos patrones para evitar resultados que no coincidan con la ejecución real en producción.

Datos de prueba y escenarios de borde

Los datos de prueba deben cubrir las combinaciones relevantes para la política. En un modelo multi-tenant, por ejemplo, no basta con probar un tenant. Deben probarse varios tenants, usuarios sin asignación, registros compartidos si existen, datos históricos, cambios de estado y casos con valores nulos si la política depende de columnas que pueden no estar informadas.

También conviene incluir escenarios de transición: altas de usuarios, cambios de departamento, reasignación de clientes, baja de permisos, cambios de propietario lógico y migraciones de datos. Muchos errores de RLS aparecen cuando el dato cambia de estado, no únicamente cuando se consulta en condiciones normales.

Errores frecuentes de configuración en RLS

La validación posterior a la implementación debe prestar atención a errores habituales que pueden pasar desapercibidos en una revisión superficial. Algunos afectan a la disponibilidad de la aplicación y otros a la confidencialidad de los datos.

Políticas incompletas por operación

Una política diseñada para lectura no garantiza por sí 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úa sobre la nueva versión de la fila propuesta, por lo que resulta esencial para evitar que un usuario inserte o actualice datos fuera de su ámbito.}

Roles con privilegios excesivos

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ón, estas cuentas deberían estar justificadas, documentadas y separadas de los roles de aplicación cuando sea posible.

Confusión entre permisos SQL y políticas RLS

RLS no sustituye al modelo de privilegios de PostgreSQL. Para que un usuario pueda ejecutar una operación, necesita permisos SQL sobre el objeto y, además, cumplir las políticas de seguridad por fila aplicables. La auditoría debe revisar ambos niveles para evitar configuraciones incoherentes.

Dependencia excesiva del contexto de sesión

Muchas implementaciones de RLS se apoyan en variables de sesión, funciones auxiliares o atributos establecidos por la aplicación. Este enfoque puede ser válido, pero debe validarse cuidadosamente. Es necesario comprobar qué ocurre si el contexto no se establece, si se establece con valores incorrectos o si una conexión reutilizada conserva información inesperada.

Auditoría de accesos y evidencias de seguridad

Auditar RLS implica reunir evidencias sobre las políticas 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á bajo control y puede revisarse de forma periódica.

PostgreSQL permite configurar distintos destinos y niveles de logging. En función de las necesidades de la organización, estos registros pueden complementarse con mecanismos de auditoría corporativos, herramientas de observabilidad, SIEM o extensiones especializadas, siempre que estén alineados con las políticas internas de seguridad y privacidad.

Qué evidencias conviene conservar

• Listado de políticas activas por tabla y su definición.
• Histórico de cambios sobre políticas, roles y permisos.
• Resultados de pruebas por rol, operación y escenario.
• Registros de acceso relevantes para operaciones sensibles.
• Evidencia de revisiones periódicas y aprobación de cambios.
• Relación entre controles de aplicación y controles en base de datos.

Revisión de pg_policies y catálogos del sistema

La vista pg_policies proporciona información útil sobre las políticas de seguridad por fila definidas en la base de datos. Esta revisión puede utilizarse para comparar el estado real de PostgreSQL con la documentación interna, detectar políticas no esperadas o confirmar que las definiciones aplicadas coinciden con lo aprobado.

Registro de accesos y cambios

Para auditoría operativa, conviene revisar qué operaciones deben registrarse, durante cuánto tiempo y con qué nivel de detalle. Registrar todo sin criterio puede generar ruido y costes innecesarios; registrar demasiado poco puede impedir reconstruir un incidente. La decisión debe equilibrar seguridad, rendimiento, privacidad y requisitos regulatorios.

Validación en entornos empresariales con múltiples roles

En organizaciones con varios equipos, aplicaciones o unidades de negocio, la validación 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ón, perfiles de soporte, administradores funcionales y servicios automatizados.

Por este motivo, la validación debe documentar quién actúa, con qué rol, bajo qué contexto y sobre qué datos. También debe identificar qué controles se aplican en la aplicación, cuáles se aplican en PostgreSQL y qué ocurre si una capa no actúa como se esperaba.

Matriz de validación recomendada

• Rol o perfil funcional.
• Objeto de base de datos afectado.
• Operación permitida o denegada.
• Condición de negocio que justifica el acceso.
• Datos de prueba utilizados.
• Resultado esperado.
• Resultado obtenido.
• Evidencia asociada y fecha de revisión.

Automatización de pruebas RLS

Cuando RLS protege datos críticos, las pruebas no deberían depender únicamente de comprobaciones manuales. Es recomendable incorporar validaciones automatizadas en los procesos de integración, despliegue y revisión de cambios de base de datos.

Estas pruebas pueden ejecutarse tras cambios en políticas, migraciones, modificaciones de roles, nuevas funcionalidades de la aplicación o cambios en la lógica de pertenencia de usuarios y datos. La automatización ayuda a detectar regresiones antes de que lleguen a producción.

Buenas prácticas para automatizar

• Definir conjuntos de datos de prueba que representen escenarios reales y casos límite.
• Ejecutar pruebas con roles diferenciados, no solo con un usuario administrador.
• Validar explícitamente resultados permitidos y denegados.
• Incluir pruebas para INSERT, UPDATE y DELETE, además de SELECT.
• Comparar el resultado de las políticas con una matriz de permisos aprobada.
• Bloquear despliegues cuando una política devuelva más filas de las esperadas.

Gobierno del cambio y mantenimiento de políticas

Las políticas RLS deben gestionarse como parte del gobierno de cambios de la base de datos. Cada modificación debería tener una justificación funcional, una revisión técnica y una prueba asociada. Esto es especialmente importante cuando se añaden columnas utilizadas en políticas, se modifican relaciones entre tablas o se cambian reglas de segmentación de datos.

La documentación debe mantenerse sincronizada con el estado real de PostgreSQL. Una política obsoleta puede ser tan problemática como una política ausente, porque dificulta la auditoría y aumenta el riesgo de decisiones incorrectas durante futuras modificaciones.

Revisiones periódicas recomendadas

• Comprobar que las políticas activas siguen respondiendo a las reglas de negocio vigentes.
• Revisar roles sin uso, permisos heredados y cuentas técnicas antiguas.
• Confirmar que las excepciones están documentadas y aprobadas.
• Validar que las pruebas automatizadas cubren las políticas críticas.
• Revisar el impacto de nuevas versiones, migraciones o rediseños de aplicación.

Buenas prácticas operativas para RLS en producción

Una operación segura de RLS combina diseño, pruebas, auditoría y disciplina de mantenimiento. En producción, las siguientes prácticas ayudan a reducir errores y a mantener la trazabilidad del modelo de seguridad.

• Aplicar el principio de mínimo privilegio en roles y permisos SQL.
• Separar roles de administración, aplicación, soporte y auditoría.
• Evitar realizar pruebas de seguridad con superusuarios o propietarios de tabla si el objetivo es validar el comportamiento de usuarios ordinarios.
• Documentar cada política con su propósito, roles afectados y regla de negocio asociada.
• Usar nombres de políticas claros y consistentes.
• Mantener pruebas de regresión para cambios en políticas y permisos.
• Revisar periódicamente las políticas mediante vistas y catálogos del sistema.
• Controlar los cambios mediante revisión, versionado y despliegues trazables.
• Alinear el logging y la auditoría con los requisitos internos de seguridad y cumplimiento.

¿Por qué considerar RLS en PostgreSQL?

RLS en PostgreSQL puede ser una pieza muy relevante dentro de una estrategia de seguridad de datos, pero su eficacia depende de una validación rigurosa después de la implementación. Probar solo los casos básicos no es suficiente cuando existen distintos roles, permisos heredados, cuentas técnicas y reglas de negocio cambiantes.

La combinación de inventario, matriz de pruebas, auditoría de accesos, revisión de políticas, automatización y gobierno del cambio permite mantener un modelo de seguridad por fila más controlado y sostenible. Para entornos empresariales, este enfoque reduce el riesgo de errores de configuración y facilita demostrar que los accesos a los datos se gestionan con criterios verificables.

Preguntas frecuentes sobre RLS en PostgreSQL

Para su empresa es vital validar políticas RLS en PostgreSQL con un enfoque seguro, trazable y adaptado a sus requisitos de negocio.

Contacte con el equipo de Hopla! y analice el siguiente paso para reforzar la seguridad de sus datos.