Comment tendre vers une démarche DevTestOps Secured ?

Comment tendre vers une démarche DevTestOps Secured ?

Comment tendre vers une démarche DevTestOps Secured ?

Quelle place pour la sécurité dans une démarche DevTestOps ? Comment tendre vers une pratique DevTestOps Secured ? La question surgit très vite dès les premières mises en pratique. Ou plutôt les questions : faut-il traiter le sujet lors d’une étape spécifique ? Ou bien au sein de chaque phase ? La pratique nous a rapidement aidé à trancher : la préoccupation de la sécurité doit être portée à travers l’ensemble du cycle et non lors d’une étape qui lui serait dédiée. 

Dans la pratique, l’étape sécurité arrive trop tard

L’expérience montre que l’approche DevTestOps se doit d’être secondée par des principes de sécurité appliqués à tous les niveaux. Cette conviction doit souvent être âprement défendue. Et pour cause : sur le papier, traiter la sécurité, de manière ciblée et concentrée sur une étape, peut donner l’impression que le travail sera bien fait. Une vision rassurante en somme. Mais dans la pratique, quel que soit son positionnement dans la démarche, cette étape « sécurité » arrive bien trop tard et occasionne des retours en arrière, sur l’ensemble du cycle, très délicats à gérer. Pire, la couverture des points de sécurité est loin d’être complète lorsqu’elle est traitée de manière isolée du reste des autres phases.

Il faut reconnaitre que la checklist de la sécurité est plutôt dense. Lors des développements, il faut ainsi veiller au respect des règles de codage, au durcissement du code, à la protection contre toutes les attaques connues (XSS, injection SQL, etc…), au contrôle de l’obsolescence des frameworks utilisés, à celui des packagings, ou encore détecter les patterns dans le code offrant des failles potentielles. Nous sommes encore loin d’avoir épuisé cette checklist qui se poursuit, bien entendu, lors des tests.

Vulnérabilités, intrusions, charge, anonymisation des données de test… Autant de sujets qui feront l’objet d’attentions spécifiques avec, à chaque fois, un enjeu clé à couvrir : bloquer les attaques malveillantes, garantir la stabilité et la robustesse du Système, protéger les données sensibles, etc…

Impossible de couvrir toute la checklist lors d’une étape unique

L’effort se poursuit en Exploitation avec le monitoring des applicatifs, la sécurisation des infrastructures, l’application des « security policies », le contrôle des habilitations ou encore la déclinaison du PRA (Plan de Reprise d’Activités), sans oublier que le déploiement s’accompagne, lui aussi, de contrôles, de traçabilité en cas d’audits et doit garantir une capacité de roll back rapide.

Loin d’être exhaustif, ce premier déroulé démontre que le traitement des enjeux de sécurité lors d’une phase dédiée, sera forcément incomplet et incohérent dans le séquencement de la démarche DevTestOps. Oui, l’image d’une phase sécurité, bien identifiée et adossée à un outil « magique » capable de couvrir l’ensemble de la checklist, est séduisante. Mais c’est un mirage, une image très éloignée des enjeux et contraintes de la réalité des projets, encore davantage d’ailleurs dans les contextes d’externalisation des développements.

Un vaste panel de compétences à mobiliser

Par ailleurs, les problématiques de sécurité requièrent un vaste panel de compétences qu’il faut pouvoir appliquer sur des domaines extrêmement variés et pointus, de la technique aux processus en passant par la réglementation. Là encore, mobiliser l’ensemble des compétences lors d’une seule et unique phase est illusoire.

C’est donc tout l’enjeu de l’approche DevTestOps Secured : substituer à ce mirage de la « sécurité-qui-se-joue-en-une-étape », une démarche bien plus pragmatique et efficace. Avec deux piliers : d’une part, une approche collaborative qui contribue à une gestion transverse des enjeux de sécurité. D’autre part, un panel d’outils pour couvrir de manière exhaustive l’ensemble de la checklist, sans perdre de vue que l’outillage devra couvrir également le pilotage de la sécurité (Gouvernance, surveillance du respect des « security policies »).

