Sécurité

Dernière mise à jour : 11 novembre 2026

L'agent StatOps s'installe sur des serveurs qui hébergent les sites de vos clients. Cette page décrit précisément ce qu'il fait, pour que vous puissiez décider en connaissance de cause, et le vérifier vous-même.

En une phrase

L'agent lit quelques informations sur le serveur et les envoie à StatOps. Il n'exécute jamais de commande reçue : la réponse de StatOps n'est pas interprétée, et l'agent n'ouvre aucun port en écoute.

Ce que l'agent lit

Information	Comment
Processeur, mémoire, charge, espace disque (hors systèmes de fichiers virtuels)	Lecture des compteurs du système, sans droits particuliers.
Nom de la machine, système, noyau, architecture, durée de fonctionnement	Lecture des compteurs du système.
Sites servis par Nginx	Commande `nginx -T`, qui affiche la configuration complète. L'agent en extrait uniquement les noms de domaine et la présence de HTTPS ; le reste de la sortie est écarté.
Sites servis par Apache	Commande `{{ 'apachectl -S` (ou `apache2ctl -S`, `httpd -S`), qui résume les hôtes virtuels. L'agent en extrait uniquement les noms de domaine (`{{ 'ServerName` et `ServerAlias`) et le port 443 comme indice de HTTPS.
Sites servis par Caddy	Requête `{{ 'GET /config/` sur l'API d'administration de Caddy, qui n'écoute que sur la machine (`localhost:2019`) et ne demande aucun droit particulier. L'agent en extrait uniquement les noms de domaine des routes et la présence de HTTPS. Si Caddy ne répond pas, la source est simplement ignorée.
Conteneurs Docker et sites routés par Traefik	Commandes `{{ 'docker ps` et `docker inspect` avec un format fixe : nom, image, état, date de démarrage, nombre de redémarrages, code de sortie et étiquettes. Les étiquettes servent à lire les règles de routage Traefik ; seuls les noms de domaine en sont retenus.
Sites routés par Traefik, via son API	Requête `GET /api/http/routers` sur l'API de Traefik, uniquement à une adresse de la machine (`localhost:8080` par défaut ; toute autre adresse que localhost, 127.0.0.1 ou [::1] est refusée). L'agent en extrait uniquement les noms de domaine et la présence de HTTPS. Si l'API n'est pas activée, la source est ignorée et les étiquettes Docker prennent le relais.
Sites publiés par un tunnel Cloudflare	Lecture du seul fichier `/etc/cloudflared/config.yml` (ou `config.yaml`), directement ou par `{{ 'cat` via la règle `sudo` ci-dessous. L'agent en extrait uniquement les lignes `hostname` ; les identifiants du tunnel et le reste du fichier sont écartés. Aucun appel à l'API de Cloudflare.
Mises à jour du système en attente (Debian, Ubuntu)	Simulation `apt-get -s dist-upgrade`, sans droits particuliers : rien n'est téléchargé ni installé. L'agent ne garde que le nombre de mises à jour, dont celles de sécurité, et la présence du fichier `/run/reboot-required`. Les noms de paquets ne sont pas envoyés.

Le format fixe de {{ 'docker inspect ne demande ni les variables d'environnement, ni les secrets, ni les journaux des conteneurs.

Ce que l'agent envoie

Un rapport par minute. Les sites et les conteneurs sont relevés au démarrage, puis toutes les cinq minutes. Le rapport contient, et rien d'autre :

la version de l'agent et l'heure d'envoi ;
la machine : nom, système, noyau, architecture, durée de fonctionnement ;
les mesures : utilisation du processeur, mémoire utilisée et totale, charge moyenne, et pour chaque disque son point de montage, l'espace utilisé et l'espace total ;
les sites découverts : nom de domaine, source (Nginx, Apache, Caddy, Traefik ou Cloudflare Tunnel) et présence de HTTPS ;
les conteneurs : nom, image (par exemple registre/projet:version), état et statut ;
les mises à jour en attente : leur nombre, celui des mises à jour de sécurité, et si un redémarrage est nécessaire ;
les erreurs de découverte éventuelles, sous forme de texte court.

L'agent ne lit pas et n'envoie pas : le contenu des sites, les fichiers, les bases de données, les journaux, les variables d'environnement, les mots de passe, les clés et les certificats.

Vous pouvez voir le rapport exact avant qu'il parte : la commande statops-agent --dry-run l'affiche sans rien envoyer.

Ces mêmes relevés servent au journal de maintenance : quand des mises à jour en attente ne le sont plus, qu'un serveur redémarre ou qu'une image de conteneur change, StatOps le note dans le journal du client concerné, que l'agence relit avant l'envoi du rapport. Aucune lecture supplémentaire n'est faite sur le serveur.

Sens unique

L'agent contacte StatOps ; StatOps ne contacte jamais l'agent.
La réponse de StatOps est ignorée en cas de succès : elle ne peut pas contenir de commande à exécuter. Aucun canal de contrôle à distance n'existe, et ce n'est pas prévu.
Les envois passent en HTTPS. HTTP n'est accepté que vers la machine locale.
Chaque serveur a son propre jeton, affiché une seule fois à la création et conservé haché côté StatOps. Supprimer le serveur dans le tableau de bord rend son jeton inutilisable, sans toucher aux autres serveurs.
Si StatOps est injoignable, l'agent garde les derniers rapports en mémoire (60 au plus) et les renvoie à la reconnexion.

Droits demandés sur le serveur

Un utilisateur système dédié, statops-agent, sans interpréteur de commandes ni dossier personnel. L'agent ne tourne pas en tant que root.
Aucun accès à la socket Docker et aucun groupe {{ 'docker (ce groupe équivaut à root). La découverte passe par une règle sudo limitée à des commandes de lecture : nginx -T, apachectl -S, docker ps -aq --no-trunc, {{ 'docker inspect avec son format fixe et cat du seul fichier de configuration de Cloudflare Tunnel. Tout autre appel est refusé.
Cette règle est affichée pendant l'installation, vérifiée par visudo, et reste consultable avec statops-agent sudoers.
Le service systemd isole le dossier {{ '/home et utilise un /tmp privé.

Installer, vérifier, désinstaller

Lisez le script avant de l'exécuter : curl -fsSL https://get.statops.fr l'affiche. Il fait uniquement ce qui est décrit en tête du fichier.
Le script vérifie la somme de contrôle SHA-256 du binaire avant de l'installer. Si minisign est installé sur le serveur, il vérifie aussi la signature avec la clé publique ci-dessous et s'arrête si elle est invalide.
Les binaires sont signés avec minisign et vous pouvez vérifier la signature vous-même, avant d'installer. Clé publique (identifiant 13188DBC96E98996) : RWSWiemWvI0YE1iIC0ZTI8oxB3RsOVNVpjIgtHL8rnys8CB8H+b1pn9J. Pour un serveur x86_64 (remplacez par {{ 'aarch64 sinon) : curl -fsSLO https://get.statops.fr/download/x86_64, puis curl -fsSL https://get.statops.fr/download/x86_64.minisig -o x86_64.minisig, puis minisign -V -m x86_64 -x x86_64.minisig -P RWSWiemWvI0YE1iIC0ZTI8oxB3RsOVNVpjIgtHL8rnys8CB8H+b1pn9J. Le commentaire signé indique la version et l'architecture.
La désinstallation est une commande : {{ 'sudo sh -s -- --uninstall supprime le service, le binaire, la règle sudoers, la configuration et l'utilisateur.
La mise à jour consiste à relancer la commande d'installation sans jeton : le script reprend celui du serveur, remplace le binaire, régénère la règle sudoers et redémarre le service.

Tests de l'agent

Les tests automatiques de l'agent exécutent 87,7 % de son code (676 lignes sur 771, sans compter le code des tests eux-mêmes). Mesure du 7 novembre 2026 sur la version 0.1.1, avec cargo-llvm-cov.

Partie de l'agent	Code exécuté par les tests
Lecture des configurations (Nginx, Apache, Caddy, Traefik, Docker, Cloudflare Tunnel)	95 à 100 %
Envoi à StatOps (HTTPS, file d'attente pendant une panne)	100 %
Mesures système (processeur, mémoire, disques)	98 %
Lancement des commandes et enchaînement de la découverte	82 %
Démarrage du service	47 %

Le reste est surtout la vie du service (envoi toutes les minutes, arrêt propre) et les cas qui demandent un vrai serveur web installé. Ces cas ont été vérifiés avec de vrais Nginx, Apache, Caddy et Traefik dans des conteneurs Debian.

Côté StatOps

Authentification à deux facteurs sur le tableau de bord.
Mots de passe stockés hachés ; secrets de double authentification et mots de passe SMTP stockés chiffrés.
Limitation des tentatives de connexion et d'inscription.
Rôles par organisation : propriétaire, membre, lecteur.
Sauvegardes de la base chiffrées, et restauration testée.
Lieu de stockage, durées de conservation et sous-traitance : voir la politique de confidentialité.

Ce qui n'est pas encore en place

Par souci de transparence, voici les limites actuelles :

Sans minisign sur le serveur, le script d'installation ne contrôle que la somme SHA-256, servie par le même serveur que le binaire. Elle détecte une corruption, mais ne protège pas contre un serveur de distribution compromis : installez minisign ou vérifiez la signature à la main, comme décrit plus haut. La clé privée est conservée hors du serveur.
Il n'existe pas encore de dépôt de paquets (APT, RPM).
Le code de l'agent n'est pas publié.

Signaler un problème de sécurité

Si vous pensez avoir trouvé une faille, écrivez à contact@statops.fr en décrivant ce que vous avez observé. Merci de ne pas la rendre publique avant que nous ayons pu la corriger.