Objetivos de la unidad

De la Unidad 2 a la Unidad 3

El caso de la unidad

El RFC de María García (id = 3) aparece modificado en un reporte de facturación.

La pregunta de la unidad

CONTROL DE ACCESO (Unidad 2)            "¿quién PUEDE?"
        │
        ▼
AUDITORÍA Y TRAZABILIDAD                "¿qué OCURRIÓ?"
   ┌────┼──────────────┐
   ▼    ▼              ▼
eventos  bitácoras     políticas prácticas
   └──────────┬────────┘
              ▼
   GOBIERNO PRÁCTICO DE DATOS            "¿quién RESPONDE?"
              ▼
   EVIDENCIAS PARA AUDITORÍA INTERNA

Actividad 1: Diagnóstico

1. ¿Por qué ese control de acceso no permite responder quién cambió el RFC?
2. ¿Qué tendría que haber existido antes del cambio para poder responder?
3. ¿A quién le corresponde decidir cuál es el RFC correcto?

El gestor primero, el despliegue después

Un mismo servidor PostgreSQL o MongoDB puede estar instalado de varias formas. Las instrucciones del gestor son las mismas en todas.

Dos tipos de sesión con psql

psql "postgresql://app_ventas:Ventas_Practica_2026@127.0.0.1/comercial?application_name=app-ventas-web" -c "SELECT 1"

La cadena de conexión, pieza por pieza

postgresql://app_ventas:Ventas_Practica_2026@127.0.0.1/comercial?application_name=app-ventas-web

Preguntarle al motor por su instalación

SELECT version();
SHOW data_directory;
SHOW config_file;
SHOW hba_file;

 PostgreSQL 16.14 (Debian 16.14-1.pgdg13+1) on x86_64-pc-linux-gnu, ...
 /var/lib/postgresql/data
 /var/lib/postgresql/data/postgresql.conf
 /var/lib/postgresql/data/pg_hba.conf

Las rutas dependen del despliegue. Las consultas son las mismas en todos

3.1 | Auditoría: qué es y qué no es

3.1 | Tres ideas que no debes olvidar

3.1 | Eventos auditables

Ejemplo: un evento de cada tipo en una bitácora real

3.1 | No todo merece registrarse

Actividad 2: Clasificación de eventos auditables

Clasifica cada evento como auditable o no auditable prioritario y justifica:

1. Un usuario consulta su propio perfil.
2. Un administrador otorga permisos de escritura a otro usuario.
3. Se elimina una columna de una tabla.
4. Un usuario lee un registro de nómina que no le corresponde.
5. Se reinicia el servicio.
6. Un usuario consulta muchos registros en poco tiempo.

3.2 | ¿Dónde está la bitácora? Depende del despliegue

PostgreSQL escribe sus mensajes en su salida de error. Con la configuración por defecto, quien decide a dónde va es el mecanismo de despliegue:

Ejemplo guiado: el servidor administra su bitácora

ALTER SYSTEM SET logging_collector = on;   -- requiere reiniciar el servicio
SELECT pg_current_logfile();

          pg_current_logfile
--------------------------------------
 log/postgresql-2026-10-25_224920.log

SELECT linea
FROM regexp_split_to_table(pg_read_file(pg_current_logfile()), E'\n') AS linea;

Fuente: documentación oficial de PostgreSQL 16, "System Information Functions" y "System Administration Functions"

Leer y filtrar la bitácora con SQL

Una vista guarda la consulta con nombre. Se crea en un esquema sin acceso público:

CREATE SCHEMA dba;
REVOKE ALL ON SCHEMA dba FROM PUBLIC;
CREATE VIEW dba.bitacora AS
SELECT t.n AS num, t.linea
FROM regexp_split_to_table(pg_read_file(pg_current_logfile()), E'\n') WITH ORDINALITY AS t(linea, n)
WHERE t.linea <> '';

SELECT num, linea FROM dba.bitacora ORDER BY num DESC LIMIT 10;      -- últimas 10
SELECT linea FROM dba.bitacora WHERE linea LIKE '%statement:%';      -- sentencias
SELECT linea FROM dba.bitacora WHERE linea ~ '(FATAL|ERROR)';        -- expresión regular
SELECT count(*) FROM dba.bitacora WHERE linea LIKE '%password authentication failed%';

3.2 | Parámetros que controlan la bitácora

Fuente: documentación oficial de PostgreSQL, "Error Reporting and Logging"

Ejemplo guiado: configuración por defecto

