Recommandations pour sécuriser un cycle de vie de développement

  • Article

S’applique à cette recommandation de liste de contrôle de sécurité Azure Well-Architected Framework :

SE :02 Maintenez un cycle de vie de développement sécurisé à l’aide d’une chaîne d’approvisionnement logicielle renforcée, principalement automatisée et auditable. Incorporez une conception sécurisée à l’aide de la modélisation des menaces pour vous protéger contre les implémentations qui n’ont pas de sécurité.

Guide connexe : Analyse des menaces

Ce guide décrit les recommandations pour renforcer votre code, votre environnement de développement et votre chaîne logistique logicielle en appliquant les meilleures pratiques de sécurité tout au long du cycle de développement. Pour comprendre ces conseils, vous devez connaître DevSecOps.

Schéma du cycle de sécurité.

DevSecOps intègre la sécurité dans les processus DevOps en :

  • Automatisation des tests de sécurité et de la validation.

  • Implémentation d’outils tels que les pipelines de sécurité pour analyser le code et l’IaC (Infrastructure as code) à la recherche de vulnérabilités.

Au cœur d’une charge de travail se trouve le code d’application qui implémente la logique métier. Le code et le processus de développement du code doivent être exempts de défauts de sécurité pour garantir la confidentialité, l’intégrité et la disponibilité.

Il ne suffit pas de sécuriser uniquement le plan d’infrastructure à l’aide de contrôles sur l’identité et la mise en réseau et d’autres mesures. Empêchez une implémentation incorrecte du code ou un bloc de code compromis pour renforcer votre posture de sécurité globale. Le plan d’utilisation, c’est-à-dire le code d’application, doit également être renforcé. Le processus d’intégration de la sécurité dans votre cycle de vie de développement est essentiellement un processus de renforcement. Comme le renforcement des ressources, le renforcement du développement de code est également indépendant du contexte. L’accent est mis sur l’amélioration de la sécurité et non sur les exigences fonctionnelles de l’application. Pour plus d’informations sur le renforcement, consultez Recommandations pour le renforcement des ressources.

Définitions

Terme Définition
Security Development Lifecycle (SDL) Ensemble de pratiques fournies par Microsoft qui prend en charge les exigences d’assurance et de conformité de sécurité.
Cycle de vie du développement logiciel (SDLC) Processus systématique et multiphase pour le développement de systèmes logiciels.

Stratégies de conception

Les mesures de sécurité doivent être intégrées à plusieurs points dans votre cycle de vie de développement logiciel (SDLC) existant pour garantir :

  • Les choix de conception n’entraînent pas de failles de sécurité.

  • Le code et la configuration de l’application ne créent pas de vulnérabilités en raison d’une implémentation exploitable et de pratiques de codage incorrectes.

  • Les logiciels acquis via la chaîne d’approvisionnement n’introduisent pas de menaces de sécurité.

  • Le code d’application, les processus de génération et de déploiement ne sont pas falsifiés.

  • Les vulnérabilités révélées par les incidents sont atténuées.

  • Les ressources inutilisées sont correctement désactivées.

  • Les exigences de conformité ne sont pas compromises ou réduites.

  • La journalisation d’audit est implémentée dans les environnements de développement.

Les sections suivantes fournissent des stratégies de sécurité pour les phases couramment pratiquées de SDLC.

Phase de configuration requise

L’objectif de la phase des exigences est de collecter et d’analyser les exigences fonctionnelles et non fonctionnelles d’une application ou d’une nouvelle fonctionnalité d’une application. Cette phase est importante, car elle facilite la création de garde-fous adaptés aux objectifs de l’application. La protection des données et de l’intégrité de votre application doit être une exigence fondamentale tout au long de chaque phase du cycle de vie du développement.

Par exemple, considérez une application qui doit prendre en charge les flux d’utilisateurs critiques qui permettent à l’utilisateur de charger et de manipuler des données. Les choix de conception de sécurité doivent couvrir les garanties relatives à l’interaction de l’utilisateur avec l’application, telles que l’authentification et l’autorisation de l’identité de l’utilisateur, l’autorisation d’autoriser uniquement les actions autorisées sur les données et empêcher l’injection sql. De même, couvrent les exigences non fonctionnelles telles que la disponibilité, la scalabilité et la facilité de maintenance. Les choix de sécurité doivent inclure les limites de segmentation, l’entrée et la sortie du pare-feu, ainsi que d’autres problèmes de sécurité transversaux.

