Défense en profondeur : principe, couches et limites

Niveau : débutant à intermédiaire.

Prérequis : connaître les notions de compte utilisateur, serveur, application, base de données, réseau, vulnérabilité et risque. Une première familiarité avec les journaux et l'authentification facilite la lecture, mais aucun produit particulier n'est requis.

L'exercice est exclusivement défensif. Il porte sur une architecture fictive et ne demande aucun scan, contournement de contrôle ou test sur un système réel. Tu travailleras à partir d'hypothèses, d'un schéma et de critères de vérification.

Le glossaire du NIST définit la défense en profondeur comme l'application de plusieurs contre-mesures, de manière superposée ou progressive, pour atteindre des objectifs de sécurité. L'idée centrale est simple : un contrôle peut être absent, mal configuré, contourné, indisponible ou inadapté au scénario rencontré. L'architecture doit donc éviter qu'une seule erreur ouvre directement l'accès aux ressources les plus sensibles.

Imagine une application métier accessible depuis Internet. Son filtrage réseau peut réduire l'exposition, mais il ne corrige pas une erreur dans le code de l'application. Une correction applicative ne protège pas nécessairement un compte dont le mot de passe a été divulgué. L'authentification multifacteur renforce ce compte, mais elle ne remplace pas la limitation de ses privilèges. Des droits limités réduisent l'impact, sans signaler automatiquement une activité anormale. La journalisation et la détection rendent cette activité observable, tandis que les sauvegardes et les procédures de restauration répondent à la possibilité qu'une perturbation se produise malgré les autres mesures.

Une défense en profondeur bien conçue poursuit quatre fonctions complémentaires :

1. Prévenir, en réduisant la probabilité qu'une action indésirable aboutisse.
2. Détecter, en produisant et en analysant des traces exploitables.
3. Contenir, en limitant le périmètre et les privilèges accessibles après une défaillance.
4. Restaurer, en préparant le retour à un état maîtrisé et vérifié.

Ces fonctions ne correspondent pas nécessairement à quatre produits distincts. Une mesure peut contribuer à plusieurs fonctions. La segmentation limite certains flux et facilite aussi leur observation. Un fournisseur d'identité applique des règles d'accès et produit des événements d'authentification. Une sauvegarde protège la disponibilité seulement si elle est isolée, suivie et restaurable.

La défense en profondeur n'est donc pas un dessin composé de cercles immuables autour d'une donnée. C'est une façon de raisonner sur les défaillances possibles, les dépendances et les conséquences. L'ANSSI, dans son essentiel consacré à la défense en profondeur, insiste elle aussi sur l'association de mesures organisationnelles et techniques plutôt que sur une protection unique supposée parfaite.

Commencer par une liste de solutions conduit facilement à payer plusieurs fois pour des fonctions similaires tout en laissant un chemin critique sans protection. Commence plutôt par identifier ce qui doit être protégé : données personnelles, secrets techniques, comptes d'administration, service indispensable à l'activité, sauvegardes, postes de travail ou chaîne de déploiement. Attribue un propriétaire et une criticité à chaque actif.

Pour chaque actif critique, formule des scénarios raisonnables. Un compte ordinaire peut être compromis. Un ordinateur portable peut être perdu. Une application peut comporter une vulnérabilité. Une règle réseau peut être trop permissive. Un fournisseur externe peut subir une interruption. Il ne s'agit pas de prévoir chaque événement possible, mais de représenter les situations qui influencent réellement les choix d'architecture.

Trace ensuite les chemins d'accès. Qui peut atteindre l'actif ? Depuis quel réseau et avec quelle identité ? Quels services intermédiaires interviennent ? Où les secrets sont-ils conservés ? Quelles opérations sont autorisées ? Quelles traces sont générées ? Cette vue révèle les dépendances communes. Par exemple, trois applications protégées par des règles différentes restent dépendantes d'un même annuaire. Si cet annuaire est indisponible ou mal administré, la diversité apparente des applications ne constitue pas trois défenses indépendantes.

Pour chaque mesure envisagée, pose six questions :

