Problema

En entornos con cientos o miles de servidores Linux, la trazabilidad de cambios suele estar fragmentada. Los equipos de operaciones gestionan parches en un sistema (por ejemplo, un repositorio apt o dnf), la autorización de esos cambios se registra en una herramienta de tickets o una hoja de cálculo, y el acceso real a la máquina se controla mediante bastiones, claves estáticas o soluciones de gestión de secretos. Cuando un auditor pide evidencia de que “Juan Pérez estuvo autorizado a aplicar el parche X en la máquina host01 el 12‑03‑2024 y lo hizo con su propia credencial”, el responsable debe combinar logs de gestión de paquetes, registros de bastión y auditorías de tickets. Esa costosa costura manual genera errores, lagunas y, en el peor caso, incumplimiento.

El patrón subyacente es la ausencia de una fuente única de verdad que relacione autorización, acceso y ejecución. Sin ella, cualquier proceso de revisión o respuesta a incidentes se vuelve una caza del tesoro.

Causa

  1. Silos de herramientas – Cada fase del ciclo de vida del cambio (aprobación, acceso, ejecución) se implementa con software distinto que no comparte un modelo de datos común.
  2. Credenciales estáticas – Claves SSH persistentes o usuarios locales hacen que la pista de auditoría dependa del nombre de login, que puede cambiar o ser reutilizado.
  3. Logs dispersos – Los registros de apt, dnf, journalctl, bastiones y sistemas de tickets se almacenan en servidores diferentes, sin correlación temporal fiable.
  4. Políticas de autorización ad‑hoc – Falta de un motor central que evalúe roles y requiera step‑up authentication para operaciones críticas.
  5. Ausencia de revocación dinámica – Cuando se revoca acceso, los certificados o claves ya emitidos siguen válidos hasta su expiración, dejando una ventana de exposición.

Estas causas aparecen con frecuencia en infraestructuras híbridas donde se combinan redes privadas y públicas, y donde el equipo de seguridad necesita pruebas rápidas y verificables.

Solución

Un enfoque reutilizable consiste en centralizar la lógica de autorización, emisión de credenciales y registro de auditoría en un único servicio API. La arquitectura típica incluye:

  1. Backend FastAPI (o cualquier framework RESTful) – Actúa como punto de entrada para todas las solicitudes de cambio. Gestiona usuarios, roles (admin, maintainer, auditor) y políticas de step‑up (TOTP, OIDC).
  2. OpenBao (o cualquier CA compatible con SSH) – Emite certificados SSH de corta duración vinculados a un identificador inmutable (praxis-user-<id>). La vida útil corta reduce la necesidad de revocación inmediata.
  3. Agente ligero en cada host – Un script o servicio que, bajo petición del backend, ejecuta el parche (apt/dnf) y reporta el resultado.
  4. Base de datos única – Almacena cada evento: solicitud de aprobación, emisión de certificado, ejecución del parche y su salida. El timestamp único permite ordenar cronológicamente todo el proceso.
  5. Modelo de “rings of trust” – Permite desplegar parches en grupos progresivos (ring 0, ring 1…) y validar comportamiento antes de escalar.

Flujo de trabajo típico

  1. Solicitud – Un maintainer abre una petición de parche mediante la UI o la API. El backend registra la solicitud con metadata (paquete, hosts objetivo, razón).
  2. Aprobación – Un admin revisa y aprueba. La aprobación se guarda como un registro firmado (por ejemplo, JWT con claim approved_by).
  3. Emisión de certificado – El backend solicita a OpenBao un certificado SSH para el praxis-user-<id> con TTL de 15 min. El certificado incluye una extensión que identifica la operación autorizada.
  4. Ejecución – El agente en el host verifica que el certificado presente la extensión esperada, ejecuta el comando de parche y envía stdout/stderr al backend.
  5. Cierre – El backend marca la operación como completada y almacena el log completo. Un auditor puede consultar el registro y obtener una vista única que muestra quién aprobó, quién ejecutó y el resultado.