Toutes ces décisions doivent conduire à une bonne définition de la posture de sécurité de l’application. Documentez les exigences de sécurité dans une spécification convenue et reflètez-les dans le backlog. Il doit indiquer explicitement les investissements en sécurité, ainsi que les compromis et les risques que l’entreprise est prête à assumer si les investissements ne sont pas approuvés par les parties prenantes de l’entreprise. Par exemple, vous pouvez documenter la nécessité d’utiliser un pare-feu d’applications web (WAF) devant votre application, comme Azure Front Door ou Azure Application Gateway. Si les parties prenantes de l’entreprise ne sont pas prêtes à accepter le coût supplémentaire de l’exécution d’un WAF, elles doivent accepter le risque que les attaques de la couche application puissent être dirigées vers l’application.

La collecte des exigences de sécurité est un élément essentiel de cette phase. Sans cet effort, les phases de conception et d’implémentation seront basées sur des choix non déclarés, ce qui peut entraîner des failles de sécurité. Vous devrez peut-être modifier l’implémentation ultérieurement pour prendre en charge la sécurité, ce qui peut être coûteux.

Phase de conception

Au cours de cette phase, les exigences de sécurité sont converties en exigences techniques. Dans votre spécification technique, documentez toutes les décisions de conception pour éviter toute ambiguïté lors de l’implémentation. Voici quelques tâches classiques :

Définir la dimension de sécurité de l’architecture système

Superposer l’architecture avec des contrôles de sécurité. Par exemple, les contrôles pratiques sur les limites d’isolation en fonction de votre stratégie de segmentation, les types d’identités nécessaires pour les composants de l’application et le type de méthodes de chiffrement à utiliser. Pour obtenir des exemples d’architectures, consultez les illustrations des sections Exemple des articles Gestion des identités et des accès et Mise en réseau .

Évaluer les affordances fournies par la plateforme

Il est important de comprendre la répartition des responsabilités entre vous et le fournisseur de cloud. Par exemple, évitez les chevauchements avec les contrôles de sécurité natifs Azure. Vous bénéficierez d’une meilleure couverture de sécurité et pourrez réallouer les ressources de développement aux besoins de l’application.

Par exemple, si votre conception appelle un pare-feu d’applications web en entrée, vous pouvez décharger cette responsabilité sur un équilibreur de charge comme Application Gateway ou Azure Front Door. Évitez de répliquer des fonctionnalités en tant que code personnalisé dans votre application.

Choisissez uniquement des frameworks, des bibliothèques et des logiciels de chaîne d’approvisionnement approuvés. Votre conception doit également spécifier le contrôle de version sécurisé. Les dépendances d’application doivent provenir de parties approuvées. Les fournisseurs tiers doivent être en mesure de répondre à vos exigences de sécurité et de partager leur plan de divulgation responsable. Tout incident de sécurité doit être signalé rapidement afin que vous puissiez prendre les mesures nécessaires. En outre, certaines bibliothèques peuvent être interdites par votre organization. Par exemple, les logiciels peuvent être protégés contre les vulnérabilités, mais toujours interdits en raison de restrictions de licence.

Pour vous assurer que ces conseils sont suivis par tous les contributeurs au logiciel, tenez à jour une liste des frameworks, bibliothèques et fournisseurs approuvés et/ou non approuvés. Si possible, placez des garde-fous dans les pipelines de développement pour prendre en charge la liste. Dans la mesure du possible, automatisez l’utilisation d’outils pour analyser les dépendances à la recherche de vulnérabilités.

Déterminez les modèles de conception de sécurité que le code d’application doit implémenter.

Les modèles peuvent prendre en charge des problèmes de sécurité tels que la segmentation et l’isolation, l’autorisation forte, la sécurité uniforme des applications et les protocoles modernes. Certains modèles opérationnels, tels que le modèle de quarantaine, peuvent aider à vérifier et à bloquer l’utilisation de logiciels susceptibles d’introduire des failles de sécurité.

Pour plus d’informations, consultez Modèles de conception cloud qui prennent en charge la sécurité.

Stocker les secrets d’application en toute sécurité

