Concevoir une défense en profondeur par couches

La défense en profondeur impose une règle brutale : aucune barrière ne mérite le statut de frontière de confiance unique. Réseau, système, application et données doivent chacun limiter une compromission déjà supposée possible dans la couche précédente.

→ Lire l’explication complète de la marmotte

Défense en profondeur : une hypothèse de compromission par couche

Une architecture en couches ne consiste pas à accumuler des produits de sécurité jusqu’à ce que le diagramme ressemble à un catalogue de salon professionnel. Elle consiste à identifier les chemins d’attaque, puis à placer des contrôles indépendants sur chaque chemin. L’indépendance est le mot qui coûte cher et sauve des incidents.

Le compromis central est net : on gagne en résistance aux défaillances, en confinement et en capacité de réponse ; on paie en complexité d’exploitation, en latence, en règles à maintenir et en risques de panne par mauvaise coordination. Ce coût est justifié dès qu’une compromission d’un composant exposé permettrait d’atteindre des données sensibles, une identité privilégiée ou un plan de contrôle.

Chaque couche doit répondre à une question distincte :

le réseau limite qui peut atteindre un service ;
le système d’exploitation limite ce qu’un processus compromis peut faire ;
l’application limite ce qu’une requête recevable peut déclencher ;
les données restent protégées si l’accès au stockage est obtenu ;
l’identité limite l’usurpation et l’élévation de privilèges ;
la journalisation rend l’échec observable avant qu’il ne devienne irréversible.

Un pare-feu ne valide pas une autorisation métier. Une validation de formulaire ne rend pas un serveur invulnérable à une exécution de code. Le chiffrement d’un disque ne protège pas les données lues par un processus déjà compromis. Chaque promesse a une frontière. Prétendre le contraire, c’est faire de la sécurité à la peinture acrylique.

La segmentation n’est donc pas une propriété d’un équipement mais une propriété de l’architecture. Elle doit survivre à la perte d’un élément : perte d’un poste d’administration, d’un serveur web, d’un compte de déploiement ou d’un jeton d’accès. Les fondations Linux restent déterminantes ici : une frontière réseau ne remplace jamais les permissions locales, les capacités de processus et l’isolation des services.

Couches réseau, système, application et données d’une architecture web

Prenons une application web exposée sur Internet, avec un frontal public, un service applicatif et une base de données. Le scénario utile n’est pas celui où tout fonctionne. C’est celui où le frontal reçoit une requête hostile, puis échoue partiellement.

La première couche est le pare-feu périmétrique. Il n’expose que le port nécessaire au protocole web chiffré et interdit les accès directs aux réseaux d’administration, aux bases de données et aux services internes. Cette couche réduit l’exploration opportuniste et bloque les connexions qui ne devraient jamais exister. Elle ne protège pas contre une requête malveillante envoyée sur un port autorisé. Le port 443 ouvert à Internet reste Internet, même avec un chiffrement impeccable.

La deuxième couche est la segmentation interne. Le frontal peut joindre l’application sur un port précis ; l’application peut joindre la base de données sur un port précis ; aucun autre flux n’est implicite. Les règles doivent être orientées par identité de service ou par adresse stable gérée, pas par une plage réseau large du genre « tout le sous-réseau applicatif ». Une plage large finit toujours par accueillir un composant imprévu. C’est une loi physique de l’infrastructure, voisine de la poussière dans les baies.

La troisième couche est le durcissement du système d’exploitation. Le processus applicatif s’exécute sous un compte dédié, sans shell interactif, sans privilège d’administration et avec un système de fichiers majoritairement en lecture seule. Les répertoires d’écriture sont limités aux journaux, caches et fichiers temporaires nécessaires. Les services doivent être isolés par un gestionnaire de services, avec restrictions d’accès aux périphériques, au réseau et au système de fichiers. La page sur systemd complète cette approche pour les hôtes Linux.

La quatrième couche est applicative. Toute entrée externe est considérée hostile : paramètres, en-têtes, fichiers, identifiants de session, contenu de message et données reçues d’une Application Programming Interface (API) partenaire. Une requête de base de données utilise des paramètres liés, jamais une concaténation de chaînes. Une décision d’autorisation est prise côté serveur sur l’identité authentifiée et l’objet demandé, jamais sur un champ fourni par le navigateur.

