CM Architecture sécurisée — le cours

Ce que le cours cherche à installer

Une architecture sécurisée ne se juge pas à la liste des outils qu’elle embarque, mais à la capacité de justifier chaque décision de conception par une menace identifiée. Le cours vous donne trois angles pour interroger n’importe quel système — la donnée qu’il manipule, le logiciel qui la traite, l’infrastructure qui l’héberge — et une règle : la sécurité n’est pas un quatrième pilier qu’on ajoute, c’est ce qui traverse les trois.

Fil conducteur de la séance : une plateforme e-commerce bancaire. La donnée, ce sont les numéros de carte ; le logiciel, c’est l’API de paiement et ses dépendances ; l’infrastructure, ce sont les serveurs qui les hébergent. Une même intrusion peut viser les trois, et il suffit d’un pilier non traité pour que les deux autres tombent.

1 · Introduction

#	Notion	En une phrase
1	Les trois piliers	Data, Software, Infrastructure — indissociables, chacun avec ses menaces propres.
1.1	Security by Design	Les exigences de sécurité entrent dans les spécifications, au même rang que les exigences fonctionnelles.
1.2	Défense en profondeur	Superposer des barrières dont les modes de défaillance sont indépendants.

Le test qui compte (1.2) : deux barrières qui tombent pour la même raison n’en font qu’une. Un WAF tombe sur une faille applicative ; un pare-feu réseau tombe sur une erreur de règle : ce ne sont pas les mêmes causes, donc ce sont bien deux couches. L’exemple du cours en superpose quatre, aux modes de défaillance indépendants : pare-feu réseau, WAF applicatif, chiffrement de disque, et un IDS/IPS qui détecte ce que les trois autres ont laissé passer.

La défense en profondeur, c’est d’abord le refus du point de défaillance unique (Single Point of Failure) : aucun dispositif seul ne porte toute la sécurité, et les couches sont de natures différentes — réseau, identité, chiffrement, détection. Déroulez l’attaque pour vous en convaincre : l’attaquant contourne le pare-feu, puis bute sur l’authentification forte de l’OS ; s’il la franchit, il atteint une base chiffrée dont la clé vit sur un serveur tiers. Chaque couche le ralentit, et chaque couche journalise son passage — le temps et la trace sont les deux dividendes de la profondeur.

Exemple concret (1.1) : rédiger la matrice des flux réseau et les contraintes de chiffrement avant d’écrire la moindre ligne de code. Le développeur reçoit alors une contrainte, pas une remarque en revue. Le même principe appliqué aux données personnelles s’appelle Privacy by Design — et il est exigé par le RGPD (art. 25).

Les principes transversaux

Ils n’appartiennent à aucun pilier : ils s’appliquent aux trois, et reviendront tout au long du cours.

Separation of Duties. Aucune action critique ne repose sur une seule personne — le modèle des deux clés du coffre, qu’il faut tourner ensemble. En pratique : le développeur ne déploie pas en production, l’administrateur ne modifie pas le code, un virement important exige un opérateur et un superviseur. Une compromission — ou une erreur — individuelle ne suffit plus.

KISS — la complexité est l’ennemie de la sécurité. Un système qu’on ne comprend plus est un système qu’on ne sait plus défendre. Et une mesure trop pénible engendre son propre contournement : le mot de passe imbuvable finit sur un post-it sous le clavier — la sécurité a créé sa propre vulnérabilité. La friction doit peser sur l’attaquant, jamais sur l’utilisateur : SSO, biométrie, des parcours légitimes simples.

Pas de sécurité par l’obscurité. Cacher l’architecture n’est pas la protéger. C’est le principe de Kerckhoffs : un système doit rester sûr même si l’attaquant en connaît tous les rouages — seule la clé est secrète. Si votre sécurité repose sur l’espoir que personne ne trouve, elle est déjà tombée.

Pour approfondir — IDS/IPS : signatures vs comportement · Segmentation & micro-segmentation · ANSSI, Guide d’hygiène informatique.

2 · Pilier 1 — Sécurité de la Data

#	Notion	En une phrase
2	Patrimoine informationnel	Toute donnée n’a pas la même valeur : on classe avant de protéger.
2.1	At rest vs in transit	Deux états, deux menaces, deux mécanismes.
2.2	Authentification vs autorisation	Qui tu es ≠ ce que tu as le droit de faire.
2.3	Moindre privilège	L’écart entre ce qu’un composant fait et ce qu’il peut faire est la surface offerte.