Implémentez en toute sécurité l’utilisation de secrets d’application et de clés pré-partagées que votre application utilise. Les informations d’identification et les secrets d’application ne doivent jamais être stockés dans l’arborescence du code source. Utilisez des ressources externes comme Azure Key Vault pour vous assurer que, si votre code source devient disponible pour un attaquant potentiel, aucun autre accès ne peut être obtenu. En général, trouvez des moyens d’éviter les secrets. L’utilisation d’identités managées, lorsque cela est possible, est un moyen d’atteindre cet objectif. Pour plus d’informations, consultez Recommandations pour la gestion des secrets d’application.

Définir des plans de test

Définissez des cas de test clairs pour les exigences de sécurité. Évaluez si vous pouvez automatiser ces tests dans vos pipelines. Si votre équipe dispose de processus pour les tests manuels, incluez les exigences de sécurité pour ces tests.

Notes

Effectuez la modélisation des menaces pendant cette phase. La modélisation des menaces peut confirmer que les choix de conception sont alignés sur les exigences de sécurité et exposer les lacunes que vous devez atténuer. Si votre charge de travail gère des données hautement sensibles, investissez dans des experts en sécurité qui peuvent vous aider à effectuer une modélisation des menaces.

L’exercice initial de modélisation des menaces doit se produire pendant la phase de conception lorsque l’architecture du logiciel et la conception générale sont en cours de définition. Cette opération au cours de cette phase vous permet d’identifier les problèmes de sécurité potentiels avant qu’ils ne soient incorporés dans la structure du système. Toutefois, cet exercice n’est pas une activité ponctuelle. Il s’agit d’un processus continu qui doit se poursuivre tout au long de l’évolution du logiciel.

Pour plus d’informations, consultez Recommandations pour l’analyse des menaces.

Phase de développement et de test

Au cours de cette phase, l’objectif est d’éviter les défauts de sécurité et la falsification dans les pipelines de code, de build et de déploiement.

Être bien formé aux pratiques de code sécurisé

L’équipe de développement doit avoir une formation formelle et spécialisée sur les pratiques de codage sécurisé. Par exemple, les développeurs web et d’API peuvent avoir besoin d’une formation spécifique pour se protéger contre les attaques de script intersites, et les développeurs back-end peuvent bénéficier d’une formation approfondie pour éviter les attaques au niveau de la base de données, telles que les attaques par injection de code SQL.

Les développeurs doivent suivre cette formation avant de pouvoir accéder au code source de production.

Vous devez également effectuer des révisions de code d’homologue internes pour promouvoir l’apprentissage continu.

Utiliser les outils de test de sécurité

Effectuez une modélisation des menaces pour évaluer la sécurité de l’architecture de l’application.

Utilisez les tests de sécurité des applications statiques (SAST) pour analyser le code à la recherche de vulnérabilités. Intégrez cette méthodologie dans l’environnement de développement pour détecter les vulnérabilités en temps réel.

Utilisez le test de sécurité des applications dynamiques (DAST) pendant l’exécution. Cette chaîne d’outils peut case activée d’erreurs dans les domaines de sécurité et simuler un ensemble d’attaques pour tester la résilience de sécurité de l’application. Si possible, intégrez cet outil à vos pipelines de build.

Suivez les normes du secteur pour des pratiques de codage sécurisées. Pour plus d’informations, consultez la section Ressources de la communauté de cet article.

Utilisez des linters et des analyseurs de code pour empêcher les informations d’identification d’être envoyées au référentiel de code source. Par exemple, les analyseurs .NET Compiler Platform (Roslyn) inspectent votre code d’application.

Pendant le processus de génération, utilisez des modules complémentaires de pipeline pour intercepter les informations d’identification dans le code source. Analysez toutes les dépendances, telles que les bibliothèques tierces et les composants du framework, dans le cadre du processus d’intégration continue. Examinez les composants vulnérables signalés par l’outil. Associez cette tâche à d’autres tâches d’analyse de code qui inspectent l’attrition du code, les résultats des tests et la couverture.

Utilisez une combinaison de tests. Pour plus d’informations sur les tests de sécurité en général, consultez Recommandations pour les tests de sécurité.

Écrire juste assez de code

Lorsque vous réduisez l’empreinte de votre code, vous réduisez également les risques de défauts de sécurité. Réutilisez le code et les bibliothèques déjà utilisés et qui ont été validées par des validations de sécurité au lieu de dupliquer du code.

Tirer parti des fonctionnalités Azure est une autre façon d’éviter le code inutile. L’une des façons consiste à utiliser des services managés. Pour plus d’informations, consultez Utiliser les options PaaS (Platform as a Service).

