Analyser l'architecture de SecurePay : flux, BPMN, UML et DCT¶

Objectifs pédagogiques¶

À la fin de ce TP, vous devez être capables de :

• inventorier les composants, les acteurs et les dépendances externes d'une application à partir de son code
• 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 des interactions en UML avec un outil dédié
• découvrir, par la modélisation, des failles de conception qu'aucun scanner ne signale
• rédiger les sections d'un document de conception technique (DCT) avec des exigences de sécurité vérifiables

Prérequis¶

• Le dépôt securepay-api cloné en local
• draw.io (diagrams.net, en ligne ou en application) ou StarUML
• Un éditeur qui affiche le Mermaid (GitLab, GitHub, VS Code avec une extension) pour les diagrammes en texte
• Le cours Threat modeling STRIDE

Contexte¶

SecurePay prépare un audit de sécurité. L'auditeur demande une analyse de l'architecture logicielle : une topologie, une cartographie précise des flux de données, des modélisations BPMN et UML, et la liste argumentée des points faibles. Personne n'a jamais documenté l'application : il faut repartir du code.

Atelier 1 : Inventorier à partir du code¶

Travail demandé¶

1. Parcourez src/, package.json, Dockerfile et .env.example.

2. Dressez l'inventaire dans docs/architecture/inventaire.md :

1. Listez chaque route HTTP exposée, sa méthode, les données reçues et renvoyées, et le contrôle d'accès qui la protège.

Ce que vous devez observer¶

En suivant le code route par route, la colonne « contrôle d'accès » révèle déjà une surprise : comparez ce qu'émet /api/auth/login et ce que vérifient les routes de /api/payments.

Critère de réussite¶

Chaque composant et chaque route est inventorié, avec ses dépendances et son contrôle d'accès réel.

Atelier 2 : Cartographier les flux¶

Travail demandé¶

1. Dessinez le diagramme de flux de niveau 0 (contexte), puis de niveau 1, avec les frontières de confiance. Vous pouvez partir de ce squelette en Mermaid, où chaque sous-graphe est une zone de confiance :

flowchart LR
    subgraph Internet["Zone : Internet (non fiable)"]
        M["Site marchand"]
    end
    subgraph SP["Zone : SecurePay"]
        A(("API SecurePay"))
        L[("Journaux")]
    end
    subgraph Ext["Zone : prestataire externe"]
        P["Prestataire de paiement"]
    end
    M -- "F1 : identifiants" --> A
    A -- "jeton JWT" --> M
    M -- "F2 : demande de paiement + JWT" --> A
    A -- "F3 : paiement + clé d'API" --> P
    A -- "F4 : événements" --> L

1. Classifiez chaque donnée (publique, interne, confidentielle, secrète) et repérez les données personnelles.

2. Construisez la matrice des flux dans docs/architecture/flux.md :

Critère de réussite¶

Chaque flux est numéroté, classé, et chaque frontière franchie est visible sur le diagramme comme dans la matrice.

Atelier 3 : Le processus de paiement en BPMN¶

Travail demandé¶

1. Dans draw.io (bibliothèque BPMN) ou un outil équivalent, modélisez le processus de paiement de bout en bout :

   • un couloir par acteur : client, site marchand, API SecurePay, prestataire ;
   • événements de début et de fin (paiement accepté, refusé) ;
   • tâches : authentification, validation de la demande, calcul des frais, appel du prestataire, réponse ;
   • passerelles : demande valide ? paiement accepté ?
   • flux de messages entre couloirs, numérotés comme dans la matrice des flux.

2. Ajoutez un objet de données là où circule une donnée confidentielle ou secrète, et une annotation avec le contrôle attendu à cette étape.

3. Versionnez le fichier source (docs/architecture/paiement.bpmn.drawio) et exportez-le en SVG pour le dossier.

Critère de réussite¶

Le processus se lit sans le code : un lecteur extérieur sait qui fait quoi, où passe chaque donnée sensible, et quel contrôle la protège.

Atelier 4 : Les diagrammes UML¶

Travail demandé¶

1. Séquence : modélisez l'authentification puis le paiement, en partant du code réel et non de ce qu'il « devrait » faire :

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: le jeton est-il vérifié ici ?
    A->>P: demande de paiement (clé d'API)
    P-->>A: résultat
    A-->>M: 201 transaction créée

1. Complétez la séquence avec /calculate-tax et /recent, puis répondez à la question de la note : où, dans le code, le jeton est-il vérifié ?

2. Déploiement : nœuds (conteneur de l'API, poste ou cluster), environnements, zones réseau, et emplacement des secrets.

3. Composants : l'API, ses modules (routes/auth, routes/payments, services/paymentService) et ses bibliothèques, avec les interfaces exposées.

Ce que vous devez observer¶

Le jeton JWT est émis, mais aucune route de paiement ne le vérifie : n'importe qui peut lancer un paiement ou lister les transactions. Aucun outil d'analyse statique ne le signale, car chaque ligne de code est correcte ; c'est une faille de conception, que le diagramme de séquence rend évidente.

Critère de réussite¶

Les trois diagrammes sont versionnés, cohérents entre eux et avec la cartographie des flux.

Atelier 5 : Identifier les points faibles¶

Travail demandé¶

1. Pour chaque flux qui franchit une frontière de confiance, passez en revue les six menaces STRIDE.

2. Pour chaque composant, vérifiez : droits minimaux, point de défaillance unique, dépendances maîtrisées, secrets.

3. Rédigez le registre des points faibles dans docs/architecture/points-faibles.md :

1. Visez au moins six points faibles, dont au moins deux de conception (invisibles pour un scanner) et deux d'implémentation.

Critère de réussite¶

Chaque point faible est argumenté, relié à un élément de la cartographie et accompagné d'une recommandation vérifiable.

Atelier 6 : Rédiger le DCT¶

Travail demandé¶

1. Rédigez docs/architecture/dct.md en suivant cette structure :

1. Contexte et périmètre
2. Exigences (fonctionnelles, non fonctionnelles, de sécurité)
3. Architecture logique (composants, responsabilités, interfaces)
4. Architecture physique (déploiement, environnements, zones réseau)
5. Flux et données (cartographie, matrice des flux, classification)
6. Sécurité (authentification, autorisation, chiffrement, secrets, journalisation)
7. Exploitation (supervision, sauvegarde, reprise)
8. Risques et décisions (points faibles, mesures, décisions d'architecture)
Annexes : diagrammes BPMN et UML, inventaire

1. Écrivez au moins cinq exigences de sécurité vérifiables, chacune associée au test, à la règle d'analyse ou à la Quality Gate qui la prouvera. Par exemple : « toute route /api/payments/* exige un jeton JWT valide ; un test d'intégration vérifie qu'une requête sans jeton reçoit une réponse 401 ».

2. Justifiez au moins un choix technologique par un ADR (voir les modèles).

3. Relisez le DCT avec les trois critères qu'emploie une certification : structuration, clarté, description complète des composants.

Critère de réussite¶

Un lecteur extérieur comprend l'application, ses flux et ses risques sans ouvrir le code, et chaque exigence de sécurité est vérifiable.

Questions de synthèse¶

• Pourquoi un outil d'analyse statique ne détecte-t-il pas qu'un jeton n'est jamais vérifié ?
• Qu'apporte la matrice des flux par rapport au seul diagramme ?
• Que montre un BPMN qu'un diagramme de séquence ne montre pas, et inversement ?
• Comment transformer un point faible de conception en contrôle automatisé dans le pipeline ?
• Pourquoi versionner les diagrammes avec le code plutôt que dans un document figé ?