149 lines
9.4 KiB
Markdown
149 lines
9.4 KiB
Markdown
# 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 :
|
|
|
|
1. l'inventaire des machines est **généré** automatiquement ;
|
|
2. chaque VM est **clonée** depuis un modèle Debian de référence (« golden template ») durci une fois pour toutes ;
|
|
3. 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 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.
|
|
|
|
### 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 :
|
|
|
|
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),
|
|
`docs/catalogue-services.md`, `docs/plan-et-generation.md`, `docs/positionnement.md`.*
|