Écrivez du code avec une approche de refus de tout par défaut. Créez des listes d’autorisation uniquement pour les entités qui ont besoin d’un accès. Par exemple, si vous avez du code qui doit déterminer si une opération privilégiée doit être autorisée, vous devez l’écrire afin que le résultat de refus soit le cas par défaut et que le résultat d’autorisation se produise uniquement lorsqu’il est spécifiquement autorisé par le code.

Protéger les environnements de développement

Les stations de travail de développeur doivent être protégées avec des contrôles réseau et d’identité forts pour éviter toute exposition. Assurez-vous que les mises à jour de sécurité sont appliquées avec diligence.

Les agents de build sont hautement privilégiés et ont accès au serveur de build et au code. Ils doivent être protégés avec la même rigueur que vos composants de charge de travail. Cela signifie que l’accès aux agents de build doit être authentifié et autorisé, qu’ils doivent être segmentés sur le réseau avec des contrôles de pare-feu, qu’ils doivent être soumis à une analyse des vulnérabilités, etc. Les agents de build hébergés par Microsoft doivent être préférés aux agents de build auto-hébergés. Les agents hébergés par Microsoft offrent des avantages tels que propre machines virtuelles pour chaque exécution d’un pipeline.

Les agents de build personnalisés ajoutent une complexité de gestion et peuvent devenir des vecteurs d’attaque. Les informations d’identification de la machine de build doivent être stockées en toute sécurité et vous devez supprimer régulièrement tous les artefacts de build temporaires du système de fichiers. Vous pouvez obtenir l’isolation réseau en autorisant uniquement le trafic sortant à partir de l’agent de build, car il utilise le modèle d’extraction de communication avec Azure DevOps.

Le référentiel de code source doit également être protégé . Accordez l’accès aux référentiels de code en fonction du besoin d’en savoir et réduisez autant que possible l’exposition aux vulnérabilités pour éviter les attaques. Disposez d’un processus complet pour examiner le code à la recherche de failles de sécurité. Utilisez des groupes de sécurité à cet effet et implémentez un processus d’approbation basé sur des justifications métier.

Déploiements de codes sécurisés

Il ne suffit pas de sécuriser le code. S’il s’exécute dans des pipelines exploitables, tous les efforts de sécurité sont vains et incomplets. Les environnements de build et de mise en production doivent également être protégés , car vous souhaitez empêcher les acteurs malveillants d’exécuter du code malveillant dans votre pipeline.

Maintenir un inventaire à jour de chaque composant intégré à votre application

Chaque nouveau composant intégré à une application augmente la surface d’attaque. Pour garantir une responsabilité et des alertes appropriées lorsque de nouveaux composants sont ajoutés ou mis à jour, vous devez disposer d’un inventaire de ces composants. Stockez-le en dehors de l’environnement de build. Régulièrement, case activée que votre manifeste correspond à ce qui se trouve dans votre processus de génération. Cela permet de s’assurer qu’aucun nouveau composant contenant des portes arrière ou d’autres programmes malveillants n’est ajouté de manière inattendue.

Tâches de pipeline

  • Extraire des tâches dans votre pipeline à partir de sources approuvées, telles que Place de marché Azure. Exécutez les tâches écrites par votre fournisseur de pipeline. Nous recommandons des tâches ou des GitHub Actions GitHub. Si vous utilisez des flux de travail GitHub, préférez les tâches créées par Microsoft. En outre, validez les tâches, car elles s’exécutent dans le contexte de sécurité de votre pipeline.

  • Secrets de pipeline. Les ressources de déploiement qui s’exécutent à l’intérieur d’un pipeline ont accès à tous les secrets de ce pipeline. Mettez en place une segmentation appropriée pour les différentes étapes du pipeline afin d’éviter toute exposition inutile. Utilisez des magasins de secrets intégrés au pipeline. N’oubliez pas que vous pouvez éviter d’utiliser des secrets dans certaines situations. Explorez l’utilisation des identités de charge de travail (pour l’authentification de pipeline) et des identités managées (pour l’authentification de service à service).

Séparer les différents environnements

Les données utilisées dans différents environnements doivent être séparées. Les données de production ne doivent pas être utilisées dans des environnements inférieurs , car ces environnements peuvent ne pas avoir les contrôles de sécurité stricts dont dispose la production. Évitez de se connecter à partir d’une application hors production à une base de données de production et évitez de connecter des composants hors production à des réseaux de production.