Cet effort continu et transverse vous paraît très ambitieux, voire trop ? Si cette crainte est légitime, elle représente aussi un obstacle qu’il va falloir dépasser pour garantir le succès d’une démarche DevTestOps Secured. Et ce n’est d’ailleurs pas le seul obstacle qui peut surgir. Quels écueils anticiper pour garantir le succès de votre initiative DevTestOps ? Comment garder le cap ? Nous en reparlons ici même très prochainement.

Antonio Albuquerque

Antonio Albuquerque

Consultant Senior Nexworld

DÉCOUVREZ COMMENT NOTRE CABINET ACCOMPAGNERA LA TRANSFORMATION DE VOTRE ENTREPRISE

Les consultants Nexworld mettent leur expertise aux services des entreprises qui veulent accélérer leur transformation numérique. Nexworld propose des séminaires adaptés aux besoins et au SI existant de votre entreprise.

Kubernetes à la mode Edge

Les nouvelles sources d’événements telles que la voiture connectée dans l’automobile, le bâtiment et les bureaux intelligents ou encore l’industrie pour la surveillance des usines, nécessitent des capacités de calcul et de traitements en complément des infrastructures...

SOA versus Microservices : quelles différences ?

Entre les architectures SOA et microservices, les similitudes sont nombreuses. Alors comment distinguer ces deux types d’architectures ? Comment gérer la transition de l’une à l’autre ? Explications.

DevOps : 8 principes pour s’attaquer au chantier du déploiement continu

DevOps : 8 principes pour s’attaquer au chantier du déploiement continu

DevOps : 8 principes pour s’attaquer au chantier du déploiement continu

Une étude le confirmait encore tout récemment : en France les responsables IT montrent un grand intérêt pour la démarche DevOps. De fait, la formation des équipes comme l’adoption d’un outillage adéquat figurent en bonne place dans la feuille de route des directions des Systèmes d’Information. Mais cette perception s’apparente à celle du verre à moitié plein…

Côté intégration continue, quelques motifs de fierté…

Dans la pratique, l’intégration continue peut susciter quelques fiertés légitimes. En général, la fameuse PIC (Plateforme d’Intégration Continue) est en place et les développeurs prennent l’habitude d’en tirer le meilleur parti pour intégrer leur travail dans un cadre collaboratif. Leurs travaux sont buildés, testés unitairement, packagés puis placés dans un référentiel avec un niveau d’automatisation qui fluidifie grandement toute cette chaîne. En revanche, le déploiement continu est beaucoup moins bien maîtrisé et certaines pratiques de déploiement en sont encore très éloignées.

Côté déploiement continu, la situation s’avère plus… délicate

Première raison, contrairement à l’intégration continue, le déploiement continu ne se limite pas aux développeurs. Et pour cause : avant d’arriver en production, les packages qui sortent de la PIC vont devoir transiter à travers de nombreux environnements au fil des tests fonctionnels, d’intégration, de sécurité, de performances. Ces environnements sont opérés et maîtrisés par des profils et compétences variés. Sans surprise, la collaboration s’avère forcément plus délicate.

Le déploiement continu cherche encore sa plateforme unique, fédérée…

Seconde raison, là où la PIC bénéficie de solutions globales ou fédérées, le déploiement continu cherche encore sa plateforme, celle capable d’automatiser de bout en bout l’ensemble des étapes : provisioning de l’infrastructure, configuration et déploiement des applicatifs.

À défaut, chacun travaille pour l’heure dans son coin, selon ses propres recettes. Avec des effets de bord bien tangibles à l’instar de cette entreprise qui estime à 3 mois le délai minimum pour déployer un nouveau service de Business Intelligence. Explications : plusieurs équipes sont impliquées (équipe BI, équipe serveur d’application, équipe bases de données, équipe SSL) qui obéissent chacune à leurs propres process et planning…

8 principes pour aller au bout de la démarche DevOps

Problème : les métiers, eux, ne peuvent plus vraiment attendre que la DSI veuille bien ouvrir une fenêtre de tir pour mettre à jour un service. La Transformation Numérique impose bien évidemment un tout autre rythme. Comment avancer concrètement ? Comment aller au bout de la démarche DevOps en s’attelant au chantier du déploiement continu ?

