Vue d'ensemble

Ce qu'InfraRiver fait

InfraRiver centralise plusieurs sources d'information sur un parc de serveurs et les fusionne en un inventaire unique et cohérent :

Source	Exemples
CMDB	GLPI, ServiceNow
Supervision	Centreon, Zabbix
Scanners de vulnérabilités	Rapid7
Annuaire	Active Directory
Virtualisation	vCenter
Orchestration	Kubernetes

Sur cette base commune, plusieurs modules d'analyse travaillent :

• cartographie applicative ;
• calcul de chemins d'attaque ;
• scoring de risque unifié ;
• suivi de fin de vie logicielle ;
• détection de dérive de durcissement ;
• un assistant IA 100 % local pour la narration et la classification.

Le produit est pensé pour un fonctionnement on-premise et air-gap-compatible : aucun composant n'a besoin d'un accès Internet pour fonctionner.

• Les connecteurs qui ont besoin d'Internet — threat intelligence CveRiver, fin de vie EOLRIVER — sont chacun opt-in et peuvent passer par un proxy sortant contrôlé.
• L'assistant IA tourne sur un modèle local (Ollama + Ministral), jamais un appel à une API externe.

Concepts clés

Connecteur — un module qui va chercher des données dans un système tiers (GLPI, Active Directory, vCenter…) et les réconcilie dans l'inventaire InfraRiver. Chaque connecteur a sa propre page de configuration, son propre intervalle de synchronisation, et peut être activé ou désactivé indépendamment sans perdre les données déjà collectées.

River — un flux de données typé que peut produire un ou plusieurs connecteurs, et que peuvent consommer d'autres modules. Deux exemples :

River	Produit par	Consommé par
inventory (liste de serveurs)	GLPI, ServiceNow, vCenter, Active Directory, Kubernetes…	Tous les autres modules
accounts (comptes observés)	Active Directory, Zabbix, ELK…	Le module Comptes et PathFinder

Cette architecture permet d'ajouter un nouveau connecteur sans modifier les modules qui consomment déjà ce type de donnée. Le glossaire des rivers liste tous les rivers et qui les produit/consomme.

Module — une fonctionnalité d'analyse qui consomme un ou plusieurs rivers pour produire une vue ou une décision (TopoMap, PathFinder, Risk Intel, CrossRiver…). Un module n'accède jamais directement à un système tiers — uniquement aux rivers déjà réconciliés.

Composants du système

flowchart LR
    A[Sources externes] --> B[Connecteurs]
    B --> C[(Rivers)]
    C --> D[Modules InfraRiver]
    D --> E[Portail InfraRiver]
    F[InfraRiver Collector] --> G[Passerelle d'ingestion mTLS]
    G --> C
    H[Ollama + Ministral] --> D

Lecture du schéma

Les connecteurs réconcilient les données provenant des systèmes tiers dans les rivers. Les modules consomment ensuite ces données réconciliées. InfraRiver Collector alimente les données de posture via la passerelle d'ingestion, tandis que l'assistant IA local fournit les fonctions de narration et de classification.

Composant	Rôle
Portail InfraRiver (paquet infrariver)	Application web (FastAPI), tous les connecteurs, tous les modules d'analyse, la base MariaDB. C'est le seul composant obligatoire.
InfraRiver Collector (paquets infrariver-collector + infrariver-agent)	Poller universel Windows/Linux qui remonte la posture système détaillée (comptes locaux, ports en écoute, logiciels installés, certificats) — voir InfraRiver Collector — principe. Optionnel : le portail fonctionne sans, avec une couverture de données plus large avec.
Assistant IA local (Ollama + Ministral)	Service tiers, installé séparément sur la même machine ou une machine dédiée, jamais un appel réseau externe. Optionnel : les fonctionnalités de narration/classification se dégradent proprement en son absence.