SELECT name, setting, source FROM pg_settings
WHERE name IN ('log_connections','log_disconnections','log_line_prefix','log_statement');

        name        | setting  | source
--------------------+----------+---------
 log_connections    | off      | default
 log_disconnections | off      | default
 log_line_prefix    | %m [%p]  | default
 log_statement      | none     | default

Ejemplo guiado: el incidente sin bitácora

La aplicación cambia el RFC:

psql "postgresql://app_ventas:Ventas_Practica_2026@127.0.0.1/comercial?application_name=app-ventas-web" -c "UPDATE clientes SET rfc = 'GAMA780912XXX' WHERE id = 3"

UPDATE 1

Buscamos evidencia:

SELECT linea FROM dba.bitacora WHERE linea ILIKE '%update%' OR linea LIKE '%app_ventas%';

(0 rows)

3.2 | Niveles de log_statement

Ejemplo guiado: configurar con ALTER SYSTEM

ALTER SYSTEM SET log_connections = on;
ALTER SYSTEM SET log_disconnections = on;
ALTER SYSTEM SET log_line_prefix = '%m [%p] user=%u db=%d app=%a client=%h ';
ALTER SYSTEM SET log_statement = 'ddl';
SELECT pg_reload_conf();

Fuente: documentación oficial de PostgreSQL, "ALTER SYSTEM". Los valores se guardan en postgresql.auto.conf

3.2 | Cuidado con la prioridad de la configuración

1. Opciones -c al arrancar el servidor     (mayor prioridad)
2. postgresql.auto.conf  ← ALTER SYSTEM
3. postgresql.conf                          (menor prioridad)

SELECT name, setting, source, sourcefile FROM pg_settings WHERE name = 'log_statement';

Fuente: documentación oficial de PostgreSQL, "Setting Parameters"

Ejemplo guiado: el cambio de configuración queda registrado

11 | ... [1] user= db= app= client= LOG:  parameter "log_statement" changed to "ddl"
10 | ... [1] user= db= app= client= LOG:  parameter "log_line_prefix" changed to "%m [%p] user=%u ..."
 9 | ... [1] LOG:  parameter "log_disconnections" changed to "on"
 8 | ... [1] LOG:  parameter "log_connections" changed to "on"

3.1 | Accesos fallidos: revisa las reglas de autenticación

SELECT line_number, type, address, auth_method FROM pg_hba_file_rules WHERE database = '{all}';

 line_number | type  |  address  |  auth_method
-------------+-------+-----------+---------------
         117 | local |           | trust
         119 | host  | 127.0.0.1 | trust
         128 | host  | all       | scram-sha-256

Fuente: documentación oficial de PostgreSQL 16, "pg_hba_file_rules"

Ejemplo guiado: accesos en la bitácora

psql "postgresql://app_ventas:incorrecta@127.0.0.1/comercial" -c "SELECT 1"
psql "postgresql://usuario_inexistente:x@127.0.0.1/comercial" -c "SELECT 1"

22:50:00.334 UTC [91] user=app_ventas db=comercial app=[unknown] client=127.0.0.1 FATAL:  password authentication failed for user "app_ventas"
22:50:00.334 UTC [91] ... DETAIL:  Connection matched file "/var/lib/postgresql/data/pg_hba.conf" line 119: "host all all 127.0.0.1/32 scram-sha-256"
22:50:00.462 UTC [98] user=usuario_inexistente ... FATAL:  password authentication failed for user "usuario_inexistente"
22:50:00.462 UTC [98] ... DETAIL:  Role "usuario_inexistente" does not exist.
22:50:00.565 UTC [105] user=app_ventas ... LOG:  connection authenticated: identity="app_ventas" method=scram-sha-256
22:50:00.566 UTC [105] user=app_ventas ... LOG:  connection authorized: user=app_ventas database=comercial application_name=app-ventas-web
22:50:00.568 UTC [105] user=app_ventas db=comercial app=app-ventas-web client=127.0.0.1 LOG:  disconnection: session time: 0:00:00.010

3.2 | Leer una línea campo por campo

2026-10-25 22:50:00.334 UTC [91] user=app_ventas db=comercial app=[unknown] client=127.0.0.1 FATAL:  password authentication failed

Ejemplo guiado: privilegios y estructura

REVOKE UPDATE ON clientes FROM soporte_ana;
GRANT UPDATE ON clientes TO app_ventas;
ALTER TABLE clientes ADD COLUMN segmento VARCHAR(20);

