Seguridad

Diseño

• Mínimo privilegio en los servidores: el usuario de inventario tiene un sudoers mínimo y de solo lectura, y las huellas de las host keys se fijan en el alta.
• Certificados SSH de vida corta firmados por la CA de OpenBao, en lugar de claves por servidor.
• Secretos por referencia: la base de datos solo guarda referencias. Los valores están en OpenBao o cifrados con AES-256-GCM.
• Separación de funciones: la API no ejecuta Ansible ni Trivy; el worker no puede leer la caja fuerte de credenciales; el gateway no recibe los secretos de la aplicación.
• Sesiones: cookie httpOnly y Secure con protección CSRF, MFA con TOTP obligatorio para administradores y reautenticación reciente para las acciones sensibles.
• Auditoría de las acciones de los usuarios.

Buenas prácticas al desplegar

• Pon un proxy con TLS delante de la web y del gateway, y usa una URL pública https.
• Guarda las claves maestras fuera del servidor y nunca en la misma copia de seguridad que la base de datos.
• Guarda fuera del servidor el material de inicialización de OpenBao y bórralo de él.

Avisar de una vulnerabilidad

Resumen de la política de seguridad (SECURITY.md) que acompañará al código:

• Versiones soportadas: solo la última versión publicada recibe parches de seguridad.
• Cómo avisar: nunca en un issue público. Por el aviso privado de vulnerabilidades del repositorio (cuando sea público) o por correo a [email protected].
• Qué incluir: versión afectada, componente, pasos para reproducirlo, impacto y, si se tiene, una prueba de concepto.
• Plazos orientativos: acuse de recibo en 72 horas, primera valoración en 7 días y parche con publicación coordinada en 90 días.
• Fuera de alcance: instalaciones mal configuradas, ataques que requieren acceso de administrador, DoS por volumen, ingeniería social y vulnerabilidades ya públicas de dependencias sin impacto específico en InfraWard.
• Crédito: con tu permiso, se te reconocerá en las notas de la versión y en el aviso de seguridad.