CAPÍTULO 8 · La base de datos también tiene fronteras
Cada tarea recibe una cuenta acorde con su trabajo
El proceso web necesita consultar y modificar ciertos datos, pero normalmente no necesita ser dueño del esquema. Aplicar una migración es otra responsabilidad, y revisar información para soporte tampoco debería exigir todos los permisos del runtime. Una cuenta compartida oculta esas diferencias y dificulta retirarle acceso a alguien sin afectar al resto.
Diseñamos roles para ejecución, migración y consulta, distinguiendo las identidades que conectan de los grupos de privilegios. La cuenta usada por Django recibe el alcance que necesita para sus operaciones. La migración dispone de otro contexto, controlado durante la entrega. La administración queda reservada para tareas que realmente la requieren.
Con esa separación podemos probar permisos por función. Pero una cuenta correctamente limitada todavía puede apuntar a la base equivocada. La distinción entre desarrollo y producción que establecimos en settings debe reflejarse también en los destinos y datos que utiliza cada entorno.
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
Cada oficio tiene su llave
Las flechas muestran responsabilidades relacionadas; no representan un orden obligatorio de ejecución.
Selecciona una pieza para destacar su responsabilidad.
Leer la explicación del mapa
- Base de datos. Objetos y propietarios
- Runtime. Opera datos concedidos
- Migrador. Controla estructura autorizada
- Lector. Consulta sin DML ni DDL
01 / EL PROBLEMA
¿Para qué sirve?
Las tareas de una aplicación web, un migrador y un analista necesitan poderes diferentes. Compartir la misma cuenta borra esa separación y su trazabilidad.
02 / COMPRENDER
El concepto, explicado
En PostgreSQL una cuenta es un rol con LOGIN; un rol NOLOGIN puede agrupar permisos. Sus miembros reciben capacidades según membresía y reglas de herencia de la versión utilizada.
El runtime recibe lo necesario para operar datos. El migrador necesita controlar la estructura y normalmente ser propietario de los objetos que modifica. Un GRANT de escritura no otorga por sí solo ALTER TABLE.
El lector recibe SELECT sobre los objetos elegidos. Para secuencias, USAGE permite nextval: no lo concedas automáticamente a un lector estricto. Si necesita inspeccionar una secuencia, evalúa SELECT específico.
Evita conceder CREATEROLE, CREATEDB, BYPASSRLS o privilegios de propietario al runtime. Aunque una cuenta no sea dueña, verifica roles heredados y posibilidad de SET ROLE; pueden volver ineficaz la separación.
Una política de solo lectura también revisa funciones ejecutables, especialmente SECURITY DEFINER, propiedad y permisos heredados. SELECT no impide efectos laterales de una función con facultades elevadas si su ejecución está concedida.
Matriz propuesta para SensorHub
| Cuenta | Datos | Estructura | Uso |
|---|---|---|---|
| sh_app | DML necesario | Sin propiedad/CREATE | Runtime |
| sh_migrator | Datos necesarios para migrar | Propiedad controlada | Pipeline de migración |
| sh_support + sh_readonly | SELECT autorizado | Sin DDL | Investigación |
| sh_dev_ana | Datos de prueba | Objetos de su DB | Desarrollo |
| Administrador autorizado | Según facultades del servicio | Administración | Provisión y emergencia |
03 / CONSTRUIR
Implementación paso a paso
- Crea roles por responsabilidad en un laboratorio nuevo.
- Define credenciales mediante un canal seguro y no las escribas en el SQL versionado.
- Crea la base productiva de laboratorio propiedad del migrador autorizado.
- Concede runtime y lector permisos por objeto, revisando esquemas y secuencias.
- Relaciona humanos con roles grupales y revisa herencia/SET ROLE según versión.
- Prueba runtime sin DDL, lector sin DML y migrador con la estructura requerida.
04 / APLICAR
Ejemplo en SensorHub
-- Provisión inicial: ejecutar con administrador autorizado, en laboratorio.
CREATE ROLE sh_app LOGIN NOSUPERUSER NOCREATEDB NOCREATEROLE NOBYPASSRLS;
CREATE ROLE sh_migrator LOGIN NOSUPERUSER NOCREATEDB NOCREATEROLE NOBYPASSRLS;
CREATE ROLE sh_readonly NOLOGIN;
CREATE ROLE sh_support LOGIN NOSUPERUSER NOCREATEDB NOCREATEROLE;
GRANT sh_readonly TO sh_support;
-- En psql configura contraseñas por prompt seguro, si ese método aplica:
\password sh_app
\password sh_migrator
\password sh_support
-- Las autorizaciones sobre bases y objetos se completan en los temas siguientes.Cómo leer el ejemplo
- CREATE ROLE es para una provisión inicial, no un script idempotente para cada despliegue.
- NOLOGIN agrupa permisos sin un secreto compartido entre humanos.
- La cuenta migradora no debe ser miembro administrador por conveniencia.
Error habitual
Un lector que puede llamar nextval cambia el estado de una secuencia; el nombre readonly no impone una restricción automática.
05 / PRACTICAR
Tu turno
Diseña una matriz para admin, app, migrador, soporte y desarrollador.
Ver solución orientativa
Admin administra el servidor con los límites del servicio; app opera datos concedidos; migrador controla estructura; soporte consulta objetos autorizados; desarrollador controla solamente su base de pruebas.
06 / VERIFICAR
Cómo sabes que funciona
- Runtime no es propietario ni miembro del migrador.
- Lector no tiene USAGE de secuencias sin justificación.
- Usuarios humanos tienen credenciales propias.
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:
Aislar producción, staging y bases de desarrollo →Continuar en modo relato