22:50:09.341 UTC [119] user=postgres db=comercial app=psql client=[local] LOG:  statement: REVOKE UPDATE ON clientes FROM soporte_ana
22:50:09.367 UTC [119] user=postgres db=comercial app=psql client=[local] LOG:  statement: GRANT UPDATE ON clientes TO app_ventas
22:50:09.372 UTC [119] user=postgres db=comercial app=psql client=[local] LOG:  statement: ALTER TABLE clientes ADD COLUMN segmento VARCHAR(20)

Ejemplo guiado: la bitácora también filtra secretos

CREATE ROLE rol_temporal LOGIN PASSWORD 'Temporal_Practica_2026';
SELECT linea FROM dba.bitacora WHERE linea LIKE '%rol_temporal%';

LOG:  statement: CREATE ROLE rol_temporal LOGIN PASSWORD 'Temporal_Practica_2026'

Ejemplo guiado: ddl no registra el UPDATE

Con log_statement = 'ddl' se repite el cambio de RFC: la bitácora muestra la conexión y la desconexión de app_ventas, pero no el UPDATE.

ALTER SYSTEM SET log_statement = 'mod';
SELECT pg_reload_conf();

22:50:19.459 UTC [155] user=postgres ... LOG:  statement: ALTER SYSTEM SET log_statement = 'mod'
22:50:19.488 UTC [1]   user= db= app= client= LOG:  parameter "log_statement" changed to "mod"
22:50:20.601 UTC [162] user=app_ventas db=comercial app=app-ventas-web client=127.0.0.1 LOG:  statement: UPDATE clientes SET telefono = '6679990000' WHERE id = 3

Ahora sí: quién, cuándo, desde dónde, con qué aplicación y qué sentencia.

3.2 | Lo que la bitácora todavía no muestra

Ejemplo guiado: errores de autorización

psql "postgresql://soporte_ana:Soporte_Practica_2026@127.0.0.1/comercial" -c "DELETE FROM clientes WHERE id = 5"

user=soporte_ana db=comercial app=psql client=127.0.0.1 ERROR:  permission denied for table clientes
user=soporte_ana db=comercial app=psql client=127.0.0.1 STATEMENT:  DELETE FROM clientes WHERE id = 5
user=postgres db=comercial app=psql client=[local] ERROR:  role "soporte_ana" cannot be dropped because some objects depend on it
user=postgres db=comercial app=psql client=[local] DETAIL:  privileges for table clientes
user=postgres db=comercial app=psql client=[local] STATEMENT:  DROP ROLE soporte_ana

Ejemplo guiado: pg_stat_activity

SELECT pid, usename, application_name, client_addr, state, left(query, 30) AS query
FROM pg_stat_activity WHERE backend_type = 'client backend';

 pid |   usename   | application_name | client_addr | state  |             query
-----+-------------+------------------+-------------+--------+--------------------------------
 196 | postgres    | psql             |             | active | SELECT pid, usename, applicati
 189 | soporte_ana | reporte-mensual  | 127.0.0.1   | active | SELECT pg_sleep(90)

El PID relaciona ambas fuentes. En la Unidad IV se usará para diagnosticar desempeño.

3.2 | Exportar y proteger la bitácora

psql -U postgres -d comercial -At -c "SELECT replace(pg_read_file(pg_current_logfile()), 'Temporal_Practica_2026', '<REDACTED>')" > evidencias/bitacora.log

-A quita la alineación, -t los encabezados. replace retira el secreto antes de que salga del servidor. > envía la salida a un archivo y lo reemplaza si existe.

Ejemplo: el hash detecta una alteración

shasum -a 256 bitacora.log

ad10b928960869be89354c5c522695b9122620372db29bd89a2c519057550e6a  bitacora.log

Alguien cambia app_ventas por soporte_ana en una sola línea del archivo:

sed -i '' 's/app_ventas/soporte_ana/' bitacora.log     # en Linux: sed -i 's/.../.../' archivo
shasum -a 256 bitacora.log

1f06e95f47838d699b8d2bb8770ea39f65bf979ec9eb6825642837ad6d705ec2  bitacora.log

3.2 | Tres niveles de auditoría

3.2 | Diseñar el registro de auditoría

Ejemplo guiado: esquema y tabla de auditoría

CREATE SCHEMA auditoria;
REVOKE ALL ON SCHEMA auditoria FROM PUBLIC;

