Analyse d'architecture sécurité : DCT, cartographie des flux, BPMN & UML
Objectifs pédagogiques
- Comprendre pourquoi certaines failles ne se voient qu'au niveau de l'architecture
- Structurer un document de conception technique (DCT) et y écrire des exigences de sécurité vérifiables
- Cartographier les flux de données, leurs frontières de confiance et la classification des données
- Modéliser un processus métier en BPMN et les interactions en UML
- Identifier les points faibles d'une topologie et les relier à des contrôles
Pourquoi analyser l'architecture
Les failles de conception
- Les scanners trouvent des erreurs d'implémentation : une injection, une dépendance vulnérable, un secret dans le code
- Ils ne voient pas les erreurs de conception : un contrôle d'accès absent, une confiance excessive entre composants, un flux sensible non chiffré
- L'OWASP Top 10 en fait une catégorie à part entière : la conception non sécurisée (Insecure Design)
- Une faille de conception corrigée après coup coûte une refonte, pas une ligne de code
- D'où l'analyse d'architecture avant l'implémentation, et à chaque évolution majeure
Un exemple réel : SecurePay
POST /api/auth/login délivre un jeton JWT signé- Les routes
/api/payments/process, /calculate-tax et /recent ne vérifient jamais ce jeton - N'importe qui peut lancer un paiement ou lister les transactions, sans s'authentifier
- Aucun outil SAST ne le signale : chaque ligne de code est « correcte »
- Le diagramme de séquence le rend évident : la flèche de vérification du jeton n'existe pas
- C'est un contrôle d'accès défaillant, la première catégorie de l'OWASP Top 10
La démarche
- Inventorier les composants, les acteurs et les dépendances externes
- Cartographier les flux de données et les frontières de confiance
- Classifier les données qui circulent
- Modéliser les processus (BPMN) et les interactions (UML)
- Analyser chaque flux qui franchit une frontière avec STRIDE
- Consigner dans le DCT : points faibles, exigences de sécurité, décisions
Le document de conception technique
Structure d'un DCT
- Contexte et périmètre : objectif, acteurs, hors périmètre
- Exigences : fonctionnelles, non fonctionnelles, de sécurité
- Architecture logique : composants, responsabilités, interfaces
- Architecture physique : déploiement, environnements, zones réseau
- Flux et données : cartographie, matrice des flux, classification
- Sécurité : authentification, autorisation, chiffrement, secrets, journalisation
- Exploitation : supervision, sauvegarde, reprise
- Risques et décisions : points faibles, mesures, décisions d'architecture (ADR)
Ce qui fait un bon DCT
- Structuré : chaque section répond à une question précise
- Clair : un lecteur extérieur comprend le système sans lire le code
- Complet : chaque composant est décrit, avec son rôle, ses interfaces et ses dépendances
- Justifié : chaque choix technologique a sa raison, consignée dans un ADR
- Vivant : les diagrammes sont versionnés avec le code et mis à jour à chaque évolution
- Ce sont aussi les critères d'évaluation d'un DCT en certification
Des exigences de sécurité vérifiables
| À éviter | À écrire |
| « L'application doit être sécurisée » | « Toute route /api/payments/* exige un jeton JWT valide, vérifié par un middleware commun ; un test automatisé le prouve » |
| « Les secrets sont protégés » | « Aucun secret n'a de valeur par défaut dans le code ; l'application refuse de démarrer sans JWT_SECRET » |
| « La connexion est protégée » | « Après 5 échecs en 15 minutes, la connexion d'un compte est temporisée » |
- Une exigence vérifiable devient un test, une règle d'analyse ou une Quality Gate
- L'OWASP ASVS fournit un catalogue d'exigences par niveau de sécurité
Cartographier les flux
Les éléments d'un diagramme de flux (DFD)
| Élément | Représentation | Exemple SecurePay |
| Entité externe | rectangle | site marchand, prestataire de paiement |
| Processus | cercle ou rectangle arrondi | API SecurePay |
| Stockage | deux traits parallèles | journaux, base des transactions |
| Flux de données | flèche nommée | « demande de paiement » |
| Frontière de confiance | trait pointillé | Internet / API, API / prestataire |
- Un flux qui franchit une frontière de confiance est toujours analysé
Des niveaux de détail
- Niveau 0 (contexte) : le système comme une seule boîte, ses acteurs et ses échanges avec l'extérieur
- Niveau 1 : les grands composants internes et les flux entre eux
- Niveau 2 : le détail d'un composant sensible, par exemple le traitement d'un paiement
- On descend d'un niveau là où les données sont sensibles ou les frontières nombreuses
- Chaque niveau reste cohérent avec le précédent : mêmes entités externes, mêmes flux sortants
Classifier les données
| Classe | Exemples | Exigences type |
| Publique | documentation de l'API | intégrité |
| Interne | journaux techniques sans données personnelles | accès authentifié |
| Confidentielle | montants, identifiants de bénéficiaires, données personnelles | chiffrement en transit, contrôle d'accès, minimisation |
| Secrète | clés d'API, secret de signature JWT, mots de passe | coffre, rotation, jamais journalisée |
- Les données personnelles relèvent aussi du RGPD : finalité, minimisation, durée de conservation
- La classification fixe le niveau de protection de chaque flux qui les transporte
La matrice des flux
| N° | Source | Destination | Protocole | Données | Classe | Authentification | Chiffrement |
| F1 | Site marchand | API | HTTPS 443 | identifiants | secrète | aucune (c'est le login) | TLS |
| F2 | Site marchand | API | HTTPS 443 | paiement | confidentielle | JWT non vérifié | TLS |
| F3 | API | Prestataire | HTTPS 443 | paiement | confidentielle | clé d'API | TLS |
| F4 | API | Journaux | local | événements | interne | — | — |
- La matrice sert aussi aux équipes réseau pour ouvrir les flux strictement nécessaires
- Chaque cellule « aucune » ou « non vérifié » est un point faible potentiel
Modéliser
BPMN : le processus métier
- Couloirs : un par acteur (client, site marchand, API, prestataire)
- Événements : début (commande validée), fin (paiement accepté ou refusé)
- Tâches : valider la demande, calculer les frais, appeler le prestataire
- Passerelles : les décisions (montant valide ? paiement accepté ?)
- Flux de messages : les échanges entre couloirs, qui correspondent aux flux de la cartographie
- Objets de données et annotations : où la donnée sensible apparaît, et quel contrôle s'applique
Annoter les contrôles sur le processus
| Étape BPMN | Donnée manipulée | Contrôle attendu |
| Réception de la demande | montant, bénéficiaire | jeton vérifié, schéma de requête validé |
| Calcul des frais | montant | aucune entrée interprétée comme du code |
| Appel du prestataire | paiement, clé d'API | clé lue dans le coffre, TLS vérifié |
| Réponse au marchand | résultat | aucune donnée interne divulguée |
| Journalisation | événement | ni secret ni donnée personnelle superflue |
- Le BPMN montre où se trouve la donnée ; l'annotation dit comment elle est protégée
Les diagrammes UML utiles en sécurité
- Composants : qui dépend de qui, quelles interfaces sont exposées
- Séquence : l'ordre exact des échanges, donc l'endroit où un contrôle manque
- Déploiement : nœuds, conteneurs, environnements et zones réseau
- Cas d'utilisation et d'abus : ce qu'un utilisateur légitime fait, et ce qu'un attaquant tenterait
La séquence de paiement de SecurePay
sequenceDiagram
actor M as Site marchand
participant A as API SecurePay
participant P as Prestataire de paiement
M->>A: POST /api/auth/login (identifiants)
A-->>M: jeton JWT
M->>A: POST /api/payments/process (Bearer JWT)
Note over A: aucune vérification du jeton
A->>P: demande de paiement (clé d'API)
P-->>A: résultat
A-->>M: 201 transaction créée
- La flèche « vérifier le jeton » est absente : la faille de conception apparaît d'elle-même
Des diagrammes versionnés
- Mermaid : texte rendu nativement par GitLab, GitHub et MkDocs (séquence, flux, composants)
- PlantUML : couverture UML plus large, rendu par un outil ou un serveur
- draw.io : bibliothèques BPMN et UML complètes, fichier XML versionnable
- StarUML : outil UML dédié
- Les diagrammes vivent dans le dépôt, à côté du code : ils se revoient en MR et suivent ses évolutions
- Pour un dossier écrit : export en SVG ou en PNG depuis la source versionnée
Identifier les points faibles
La méthode
- Pour chaque flux qui franchit une frontière : passer en revue les six menaces STRIDE
- Pour chaque composant : droits minimaux ? point de défaillance unique ? dépendances maîtrisées ?
- Pour chaque donnée sensible : où est-elle stockée, journalisée, copiée ?
- Pour chaque secret : où vit-il, qui y accède, comment est-il renouvelé ?
- Chaque point faible reçoit une gravité, une recommandation et un responsable
Les faiblesses d'architecture fréquentes
- Authentification présente mais autorisation absente ou non vérifiée
- Confiance implicite entre services internes (« c'est le réseau interne »)
- Validation faite seulement côté client
- Secret partagé entre composants ou environnements, ou valeur par défaut dans le code
- Flux sensible non chiffré, même en interne
- Interface d'administration exposée sur Internet
- Point de défaillance unique sur un composant critique
- Journaux qui contiennent des secrets ou des données personnelles superflues
Les points faibles de SecurePay
| Point faible | Élément | STRIDE | Gravité | Recommandation |
| Jeton JWT jamais vérifié | flux F2 | S, E | critique | middleware d'authentification sur /api/payments |
Mot de passe unique codé en dur, rôle ADMIN pour admin | processus de connexion | S, E | critique | référentiel d'utilisateurs, mots de passe hachés |
| Secrets avec valeur par défaut dans le code | API | I | haute | coffre, refus de démarrer sans secret |
Formule interprétée par eval() | calcul des frais | T, E | critique | aucune entrée exécutée comme du code |
| Aucune limite de tentatives de connexion | flux F1 | S, D | moyenne | limitation de débit et temporisation |
| Transactions listées sans contrôle d'accès | /recent | I | haute | autorisation par marchand |
Du point faible au contrôle
| Point faible | Exigence du DCT | Contrôle automatisé | Preuve |
| Jeton non vérifié | toute route de paiement exige un jeton valide | test d'intégration : requête sans jeton → 401 | rapport de tests |
| Secret par défaut | aucun secret n'a de valeur par défaut | Gitleaks + règle Semgrep maison | pipeline bloquant |
eval() | aucune entrée exécutée comme du code | règle SAST bloquante + test de non-régression | Quality Gate |
- L'analyse d'architecture alimente directement les contrôles du pipeline et le registre des risques
Anti-patterns à proscrire
- Un DCT écrit après la mise en production, pour l'audit
- Des diagrammes décoratifs, jamais mis à jour
- Une cartographie avec un flux « Internet → tout »
- Des exigences de sécurité invérifiables
- Analyser les composants sans analyser les flux qui les relient
- Ignorer les dépendances externes (prestataire, services cloud)
À retenir
- Les failles de conception échappent aux scanners : seule l'analyse d'architecture les révèle
- Le DCT décrit composants, flux, données et exigences de sécurité vérifiables, avant le code
- La cartographie des flux, avec frontières de confiance et classification, désigne ce qu'il faut protéger
- BPMN montre où circule la donnée, UML comment les composants l'échangent
- Chaque point faible devient une exigence, puis un contrôle automatisé, puis une preuve
Pour aller plus loin