9.4 KiB
L'écosystème numérique Chezlepro
Document de présentation — souveraineté et sécurité
En une phrase
Chezlepro est un écosystème numérique souverain : une infrastructure interne complète — identité, confiance, nommage, données, communication, observabilité, applications — hébergée sur sa propre grappe Proxmox, sans dépendance à un service en nuage tiers, entièrement décrite en code et reconstructible à volonté.
Le moteur qui la construit et l'entretient s'appelle Set-OPS. Il est libre,
réutilisable par n'importe quel hébergeur, et s'exploite entièrement à la main :
la documentation, les commandes make et l'interface locale suffisent. L'outil
libère de la dépendance aux géants du numérique ; il ne la remplace pas par une
dépendance à une intelligence artificielle.
Pourquoi un écosystème, et pas seulement des serveurs
La plupart des organisations louent leur identité, leurs courriels, leurs noms de domaine et leur confiance numérique à quelques fournisseurs étrangers. Chaque brique louée est une dépendance, un coût récurrent et une perte de contrôle.
Chezlepro renverse cette logique : chaque pilier de l'infrastructure est hébergé et maîtrisé en interne, et les piliers sont reliés entre eux comme un tout cohérent.
| Pilier | Ce qu'il apporte |
|---|---|
| Identité | Annuaire interne (LDAP) et authentification unique (SSO) : un seul compte, partout. |
| Confiance | Autorité de certification interne (PKI/ACME) : les serveurs se reconnaissent par certificats émis localement, sans acheter de confiance à l'extérieur. |
| Nommage | DNS interne : des noms de machines stables et dérivables, plutôt que des adresses IP fragiles. |
| Données | Bases relationnelles et cache, avec un registre des connexions applicatives. |
| Communication | Relais courriel interne pour les alertes, notifications et réinitialisations. |
| Observabilité | Métriques, journaux centralisés, tableaux de bord et supervision active. |
| Applicatif | Services internes (forge logicielle, collaboration documentaire) derrière une couche web sécurisée. |
Tous ces services sont libres (OpenLDAP, Keycloak, step-ca, PowerDNS, PostgreSQL, Redis, NGINX, Prometheus, Loki, Grafana, Icinga, Forgejo, Sendmail…). Aucun verrou propriétaire, aucune licence captive.
Comment c'est construit : reproductible par conception
Rien n'est configuré « à la main » sur un serveur. Tout part d'un plan déclaratif — quelques fichiers lisibles qui décrivent l'état voulu de l'infrastructure (les serveurs, les applications, les bases de données, les domaines). À partir de ce plan :
- l'inventaire des machines est généré automatiquement ;
- chaque VM est clonée depuis un modèle Debian de référence (« golden template ») durci une fois pour toutes ;
- sa configuration réelle est appliquée par Ansible, de façon idempotente (on peut la relancer sans effet de bord).
Conséquence concrète pour la résilience : si une machine est perdue, elle se reconstruit à l'identique depuis le plan et le code. L'infrastructure n'est pas un objet fragile patiemment bricolé — c'est un artefact reproductible.
Honnêteté sur le statut. Une grande partie de l'écosystème est aujourd'hui définie, codée et validée (vérification de syntaxe, analyse statique) mais n'a pas encore été éprouvée sur des machines de production réelles. Le socle Debian durci et son modèle sont la fondation établie ; les services applicatifs sont prêts en tant que code et se déploient progressivement. Nous ne présentons jamais un service non déployé comme « en production ».
Mesures de renforcement (durcissement)
La sécurité n'est pas une couche ajoutée après coup : elle est intégrée dès le socle commun de chaque machine, puis renforcée par un groupe de durcissement appliqué aux serveurs. Voici les mesures réellement en place dans le moteur.
1. Accès SSH verrouillé
L'accès distant est la porte d'entrée la plus exposée ; elle est fermée par défaut à tout ce qui n'est pas strictement nécessaire.
- Authentification par clé uniquement — le mot de passe est désactivé (
PasswordAuthentication no,AuthenticationMethods publickey). - Connexion root interdite (
PermitRootLogin no), pas de mots de passe vides, pas d'authentification par hôte. - Aucune redirection : X11, agent, ports TCP, tunnels, sockets — tout est désactivé.
- Sessions limitées : déconnexion automatique des sessions inactives, nombre de tentatives plafonné (
MaxAuthTries 3), délai de grâce court (LoginGraceTime 20s), sessions simultanées limitées. - Garde-fou opérationnel : toute modification SSH est validée (
sshd -t) avant d'être rechargée, et l'authentification par mot de passe n'est jamais coupée avant d'avoir confirmé que l'accès par clé fonctionne — pour ne jamais se verrouiller dehors.
2. Protection contre le brute-force
- fail2ban surveille les tentatives de connexion SSH et bannit automatiquement les adresses fautives (5 échecs en 10 min → bannissement d'1 h).
3. Durcissement du noyau (sysctl)
Une trentaine de paramètres noyau resserrent le comportement du système et du réseau, notamment :
- Réseau : rejet des redirections et du routage par la source ICMP/IP, protection anti-spoofing (
rp_filter), cookies SYN contre les inondations, journalisation des paquets « martiens », rejet des broadcasts ICMP. - Noyau : ASLR activé (
randomize_va_space), restriction dedmesget des pointeurs noyau, blocage de Ctrl-Alt-Suppr, restriction deperf_event. - Système de fichiers : protection des liens durs/symboliques, des FIFO et fichiers réguliers, interdiction des core dumps SUID.
4. Pare-feu prêt, activé au bon moment
- nftables est installé et préparé sur le socle, mais volontairement désactivé dans le modèle. Il est activé sur les serveurs finaux avec des règles adaptées à leur rôle (politique par défaut « tout refuser » en entrée et en transit). Principe : on n'active jamais un pare-feu générique sans connaître la fonction réelle de la machine, pour ne pas couper l'accès par accident.
5. Confinement et intégrité
- AppArmor : confinement des applications par profils.
- auditd : journalisation d'audit du système avec un jeu de règles Set-OPS.
- debsums / needrestart / apt-listchanges : vérification de l'intégrité des paquets et détection des services à redémarrer après mise à jour.
6. Mises à jour de sécurité automatiques
- unattended-upgrades applique automatiquement les correctifs de sécurité Debian. Le redémarrage automatique reste désactivé par défaut (décision laissée à l'opérateur), et les dépendances inutilisées sont nettoyées.
7. Journalisation maîtrisée
- journald est borné (rétention et taille plafonnées) pour garder des traces utiles sans saturer le disque. Les journaux peuvent ensuite être centralisés vers Loki.
8. Politique de mots de passe et gestion des secrets
- libpam-pwquality impose une qualité minimale des mots de passe locaux.
- Aucun secret n'est stocké en clair dans le code. Mots de passe, clés privées, jetons et certificats sont gérés hors dépôt (Ansible Vault, fichiers locaux non versionnés, gestionnaire de secrets). Le modèle de VM ne contient ni données de clone, ni secret, ni clé privée.
9. Garde-fous sur les actions destructives
- Toute opération risquée (modification bloquante de SSH, activation d'un pare-feu, suppression d'utilisateurs ou de paquets critiques, formatage, purge de données, redémarrage massif, opérations de stockage…) exige une confirmation explicite. Sans elle, l'exécution est refusée.
10. Sécurité par l'architecture
Au-delà des réglages machine, l'architecture elle-même est une mesure de sécurité :
- Tout service exposé en HTTP(S) passe par un point d'entrée unique (NGINX en mandataire inverse, terminaison TLS, WAF) plutôt que d'être exposé directement.
- Authentification centralisée : les services à accès humain se branchent au SSO, ce qui évite la multiplication des comptes et des mots de passe dispersés.
- Certificats internes : les services se font confiance via la PKI interne, sans exposer de secrets à des autorités externes.
- Dépendances déclarées : un service ne se déploie pas si ses prérequis (DNS, PKI…) ne sont pas réellement actifs — ce qui évite les états incohérents.
- Source unique de vérité : l'état voulu vit dans des registres lisibles, versionnés par Git, qui sert de filet en cas d'erreur.
Souveraineté jusqu'au bout
Trois principes résument la posture de Chezlepro :
- Tout est libre. Aucune brique propriétaire, aucune licence captive.
- Aucune dépendance externe pour les fonctions vitales — confiance, identité, nom, communication sont hébergées et maîtrisées en interne.
- Exploitable sans IA, par un humain. La documentation,
makeet l'interface locale forment l'interface complète. L'intelligence artificielle n'assiste éventuellement que le mainteneur de l'outil — jamais l'utilisateur final, qui reste pleinement autonome.
Détails techniques et runbooks : voir AGENTS.md (autorité du dépôt),
docs/catalogue-services.md, docs/plan-et-generation.md, docs/positionnement.md.