pgAudit en PostgreSQL 18: auditoria con limite medible
Guia tecnica para registrar cambios con pgAudit, separar permisos, controlar volumen de logs, guardar evidencia y probar restauracion.
Una linea AUDIT puede decir usuario, accion, 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 guia explica que activar, que dejar afuera, quien administra permisos, cuanto espacio reservar y como probar que la evidencia vuelve.
Donde el log comun pierde contexto
La advertencia mas util de pgAudit no es comercial: segun su propia documentacion, una configuracion 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 tambien ocupa presupuesto.
El contexto global confirma que la auditoria ya no vive solo en grandes plataformas. GitHub Octoverse 2025 informo mas 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 padron, una tasa o un permiso.
Que registra pgAudit y quien 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 version mayor, incluida PostgreSQL 18. La pagina 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 decision tecnica arranca por compatibilidad, no por entusiasmo.
Como funciona por dentro
El flujo minimo 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 aplicacion, soporte, lectura y auditoria. Cuarto, activa clases concretas, por ejemplo WRITE y DDL, en bases o roles definidos. Quinto, PostgreSQL escribe logs en stderr, csvlog o jsonlog segun configuracion. Sexto, un colector mueve logs a almacenamiento externo con retencion. Septimo, la prueba restaura base, configuracion y muestra de logs.
PostgreSQL guarda registros estructurados, roles, privilegios y WAL. pgAudit recibe sentencias y contexto de ejecucion; 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 configuracion, pero la documentacion de PITR recuerda que los archivos de configuracion editados a mano no viajan dentro del WAL. Ese punto obliga a respaldar postgresql.conf, pg_hba.conf y parametros de auditoria.
Que se instala o configura primero
La pila inicial usa PostgreSQL 18, pgAudit 18, logs CSV o JSON, rotacion diaria, usuario DBA separado, usuario auditor de solo lectura, almacenamiento S3 o disco externo, tablero de volumen y restauracion mensual. El piloto cuesta entre USD 900 y USD 2.800, entre ARS 1,28 y ARS 3,98 millones al dolar 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 restauracion en otro host. El costo no incluye afinamiento de la aplicacion, migracion 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 lineas generadas. El equipo anota bytes por cada mil operaciones. Esa cuenta define retencion y disco antes de habilitar auditoria 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 operacion 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 padron 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 revision manual.
Donde se rompe y como probarlo
Primer riesgo: auditar todo. La senal 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 dias. Segundo riesgo: parametros visibles. La senal 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 senal es un registro firmado por postgres para tareas humanas. La prueba exige usuarios nominales y roles heredados. Cuarto riesgo: restauracion incompleta. La senal es una base recuperada sin configuracion de auditoria ni logs externos. La prueba recupera base, configuracion y una busqueda AUDIT fechada. La auditoria sirve cuando una pregunta concreta recibe una linea concreta.