Qu'est-ce que la sécurité DevOps ?

• Glossaire IAM
• Qu'est-ce que la sécurité DevOps ?

La sécurité DevOps, également connue sous le nom de DevSecOps, est un conglomérat des mots développement, opérations et sécurité. La sécurité DevOps et DevSecOps font toutes deux référence à une philosophie consistant à intégrer la sécurité dans le cycle de vie du développement logiciel (SDLC) le plus tôt possible, de préférence avant l'écriture d'une seule ligne de code.

Quelle est la différence entre DevOps et DevSecOps ?

DevSecOps est une extension ou une amélioration de la philosophie DevOps. Pour cette raison, il est important de comprendre ce que DevOps et DevSecOps ont en commun avant de parler de leurs différences.

DevOps et DevSecOps font tous deux référence à une philosophie ou à une approche du développement logiciel, et non à un outil ou un ensemble d'outils. De la même manière que l'installation d'un système de suivi des problèmes ne signifie pas que vous « faites du DevOps », l'installation d'outils de sécurité des applications statiques ou dynamiques ne signifie pas que vous « faites du DevSecOps ».

DevOps et DevSecOps mettent tous deux l'accent sur la collaboration, l'automatisation et la surveillance active des applications logicielles. La capacité à capturer des données d'application en temps réel est essentielle pour ces deux philosophies, car « faire » du DevOps et du DevSecOps exige de capturer et d'analyser continuellement ces données pour découvrir des moyens d'accroître la productivité et d'apporter des améliorations.

Ces deux philosophies reposent également sur la collaboration, notamment l'élimination des silos organisationnels. DevOps cherche à éliminer les silos entre le développement de logiciels et les opérations informatiques, l'idée étant que lorsque les développeurs et le personnel informatique travaillent ensemble, les logiciels sont publiés plus rapidement et avec moins d'erreurs. DevSecOps va un peu plus loin et cherche à valoriser les opérations de sécurité. Le concept DevSecOps repose sur l'idée que lorsque les développeurs, le personnel informatique et le personnel de sécurité travaillent ensemble, les logiciels sont publiés plus rapidement, sont de meilleure qualité et sont plus sûrs.

Bien « faire » du DevSecOps implique que les applications soient correctement protégées contre les risques avant d'être mises en production. Cette pratique est souvent appelée « shift left », car elle consiste à intégrer la sécurité au début de la chronologie du projet, avant même qu'une seule ligne de code ne soit écrite, au lieu de l'aborder dans des phases ultérieures. Dans un environnement DevSecOps, les développeurs codent en gardant la sécurité à l'esprit, ce que DevOps, à lui seul, ne fait pas.

En intégrant des pratiques telles que l'analyse du code, la détection des menaces et l'évaluation des vulnérabilités dans le SDLC, avec des tests et des évaluations en continu, DevSecOps garantit que la base de code est sécurisée dès le départ. En plus d'améliorer la sécurité des applications, DevSecOps améliore la productivité. La détection et la résolution des problèmes de sécurité à un stade précoce sont beaucoup moins longues et coûteuses que la refonte du code à un stade ultérieur du cycle de vie du logiciel.

Les problématiques de la sécurité DevOps

Malgré tous les avantages de DevSecOps, les entreprises peuvent avoir du mal à l'appliquer correctement. Passons en revue certaines des problématiques les plus courantes en matière de sécurité DevOps.

• Trop d'importance accordée aux outils, trop peu d'importance accordée aux processus. Comme mentionné plus haut dans l'article, DevOps et DevSecOps sont tous deux des philosophies, et non des obligations d'utiliser un logiciel particulier.

• Résistance culturelle de la part des développeurs, ou des phrases du type « mais nous avons toujours fait comme ça ». Les développeurs ne sont peut-être pas habitués aux pratiques de codage sécurisé. Traditionnellement, les développeurs codaient en se concentrant sur la fonctionnalité, et les failles de sécurité étaient découvertes et corrigées plus tard. Les développeurs peuvent craindre que le fait de devoir se « préoccuper » de la sécurité ne ralentisse la production.

• Résistance culturelle de la part des équipes de sécurité. Les développeurs ne sont pas les seuls à s'accrocher à « la façon dont on a toujours fait. » Les équipes DevOps se concentrent sur la rapidité, modifient et poussent le code en quelques heures ou quelques jours et ce, à un rythme soutenu qui peut laisser les équipes de sécurité perplexes. La différence est que les équipes DevOps automatisent autant de processus que possible, tandis que les équipes de sécurité font souvent une grande partie de leur travail manuellement.

• Gestion inadéquate des secrets. Les environnements DevOps sont très complexes et profondément interconnectés. Il n'est pas rare que les ateliers DevOps comptent des centaines de groupes de sécurité et des milliers d'instances de serveurs, qui utilisent tous des secrets tels que des informations d'identification de comptes privilégiés, des clés SSH, des jetons API, des mots de passe de bases de données et bien d'autres encore, tous dispersés dans l'environnement de données de l'entreprise, dans une situation connue sous le nom de « prolifération de secrets ». Une simple erreur de configuration peut conduire à la divulgation de l'un de ces secrets et à une cyberattaque catastrophique pour l'entreprise.

• Gestion inadéquate des accès privilégiés. Pour accélérer la production, de nombreuses équipes DevOps donnent à leurs membres un accès pratiquement illimité à des comptes privilégiés tels que root et admin. Pire encore, plusieurs personnes peuvent partager le même ensemble d'informations d'identification, ce qui constitue un gros problème de sécurité et un problème majeur lors des audits de conformité, au cours desquels les entreprises sont censées présenter une piste d'audit irréprochable. De plus, l'orchestration, la gestion de la configuration et d'autres outils DevOps peuvent aussi avoir des niveaux d'accès très élevés, bien supérieurs à ce dont l'outil a besoin pour fonctionner.

Bonnes pratiques de sécurité DevOps

Voici quelques bonnes pratiques pour appliquer la sécurité DevOps dans votre entreprise.

• N'oubliez pas que DevSecOps, comme DevOps, correspond à un état d'esprit, et non à un ensemble d'outils. Au lieu d'acheter des outils DevSecOps et de déterminer où vous voulez les utiliser, concentrez-vous sur vos objectifs finaux, développez des processus pour les atteindre, puis achetez des outils qui appuient ces processus et ces objectifs.
• Utilisez des méthodes de conduite du changement appropriées pour dépasser la résistance culturelle de vos développeurs et de votre personnel de sécurité. Démontrez aux deux équipes que DevSecOps leur fera gagner du temps et les rendra plus productives, et non pas moins. Établissez des normes de codage claires pour vos développeurs et automatisez autant que possible les processus et outils de sécurité.
• Combattez la prolifération des secrets avec un outil tel que Keeper Secrets Manager.
• Renoncez à des droits et à des niveaux d'accès excessifs grâce à des dispositifs tels que le contrôle d'accès basé sur les rôles (RBAC), l'accès au moindre privilège et l'approvisionnement juste à temps.
• Évitez les accès abusifs aux privilèges grâce à l'enregistrement et à l'audit des sessions.