Architecture
Une isolation honnête : forte, mais pas absolue.
Nos services tournent dans des conteneurs dédiés, sans accès à l’hôte ni aux autres projets. Ils partagent toutefois le noyau du serveur : c’est une limite connue, documentée, et la raison pour laquelle une machine séparée reste la frontière la plus sûre.
Le schéma
Quatre couches, une seule porte d’entrée.
Chaque couche a une raison d’être et une limite. Le schéma ci-dessous est accompagné de sa description textuelle complète : rien n’est réservé à celles et ceux qui voient l’image.
Le même schéma, en texte
- Serveur unique. Un seul serveur, exploité par Wiinup, héberge le socle.
- Daemon Docker rootless dédié. Il tourne sous un utilisateur Unix distinct, avec ses propres chemins, ses propres réseaux et des quotas de ressources. Aucun socket de l’hôte n’est monté dans un conteneur.
- Réseau interne privé. Les conteneurs se parlent entre eux sans être joignables depuis l’extérieur.
- Passerelle. Seul point d’entrée, sur le port 443 : chiffrement du transport, en-têtes de sécurité, limitation de débit.
- Site public et Command Center. Rendu côté serveur ; aucune clé ni aucun jeton n’est manipulé par le navigateur.
- Interface de programmation. Mandats, incidents, politique d’action, journal d’audit. Chaque écriture laisse une trace chaînée.
- Base de données. Les données sont cloisonnées par espace client, contrôlées côté serveur et jamais seulement dans l’interface.
- Stockage des preuves. Les preuves vivent hors de la base, adressées par leur empreinte SHA-256, avec leur chaîne de conservation.
- Sortie refusée par défaut. Aucun conteneur ne peut appeler l’extérieur sans une autorisation explicite.
- Limite assumée. Tous ces conteneurs partagent le noyau Linux de l’hôte (
SHARED_KERNEL_ISOLATION). Ce n’est pas une machine virtuelle.
La limite
SHARED_KERNEL_ISOLATION : ce que cela veut dire.
Nous employons ce terme dans notre documentation interne et nous l’affichons ici plutôt que de le garder pour nous.
Pourquoi ce n’est pas une machine virtuelle
Un conteneur n’embarque pas son propre noyau : il utilise celui du serveur, avec des cloisonnements (espaces de noms, groupes de contrôle, capacités) qui limitent ce qu’il peut voir et faire. Ces cloisonnements sont efficaces contre une application compromise. Ils ne protègent pas contre une faille du noyau lui-même.
Une machine virtuelle, elle, embarque son propre noyau et s’appuie sur une frontière matérielle. C’est une isolation d’un autre ordre — et un coût d’un autre ordre.
Ce que nous faisons malgré tout
- Un daemon de conteneurs sans privilèges, réservé à Wiinup, exécuté par un utilisateur système distinct.
- Des chemins de données et des réseaux séparés des autres projets hébergés sur la même machine.
- Des quotas de mémoire et de processeur, pour qu’un incident sur Wiinup ne prive pas les autres services.
- Aucun socket de l’hôte monté dans un conteneur : un conteneur ne peut pas piloter le daemon.
- Une sortie réseau refusée par défaut : un conteneur ne peut pas appeler l’extérieur sans autorisation explicite.
Ce que nous recommandons
Si votre analyse de risque exige une frontière plus forte — par exemple parce que vous traitez des données de santé, des données judiciaires ou des secrets industriels — la réponse n’est pas une option de configuration : c’est une machine dédiée. Nous le dirons plutôt que de vous vendre une isolation que le modèle technique ne permet pas.
Conséquences
Pourquoi certains modules ne tournent pas ici.
La mémoire d’un serveur n’est pas extensible : les moteurs d’observation les plus gourmands sont définis, mais non démarrés sur cette instance.
Le socle — mandats, incidents, preuves, politique d’action, audit — tient dans une empreinte modeste et fonctionne en permanence. Les moteurs de collecte et de recherche à grande échelle, eux, réclament plusieurs gigaoctets de mémoire à eux seuls. Les démarrer ici dégraderait le socle et les autres projets hébergés sur la même machine.
Nous préférons donc une instance de démonstration honnête : ce que vous voyez tourne réellement, et ce qui ne tourne pas est annoncé comme tel, module par module.
Les capteurs réseau relèvent d’une autre contrainte, indépendante de la mémoire : un capteur ne peut observer que le trafic qui passe devant lui. Ils se déploient donc sur vos hôtes, sous mandat, jamais sur notre serveur central.
Une question sur un point précis de cette page ? Écrivez-nous, nous répondons avec le même niveau de détail.