Ce qu’il faut retenir

Classer d’abord (2). Identifier les données sensibles — santé (HDS), moyens de paiement (PCI-DSS), données personnelles (RGPD) — pour leur appliquer une politique d’accès et de stockage dédiée. Encore faut-il savoir lesquelles on détient : c’est cette classification qui déterminera ensuite dans quelle zone réseau elles vivent. Et la donnée a un cycle de vie — création, stockage, transit, archivage, destruction — dont chaque étape a ses menaces et ses contrôles propres.

Le chiffrement ne remplace pas le contrôle d’accès (2.1). Chiffrer PostgreSQL sur disque en AES-256 (at rest) et forcer TLS 1.3 sur tous les flux web (in transit), ce sont deux réponses à deux menaces distinctes. Mais la donnée chiffrée au repos est en clair pour toute application autorisée à la lire : le chiffrement répond au vol de support, pas à la compromission d’un compte applicatif.

Une authentification forte n’autorise rien (2.2). Valider l’identité par mot de passe + MFA, puis vérifier que le jeton JWT porte le rôle attendu. Sans contrôle du rôle, tout utilisateur authentifié devient administrateur. Rappel sur le JWT : il est signé donc infalsifiable, mais lisible par tous — on n’y met jamais de secret.

Le test du moindre privilège (2.3). L’exemple du cours : un service web qui tourne sous un compte système non-administrateur, avec un accès en lecture seule sur ses fichiers de configuration. Et le test : écrivez en une phrase ce que fait chaque compte de service. Si la phrase contient « et éventuellement », le privilège est trop large.

Ce que le moindre privilège borne, c’est le rayon d’impact d’un compte compromis. Et il s’érode tout seul : au fil des postes et des projets, les droits s’accumulent et ne sont jamais retirés — c’est le privilege creep. Deux contre-mesures : des revues de droits régulières, et l’accès Just-In-Time — le privilège est accordé au moment du besoin, pour la durée du besoin, puis retiré.

Pour approfondir — RGPD art. 25 (protection des données dès la conception) · PCI-DSS v4.0 · Référentiel HDS · OWASP Authentication et Authorization Cheat Sheets.

3 · Pilier 2 — Sécurité Software & DevSecOps

#	Notion	En une phrase
3	DevSecOps	Ce qui n’est pas automatisé dans le pipeline ne sera pas fait.
3.1	Shift Left	Déplacer les contrôles au plus tôt : chaque étape franchie multiplie le coût de correction par dix.
3.2	SAST	Lire le code sans l’exécuter : on voit le défaut, pas encore son exploitation.
3.3	DAST	Attaquer l’application qui tourne : on voit l’exploitation, pas la cause.
3.4	SCA	Votre code, c’est 10 % de ce que vous livrez — le reste vient d’ailleurs.

Les trois familles et leurs angles morts

Famille	Voit	Ne voit pas	Outil cité en cours
SAST	Le code source (ex. une concaténation SQL vulnérable)	Le comportement réel — et il produit des faux positifs	SonarQube
DAST	L’application en exécution, vue de l’extérieur — sur l’environnement de recette	Le code non atteint par le scan	OWASP ZAP
SCA	Les CVE des dépendances (`package.json`, image Docker)	Une faille dans votre code	Trivy, Snyk

La règle qui fait la différence : un contrôle qui n’échoue jamais le build n’est pas un contrôle, c’est un rapport — et un rapport que personne ne lit. Choisissez le seuil, assumez-le, et faites en sorte qu’une exception se date, se nomme et expire.

Et générez le SBOM au passage : le jour où une CVE majeure sort, la question « sommes-nous concernés ? » devient une requête au lieu d’une enquête. L’ordre compte — on génère le SBOM, puis on le scanne :

syft . -o cyclonedx-json > sbom.json
grype sbom:sbom.json --fail-on high

Concevoir sécurisé coûte moins que réparer sécurisé. On ne rend pas un gratte-ciel parasismique après construction : les fondations se coulent au début, ou jamais. Ajouter du chiffrement à une base legacy ou greffer OAuth sur une vieille API, c’est du retrofit — bugs, régressions, et un coût sans commune mesure avec le même choix fait en conception. Le Shift Left est la traduction industrielle de ce constat : chaque étape franchie multiplie le coût de correction par dix.

