Sécurité, confidentialité et conformité dès la conception

Bienvenue dans le chapitre 8 : Sécurité, confidentialité et conformité dès la conception. La plupart des violations graves ne sont pas dues à une attaque exotique contre la cryptographie. Elles viennent de décisions structurelles. Un service interne qui faisait confiance à tout appelant du réseau. Une API d’administration qui omettait un contrôle d’autorisation. Une clé d’accès commitée dans un dépôt. Chacune résultait d’un choix architectural sur l’emplacement de la confiance, sur ce que chaque composant peut faire et sur le chemin que suivent les données.

Ce chapitre s’adresse aux développeurs et aux architectes qui connaissent les architectures distribuées et les architectures de données des chapitres 6 et 7, et qui doivent maintenant les sécuriser. Chaque frontière de service, file, cache, réplique et copie analytique agrandit la surface d’attaque. La distribution multiplie les frontières de confiance, et l’architecture des données décide combien de copies des données à caractère personnel existent et combien de temps elles vivent. Le chapitre traite la sécurité comme un attribut de qualité intégré à la structure, au sens des scénarios de sécurité du chapitre 2, et non comme une liste de produits achetés à la fin. Il suppose aussi connue la section du chapitre 0 sur les réseaux, HTTPS et TLS. Et il mène au chapitre 9, qui garde le système sécurisé rapide et opérationnel sous contrainte.

L’exemple fil rouge est la plateforme de livraison de repas utilisée tout au long du cours : des clients, des restaurants et des livreurs, une API gateway, des services de commandes, de paiements, d’affectation et de notification, un flux d’événements et un entrepôt de données. La section huit point un pose le vocabulaire : la confidentialité, l’intégrité et la disponibilité, les principes de conception de Saltzer et Schroeder datant de 1975, comme le moindre privilège, puis la défense en profondeur, la sécurité par défaut et l’OWASP Top 10. La section huit point deux transforme ces principes en une activité de conception reproductible. Vous dessinez un diagramme de flux de données avec ses frontières de confiance, vous vous demandez ce qui peut mal tourner à l’aide de STRIDE et des arbres d’attaque, vous évaluez les risques et vous décidez des mesures d’atténuation. La section huit point trois traite de qui appelle : les mots de passe, les passkeys, les sessions et les tokens, OAuth avec PKCE, OpenID Connect, et les principaux modèles pour décider de ce que chaque appelant peut faire. La section huit point quatre couvre le chiffrement en transit et au repos, le hachage des mots de passe, la gestion des clés avec le chiffrement d’enveloppe, les secrets, la tokenisation et la décision de ce qu’il faut chiffrer et où.

Voici l’une des idées centrales de la section huit point un, la défense en profondeur, représentée le long du chemin que suit une commande à travers la plateforme. En haut se trouve l’app client, à l’extérieur de la frontière de confiance. Elle ne communique avec la plateforme que par HTTPS, et la plateforme ne fait confiance à rien de ce qui se trouve sur l’appareil. À l’intérieur de la frontière, chaque couche ajoute ses propres contrôles. La périphérie absorbe les afflux de trafic, applique des limites de débit et bloque les schémas d’attaque connus. L’API gateway vérifie chaque token et rejette les requêtes qui ne respectent pas le schéma de l’API. Le service des commandes vérifie que ce client a le droit de voir cette commande précise. La base de données utilise un compte doté du moindre privilège, et elle est chiffrée au repos, avec des sauvegardes chiffrées sous des clés distinctes. La journalisation de sécurité, la détection et les alertes couvrent toutes les couches. Comme chaque couche a ses propres contrôles, le contournement d’un seul contrôle n’expose pas les données.

