Module 5 : NetSecDevOps et Sécurité Automatisée

Module 5 Module 5

DevSecOps appliqué au réseau

Définition

Intégrer la sécurité à chaque étape du cycle DevOps, plutôt qu’en contrôle final avant mise en production.

Shift-left

Déplacer les contrôles de sécurité le plus tôt possible dans le pipeline (dès le commit), pour détecter un problème avant le déploiement plutôt qu’après.

Étapes типiques d’un pipeline CI/CD sécurisé

Commit --> Lint --> Validation --> Tests --> Déploiement --> Monitoring

Pipeline CI/CD sécurisé avec shift-left Pipeline CI/CD sécurisé avec shift-left Les contrôles de sécurité (lint, validation, tests) sont poussés le plus tôt possible dans le pipeline.

Étape Rôle
Lint vérifier la syntaxe (ex. JSON/YAML valide)
Validation vérifier la cohérence métier (ex. pas de règle « any-any »)
Tests tests de non-régression sur les flux attendus
Déploiement application automatisée sur l’équipement cible
Monitoring vérification post-déploiement (état, alertes)

Firewall-as-Code (FaC)

Principe

Versionner les règles de pare-feu comme du code (lien avec le Module 1) : chaque changement passe par une Pull Request, une revue, et un pipeline CI/CD avant application.

main (protégée) <-- PR <-- feature/ouverture-flux-web
                              |
                         CI : lint + tests de non-régression

Tests de non-régression sur les flux

Avant d’appliquer une nouvelle règle, vérifier automatiquement que :

  • les flux qui doivent être autorisés le sont toujours,
  • les flux qui doivent être bloqués le restent (pas d’ouverture accidentelle).

Zero Trust

Principes

  • Jamais de confiance implicite, même à l’intérieur du réseau,
  • chaque accès est authentifié et autorisé individuellement,
  • moindre privilège : un utilisateur ou service n’accède qu’à ce dont il a strictement besoin.

ZTNA vs VPN classique

Critère VPN classique ZTNA
Accès accordé à tout le sous-réseau distant à une ressource précise
Confiance implicite une fois connecté vérifiée à chaque accès
Surface d’attaque large (tout le LAN exposé) réduite (accès unitaire)

ZTNA vs VPN classique ZTNA vs VPN classique VPN classique : accès à tout le sous-réseau. ZTNA : accès vérifié, point-à-point, à une seule ressource.

Réseau overlay WireGuard

Les solutions ZTNA modernes (NetBird, Tailscale…) s’appuient souvent sur WireGuard : un protocole VPN léger, chiffré, qui crée un réseau virtuel (overlay) entre pairs, indépendamment de leur position réseau réelle.

SOAR (Security Orchestration, Automation and Response)

Cycle détection → décision → réponse

IDS/IPS détecte --> Webhook/alerte --> Script SOAR décide --> Action sur le pare-feu (API)

Boucle SOAR détection-décision-réponse Boucle SOAR détection-décision-réponse Un cycle continu : le script peut décider d’agir (bloquer) ou d’ignorer (faux positif).

Playbook

Séquence d’actions prédéfinie déclenchée par un type d’alerte (ex. « IP suspecte détectée » → « bloquer cette IP sur le pare-feu pendant 1h »).

Risque de faux positifs

Une automatisation trop agressive peut bloquer du trafic légitime. Bonnes pratiques :

  • limiter la portée et la durée des actions automatiques (ex. blocage temporaire),
  • journaliser toute action automatique pour audit,
  • prévoir une liste blanche pour les adresses critiques.

Micro-segmentation Kubernetes

NetworkPolicy

Ressource Kubernetes qui définit les flux autorisés entre pods, à la manière d’un pare-feu interne au cluster.

Default deny

Par défaut, Kubernetes autorise tout le trafic entre pods. Une bonne pratique de sécurité consiste à définir une politique default deny, puis à n’autoriser explicitement que les flux nécessaires :

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]

Sélecteurs de labels

Les NetworkPolicy ciblent des pods via leurs labels, pas leurs adresses IP (qui changent à chaque redéploiement) :

  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend

Rôle du CNI

Les NetworkPolicy ne sont appliquées que si le plugin réseau du cluster (CNI) les supporte (ex. Calico, Cilium). Certains CNI basiques les ignorent silencieusement.

Trois états d’une NetworkPolicy Kubernetes Trois états d’une NetworkPolicy Kubernetes Sans politique : tout est ouvert. Avec default-deny : tout est fermé. Avec des autorisations ciblées : seuls les flux nécessaires (par label) sont réouverts.

Compliance-as-Code

Principe

Vérifier automatiquement, par script, qu’une configuration respecte un référentiel de sécurité (ex. benchmarks CIS), plutôt que par audit manuel ponctuel.

Audit continu

Exécuter les contrôles régulièrement (pipeline planifié) pour détecter rapidement un écart, et générer un rapport automatisé (liste des non-conformités, criticité).

Boucle d’audit continu Compliance-as-Code Boucle d’audit continu Compliance-as-Code Un déclencheur planifié relance périodiquement les contrôles sur toute la flotte d’équipements.

À retenir

  • Le shift-left rapproche les contrôles de sécurité du début du pipeline.
  • Firewall-as-Code applique au pare-feu les mêmes garanties que Git + CI/CD (Module 1).
  • ZTNA remplace l’accès réseau large du VPN par un accès unitaire, vérifié en continu.
  • Un playbook SOAR automatise détection → décision → réponse, avec des garde-fous contre les faux positifs.
  • Les NetworkPolicy Kubernetes appliquent le moindre privilège au niveau des pods, via des labels.
  • Compliance-as-Code transforme un audit de sécurité en contrôle automatisé et reproductible.