CAPÍTULO 8 · La base de datos también tiene fronteras
Comprobar el permiso donde realmente se aplica
Con las cuentas creadas y las conexiones organizadas, es momento de dejar de suponer. Un nombre como readonly no demuestra que una cuenta sea de solo lectura. Necesitamos entrar con esa identidad y observar qué sucede al intentar las operaciones que su responsabilidad permite y las que debería rechazar.
Usamos psql para comprobar destino, conexión segura e identidad efectiva. Consultamos lo necesario para entender permisos y ensayamos acciones bajo cada rol. Las pruebas se realizan en un contexto controlado: la intención es verificar el acuerdo, no provocar daños para demostrar que una cuenta tiene demasiado poder.
Ya contamos con evidencia de acceso y de rechazo. Sin embargo, proteger quién modifica los datos no elimina fallos de aplicación, errores humanos o incidentes de infraestructura. Para completar la preparación necesitamos responder una pregunta más difícil: si perdemos el estado esperado, ¿sabemos reconstruirlo?
Leer esta parte dentro del relato completo →DEL RELATO A LA PRÁCTICA
Vamos a desarrollar esta decisión con su mapa, explicación, código y ejercicio.
MIRA · CONECTA · COMPRENDE
Verificar destino antes de operar
Las flechas resumen el recorrido conceptual. Los controles y dependencias se detallan debajo.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- psql + TLS. Conecta al servidor verificado
- Identidad efectiva. Usuario y rol actuales
- Inspección. ACL, defaults y propietarios
- Pruebas. Acciones permitidas y denegadas
01 / EL PROBLEMA
¿Para qué sirve?
Antes de diagnosticar un GRANT, necesitas saber a qué base y como qué usuario te conectaste. Una conexión correcta no demuestra que los permisos estén bien diseñados.
02 / COMPRENDER
El concepto, explicado
psql es un cliente de PostgreSQL. La cadena de conexión combina host, puerto, base, usuario y modo TLS. Los ejemplos deben usar marcadores o valores del laboratorio, nunca contraseñas en el historial.
sslmode=require exige cifrado, pero no expresa por sí solo toda la verificación de nombre y CA. Para verificar identidad del servidor configura verify-full y certificados de confianza compatibles con tu proveedor.
session_user identifica quien abrió sesión; current_user puede cambiar con SET ROLE. Esa diferencia explica quién crea objetos y cuáles defaults se aplican.
La comprobación completa combina inventario, privilegios efectivos y pruebas en conexiones reales. Una cuenta readonly no garantiza aislamiento de filas; usa vistas o RLS cuando el dominio lo requiera, con sus políticas y pruebas.
03 / CONSTRUIR
Implementación paso a paso
- Instala un cliente compatible y obtén hostname/CA desde configuración oficial.
- Conecta con TLS y prompt de contraseña o mecanismo de identidad establecido.
- Ejecuta conninfo y consulta base, usuario y versión.
- Inspecciona roles, ACL, defaults y propietarios.
- Prueba consulta, escritura y DDL sobre una tabla de laboratorio con cada identidad.
- Registra resultados, realiza el cierre temporal y comprueba configuración del runtime.
04 / APLICAR
Ejemplo en SensorHub
# PowerShell o terminal: adapta ruta de CA y parámetros del laboratorio.
psql "host=<HOST_POSTGRES> port=5432 dbname=sh_prod user=sh_support sslmode=verify-full sslrootcert=<CA_FILE>" -W
-- Ya dentro de psql:
\conninfo
SELECT current_database(), session_user, current_user, version();
\du
\dp public.*
\ddp
SELECT has_database_privilege('sh_support', 'sh_prod', 'CONNECT');
SELECT has_schema_privilege('sh_support', 'public', 'CREATE');
-- Sobre una tabla de laboratorio existente:
SELECT has_table_privilege('sh_support', 'public.permission_probe', 'SELECT');
SELECT has_table_privilege('sh_support', 'public.permission_probe', 'UPDATE');Cómo leer el ejemplo
- El primer comando va en terminal; las líneas posteriores van dentro de psql.
- -W pide contraseña sin incluirla en la cadena; adapta el flujo si usas tokens Entra.
- permission_probe debe existir antes de consultar sus privilegios.
- Inventario de roles no contiene secretos, pero maneja el resultado como información operativa.
Error habitual
Diagnosticar permisos en la base postgres cuando Django usa otra, o publicar una captura con cadena que contiene password.
05 / PRACTICAR
Tu turno
El lector consulta mediciones y falla al insertar. El runtime inserta y falla al crear tabla. ¿Qué prueba falta?
Ver solución orientativa
Comprueba el migrador sobre una tabla nueva, propietario/defaults y runtime tras esa migración; prueba que la cuenta DEV no entra a PROD. Agrega lector contra UPDATE y nextval, según objetos usados.
06 / VERIFICAR
Cómo sabes que funciona
- Base y usuario efectivo quedan documentados.
- TLS verifica el destino según la configuración elegida.
- Las pruebas negativas fallan por el permiso esperado.
- La conexión del runtime conserva su rol mínimo.
Para profundizar
Documentación oficial para comprobar configuración, permisos y condiciones vigentes. Revisión del tema: 2026-10-11.
CONTINUAR LA EXPERIENCIA
El siguiente paso del recorrido:
Backup y restauración ensayada con pgAdmin →Continuar en modo relato