Exemple concret (3.1) : bloquer un git push via un hook pre-commit si une clé d’API ou un mot de passe en clair est détecté. Le secret n’entre jamais dans l’historique — car un secret commité est un secret compromis, même supprimé au commit suivant.

Pour approfondir — Scan de vulnérabilités · Durcissement & conformité · GitOps Workflow · OWASP Top 10 · Cyber Resilience Act (UE 2024/2847) pour l’obligation de SBOM.

4 · Pilier 3 — Sécurité Infrastructure & modélisation des flux

#	Notion	En une phrase
4	Contenir plutôt qu’espérer	On conçoit pour borner le rayon d’impact, pas pour empêcher l’intrusion.
4.1	Segmentation (DMZ, App, DB)	Le critère de zone, c’est l’exposition et la sensibilité — pas l’organigramme.
4.2	Nord-Sud vs Est-Ouest	L’essentiel du trafic est latéral, et c’est celui qu’on ne filtrait pas.
4.3	Sécurité selon le modèle OSI	Chaque couche voit ce que les autres ne voient pas.
4.4	Firewalling & Deny All	Fermer par défaut, c’est choisir un mode d’échec bruyant plutôt que silencieux.
4.5	Micro-segmentation	Descendre le grain au workload — à condition que l’inventaire soit juste.
4.6	Interconnexion de SI distants	Relier deux réseaux de confiance à travers un réseau qui ne l’est pas.

Ce qu’il faut retenir

Sur un réseau plat, le rayon d’impact est égal au SI entier (4). La première machine compromise donne accès à toutes les autres. C’est la métrique que la segmentation cherche à réduire — en isolant, physiquement ou virtuellement, les différents types d’équipements.

Le plus exposé et le plus précieux ne vivent jamais dans la même zone (4.1) — ils tomberaient ensemble. Serveur web en DMZ publique, base de données en sous-réseau privé sans accès direct depuis Internet.

Une fois le frontal compromis, le pare-feu périmétrique ne joue plus aucun rôle (4.2). Seul le contrôle latéral décide de la suite : WAF sur le trafic entrant (Nord-Sud), mTLS entre microservices internes (Est-Ouest).

Un pare-feu L4 ne voit qu’une connexion TCP légitime vers le port 443 (4.3). Le contenu malveillant lui est structurellement invisible — d’où le partage des rôles : pings et scans de ports bloqués en L3/L4 (iptables), injections XSS/SQL filtrées en L7 (WAF), en complément et non en remplacement.

Deny All se paie en journal des refus (4.4). Règle finale Block All (* → *), puis uniquement les flux justifiés — Allow Web-Server → DB-Server sur TCP/5432, et rien d’autre. Sans journalisation des refus, une politique fermée devient indiagnosticable en exploitation. Et souvenez-vous du filtrage à états : une règle décrit un échange bidirectionnel dans le sens de l’initiative — elle autorise donc aussi la réponse, et son contenu.

N’entrez pas dans la micro-segmentation avant d’avoir réussi la segmentation (4.5). Un grain fin appliqué sur une cartographie fausse produit des règles fines et fausses — et une exploitation ingérable.

Mais la segmentation macro a une limite structurelle : elle contrôle bien le Nord-Sud et ignore l’Est-Ouest — souvent plus de 70 % du trafic d’un datacenter moderne. Un serveur web compromis pivote vers la base de données du même sous-réseau sans jamais repasser par le pare-feu. La micro-segmentation répond en descendant le deny-all au niveau de la charge de travail elle-même — la VM, le conteneur — de façon software-defined : agents sur les hôtes, pare-feu distribués de l’hyperviseur, NetworkPolicies Kubernetes ou Cilium. Et les règles s’écrivent par identités et étiquettes, pas par adresses — « Frontend → Backend : 443 », jamais 192.168.1.10 : en cloud comme sous Docker, les IP sont éphémères. Les bénéfices sont directs : stopper le mouvement latéral (les rançongiciels en vivent), et isoler un périmètre de conformité — le scope PCI-DSS — au lieu d’y faire entrer tout le SI. Vous en ferez d’ailleurs sans le savoir en TP : des réseaux bridge Docker isolés et des règles iptables sur les hôtes, c’est déjà de la micro-segmentation — basique, mais réelle.

Deux pièges classiques du VPN site-à-site (4.6) : des plans d’adressage qui se chevauchent — deux réseaux en 192.168.1.0/24 ne s’interconnectent pas — et un tunnel qui, une fois monté, autorise tout. Le VPN chiffre le transport, il ne remplace pas la matrice de flux.

