Connue sous le nom de shift-left, le « virage à gauche de la sécurité » est une approche consistant à prendre en compte les questions de sécurité au plus tôt dans le processus de développement. Arnaud Lemaire, directeur technique de F5 France, explique ses atouts aux lecteurs de Solutions Numériques.
Cet approche consiste à mettre en œuvre des stratégies et des contrôles de sécurité dès les premières étapes du processus de développement des logiciels, sans attendre la mise en production des applications.
Le shift-left exige ainsi que les développeurs d’applications et les équipes DevOps d’une entreprise considèrent la sécurité comme une partie intégrante de leurs applications et de leurs processus (et en particulier qu’ils la testent à toutes les phases du pipeline CI/CD). À la clé : le renforcement significatif de la sécurité des applications lorsque celles-ci arrivent en production.
Si l’on s’attarde sur la signification générale du shift-left, le choix des outils et approches les mieux adaptés à cette tâche est souvent très controversé. La plupart des débats publics portent sur les outils d’analyse de code et de correction automatique ou sur les nouveaux outils de sécurité spécifiquement conçus pour les applications et infrastructures modernes. Les outils tels que le pare-feu d’application Web (WAF), depuis longtemps employés pour appliquer des stratégies de sécurité en temps réel dans les environnements de test et de production, sont bien souvent laissés de côté. Quelle est la raison de cette exclusion ? Les outils de sécurité traditionnels n’ont-ils vraiment pas leur place dans l’entreprise d’aujourd’hui ? L’impératif de protection des applications d’entreprises contre des attaques ciblées, plus fort que jamais, est en constante évolution et exige une approche multi‑couches.
La tendance au shift-left a-t-elle creusé le fossé entre sécurité et DevOps ?
Avant d’entrer dans les détails, une question plus fondamentale encore est à se poser : si opérer un virage à gauche de la sécurité est la bonne marche à suivre, pourquoi les entreprises n’ont-elles pas toujours procédé ainsi ? La réponse tient en la manière dont celles-ci gèrent habituellement leurs applications et infrastructures traditionnelles : de façon centralisée, aux mains d’une équipe NetOps, IT ou Infrastructure & Operations. Selon ce modèle, il est parfaitement logique de consolider l’application de la sécurité à la périphérie de l’infrastructure (elle-même gérée de manière centralisée) sur laquelle sont déployées les applications.
Lorsque les entreprises modernes s’engagent dans la transformation numérique pour gagner en efficacité et en agilité, une tendance à la décentralisation est généralement observée. Le développement des applications est décentralisé entre plusieurs équipes, l’infrastructure sous-jacente des applications est décentralisée, les opérations sont décentralisées (et opèrent un virage à gauche), et les applications elles-mêmes sont décentralisées en un ensemble de services, de points d’extrémité et de dispositifs qui interagissent via des API sur le réseau. Tous ces composants sont souvent gérés par les équipes Dev et DevOps, en dehors du champ d’action des équipes d’infrastructure traditionnelles et centralisées.
Cette décentralisation a conduit certains acteurs à préconiser une sécurité davantage tournée vers les applications et intégrée plus en amont au processus de développement, en l’absence de contrôleur d’accès centralisé à la périphérie sur lequel s’appuyer. Malheureusement, cette décentralisation a entraîné des frictions importantes entre les équipes Dev et DevOps d’une part, et les équipes de sécurité d’autre part.
Quelles sont les raisons de ce conflit ? Cette situation s’explique en grande partie par le fait que la transformation n’a pas eu lieu au même rythme dans toutes les équipes. Le champ d’application de la sécurité est passé d’un périmètre bien compris et défini, mettant en œuvre un seul centre de données, à une surface d’attaque extrêmement vaste et difficile à délimiter, constituée de charges d’applications modernes fonctionnant sur plusieurs sites, communiquant entre elles sur des réseaux (souvent publics) et extrayant des données d’appareils et d’utilisateurs du monde entier.
Le virage à gauche de la sécurité élargit aussi considérablement le cercle des interlocuteurs avec lesquels l’équipe de sécurité doit interagir (dont beaucoup possèdent une expertise limitée en matière de sécurité), alors que l’équipe de sécurité elle-même n’a pas nécessairement obtenu le budget nécessaire pour se développer. Le défi à relever est d’autant plus grand que de nombreux outils traditionnels bien connus des équipes de sécurité n’ont pas totalement adopté le concept de shift-left. Les équipes n’ont alors d’autre choix que d’essayer de les insérer dans le pipeline, même si ces outils ne sont pas conçus pour l’automatisation et les infrastructures modernes. Les outils ne fournissent généralement pas non plus de self‑service, de sorte que les équipes Dev et DevOps (dont la mission consiste à avancer rapidement, mais qui sont contraintes d’attendre que la sécurité mette en œuvre les changements de stratégie) considèrent la sécurité comme un ralentisseur et essaient souvent de trouver un moyen de la contourner, en recourant à la redoutable « informatique cachée » ou shadow IT.
Contribuer à combler le fossé entre DevOps et sécurité avec les outils de sécurité adéquats
Pour revenir à la question initiale, les outils de sécurité tels que les WAF ont-ils un rôle à jouer dans ce virage à gauche ? La réponse est un « oui » sans équivoque. Comme mentionné plus haut, les entreprises ont besoin d’un moyen de protéger leurs applications et leurs API contre les attaques ciblées. Il est essentiel pour leur bon fonctionnement de s’assurer que leurs applications répondent à leurs exigences en matière de gestion des risques et de conformité.
Or, pour être efficace, le WAF lui-même doit évoluer et opérer un virage à gauche. Un WAF léger, facile à déployer dans plusieurs environnements, optimisé pour les infrastructures et les pipelines modernes, permet aux entreprises de tester l’efficacité de leurs stratégies de sécurité pendant les phases de construction et de test fonctionnel des composants applicatifs et des API, et ce avant que les applications ne soient exécutées dans un environnement réel. La clé ? Il s’agit de s’appuyer sur un WAF qui automatise la configuration et les stratégies de sécurité, afin que les entreprises puissent le provisionner dans leur pipeline. Puisque le personnel de sécurité n’est jamais en surnombre, l’automatisation sera toujours une bonne alliée dans un environnement décentralisé.
Réussir une stratégie shift-left en s’appuyant sur les bons outils et garde-fous
Rechercher le WAF qui convient et opérer un virage à gauche n’est cependant qu’un aspect du tableau. Lorsqu’une entreprise se modernise, des points de friction apparaissent entre les équipes, d’une part parce que les contrôles et les processus de sécurité sont obsolètes, mais aussi en raison de la façon dont les mécanismes de sécurité qui répondent aux besoins de l’entreprise sont fournis aux équipes Dev et DevOps. Un exemple parlant est l’intégration de véritables garde-fous à la sécurité et non de simples portes, dans les processus de développement et les pipelines.
Trop souvent, la sécurité est dictée par les interruptions. Les équipes chargées de la sécurité insistent en effet pour que le développement soit interrompu le temps qu’elles vérifient et évaluent les stratégies et processus de sécurité. Les équipes Dev et DevOps afficheront un plus grand degré de satisfaction si les directives données par l’équipe de sécurité leur permettent de poursuivre le développement, tout en garantissant des conditions de sécurité adéquates. En d’autres termes, la sécurité elle-même devient aussi « continue » que les autres éléments du pipeline CI/CD.
Une façon d’y parvenir est de sélectionner des outils de sécurité pouvant être insérés dans le pipeline en tant que code. Mais cela exige également un changement de perspective pour les équipes de sécurité, qui doivent concevoir des procédures de sécurité destinées à des applications de plus en plus décentralisées et distribuées. Les procédures de sécurité elles-mêmes doivent évoluer, devenir davantage orientées applications et suivre une stratégie shift-left en réponse à toutes sortes de facteurs : public cible de l’application, conception de l’application, environnements de déploiement de l’application et exigences de conformité standard.
Un plan de pilotage permettant d’orchestrer la sécurité dans un large éventail d’applications peut réellement apporter une valeur ajoutée dans un tel environnement. Ce plan permet en effet à l’équipe de sécurité de définir aisément des directives de sécurité appropriées qui seront ensuite adaptées aux applications sous-jacentes en fonction des paramètres définis par l’équipe. La mise en place de garde-fous donne aux équipes de sécurité, Dev et DevOps l’opportunité de collaborer avec un minimum d’interactions ou d’interruptions. Il s’agit d’un domaine en pleine évolution, car les plans de pilotage deviennent davantage orientés applications, et de nombreuses approches différentes voient le jour.
Pas de solution universelle
Une affirmation qui ne peut être démentie concernant la sécurité des applications est celle expliquant qu’il n’existe pas d’approche universelle. De plus, la meilleure stratégie pour une entreprise est celle qui intègre plusieurs couches de sécurité. L’essentiel est de s’assurer que chaque solution de sécurité mise en œuvre s’intègre efficacement dans le pipeline, et que les équipes de développement et de sécurité soient sur la même longueur d’onde, s’appuyant sur des directives efficaces de sécurisation des applications et des API de l’entreprise.