• Quel scénario cette mesure traite-t-elle ?
• Prévient-elle, détecte-t-elle, contient-elle ou aide-t-elle à restaurer ?
• De quelles données, identités ou infrastructures dépend-elle ?
• Comment constates-tu qu'elle fonctionne encore ?
• Que se passe-t-il si elle échoue ?
• Une autre mesure indépendante limite-t-elle alors les conséquences ?

L'indépendance est importante. Deux contrôles qui reposent sur le même secret, la même console d'administration et le même réseau de gestion peuvent échouer ensemble. À l'inverse, le moindre privilège, une segmentation bien définie, des journaux protégés et une sauvegarde isolée réduisent des conséquences différentes. L'indépendance absolue est rarement possible, mais les dépendances doivent être visibles et traitées.

Enfin, documente les modes dégradés. Si l'annuaire central ne répond plus, les administrateurs disposent-ils d'un accès de secours protégé et surveillé ? Si la collecte de journaux s'arrête, une alerte de santé est-elle émise ? Si un contrôle bloque à tort une opération essentielle, qui peut autoriser une exception, pour combien de temps et avec quelle trace ? Une couche que personne ne sait exploiter en situation réelle peut devenir un point de fragilité.

Il n'existe pas une liste universelle de couches valable pour toutes les organisations. Une petite structure utilisant principalement des services en ligne n'a pas la même architecture qu'un site industriel ou qu'un hébergeur. Le découpage suivant sert de grille de lecture, pas de modèle à copier sans analyse.

Gouvernance, inventaire et gestion du risque

Cette couche donne une direction aux autres. Elle comprend l'inventaire des actifs, les responsabilités, les règles de configuration, la gestion des changements, le suivi des vulnérabilités, les exigences imposées aux fournisseurs et les plans de continuité. Un actif inconnu peut rester sans correctif, sans propriétaire et sans journalisation. Une procédure non attribuée peut rester inutilisée au moment où elle devient nécessaire.

Identités et privilèges

Les identités relient une personne, une machine ou un service à des droits. Cette couche comprend l'authentification multifacteur adaptée au risque, le moindre privilège, la séparation des comptes ordinaires et administratifs, la revue des accès, la suppression rapide des comptes inutiles et la protection des identités techniques. L'objectif n'est pas seulement de vérifier une identité à l'entrée, mais de limiter ce qu'elle peut faire et pendant combien de temps.

Postes, serveurs et équipements

Le durcissement réduit les fonctions inutiles, les configurations faibles et les possibilités d'exécution non maîtrisées. Il s'accompagne de mises à jour, de protection des terminaux, de chiffrement lorsque le risque le justifie, de contrôle des périphériques et d'une administration séparée des usages courants. Un poste conforme le jour de son installation peut dériver. Il faut donc suivre son état et traiter les écarts.

Réseaux et communications

Cette couche contrôle les flux entre zones, services et points d'administration. Elle inclut la réduction des services exposés, la segmentation, le filtrage entrant et sortant, le chiffrement des communications et la protection des interfaces de gestion. Une segmentation utile est liée aux besoins métier et vérifiée. Un schéma réseau sans règles maintenues n'isole rien.

Applications et données

La sécurité applicative comprend la validation des entrées, les contrôles d'autorisation côté serveur, la gestion des secrets, les dépendances, les revues et les tests adaptés. Les données nécessitent une classification, des accès limités, une protection en transit et au repos selon le risque, ainsi que des règles de conservation. Un pare-feu ne compense pas une application qui remet les données d'un autre utilisateur à un compte authentifié mais non autorisé.

Journalisation, détection et réponse

Les événements d'identité, d'administration, d'application, de réseau et de poste doivent répondre à des questions définies. Les bonnes pratiques de la CISA sur la journalisation et la détection recommandent une base cohérente de journaux et leur centralisation afin de soutenir l'analyse. Il faut aussi surveiller la santé de la collecte, protéger les traces, synchroniser les horloges et préparer les procédures de triage et de réponse. Une alerte sans propriétaire ni première action attendue n'est pas une défense complète.

Sauvegarde, continuité et restauration

