Comment tendre vers une démarche DevTestOps Secured ?

3/05/2017

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ée 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.