La cinquième couche protège les données au repos. Le chiffrement du stockage évite qu’un volume copié ou un disque perdu livre son contenu brut. Pour les données à haute sensibilité, chiffrer les champs ou colonnes avant persistance réduit aussi l’impact d’un export de base de données. Les clés ne résident pas dans le même emplacement que les données chiffrées : une clé de chiffrement doit provenir d’un service de gestion de clés ou d’un HSM (Hardware Security Module) quand la criticité l’impose.

Couverture des vecteurs d’attaque plutôt que redondance décorative

La défense en profondeur échoue quand plusieurs couches protègent le même vecteur alors qu’un autre reste nu. Trois pare-feu successifs filtrant le même flux entrant ne compensent pas une application qui construit des requêtes Structured Query Language (SQL) par concaténation. Ils produisent surtout trois jeux de règles à auditer pendant l’incident.

Une matrice de couverture doit associer chaque menace à une barrière principale, une barrière de secours et un signal de détection. Par exemple :

Vecteur	Barrière principale	Barrière de secours	Signal attendu
Exploration externe	Pare-feu périmétrique	Limitation de débit applicative	Refus réseau et erreurs HTTP
Mouvement latéral	Segmentation interne	Comptes de service distincts	Tentatives de flux interdits
Exécution de code	Correctifs et isolation système	Processus sans privilège	Création de processus anormale
Injection SQL	Requêtes paramétrées	Droits minimaux en base	Erreurs de syntaxe et requêtes atypiques
Vol de volume	Chiffrement au repos	Clés séparées des données	Accès anormal au service de clés
Vol de session	Cookies protégés et expiration	Réauthentification pour action sensible	Connexions concurrentes ou changements d’appareil

Une même menace peut traverser plusieurs couches, mais les contrôles ne doivent pas partager le même défaut. Une liste d’adresses autorisées sur le pare-feu et dans le code applicatif reste corrélée si elle provient de la même source erronée. À l’inverse, un contrôle réseau, une autorisation métier et une clé séparée échouent pour des raisons différentes. C’est exactement ce qui leur donne de la valeur.

Le choix entre duplication et diversité dépend de la conséquence d’échec. Pour une exposition publique à faible enjeu, deux contrôles homogènes peuvent être acceptables. Pour l’accès à des secrets ou à des données réglementées, il faut diversifier : identité distincte, frontière réseau distincte, contrôle cryptographique distinct. Les slides promettent le « zero trust » en trois clics ; la version exploitable commence par décider qui a le droit de parler à quoi, et pourquoi.

Exemple de segmentation reproductible avec nftables

L’exemple suivant filtre un hôte applicatif Linux. Seul le frontal 192.0.2.10 peut joindre le service web sur le port 8443, et seul le réseau d’administration peut ouvrir une session Secure Shell (SSH). Les connexions sortantes ne sont pas traitées ici : elles doivent être réduites séparément selon les dépendances réelles de l’application.

#!/usr/sbin/nft -f

# Politique par défaut : tout flux entrant non prévu est refusé.
flush ruleset

table inet filter {
  chain input {
    type filter hook input priority 0;
    policy drop;

    # Le trafic local reste nécessaire au fonctionnement du système.
    iifname "lo" accept

    # Autoriser les réponses aux connexions déjà établies.
    ct state established,related accept

    # Le frontal web est le seul émetteur autorisé vers l'application.
    ip saddr 192.0.2.10 tcp dport 8443 accept

    # Administration limitée au réseau dédié, pas au réseau utilisateur.
    ip saddr 198.51.100.0/24 tcp dport 22 accept

    # Refuser explicitement le reste pour obtenir un compteur exploitable.
    counter drop
  }
}

Appliquer cette règle sans accès console hors bande est une mauvaise idée. Une erreur d’adresse coupe l’administration aussi efficacement qu’une attaque, avec la courtoisie supplémentaire de laisser un ticket d’incident. Tester d’abord dans une machine de laboratoire, valider la persistance au redémarrage, puis vérifier les compteurs de refus.

Cette configuration ne garantit ni l’authentification du frontal, ni l’intégrité de son contenu, ni la sécurité du code applicatif. Une adresse source peut être usurpée sur un réseau mal contrôlé ; il faut donc compléter par un chiffrement Transport Layer Security (TLS) mutuel lorsque la topologie le permet, et par une autorisation applicative indépendante.

Exploitation : secrets, rotation, supervision et reprise

