The Secure Developer : parler DevSecOps sur Azure avec Victoria Almazova de Microsoft

En février dernier, Snyk a lancé une nouvelle communauté éducative, indépendante des fournisseurs et axée sur la sécurité : The Secure Developer. Snyk souhaite aider les développeurs à intégrer la sécurité à chaque étape de leur processus de développement. La communauté The Secure Developer est l’endroit idéal pour y parvenir : vous pouvez y découvrir les bonnes pratiques de sécurité auprès d’experts, dans une ambiance accessible et positive.

Au cours des sept derniers mois, The Secure Developer a organisé des sessions virtuelles toutes les deux semaines, sur des sujets allant de la sécurité des microservices aux 10 contrôles proactifs de l’OWASP.

Si vous doutez de l’intérêt d’une session virtuelle, permettez-moi de vous donner un aperçu rapide d’une session récente de The Secure Developer. J’espère que cela vous convaincra de nous rejoindre lors de notre prochaine session virtuelle.

DevSecOps sur Azure avec Victoria Almazova de Microsoft

Victoria Almazova est architecte de solutions cloud chez Microsoft. Elle aide les utilisateurs à planifier, concevoir et déployer leurs projets sur le cloud Azure. Elle prend en compte la sécurité tout au long du processus : c’est précisément le sujet de sa récente session. Victoria nous a présenté sa démarche pour :

• mettre en œuvre la sécurité Azure au niveau de l’abonnement

• développer des applications sécurisées

• déployer vos applications en toute sécurité

• analyser régulièrement les environnements de production pour vérifier leur conformité et leur sécurité

Lorsque le DevOps a commencé à gagner en popularité, Victoria était sceptique, car elle avait l’impression que la sécurité était mise de côté. Elle a fini par adhérer à l’idée du DevOps, qui offre la possibilité d’intégrer la sécurité de manière plus globale. Pour Victoria, le DevOps est l’union des personnes, des processus et des technologies qui permet de fournir en continu de la valeur aux utilisateurs finaux. Que l’on apprécie ou non le mot à la mode « DevSecOps », la sécurité peut effectivement intervenir tout au long du processus DevOps, du début à la fin, et rendre ainsi le produit final encore plus intéressant.

L’intégration de la sécurité dans un processus DevOps peut sembler insurmontable. Victoria nous propose donc quelques pistes pour démarrer.

L’infrastructure est un bon point de départ. Victoria recommande d’organiser les abonnements Azure « par projet » et « par environnement ». Cela permet de définir les autorisations et les paramètres appropriés pour chaque projet et environnement. Il est également important que les politiques soient transparentes et proactives. Victoria recommande en outre d’utiliser Azure Security Center dès le premier jour.

Pour compléter ses recommandations sur l’infrastructure, Victoria insiste sur l’importance d’adopter une approche Infrastructure as Code (IaC). Si vous ne connaissez pas ce terme, l’IaC consiste à gérer l’infrastructure à l’aide d’un modèle descriptif, en utilisant le même système de gestion des versions que les équipes DevOps pour le code source. Cette approche limite la dérive des environnements et garantit leur cohérence.

Dernier conseil de Victoria pour sécuriser l’infrastructure : les environnements de production doivent être mis à jour uniquement via le pipeline d’intégration continue et de livraison continue (CI/CD), jamais manuellement. Ce pipeline est au cœur des initiatives de sécurité. En abordant la sécurité des applications, Victoria a expliqué à la communauté comment celle-ci s’intègre aux différentes étapes du pipeline CI/CD. Selon Victoria, il comprend les étapes suivantes :

1. Avant le commit

2. Commit (CI)

3. Acceptation (CD)

4. Production

5. Exploitation

Chacune de ces étapes peut être renforcée par des pratiques de sécurité, détaillées dans les sections suivantes.

Avant le commit

À l’étape précédant le commit, le développeur écrit du code ou modifie du code existant. Tout investissement dans la sécurité à ce stade sera bénéfique par la suite, car les changements sont plus faciles à effectuer à ce point du pipeline. C’est le moment idéal pour modéliser les menaces, utiliser un plug-in de sécurité pour l’IDE, respecter les normes de codage sécurisé de votre équipe et procéder à une revue par les pairs.

Commit (CI)

À l’étape du commit, vous pouvez configurer l’exécution automatique de plusieurs processus. Les mesures de sécurité à prendre en compte à ce stade du pipeline CI/CD comprennent l’analyse statique du code, les tests unitaires de sécurité et la gestion des dépendances.

Acceptation (CD)

À l’étape d’acceptation, les mesures de sécurité pertinentes comprennent l’IaC, l’analyse de sécurité, la configuration du cloud et les tests d’acceptation de sécurité. Ces tests peuvent être effectués dans un environnement d’assurance qualité ou de préproduction avant le déploiement en production.

Production

En production, les tests de fumée de sécurité, les vérifications de configuration et les tests d’intrusion sont des procédures de sécurité utiles.

Exploitation

En phase d’exploitation, la surveillance continue, le renseignement sur les menaces, les tests d’intrusion et les rétrospectives sans recherche de responsabilité contribuent à renforcer la posture et la culture de sécurité.

The Secure Developer

Victoria a conclu sa session par une démonstration et une séance de questions-réponses. Je vous invite à regarder la présentation complète ici. J’ai beaucoup apprécié le point de vue de Victoria sur les nombreuses façons dont les développeurs peuvent renforcer leur sécurité, qu’ils déploient un projet sur le cloud Azure ou sur une autre solution.

La communauté The Secure Developer s’attache à inviter d’excellents intervenants comme Victoria Almazova à ses sessions virtuelles et à son podcast. Si vous souhaitez en savoir plus sur tous les aspects de la sécurité, pensez à rejoindre la communauté. Nous serions ravis de vous y retrouver.