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** | Service de courriel souverain : boîtes adossées à l'annuaire, réception SMTP, lecture IMAP, antispam et signature DKIM. Le relais des alertes système en est distinct. |
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 de `dmesg` et des pointeurs noyau, blocage de Ctrl-Alt-Suppr, restriction de `perf_event`.
- **Système de fichiers** : protection des liens durs/symboliques, des FIFO et fichiers réguliers, interdiction des core dumps SUID.
- **nftables** est **volontairement désactivé dans le modèle** — on n'active jamais un pare-feu générique sans connaître la fonction réelle de la machine — et **armé sur chaque serveur de la flotte**, en politique « tout refuser » par défaut.
- **Ses règles ne sont pas écrites à la main.** Chaque rôle déclare ce qu'il écoute et ce à quoi il se connecte ; le jeu de règles en est **dérivé**. Le même registre alimente le pare-feu de l'hyperviseur et la frontière du site : trois couches de filtrage qui ne *peuvent pas* se contredire, parce qu'elles descendent d'une seule décision. C'est aussi ce qui produit la **matrice d'accès réseau** exigée par un audit de sécurité — source, destination, port, chiffrement et *raison*, pour chaque flux autorisé.
- **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.
- **Les sauvegardes sortent du site.** L'état non régénérable (clés de l'autorité, annuaire, bases, boîtes, forge) est sauvegardé **chiffré côté client** vers un dépôt hors-machine, puis emporté **hors du bâtiment**. Chaque nœud vérifie lui-même son propre dépôt distant : celui qui héberge les octets ne peut pas les lire, donc ne peut pas les juger.
- **Ce qu'on affirme, on le prouve.** Un harnais de **57 vérifications** rejoue à la demande ce que le dépôt promet et produit une pièce justificative datée ; dix « devis » interrogent en plus le système *déployé* pour confirmer qu'il ressemble à ce qui est déclaré.
Trois principes résument la posture de Chezlepro :
1.**Tout est libre.** Aucune brique propriétaire, aucune licence captive.
2.**Aucune dépendance externe pour les fonctions vitales** — confiance, identité, nom, communication sont hébergées et maîtrisées en interne.
3.**Exploitable sans IA, par un humain.** La documentation, `make` et 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),
