CreaRack-SL
Vista limpiaEditar

Descripción

Implementación de auditoría transversal en mutaciones sensibles de los módulos ITSM, Alerting, Wireless y UPS (seguimiento SA4/SA5 de Auditoría Suprema). Registra quién hizo qué, cuándo y en qué organización, para todas las acciones que implican cambios de configuración crítica.

Motivación

Las mutaciones en políticas SLA, canales de notificación, alertas y configuraciones de infraestructura (wireless/UPS) carecían de trazabilidad. Un operador eliminaba una alerta o actualizaba un escalado sin registro de auditoría. Esto viola requisitos de compliance y dificulta el debugging de cambios inesperados.

Alcance

Categorías auditadas

  1. ITSM (canales, escalados, mantenimiento, runbooks):

    • sla.update — Cambio de política SLA (ventana de reconocimiento)
    • channel.create / update / delete — Canales de notificación (webhook, email, etc.)
    • escalation.create / update / delete — Políticas de escalado multi-nivel
    • maintenance.create / update / delete — Ventanas de mantenimiento
    • runbook.create / delete / apply — Runbooks (creación, eliminación, aplicación a insights)

  2. OBSERVATORY (alertas, wireless, UPS):

    • alert.delete — Eliminación de alerta (potencial silenciamiento)
    • alert.resolve — Resolución manual de evento
    • alert.threshold — Cambio de umbral de disparo
    • wireless.deep_discover — Trigger de descubrimiento de APs
    • wireless.group_assign — Asignación de grupos a APs
    • ups.deep_discover — Trigger de descubrimiento de UPS
    • ups.group_assign — Asignación de grupos a UPS

No auditadas (por diseño)

  • Lecturas (GET, list, retrieve) — No son mutaciones
  • Cambios cosméticos (dashboard layout, notas, orden de columnas)
  • Operaciones internas del sistema (jobs, rebalances)

Implementación

Helper genérico: log_action()

from core.utils import log_action

# En cualquier endpoint:
log_action(request, "ITSM", "channel.create", f"id={c.id} name={c.name} type={c.channel_type}")

Ubicado en core.utils.audit.log_action():

  • Best-effort: Fallos de logging nunca rompen el request
  • Aislado org+user: Resuelve automáticamente desde request y contexto RLS
  • Anónimo-safe: Si el usuario no está autenticado, registra user=None
  • Parámetros:
    • request — Contexto HTTP (usuario, org, IP)
    • category — Constante ("ITSM", "OBSERVATORY", etc.)
    • action — Identificador de la acción ("channel.create")
    • details — Payload opcional (JSON o texto libre)
    • level — Severity ("INFO" por defecto; puede ser "WARN", "ERROR")

Modelo: Extensión de SystemLog

La migración 0023_alter_systemlog_category añade dos categorías nuevas:

  • ITSM → Auditoría de ITSM Management
  • OBSERVATORY → Auditoría de Observatory Management (alertas, wireless, UPS)
CATEGORY_CHOICES = [
    ("AUTH", "Authentication"),
    ("RACK", "Rack Management"),
    ("BLUEPRINT", "Blueprint Management"),
    ("SYSTEM", "System"),
    ("NETWORK", "Network Management"),
    ("ITSM", "ITSM Management"),           # NEW
    ("OBSERVATORY", "Observatory Management"),  # NEW
]

Endpoints modificados

ArchivoMutacionesAcción
monitoring/api/itsm.py9SLA update, channel create/update/delete, escalation create/update/delete, maintenance create/update/delete
monitoring/api/itsm_runbooks.py3runbook create/delete/apply
monitoring/api/alerts.py3alert delete/resolve/threshold
monitoring/api/wireless.py2deep_discover, group_assign
monitoring/api/ups.py2deep_discover, group_assign
Total19—

Tests

Cobertura mínima en tests/api/test_monitoring_sa4_sa5.py::TestAuditLogs:

  • test_channel_create_writes_audit_entry: Verifica que POST /itsm/notifications/channels registre category=ITSM, action=channel.create
  • test_alert_delete_writes_audit_entry: Verifica que DELETE /alerts/{id} registre category=OBSERVATORY, action=alert.delete

Ambos validan que:

  • El user es el operador
  • La organization es correcta
  • El action y category se registran

Impacto operacional

  • Performance: Escritura asincrónica en SystemLog + índice en (organization, category, action, timestamp)
  • Almacenamiento: ~200 bytes por entrada (campos pequeños, sin blob); estimar 1-2 MB/mes para orgs activas
  • Compliance: Trazabilidad completa de mutaciones críticas → pasaporte para auditorías SOC2/ISO27001
  • Debugging: Responder “¿quién cambió la política SLA a las 15:30?” en <100ms

Rollout

  1. Migración silenciosa (0023) — no requiere downtime
  2. log_action() available inmediatamente en core.utils
  3. Endpoints comienzan a emitir logs tras el deploy
  4. Retroactividad: 0 (logs anteriores no existirán; esto es punto de inicio)

Véase también

  • [[entity—core—service—log-action]] — Documentación técnica del helper genérico de auditoría
  • [[entity—core—model—systemlog]] — Modelo de datos SystemLog extendido
  • [[decision—20260607—audit-logs-best-effort]] — ADR sobre la garantía best-effort

Referenciado desde

Inicio
Yo