Operaciones y Administración → Auditoría de configuración

Auditoría de configuración

1) Objetivo y valor

La auditoría de configuraciones garantiza la rendición de cuentas probada y la repetibilidad de los cambios: quién, cuándo y qué ha cambiado; lo que está justificado; cómo se verifica; Cómo hacer retroceder. Esto reduce el riesgo de incidentes, filtraciones de secretos, incumplimiento de cumplimiento y revisiones «encubiertas» en la venta.

• Fuente única de la verdad (SoT) para las configuraciones.
• Seguimiento completo de los cambios (fin a fin).
• Versiones predecibles y reversión rápida.
• Cumplimiento de normas reglamentarias y políticas de seguridad.

2) Alcance

Infraestructura: manifiestos Terraform/Helm/Ansible/K8s, ACL/WAF/CDN de red.
Confecciones de aplicaciones: archivos 'yaml/json/properties', banderas de fichas, límites/cuotas.
Secretos y claves: vault/kms, certificados, tokens, contraseñas.
Pipelines de datos: diagramas, transformaciones, programaciones ETL/streams.
Integraciones: PSP/KYC/proveedores, webhooks, políticas retry/timeout.
Observabilidad: reglas de alertas, dashboards, SLO/SLA.

3) Principios

Config as Data: artefactos declarativos, versionables, probados.
Inmutabilidad e idempotencia: reproducibilidad del medio a partir del código.
Esquemas y contratos: validación estricta (JSON-Schema/Protobuf), back/forward-compatibilidad.
Minimizar las revisiones manuales: cambios sólo a través de MR/PR.
Reparto de responsabilidades (SoD) y 4-eyes: ¡autor! = deploer; un rugido obligatorio.
Atribución y firmas: firmas de commits/lanzamientos, attestations de artefactos.

4) Arquitectura de auditoría

1. SCM (Git) como SoT: todas las configuraciones del repositorio, la rama 'main' está protegida.

• Config Registry (catálogo de confecciones, propiedad, SLA, entorno),
• Registro de Schema (versiones de esquemas de configuraciones/eventos),
• Motor de políticas (OPA/Conftest): conjunto de comprobaciones.
• 3. Gafas CI/CD: formato/esquema → comprobación estática de → checks de políticas → exploración secreta → dry-run → plan de cambios.
• 4. Entrega: GitOps (por ejemplo, ArgoCD/Flux) con detector de drift y logotipos de audit de aplicaciones.
• 5. Evidence Store: almacenamiento de artefactos de auditoría (plan, registros, firmas, builds, SBOM).
• 6. Registro de actividades: Registro de eventos (append-only) sin cambios de 'CREATE/APPROVE/APPLY/ROLLBACK/ACCESS'.

5) Modelo de datos de auditoría (mínimo)

Сущности: `ConfigItem(id, env, service, owner, schema_version, sensitivity)`

События: `change_id, actor, action, ts, diff_hash, reason, approvals[]`

Артефакты: `plan_url, test_report_url, policy_report, signature, release_tag`

Conexiones: RFC/ticket ↔ PR ↔ deba (sha) ↔ grabación de liberación ↔ monitoreo de SLO.

6) Proceso de cambio (de extremo a extremo)

1. RFC/ticket → objetivo, riesgo, retroceso.
2. PR/MR → linting, validación esquemática, verificaciones de políticas, secreto-escaneo.
3. Plan/previsualización → dry-run/plan, recursos diff, estimación de valor/impacto.
4. Approve (4-eyes/SoD, la etiqueta AMB a alto riesgo).
5. Deploy (por ventana/calendario) → GitOps aplica; activado drift-alerting.
6. Verificación → smoke/SLO-gardraila, confirmación del resultado.
7. Archivado de pruebas → tienda de noticias; Actualización del diccionario de confecciones.

7) Políticas y normas (ejemplos)

SoD: el autor de PR no se frunce en el prod.
Límite de tiempo: prod-deploy fuera de «freeze» está prohibido.
Scope: cambiar claves sensibles requiere 2 apruvers de Security/Compliance.
Secretos: prohibido guardar en repos; sólo referencias a la ruta de acceso vault + rol de acceso.
Redes: ingress con '0. 0. 0. 0/0 'prohibido sin excepción temporal y TTL.
Alertas: está prohibido reducir la criticidad de la P1 sin AMB.

8) Control de secretos

Almacenamiento en Vault/KMS, TTL corto, rotación automática.
Scanning secreto en CI (patrones de clave, high-entropy).
Aislamiento de secretos por entorno/roles; privilegios mínimos necesarios.
Cifrado «en el cable» y «en reposo»; registros de auditoría cerrados de acceso a secretos.

9) Herramientas (variable)

Lint/Schema: `yamllint`, `jsonschema`, `ajv`, `cue`.
Policy: OPA/Conftest, Checkov/tfsec/kube-policies.
GitOps: ArgoCD/Flux (drift detection, audit, RBAC).
Secrets: HashiCorp Vault, cloud KMS, cert managers.
Escáneres: trufflehog, gitleaks (secretos); OPA/Regula (reglas).
Informes: exportación de registros en DWH/BI, conjunto con el sistema de incidentes y cambios.

10) Ejemplos de reglas y artefactos

JSON-Schema para configuración de límites

json
{
"$schema": "http://json-schema. org/draft-07/schema#",
"title": "limits",
"type": "object",
"required": ["service", "region", "rate_limit_qps"],
"properties": {
"service": {"type":"string", "pattern":"^[a-z0-9-]+$"},
"region": {"type":"string", "enum":["eu","us","latam","apac"]},
"rate_limit_qps": {"type":"integer","minimum":1,"maximum":5000},
"timeouts_ms": {"type":"integer","minimum":50,"maximum":10000}
},
"additionalProperties": false
}

