Durante años, el acceso a datos en sistemas como PostgreSQL siguió un modelo relativamente claro: conexión directa mediante string, autenticación por usuario/contraseña, control de privilegios con GRANT y, en muchos casos, protección adicional mediante firewall o red privada.
El perímetro era la red.
La seguridad era principalmente binaria: dentro o fuera.
Hoy ese paradigma ha evolucionado. En arquitecturas modernas orientadas a la nube, los datos ya no son accedidos únicamente mediante conexiones internas, sino también a través de APIs HTTP siguiendo principios API First. Esto cambia radicalmente el modelo de exposición y, por tanto, el modelo de seguridad.
PostgreSQL expuesto como API: el papel de PostgREST
PostgreSQL no expone una API REST de forma nativa. Sin embargo, herramientas como PostgREST permiten convertir un esquema de base de datos en un endpoint REST automáticamente.
La guía de implementación la encuentras en >> https://docs.postgrest.org/en/v14/tutorials/tut0.html
Arquitectura simplificada:
Cliente → API REST → PostgreSQL
En este modelo, las tablas pueden consultarse mediante endpoints HTTP. Esto introduce una nueva necesidad: no basta con permisos a nivel de tabla. Se requiere control granular a nivel de fila.
Aquí entra en juego Row Level Security (RLS).
RLS: de control perimetral a control por flujo
RLS en PostgreSQL permite definir políticas que filtran filas según el usuario o contexto de ejecución.
Ejemplo básico:
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY user_can_view_own_orders
ON orders
FOR SELECT
USING (user_id = current_setting('request.jwt.claim.sub')::uuid);
Con esta política:
- La tabla está accesible.
- El usuario solo ve sus propias filas.
- No es necesario modificar cada consulta manualmente.
El motor impone la regla.
Este modelo representa un cambio conceptual:
Seguridad tradicional → valla perimetral
RLS → tubería de acceso regulada dinámicamente
Supabase como implementación integrada
Plataformas como Supabase integran PostgreSQL con PostgREST y autenticación JWT. La exposición vía API puede activarse o desactivarse, permitiendo decidir si el acceso será únicamente por conexión directa o también mediante endpoints REST.
Cuando la API está habilitada, el flujo es:
Cliente → JWT → REST endpoint → PostgreSQL (con RLS)
Sin políticas RLS adecuadas, la exposición sería amplia. Con RLS, el acceso se convierte en declarativo y controlado.
RLS más allá de la base: capa semántica y datasets
La seguridad no termina en la base transaccional. En plataformas analíticas como:
- Power BI
- Google BigQuery
- Looker
la seguridad puede aplicarse en la capa de modelo o dataset.
Puedes mirar:
- Power BI Row-Level Security (RLS): A Comprehensive Tutorial.
- Implementa la segmentación a nivel de la fila para el contenido de Looker incorporado.
- Row-level security (Microsoft Azure).
Aquí el enfoque cambia:
- En la base: se filtran filas físicas.
- En el modelo semántico: se restringen dimensiones, métricas o incluso objetos completos (OLS – Object Level Security).
Ejemplo conceptual en un modelo analítico:
- Ventas ve solo su región.
- Finanzas ve todas las regiones.
- Dirección ve agregados, no detalle transaccional.
Este control puede aplicarse sin modificar la fuente subyacente, actuando como una segunda capa de protección.
Seguridad por capas: defensa en profundidad
En entornos cloud y arquitecturas de microservicios, la seguridad suele distribuirse en múltiples niveles:
- IAM (Identity and Access Management)
- RLS en base de datos
- Políticas en API
- Seguridad en modelo semántico
- Restricciones en frontend
Esto responde a principios modernos como:
- Zero Trust (no confiar por ubicación de red)
- Deny by default (negar todo salvo lo explícitamente permitido)
En lugar de preguntar “¿está dentro de la red?”, el sistema pregunta:
¿Quién es este actor y qué subconjunto de datos le corresponde?
Ejemplo combinado: API + RLS
Supongamos una tabla multi-tenant:
CREATE TABLE invoices (
id uuid primary key,
tenant_id uuid not null,
amount numeric,
created_at timestamp
);
Activamos RLS:
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation
ON invoices
FOR ALL
USING (tenant_id = current_setting('app.current_tenant')::uuid);
En la capa API:
- El JWT contiene el tenant_id.
- El middleware establece
app.current_tenant. - PostgreSQL aplica el filtro automáticamente.
Resultado: aislamiento fuerte entre tenants sin lógica duplicada en cada servicio.
Implicaciones en la nube moderna
En entornos de microservicios y plataformas cloud:
- Los servicios hablan entre sí mediante tokens.
- Las bases pueden estar expuestas como APIs.
- Los datos pueden circular por múltiples capas analíticas.
RLS se convierte en un mecanismo estructural, no accesorio.
No reemplaza IAM.
No reemplaza la seguridad de red.
Complementa ambos.
La seguridad deja de ser un períímetro estático y se convierte en un conjunto de reglas declarativas que acompañan al dato a lo largo de su ciclo de vida.
La evolución desde acceso directo a base de datos hacia modelos API First obliga a repensar la seguridad. RLS no es simplemente una característica avanzada del motor, sino un principio de diseño alineado con:
- Identidad como perímetro
- Deny by default
- Microservicios
- Zero Trust
- Analítica segura
Aplicado correctamente, RLS permite que cada capa —base, API, modelo semántico— regule el flujo de datos con precisión matemática.
En sistemas modernos, la pregunta ya no es solo “¿quién puede conectarse?”, sino “¿qué subconjunto exacto del universo de datos puede ver este actor en este contexto?”.
Esa diferencia define la arquitectura contemporánea de datos.
Ser arquitecto de datos no es “saber bases”, es entender el ciclo de vida completo del dato.
Desde que nace…
hasta que alguien lo visualiza en un dashboard…
pasando por transformaciones, agregaciones, caches, APIs, exportaciones, notebooks y modelos ML.
Y en cada salto, la pregunta no es solo “¿funciona?”. Es: “¿Sigue protegido conforme a su contexto original?”
Y atención al villano silencioso del ecosistema moderno de datos: Nada destruye más rápido una arquitectura elegante de RLS + IAM + Zero Trust que el inocente botón:
“ahora descarga los datos como CSV para continuar con el análisis”
Este video te explica la transición desde la seguridad perimetral tradicional hacia un modelo de acceso basado en APIs, donde el control de datos debe ser más preciso:
Save as PDFAbout the Author