CREATE TABLE auditoria.cambios_clientes (
    id_evento        BIGSERIAL PRIMARY KEY,
    momento          TIMESTAMPTZ NOT NULL DEFAULT now(),
    usuario_sesion   TEXT        NOT NULL DEFAULT session_user,
    usuario_efectivo TEXT        NOT NULL DEFAULT current_user,
    aplicacion       TEXT        DEFAULT current_setting('application_name'),
    ip_cliente       INET        DEFAULT inet_client_addr(),
    operacion        TEXT        NOT NULL,
    id_cliente       BIGINT,
    valores_antes    JSONB,
    valores_despues  JSONB
);

Ejemplo guiado: la función de disparador

CREATE OR REPLACE FUNCTION auditoria.registrar_cambio_cliente()
RETURNS trigger LANGUAGE plpgsql
SECURITY DEFINER
SET search_path = pg_catalog, public
AS $$
BEGIN
    IF TG_OP = 'INSERT' THEN
        INSERT INTO auditoria.cambios_clientes (operacion, id_cliente, valores_despues)
        VALUES (TG_OP, NEW.id, to_jsonb(NEW));
        RETURN NEW;
    ELSIF TG_OP = 'UPDATE' THEN
        INSERT INTO auditoria.cambios_clientes (operacion, id_cliente, valores_antes, valores_despues)
        VALUES (TG_OP, NEW.id, to_jsonb(OLD), to_jsonb(NEW));
        RETURN NEW;
    ELSIF TG_OP = 'DELETE' THEN
        INSERT INTO auditoria.cambios_clientes (operacion, id_cliente, valores_antes)
        VALUES (TG_OP, OLD.id, to_jsonb(OLD));
        RETURN OLD;
    END IF;
    RETURN NULL;
END;
$$;

Fuente: documentación oficial de PostgreSQL, "Trigger Functions", ejemplo 43.4 (función de disparador para auditoría)

Ejemplo guiado: asociar el disparador

REVOKE ALL ON FUNCTION auditoria.registrar_cambio_cliente() FROM PUBLIC;

CREATE TRIGGER trg_auditoria_clientes
AFTER INSERT OR UPDATE OR DELETE ON clientes
FOR EACH ROW EXECUTE FUNCTION auditoria.registrar_cambio_cliente();

3.2 | SECURITY DEFINER y search_path

Ejemplo guiado: el incidente auditado

psql "postgresql://app_ventas:Ventas_Practica_2026@127.0.0.1/comercial?application_name=app-ventas-web" -c "UPDATE clientes SET rfc = 'GAMA780912ZZZ' WHERE id = 3"

id_evento        | 1
momento          | 2026-10-25 22:50:52.903439+00
usuario_sesion   | app_ventas
usuario_efectivo | postgres
aplicacion       | app-ventas-web
ip_cliente       | 127.0.0.1
operacion        | UPDATE

Ejemplo guiado: ¿qué campo cambió?

SELECT a.id_evento, a.usuario_sesion, a.ip_cliente, d.key AS campo,
       a.valores_antes ->> d.key AS antes, d.value #>> '{}' AS despues
FROM auditoria.cambios_clientes a
CROSS JOIN LATERAL jsonb_each(a.valores_despues) d
WHERE a.operacion = 'UPDATE'
  AND a.valores_antes -> d.key IS DISTINCT FROM d.value
ORDER BY a.id_evento;

 id_evento | usuario_sesion | ip_cliente | campo |     antes     |    despues
-----------+----------------+------------+-------+---------------+---------------
         1 | app_ventas     | 127.0.0.1  | rfc   | GAMA780912XYZ | GAMA780912ZZZ

Ahora facturación puede restaurar el valor anterior.

Ejemplo guiado: altas y bajas

 id_evento | usuario_sesion |   aplicacion   | operacion | id_cliente |   rfc_antes   |  rfc_despues
-----------+----------------+----------------+-----------+------------+---------------+---------------
         1 | app_ventas     | app-ventas-web | UPDATE    |          3 | GAMA780912XYZ | GAMA780912ZZZ
         2 | postgres       | psql           | INSERT    |          6 |               | RUPE950101AAA
         3 | postgres       | psql           | DELETE    |          6 | RUPE950101AAA |

Ejemplo guiado: intentar borrar la evidencia

Desde la aplicación:

DELETE FROM auditoria.cambios_clientes                       → ERROR: permission denied for schema auditoria
ALTER TABLE clientes DISABLE TRIGGER trg_auditoria_clientes  → ERROR: must be owner of table clientes

