Architecture en tant qu’élément de culture IT
vhanniet - 2022/02/03
J’étais à devops REX 2019 l’automne dernier. Et comme je n’aime pas spécialement la « sécurité » j’ai suivi la track DevSecOps car j’étais là pour apprendre ;)
— [Début]
Pourquoi mettre en avant la sécurité dans le DevOps ? Pourquoi parler de DevSecOps ? DevOps c’est bien sûr automatiser tout ce qu’on peut sans trop d’effort pour concentrer le temps humain sur ce qui a plus de valeur ajoutée : i.e. tout ce qui ne peut pas être facilement outillé ou automatisé. Mais au delà, DevOps c’est aussi (surtout ?) mettre autour de la table toutes les parties prenantes du produit qu’on est en train de développer. Le mot clé était d’ailleurs cette année « Bienveillance ». Et pour ce qui nous concerne : bienveillance envers la sécurité. D’où le mignon « DevSecOps » qui met la sécurité au coeur du DevOps. En effet : pourquoi pas ?
J’ai donc écouté des REX sur la prise en compte de la sécurité dans une démarche DevOps. J’en retiens surtout deux.
Bienveillance : ça commence là…
Le premier était celui d’un Responsable Sécurité SI d’une assurance mutuelle de taille moyenne. Il expliquait qu’il disposait de relativement peu de moyens et que pour atteindre son objectif, à savoir la prise en compte des principes qu’il défendait, la meilleure approche était de faire ami-ami avec les développeurs le plus en amont possible. C’est pas faux d’ailleurs : la bienveillance est toujours une approche à considérer. A défaut, comme c’est souvent le cas, quand un sujet comme la sécurité arrive sur la table des équipes de delivery 2 semaines avant la mise en production d’une nouvelle release à l’occasion des ultimes tests d’homologation : c’est trop tard ! Au mieux on patch un ou deux trucs et on envoie : trop d’enjeux business pour s’arrêter. Le pire est qu’on n’aura même pas le temps de fixer le problème dans la prochaine release : les délais sont tendus, time to market oblige, la prochaine release est d’ailleurs déjà presque prête travail parallèle oblige. En amont donc : c’est important. Mais ça ne suffit pas. L’intervenant expliquait sur scène combien il aimait les développeurs et voulait être aimé d’eux, ou du moins être entendu par eux. Et en voulant illustrer combien il les aimait il s’est lancé dans une chaleureuse louange du travail du développeur qui démontrait… qu’il n’avait qu’une idée assez vague de ce que font vraiment les développeurs ! Un grand moment de solitude ? Même pas, car il ne s’est pas rendu compte du gap. On peut d’ailleurs raisonnablement en déduire que le gap est vrai aussi dans l’autre sens : qu’est-ce qu’un développeur connaît vraiment aux problèmes de sécurité d’un produit ou d’un SI ? Aux vrais problèmes ? Pas tant que ça je pense… Donc travailler ensemble, échanger souvent, être bienveillants, est certainement une étape important dans la prise en compte réelle, profonde, des principes de sécurité au cœur du DevOps. Et c’est un travail de longue haleine…
Ne pas exiger sans expliquer et aider
Dans le deuxième témoignage que j’ai retenu, une responsable de la sécurité chez un opérateur des transports publics mettait l’accent sur un aspect différent. Idéalement, si on veut que la sécurité soit convenablement traitée il faudrait que les développeur et les exploitants portent en eux les principes essentiels de la sécurité (infosec) souhaitée dans le produit. Cela garantirait que les questions de sécurité sont toujours traitées, et toujours à temps puisqu’elle feraient partie de la culture des équipes DevOps. Idéalement même il n’y aurait même plus besoin d’experts sécurité… vraiment ? En fait non : comme tout topic dans l’IT les techniques d’intrusion et les parades évoluent à chaque changement de paradigme ou de techniques IT. Le truc c’est qu’il faut pouvoir assurer la veille, repérer ou inventer des parades, les diffuser, tout comme on doit diffuser les principes acquis depuis longtemps. Et mettre cette matière à disposition des équipes DevOps pour que jamais, jamais, on ne se retrouve dans la situation de dire : « Mon exigence de sécurité n’est pas respectée. Je ne donne pas mon accord. Débrouillez-vous pour trouver une solution qui soit conforme à ma volonté ». Car ça ça ne marche plus vraiment. Plus du tout en fait.
Il y avait une sorte de consensus dans d’autres témoignages sur cette approche : rendre la sécurité soluble dans les équipes DevOps, partie prenante de la culture de ces équipes, et ne conserver qu’une cellule de veille et de support aux équipes pour les aider à mettre en œuvre des solutions.
— [Fin]
Ah, mince, j’ai intitulé mon billet « Architecture en tant qu’élément de culture IT » et je n’ai parlé que de sécurité. Mais au fait cher lecteur veux-tu participer à un tour de magie ? Allez, chiche ? C’est très simple : relis le texte entre [Début] et [Fin] et remplace toutes les occurrences de « sécurité » par « architecture »…
C’est fou hein ? Ça colle parfaitement aussi, même s’il faut admettre que les développeurs sont généralement plus forts en architecture qu’en sécurité. Et pourtant on ne parle pas de DevArchOps. En fait on ne parlera pas non plus longtemps de DevSecOps. Le truc c’est que si on veut progresser dans l’agilité produit et la sécurité informatique il n’y a pas le choix : il faut que sécurité et architecture fassent partie de la culture des toutes les parties prenantes. Et dans les deux cas la préoccupation doit commencer dans les cas d’usage métier et aller jusqu’à l’infrastructure d’exploitation. C’est une co-construction. Et ce n’est pas que technique, loin de là…
Edit (merci Oumar) :
Quand on dispose d’une automatisation DevOps type CI/CD il faut intégrer dans les workflows le maximum d’éléments liés à la sécurité ou à l’architecture : checks de conformité, tests d’intrusion, contrôles d’anti-patterns, etc. Ça permet de renforcer la culture car s’il y a bien une chose qu’un développeur déteste par dessus tout c’est qu’un contrôle qualité lui dise que son code est un peu pourri ! Ça vaut aussi d’ailleurs pour l’infra-as-code des adeptes du cloud :)