Le mouvement DevOps et les méthodologies de déploiement et d’intégration continus sont adoptés dans des entreprises du monde entier, et celles qui y ont recours sont nettement plus efficaces et productives. Si vous n’en êtes pas convaincus, jetez un coup d’œil à l’article de Developpez.com à propos de l’étude de Puppet Labs de cette année, qui révèle que les entreprises ayant adopté les pratiques DevOps déploient du code 30 fois plus vite et avec moitié moins d’échecs que les autres entreprises.

Ces résultats de DevOps, parce qu’ils sont axés sur une amélioration constante via une collaboration continue et des itérations rapides, correspondent exactement à ce que les entreprises cherchent à  atteindre. Et cela leur permet d’être plus agiles et compétitives.

Y parvenir n’est jamais simple ; pour cela, de nombreux obstacles structurels, technologiques et liés à la sécurité doivent être surmontés.

Il est important de souligner que lorsque nous parlons de DevOps, la sécurité est une préoccupation légitime.Alors que les développeurs et les équipes opérationnelles commencent à travailler plus étroitement et rapidement ensemble, une grande partie des contrôles de sécurité typiques et des vérifications de l’assurance qualité sont considérablement affectés, voire même supprimés. C’est pourquoi les efforts DevOps rencontrent souvent une résistance importante  de la part des équipes de sécurité.

Les dangers liés à la sécurité sont doubles et ont d’importantes conséquences

Danger n°1 : Le premier danger est que les contrôles de sécurité en place depuis des années ne suivront pas la transition vers DevOps. Mais les processus de sécurité antérieurs à DevOps ne doivent pas être délaissés s’ils sont scriptés et automatisés. Cela signifie que lorsque les vérifications de la qualité et des performances des logiciels sont automatisées, les scripts de sécurité doivent être intégrés à ce processus, afin de rechercher les erreurs de programmation de logiciels.

C’est souvent plus facile à dire qu’à faire. Cela nécessite que des développeurs, des équipes d’assurance qualité (QA) et des équipes de sécurité accèdent à des environnements de tests identiques à l’environnement de production, ainsi qu’à un processus d’intégration continu élaboré. Les outils de test doivent également être conçus, calibrés, maintenus et utilisés correctement, ou les contrôles de sécurité et de conformité seront voués à l’échec.

Danger n°2 : Cela nous conduit au second danger. Si les processus et les contrôles de sécurité ne sont pas effectués correctement manuellement dans une entreprise, la situation ne fera qu’empirer lorsque l’automatisation sera appliquée aux processus de gestion des opérations et du développement. C’est pourquoi il est important de réfléchir et de s’efforcer d’optimiser ces processus autant que possible avant de concevoir tout test d’assurance de qualité et de sécurité automatisé.

Il n’y a cependant pas que des mauvaises nouvelles

Appliqué correctement, le DevOps peut en fait contribuer à simplifier considérablement les tâches de sécurité.

Par exemple, lors du déploiement dans le processus d’intégration continue d’unités de code ou d’application, les sprints doivent être suffisamment avancés afin de pouvoir être complètement testés à la recherche de défauts de sécurité avant le déploiement du code. Et le fait est qu’intégrer la sécurité et les contrôles qualité dans les premières phases du développement est l’objectif défini part les meilleures pratiques en matière de sécurité des applications. 

La sécurité n’est pas la seule fonction de l’entreprise transformée par DevOps : les processus d’audit le sont également.Comme vous pouvez l’imaginer, alors que les équipes de sécurité stressent avec l’automatisation, la réaction des auditeurs et régulateurs est plus vive. Et plus j’interroge d’entreprises au sujet de leurs pratiques DevOps, plus je me rends compte que la sécurité n’est pas le principal obstacle au DevOps, ce sont bien souvent les auditeurs internes et externes qui en sont la cause.

Toutes les entreprises ne seront pas confrontées à des obstacles réglementaires bien que ce soit le cas pour la plupart d’entre elles actuellement. Et si ce n’est pas le cas actuellement, un nouveau règlement aura probablement un impact sur la façon dont les processus informatiques sont  inspectés à l’avenir – ou bien ce sera une administration ou un client important qui exigeront des audits plus poussés dans le cadre de leurs contrôles de sécurité.

Il ne s’agit pas d’un détail pour les auditeurs. Ces derniers ont beaucoup de responsabilité et de pression lorsqu’ils valident les contrôles qu’une entreprise met en place et il est donc justifié qu’ils s’inquiètent lorsqu’ils commencent à entendre parler de changements importants affectant les contrôles réglementaires.

C’est avec ces éléments en tête que j’ai récemment interviewé les auteurs du DevOps Audit Defense Toolkit (le toolkit est disponible ici), qui vise à aider les entreprises à améliorer la communication entre les adeptes du DevOps et les auditeurs, ainsi qu’à aider les auditeurs à mieux comprendre l’informatique, y compris le langage des risques, des objectifs de contrôle, des contrôles et l’esprit de l’audit.

L’idée est d’aider les équipes informatiques à informer leurs auditeurs à propos des contrôles qui sont mis en place afin que ceux-ci comprennent comment les tests et les contrôles automatisés, les journaux des modifications et d’autres systèmes de surveillance dans le cadre des processus de déploiement et d’intégration continus fonctionnent tous ensemble. Ainsi, lorsque les choses sont faites correctement, la sécurité et les contrôles réglementaires peuvent être améliorés à de nombreux égards.

Il s’agit d’un renversement de situation fascinant : alors que le mouvement DevOps et les méthodologies d’intégration/de livraison continues mettent à rude épreuve les processus d’audit et de sécurité traditionnels, lorsque les choses sont faites correctement, il est possible que ces disciplines informatiques ne s’assurent pas uniquement que ces entreprises maintiennent leurs niveaux de sécurité et de conformité, mais aussi qu’elles permettent une amélioration de ces dernières à partir de ces efforts de la même manière que le DevOps et l’informatique continue améliorent l’agilité.