Les quatre sections suivantes élargissent le regard. La section huit point cinq remplace l’idée d’un réseau interne de confiance par une authentification et une autorisation à chaque requête entre services, à l’aide du TLS mutuel, de certificats et de points distincts où la politique est décidée et appliquée. La section huit point six traite les dépendances, les systèmes de build et les images de conteneurs comme faisant partie de la surface d’attaque, avec les nomenclatures logicielles, la signature et le règlement européen sur la cyberrésilience. La section huit point sept explique comment le RGPD et le RGPD britannique façonnent l’architecture : minimisation des données, pseudonymisation, droits des personnes concernées, conservation et effacement dans les sauvegardes et les journaux d’événements. Et la section huit point huit boucle la boucle avec la journalisation de sécurité, la détection, la gestion des vulnérabilités, la réponse aux incidents et la notification des violations.

Ce diagramme de la section huit point cinq montre ce que change le zero trust. Avant, sur un réseau interne plat, n’importe quel hôte peut atteindre n’importe quel port, et tous les services partagent une seule base de données. Lorsque le service de la carte est compromis, l’attaquant peut aller directement aux paiements. Après, chaque service a sa propre base de données, et seules des identités nommées peuvent effectuer les appels autorisés. Commandes appelle Paiements en TLS mutuel, avec une politique. Lorsque le service de la carte compromis tente d’appeler Paiements, l’appel est refusé. Remarquez ce que le zero trust ne fait pas. Il n’empêche pas un service d’être compromis. Il limite ce que le service compromis peut atteindre.

Un architecte n’a pas besoin d’être testeur d’intrusion ni cryptographe, et ne doit pas inventer de cryptographie. L’architecte prend les décisions coûteuses à changer : où se situent les frontières de confiance, et quel fournisseur d’identité et quel modèle de tokens utilise toute la plateforme. Mais aussi quelles données sont classées comme restreintes, chiffrées avec quelles clés, et comment les services se prouvent mutuellement leur identité. Ces décisions ont leur place dans les enregistrements de décision d’architecture, comme toute autre décision importante. Les développeurs sont responsables d’un ensemble tout aussi important : valider les entrées, encoder les sorties, utiliser correctement les bibliothèques de sécurité de la plateforme, gérer les erreurs sans échouer en mode ouvert et tenir les dépendances à jour. Les deux se rejoignent dans la modélisation des menaces, dans les revues de conception sécurisée et dans les vérifications automatisées du pipeline de livraison.

La sécurité et la protection de la vie privée regorgent de normes numérotées et de dispositions juridiques. Le chapitre les nomme avec précision, donne l’édition en vigueur au moment de la rédaction, octobre 2026, et renvoie à la source qui fait autorité. Les passages sur la réglementation expliquent comment le droit influe sur l’architecture. Il s’agit d’informations, non de conseils juridiques. Pour une situation précise, ce sont les juristes de l’organisation et son délégué à la protection des données qu’il faut consulter.

Si vous ne deviez retenir qu’une chose de ce chapitre, ce serait celle-ci. Décidez à qui et à quoi votre système fait confiance, pour quoi et pourquoi. Décidez-le délibérément, tôt et par écrit, plutôt que de le laisser implicite. Et rendez chacune de ces décisions de confiance vérifiable. Les modèles de menaces, le moindre privilège, les scopes OAuth, le chiffrement d’enveloppe, le TLS mutuel, les builds signés et les journaux d’audit sont tous des moyens de remplacer une confiance implicite par une confiance explicite et vérifiable. Un système conçu ainsi limite les dégâts de la violation qui finira par se produire, et peut montrer à ses clients, à ses auditeurs et aux autorités de régulation comment il les protège.

Le mieux est de lire les sections dans l’ordre. Mais chacune se suffit aussi à elle-même, si bien que vous pouvez aller directement à la section dont vous avez besoin. Comptez environ trois heures et demie pour lire tout le chapitre. À la fin de chaque section, vous trouverez des questions d’autoévaluation. Répondez-y de tête avant de regarder les réponses. Quand vous serez prêt, un test du chapitre facultatif vous attend ; il prend environ quarante-cinq minutes. Il comporte vingt questions à choix multiples et deux réponses rédigées. La note de réussite est de quatre-vingts pour cent.

Voilà comment le chapitre est construit. Commencez par la section huit point un, sur les principes de sécurité pour les architectes, où est posé le vocabulaire de tout ce qui suit. À très vite.