Zero Trust — quand le périmètre disparaît

Le modèle historique — castle-and-moat, une frontière fortifiée autour d’un intérieur de confiance — reposait sur une hypothèse qui n’existe plus : que le SI ait un intérieur. Cloud, télétravail, BYOD, partenaires : les ressources et les utilisateurs sont partout, le périmètre nulle part. Et le modèle échouait déjà de l’intérieur : un phishing réussi place l’attaquant « dedans », avec tout le champ libre que la confiance implicite lui offre.

D’où le renversement : « never trust, always verify ». La confiance est une vulnérabilité, et l’emplacement réseau n’est jamais un critère suffisant. Trois piliers :

Vérification explicite et continue — chaque accès est évalué sur des signaux contextuels : identité, santé de l’appareil, localisation, comportement. Pas une fois à l’entrée : en continu.
Moindre privilège poussé à l’extrême — Just-In-Time et Just-Enough-Access : le droit exact, au moment exact, pour la durée exacte.
Assume breach — on conçoit en supposant la compromission déjà acquise : chiffrer même le trafic interne, segmenter, surveiller. L’objectif n’est plus seulement d’empêcher l’intrusion, mais d’en limiter l’expansion.

Pour approfondir — Pare-feu à état & flux réseau · Segmentation & micro-segmentation · VPN IPsec — le concept · ANSSI, Recommandations pour la mise en place de cloisonnement système · NIST SP 800-207 (Zero Trust).

5 · Infrastructure as Code & conteneurisation

#	Notion	En une phrase
5	L’infrastructure devient du code	Même rigueur que le code applicatif : versionné, relu, testé.
5.1	IaC sécurisée	Le dépôt qui reconstruit le SI le cartographie aussi.
5.2	Durcissement des conteneurs	Le noyau est partagé : un conteneur n’est pas une VM.
5.3	Réseaux Docker & isolement	Le bridge par défaut met tout le monde dans la même pièce.

Ce qu’il faut retenir

Une infrastructure décrite en fichiers est une infrastructure qu’on peut relire avant qu’elle n’existe (5). Fichiers de configuration et conteneurs se traitent avec la même rigueur que le code applicatif : revue obligatoire, historique, tests avant application — et des scripts idempotents.

Le contrôle s’exécute avant le déploiement (5.1). Scanner un script Terraform avec Checkov pour vérifier qu’aucun groupe de sécurité n’expose SSH à 0.0.0.0/0 : l’erreur n’atteint jamais le cloud. Et c’est le même mouvement que vous vivrez en TP — les zones décrites une fois, dans un fichier :

# Vagrantfile : les zones du TP, décrites une fois
NODES = {
  "LAB-FRONT-01" => { zone: "lab-front", ip: "10.10.40.20" },
  "LAB-DB-01"    => { zone: "lab-back",  ip: "10.10.10.20" },
}
config.vm.network "private_network",
                  # LA ligne qui garantit la segmentation :
                  # réseau interne : aucun chemin ne sort de l'hyperviseur
                  virtualbox__intnet: n[:zone], ip: n[:ip]

Revers à connaître : un dépôt IaC est une carte complète du SI, et souvent la cible la plus rentable — secrets hors du dépôt, revue obligatoire sur tout changement de filtrage.

Le minimum non négociable côté conteneur (5.2) :

frontal:
  image: gcr.io/distroless/java17     # image minimale, pas de shell
  user: "1001:1001"                   # jamais root
  read_only: true
  cap_drop: [ALL]                     # on retire tout...
  cap_add: [NET_BIND_SERVICE]         # ...puis le strict nécessaire
  security_opt: [no-new-privileges:true]

Une image sans shell prive l’attaquant de son premier outil après l’exploitation. À l’inverse, --privileged et le montage du socket Docker annulent presque toute l’isolation.

La limite du réseau Docker (5.3). Un bridge personnalisé, non publié sur l’hôte, isole les conteneurs web et db du reste — mais ce trafic reste invisible au pare-feu de zone, qui est au-dessus. Pour deux niveaux de sensibilité différents, on sépare l’hôte, pas seulement le réseau — et c’est le choix retenu dans les TP, où chaque zone est une VM derrière une patte d’OPNsense.

Pour approfondir — Vagrant · Convention de nommage · Durcissement & conformité · CIS Docker Benchmark · NIST SP 800-190 (Application Container Security).

