Les cinq éléments d'un diagramme de flux de données

Un diagramme de flux de données (DFD) se compose de formes qui créent des représentations graphiques du système, et chaque forme a une fonction unique. Les bien utiliser améliore les données que reçoivent vos collègues et l'équipe de sécurité, et évite des documents de conception interminables ; si les éléments sont négligés, le système se déploie avec des vulnérabilités que personne n'a dessinées. « Create a threat model using data-flow diagram elements » sur Microsoft Learn détaille les cinq éléments du DFD, le contexte que chacun porte et les règles qui les composent. Ce post les parcourt dans cet ordre.

Les cinq éléments

Forme	Élément	Fonction
Cercle	Processus	Activité qui reçoit, modifie ou redirige l'entrée vers les sorties
Lignes parallèles	Magasin de données	Stockage temporaire ou permanent
Carré	Entité externe	Processus, magasin ou application hors contrôle direct
Flèches directionnelles	Flux de données	Mouvement de données entre éléments
Lignes pointillées ou carré pointillé	Limite de confiance	Flux en traversant des zones de confiance différentes

La distinction entre forme et fonction est la clé du vocabulaire : un cercle représente un processus, les lignes parallèles un magasin de données, et « le service » ou « la base de données » est le détail à l'intérieur. Qui lit votre DFD identifie l'élément avant le détail, et avec ça sait déjà quelles questions de sécurité s'appliquent. Chaque interaction que le dessin montre est analysée ensuite pour identifier d'éventuelles menaces et des façons de réduire le risque. Le contexte de chaque élément n'est pas de la documentation pour l'archive : c'est la liste d'hypothèses que le cadre de menaces va interroger quand viendra le tour de trouver des menaces.

Le processus : la tâche qui transforme

Le processus est une activité qui modifie ou redirige l'entrée vers les sorties : un microservice qui reçoit un appel d'API et le renvoie vers le service de gestion d'API, ou le code qui valide les entrées. Son contexte répond à sept questions : code (C#, C++, Objective C, Java, scripting), niveau de permission (kernel, local, administration), isolation du service, entrée (tout le monde, comptes locaux, seulement administrateurs), validation (comment il analyse et accepte l'entrée), authentification (Entra ID ou autre) et autorisation (ACL ou autre, où l'ACL est la liste de contrôle d'accès qui définit qui peut voir ou modifier).

Les sept réponses transforment « il y a un processus ici » en « il y a un processus ici qui tourne en C#, accepte l'entrée de n'importe qui et valide à sa manière ». Ce détail est ce dont un cadre de menaces a besoin pour générer des menaces concrètes.

Quant à l'endroit où il va dans le dessin : le processus s'ajoute entre magasins de données, entre entités externes et autres éléments, et entre processus. Il peut aussi servir de « zoom » : dans un DFD de niveau supérieur, un processus est clairement étiqueté et un DFD indépendant est créé pour ce processus spécifique, donc le détail est disponible en se rapprochant. Le diagramme du dessus ne change pas ; ce qui apparaît est un fichier frère avec l'étiquette du processus, et cette convention rend l'inventaire des dessins navigable sans explications. La même pièce peut représenter plusieurs tâches sous un processus quand le détail n'est pas encore nécessaire.

Le magasin de données : où restent les données

