CAPÍTULO 8 · La base de datos también tiene fronteras
La aplicación protegida todavía puede usar una cuenta demasiado poderosa
Las vistas pueden verificar roles y rechazar solicitudes indebidas, pero la conexión a PostgreSQL actúa con sus propios permisos. Si esa cuenta puede crear, borrar o administrar todo, un fallo de la aplicación dispone de un alcance mucho mayor del necesario. La seguridad del backend necesita continuar más allá del último método de Python.
Introducimos una política de gobierno para la base de datos. Preguntamos qué necesita hacer el proceso web, qué tareas corresponden al despliegue y cuáles requieren intervención administrativa. El objetivo es que los permisos acompañen responsabilidades concretas, en lugar de utilizar una sola credencial cómoda para todas las operaciones.
El criterio es el mismo que aplicamos a usuarios y recursos, ahora expresado en PostgreSQL. Para volverlo operativo debemos convertir esas responsabilidades en cuentas y roles distinguibles. Solo entonces podremos comprobar que una acción permitida a una tarea permanece prohibida para las demás.
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
Tres capas de gobierno distintas
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
- Responsabilidad. Define tarea y duración
- Azure RBAC. Opera recurso cloud
- Roles SQL. Controlan conexión y objetos
- Política Django. Autoriza negocio
01 / EL PROBLEMA
¿Para qué sirve?
Si Django usa la cuenta administradora del servidor, una fuga de configuración compromete mucho más que las acciones normales de la aplicación.
02 / COMPRENDER
El concepto, explicado
Gobernar acceso significa decidir quién entra, a qué base, qué operaciones ejecuta, durante cuánto tiempo y cómo se retira el acceso. Las decisiones deben quedar vinculadas a tareas reales y responsables.
Azure RBAC gobierna el recurso administrado: red, escalado, configuración o restauración según rol. PostgreSQL gobierna conexiones y objetos SQL. Django gobierna acciones sobre datos de negocio. Ninguna capa sustituye las otras.
El administrador inicial de Flexible Server tiene capacidades elevadas pero no es un superusuario PostgreSQL irrestricto; el servicio reserva privilegios de plataforma. Conserva esa identidad para administración autorizada y emergencias.
Un runtime con permisos DML puede seguir extraer o modificar todos los datos que tiene concedidos. Mínimo privilegio limita daños estructurales, pero necesita acompañarse de controles de aplicación, consultas parametrizadas, red y protección de secretos.
Capas complementarias
| Capa | Qué decide | Ejemplo |
|---|---|---|
| Azure RBAC | Operación del recurso cloud | Cambiar capacidad del servidor |
| PostgreSQL | Conexión y privilegios SQL | SELECT sobre una vista |
| Django | Acción y alcance de negocio | Consultar sensores de la organización propia |
03 / CONSTRUIR
Implementación paso a paso
- Inventaría bases, usuarios, membresías, propietarios y aplicaciones consumidoras.
- Define tareas de runtime, migración, soporte de lectura y desarrollo.
- Diseña roles y scopes SQL por tarea; revisa asignaciones Azure por separado.
- Guarda credenciales por entorno y establece dueños y revisiones de acceso.
- Prueba acciones permitidas y denegadas desde cuentas reales.
- Documenta la baja, la revocación y qué hacer con sesiones activas.
04 / APLICAR
Ejemplo en SensorHub
-- Consulta de inventario; no muestra contraseñas.
SELECT rolname, rolcanlogin, rolsuper, rolcreatedb,
rolcreaterole, rolbypassrls
FROM pg_roles
WHERE rolname NOT LIKE 'pg_%'
ORDER BY rolname;
SELECT datname, pg_get_userbyid(datdba) AS owner
FROM pg_database
WHERE NOT datistemplate
ORDER BY datname;Cómo leer el ejemplo
- Los roles existen a nivel de cluster/servidor; sus privilegios sobre objetos dependen de cada base.
- Las consultas son un punto de partida, no una evaluación completa de membresías y permisos efectivos.
- No cambies roles internos del proveedor como parte del ejercicio.
Error habitual
Tratar un rol Azure de colaborador como permiso SELECT, o suponer que quitar DDL evita exfiltración de datos.
05 / PRACTICAR
Tu turno
Una cuenta de soporte necesita investigar alarmas sin editar datos. Define permisos y riesgo residual.
Ver solución orientativa
Usa identidad personal y un rol lector sobre vistas o tablas necesarias, con CONNECT y USAGE adecuados. Mantén fuera permisos de escritura y estructura; registra que lectura también permite exfiltrar lo visible.
06 / VERIFICAR
Cómo sabes que funciona
- Django no usa administrador de servidor.
- Cada cuenta tiene propósito y responsable.
- Se comprueban permisos SQL además de IAM.
- No se declara seguridad total por tener roles separados.
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:
Roles de runtime, migración y consulta →Continuar en modo relato