Este modelo elimina la necesidad de correlacionar logs externos y garantiza que cualquier auditoría se haga contra una tabla única.

Cuándo aplicar esta solución

  • Entornos con requisitos de cumplimiento (PCI‑DSS, ISO 27001) donde se exige evidencia de autorización y ejecución.
  • Fleets de más de 50 servidores donde la gestión manual de credenciales y tickets se vuelve insostenible.
  • Infraestructura híbrida que combina bastiones, VPN y acceso directo; la solución unifica el control sin depender de un único punto de acceso.
  • Equipos que ya usan FastAPI o Python y pueden integrar rápidamente un microservicio.

No es la mejor opción cuando:

  • La organización ya cuenta con una herramienta de CM completa (Ansible, Puppet) que incluye gestión de cambios y auditoría integrada.
  • El número de hosts es muy bajo (<10) y la sobrecarga de implementar una CA y base de datos no se justifica.
  • Se necesita revocación inmediata y granular; la solución de certificados de corta vida no cubre revocación en tiempo real.

Código

# 1. Generar una CA SSH con OpenBao (asumiendo que baoctl está instalado)
baoctl ca create \
  --name praxis-ca \
  --type ssh \
  --key-type ed25519 \
  --validity 365d

# 2. Emitir un certificado de 15 minutos para el usuario praxis-user-42
baoctl sign ssh \
  --ca praxis-ca \
  --principal praxis-user-42 \
  --ttl 15m \
  --extensions "permit-pty,permit-agent-forwarding" \
  --output /tmp/praxis-user-42-cert.pub

# 3. Copiar el certificado al agente (ejemplo usando scp)
scp /tmp/praxis-user-42-cert.pub root@host01:/etc/ssh/authorized_principals/praxis-user-42

# 4. Ejecutar el parche desde el agente, usando la clave privada asociada
ssh -i ~/.ssh/praxis-user-42 -o CertificateFile=/tmp/praxis-user-42-cert.pub root@host01 \
  "apt-get update && apt-get install -y <paquete>"

Verificación

  1. Revisar la tabla de auditoría – Ejecutar una consulta en la base (por ejemplo, SELECT * FROM events WHERE host='host01' ORDER BY ts DESC LIMIT 5;) y confirmar que aparecen los campos request_id, approved_by, executed_by y result.
  2. Validar la extensión del certificado – En el host, usar ssh-keygen -L -f /etc/ssh/authorized_principals/praxis-user-42 y comprobar que la lista de extensiones coincide con la operación autorizada.
  3. Simular expiración – Esperar a que el TTL del certificado venza (15 min) y volver a intentar la conexión; el acceso debe ser denegado, confirmando que la vida corta funciona.
  4. Auditoría externa – Exportar los registros en JSON y cargar en la herramienta de auditoría para validar la cadena completa de eventos.

Notas adicionales

  • Gestión de claves privadas – Mantener la clave privada del praxis-user en un vault (HashiCorp Vault, 1Password) y rotarla cada 30 días reduce la superficie de ataque.
  • Sin CRL/OCSP – En la versión inicial no hay revocación inmediata; si se necesita revocar antes del TTL, la práctica recomendada es reducir el TTL a 5 min y forzar una renovación.
  • Persistencia de logs – Aunque Praxis no elimina logs automáticamente, se recomienda una política de retención (por ejemplo, 90 días) mediante herramientas de logrotate o un bucket S3 privado.
  • Integración con OIDC – Vincular la autenticación del backend a un proveedor de identidad (Keycloak, Azure AD) permite que los roles se sincronicen automáticamente y que el step‑up use el mismo MFA que la organización.
  • Escalado horizontal – El backend FastAPI es sin estado; colocar varios réplicas detrás de un load balancer y usar una base de datos PostgreSQL compartida permite soportar miles de solicitudes simultáneas.

Con este enfoque, la aprobación de parches, la concesión de acceso SSH y la evidencia de auditoría quedan encapsuladas en un único registro, simplificando la respuesta a auditorías y reduciendo la carga operativa.