Les sauvegardes doivent couvrir les données et configurations nécessaires, être protégées contre la modification non autorisée et faire l'objet de tests de restauration. La continuité prévoit les priorités, les délais, les dépendances et les décisions. Posséder une copie ne garantit ni sa lisibilité, ni sa complétude, ni la capacité à remettre un service en production de façon sûre.

La défense en profondeur et le Zero Trust sont souvent rapprochés, mais ils ne sont pas synonymes. La défense en profondeur cherche à combiner des mesures complémentaires afin d'éviter une dépendance à un contrôle unique. Le NIST SP 800-207 sur l'architecture Zero Trust refuse, pour sa part, d'accorder une confiance implicite à une identité ou à un actif uniquement en raison de sa localisation physique ou réseau.

Une architecture Zero Trust évalue les demandes d'accès à partir d'informations comme l'identité, l'état de l'actif, la ressource demandée, le contexte et la politique applicable. Elle vise une décision d'accès explicite et limitée. Elle ne signifie pas que chaque utilisateur est hostile, ni qu'il suffit d'acheter un produit portant cette étiquette.

Les deux démarches peuvent se renforcer. Une décision d'accès contextuelle constitue une mesure parmi d'autres. Elle reste entourée par la sécurité de l'identité, le durcissement du poste, la protection de l'application, la journalisation, la détection et la restauration. Si le moteur de décision, l'annuaire ou la télémétrie deviennent indisponibles, tu dois aussi connaître le comportement prévu : refus des accès, fonctionnement dégradé, procédure de secours ou maintien temporaire de certaines opérations.

Il faut également éviter de remplacer un périmètre unique par une dépendance unique à l'identité. Un compte fortement authentifié peut disposer de droits excessifs. Un appareil déclaré conforme peut devenir vulnérable après son évaluation. Une règle correcte peut utiliser une donnée de contexte incomplète. La vérification explicite améliore le contrôle des accès, mais elle ne supprime ni les vulnérabilités applicatives, ni les erreurs d'administration, ni les besoins de détection et de reprise.

Pour appliquer les deux idées sans confusion, décris d'abord la décision d'accès : sujet, ressource, contexte, politique et durée. Puis examine ce qui se passe avant et après cette décision. Le terminal est-il durci ? L'application vérifie-t-elle encore ses autorisations ? Les privilèges sont-ils limités ? Les événements sont-ils exploitables ? Une compromission peut-elle être contenue ? Le service peut-il être restauré ? Cette chaîne replace le contrôle d'accès dans une défense plus large.

L'entreprise fictive Atelier Boréal emploie 45 personnes. Elle utilise une application web de gestion des commandes, accessible aux clients, et un espace d'administration réservé à huit salariés.

L'architecture connue est la suivante :

• un frontal web est accessible depuis Internet sur HTTPS ;
• le frontal transmet les requêtes à un serveur applicatif ;
• le serveur applicatif accède à une base contenant les clients et les commandes ;
• les salariés utilisent un fournisseur d'identité commun pour la messagerie et l'espace d'administration ;
• les administrateurs utilisent actuellement leur compte professionnel ordinaire ;
• les journaux du frontal et du fournisseur d'identité sont centralisés, mais ceux de l'application ne le sont pas ;
• une sauvegarde quotidienne de la base est conservée avec un compte administré depuis le même fournisseur d'identité ;
• les postes reçoivent des mises à jour et une protection de terminal ;
• aucune règle ne limite explicitement les connexions sortantes du serveur applicatif.

Travaille uniquement sur cette description. Ne tente aucune vérification sur un service réel.

Étape 1 : identifier les actifs et les scénarios

Liste au moins quatre actifs critiques. Tu peux retenir la base de données, l'espace d'administration, le fournisseur d'identité, les sauvegardes et les journaux. Étudie ensuite trois scénarios fictifs : le mot de passe d'un salarié autorisé à administrer l'application est compromis ; le serveur applicatif exécute une requête inattendue à la suite d'une erreur logicielle ; le compte qui administre les sauvegardes devient indisponible.

Pour chaque scénario, note ce qui est actuellement prévenu, ce qui serait détectable, ce qui limite l'impact et ce qui permettrait la restauration. Écris inconnu lorsque la description ne fournit pas l'information. N'invente pas un contrôle.

