Be Wise Apps
Read in English · Leer en español · Auf Deutsch lesen
Section 8.1 sur 8.8 · Intermédiaire · 20 min de lecture
Principes de sécurité pour les architectes
Leçon vidéo
5 min · narré en anglais, avec sous-titresÉcouter seulement (audio)
Lire la transcription
La plupart des violations graves ne viennent pas d’attaques ingénieuses contre la cryptographie. Elles viennent de décisions de conception sur la confiance que personne n’a prises explicitement. Cette leçon vous donne les principes pour les prendre délibérément.
Pensez à la façon dont une agence bancaire est protégée. Il y a une porte d’entrée fermée à clé, et le personnel n’a les clés que des pièces dont il a besoin. Il faut être deux pour ouvrir la chambre forte. Il y a des caméras, et une alarme qui appelle la police. Et tout cela a été prévu dès la conception. La sécurité logicielle fonctionne de la même façon : les architectes décident tôt où se trouvent les portes fermées à clé, qui reçoit quelles clés et ce qui se passe quand une serrure cède.
Le vocabulaire de départ, c’est la triade CIA. Sur la plateforme de livraison de repas, la confidentialité couvre les adresses des clients, la position en direct des livreurs et les coordonnées bancaires de versement des restaurants. L’intégrité couvre les prix, les remboursements et les versements. Un attaquant qui ramène le prix d’un repas à zéro n’a rien lu de secret, mais il a causé un vrai tort. La disponibilité compte surtout pendant le pic du soir. Nommez les propriétés qui comptent pour chaque actif, car elles entrent en conflit. Échouer en mode fermé protège les données mais coûte de la disponibilité. Une carte publique peut échouer en mode ouvert vers une copie en cache, alors qu’un remboursement doit échouer en mode fermé.
En 1975, Jerome Saltzer et Michael Schroeder ont publié huit principes de conception qui restent le fondement de la conception sécurisée, parce qu’ils portent sur la structure, pas sur la technologie. En voici cinq. L’économie de mécanisme : garder la sécurité petite et simple. Une seule bibliothèque d’autorisation, partagée et bien relue, et non des contrôles écrits différemment dans chaque service. Les valeurs par défaut sûres : en cas de doute, ou quand quelque chose échoue, la réponse est non. Un moteur de politique injoignable signifie refuser. La médiation complète : vérifier chaque accès, à chaque fois. Le service des commandes vérifie à chaque requête que ce client possède bien cette commande. La séparation des privilèges : exiger deux conditions indépendantes, comme deux clés. Un remboursement important exige un second approbateur. Et le moindre privilège : seulement les privilèges nécessaires, pour la durée nécessaire. Le compte de base de données du service de la carte ne peut pas lire les données des paiements.
La défense en profondeur superpose des contrôles indépendants, afin qu’une seule défaillance n’expose pas l’actif. Voici les couches sur le chemin d’une commande de la plateforme. L’app client est à l’extérieur de la frontière de confiance. Elle ne communique avec la plateforme que par HTTPS, et rien de ce qui se trouve sur l’appareil n’est considéré comme fiable. À l’intérieur, la périphérie absorbe les afflux de trafic et applique des limites de débit. L’API gateway vérifie la signature, l’expiration, l’audience et le scope de chaque token. Le service des commandes vérifie que ce client a le droit de voir cette commande. Ainsi, même si la passerelle a un bug, un client ne peut pas lire la commande d’un autre. La base de données utilise un compte au moindre privilège et elle est chiffrée au repos, avec des sauvegardes sous des clés distinctes. La journalisation et les alertes sur toutes les couches devraient intercepter ce qui passe malgré tout. Le mot clé est « indépendants » : deux couches qui échouent pour la même raison ne sont qu’une seule couche dessinée deux fois.
Sécurisé par défaut signifie qu’affaiblir la protection exige un acte délibéré. Si le modèle de service partagé inclut déjà la validation des tokens et la journalisation de sécurité, chaque nouveau service démarre sécurisé. Certains appellent cela une paved road, un chemin balisé. La surface d’attaque, c’est tout ce qu’un attaquant peut atteindre. Supprimer un endpoint inutilisé réduit le risque à moindre coût que n’importe quel contrôle ajouté. Une frontière de confiance est l’endroit où la confiance change, et c’est là que l’authentification, l’autorisation et la validation des entrées ont leur place. Tout ce qui se trouve sur l’appareil du client est sous le contrôle de l’attaquant, donc masquer un bouton n’est pas une autorisation.
Appliquons les principes. Une première conception des remboursements par le support permet à n’importe quel agent de rembourser n’importe quelle commande, de n’importe quel montant. Avec le moindre privilège, les agents ne peuvent rembourser que les commandes de leur propre marché, et l’outil ne peut jamais lire les données de carte. Avec les valeurs par défaut sûres, si un contrôle échoue ou expire, le remboursement est refusé. Aucun chemin de repli ne saute les contrôles. Avec la médiation complète, Paiements vérifie lui-même chaque remboursement par rapport au débit initial, au lieu de faire confiance à l’outil. Avec la séparation des privilèges, les remboursements de plus de cent livres, ou un troisième remboursement au même client dans la semaine, exigent l’approbation d’un superviseur. Et chaque remboursement est inscrit dans un journal d’audit où l’on ne peut qu’ajouter. Désormais, un agent malhonnête, ou quelqu’un qui a pris le contrôle du compte d’un agent, est limité à de petits remboursements journalisés dans un seul marché.
Les architectes sont responsables des décisions qui concernent plusieurs équipes et sont coûteuses à changer : les frontières de confiance, le modèle d’identité et d’autorisation, et quelles données sont chiffrées avec quelles clés. Les équipes sont responsables de la bonne application : l’autorisation à chaque endpoint et à chaque objet, la validation des entrées et des dépendances à jour. Et l’OWASP Top 10, la liste des risques des applications web établie par l’Open Worldwide Application Security Project, est une liste de sensibilisation, pas une norme. Elle vous aide à vérifier que rien d’important ne manque.
La section complète contient les huit principes, le tableau de l’OWASP Top 10 et le cycle de développement sécurisé. Ensuite, dans la section huit point deux, vous apprendrez à modéliser les menaces d’une conception. À très vite.
Ce qu’il faut savoir
- La sécurité est une qualité de la structure : l’emplacement des frontières de confiance, ce que chaque composant peut faire et le chemin que suivent les données déterminent la plupart des propriétés de sécurité, et la plupart des violations exploitent de telles décisions plutôt que la cryptographie.
- La confidentialité, l’intégrité et la disponibilité, plus l’authenticité, l’imputabilité et la non-répudiation, doivent être nommées pour chaque actif parce qu’elles entrent en conflit : échouer en mode fermé protège les données mais coûte de la disponibilité.
- Les principes de Saltzer et Schroeder de 1975 (économie de mécanisme, valeurs par défaut sûres, médiation complète, conception ouverte, séparation des privilèges, moindre privilège, moindre mécanisme commun, acceptabilité psychologique) restent le fondement de la conception sécurisée.
- La défense en profondeur superpose des contrôles indépendants afin qu’une seule défaillance n’expose pas un actif ; la sécurité par défaut et une paved road (chemin balisé) font du chemin le plus facile le chemin sûr.
- Réduisez la surface d’attaque et placez l’authentification, l’autorisation et la validation à chaque frontière de confiance ; tout ce qui se trouve côté client est à l’extérieur de la frontière.
- L’OWASP Top 10:2025 est une liste de sensibilisation, pas une norme ; le SSDF du NIST (SP 800-218) décrit un cycle de développement sécurisé, et les architectes sont responsables des décisions de sécurité qui concernent plusieurs équipes, tandis que les équipes sont responsables de leur bonne application.
La sécurité, une qualité de la structure
Le chapitre 2 a présenté la sécurité comme un attribut de qualité : la capacité du système à protéger les données et les fonctions contre une utilisation non autorisée tout en servant ceux qui sont autorisés, exprimée par des scénarios de sécurité testables qui nomment un attaquant, une attaque, une cible et une réponse mesurable. Ce chapitre va plus loin et se demande comment l’architecture produit cette qualité. La réponse est que la plupart des propriétés de sécurité sont déterminées par la structure : quels composants existent, lesquels font confiance à quels autres, où les données sont stockées et copiées, et par quels rares points chaque requête doit passer.
Voyez comment se produisent les violations réelles. Un attaquant modifie le numéro de commande dans une URL et voit l’adresse d’un autre client, parce que le service a vérifié que l’utilisateur était connecté mais pas que la commande était la sienne. Un bucket de stockage contenant des exports de base de données est lisible depuis Internet parce qu’un paramètre par défaut a été modifié il y a des années. Un service interne de reporting accepte toute requête provenant de l’intérieur du réseau, si bien qu’un seul ordinateur portable compromis atteint chaque fiche client. Aucune de ces failles n’exige de cryptographie ingénieuse pour être exploitée ; chacune est une décision de conception sur la confiance que personne n’a prise explicitement. La sécurité dès la conception consiste à prendre ces décisions délibérément, tôt et par écrit, puis à les rendre difficiles à enfreindre par accident.
L’architecture de sécurité se range donc aux côtés des autres préoccupations transversales de la section 8 d’arc42 : un modèle d’identité, un modèle d’autorisation, un concept de protection des données et un concept de journalisation que chaque équipe applique. La suite de cette section pose le vocabulaire et les principes sur lesquels s’appuient les autres sections du chapitre.
Confidentialité, intégrité et disponibilité dans un système réel
La triade CIA est le point de départ. Sur la plateforme de livraison de repas, la confidentialité couvre les noms, adresses, numéros de téléphone et historiques de commandes des clients, la position en direct et les pièces d’identité des livreurs, les coordonnées bancaires de versement des restaurants et les propres secrets de la plateforme. L’intégrité couvre les prix, les totaux de panier, les remboursements, les versements aux livreurs et la carte que voit un client : un attaquant capable de ramener le prix d’un repas à zéro, ou de détourner les versements d’un restaurant vers son propre compte bancaire, n’a rien lu de secret mais a causé un tort sérieux. La disponibilité compte surtout pendant le pic du soir, quand une attaque par déni de service ou une infection par rançongiciel coûte du chiffre d’affaires à chaque minute.
L’ISO/IEC 25010:2023 ajoute l’authenticité (les identités peuvent être prouvées), l’imputabilité (les actions peuvent être rattachées à leur auteur), la non-répudiation (on peut prouver que les actions ont eu lieu) et la résistance (le produit continue de fonctionner comme prévu sous attaque). Les architectes doivent nommer les propriétés qui comptent pour chaque actif, car elles tirent dans des directions différentes. Échouer en mode fermé protège la confidentialité et l’intégrité mais coûte de la disponibilité : si le service d’autorisation est en panne, un service des commandes qui échoue en mode fermé refuse les commandes. Échouer en mode ouvert préserve la disponibilité et joue tout le reste à pile ou face. Le bon choix diffère selon l’opération : la consultation d’une carte publique peut échouer en mode ouvert vers une copie en cache, alors que l’émission d’un remboursement doit échouer en mode fermé.
Les principes de conception de Saltzer et Schroeder
En 1975, Jerome Saltzer et Michael Schroeder, forts de leur expérience du système d’exploitation Multics au MIT, ont publié huit principes de conception pour les mécanismes de protection dans The Protection of Information in Computer Systems. Un demi-siècle plus tard, ils restent le fondement le plus cité de la conception sécurisée, parce qu’ils portent sur la structure plutôt que sur la technologie. Le tableau reformule chacun d’eux et donne un exemple moderne tiré de la plateforme de livraison de repas.
Les huit principes de conception, avec des exemples modernes
| Principe | Ce qu’il demande | Exemple moderne |
|---|---|---|
| Économie de mécanisme | Garder la conception de sécurité aussi petite et simple que possible, afin de pouvoir l’inspecter et la tester à fond. | Une seule bibliothèque d’autorisation ou un seul moteur de politique, partagé et bien relu, au lieu de contrôles de permission écrits à la main différemment dans chaque service. |
| Valeurs par défaut sûres | Fonder l’accès sur une permission explicite ; en cas de doute, ou quand quelque chose échoue, la réponse est non. | Un nouvel endpoint d’API est refusé tant qu’aucune politique n’y donne accès ; un moteur de politique injoignable signifie refuser, pas autoriser. |
| Médiation complète | Vérifier chaque accès à chaque objet, à chaque fois, et pas seulement la première fois. | Le service des commandes vérifie la propriété à chaque GET /orders/{id} au lieu de faire confiance à n’importe quel identifiant venant d’un utilisateur connecté ; les décisions en cache expirent rapidement. |
| Conception ouverte | La sécurité ne doit pas dépendre du secret de la conception ; seuls les clés et les mots de passe doivent être secrets. | Des algorithmes publiés (AES, TLS 1.3) et des protocoles standard (OAuth 2.0) qui restent sûrs même si les attaquants lisent le code source. |
| Séparation des privilèges | Lorsque c’est possible, exiger deux conditions indépendantes (deux clés) avant d’accorder l’accès. | Les remboursements au-delà d’un seuil exigent un second approbateur ; une mise en production exige à la fois une revue de code et un pipeline au vert ; connexion multifacteur. |
| Moindre privilège | Ne donner à chaque programme et à chaque utilisateur que les privilèges nécessaires à sa tâche, et pour la durée nécessaire. | Le compte de base de données du service de la carte ne peut pas lire le schéma des paiements ; le rôle cloud d’un job de build peut pousser des images mais pas supprimer des clusters. |
| Moindre mécanisme commun | Réduire au minimum les mécanismes partagés entre utilisateurs, car chaque mécanisme partagé est une voie de fuite d’informations. | Des caches, des files ou des pools de connexions séparés par locataire ou par niveau de confiance ; un cache partagé dont les clés sont mal conçues sert les données d’un utilisateur à un autre. |
| Acceptabilité psychologique | La protection doit être facile à utiliser correctement, sinon les gens la contourneront. | Des passkeys au lieu de règles de mots de passe complexes ; une sécurité par défaut dans la plateforme ; des avertissements rares et donc lus. |
Défense en profondeur
La défense en profondeur consiste à superposer plusieurs contrôles indépendants, afin que la défaillance ou le contournement de l’un d’eux n’expose pas l’actif. L’idée vient de la fortification militaire et c’est une pratique courante en ingénierie de la sûreté comme en sécurité. Sa valeur dépend entièrement du mot indépendants : deux couches qui échouent pour la même raison, comme deux services qui font tous deux confiance à un en-tête falsifié, ne sont qu’une seule couche dessinée deux fois.
Le diagramme montre les couches sur le chemin d’une commande de la plateforme de livraison de repas. Si la validation des tokens par la passerelle a un bug, le contrôle au niveau objet du service des commandes empêche toujours un client de lire la commande d’un autre. Si un attaquant vole les instantanés de disque de la base de données, le chiffrement au repos, avec des clés conservées ailleurs, les protège. Si tout cela échoue, la supervision devrait remarquer le schéma inhabituel des requêtes, et quelqu’un devrait réagir. La défense en profondeur est aussi la réponse honnête à la question « et si ce contrôle échoue ? », que pose tout modèle de menaces.
Sécurisé par défaut et sécurisé dès la conception
Un produit est sécurisé par défaut lorsque sa configuration d’origine est la configuration sûre, de sorte qu’affaiblir la protection exige un acte délibéré. Beaucoup de violations de grande ampleur sont venues de valeurs par défaut non sécurisées laissées en place : des bases de données à l’écoute sur Internet sans mot de passe, des consoles d’administration avec les identifiants d’usine, des buckets de stockage qu’un seul paramètre suffisait à rendre publics. Les fournisseurs ont évolué : depuis avril 2023, par exemple, les nouveaux buckets Amazon S3 sont créés avec Block Public Access activé et les listes de contrôle d’accès désactivées. En 2023, la Cybersecurity and Infrastructure Security Agency (CISA) des États-Unis et des agences partenaires de plusieurs pays ont publié des recommandations communes exhortant les fabricants à rendre leurs produits sécurisés dès la conception et par défaut, et en 2024 la CISA a lancé un engagement volontaire, le Secure by Design pledge, destiné aux éditeurs de logiciels.
Pour les architectes, le principe « sécurisé par défaut » s’applique à la plateforme autant qu’aux produits. Si le modèle de service partagé inclut déjà la validation des tokens, une journalisation de sécurité structurée, un utilisateur de conteneur non root et un compte de base de données au moindre privilège, chaque nouveau service démarre sécurisé et les équipes doivent s’en écarter explicitement, ce qui est visible en revue. C’est ce que certaines organisations appellent une paved road (chemin balisé) : le chemin le plus facile est aussi le chemin sécurisé.
Un sujet proche est le comportement d’un système quand quelque chose tourne mal. L’OWASP Top 10:2025 a ajouté une catégorie pour la mauvaise gestion des conditions exceptionnelles, qui inclut l’échec en mode ouvert : une erreur dans un contrôle de permission qui est interceptée et ignorée, un délai d’expiration qui conduit par défaut à « autorisé », un échec d’analyse syntaxique qui saute la validation. Les valeurs par défaut sûres, appliquées dans le code, signifient que chaque chemin d’exception d’une décision de sécurité se termine par un refus.
Surface d’attaque et frontières de confiance
La surface d’attaque est tout ce qu’un attaquant peut atteindre et influencer : les endpoints publics et leurs paramètres, les ports ouverts, les envois de fichiers, les files de messages qui acceptent des entrées de partenaires, les webhooks, les consoles d’administration, les apps mobiles qui peuvent être décompilées, ainsi que le code tiers et les personnes auxquels le système fait confiance. Michael Howard, chez Microsoft, a popularisé l’idée de la mesurer au début des années 2000 ; la règle pratique est de la rendre aussi petite que possible et de savoir exactement ce qu’elle contient. Supprimer un endpoint inutilisé, fermer à Internet un port d’administration ou désactiver une fonctionnalité que personne n’utilise réduit le risque à moindre coût que n’importe quel contrôle ajouté. Chaque choix de style architectural du chapitre 6 a ici un coût de sécurité : chaque nouveau service accessible par le réseau ajoute des endpoints, des identifiants et du trafic à protéger.
Une frontière de confiance est l’endroit où des données ou le contrôle passent entre des parties de niveaux de confiance ou de privilège différents. La plus évidente se situe entre Internet et la plateforme, mais il y en a bien d’autres : entre l’app client et l’API, entre la tablette d’un restaurant et le service de la carte, entre des services détenus par des équipes différentes, entre la plateforme et un prestataire de paiement, entre le code applicatif et la base de données, et entre les utilisateurs ordinaires et les administrateurs. Les frontières de confiance comptent parce que c’est là que les contrôles ont leur place : l’authentification, l’autorisation, la validation des entrées et l’encodage des sorties ont lieu quand les données franchissent une frontière, jamais en supposant que l’autre côté l’a déjà fait. Tracer les frontières de confiance sur un diagramme de flux de données est la première étape de la modélisation des menaces.
L’OWASP Top 10, une liste de sensibilisation
L’OWASP Top 10 est la liste classée, établie par l’Open Worldwide Application Security Project, des risques de sécurité les plus critiques pour les applications web, compilée à partir de données de vulnérabilités fournies par des contributeurs et d’une enquête auprès de la communauté. L’édition actuelle, l’OWASP Top 10:2025, est la huitième. Par rapport à l’édition 2021, le contrôle d’accès défaillant reste premier et inclut désormais la falsification de requêtes côté serveur (SSRF), la mauvaise configuration de sécurité monte à la deuxième place, l’ancienne catégorie des composants vulnérables et obsolètes s’élargit en défaillances de la chaîne d’approvisionnement logicielle, et une nouvelle catégorie couvre la mauvaise gestion des conditions exceptionnelles.
L’OWASP Top 10:2025 et les leviers architecturaux
| Catégorie | Ce qui tourne mal | Levier architectural |
|---|---|---|
| A01 Broken Access Control (contrôle d’accès défaillant) | Des utilisateurs agissent en dehors de leurs permissions, par exemple en lisant la commande d’un autre client en modifiant un identifiant ; inclut la falsification de requêtes côté serveur. | Un seul modèle d’autorisation, refus par défaut, contrôles au niveau objet dans chaque service, accès réseau sortant restreint. |
| A02 Security Misconfiguration (mauvaise configuration de sécurité) | Valeurs par défaut non sécurisées, stockage ouvert, pages d’erreur trop bavardes, fonctionnalités inutiles laissées actives. | Infrastructure en tant que code, modèles durcis, vérifications automatisées des politiques dans le pipeline. |
| A03 Software Supply Chain Failures (défaillances de la chaîne d’approvisionnement logicielle) | Dépendances, outils de build et canaux de distribution vulnérables ou compromis. | Inventaire des dépendances (SBOM), épinglage des versions, provenance signée ; voir la sécurité de la chaîne d’approvisionnement. |
| A04 Cryptographic Failures (défaillances cryptographiques) | Données sensibles non chiffrées, algorithmes faibles, mauvaise gestion des clés. | Classification des données, TLS partout, un KMS et le chiffrement d’enveloppe. |
| A05 Injection | Des données non fiables interprétées comme du code : SQL, commandes du système d’exploitation, cross-site scripting. | Requêtes paramétrées, encodage des sorties adapté au contexte, API sûres des frameworks. |
| A06 Insecure Design (conception non sécurisée) | Des contrôles absents ou inefficaces qu’aucun codage correct, si soigné soit-il, ne peut corriger. | Modélisation des menaces, patrons de conception sécurisée, cas d’abus à côté des récits utilisateur. |
| A07 Authentication Failures (défaillances d’authentification) | Bourrage d’identifiants (credential stuffing), parcours de récupération faibles, défauts de gestion des sessions. | Un fournisseur d’identité central, MFA ou passkeys, limites de débit sur la connexion. |
| A08 Software or Data Integrity Failures (défaillances d’intégrité des logiciels ou des données) | Faire confiance à du code, à des mises à jour ou à des données sans en vérifier l’intégrité, par exemple des mises à jour non signées ou une désérialisation non sûre. | Vérification des signatures, contrôles d’intégrité sur les données qui franchissent des frontières. |
| A09 Security Logging and Alerting Failures (défaillances de journalisation et d’alerte de sécurité) | Les attaques ne sont pas enregistrées, ou enregistrées mais jamais remarquées ni traitées. | Une norme de journalisation de sécurité, des alertes, des runbooks d’incident. |
| A10 Mishandling of Exceptional Conditions (mauvaise gestion des conditions exceptionnelles) | Erreurs traitées de façon incohérente, systèmes qui échouent en mode ouvert, messages d’erreur qui divulguent des détails. | Échec en mode fermé, gestion centralisée des erreurs, limites de ressources. |
Traitez la liste pour ce que l’OWASP dit qu’elle est : un document de sensibilisation, pas une norme. Elle est utile pour la formation, pour vérifier qu’un modèle de menaces n’a pas oublié toute une classe de problèmes et pour dialoguer avec les parties prenantes. Ce n’est pas un ensemble complet d’exigences, et « nous sommes conformes à l’OWASP Top 10 » ne veut pas dire grand-chose. Pour des exigences vérifiables, l’Application Security Verification Standard (ASVS) de l’OWASP énumère des contrôles testables selon trois niveaux de rigueur, et l’OWASP API Security Top 10, distinct, couvre les risques propres aux API, comme l’autorisation défaillante au niveau objet.
Un cycle de développement sécurisé et le shift left
Un cycle de développement sécurisé intègre des activités de sécurité à chaque étape de la livraison au lieu de compter sur un test juste avant la mise en production. Microsoft a rendu obligatoire son Security Development Lifecycle en 2004, après le mémo Trustworthy Computing de Bill Gates en 2002, et l’idée s’est répandue dans tout le secteur. La référence actuelle est le Secure Software Development Framework (SSDF) du NIST, SP 800-218, dont la version 1.1 a été publiée en février 2022 ; le NIST a soumis à consultation un projet de révision (version 1.2) en décembre 2025, qui n’avait pas été finalisé au moment de la rédaction. Le SSDF regroupe les pratiques en quatre familles : préparer l’organisation (rôles, formation, chaînes d’outils, exigences de sécurité), protéger le logiciel (protéger le code et l’intégrité du build, conserver la provenance), produire un logiciel bien sécurisé (concevoir pour satisfaire les exigences de sécurité, modéliser les menaces, relire et tester, configurer de manière sécurisée par défaut) et répondre aux vulnérabilités (identifier, corriger et analyser les causes profondes pour que la même classe ne se reproduise pas). Il décrit des résultats plutôt que de prescrire des outils, ce qui en fait une bonne liste de contrôle pour un architecte qui évalue un processus de livraison.
Faire du shift left, c’est déplacer le travail de sécurité plus tôt : exigences de sécurité et cas d’abus avec les récits utilisateur, modélisation des menaces lors de la conception, analyse statique et détection de secrets à chaque commit, vérification des dépendances dans le pipeline. L’argument économique est connu depuis le chapitre 1 : un contrôle d’autorisation manquant découvert en revue de conception coûte une heure ; la même faille découverte après une violation coûte une notification aux autorités de régulation. Les praticiens ne s’accordent pas sur le degré auquel il faut le pousser. Ses partisans disent que les développeurs qui comprennent la sécurité écrivent moins de vulnérabilités. Ses détracteurs font remarquer que le simple fait de placer des outils de sécurité devant les développeurs les submerge de constats de faible qualité et fait de la sécurité le travail à temps partiel de tout le monde et l’expertise de personne ; ils plaident pour une sécurité par défaut intégrée à la plateforme (la paved road), afin que le chemin sécurisé ne demande aucun effort supplémentaire, et pour des spécialistes de la sécurité intégrés là où le risque est le plus élevé. La plupart des organisations matures font les deux, et continuent aussi de tester et de superviser en production, ce qui explique que certaines parlent désormais de « shift everywhere », la sécurité à chaque étape.
Ce dont les architectes sont responsables, et ce dont les développeurs sont responsables
Le travail de sécurité est partagé, et la confusion sur qui est responsable de quoi est en soi une vulnérabilité. L’architecte est responsable des décisions qui franchissent les frontières entre équipes et sont coûteuses à changer ; les équipes sont responsables de leur bonne application. Un schéma courant associe une petite équipe de sécurité centrale qui fixe les normes et exploite les services de sécurité de la plateforme, des référents sécurité (security champions) dans chaque équipe produit qui animent la modélisation des menaces et les revues, et des architectes qui veillent à ce que les décisions structurelles soient prises et consignées.
Répartir les responsabilités de sécurité
| Préoccupation | Architecte (et architecture de sécurité) | Équipes de développement |
|---|---|---|
| Frontières de confiance et flux de données | Les définir, les documenter, animer la modélisation des menaces pour les changements importants. | Garder le code cohérent avec elles ; signaler les changements qui déplacent une frontière. |
| Identité et accès | Choisir le fournisseur d’identité, le modèle de tokens, le modèle d’autorisation et l’endroit où la politique est décidée. | Appliquer l’autorisation à chaque endpoint et à chaque objet ; la tester. |
| Protection des données | Classer les données ; décider de ce qui est chiffré où, avec quelles clés ; choisir le KMS et le coffre de secrets. | Utiliser les bibliothèques approuvées ; ne jamais journaliser de secrets ni, sans nécessité, de données à caractère personnel. |
| Traitement des entrées et des sorties | Fixer la stratégie de validation et d’encodage aux frontières ; fournir des bibliothèques partagées. | Valider, encoder et paramétrer dans chaque gestionnaire. |
| Dépendances et build | Fixer les contrôles du pipeline, les sources approuvées et la politique SBOM. | Tenir les dépendances à jour ; traiter les alertes dans les délais convenus. |
| Détection et réponse | Définir la journalisation de sécurité, les événements d’audit et les rôles en cas d’incident. | Émettre les événements convenus ; corriger les vulnérabilités dans les niveaux de service convenus. |
Exemple commenté
Exemple commenté : appliquer les principes à une fonction de remboursement par le support
Les agents du support de la plateforme de livraison de repas doivent rembourser les clients pour les livraisons ratées depuis l’outil de back-office. Une première conception permet à n’importe quel agent d’appeler l’endpoint de remboursement du service Paiements avec n’importe quel numéro de commande et n’importe quel montant. Le tableau montre comment les principes la remodèlent.
| Moindre privilège | Les agents reçoivent une permission refund:create uniquement pour les commandes de leur propre marché ; l’identité de service de l’outil de back-office peut appeler l’API de remboursement mais jamais lire les données de carte. |
|---|---|
| Valeurs par défaut sûres | Si le contrôle de politique ou la recherche de la commande échoue ou expire, le remboursement est refusé avec un message « réessayez » ; aucun chemin de repli ne saute les contrôles. |
| Médiation complète | Paiements revérifie lui-même chaque remboursement par rapport au débit initial (le remboursement ne peut pas dépasser le montant capturé moins les remboursements antérieurs), au lieu de faire confiance à l’outil de back-office. |
| Séparation des privilèges | Les remboursements de plus de £100, ou un troisième remboursement au même client dans la semaine, exigent l’approbation d’un superviseur dans le même outil. |
| Économie de mécanisme | Utilise le moteur de politique et la bibliothèque d’audit existants de la plateforme ; aucun code de permission spécifique n’est écrit pour les remboursements. |
| Acceptabilité psychologique | L’approbation se demande en un clic ; les motifs se choisissent dans une courte liste, si bien que le contrôle ne ralentit pas les agents honnêtes. |
| Imputabilité | Chaque remboursement est inscrit dans un journal d’audit en ajout seul, avec l’agent, l’approbateur, la commande, le montant et le motif. |
| Défense en profondeur | L’outil de back-office n’est accessible que par authentification unique (SSO) avec une MFA résistante à l’hameçonnage, depuis des appareils gérés. |
Un agent malhonnête comme un attaquant qui a pris le contrôle du compte d’un agent sont désormais limités à de petits remboursements journalisés dans un seul marché.
Le coût est un court délai pour les gros remboursements et un peu de travail de conception supplémentaire, ce qui est bien moins cher que d’ajouter ces contrôles après coup, une fois la fraude découverte.
Vérifiez votre compréhension
Pourquoi la défense en profondeur dépend-elle de l’indépendance des couches ?
Si deux couches échouent pour la même raison, par exemple parce qu’elles font toutes deux confiance au même en-tête falsifié, une seule attaque les met toutes deux en échec, si bien qu’elles ne protègent pas mieux qu’une seule couche.
Quel principe de Saltzer et Schroeder est enfreint lorsqu’un service vérifie qu’un utilisateur est connecté, mais pas que la commande demandée lui appartient ?
La médiation complète : chaque accès à chaque objet doit faire l’objet d’un contrôle d’autorité, et pas seulement le fait que l’utilisateur s’est authentifié.
Une équipe affirme que son application est « conforme à l’OWASP Top 10 ». Qu’est-ce qui ne va pas dans cette affirmation ?
Le Top 10 est une liste de sensibilisation à des catégories de risques, pas une norme comportant des exigences testables ; la vérification nécessite quelque chose comme l’ASVS de l’OWASP et un modèle de menaces du système réel.
Donnez un exemple d’échec en mode ouvert et expliquez pourquoi il est dangereux.
Un contrôle de permission qui traite un délai d’expiration du moteur de politique comme « autorisé ». Un attaquant capable de ralentir ou de casser le moteur de politique obtient alors l’accès à tout ce qu’il protège.
Sources et lectures complémentaires
Une question sur cette section ? ArchitectBot, l’assistant d’étude IA du cours, répond d’abord à partir du cours.
Demander : « Quelles décisions de sécurité de notre conception de livraison de repas un architecte devrait-il prendre de manière centralisée, et lesquelles chaque équipe devrait-elle prendre elle-même ? »