ADR-0166 : Haute disponibilité déclarée par service dans le catalogue du Navin Manager, analyse obligatoire des fichiers par ClamAV et YARA-X avant toute ingestion

Contexte

Les clients bancaires demandent des déploiements en haute disponibilité ou en cluster qui tiennent réellement leurs promesses. Multiplier les instances ne suffit pas : chaque service a son propre mécanisme (Raft d'etcd, d'OpenBao et de Qdrant, Keeper de ClickHouse, Gossip d'Alertmanager, Sentinel ou Redis Cluster, Group Replication de MySQL, répartiteur devant des instances sans état, agent par hôte), ses dépendances doivent être elles-mêmes hautement disponibles, et certains outils (garak, promptfoo, Ragas) n'ont aucun cluster natif. Le catalogue décrivait les modes et les cardinalités, sans dire ce que chaque mode garantit ni sous quelles conditions.

Par ailleurs, les fichiers déposés par les utilisateurs et les connecteurs (PDF, Word, Excel, PowerPoint, archives, images, audio) atteignaient Docling, l'OCR, le stockage des médias et la transcription sans analyse antivirus. Une banque isolée d'Internet exige une analyse locale avant toute ingestion, un blocage en cas de doute et une traçabilité complète.

Décision

1. Bloc high_availability obligatoire dans chaque descripteur du catalogue (navin-manager/catalog/schema/service.schema.json) : lien complet de la documentation officielle, nature du cluster, de la haute disponibilité, de la bascule, de la réplication et du quorum, découverte, point d'entrée, sécurité entre nœuds, prérequis (dépendances qui doivent être HA), une topologie par mode (niveau standalone, ha ou cluster, répartition actif-actif, actif-passif, par hôte ou jobs parallèles, composant porteur du quorum, domaines de panne), commande d'état du cluster et réserves écrites. Le chargeur refuse un bloc incohérent avec les modes, composants, liaisons, paramètres et commandes du service ; la vivacité et la disponibilité sont dérivées des contrôles de santé déjà déclarés. GET /api/v1/catalog/high-availability publie la matrice ; la console du Manager montre la capacité et l'état HA de chaque service (page Services, action de ligne « Haute disponibilité (HA) ») ; les pages de services générées et navin-manager/docs/{fr,en}/high-availability.md documentent la matrice et l'architecture cible.
2. Contrôles d'installation HA (navin_manager/services/ha_checks.py) à l'installation et au changement de mode : hôtes distincts, domaines de panne (étiquette zone, sinon rack), quorum impair, prérequis HA, répartiteur HAProxy et Keepalived ou répartiteur de la banque, TLS entre nœuds, contrôles de disponibilité. Un échec refuse l'opération (409 ha_requirements_not_met), un avertissement exige un accusé explicite (ha_acknowledged). Le tableau de bord du service donne l'état HA (sain, dégradé, quorum perdu).
3. Deux services de sécurité dans le catalogue : ClamAV 1.4.6 LTS (GPL-2.0-only) et YARA-X 1.22.1 (BSD-3-Clause), installables en mode autonome ou répliqué. clamd n'écoute jamais sur le réseau : une passerelle HTTPS authentifiée ne transmet que INSTREAM, PING et VERSION. freshclam ne lit que le miroir interne de la banque ; les règles YARA-X viennent du dépôt interne, vérifiées par sha256, compilées en préparation puis basculées atomiquement, l'ancienne version restant active en cas d'échec.
4. Pipeline obligatoire de la plateforme : Upload, Quarantaine, ClamAV + YARA-X, Validation, Docling, RAG / IA. Chaque envoi naît en quarantaine ; seul un verdict propre des deux moteurs produit une autorisation d'analyse liée au sha256 des octets, exigée structurellement par Docling, l'OCR, le stockage des médias et la transcription. Malware, fichier suspect, fichier non inspectable (chiffré, limites dépassées), règle du tenant violée, moteur indisponible ou délai dépassé : blocage. Le mode enforce est imposé en production par la garde de démarrage ; les règles verrouillées (analyse avant ingestion, deux moteurs, échec fermé) ne sont pas modifiables par un tenant.
5. Journalisation et alertes : un enregistrement par analyse, un événement d'audit, un événement de sécurité et une détection SOC par blocage, des métriques eai_file_scan_* et des règles d'alerte Prometheus livrées par le Manager ; écran Sécurité des fichiers du portail ; routes /v1/file-security dans les quatre SDK.

Alternatives écartées

• KicomAV et PRX-SD (MIT, Apache-2.0) : maturité opérationnelle et efficacité de détection non démontrées pour une production bancaire.
• Assemblyline 4 et Strelka : plateformes d'analyse de fichiers, pas des antivirus autonomes ; la pile documentée d'Assemblyline dépend d'Elasticsearch, hors licence Apache. Elles restent possibles en complément.
• Exposer clamd en TCP : son protocole n'a ni TLS ni authentification et accepte SHUTDOWN.
• Lier libclamav au Control Plane : mélange des licences et du domaine de panne ; le dialogue par socket et HTTPS garde ClamAV dans un processus séparé.
• Appeler l'analyse par convention avant Docling : une nouvelle route l'oublierait ; l'autorisation liée au sha256 rend l'oubli impossible.
• Bascule des scanners uniquement par répartiteur : le client de la plateforme bascule seul entre toutes les instances, une adresse de répartiteur reste acceptée.

Conséquences

Une panne simultanée de toutes les instances d'un moteur bloque l'ingestion (503 file_scan_unavailable) : c'est voulu. Chaque hôte ClamAV demande environ 3 Go de mémoire pour la base complète. La fraîcheur des signatures dépend du miroir interne de la banque ; leur âge est surveillé et peut bloquer selon la politique. L'antivirus ne protège pas des injections de prompt : le filtrage existant du texte extrait (marqueurs d'injection, texte caché, quarantaine du RAG) s'applique toujours après Docling.

Preuves

navin-manager/server/tests/test_catalog_high_availability.py, navin-manager/server/tests/test_ha_install_checks.py, navin-manager/server/tests/test_catalog_scanners.py, services/control-plane/tests/test_file_security.py, services/control-plane/tests/test_file_security_api.py, portal/tests/file-security.test.ts, les tests de conformité des quatre SDK.