Combien de détail ? Les quatre couches de profondeur d'un DFD

Un diagramme de flux de données (DFD) trop complexe, personne ne le lit, et un trop général ne trouve pas de menaces. La modélisation de menaces permet de décrire graphiquement le système aux autres, en créant un terrain commun et des conversations de sécurité plus ciblées ; le problème est que les modèles peuvent tomber dans l'un ou l'autre extrême. « Provide context with the right depth layer » sur Microsoft Learn résout ce problème avec les couches de profondeur du DFD : quatre niveaux qui aident à décider combien de contexte incluire et quand approfondir.

La règle qui ordonne tout le post est celle-ci : chaque système a sa vue d'ensemble de haut niveau, et la plupart ont en plus des DFDs additionnels centrés sur les parties qui demandent plus de détail, comme un processus qui analyse des données hautement confidentielles ou un système d'authentification tiers. Les couches sont le mécanisme pour décider lesquels.

Couche 0 : la couche de contexte

La couche 0, appelée aussi couche du système ou couche de contexte, est le point de départ de tout système et doit se créer pour tous. Elle représente les parties principales avec assez de contexte pour comprendre comment elles fonctionnent et interagissent, et elle a trois règles de forme : elle doit tenir sur une seule page, contenir seulement les processus principaux et étiqueter clairement chaque élément.

Un DFD de couche 0 n'est pas un brouillon : c'est le diagramme qu'un inconnu du système peut lire en entier sans demander de quoi il s'agit. La restriction de page unique est celle qui rencontre le plus de résistance et celle qui apporte le plus : elle oblige à décider ce qui compte comme « principal », et cette décision est le premier accord de sécurité de l'équipe, avant de dessiner la moindre menace. Ce que la couche 0 ne fait pas, c'est répondre à comment chaque pièce fonctionne à l'intérieur ; pour ça il y a l'approfondissement. La couche 0 fonctionne aussi comme contrat de lecture : les éléments qui apparaissent ici sont ceux que les autres couches peuvent élargir.

Quand approfondir : la liste des signaux

Toutes les parties du système ne méritent pas le même détail. Une partie mérite de l'approfondissement quand elle présente un risque, et la source donne la liste concrète des signaux :

Nouveaux systèmes qui introduisent des risques inconnus.
Nouveaux analyseurs, protocoles ou formats de fichiers.
Nouveaux mécanismes d'authentification et d'autorisation.
Nouveaux algorithmes de chiffrement ou de stockage de secrets.
Intégration avec une authentification tiers comme Facebook.
Privilèges élevés requis pour la fonctionnalité principale.
Canaux de communication non chiffrés.

La liste a une logique interne : chaque entrée décrit une partie du système que l'équipe comprend moins que son code principal, ou dont la panne fait plus mal. Un analyseur de nouveaux formats est du code que personne d'audit n'a écrit avant ; un canal non chiffré est une vieille décision que le DFD vient de mettre au jour.

La procédure d'approfondissement est mécanique : on crée un élément de processus avec une étiquette claire (par ex. le nom du service web), un nouveau fichier avec exactement la même étiquette, et on centre le DFD sur cette partie. Le résultat est un diagramme de couche de processus, ou couche 1.

flowchart LR
    L0["Couche 0 : contexte<br/>une page, processus principaux"] -->|"zoom : processus étiqueté<br/>fichier avec la même étiquette"| L1["Couche 1 : processus<br/>un DFD par partie du système"]
    L1 -->|"zoom encore"| L2["Couche 2 : sous-processus<br/>un DFD par sous-partie"]
    L2 --> L3["Couche 3 : niveau inférieur<br/>chaque sous-processus en détail"]

En clair : chaque couche est un nouveau fichier nommé d'après le processus sur lequel vous avez zoomé, et chacune se justifie par un risque spécifique, pas par l'ambition de compléter l'arbre.

Couche 1 : où vit la majorité

La couche de processus contient des DFDs indépendants détaillant chaque partie du système, avec les processus de leurs parties respectives et aussi sur une seule page. La règle de la source est claire : la plupart des DFDs requièrent une couche de profondeur de processus pour une évaluation adéquate, et c'est surtout important quand le système contrôle des données confidentielles, qui ont un plus grand risque d'être violées.

Si votre système a des données confidentielles, la couche 1 n'est pas optionnelle. Les systèmes avec données confidentielles ont un plus grand risque d'être violés, et le contexte de la couche 1 aide à identifier menaces et réductions de risques avec plus d'efficacité. C'est le point où le modèle cesse d'être une présentation et commence à être un instrument de travail : chaque partie du système a son propre dessin, et chaque dessin peut passer par un cadre de menaces sans que la feuille devienne illisible.

