Com protegeix Hermes Haven l'accés a un Hermes Agent?
Hermes Haven col·loca un gateway HTTPS davant dels agents allotjats. nginx termina TLS i encamina el trànsit entrant a l'agent corresponent en lloc de presentar-lo mitjançant una IP pública directa. La configuració auditada permet TLS 1.2 i TLS 1.3; no obliga a utilitzar exclusivament TLS 1.3. [C05][C22]
L'accés al panell de l'agent utilitza un proveïdor d'identitat OIDC operat per HermesHaven. El flux de compte predeterminat exigeix 2FA, tot i que la implementació conté un ajust que ha de romandre actiu perquè «2FA a tots els comptes» continuï sent cert. [C09][C17]
Els agents allotjats estan aïllats entre ells?
Cada agent rep una xarxa overlay de Docker separada. L'evidència avala que els agents no es poden comunicar directament entre ells. No avala expressions més àmplies com «zero trànsit creuat» o «sense accés a internet»: hi ha serveis compartits de plataforma i els agents tenen connectivitat sortint. [C06][C07]
| Control o límit | Afirmació publicable | Estat de l'evidència |
|---|---|---|
| Gateway entrant | El trànsit entrant s'encamina pel gateway HTTPS de la plataforma. | Verificat [C22] |
| Xarxa per agent | Els agents no es poden comunicar directament entre ells. | Amb matís [C06] |
| Accés sortint | Els agents poden accedir a internet per a eines i proveïdors externs. | Límit verificat [C07] |
| Identitat del panell | HermesHaven opera el proveïdor OIDC utilitzat pels panells d'agent. | Verificat [C17] |
| 2FA de compte | Exigit en el flux predeterminat; cal comprovar la configuració de producció. | Verificat amb nota [C09] |
| Runtime sense root | L'auditoria no ho va verificar a la imatge upstream de Hermes Agent. | No demostrat [C08] |
Les dades de l'agent estan xifrades?
El trànsit del gateway públic admet TLS 1.2 i TLS 1.3. L'auditoria no va trobar xifratge a nivell de disc per als volums persistents ni una implementació que avali AES-256 en repòs o xifratge amb embolcall. Els fitxers de l'agent a l'emmagatzematge RBD/ext4 auditat no s'han de descriure com a xifrats en repòs. [C05]
On s'emmagatzemen i es processen les dades?
La capa auditada utilitza volums persistents Ceph/RBD amb redundància d'emmagatzematge. És una afirmació d'arquitectura de durabilitat, no de xifratge ni de compliment normatiu. [C25]
La inferència segueix un camí separat. Els models premium i els proveïdors configurats per l'usuari poden processar peticions fora de la UE, de manera que «cap dada surt de la UE» és fals. El proveïdor escollit determina on es pot processar la petició. [C03]
Consulta l'explicació de routing a Models.
L'arquitectura demostra el compliment del RGPD?
No. L'auditoria no va trobar política de privacitat, registres de tractament, contracte d'encarregat o altra documentació legal suficient per establir el compliment del RGPD. L'arquitectura pot documentar controls i fluxos, però no estableix per si sola una conclusió legal. [C01]
Quines afirmacions de seguretat no s'han d'utilitzar?
No publiquis amb l'evidència actual:
- «AES-256 en repòs» o «xifratge amb embolcall». [C05]
- «Cap dada surt de la UE». [C03]
- «Sense accés a internet». [C07]
- «Zero vectors d'escapada». [C08]
- «Compleix el RGPD per disseny». [C01]
- «Tota la infraestructura és a Grenoble». [C02]
Consulta el context operatiu a Plataforma i el repartiment de responsabilitats a Comparar self-hosting i VPS.
Què ha de demanar un revisor de seguretat?
Demana el diagrama de xarxa vigent, l'inventari de fluxos per proveïdor, la política de còpies de seguretat, evidència de restauració, la configuració de control d'accés, el disseny de secrets i el roadmap de xifratge. La disponibilitat, els objectius de recuperació i el compliment legal han de provenir de documents revisats.