Architecture
Un serveur, neuf services, et aucune envie d’être réveillé la nuit
J’administre une machine modeste — moins de deux gigaoctets de mémoire vive — sur laquelle tournent neuf services. Ce n’est pas une prouesse d’échelle : c’est un terrain où chaque décision se paie comptant, ce qui est exactement ce qui rend l’exercice formateur.
La question que je me pose à chaque installation n’est pas « est-ce que ça marche », mais « qu’est-ce qui casse si ça tombe, et comment je reviens en arrière ». Voici les règles qui en découlent.
Une application, un compte
Chaque service tourne sous son propre compte système, sans droits d’administration.
Aucun service ne peut lire les secrets d’un autre, ni écrire ailleurs que dans le seul répertoire qui lui est ouvert. Quand une application a besoin d’une commande privilégiée, elle obtient cette commande précise et rien d’autre. La question n’est pas de savoir si une application sera compromise, mais ce qu’un attaquant peut atteindre depuis celle-ci.
Confinement au niveau du système
Les unités de service interdisent l’élévation de privilèges, montent le système en lecture seule, masquent les répertoires personnels et filtrent les appels système.
Un plafond mémoire est fixé par service. Sur une machine modeste, ce n’est pas une précaution théorique : sans lui, une seule application qui dérive emporte toutes les autres. Les services qui ne peuvent pas être confinés — parce qu’ils administrent la machine — sont identifiés comme tels, et leur exception est documentée.
Cloisonnement des données
Un rôle de base de données par application, jamais de superutilisateur.
Chaque application possède sa base et le rôle qui va avec. Aucun accès croisé, y compris entre une application et sa propre instance de démonstration : code identique, base, compte et secrets distincts.
Rien d’irremplaçable sur le disque
L’état vit en base ou dans un emplacement explicitement sauvegardé, jamais dans le répertoire déployé.
Cette contrainte rend le déploiement ennuyeux, ce qui est exactement le but : un déploiement qui remplace entièrement le répertoire de l’application ne peut structurellement rien détruire. La sauvegarde tient alors en une commande.
Chiffrement et exposition minimale
Le proxy inverse est la seule porte ouverte ; les applications n’écoutent que localement.
Certificats renouvelés automatiquement, en-têtes de sécurité posés au niveau du proxy, limitation de débit sur les pages d’authentification, et taille des requêtes plafonnée pour les applications qui n’acceptent aucun fichier. Le pare-feu est la seconde barrière, jamais la seule.
Savoir ce qui tourne
Une console de supervision maison donne l’état réel des services, des ressources et des certificats.
Elle lit ce que le système déclare, pas ce que la documentation prétend — c’est ainsi que j’ai découvert que plusieurs applications écoutaient plus largement qu’annoncé. Chaque installation s’accompagne d’une procédure de retour arrière écrite avant l’installation elle-même.