pgAudit en PostgreSQL 18: auditoría con límite medible
Guía técnica para registrar cambios con pgAudit, separar permisos, controlar volumen de logs, guardar evidencia y probar restauración.
Una línea AUDIT puede decir usuario, acción, objeto y sentencia en vez de dejar una pregunta abierta. En PostgreSQL 18, pgAudit agrega registros de sesion u objeto sobre la salida normal de logs. Para pymes con sistemas propios, expedientes o cobranzas, esta guía explica que activar, que dejar afuera, quien administra permisos, cuanto espacio reservar y como probar que la evidencia vuelve.
Dónde el log comun pierde contexto
La advertencia mas util de pgAudit no es comercial: segun su propia documentación, una configuración amplia puede generar un volumen enorme y el archivo de log puede medir muchas veces el tamano de los datos insertados. Esa cifra cambia la compra de discos antes que la consulta SQL. El log también ocupa presupuesto. El contexto global confirma que la auditoría ya no vive solo en grandes plataformas. GitHub Octoverse 2025 informo más de 180 millones de desarrolladores y 630 millones de repositorios. Una municipalidad del Gran Mendoza con menos de 50.000 habitantes no maneja esa escala, pero si necesita saber quien cambio un padrón, una tasa o un permiso.
Que registra pgAudit y quién puede tocarlo
El antagonista es la tabla modificada por "admin" a las 19:42 sin persona responsable. En una mesa de soporte municipal, un monitor de 19 pulgadas muestra tickets abiertos y una etiqueta Dymo pegada en el teclado todavia dice "catastro". El dato que falta no es poetico: usuario real, rol, sentencia, objeto, fecha y origen. pgAudit soporta PostgreSQL 14 o superior y mantiene rama por versión mayor, incluida PostgreSQL 18. La página de release notes de PostgreSQL muestra la rama 18 activa y publica versiones 18.4, 17.10, 16.14, 15.18 y 14.23 al 14 de mayo de 2026. La decisión técnica arranca por compatibilidad, no por entusiasmo.
Cómo funciona por dentro
El flujo mínimo tiene siete pasos. Primero, el DBA instala pgAudit y lo carga en shared_preload_libraries. Segundo, crea la extension antes de definir pgaudit.log. Tercero, separa roles de aplicación, soporte, lectura y auditoría. Cuarto, activa clases concretas, por ejemplo WRITE y DDL, en bases o roles definidos. Quinto, PostgreSQL escribe logs en stderr, csvlog o jsonlog segun configuración. Sexto, un colector mueve logs a almacenamiento externo con retencion. Septimo, la prueba restaura base, configuración y muestra de logs. PostgreSQL guarda registros estructurados, roles, privilegios y WAL. pgAudit recibe sentencias y contexto de ejecución; entrega entradas con clase, comando, objeto y sentencia. El colector recibe archivos de log; entrega busqueda por usuario, fecha y objeto. El backup recupera base y configuración, pero la documentación de PITR recuerda que los archivos de configuración editados a mano no viajan dentro del WAL. Ese punto obliga a respaldar postgresql.conf, pg_hba.conf y parametros de auditoría.
Qué se instala o configura primero
La pila inicial usa PostgreSQL 18, pgAudit 18, logs CSV o JSON, rotación diaria, usuario DBA separado, usuario auditor de solo lectura, almacenamiento S3 o disco externo, tablero de volumen y restauración mensual. El piloto cuesta entre USD 900 y USD 2.800, entre ARS 1,28 y ARS 3,98 millones al dólar vendedor oficial de $1.421 informado por Bluelytics. Incluye dos bases, diez tablas sensibles, tres roles y prueba. El plazo va de dos a cuatro semanas. UMSA suele pedir un entregable verificable: cambio de dato por rol autorizado, rechazo por rol incorrecto, entrada AUDIT buscable, log rotado, copia externa y restauración en otro host. El costo no incluye afinamiento de la aplicación, migración de roles historicos ni custodia legal de evidencia. La primera prueba crea una tabla de ejemplo, ejecuta INSERT, UPDATE y DELETE, y mide cantidad de líneas generadas. El equipo anota bytes por cada mil operaciones. Esa cuenta define retencion y disco antes de habilitar auditoría sobre tablas con mucho movimiento. La segunda prueba revisa permisos. Un operador de mesa de ayuda intenta modificar una tabla fuera de su rol. PostgreSQL debe rechazar la operación y pgAudit debe registrar el intento si la clase configurada lo cubre. El registro tiene que mostrar usuario, base, objeto y hora. Un tercer control mira lectura sensible. El auditor pide todas las consultas sobre una tabla de padrón durante dos horas. El equipo entrega filtro, archivo, hash y responsable de custodia. Esa salida demuestra que el log puede responder una pregunta puntual sin abrir toda la base a revisión manual.
Dónde se rompe y cómo probarlo Primer riesgo: auditar todo.
La señal aparece cuando el directorio de logs crece mas rapido que la ventana de backup. La prueba mide una hora de carga real y proyecta treinta días. Segundo riesgo: parametros visibles. La señal aparece cuando un log guarda datos personales o secretos. La prueba ejecuta sentencias con parametros de muestra y revisa pgaudit.log_parameter. Tercer riesgo: superusuarios compartidos. La señal es un registro firmado por postgres para tareas humanas. La prueba exige usuarios nominales y roles heredados. Cuarto riesgo: restauración incompleta. La señal es una base recuperada sin configuración de auditoría ni logs externos. La prueba recupera base, configuración y una busqueda AUDIT fechada. La auditoría sirve cuando una pregunta concreta recibe una línea concreta.