La mécanique de la couche 1 définit aussi comment se choisit la portée de chaque diagramme : une partie du système par fichier, pas un diagramme par équipe ni par sprint. L'unité est l'architecture.

Couche 2 : pour ce que l'organisation juge critique

La couche de sous-processus se réserve aux systèmes hautement sensibles que l'organisation juge critiques : environnements protégés, traitement de données confidentielles ou classification à haut risque. Le critère d'impact est explicite dans la source : une violation dans une sous-partie pourrait mettre en danger tout le système, les clients et l'organisation. Les DFDs sont indépendants par sous-partie, aussi sur une seule page, et la nomenclature continue comme un arbre (« service web - travail - analyseur d'entrée »).

Apparaît ici la sauvegarde la plus importante de la méthode : il faut consulter l'équipe pour confirmer que ce niveau de profondeur est requis. La profondeur supplémentaire coûte des heures de modélisation et de revue ; la demander sans consulter est la façon dont les modèles meurent de Complexité.

Couche 3 : la couche de niveau inférieur

La dernière couche est pour les systèmes de niveau kernel ou très critiques, décrivant chaque sous-processus en détail. Le signal que vous êtes sérieux : il est courant d'avoir plusieurs rondes de revues de sécurité juste pour un sous-processus. Comme la couche 2, son besoin se confirme avec l'équipe, et le coût de la maintenir vivante grandit avec chaque changement du système. Le système qui arrive ici est déjà passé par trois couches de revue et il semble encore qu'il manque quelque chose à regarder ; à ce point de la gamme, cette sensation est un bon signe.

La règle de nommage qui enchaîne les couches

Les diagrammes s'enchaînent par noms, pas par références croisées. La couche 1 utilise une structure de noms similaire à un chemin (« Nom du service web : nom de travail du service web ») et la couche 2 continue comme un arbre (« nom du service web - Nom du travail - Nom de l'analyseur d'entrée »). La convention a un but pratique : en voyant un processus dans un diagramme de niveau supérieur, le nom dit exactement quel fichier ouvrir pour voir son détail. Et comme la structure imite un arbre de fichiers, l'inventaire complet de la modélisation s'audit avec l'explorateur de fichiers : des couches isolées ou des processus sans fils se voient à l'œil nu.

Couche	Nom	Quand ça s'applique	Ce qu'elle contient
0	Système (contexte)	Tous les systèmes	Parties principales, une page
1	Processus	La plupart ; obligatoire avec données confidentielles	Un DFD par partie du système
2	Sous-processus	Systèmes critiques, avec confirmation de l'équipe	Un DFD par sous-partie
3	Niveau inférieur	Niveau kernel ou très critiques	Chaque sous-processus, avec plusieurs rondes de revue

Le tableau est aussi un outil de conversation : si quelqu'un demande « le DFD du système », la réponse est la couche 0, et s'il demande le détail d'une partie, le nom du processus lui dit quelle couche 1 ouvrir. Et il a un effet secondaire sain sur la discussion de portée : « on fait la couche 2 de tout » cesse d'être un élan et devient une décision qui requiert la confirmation de l'équipe et un nom de fichier par sous-partie.

Un ajout : diagrammes par rôle d'utilisateur

En plus des quatre couches, la source recommande de créer des diagrammes basés sur des rôles d'utilisateur pour identifier les points faibles d'authentification et d'autorisation. La justification pointe vers l'extérieur : selon des sources comme OWASP (Open Web Application Security Project, le projet qui publie les listes de risques de sécurité web les plus citées), ces faiblesses peuvent être parmi les principaux problèmes de sécurité des organisations actuelles.

Les diagrammes par rôle sont un axe transversal : ils ne remplacent pas les couches, ils se lisent par-dessus. Le rôle « utilisateur anonyme » traversant la couche 0 montre ce que quelqu'un sans identifiants peut faire ; le rôle « administrateur » en couche 1 montre ce qui arrive avec les privilèges élevés dans chaque partie.

De la lecture à l'exécution

Ce parcours a été de lecture : je n'ai pas monté les couches d'un système à soi. Ce que la source rend clair, c'est la logique complète d'approfondissement ; ce qui manque, c'est de la tester, parce que c'est là qu'apparaissent les vrais doutes : si votre système de deux services a besoin de la couche 1 ou seulement d'un couche 0 bien faite, et si l'équipe confirme ou baisse la mise quand vous demandez la couche 2. Un bon premier pas est de dessiner la couche 0 de quelque chose que vous connaissez, de chercher le signal de risque le plus évident de sa liste et de zoomer seulement là.

---

*Source : le module « Provide context with the right depth layer » de Microsoft Learn.*