Defense en profondeur¶

Empiler les couches de protection — aucune mesure unique n'est infaillible.

Le principe¶

La defense en profondeur part du constat qu'aucune mesure de sécurité n'est infaillible. Chaque couche de protection peut être contournee — mais l'attaquant doit franchir toutes les couches successivement. Chaque couche ralentit, détecté ou stoppe l'attaque.

Ce n'est pas une liste de technologies a déployer. C'est un principe de conception : pour chaque menace identifiée, plusieurs mécanismes indépendants la contrent. Si l'un échoué, les autres prennent le relais.

graph TD
    Reseau["Reseau\nFirewall, segmentation, WAF"]
    Plateforme["Plateforme\nHardening, patch, runtime"]
    Application["Application\nValidation, encoding, CSRF"]
    Donnees["Donnees\nChiffrement, masking, tokenization"]
    Identite["Identite\nMFA, rotation, audit"]

    Reseau --> Plateforme --> Application --> Donnees --> Identite

Les couches de protection¶

Couche réseau¶

La première ligne de defense. Elle filtre et inspecte le trafic avant qu'il n'atteigne les applications.

Couche plateforme¶

Le durcissement de l'infrastructure et du runtime.

Couche application¶

La validation et la protection au niveau du code applicatif.

Couche données¶

La protection des données au repos et en transit.

Couche identité¶

Le contrôle des accès et la traçabilite des actions.

Détection vs prevention¶

Chaque couche a deux rôles : prévenir les attaques et détecter celles qui passent. La prevention bloque. La détection alerte. Les deux sont nécessaires.

Une couche qui previent sans détecter ne donne pas de visibilité sur les tentatives. Une couche qui détecté sans prévenir ne protégé pas mais permet de reagir.

Zones de sécurité¶

Les frontieres de sécurité découpent le système en zones de niveaux de confiance différents. Le trafic entre zones est filtre et inspecte. Le trafic intra-zone obeit a des règles plus souples, mais n'est jamais implicitement de confiance absolue.

Architecture en zones¶

graph TD
    subgraph Internet
        EXT[Clients externes]
    end

    subgraph DMZ
        WAF[WAF]
        LB[Load Balancer]
        GW[API Gateway]
    end

    subgraph Internal
        SVC_A[Service Commandes]
        SVC_B[Service Catalogue]
        SVC_C[Service Notifications]
        QUEUE[Message Queue]
    end

    subgraph Restricted
        DB_A[(DB Commandes)]
        DB_B[(DB Catalogue)]
        VAULT[Secrets Vault]
    end

    EXT --text--> WAF --text--> LB --text--> GW
    GW --text--> SVC_A
    GW --text--> SVC_B
    SVC_A --text--> QUEUE --text--> SVC_C
    SVC_A --text--> DB_A
    SVC_B --text--> DB_B
    SVC_A --text--> VAULT

Description des zones¶

Zone Internet — aucune confiance. Tout le trafic est inspecte et filtre avant d'entrer. Le WAF inspecte le trafic HTTP, le pare-feu filtre par IP et par port. Aucune connexion directe depuis Internet vers l'interne n'est autorisee.

DMZ (Demilitarized Zone) — zone exposee a Internet mais isolee de l'interne. Les composants en DMZ ne doivent pas avoir d'accès direct aux bases de données ou aux services internes sensibles. Toute communication vers l'interne passe par des points de contrôle. En cas de compromission d'un composant en DMZ, l'attaquant est contenu dans cette zone.

Internal — services applicatifs. Le trafic provient uniquement de la DMZ ou d'autres services internes. L'authentification mutuelle (mTLS) s'applique entre services. Les network policies limitent les communications au strict nécessaire.

Restricted — zone la plus protégée. Accès uniquement depuis les services internes autorises. Les secrets et les données sensibles vivent ici. Les connexions entrantes sont loggees et auditees. Toute tentative d'accès direct depuis la DMZ ou Internet est bloquee et alertee.

Règles de passage entre zones¶

Le passage d'une zone vers une zone plus protégée doit être explicitement autorise. Par défaut, le trafic est refuse.

Segmentation réseau¶

La segmentation divise le réseau en segments isoles avec des contrôles d'accès entre eux. C'est l'implémentation concrète des zones de sécurité.

Niveaux de segmentation¶

Micro-segmentation en Kubernetes¶

La micro-segmentation dans Kubernetes utilise les Network Policies pour contrôler le trafic pod-to-pod :

# Politique : le service "orders" ne peut etre appele
# que par le service "api-gateway"
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: orders-ingress
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: orders
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: api-gateway
      ports:
        - protocol: TCP
          port: 8080

Positionnement WAF / IDS / IPS¶

Le positionnement des dispositifs de détection et de prevention dans l'architecture est critique. Mal place, un WAF ne voit pas le trafic qu'il devrait inspecter.

WAF — Web Application Firewall¶

Le WAF inspecte le trafic HTTP au niveau applicatif (couche 7). Il se place devant les applications web, généralement en amont du load balancer ou intégré a celui-ci.

graph LR
    CLIENT[Client] --text--> WAF[WAF] --text--> LB[Load Balancer] --text--> APP[Application]

Fonctions principales : détection d'injections SQL, XSS, CSRF, protection contre les bots, rate limiting applicatif, virtual patching (bloquer l'exploitation d'une CVE avant le patch).

IDS — Intrusion Détection System¶

L'IDS analyse le trafic réseau pour détecter les comportements suspects. Il ne bloque pas — il alerte. Place en mode "tap" ou "mirror", il observe une copie du trafic sans l'impacter.

IPS — Intrusion Prevention System¶

L'IPS combine la détection de l'IDS avec la capacité de bloquer le trafic malveillant. Place "inline" (dans le chemin du trafic), il peut dropper les paquets suspects.

Chapitre suivant : mTLS — authentification mutuelle entre services, PKI interne et rotation automatique.