Étape 2 : proposer des mesures complémentaires

Choisis au moins une amélioration pour chaque scénario. Tu peux proposer des comptes administratifs séparés, une MFA adaptée, une autorisation applicative contrôlée côté serveur, des privilèges minimaux pour la base, un filtrage sortant justifié, la centralisation des journaux applicatifs, une alerte sur les actions sensibles, un compte de secours protégé ou une sauvegarde isolée. Pour chaque proposition, indique la fonction visée et sa dépendance principale.

Étape 3 : définir une vérification

Associe à chaque mesure un test défensif et non intrusif. Exemples : revue trimestrielle des comptes administratifs ; contrôle automatisé de la réception d'un événement applicatif fictif ; vérification documentée qu'un serveur ne peut joindre que les destinations nécessaires ; restauration d'une copie dans un environnement isolé ; exercice sur table simulant l'indisponibilité du fournisseur d'identité.

Critère de réussite

Tu as réussi si ton tableau contient au moins quatre actifs, trois scénarios, les quatre fonctions prévention, détection, contention et restauration, puis une méthode de vérification pour chaque mesure proposée. Au moins une proposition doit réduire une dépendance commune, par exemple en séparant l'administration des sauvegardes du compte utilisé au quotidien. Tu dois aussi signaler au moins deux inconnues au lieu de supposer que les contrôles existent.

La défense en profondeur réduit certaines dépendances, mais elle ne supprime pas le risque. Son efficacité diminue rapidement lorsque les couches sont seulement présumées, lorsqu'elles partagent les mêmes causes de défaillance ou lorsqu'elles ne sont plus adaptées à l'architecture réelle.

Accumuler des produits sans scénario

Plusieurs consoles peuvent couvrir le même signal tout en laissant une application critique sans journalisation. Chaque contrôle doit être associé à un actif, un scénario, un responsable et une méthode de vérification. Sinon, la complexité augmente sans que la couverture soit démontrée.

Confondre redondance et indépendance

Deux outils configurés par le même compte privilégié et alimentés par la même source de données peuvent échouer ensemble. La diversité de fournisseurs ne suffit pas si les décisions reposent sur la même information erronée. Recherche les dépendances techniques, humaines et organisationnelles communes.

Négliger les interfaces entre couches

Un pare-feu peut autoriser un flux correctement, alors que l'application accorde trop de droits. Une MFA peut réussir, alors que le poste utilisé n'est plus maîtrisé. Une alerte peut être exacte, mais rester sans traitement faute de procédure. Les interfaces, les transferts de responsabilité et les modes dégradés demandent autant d'attention que les composants.

Produire des traces sans capacité de réponse

Une journalisation abondante n'est pas une capacité de détection complète. Il faut vérifier la réception, l'horodatage, la conservation, les droits d'accès, les règles, les procédures et la disponibilité des personnes chargées d'analyser. Les recommandations de la CISA citées plus haut relient précisément la qualité des événements à la capacité de détecter et d'enquêter.

Oublier l'exploitation quotidienne

Les droits s'accumulent, les règles réseau dérivent, les exceptions deviennent permanentes et les connecteurs cessent de transmettre. Définis des indicateurs simples : couverture de l'inventaire, âge des comptes inactifs, état des collecteurs, résultats des restaurations, exceptions arrivant à échéance et délais de traitement des alertes. Ces mesures ne prouvent pas une sécurité parfaite, mais rendent les écarts visibles.

Croire qu'une couche compense tout

Une sauvegarde aide à restaurer, mais ne corrige pas une fuite de données. Une détection rapide réduit le temps d'exposition, mais ne remplace pas un contrôle d'autorisation. Une MFA diminue certains risques liés aux mots de passe, mais n'empêche pas toutes les compromissions de session. Décris toujours la limite de chaque mesure.

Revois enfin l'architecture après un changement important, un incident, une acquisition, une migration ou l'apparition d'un nouveau scénario crédible. La défense en profondeur est un processus de conception et de maintien. Elle reste utile tant que les couches correspondent aux actifs réels, que leurs dépendances sont comprises et que leur fonctionnement est régulièrement vérifié.