6 · Méthodologie de sécurisation — étude de cas ATLAS

La dernière partie du cours passe de la théorie à une architecture réelle : ATLAS, étudiée périmètre par périmètre. La démarche vaut plus que le cas : c’est celle que vous appliquerez à vos propres conceptions.

#	Notion	En une phrase
6	Doctrine de sécurité	Security by Design + défense en profondeur : deux fondements appliqués ensemble, pas l’un après l’autre.
6.1	Trois piliers transverses	Moindre privilège, Zero Trust, minimisation des données — sur tous les périmètres, sans exception.
6.2	Périmètre infrastructure	Réduire l’exposition externe, empêcher la propagation latérale.
6.3	Périmètre logiciel — chaîne de livraison	Une infra durcie ne vaut rien si l’application y introduit ses propres failles.
6.4	Périmètre logiciel — surface applicative	Ce que le client a validé n’engage que le client.
6.5	Périmètre données	L’actif dont la compromission est la moins réversible.
6.6	Socle transverse	Les couches précédentes empêchent ; celle-ci suppose que quelque chose passera.
6.7	La grille de sécurité	Cinq fonctions × trois périmètres, aucune case vide.

Ce qu’il faut retenir

La doctrine (6). La modélisation des menaces précède les spécifications : chaque fonctionnalité métier arrive avec ses contraintes de sécurité attachées. Et la défense en profondeur — doctrine ANSSI : aucun dispositif n’est inviolable — fait que l’architecture prévoit qu’un secret compromis, une faille logicielle ou une erreur de configuration ne suffise jamais à tout emporter.

Les trois piliers transverses (6.1). Moindre privilège : chaque identité, humaine ou applicative, ne détient que les droits indispensables à sa tâche, pour une durée limitée. Zero Trust : la confiance n’est jamais liée à la position d’un équipement sur le réseau — accéder à une ressource interne exige une validation explicite, jamais une approbation implicite héritée du LAN. Minimisation des données : une donnée ni collectée, ni stockée, ni exposée élimine nativement le risque d’exfiltration.

Infrastructure (6.2). Cloisonnement d’exécution — conteneurs non-root, racine en lecture seule, capacités noyau réduites, OS durci selon les guides CIS et l’hygiène ANSSI — et résilience traitée comme une composante de la sécurité : répartition multi-nœuds avec bascule automatique, exécution intégralement locale, réseau non routable injoignable de l’extérieur même en cas d’erreur de filtrage.

Chaîne de livraison (6.3). Le SSDLC fait de la sécurité une étape formelle de chaque itération, pas une revue finale. Deux points saillants du cas : la détection de secrets porte sur tout l’historique du dépôt, pas sur les seules modifications en cours — un secret retiré au commit suivant reste exploitable ; et le build multi-étapes élimine chaînes de compilation, dépendances de développement et interpréteurs de commandes de l’image finale.

Surface applicative (6.4). Rôles stricts et authentification forte pour l’administration ; validation des entrées par liste d’autorisation — on énumère ce qui est permis et on rejette le reste, jamais l’inverse ; requêtes intégralement paramétrées — l’injection SQL est neutralisée structurellement, pas filtrée ; secrets injectés en mémoire au démarrage depuis un coffre-fort dédié. Et en multi-tenant, l’isolation s’applique au plus près du stockage, pas par un filtre applicatif : une erreur dans une couche haute ne peut pas provoquer de fuite transverse.

Données (6.5). Minimisation et rétention définie — les charges utiles analysées sont purgées, seules les métadonnées subsistent ; chiffrement en transit sur tous les flux y compris internes, et au repos (AES-256), avec des clés gérées par un composant distinct des données qu’elles protègent ; supervision étanche — le dashboarding n’utilise pas le compte de production mais un rôle en lecture seule sur des vues SQL filtrées ; et un journal d’audit en écriture seule (append-only), distinct des journaux applicatifs : un attaquant devenu privilégié ne peut pas effacer sa trace sans que ce soit détectable.

Détection & gouvernance (6.6). Ce qui n’est pas détecté ne peut pas être traité. Les seuils portent sur les signaux caractéristiques d’une attaque en cours — pics d’échecs d’authentification, volumétrie anormale sur un tenant — et non sur des métriques d’usage moyennes : un seuil mal choisi produit du bruit et détruit la confiance dans l’alerte.

La grille de sécurité, en une page (6.7)

	Infrastructure	Logiciel	Données