Desde el administrador (desactiva, cambia y reactiva): la tabla de auditoría no registra el cambio, pero la bitácora sí, incluido el intento fallido de la aplicación:

user=app_ventas ... LOG:  statement: ALTER TABLE clientes DISABLE TRIGGER trg_auditoria_clientes
user=postgres ... LOG:  statement: ALTER TABLE clientes DISABLE TRIGGER trg_auditoria_clientes
user=postgres ... LOG:  statement: UPDATE clientes SET rfc = 'GAMA780912GHI' WHERE id = 3
user=postgres ... LOG:  statement: ALTER TABLE clientes ENABLE TRIGGER trg_auditoria_clientes

3.2 | Un mecanismo audita al otro

Tabla de auditoría      →  detalle del dato (antes y después)
                           la desactiva el propietario de la tabla

Bitácora del servidor   →  registra que la auditoría se desactivó
                           la altera quien controla el servidor

3.2 | El límite del disparador: las lecturas

No existe disparador para SELECT. Con log_statement = 'mod', la bitácora tampoco registra consultas.

3.2 | pgaudit (práctica avanzada opcional)

SELECT name, default_version FROM pg_available_extensions WHERE name = 'pgaudit';
CREATE EXTENSION pgaudit;
-- ERROR:  pgaudit must be loaded via shared_preload_libraries

ALTER SYSTEM SET shared_preload_libraries = 'pgaudit';
SELECT pg_reload_conf();
SELECT name, setting, pending_restart FROM pg_settings WHERE name = 'shared_preload_libraries';
--  shared_preload_libraries |         | t        ← espera un reinicio

Después de reiniciar el servicio: CREATE EXTENSION pgaudit; → versión 16.1.

Fuente: repositorio oficial del proyecto pgaudit

Recargar o reiniciar: cómo saberlo

Fuente: documentación oficial de PostgreSQL 16, "Setting Parameters" y "ALTER SYSTEM"

Ejemplo guiado: auditoría de objeto con pgaudit

El rol auditor no inicia sesión. Sus privilegios son un filtro de qué columnas auditar:

CREATE EXTENSION pgaudit;
CREATE ROLE auditor_datos NOLOGIN;
GRANT SELECT (rfc, telefono), UPDATE (rfc, telefono) ON clientes TO auditor_datos;
ALTER SYSTEM SET pgaudit.log = 'role, ddl';
ALTER SYSTEM SET pgaudit.role = 'auditor_datos';
ALTER SYSTEM SET log_line_prefix = '%m [%p] user=%u db=%d app=%a client=%h ';
SELECT pg_reload_conf();

user=app_ventas ... AUDIT: OBJECT,1,1,READ,SELECT,TABLE,public.clientes,"SELECT nombre, rfc FROM clientes WHERE id = 3",<not logged>
user=app_ventas ... AUDIT: OBJECT,2,1,READ,SELECT,TABLE,public.clientes,SELECT * FROM clientes WHERE id = 4,<not logged>
user=app_ventas ... AUDIT: OBJECT,3,1,WRITE,UPDATE,TABLE,public.clientes,UPDATE clientes SET rfc = 'LOAA850315XXX' WHERE id = 1,<not logged>
user=postgres   ... AUDIT: SESSION,1,1,ROLE,GRANT,TABLE,,GRANT SELECT ON clientes TO soporte_ana,<not logged>

SELECT nombre, ciudad ... y UPDATE ... SET ciudad ... no aparecen.

3.2 | Advertencias del propio pgaudit

Fuente: README oficial de pgaudit

Relación con el Laboratorio 01

Una limitación real que debes conocer

Fuente: MongoDB Manual, "Auditing"

3.1 | Qué registraría la auditoría nativa

Según la documentación oficial (sin practicarlo en esta materia):

3.2 | Lo que sí existe en Community

Fuente: MongoDB Manual, "Database Profiler"

Ejemplo guiado: preparar MongoDB con autenticación

use admin
db.createUser({ user: "admin", pwd: "Admin_Practica_2026", roles: ["root"] })
db.auth("admin", "Admin_Practica_2026")

use comercial
db.createUser({ user: "app_ventas", pwd: "Ventas_Practica_2026",
                roles: [{ role: "readWrite", db: "comercial" }] })
db.clientes.insertMany([ /* 5 clientes ficticios de la Unidad 2 */ ])

Ejemplo guiado: el incidente sin perfilado

db.getProfilingStatus()

