Mantenimiento de registros y protocolos

1) Por qué se necesitan registros y protocolos

Los registros son la «caja negra» de la organización: proporcionan evidencia (evidence) para auditorías e investigaciones, reducen el riesgo operativo y regulatorio, permiten recuperar el curso de los eventos y validar la ejecución de políticas (access, retence, encriptación, KYC/AML, PCI, etc.).

• Seguimiento de acciones (quién/qué/cuándo/dónde/por qué/qué).
• Detección y contención de incidentes (controles detectives y preventivos).
• Base de pruebas para reguladores/auditores (immutabilidad).
• Análisis de rendimiento y cumplimiento de SLA/SLO.

2) Taxonomía de los registros (cobertura mínima)

Accesos e identidades (IAM/IGA): autenticación, cambio de roles, SoD, accesos JIT.
Infraestructura/nube/IaC: llamadas API, derivación de configuración, eventos KMS/HSM.
Aplicaciones/negocios: transacciones, operaciones PI/finanzas, ciclo de vida de solicitudes (DSAR).
Seguridad: IDS/IPS, EDR, DLP/EDRM, WAF, vulnerabilidad/parches, antivirus.
Red: firewall, VPN/Zero Trust, proxy, DNS.
CI/CD/DevSecOps: conjuntos, deploy, SAST/DAST/SCA, secreto-escaneado.
Datos/análisis: lineage, acceso a vitrinas, enmascaramiento/anonimización.
Operaciones: ITSM/tickets, incidentes, change-management, pruebas DR/BCP.
Vendedores/3rd-party: webhooks, federación SSO, eventos SLA.

3) Requisitos regulatorios (puntos de referencia)

GDPR/ISO 27701: minimización/enmascaramiento de PI, retén gráfico, hold legal, rastreo DSAR.
SOC 2/ISO 27001: audit trails, control de acceso a logs, comprobante de cumplimiento de controles.
PCI DSS: lógica de acceso a entornos/datos de mapas, integridad de registros, revisión diaria.
AML/KYC: trazabilidad de las inspecciones, cribado sancionador/RR, protocolos NAT/SAR.

4) Arquitectura de referencia de la lógica

1. Productores: aplicaciones, nube, red, agentes de host.
2. Bus/colectores: recepción con back-pressure, retry, TLS mTLS, deduplicación.
3. Normalización: formato único (JSON/OTel), enriquecimiento (tenant, user, geo, severity).

• Caliente (búsqueda/SIEM): 7-30 días, acceso rápido.
• Frío (objeto): meses/años, almacenamiento barato.
• Archivo de seguridad (WORM/Object Lock): inmutabilidad, recibos hash.
• 5. Integridad y firma: cadenas de hashes/merkley-árbol/marcas de tiempo.
• 6. Acceso y seguridad: RBAC/ABAC, segmentación por jurisdicciones, acceso basado en casos.
• 7. Análisis y alertas: SIEM/SOAR, ID de correlación, playbooks.
• 8. Directorios y esquemas: registro de tipos de eventos, versioning, pruebas de esquemas.

5) Políticas-como-código (ejemplos YAML)

Retencia y Legal Hold

yaml id: LOG-RET-001 title: "Access logs retention"
scope: ["iam. ","app. access"]
retention:
hot_days: 30 cold_days: 365 worm_years: 3 legal_hold: true # when Legal Hold is active, block privacy removal:
pii_mask: ["email","phone","ip"]
review: "annual"

Integridad y firma

yaml id: LOG-INT-001 title: "Signature and commercial fixation"
hashing: "SHA-256"
anchor:
cadence: "hourly"
store: "s3://evidence/anchors"
verification:
schedule: "daily"
alert_on_failure: true

6) Requisitos de calidad de los registros

Estructuración: sólo JSON/OTel, sin texto «crudo».
Sincronización de tiempo: NTP/PTP, control de drift; la entrada 'timestamp', 'received _ at'.
ID de correlación: 'trace _ id', 'span _ id', 'request _ id', 'user _ id' (alias).
Semántica de campos: diccionario (dictionario de datos) y contrato de esquema con pruebas.
Localización/idioma: los campos son claves inglesas, los valores son unificados (enum).
Volumen y política de drop: prohibición del drop incontrolable; colas/cuotas/sampling por riesgo.
Datos sensibles: enmascaramiento/tokenización; prohibición de guardar completamente los secretos/tarjetas.

7) Privacidad y minimización

Higiene PII: lógica hashes/tokens en lugar de valores; máscara estricta para correo electrónico/teléfono/IP.
Contexto: no píxelesPayload con datos personales sin fundamento.
Jurisdicciones: almacenamiento y acceso por país (residencia de datos), trazabilidad de copias.
DSAR: etiquetas de búsqueda y exportación por caso; posibilidad de imprimir informes con despersonalización.

8) Inmutabilidad y evidencia (immutabilidad)

WORM/Object Lock: prohibición de eliminar/sobrescribir en el período.
Cifrado: firma de batches; Raíces Merckley con anclaje diario.
Cadena de retención (cadena de custodia): registro de acceso, recibos hash, quits en los informes.
Verificación: comprobaciones periódicas de integridad y alertas de resincronización.

9) Control de acceso a logotipos

RBAC/ABAC: roles de «lectura/sólo búsqueda» vs «exportación/sharing».
Case-based access: acceso a logs sensibles - sólo como parte de la investigación/ticket.
Secretos/claves: KMS/HSM; rotación, split-knowledge, dual-control.
Auditoría de acceso: revista separada «quién leyó qué registros» + alertas para anomalías.

10) Métricas y lógica SLO