Prévention	Segmentation VPC, OS durci, exposition minimale	SSDLC, revue de code, validation par schéma	Minimisation des collectes, rétention limitée
Confinement	Réseau privé non routable, conteneurs non-root	RBAC applicatif, isolation multi-tenant	Vues SQL filtrées (CLS), rôles restreints
Contrôle	Scans de vulnérabilité d’hôte	SAST, SCA et SBOM bloquants en CI/CD	Chiffrement AES-256 & gestion des clés
Détection	Supervision réseau / PaaS	Journalisation applicative structurée	Journal d’audit inaltérable (append-only)
Résilience	Multi-nœuds, sauvegardes isolées	Pipeline de reconstruction automatisé	Procédure de restauration testée

Pour approfondir — Durcissement & conformité · Scan de vulnérabilités · OWASP ASVS · CIS Benchmarks.

Synthèse — les trois piliers, une seule posture

Résilience n’est pas invulnérabilité. On ne supprime pas l’incident : on en borne la portée, on le rend visible, et on se reconstruit sans son concepteur.

Glossaire du cours

Terme	Définition
ACL	Liste ordonnée de règles d’autorisation ou de refus appliquée sur une interface.
AES-256	Algorithme de chiffrement symétrique. La robustesse réelle dépend de la gestion des clés, pas de la taille annoncée.
Append-only	Journal en ajout seul : ni modification ni suppression des entrées existantes, y compris par un administrateur.
Authentification (AuthN)	Vérification de l’identité d’une entité.
Autorisation (AuthZ)	Vérification de ses droits sur une ressource donnée.
Bridge (Docker)	Réseau par défaut auquel Docker rattache tout conteneur sans configuration : tous s’y voient mutuellement. Le bridge personnalisé est nommé, avec DNS entre conteneurs et isolation vis-à-vis des autres réseaux.
BYOD	Bring Your Own Device : usage d’équipements personnels pour accéder au SI — l’un des facteurs qui dissolvent le périmètre.
Capability	Fragment des droits de root, accordé ou retiré individuellement.
Castle-and-moat	Modèle périmétrique historique : une frontière fortifiée, une confiance implicite à l’intérieur. Rendu obsolète par le cloud, le télétravail et le BYOD.
cgroup	Plafond de ressources (CPU, mémoire) imposé à un groupe de processus.
Checkov / tfsec	Analyseurs statiques de code d’infrastructure : le SAST appliqué au Terraform.
CI/CD	Intégration et livraison continues : chaque modification déclenche build, tests et déploiement.
Column-level security (CLS)	Restriction d’accès au niveau de la colonne : le rôle voit la ligne sans en voir les champs sensibles.
Compte de service	Identité non humaine utilisée par une application. Jamais nominative, souvent oubliée à la revue des droits.
CVE	Identifiant public d’une vulnérabilité connue.
Cul-de-sac	Zone où le trafic entre sans jamais ressortir — le modèle du puits de journaux.
Cycle de vie de la donnée	Création, stockage, transit, archivage, destruction : chaque étape a ses menaces et ses contrôles propres.
DAST	Analyse dynamique de l’application en cours d’exécution, vue de l’extérieur.
Défense en profondeur	Superposition de barrières indépendantes, pour qu’une seule défaillance ne compromette pas l’ensemble.
Deny All	Politique par défaut fermée : tout est interdit sauf ce qui a été explicitement autorisé.
Distroless	Image ne contenant que l’application et ses dépendances d’exécution : ni shell, ni gestionnaire de paquets — donc très peu de surface et très peu de CVE.
DMZ	Zone tampon hébergeant les services exposés, séparée à la fois d’Internet et du réseau interne.
Egress	Trafic sortant d’une zone ; l’interdire est la mesure anti-exfiltration la plus simple.
Endpoint	Point d’entrée d’une API : une URL + une méthode.
Faux positif	Alerte sur un cas non exploitable ; c’est le principal coût d’exploitation du SAST.
Filtrage à états	Le pare-feu mémorise les connexions établies : une règle décrit un échange bidirectionnel, dans le sens de l’initiative — elle autorise donc aussi la réponse, et son contenu.
Flux Est-Ouest	Trafic latéral entre deux ressources internes — souvent la majorité du trafic d’un datacenter moderne, et le terrain du mouvement latéral.
Flux Nord-Sud	Trafic entrant ou sortant du réseau.
Gate	Contrôle bloquant : s’il échoue, la livraison s’arrête.
Groupe de sécurité	Pare-feu attaché à une ressource cloud. `0.0.0.0/0` signifie « depuis n’importe où sur Internet ».
Hardened OS	Système durci : services inutiles retirés, comptes et permissions restreints, paramètres alignés sur un référentiel (CIS, ANSSI).
HDS	Agrément français d’hébergeur de données de santé.
Hook pre-commit	Script exécuté avant l’enregistrement d’un commit ; il peut le refuser.
IaC	Provisionnement de l’infrastructure par des fichiers versionnés et rejouables, plutôt que par des actions manuelles.
IDS / IPS	Système de détection (alerte) ou de prévention (blocage) d’intrusion.
Idempotence	Propriété d’un script qui, appliqué deux fois, produit le même état.
Injection SQL	Insertion de code SQL dans une entrée utilisateur concaténée à une requête ; le correctif est la requête paramétrée.
IPsec	Suite de protocoles assurant chiffrement, intégrité et authentification au niveau IP.
JIT / JEA	Just-In-Time / Just-Enough-Access : le droit exact, accordé au moment du besoin, pour la durée du besoin, puis retiré.
JWT	Jeton signé transportant identité et rôles. Signé donc infalsifiable, mais lisible par tous.
Liste d’autorisation (allow-list)	On énumère ce qui est permis et on rejette le reste. L’inverse — la liste d’interdiction — laisse passer tout ce qu’on n’a pas su prévoir.
MFA	Authentification à plusieurs facteurs : ce que l’on sait, ce que l’on possède, ce que l’on est.
Matrice de flux	Tableau exhaustif des communications autorisées entre zones ; ce qui n’y figure pas est interdit. C’est la spécification dont les règles sont la traduction.
Micro-segmentation	Isolation au niveau du workload individuel, appliquée de façon distribuée, avec des règles exprimées par identités et étiquettes plutôt que par adresses IP.
Minimisation	Principe de sécurité et exigence RGPD : ne traiter que les données strictement nécessaires à la finalité.
MitM	Attaquant placé entre deux interlocuteurs, capable de lire ou d’altérer l’échange.
Modèle OSI	Découpage en sept couches ; en sécurité on retient surtout L3 (IP), L4 (port) et L7 (contenu).
Moindre privilège	N’accorder que les droits strictement nécessaires à la fonction.
Mouvement latéral	Progression d’un attaquant de machine en machine à l’intérieur du SI, après la compromission initiale.
mTLS	TLS mutuel : les deux extrémités présentent un certificat.
Namespace	Cloisonnement de la vue qu’un processus a du système. Ce n’est pas une frontière matérielle.
Noisy neighbor	Dégradation subie par un locataire du fait de la consommation anormale d’un autre sur une ressource partagée.
PaaS	Plateforme d’exécution conteneurisée qui prend en charge l’orchestration, laissant à l’équipe la seule responsabilité de l’application.
PCI-DSS	Norme de sécurité des données de l’industrie des cartes de paiement.
PKI	Infrastructure qui délivre et révoque les certificats internes.
Plan d’adressage	Répartition des sous-réseaux ; il doit rester disjoint entre sites interconnectés.
Politique réseau	Règle d’autorisation exprimée sur des étiquettes plutôt que sur des adresses IP (NetworkPolicy, Cilium).
Principe de Kerckhoffs	Un système reste sûr même si l’attaquant en connaît toute l’architecture ; seule la clé est secrète.
Privacy by Design	Security by Design appliqué aux données personnelles ; exigé par le RGPD (art. 25).
Privilege creep	Accumulation de droits au fil des postes et des projets, jamais retirés ; se combat par des revues de droits régulières.
Rayon d’impact	Étendue de ce qu’un attaquant atteint depuis un point de compromission donné. C’est la métrique que la segmentation cherche à réduire.
RBAC	Attribution des droits par rôle plutôt qu’individu par individu.
Recette	Environnement de validation, image de la production, sur lequel on peut attaquer sans risque.
Réseau interne (intnet)	Commutateur virtuel isolé : seules les VM rattachées se voient — et le trafic inter-zone est obligé de traverser le pare-feu.
Réseau non routable	Plan d’adressage sans route vers Internet : injoignable depuis l’extérieur, même en cas d’erreur de filtrage.
SAST	Analyse du code source, sans exécution.
SBOM	Nomenclature des composants embarqués dans un artefact (CycloneDX, SPDX). Rendue obligatoire par le Cyber Resilience Act pour les produits mis sur le marché européen.
SCA	Détection des vulnérabilités connues dans les dépendances réutilisées.
SDN	Software-Defined Networking : réseau piloté par logiciel, qui permet d’appliquer le filtrage au plus près des charges de travail.
seccomp	Filtre qui restreint les appels système qu’un processus a le droit d’émettre.
Secret	Clé d’API, mot de passe, certificat privé : tout élément dont la divulgation donne un accès.
Security by Design	Intégration des exigences de sécurité dès la conception.
Security by Obscurity	Faire reposer la sécurité sur le secret de l’architecture : anti-pattern — voir principe de Kerckhoffs.
Separation of Duties	Aucune action critique ne repose sur une seule personne : décider et exécuter sont deux rôles distincts.
Seuil d’alerte	Condition qui transforme une observation en action. Mal choisi, il produit du bruit et détruit la confiance dans l’alerte.
Shift Left	Déplacer les contrôles de sécurité au plus tôt dans le cycle.
SPOF	Single Point of Failure : composant unique dont la défaillance emporte tout ; la défense en profondeur est son refus organisé.
SSDLC	Cycle de développement où la sécurité est une étape formelle de chaque itération, pas une revue finale.
STRIDE	Grille de modélisation des menaces : usurpation, altération, répudiation, divulgation, déni de service, élévation de privilège.
Surface d’attaque	Ensemble des points par lesquels un attaquant peut interagir avec le système.
TLS 1.3	Version courante du protocole de chiffrement du transport ; supprime les suites cryptographiques obsolètes.
VPN site-à-site	Tunnel permanent entre deux réseaux, transparent pour les postes qui l’empruntent.
WAF	Filtre applicatif de couche 7, qui inspecte le contenu des requêtes HTTP.
Workload	Unité de traitement déployée : une VM, un conteneur, un pod.
XSS	Injection de code exécuté dans le navigateur d’un autre utilisateur.
Zero Trust	« Never trust, always verify » : chaque accès est authentifié et autorisé individuellement, quelle que soit l’origine réseau de la demande. Repose sur la vérification continue, le moindre privilège (JIT/JEA) et l’assume breach.
Zone de confiance	Regroupement de machines partageant exposition, sensibilité et conséquence en cas de compromission.

