Architecture de sécurité

Limites de confiance

┌─────────┐  HTTPS + Bearer + Ed25519-sig   ┌──────────┐    pgx    ┌──────────────┐
│  Agent  │ ──────────────────────────────▶ │  Hub API │ ────────▶ │ TimescaleDB  │
└─────────┘                                 └──────────┘           └──────────────┘
     │                                          │                        │
     │  WebSocket (urgence + RPC de console)     │                        │
     ▼                                          ▼                        ▼
  Honeypots                                Tableau de bord                 Sécurité par
  Process DNA                             (Next.js +              tenant_id

  Agent → Hub : jeton Bearer + X-Monsys-Signature (Ed25519 sur sha256(body))
  Hub   → Agent : Ed25519 tokens d'urgence / de session de console (5-vérifications valident)

Modèle de confiance

L’agent a confiance dans le hub — pour la vérification des signatures Ed25519 sur les tokens d’urgence.
Le hub ne fait pas confiance à l’agent — chaque payload reçu est validé, taille de batch limitée, limite de taux imposée.
Le hub a confiance dans la session de navigateur uniquement via des cookies signés HMAC (HttpOnly, Secure, SameSite=Lax, 8u TTL).
Isolation multi-tenant — les politiques de sécurité par niveau de ligne de Postgres empêchent que tenant A voie les données de tenant B, même en cas d’une erreur SQL dans le code du hub.

Cryptographie

Objectif	Algorithme
Cookie de session HMAC	SHA-256
Mot de passe	bcrypt cost 10
Tokens d’urgence	Ed25519
Signature de payload agent	Ed25519 (clef de paire par agent, TOFU pin)
TOTP (2FA login)	RFC 6238 / SHA-1
TLS	Let’s Encrypt (TLS 1.3)
Signature de webhook	HMAC-SHA256
Stockage du jeton agent	Hash SHA-256, jamais en clair
Intégrité de la session de console	SHA-256 sur journal d’audit append-only

Intégrité de l’agent

Depuis mai 2026, le hub exige des signatures Ed25519 sur chaque payload reçu dès que la clé publique de l’agent est pinée. La volatilité des jetons ne suffit pas — voir Signature de payload agent.

Le hub tourne un IntegrityCheckWorker qui cherche six catégories d’anomalies toutes les 10 minutes (drift horaire, métriques plates, downgrade de version, payload non signé, signature invalidée, anomalie de cadence). Les items ouverts nécessitent une revue administrative ; les items résolus restent enregistrés comme traçage d’audit. Voir Surveillance de l’intégrité de l’agent.

Secrets multi-étages

Trois types de secrets, chacun rotatif séparément :

Secret	Stockage	Point de rotation
Jeton Bearer agent	`/etc/monsys/agent.toml` (hôte)	`POST /api/v1/agents/:id/rotate-token`
Clé de signature agent	`/var/lib/monsys/agent-signing.key`	`POST /api/v1/agents/:id/rotate-signing-key`
Clé privée Ed25519 du hub	`HUB_EMERGENCY_PRIVATE_KEY` env (hub)	manuel via script de rotation de clés

Voir Rotation de jetons pour la procédure.

Ce que Monsys ne protège pas

Une API hub compromis peut donner des instructions à tous les agents. Protégez l’OS du hub (firewall, mise à jour OS, MFA sur SSH).
Un hôte agent compromis peut mentir sur sa propre telemetrie. Détection : comparaison entre plusieurs hôtes, processus DNA.
Menaces internes — un propriétaire légitime peut lancer des actions d’urgence. Mitigation : journal d’audit, approbation 2-of-N facultative pour les actions de niveau 3 (en playbooks).