Pour y parvenir, en tout cas pour s’engager sur la bonne voie, voici 8 principes que nous nous efforçons d’appliquer lors de nos missions :

  • S’appuyer sur des processus de déploiement fiables et reproductibles
  • Se montrer capable d’industrialiser les processus en les automatisant
  • Tout versionner (vraiment tout)
  • S’attaquer aux tâches les plus pénibles… en premier
  • Améliorer la qualité des livrables
  • Considérer que le travail est achevé seulement quand le déploiement est effectué
  • Veiller à ce que tout le monde se sente responsable, du début à la fin
  • Considérer que l’amélioration doit être continue (lien avec chronique DevTestOps)

Précision sur le principe #4. Ainsi formulé, il peut surprendre mais son application est cruciale. Il s’agit finalement de considérer qu’une tâche est d’autant plus pénible qu’on l’exécute rarement. La traiter en priorité, c’est se contraindre à penser comment la régulariser et l’automatiser. Donc c’est aussi simplifier et limiter les risques d’erreur.

Jusqu’à quel point les conteneurs vont-ils changer la donne ?

Dans tous les cas, appliquer réellement ces principes demande ténacité et rigueur en attendant… que les conteneurs changent la donne. Car, moyennant l’ajout d’une couche d’abstraction, ces deniers promettent de nous épargner les fastidieuses tâches de configurations des packages pour les différents environnements. Une perspective qui rendrait du coup caduque la notion même de déploiement continu. Un mythe ? Nous en reparlerons donc très vite ici même…

DÉCOUVREZ COMMENT NOTRE CABINET ACCOMPAGNERA LA TRANSFORMATION DE VOTRE ENTREPRISE

Les consultants Nexworld mettent leur expertise aux services des entreprises qui veulent accélérer leur transformation numérique. Nexworld propose des séminaires adaptés aux besoins et au SI existant de votre entreprise.

Kubernetes à la mode Edge

Les nouvelles sources d’événements telles que la voiture connectée dans l’automobile, le bâtiment et les bureaux intelligents ou encore l’industrie pour la surveillance des usines, nécessitent des capacités de calcul et de traitements en complément des infrastructures...

SOA versus Microservices : quelles différences ?

Entre les architectures SOA et microservices, les similitudes sont nombreuses. Alors comment distinguer ces deux types d’architectures ? Comment gérer la transition de l’une à l’autre ? Explications.

Pour profiter (vraiment) de l’amélioration continue, passez de DevOps à DevTestOps

Pour profiter (vraiment) de l’amélioration continue, passez de DevOps à DevTestOps

Pour profiter (vraiment) de l’amélioration continue, passez de DevOps à DevTestOps

Mon premier n’est ni vraiment une organisation, ni une suite de process, ni un outillage mais un peu tout cela à la fois. Mon tout vise à dépasser les clivages habituels d’une Direction des Systèmes d’Information tout en conciliant les enjeux Métiers avec ceux des équipes IT. Qui suis-je ?

Tout le monde aura ici reconnu le DevOps. Le sujet a beau générer des centaines de tweets chaque jour (si, si…), il n’en reste pas moins source de confusion. À tel point que l’InnovationLab de Nexworld a opté pour la qualification d’un autre modèle (pas concurrent bien évidemment mais complémentaire), le DevTestOps.

Explications :

Entre des métiers challengés au quotidien par la nouvelle donne de la transformation numérique, des équipes projets pressés de construire de nouvelles applications et des exploitants soucieux de préserver la disponibilité et la stabilité des services, le SI se retrouve inévitablement sous tension. DevOps est arrivé à point nommé pour baisser cette tension de la même manière que l’on soulève la soupape d’une marmite qui commence à siffler.

Il faut avouer que les symptômes de cette tension se multipliaient : retards dans les développements, livraisons approximatives, phases de recette longues et coûteuses, communication difficile (euphémisme) entre les équipes, plannings et budgets difficiles à maîtriser.

Dans ce contexte, les promesses initiales de DevOps ne pouvaient que capter l’attention. Comment ne pas s’intéresser à une démarche qui propose de prendre en compte rapidement les nouveaux besoins, de fluidifier les développements et les livraisons ? Sauf, que dans l’enthousiasme et l’empressement ambiants, des raccourcis malheureux se sont glissés dans l’esprit DevOps.