Conftest/OPA (rego) - prohibición '0. 0. 0. 0/0` в ingress

rego package policy. network

deny[msg] {
input. kind == "IngressRule"
input. cidr == "0. 0. 0. 0/0"
msg:= "Ingress 0. 0. 0. 0/0 is not allowed. Specify specific CIDRs or throw an exception with TTL"
}

Conftest/OPA - SoD (el prod no es mermado por el autor)

rego package policy. sod

deny[msg] {
input. env == "prod"
input. pr. author == input. pr. merger msg: = "SoD: PR author cannot hold in prod."
}

SQL (DWH) - Quién redujo la crítica de alertas en un mes

sql
SELECT actor, COUNT() AS cnt
FROM audit_events
WHERE action = 'ALERT_SEVERITY_CHANGED'
AND old_value = 'P1' AND new_value IN ('P2','P3')
AND ts >= date_trunc('month', now())
GROUP BY 1
ORDER BY cnt DESC;

Ejemplo Git commit message (campos obligatorios)

feat(config/payments): raise PSP_B timeout to 800ms in EU

RFC: OPS-3421
Risk: Medium (PSP_B only, EU region)
Backout: revert PR + restore timeout=500ms
Tests: schema ok, conftest ok, e2e ok

11) Monitoreo y alerting

Drift-detect: configuración en el clúster ≠ Git → P1/P2 señal + auto-remediación (reconcile).
Cambio de alto riesgo: cambiar redes/secretos/políticas - notificación en # security-ops.
Desbloqueo: deploy sin plan/firma/informes - bloque o alerta.
Expired assets: fechas de validez de certificados/claves → alertas pro-activas.

12) Métricas y KPI

Audit Coverage% es la proporción de confiscaciones bajo esquemas/políticas/escáneres.
Drift MTTR es el tiempo medio de eliminación de la deriva.
Policy Compliance% - Paso de directivas en PR.
Secrets Leak MTTR: desde la fuga hasta la revocación/rotación.
Backout Rate - Porcentaje de revisiones de cambios de configuración.
Mean Change Size - Diff medio por fila/recurso (menos - mejor).

13) Informes y cumplimiento

Rastros de auditoría: almacenamiento ≥ 1-3 años (según los requisitos), almacenamiento de información inmutable.
Regulación: ISO 27001/27701, SoD similar a SOX, GDPR (PII), requisitos de la industria (iGaming: contabilidad de cambios en los cálculos de GGR/NGR, límites, reglas de bonificación).
Informes mensuales: cambios superiores, infracciones de políticas, deriva, certificados caducados, estado de rotación.

14) Playbucks

A. Se detectó una deriva en la venta

1. Bloquear auto-deploy para el servicio afectado.
2. Quitar el snapshot del estado actual.
3. Comparar con Git, iniciar 'reconcile' o retroceso.
4. Cree un incidente P2, especifique el origen de la deriva (kubectl/consola manual).
5. Incluir protección: prohibir cambios directos (PSP/ABAC), notificar a los propietarios.

B. Certificado PSP caducado

1. Cambiar a la ruta de espera/PSP, bajar el tiempo de espera/retroceso.
2. Emitir un nuevo certificado a través del proceso PKI, actualizar la configuración a través de Git.
3. Smoke-test, recuperar el tráfico, cerrar el incidente, realizar un post-mortem.

C. El secreto llegó a PR

1. Revocar la clave/token, activar la rotación.
2. Reescribir el historial/eliminar el artefacto de los cachés, formalizar RCA.
3. Agregar una regla al analizador secreto, entrenar al equipo.

15) Anti-patrones

Correcciones manuales «en venta» sin rastro y retroceso.
Confecciones sin esquemas y sin validación.
Secretos en variables Git/CI sin KMS/Vault.
Monorepo con el equivalente de «super-derecho global».
GitOps «sordo» sin alertas de drift y registros de aplicaciones.
Las enormes relaciones públicas «todo a la vez» son una atribución difusa y un alto riesgo.

16) Hojas de cheques

Antes del merge

• Se han completado el esquema y los linderos
• Políticas de OPA/Conftest «verdes»
• Secret-scan - «puramente»
• Plan/diff aplicado, riesgo evaluado, backout listo
• 2 apruva (prod) y SoD cumplidos

Antes de deploy

• Ventana de lanzamiento y calendario verificados
• Drift-monitoreo está activo
• SLO-gardrailes están personalizados, las pruebas de humo están listas

Mensualmente

• Rotación de claves/certificados
• Inventario de propietarios y derechos
• Reglamento de AVR/exenciones (TTL)
• Prueba de incidentes de reproducción (fire-drill)

17) Consejos de diseño

Aplastar los cambios en pequeños diffs; Un PR es un objetivo.
Plantillas de PR/commits obligatorias con RFC/riesgo/eliminación.
Para las confecciones dinámicas, utilice los «centros de configuración» con auditoría y rollback.
Versione los esquemas; prohíba el breaking sin migraciones.
Visualice la «tarjeta de configuración»: qué, dónde, quién es administrado.

18) Integraciones con gestión de cambios e incidentes

PR ↔ RFC ↔ calendario de lanzamientos ↔ incidentes/post-mortem.
Ajuste automático de métricas (SLO/business) a versiones de configuraciones.
Creación automática de tareas para eliminar marcas/excepciones antiguas (TTL).

19) Resultado

La auditoría de configuraciones no es un «informe en papel», sino un mecanismo operativo de fiabilidad: las configuraciones son datos, cambios - controlables y verificables, secretos - bajo llave, y toda la historia es transparente y verificable. Así se construye una plataforma sostenible, cumplida y predecible.