Exposition progressive

Utilisez une exposition progressive aux fonctionnalités de mise en production pour un sous-ensemble d’utilisateurs en fonction des critères choisis. En cas de problème, l’impact est réduit pour ces utilisateurs. Cette approche est une stratégie d’atténuation des risques courante, car elle réduit la surface d’exposition. À mesure que la fonctionnalité évolue et que vous avez plus de confiance dans les garanties de sécurité, vous pouvez la publier progressivement pour un ensemble plus large d’utilisateurs.

Phase de production

La phase de production présente la dernière occasion responsable de corriger les failles de sécurité. Conservez un enregistrement de l’image en or publiée en production.

Conserver les artefacts avec version

Conservez un catalogue de toutes les ressources déployées et de leurs versions. Ces informations sont utiles lors du triage des incidents, lorsque vous atténuez les problèmes et lorsque vous rétablissez l’état de fonctionnement du système. Les ressources avec version peuvent également être comparées aux avis publiés sur les vulnérabilités et les expositions courantes (CVE). Vous devez utiliser l’automatisation pour effectuer ces comparaisons.

Correctifs d’urgence

Votre conception de pipeline automatisée doit avoir la flexibilité nécessaire pour prendre en charge les déploiements réguliers et d’urgence. Cette flexibilité est importante pour prendre en charge des correctifs de sécurité rapides et responsables.

Une mise en production est généralement associée à plusieurs portes d’approbation. Envisagez de créer un processus d’urgence pour accélérer les correctifs de sécurité. Le processus peut impliquer la communication entre les équipes. Le pipeline doit permettre des déploiements de restauration et de restauration rapides qui répondent aux correctifs de sécurité, aux bogues critiques et aux mises à jour de code qui se produisent en dehors du cycle de vie de déploiement normal.

Notes

Privilégiez toujours les correctifs de sécurité par rapport à la commodité. Un correctif de sécurité ne doit pas introduire de régression ou de bogue. Si vous souhaitez accélérer le correctif via un pipeline d’urgence, réfléchissez soigneusement aux tests automatisés qui peuvent être contournés. Évaluez la valeur de chaque test par rapport à la durée d’exécution. Par exemple, les tests unitaires se terminent généralement rapidement. Les tests d’intégration ou les tests de bout en bout peuvent s’exécuter pendant une longue période.

Phase de maintenance

L’objectif de cette phase est de s’assurer que la posture de sécurité ne se dégrade pas au fil du temps. SDLC est un processus agile continu. Les concepts abordés dans les phases précédentes s’appliquent à cette phase, car les exigences changent au fil du temps.

Gestion des correctifs. Maintenez les logiciels, les bibliothèques et les composants d’infrastructure à jour avec les mises à jour et les correctifs de sécurité.

Amélioration continue. Évaluez et améliorez en permanence la sécurité du processus de développement de logiciels en prenant en compte les révisions de code, les commentaires, les leçons apprises et l’évolution des menaces.

Désaffectez les ressources héritées qui sont obsolètes ou qui ne sont plus utilisées. Cela réduit la surface d’exposition de l’application.

La maintenance inclut également des correctifs d’incident. Si des problèmes sont détectés en production, ils doivent être rapidement intégrés dans le processus afin qu’ils ne se reproduisent pas.

Améliorez en permanence vos pratiques de codage sécurisé pour suivre le paysage des menaces.

Animation Azure

Microsoft Security Development Lifecycle (SDL) recommande des pratiques sécurisées que vous pouvez appliquer à votre cycle de vie de développement. Pour plus d’informations, consultez Cycle de vie du développement de sécurité Microsoft.

Defender pour DevOps et les outils SAST sont inclus dans GitHub Advanced Security ou Azure DevOps. Ces outils peuvent vous aider à suivre un score de sécurité pour votre organization.

Suivez les recommandations de sécurité Azure décrites dans ces ressources :

Pour rechercher des informations d’identification dans le code source, envisagez d’utiliser des outils tels que GitHub Advanced Security et les outils d’analyse du code source OWASP.

Validez la sécurité de tout code open source dans votre application. Ces outils et ressources gratuits peuvent vous aider à effectuer votre évaluation :

Liste de contrôle de sécurité

Reportez-vous à l’ensemble complet de recommandations.

Liste de contrôle de sécurité