{ was: 0, slowms: 100, sampleRate: 1, ok: 1 }

La aplicación cambia el RFC:

mongosh "mongodb://app_ventas:Ventas_Practica_2026@127.0.0.1:27017/comercial?appName=app-ventas-web" --quiet --eval 'db.clientes.updateOne({ _id: 3 }, { $set: { rfc: "GAMA780912XXX" } })'

La conexión a MongoDB, pieza por pieza

mongodb://app_ventas:Ventas_Practica_2026@127.0.0.1:27017/comercial?appName=app-ventas-web

Ejemplo guiado: activar el perfilador

db.setProfilingLevel(2)     // { was: 0, ... }  ← devuelve el nivel ANTERIOR
db.getProfilingStatus()     // { was: 2, slowms: 100, sampleRate: 1, ok: 1 }

{
  op: 'update',
  ns: 'comercial.clientes',
  command: { q: { _id: 3 }, u: { '$set': { rfc: 'GAMA780912XYZ' } }, multi: false, upsert: false },
  docsExamined: 1,
  nModified: 1,
  ts: ISODate('2026-10-25T22:52:45.909Z'),
  client: '127.0.0.1',
  appName: 'app-ventas-web',
  user: 'app_ventas@comercial'
}

Fuente: MongoDB Manual, "Database Profiler Output"

3.2 | Interpretar system.profile

Ejemplo guiado: reducir volumen con un filtro

db.setProfilingLevel(0)
db.system.profile.drop()          // exporta antes lo que necesites
db.setProfilingLevel(1, { filter: { op: { $in: ["insert", "update", "remove"] } } })

{
  was: 1, slowms: 100, sampleRate: 1,
  filter: { op: { '$in': [ 'insert', 'remove', 'update' ] } },
  note: 'When a filter expression is set, slowms and sampleRate are not used ...',
  ok: 1
}

Tras una consulta y una actualización de la aplicación, system.profile contiene solo el update.

3.2 | Límites del perfilador como evidencia

Fuente: MongoDB Manual, "Database Profiler"

3.2 | La bitácora de mongod

Cada línea es un documento JSON: t (fecha), s (severidad), c (componente: NETWORK, ACCESS, COMMAND), id, ctx (conexión, por ejemplo conn12), msg y attr.

function bitacora() {
  return db.adminCommand({ getLog: "global" }).log.map(l => JSON.parse(l))
}
bitacora().filter(e => e.c === "ACCESS").slice(-5)

Fuente: MongoDB Manual, "Log Messages", "getLog" y "Self-Managed Configuration File Options"

Ejemplo guiado: acceso fallido en mongod

bitacora()
  .filter(e => e.c === "ACCESS" && e.msg === "Failed to authenticate")
  .map(e => ({ t: e.t, id: e.id, ctx: e.ctx, user: e.attr.user, client: e.attr.client, error: e.attr.error, result: e.attr.result }))

{
  t: { '$date': '2026-10-25T22:52:58.122+00:00' },
  id: 5286307, ctx: 'conn41', user: 'app_ventas', client: '127.0.0.1:37276',
  error: 'AuthenticationFailed: SCRAM authentication failed, storedKey mismatch',
  result: 18
},
{
  ..., user: 'usuario_inexistente',
  error: 'UserNotFound: Could not find user "usuario_inexistente" for db "comercial"',
  result: 11
}

Un acceso exitoso aparece como "Successfully authenticated" con result: 0 y el nombre de la aplicación en attr.doc.application.name.

Ejemplo guiado: correlacionar por conexión

{ ctx: 'conn31', msg: 'Profiler settings changed',
  attr: { from: { level: 0, ... }, to: { level: 1, ..., filter: { ... } }, db: 'comercial' } }

El evento no dice quién hizo el cambio. Sí dice qué conexión:

bitacora().filter(e => e.ctx === "conn31" && e.msg === "Successfully authenticated")
          .map(e => ({ t: e.t, ctx: e.ctx, user: e.attr.user, db: e.attr.db }))

[ { t: { '$date': '2026-10-25T22:52:56.959+00:00' }, ctx: 'conn31', user: 'admin', db: 'admin' } ]

3.1 | Cambios de privilegios: el límite más importante

db.grantRolesToUser("app_ventas", [{ role: "dbAdmin", db: "comercial" }])

En la verificación del laboratorio, el cambio no apareció en system.profile ni en la bitácora de mongod.

Control compensatorio: instantáneas periódicas de privilegios.