Nous pouvons en compter au moins 3 :

Malentendu #1 : La plateforme d’intégration continue (PIC) couvre le cycle DevOps

Pas de DevOps sans une « PIC ». Autrement dit, sans une plateforme pour versionner, compiler, packager et tester de manière continue et industrialisée. Problème : cette PIC a rapidement été considérée comme la plateforme globale du cycle DevOps. Un premier raccourci dommageable car le rôle principal de la PIC est de soutenir l’industrialisation des développements et des tests unitaires.

Assez logiquement, les développeurs se sont donc appropriés la PIC pour la réserver à leur usage exclusif.

Autrement dit, elle ne couvre que la première partie seulement du cycle DevOps et s’adresse exclusivement aux développeurs.

Malentendu #2 : L’amélioration continue se joue dans une étape spécifique du cycle

Prise au pied de la lettre, la démarche DevOps conduit à enchaîner des cycles sur un rythme soutenu et à traiter l’ensemble des dysfonctionnements (fonctionnels, techniques, Architecturaux) lors d’une phase dédiée. Dans la pratique, jouer l’amélioration continue lors d’une telle phase spécifique du cycle DevOps se fait au détriment de la qualité. Impossible en effet de parvenir à un code de qualité si les tests et la recette ne sont pas traités de manière distincte. Pour analyser le sujet de manière complète, il faudrait d’ailleurs différencier :

  • Les tests unitaires
  • Les tests d’intégration
  • Les tests fonctionnels
  • Les tests de sécurité
  • Les tests de qualimétrie
  • Les tests de performance
  • Les tests d’exploitabilité

Si les premiers (les tests unitaires) relèvent bien de la responsabilité des développeurs et prennent place dans le cadre de la PIC, les autres sont dans les mains des Métiers, des exploitants et d’autres acteurs de la DSI. Pour être menés de manière qualitative, les tests d’intégration comme la recette utilisateur appellent donc des activités distinctes qui se jouent à différentes étapes du cycle DevOps et non dans une étape unique.

Malentendu #3 : Livraisons et déploiements s’enchainent sur un même rythme

Dans le langage DevOps, livraison continue et déploiement continu sont souvent évoqués de concert comme s’ils étaient synchrones. Là aussi, dans la pratique, ce n’est pas le cas. De la livraison au déploiement, un phasing s’impose et requiert de saines interruptions afin que chacun (développeurs, Métiers et exploitants) puisse exercer ses propres contrôles.

Voilà pourquoi, face à ces malentendus assez courants sur le terrain, plutôt que le DevOps, nous préférons évoquer (et pratiquer) une approche DevTestOps. Et substituer à la vision DevOps traditionnelle une approche qui considère l’amélioration continue comme une préoccupation transverse. Contrairement à la vue cyclique habituelle, finalement contraignante, le DevTestOps propose de contribuer à l’amélioration continue dans chaque étape du cycle. Avec des gains bien tangibles pour la qualité des projets mais aussi pour leur sécurité – nous y reviendrons très prochainement.

Pour en savoir plus, découvrez notre formation DevOps et déploiement continu

Mariano BONI

Mariano BONI

DIrecteur associé de Nexworld

DÉCOUVREZ COMMENT NOTRE CABINET ACCOMPAGNERA LA TRANSFORMATION DE VOTRE ENTREPRISE

Les consultants Nexworld mettent leur expertise aux services des entreprises qui veulent accélérer leur transformation numérique. Nexworld propose des séminaires adaptés aux besoins et au SI existant de votre entreprise.

Kubernetes à la mode Edge

Les nouvelles sources d’événements telles que la voiture connectée dans l’automobile, le bâtiment et les bureaux intelligents ou encore l’industrie pour la surveillance des usines, nécessitent des capacités de calcul et de traitements en complément des infrastructures...

SOA versus Microservices : quelles différences ?

Entre les architectures SOA et microservices, les similitudes sont nombreuses. Alors comment distinguer ces deux types d’architectures ? Comment gérer la transition de l’une à l’autre ? Explications.