Ce qu’on vous demandera en TP

L’attendu n’est pas que « ça marche ». C’est que chaque ligne de votre matrice de flux ait une justification, et que vous puissiez la défendre. On part du besoin applicatif, pas de la topologie : chaque ligne naît d’une fonction que quelqu’un réclame.

❌ Justification refusée	Pourquoi elle ne dit rien
« Frontale → Données, car la frontale doit accéder aux données. »	Tautologie : la règle se justifie par elle-même.
« PostgreSQL a besoin du 5432. »	Décrit la technique, pas le besoin.
« Pour l’administration. »	Aucun demandeur, aucune limite.

✅ Justification acceptée	Pourquoi elle tient
« Le catalogue lit ses articles en base ; aucun autre port n’est nécessaire. »	Une fonction, et une limite.
« Chaque zone pousse ses journaux vers la supervision, qui ne répond pas. »	Le sens de l’initiative est nommé.
« L’exploitant se connecte en SSH depuis le poste d’admin uniquement. »	Qui, d’où, et le reste exclu.

La règle : une justification tient quand elle nomme une fonction, un demandeur et une limite.

Le critère d’arrêt : votre matrice est finie quand, pour chaque paire de zones, vous pouvez dire soit la ligne qui l’autorise et pourquoi, soit la règle qui l’interdit.

Référentiels cités

ANSSI — Recommandations pour la mise en place de cloisonnement système · Recommandations relatives à l’interconnexion d’un SI à Internet · Guide d’hygiène informatique
NIST — SP 800-207 Zero Trust Architecture · SP 800-190 Application Container Security Guide
OWASP — Top 10 · ASVS · Cheat Sheet Docker Security · ZAP
CIS Benchmarks — Docker, Ubuntu, PostgreSQL
IEC 62443 — zones et conduits en environnement industriel / OT
Cyber Resilience Act — Règlement (UE) 2024/2847 : SBOM, gestion des vulnérabilités, divulgation coordonnée
RGPD — art. 25, protection des données dès la conception · PCI-DSS v4.0 · HDS

Voir aussi la page Ressources — la bibliothèque pour les guides complets.