db.getSiblingDB("auditoria").instantaneas_privilegios.insertOne({
  momento: new Date(),
  tomada_por: db.runCommand({ connectionStatus: 1 }).authInfo.authenticatedUsers,
  usuarios: db.getUsers().users.map(u => ({ user: u.user, db: u.db, roles: u.roles }))
})

3.1 | Lo que responde una instantánea

3.2 | Comparación de los tres escenarios

"Documentado" significa descrito en el manual oficial de MongoDB, no practicado en la materia

Relación con el Laboratorio 02

3.2 | Tres condiciones de la evidencia

REGISTRO      →   el evento quedó escrito
CONSERVACIÓN  →   el registro sigue existiendo, íntegro y protegido, cuando se necesita
INTERPRETACIÓN →  alguien puede leerlo y responder preguntas concretas

3.2 | Cómo se pierde la evidencia sin que nadie la borre

3.2 | Criterio de conservación

Fuente: NIST SP 800-92, "Guide to Computer Security Log Management"

Ejemplo: un criterio de conservación razonado

3.2 | Interpretar es responder preguntas

3.2 | Reconstruir una cronología

Fragmento de una ejecución verificada del Laboratorio 01:

Actividad 5: Interpretación y conservación

1. Con tu bitácora de PostgreSQL o de MongoDB, interpreta al menos cuatro eventos distintos.
2. Indica qué prueba y qué no prueba cada uno.
3. Propón cuánto tiempo conservarías ese tipo de bitácora y justifica con sensibilidad, obligaciones y espacio.

3.3 | Política no es procedimiento

3.3 | Las seis políticas prácticas

3.3 | Plantilla mínima

POL-0X — Nombre

Objetivo:      qué riesgo reduce
Alcance:       datos, sistemas y ambientes
Regla:         una a tres oraciones verificables
Responsable:   quién decide / quién ejecuta
Excepciones:   cuándo puede omitirse y quién lo autoriza
Evidencia:     qué registro demuestra que se cumplió
Revisión:      cada cuánto se revisa

Ejemplo: una política completa

POL-06 — Cambios en producción

Objetivo:     evitar cambios de estructura o de privilegios no autorizados en producción
Alcance:      base comercial (PostgreSQL y MongoDB), ambiente de producción
Regla:        todo cambio en producción requiere una solicitud con folio aprobada por el
              Comité de cambios y se ejecuta dentro de la ventana autorizada. El DBA concilia
              cada mes las sentencias CREATE, ALTER, DROP, GRANT y REVOKE de la bitácora con
              las solicitudes aprobadas
Responsable:  decide el Comité de cambios, ejecuta el DBA, concilia una persona distinta del DBA
Excepciones:  emergencia que detiene la operación. Se ejecuta con aviso al propietario y la
              solicitud se registra en las 24 horas siguientes
Evidencia:    tabla gobierno.solicitudes_cambio + bitácora exportada con hash + acta de conciliación
Revisión:     anual, o después de cualquier cambio no autorizado detectado

3.3 | Verificable o no verificable

3.3 | Las políticas deben ser coherentes entre sí

Actividad 6: Políticas prácticas

1. Redacta POL-01 a POL-06 con la plantilla, para la base comercial de Comercializadora Norte.
2. Cada Evidencia nombra un registro concreto, o indica que hoy no existe.
3. POL-02 y POL-04 son reglas de decisión: "El procedimiento técnico se definirá en la Unidad V".
4. Revisa que no se contradigan.

3.4 | El gobierno práctico no es burocracia

Fuente: DAMA-DMBOK, marco profesional de gestión de datos. Aquí se trabaja su forma mínima operativa

Ejemplo guiado: calidad desde la operación

SELECT lower(correo) AS correo_normalizado, count(*) AS registros,
       string_agg(id::text, ', ') AS ids
FROM clientes GROUP BY lower(correo) HAVING count(*) > 1;

SELECT id, nombre, rfc FROM clientes
WHERE rfc IS NULL OR rfc !~ '^[A-ZÑ&]{3,4}[0-9]{6}[A-Z0-9]{3}$';

   correo_normalizado   | registros | ids
------------------------+-----------+------
 ana.lopez@example.test |         2 | 1, 7

 id |   nombre   |     rfc
----+------------+--------------
  7 | Ana Lopez  | LOAA850315AB
  8 | Jorge Díaz |

La expresión regular verifica el formato para la práctica. No valida el RFC ante el SAT

3.4 | El DBA detecta, el propietario decide

