Pourquoi Nixos

Architecture sécurisée

Les choix techniques qui font de votre serveur NixOS une forteresse, sans Docker, avec isolation par application et audit Lynis.

Architecture sécurisée : pourquoi votre serveur est une forteresse

Un serveur sécurisé ne s'improvise pas. Chaque choix technique, de l'OS au moindre paramètre kernel, est un maillon de la chaîne. Voici les décisions architecturales concrètes qui protègent vos données et vos applications au quotidien.

Pas de Docker : des services natifs, sans couche inutile

La plupart des solutions d'auto-hébergement empilent les couches : Ubuntu + Docker + un orchestrateur + un reverse proxy conteneurisé. Chaque couche ajoute de la complexité, de la surface d'attaque et des points de défaillance.

Avec NixOS, Docker est inutile. Chaque application tourne comme un service natif du système, géré directement par systemd. Pas de daemon Docker tournant en root. Pas de container escapes possibles. Pas d'images opaques à maintenir.

Ce que NixOS remplace nativement :

BesoinAvec DockerAvec NixOS
Isolation des dépendancesImages Docker (couches)Nix store (hash cryptographique)
Isolation des processusNamespaces DockerSandboxing systemd (30+ directives)
ReproductibilitéDockerfile (impératif)Configuration déclarative (pur)
Reverse proxyTraefik conteneuriséCaddy natif, intégré au système
OrchestrationDocker Compose / Swarmsystemd (dépendances, redémarrage)
Mise à jourRebuild d'imagesnixos-rebuild switch atomique
RollbackTag d'image (manuel)Intégré, 1 commande

Le résultat : moins de couches, moins de surface d'attaque, moins de maintenance. Et des performances brutes supérieures, puisque vos applications accèdent directement au système sans passer par une couche de virtualisation.

Chaque application est isolée dans sa bulle

Sur un serveur traditionnel, toutes les applications partagent le même environnement. Si l'une est compromise, l'attaquant a potentiellement accès à tout. Sur votre serveur NixOS, chaque application est enfermée dans un sandbox systemd avec des dizaines de directives de sécurité.
    Un utilisateur dédié par service
    Chaque application tourne sous son propre utilisateur système, avec des droits minimaux. Une application compromise ne peut pas lire les données d'une autre.
    Système de fichiers verrouillé
    ProtectSystem=strict rend /usr, /boot et /etc en lecture seule. Chaque service ne peut écrire que dans son propre répertoire de données, explicitement autorisé.
    Privilèges supprimés
    NoNewPrivileges, CapabilityBoundingSet="", PrivateDevices, les services ne peuvent pas escalader leurs droits, accéder aux périphériques ni charger de modules kernel.
    Appels système filtrés
    SystemCallFilter limite les appels système autorisés au strict nécessaire. MemoryDenyWriteExecute bloque l'injection de code en mémoire. Chaque service n'a accès qu'à ce dont il a besoin.
    Réseau contrôlé par socket
    SocketBindAllow autorise un service à écouter uniquement sur son port attitré. SocketBindDeny=any bloque tout le reste. Impossible d'ouvrir un port non prévu.
    Isolation complète
    PrivateTmp, PrivateUsers, ProtectHome, ProtectProc=invisible, chaque service vit dans un monde restreint où il ne voit ni les autres processus, ni les répertoires utilisateurs, ni les fichiers temporaires des autres.

Audit Lynis : une sécurité vérifiée, pas supposée

Affirmer qu'un serveur est sécurisé ne suffit pas, il faut le prouver. Votre serveur est audité avec Lynis, l'outil de référence pour l'audit de sécurité Linux. Lynis analyse plus de 300 points de contrôle : configuration SSH, permissions des fichiers, paramètres kernel, politique de mots de passe, pare-feu, et bien plus.

Un profil Lynis personnalisé pour NixOS exclut les faux positifs liés aux spécificités de l'OS (store immuable, gestion des paquets par Nix, nftables au lieu d'iptables) pour ne garder que les alertes pertinentes. Le résultat : un score de sécurité élevé et vérifiable, pas une promesse marketing.

Durcissement à chaque couche

    SSH blindé
    Port personnalisé (pas le 22 par défaut), authentification par clés uniquement, root interdit, forwarding désactivé, maximum 3 tentatives. Fail2ban bannit les attaquants avec des durées exponentielles, jusqu'à une semaine.
    Firewall strict
    Seuls 3 ports sont ouverts sur votre serveur : SSH (port personnalisé), HTTP (80) et HTTPS (443). Tous les autres sont fermés par défaut. Chaque application déclare ses besoins réseau, rien de plus.
    Kernel durci
    15 paramètres sysctl de sécurité activés : anti-spoofing, BPF JIT durci, pointeurs kernel masqués, redirections ICMP bloquées, core dumps désactivés. 5 modules réseau inutiles blacklistés (DCCP, SCTP, RDS, TIPC, USB storage).
    Secrets chiffrés en RAM
    Vos mots de passe et clés API sont chiffrés au repos avec age (chiffrement moderne). Au démarrage, ils sont déchiffrés dans un tmpfs en RAM, jamais écrits en clair sur le disque. Permissions 400 : seul le service concerné peut lire son secret.
    Journalisation et audit
    Un daemon d'audit surveille en permanence les modifications sur /etc/passwd, /etc/shadow, /etc/sudoers et la configuration réseau. Chaque changement est tracé. La comptabilité des processus enregistre toute exécution sur le système.
    Sudo granulaire
    Les commandes destructrices (rm, dd, shred, iptables, reboot) exigent un mot de passe même pour les administrateurs. Les services critiques (PostgreSQL, Caddy, Fail2ban) ne peuvent pas être arrêtés sans confirmation explicite.

Comparaison : serveur classique vs. votre serveur NixOS

Mesure de sécuritéServeur Ubuntu + DockerVotre serveur NixOS
Isolation des appsConteneurs Docker (root)Sandbox systemd (30+ directives)
Daemon privilégiéDocker daemon en rootAucun, services natifs
SecretsVariables d'env en clairChiffrés age, déchiffrés en RAM
Audit de sécuritéManuel, ponctuelLynis intégré, profil NixOS
Kernel hardeningÀ configurer manuellement15 sysctl + 5 modules blacklistés
SSHPort 22, souvent mot de passePort custom, clés only, fail2ban
FirewallUFW manuelDéclaratif, 3 ports ouverts
Rollback sécuritéPas de mécanisme natif1 commande, instantané
ReproductibilitéDépend de l'historique bashConfiguration Nix versionnée
Surface d'attaqueOS + Docker + orchestrateurOS seul, services natifs

Un serveur durci par conception, pas par rustine

Réservez un appel pour découvrir comment ces choix architecturaux protègent concrètement vos données et vos applications. Sans engagement.
Copyright © 2026