Note : 6 ; Où il apparait que l’on parle plus de DDD que de sécurité, mais que les deux parviennent à être indissociables…

J’avais initialement classé cet ouvrage dans ma (très pauvre) section « sécurité ». Il m’est très vite apparu que ce n’était pas sa place. C’est bien de conception dont va nous parler cet ouvrage, et même de DDD en grande partie. C’est donc un cocktail assez inhabituel et intéressant, au sens positif.

L’objet n’est pas léger, avec ses 360 pages. Nous verrons que ce n’est pas son meilleur aspect, hélas. Le tout compte 14 chapitres divisés en 3 parties. La première s’intitule sobrement introduction et contient les deux premiers chapitres, soit 45 pages. « Why design matters for security ? » est le chapitre qui ouvre le bal. L’approche évoquée par ce livre est la sécurité de l’intérieur, au niveau du code lui-même, un propos que les auteurs illustrent fort bien avec quelques histoires, que ce soit avec une histoire de braquage de banque avec le « billion Lauga » torché en 2 coups de cuiller à XML. Un chapitre très plaisant. Le second chapitre est un interlude pour nous illustrer les conséquences d’une modélisation un peu légère, ou comment obtenir un livre gratuit en commandant dans le même panier un « Hamlet » et… un « anti-Hamlet ». Une histoire hélas inspirée d’un fait réel.

La seconde partie « fondamentaux » couvre la majeure partie de l’ouvrage, avec 9 chapitres sur près de 250 pages. J’ai dit que le DDD était une pierre angulaire de l’approche, le chapitre 3 qui ouvre cette partie est une introduction au sujet. C’est bien écrit, mais un peu verbeux, car il faut compter 37 pages. Ne ratez pas l’explication du « tomber pour tourner » sur les virages pris à vélo ! Au sein du DDD, ce sont surtout les value objects qui retienne l’attention des auteurs. En l’occurrence deux aspects qui leur sont rattachés : construire des value objects immutables (bonjour Scala) et le « fail fast », c’est-à-dire des objets rejetés à la construction s’ils ne satisfont pas les conditions d’entrée (bonjour Bertrand Meyer). Ce chapitre est l’un des points forts du livre. Le chapitre 5 va un cran plus loin, avec les « domain primitives » qui sont un sur-ensemble des value objects. On voit ici comment construire ces primitives de manière sécure, en s’appuyant entre autres sur les invariants. Moins fort que le chapitre précédent, le texte reste quand même intéressant.

Au chapitre 6, ce sont les entités qui sont évoquées et plus particulièrement la gestion de leurs états. Mais les auteurs ont aussi une dent contre les ORMs qui nécessitent des getters, des setters et des constructeurs par défaut. Je les comprends. Le propos nous éclaire aussi justement sur des subtilités telles que le partage d’états mutables. Le chapitre 7 va plus loin avec les états « partiellement immutables » et quelques patterns tels que les snapshots et les entités relais. Cale sent l’event sourcing… Un chapitre particulièrement solide sur les aspects conception.

Le chapitre 8 évoque la sécurisation du pipeline, mais en fait c’est surtout de tests dont il est questions, avec toutefois l’angle du « secure by design », par exemple en focalisant sur les tests aux limites du système. Il figure aussi un propos plus original sur la gestion de la configuration des features toggles. C’est surtout ce dernier point qui a retenu mon attention. Bien que court, le chapitre 9 donne pas mal d’idées à cogiter sur la gestion des défaillances, avec entre autres une stratégie intéressante sur les exceptions pour ne pas les laisser fuiter. On y évoque aussi quelques patterns liés aux microservices mais je me demande ce qu’ils font là.

Direction le cloud avec le chapitre 10. Ici les auteurs nous donnent, en plus de nous rappeler les désormais célèbres « 12 factors », des guides pour les configurations d’infrastructures cloud. C’est extrêmement clair et intéressant, dommage que cela soit d’un peu haut niveau et manque d’exemples. Nouvel interlude pour boucler cette seconde partie. Les auteurs nous livrent un bel exemple avec « une police d’assurance gratuite » où le bon usage du DDD aurait évité une conception qui fuit !

La 3ème partie « appliquer les fondamentaux » s’étend sur 3 chapitres, soit une soixantaine de pages. Au chapitre 12 il est question de code legacy, c’est bien ! Le propos se concentre surtout sur deux axes : les primitives du domaine, pour éviter d’avoir des abstractions qui fuient, et les contrats des APIs. Nous avons droit aussi à une petite variation intéressante sur le principe du DRY qui complète bien le propos des pragmatic programmers.

Rien de révolutionnaire sur le guide pour les microservices, thème du chapitre 14. Les patterns du chapitre 9 auraient trouvé leur place ici. Au moins le texte fait-il un bon boulot pour focaliser notre attention là où il faut. Le livre se conclut sur un chapitre 14 qui revient sur des éléments plus classiques de la sécurité : tests de pénétration, audit, etc. Il ne s’agit pas de faire le tour de la question, mais de rappeler que cela existe aussi et que le « secure by design » ne remplace pas cela.

Le livre est assurément une bonne surprise. Il réussit même à me réconcilier avec le sujet de la sécurité qui est un peu aride pour moi. Le contrat est rempli à 100% pour nous faire appréhender la convergence du design et de la sécurité. Le seul point faible du texte est d’être un peu verbeux. Je pense qu’il aurait pu sans problème être 20% plus court. Mais que cela ne gâche pas votre plaisir.

Référence complète : Secure by Design – Dan Bergh Johnsson, Daniel Deogun & Daniel Sawano – Manning 2019 – ISBN : 978 1 61729 435 8