3.4 | Propietario, custodio y usuario

3.4 | Catálogo y diccionario

Ejemplo guiado: diccionario dentro del motor

COMMENT ON COLUMN clientes.rfc IS 'RFC del cliente. Dato personal. Uso: facturación. Cambios auditados en auditoria.cambios_clientes.';

SELECT c.column_name AS columna, c.data_type AS tipo, c.is_nullable AS acepta_nulos,
       col_description('public.clientes'::regclass, c.ordinal_position) AS descripcion
FROM information_schema.columns c
WHERE c.table_schema = 'public' AND c.table_name = 'clientes'
ORDER BY c.ordinal_position;

 columna |       tipo        | acepta_nulos |                     descripcion
---------+-------------------+--------------+------------------------------------------------------
 id      | bigint            | NO           | Identificador interno del cliente. Generado por el sistema.
 correo  | character varying | NO           | Correo de contacto. Dato personal. Uso: notificaciones al cliente.
 rfc     | character varying | YES          | RFC del cliente. Dato personal. Uso: facturación. Cambios auditados...

Fuente: documentación oficial de PostgreSQL, "COMMENT" e "information_schema.columns"

Ejemplo: exportar el diccionario a un archivo

psql -U postgres -d comercial --csv -c "SELECT c.column_name AS columna, c.data_type AS tipo, c.character_maximum_length AS longitud, c.is_nullable AS acepta_nulos, col_description('public.clientes'::regclass, c.ordinal_position) AS descripcion FROM information_schema.columns c WHERE c.table_schema = 'public' AND c.table_name = 'clientes' ORDER BY c.ordinal_position" > evidencias/diccionario-clientes.csv

--csv hace que psql entregue el resultado separado por comas, listo para abrirse en una hoja de cálculo.

columna,tipo,longitud,acepta_nulos,descripcion
id,bigint,,NO,Identificador interno del cliente. Generado por el sistema.
nombre,character varying,120,NO,Nombre completo. Dato personal identificador directo.

3.4 | Catálogo mínimo de la base comercial

Ejemplo guiado: registro de cambios y conciliación

CREATE TABLE gobierno.solicitudes_cambio (
    folio TEXT PRIMARY KEY, descripcion TEXT NOT NULL, solicitado_por TEXT NOT NULL,
    aprobado_por TEXT, ambiente TEXT NOT NULL CHECK (ambiente IN ('desarrollo','pruebas','produccion')),
    fecha_aprobacion TIMESTAMPTZ, ventana_inicio TIMESTAMPTZ, ventana_fin TIMESTAMPTZ
);

Conciliación: comparar lo que ocurrió (bitácora, consultada con dba.bitacora) con lo que estaba autorizado (registro)

3.4 | Afirmación o evidencia

3.4 | El expediente de auditoría interna

EXPEDIENTE.md
 1. Alcance
 2. Configuración de auditoría             (E1, E3, E6)
 3. Bitácora interpretada                  (al menos tres eventos)
 4. Elementos de gobierno                  (responsables, catálogo, diccionario)
 5. Conservación
 6. Políticas                              (POL-01 a POL-06)
 7. Conciliación de cambios
 8. Hallazgos                              (severidad, impacto, recomendación, decisión)
 9. Limitaciones y riesgos aceptados       (verificado vs. documentado)
10. Índice de evidencias con hash

Actividad 7: Evidencia oficial de la unidad

Errores conceptuales frecuentes

Mecanismos complementarios

                 ¿Qué ocurrió en clientes?
                           │
   ┌──────────────┬────────┴────────┬──────────────────┐
   ▼              ▼                 ▼                  ▼
Bitácora       Tabla de          pgaudit           Profiler + log
PostgreSQL     auditoría         (opcional)        MongoDB
quién, cuándo, valor antes       lecturas de        operaciones,
qué sentencia  y después         columnas           accesos
   └──────────────┴────────┬────────┴──────────────────┘
                           ▼
       Políticas + responsables + catálogo + diccionario
                           ▼
              Expediente para auditoría interna

Pregunta de cierre

La base de datos tiene roles correctos, la bitácora en mod, una tabla de auditoría con disparador y un perfilador activo en MongoDB. Pero nadie tiene asignado el dato, no hay política de retención de bitácoras y los servidores se reinstalan cada semana sin conservar sus archivos de bitácora.

¿Puede demostrarse quién cambió el RFC hace un mes?

¿Qué sigue?

Referencia rápida del DBA

Referencias