Registro de la ingeniería: 95 ° percentil de retraso de recepción (objetivo ≤ 60 segundos).
Drop Rate: proporción de eventos perdidos (objetivo 0; alerta> 0. 001%).
Cumplimiento de Schema:% de los eventos que han pasado la validación del esquema (≥ 99. 5%).
Cobertura:% de los sistemas bajo lógica centralizada (≥ el 98% de los críticos).
Integrity Pass: verificaciones exitosas de cadenas hash (100%).
Revisión de acceso: publicidad mensual de derechos, retraso - 0.
PII Leak Rate: PI «puros» detectados en los logs (objetivo 0 crítico).

11) Dashboards (conjunto mínimo)

Ingestion & Lag: volumen/velocidad, log, drop, fuentes «calientes».
Integrity & WORM: estado de anclaje, verificación, bloqueo de objetos.
Eventos de seguridad: correlaciones críticas, tarjeta MITRE.
Access to Logs: quién y qué leyó/exportó; anomalías.
Compliance View: estados de retén/Legal Hold, informes de auditoría, exportaciones DSAR.
Schema Health: errores de parsing/versión de esquemas, proporción de agentes obsoletos.

12) SOP (procedimientos estándar)

SOP-1: Conexión de origen de registros

1. Registro de fuente y criticidad → 2) selección de esquema/OTel → 3) TLS/mTLS, tokens →

2. dry-run en stage (validación de circuitos, máscaras PII) → 5) conectividad en prod →

3. agregar a catálogos/dashboards → 7) verificación de retención/WORM.

SOP-2: Respuesta al incidente (las revistas son como evidence)

Detect → Triage → Recolección de registros (case-scope) → Congelación (Legal Hold) →

Confirmación y anclaje hash → Análisis/línea de tiempo → Informe y CAPA → Lanzamiento de lecciones.

SOP-3: Solicitud de registro/auditoría

1. Abrir el caso y los filtros de ID de la solicitud → 2) exportar al formato deseado →

2. Verificación Legal/Compliance → 4) Resumen hash → 5) Envío y registro.

SOP-4: Revisión de acceso a logs

Certificación mensual de propietarios; las reverencias automáticas de los derechos «huérfanos»; Informe de SoD.

13) Formatos y ejemplos

Ejemplo de evento de acceso (JSON)

json
{
"ts": "2025-10-31T13:45:12. 345Z",
"env": "prod",
"system": "iam",
"event": "role_grant",
"actor": {"type": "user", "id": "u_9f1...", "tenant": "eu-1"},
"subject": {"type": "user", "id": "u_1ab..."},
"role": "finance_approver",
"reason": "ticket-OPS-1422",
"ip": "0. 0. 0. 0",
"trace_id": "2a4d...",
"pii": {"email": "hash:sha256:..."},
"sign": {"batch_id":"b_20251031_13","merkle_leaf":"..."}
}

Regla de detección (pseudo-rego)

rego deny_access_if_sod_conflict {
input. event == "role_grant"
input. role == "finance_approver"
has_role(input. subject. id, "vendor_onboarder")
}

14) Roles y RACI

15) Gestión de vendedores y cadena de suministro

En contratos: derecho de auditoría de registros, formatos, SLA de almacenamiento y acceso, WORM/immutabilidad.
Subprocesadores: registro de fuentes y retención «de extremo a extremo».
Exportación/offboarding: confirmación de destrucción e informe de resumen hash.

16) Antipattern

Registros en «texto libre», sin esquemas y correlación.
Almacenamiento sin WORM y fijación hash: controversia en la auditoría.
Datos sensibles en los logs «tal cual».
No hay sincronización de tiempo y trace_id normal.
Drop de eventos en picos de carga; ningún back-pressure.
Acceso universal a logs sin control de casos.
«Eternos» derechos de lectura de registros, sin re-certificaciones.

17) Hojas de cheques

Inicio de la función de lógica

• Se ha definido la taxonomía de las fuentes y la criticidad.
• Los esquemas y políticas de retención/Legal Hold son declarados (como-code).
• TLS/mTLS, tokens, agentes con actualización automática.
• Se han probado máscaras/tokens PII.
• WORM/Object Lock y el anclaje están incluidos.
• Los dashboards/alertas/métricas están establecidos.
• La revisión de acceso y SoD están configuradas.

Ante la auditoría/reg-interpelación

• Recogido por «audit pack»: esquemas, políticas, informes de integridad, muestras.
• Comprobar la integridad y los registros de acceso durante el período.
• Los estados de DSAR/Legal Hold están confirmados.
• Se ha generado un resumen hash de las descargas y la confirmación del envío.

18) Modelo de madurez (M0-M4)

M0 Manual: registros dispersos, sin circuitos y retenciones.
M1 Recogida centralizada: búsqueda básica, taxonomía parcial.
M2 Administrado: diagramas y políticas-como-código, dashboards, retén/WORM.
M3 Integrado: OTel-rastreo, SOAR, anclaje/merkeley, case-based access.
M4 Assured: «audit-ready on the botón», detección predictiva, control automático de integridad y recibos legalmente significativos.

19) Artículos relacionados wiki

Monitoreo continuo de cumplimiento (CCM)

KPI y métricas de cumplimiento

Legal Hold y congelación de datos

Ciclo de vida de políticas y procedimientos

Comunicación de soluciones de cumplimiento

Administrar cambios en la política de cumplimiento

Due Diligence y riesgos de externalización

Una función de lógica fuerte no es un «almacén de mensajes», sino un sistema administrado: eventos estructurados, esquemas y retenciones rigurosos, inmutabilidad y firma, privacidad predeterminada, control de acceso estricto y replicación en evidencia. Tal sistema hace que las investigaciones sean rápidas, que las auditorías sean predecibles y que los riesgos sean manejables.