¿Cómo protege Hermes Haven el acceso a un Hermes Agent?
Hermes Haven coloca un gateway HTTPS delante de los agentes alojados. nginx termina TLS y enruta el tráfico entrante al agente correspondiente en vez de presentarlo mediante una IP pública directa. La configuración auditada permite TLS 1.2 y TLS 1.3; no obliga a usar exclusivamente TLS 1.3. [C05][C22]
El acceso al panel del agente usa un proveedor de identidad OIDC operado por HermesHaven. El flujo de cuenta predeterminado exige 2FA, aunque la implementación contiene un ajuste que debe permanecer activo para que «2FA en todas las cuentas» siga siendo cierto. [C09][C17]
¿Están aislados entre sí los agentes alojados?
Cada agente recibe una red overlay de Docker separada. La evidencia respalda que los agentes no pueden comunicarse directamente entre sí. No respalda expresiones más amplias como «cero tráfico cruzado» o «sin acceso a internet»: existen servicios compartidos de plataforma y los agentes tienen conectividad saliente. [C06][C07]
| Control o límite | Afirmación publicable | Estado de evidencia |
|---|---|---|
| Gateway entrante | El tráfico entrante se enruta por el gateway HTTPS de la plataforma. | Verificado [C22] |
| Red por agente | Los agentes no pueden comunicarse directamente entre sí. | Con matiz [C06] |
| Acceso saliente | Los agentes pueden acceder a internet para herramientas y proveedores externos. | Límite verificado [C07] |
| Identidad del panel | HermesHaven opera el proveedor OIDC usado por los paneles de agente. | Verificado [C17] |
| 2FA de cuenta | Exigido en el flujo predeterminado; debe comprobarse la configuración de producción. | Verificado con nota [C09] |
| Runtime sin root | La auditoría no lo verificó en la imagen upstream de Hermes Agent. | No demostrado [C08] |
¿Están cifrados los datos del agente?
El tráfico del gateway público admite TLS 1.2 y TLS 1.3. La auditoría no encontró cifrado a nivel de disco para los volúmenes persistentes ni una implementación que respalde AES-256 en reposo o cifrado con envolvente. Los archivos del agente en el almacenamiento RBD/ext4 auditado no deben describirse como cifrados en reposo. [C05]
¿Dónde se almacenan y procesan los datos?
La capa auditada usa volúmenes persistentes Ceph/RBD con redundancia de almacenamiento. Es una afirmación de arquitectura de durabilidad, no de cifrado ni cumplimiento normativo. [C25]
La inferencia sigue un camino separado. Los modelos premium y proveedores configurados por el usuario pueden procesar peticiones fuera de la UE, por lo que «ningún dato sale de la UE» es falso. El proveedor elegido determina dónde puede procesarse la petición. [C03]
Consulta la explicación de routing en Modelos.
¿Demuestra la arquitectura el cumplimiento del RGPD?
No. La auditoría no encontró política de privacidad, registros de tratamiento, contrato de encargado u otra documentación legal suficiente para establecer el cumplimiento del RGPD. La arquitectura puede documentar controles y flujos, pero no establece por sí sola una conclusión legal. [C01]
¿Qué afirmaciones de seguridad no deben utilizarse?
No publiques con la evidencia actual:
- «AES-256 en reposo» o «cifrado con envolvente». [C05]
- «Ningún dato sale de la UE». [C03]
- «Sin acceso a internet». [C07]
- «Cero vectores de escape». [C08]
- «Cumple el RGPD por diseño». [C01]
- «Toda la infraestructura está en Grenoble». [C02]
Consulta el contexto operativo en Plataforma y el reparto de responsabilidades en Comparar self-hosting y VPS.
¿Qué debe solicitar un revisor de seguridad?
Pide el diagrama de red vigente, el inventario de flujos por proveedor, la política de backup, evidencia de restauración, la configuración de control de acceso, el diseño de secretos y el roadmap de cifrado. Disponibilidad, objetivos de recuperación y cumplimiento legal deben proceder de documentos revisados.