Le magasin s'utilise dès que des données sont stockées : Azure SQL, un cache local, le cache du navigateur pour la session, les événements de journal dans une base de données. Un cache qui garde les cookies liés au service d'un utilisateur est un magasin de données, lignes parallèles et tout. Son contexte : type (Azure SQL, cookies, local), fonction (partager des données, sauvegardes, journaux de sécurité, identifiants ou secrets), niveau de permissions (contrôle d'accès : qui lit et écrit) et contrôles additionnels (chiffrement, disque, signatures numériques).

Trois règles de composition sortent de là. Entre deux magasins de données il doit y avoir un processus, parce que les processus contrôlent toute la communication entre magasins. Les magasins et les entités externes initient le flux de données, donc il faut vérifier que le DFD en contient au moins un des deux. Et ce qui est presque toujours oublié : le post-traitement des données, comme les services d'analytics (Azure Analytics), qui mérite aussi d'être dans le dessin.

Le détail oublié a une conséquence : un service d'analytics qui n'est pas dans le DFD est du trafic qui traverse des limites de confiance sans être modélisé.

L'entité externe : ce que vous ne contrôlez pas

L'entité externe représente un processus, magasin ou application complet hors de votre contrôle direct : un utilisateur qui interagit avec un service, un service d'authentification tiers. Son contexte : origine (interne ou externe), type (personne, fournisseur de services ou service web), authentification (Entra ID ou autre) et autorisation (ACL ou autre). La règle pratique : ce que vous ne pouvez pas modifier directement va en entité externe, et ça inclut la partie du système qui tourne du côté de quelqu'un d'autre.

Marquer quelque chose comme entité externe est aussi un acte d'honnêteté sur le périmètre de la modélisation : de cette boîte vous ne recevrez pas d'aide quand vous penserez aux contrôles ; vous ne pourrez décider que de la façon dont vous vous y communiquez.

Le flux de données : ce qui bouge et comment

Le flux de données documente le mouvement entre chaque interaction d'éléments : les identifiants envoyés par un utilisateur, la requête pour ajouter une entrée, et normalement aussi les réponses à chaque requête. Son contexte est le plus détaillé : description (jeton de session, chaîne SQL, identifiants), protocole (HTTPS ; SOAP, le protocole de messages basé sur XML ; REST, le style d'API sur HTTP), séquence de flux (numérotée pour suivre l'ordre), type de charge (cookies, XML, charges SOAP, REST ou JSON), contrôles additionnels (protection contre la falsification et autres marques de sécurité), authentification et autorisation.

La séquence numérotée mérite une mention à part : c'est ce qui permet de reconstruire l'ordre des flux quand le DFD a plus de deux éléments, et aussi ce qui rend un diagramme discutable à voix haute étape par étape.

La limite de confiance : où l'attaquant vise

La limite de confiance décrit le flux de données en traversant des zones de confiance différentes : pare-feu, connexions à des services tiers, parties du système réservées aux administrateurs. Les lignes représentent le flux en traversant de grands environnements comme Internet ; les carrés représentent des environnements plus petits comme les sandboxes et les réseaux d'entreprise. Son contexte est la description : limite de réseau d'entreprise, Internet, abonnement Azure.

L'avertissement de la source est direct : les zones aux zones changeantes sont les plus visées par les attaquants et doivent se concevoir avec soin. Microsoft maintient des prérequis prédéfinis de zone de confiance pour ses ingénieurs. La règle pratique qui reste est simple : chaque flèche qui croise une limite de confiance mérite son protocole écrit et son contrôle nommé, parce que ce croisement est exactement là où le système cesse de contrôler ses propres conditions.

Trois systèmes, trois dessins

Les éléments s'utilissent dès qu'un DFD se crée, et le cas change selon le système. Dans un microservice Azure, on ajoute des éléments pour les utilisateurs, les processus d'authentification, le stockage de données, les processus de requête de données et les processus de contrôle des réponses, sans oublier les changements de niveau de zone de confiance. Dans une API publique, les éléments centraux sont utilisateurs, stockage, journalisation et supervision : la journalisation et la supervision apparaissent ici parce qu'une API publique se gère en regardant ses logs, et gérer sans eux c'est gérer à l'aveugle. Dans une nouvelle fonctionnalité sur une application existante, le dessin inclut les parties existantes et les nouvelles, ce qui est le cas où l'équipe ne dessine en général que le nouveau et oublie avec quoi ça percute.

flowchart LR
    U([Utilisateur<br/>entité externe]) -->|"identifiants (HTTPS)"| P[(Processus<br/>microservice)]
    P -->|"requête"| A[Magasin de données<br/>Azure SQL]
    A -->|"réponse"| P
    P -->|"réponse"| U
    subgraph Zone de confiance Azure
        P
        A
    end

En clair : un utilisateur d'Internet croise la limite de confiance vers un processus qui parle avec un magasin ; chaque flèche qui croise la ligne pointillée est une conversation que le cadre de menaces va interroger. Le dessin est court exprès : les cinq éléments apparaissent une fois chacun, et ça suffit pour que la conversation de sécurité commence sur des faits.

De la lecture à l'exécution

Ce parcours a été de lecture : je n'ai pas dessiné de vrai DFD avec ces formes et contextes. Ce que la source rend clair, c'est le vocabulaire complet et les règles de composition ; ce qui manque, c'est de l'appliquer à un système à soi, parce que c'est là qu'apparaissent les vrais doutes : si votre cache va comme magasin ou comme processus, si le fournisseur d'authentification tiers est une entité externe ou partie du système, et combien de contexte le dessin encaisse avant de devenir illisible. Un bon premier exercice est de dessiner le microservice le plus ennuyeux que vous connaissez avec les cinq éléments et de vérifier que chaque flèche qui croise une limite de confiance a son protocole écrit. Ensuite comparez la liste d'hypothèses écrite dans les contextes à ce qu'un collègue de l'équipe de sécurité aurait regardé dans le même dessin : la différence entre les deux listes est la carte de ce que vos hypothèses ne couvrent pas.

---

*Source : le module « Create a threat model using data-flow diagram elements » de Microsoft Learn.*