Les contrôles de sécurité deviennent des dettes si leur exploitation n’est pas conçue au départ. Une règle réseau sans journalisation ne permet pas de distinguer un scan d’une dépendance oubliée. Un chiffrement sans inventaire des clés transforme une restauration en séance d’archéologie numérique.

Les secrets applicatifs doivent être fournis au démarrage depuis un gestionnaire dédié, jamais figés dans une image de conteneur, un dépôt Git ou une variable d’environnement visible par tous les outils de diagnostic. La rotation doit pouvoir coexister avec l’ancienne valeur pendant une période limitée. Une rotation atomique impossible impose une interruption contrôlée ; mieux vaut l’assumer que découvrir que les sessions de production dépendent d’un secret éternel.

Pour les clés de chiffrement, séparer clé de données et clé de protection permet de renouveler la seconde sans rechiffrer immédiatement tout le stockage. La sauvegarde doit inclure les données, les métadonnées de version des clés, les politiques d’accès et les journaux nécessaires à l’enquête. Sauvegarder des données chiffrées sans chemin de récupération des clés revient à construire un coffre-fort puis à couler la clé dans le béton.

La supervision doit mesurer les refus réseau, les échecs d’autorisation, les accès aux clés, les changements de règles et les écarts de configuration. Les principes d’observabilité donnent la méthode pour corréler ces signaux. Un pic de refus seul peut être un scan ; un pic de refus suivi d’un accès inhabituel à une clé mérite une réaction immédiate.

Enfin, tester la reprise est obligatoire : restaurer une sauvegarde chiffrée, récupérer les clés avec des droits minimaux, redéployer les règles de segmentation et vérifier que les anciens secrets sont refusés. La défense en profondeur ne garantit pas l’absence d’intrusion. Elle garantit seulement qu’une intrusion doit franchir plusieurs décisions indépendantes, laisser davantage de traces et accéder à moins de choses avant d’être contenue.

🐝 Ce qui arrive si on s’en passe

Sans couches indépendantes, l’analyse post-incident perd son principal outil : la délimitation. Quand une seule barrière protège tout, rien ne permet de démontrer jusqu’où un intrus est allé, et le périmètre à considérer comme compromis devient l’ensemble du système. La remise en service se transforme alors en reconstruction complète : réinstallation des hôtes, renouvellement de tous les secrets, invalidation de toutes les sessions, faute de pouvoir prouver qu’un compte ou un volume est resté hors d’atteinte. Les obligations de notification suivent la même logique : sans frontière vérifiable, l’estimation des données concernées se fait par défaut au maximum. S’y ajoute une perte de marge temporelle : un contrôle unique franchi ne produit aucun refus intermédiaire, donc aucun signal exploitable avant que l’objectif ne soit atteint.

🦫 Explication de la marmotte 🍫

Une défense en profondeur protège un service avec plusieurs niveaux qui n’ont pas le même rôle. D’abord, les règles réseau empêchent la plupart des machines inconnues de contacter les services internes. Ensuite, les machines qui hébergent les programmes limitent les droits de chaque programme : un programme qui tombe en panne ou qui est piraté ne doit pas pouvoir modifier tout le système.

Le programme qui traite les demandes reçues vérifie ensuite chaque information. Il ne doit pas croire un nom, un numéro ou un droit envoyé par un navigateur. Il vérifie l’identité de la personne, ses permissions et le format des données avant toute action. Les données enregistrées sont aussi chiffrées, c’est-à-dire transformées pour ne pouvoir être lues qu’avec une clé gardée séparément.

Ces protections sont prévues pour échouer parfois. Si une règle réseau laisse passer une mauvaise demande, la vérification du programme peut encore la bloquer. Si le programme est piraté, ses droits limités et le chiffrement peuvent empêcher l’accès à toutes les données. Si des données sont copiées, elles restent illisibles sans la clé.

Le piège consiste à répéter plusieurs fois la même protection tout en oubliant un danger différent. Il faut donc lister les attaques possibles, vérifier quelle protection les bloque, et surveiller les refus, les accès anormaux et les changements de réglages.

Pages voisines

La citent

Concevoir une défense en profondeur par couches

Elle cite

Concevoir une défense en profondeur par couches

Concevoir une défense en profondeur par couches

Défense en profondeur : une hypothèse de compromission par couche

Couches réseau, système, application et données d’une architecture web

Couverture des vecteurs d’attaque plutôt que redondance décorative

Exemple de segmentation reproductible avec nftables

Exploitation : secrets, rotation, supervision et reprise

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines