Partager via

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

  • Article

S’applique à cette recommandation de liste de contrôle Sécurité Power Platform Well-Architected :

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

Ce guide décrit les recommandations pour sécuriser votre code et votre environnement de développement en appliquant les bonnes pratiques de sécurité tout au long du cycle de développement.

Au cœur d’une charge de travail se trouvent les composants qui implémentent la logique métier. Ces composants peuvent être un mélange d’éléments low-code comme les applications canevas et flux, et d’éléments axés sur le code comme les plug-ins. Tous les composants qui constituent votre charge de travail doivent être exempts de défauts de sécurité pour garantir la confidentialité, l’intégrité et la disponibilité.

Sécuriser le plan d’infrastructure avec des contrôles d’identité et de réseau est important, mais cela ne suffit pas. Prévenir une mauvaise mise en œuvre des charges de travail Power Platform et les activités compromises dans ces charges de travail pour renforcer votre posture de sécurité globale. Le processus d’intégration de la sécurité dans votre cycle de vie de développement est essentiellement un processus de durcissement. À l’instar du renforcement des ressources, le renforcement du développement du 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.

Définitions

Terme Définition
Cycle de vie du développement de la sécurité Ensemble de pratiques fournies par Microsoft qui prennent en charge les exigences d’assurance de la sécurité et de conformité.
Cycle de vie du développement logiciel Processus systématique et en plusieurs étapes pour développer des systèmes logiciels.

Stratégies de conception clés

Les mesures de sécurité doivent être intégrées à plusieurs points de votre cycle de vie de développement logiciel existant pour garantir ce qui suit :

  • Les choix de conception n’entraînent pas de failles de sécurité.
  • Les composants low-code et code-first ainsi que la configuration ne créent pas de vulnérabilités en raison d’une implémentation exploitable et de pratiques de codage inappropriées.
  • Les composants et les processus de déploiement low-code et code-first ne sont pas altérés.
  • Les vulnérabilités révélées par les incidents sont atténuées.
  • Les exigences de conformité ne sont ni compromises ni réduites.
  • La journalisation d’audit est implémentée dans tous les environnements.

Les sections suivantes fournissent des stratégies de sécurité pour les phases couramment pratiquées du cycle de vie de développement logiciel.

Phase des besoins

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

Par exemple, considérons une charge de travail dans laquelle les utilisateurs saisiront et modifieront des données dans une application. Les choix de conception de sécurité doivent couvrir les garanties de l’interaction de l’utilisateur avec les données, comme l’authentification et l’autorisation de l’identité de l’utilisateur et l’autorisation uniquement des actions autorisées sur les données. Les exigences non fonctionnelles couvrent la disponibilité, la convivialité et la maintenabilité. Les choix de sécurité doivent inclure les limites de segmentation, les entrées et sorties du pare-feu, ainsi que d’autres problèmes de sécurité transversaux.

Toutes ces décisions devraient conduire à une bonne définition de la posture de sécurité de la charge de travail. Documentez les exigences de sécurité dans une spécification convenue et reflétez-les dans la réplication. Le document doit indiquer explicitement les investissements en matière de 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 IP dans les environnements Power Platform pour protéger les données de votre organisation en les limitant à l’accès Dataverse aux seuls emplacements IP autorisés. Si les parties prenantes de l’entreprise ne sont pas disposées à supporter le coût supplémentaire lié à l’utilisation d’une solution telle que les environnements gérés, elles doivent être prêtes à accepter le risque que les ressources organisationnelles soient accessibles à partir de lieux publics, comme un café. Comme autre exemple, imaginez que votre application doive se connecter à une source de données tierce. Power Platform peut avoir un connecteur prêt à l’emploi pour cela, mais il peut ne pas prendre en charge les exigences d’authentification approuvées par vos équipes de sécurité. Dans ce cas, vos acteurs de la sécurité peuvent être disposés à accepter le risque lié à l’utilisation d’une méthode d’authentification non approuvée. Vous pouvez également envisager d’utiliser un connecteur personnalisé, tout en pesant les avantages d’un temps de développement accru et d’un retard potentiel du projet.

La collecte des exigences de sécurité est une partie essentielle de cette phase. Sans cet effort, les phases de conception et de mise en œuvre reposeront sur des choix non déclarés, ce qui peut entraîner des failles de sécurité ou des exigences changeantes qui augmenteront le temps de développement. Vous devrez peut-être modifier l’implémentation ultérieurement pour assurer la sécurité, ce qui peut s’avérer coûteux.

Phase de conception

Durant 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 la mise en œuvre. Voici quelques tâches classiques :

  • Définir la dimension sécurité de l’architecture. Superposer l’architecture avec des contrôles de sécurité. Par exemple, des contrôles pratiques sur les limites d’isolation du réseau, les types d’identités et les méthodes d’authentification nécessaires pour les composants de la charge de travail et le type de méthodes de chiffrement à utiliser.

  • Évaluer les possibilités fournies par la plateforme. Il est important de comprendre le partage des responsabilités entre vous et Power Platform. Évitez les chevauchements ou les duplications grâce aux contrôles de sécurité natifs Power Platform. Vous bénéficierez d’une meilleure couverture de sécurité et pourrez réaffecter les ressources de développement aux besoins de l’application.

    Par exemple, au lieu de créer une logique personnalisée qui identifie et alerte de manière réactive les modèles d’utilisation non approuvés dans les applications et les flux, utilisez les stratégies de prévention contre la perte de données pour catégoriser la manière dont les connecteurs peuvent être utilisés.

    Choisissez uniquement des implémentations de référence, des modèles, des composants de code, des scripts et des bibliothèques fiables. Votre conception doit également spécifier un contrôle de version sécurisé. Les dépendances des applications doivent provenir de parties de confiance. 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 ou implémentations de référence peuvent être interdites par votre organisation. Par exemple, même si elle est sécurisée et exempte de vulnérabilités, elle peut néanmoins être refusée, car elle utilise des fonctionnalités non encore approuvées par votre organisation, des restrictions de licence ou le modèle de support de l’implémentation de référence.

    Pour vous assurer que ces directives sont suivies, maintenez une liste des frameworks, bibliothèques et fournisseurs approuvés et/ou non approuvés, et assurez-vous que vos créateurs connaissent cette liste. Lorsque cela est possible, placez des garde-fous dans les pipelines de développement pour soutenir la liste. Dans la mesure du possible, automatisez l’utilisation d’outils pour analyser les dépendances à la recherche de vulnérabilités.

  • Stockez les clés secrètes des applications en toute sécurité. Implémentez en toute sécurité l’utilisation des clés secrètes d’application et des 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 le code source de la charge de travail (application ou flux). Utilisez des ressources externes comme Azure Key Vault pour vous assurer que, si votre code source devient disponible pour un attaquant potentiel, aucun accès supplémentaire ne pourra être obtenu.

  • Connectez-vous à vos données en toute sécurité. Profitez des fonctionnalités de sécurité avancées de Microsoft Dataverse pour protéger vos données, telles que la sécurité basée sur les rôles et au niveau des colonnes. Pour les autres sources de données, utilisez des connecteurs dotés de méthodes d’authentification sécurisées. Évitez les requêtes qui stockent le nom d’utilisateur et le mot de passe en texte brut. Empêchez le protocole HTTP de créer des connecteurs personnalisés.

  • Définissez comment les utilisateurs finaux interagiront avec la charge de travail et les données. Déterminez si les utilisateurs auront un accès direct aux données, de quel niveau d’accès ils ont besoin et d’où ils accéderont aux données. Pensez à la manière dont les applications seront partagées avec les utilisateurs finaux. Assurez-vous que seuls ceux qui ont besoin d’accéder à l’application et aux données y auront accès. Évitez les modèles de sécurité complexes qui encouragent des solutions de contournement pour éviter les bloqueurs de sécurité.

  • Évitez le codage en dur. Évitez le codage en dur des URL et des clés. Par exemple, évitez de coder en dur dans une action HTTP Power Automate l’URL ou la clé du service backend. Utilisez plutôt un connecteur personnalisé ou utilisez une variable d’environnement pour l’URL et Azure Key Vault pour la clé API.

  • Définissez les plans de tests. 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 de tests manuels, incluez les exigences de sécurité pour ces tests.

Note

Effectuez une 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 révéler les lacunes que vous devez atténuer. Si votre charge de travail gère des données très sensibles, investissez dans des experts en sécurité qui peuvent vous aider à modéliser les menaces.

L’exercice initial de modélisation des menaces doit avoir lieu pendant la phase de conception, lorsque l’architecture et la conception de haut niveau du logiciel sont définies. Y parvenir pendant cette phase vous aide à identifier les problèmes de sécurité potentiels avant qu’ils ne soient intégrés dans la structure du système. Cependant, 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 sur l’analyse des menaces.

Phase de développement et de test

Durant cette phase, l’objectif consiste à prévenir les défauts de sécurité et la falsification des pipelines de code, de construction et de déploiement.

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

L’équipe de développement devrait bénéficier d’une formation aux pratiques de codage sécurisé. Par exemple, les développeurs doivent être familiarisés avec les concepts de sécurité dans Microsoft Dataverse pour mettre en œuvre un modèle de sécurité de moindre privilège, des politiques de sécurité du contenu pour les applications basées sur un modèle afin de restreindre l’intégration aux domaines de confiance et des méthodes d’authentification de connecteur/passerelle sur site.

Les développeurs devraient être tenus de suivre cette formation avant de commencer à travailler sur les charges de travail Power Platform.

Effectuez des révisions internes du code par les pairs pour promouvoir l’apprentissage continu.

Utiliser des outils d’analyse de code

Le vérificateur de solutions doit être utilisé pour les ressources Power Platform et le code source de tout code traditionnel pourraient être vérifiés pour détecter d’éventuelles failles de sécurité, y compris la présence d’informations d’identification dans le code. Identifiez les cas possibles d’exposition d’informations d’identification et de clés secrètes dans le code source et les fichiers de configuration. C’est le bon moment pour revoir la manière dont les informations d’identification de connexion seront gérées en production.

Effectuer des tests approximatifs

Utilisez des données mal formées et inattendues pour vérifier les vulnérabilités et valider la gestion des erreurs, particulièrement importantes avec des solutions parmi lesquelles figure Power Pages.

É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éutiliser le code et les bibliothèques déjà utilisés et ayant fait l’objet de validations de sécurité au lieu de dupliquer le code. Détection de logiciels open source et vérification de la version, de la vulnérabilité et des obligations légales. Il existe un nombre croissant de ressources Power Platform open source, il ne faut donc pas les négliger. Lorsque cela est possible, cela doit être discuté lors de la phase de conception pour éviter les problèmes de dernière minute.

Protéger les environnements de développement

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

Le référentiel du code source doit être sauvegardé également. Accordez l’accès aux référentiels de code en cas de besoin et réduisez autant que possible l’exposition aux vulnérabilités pour éviter les attaques. Faites en sorte de disposer d’un processus approfondi pour réviser le code pour les failles de sécurité. Utilisez des groupes de sécurité à cette fin et mettez en œuvre un processus d’approbation basé sur des justifications commerciales.

Déploiements sécurisés de code

Il ne suffit pas de sécuriser le code. S’il fonctionne dans des pipelines exploitables, tous les efforts de sécurité sont vains et incomplets. Les environnements de build et de publication doivent également être protégés parce que vous voulez empêcher les mauvais acteurs d’exécuter du code malveillant dans votre pipeline.

Maintenir à jour les stocks de chaque composant intégré à votre application

Chaque nouveau composant intégré dans une application augmente la surface d’attaque. Pour garantir une responsabilité et une alerte appropriées lorsque de nouveaux composants sont ajoutés ou mis à jour, vous devez disposer d’un inventaire de ces composants. Vérifiez régulièrement que votre manifeste correspond au contenu de votre processus de génération. Cela permet de garantir qu’aucun nouveau composant contenant des portes dérobées ou d’autres logiciels malveillants n’est ajouté de manière inattendue.

Nous vous recommandons d’utiliser Pipelines pour Power Platform pour vos déploiements. Étendez les pipelines avec GitHub Actions. Si vous utilisez des workflows GitHub, préférez les tâches créées par Microsoft. Validez également les tâches, car elles s’exécutent dans le contexte de sécurité de votre pipeline.

Explorez l’utilisation des principaux de service pour le déploiement.

Phase de production

La phase de production présente la dernière opportunité responsable de corriger les failles de sécurité. Gardez une trace de l’image dorée publiée en production.

Conserver les artefacts versionnés

Conservez un catalogue de tous les actifs déployés et de leurs versions. Ces informations sont utiles lors du tri des incidents, lorsque vous atténuez les problèmes et lorsque vous remettez le système en état de fonctionnement. Les actifs versionnés peuvent également être comparés aux avis publiés sur les vulnérabilités et expositions communes (CVE). Vous devez utiliser l’automatisation pour effectuer ces comparaisons.

Correctifs d’urgence

La conception de votre pipeline automatisé doit être suffisamment flexible 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 version 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 une communication entre les équipes. Le pipeline doit permettre des déploiements rapides de déploiement par étape et de déploiement par annulation qui corrigent les correctifs de sécurité, les bogues critiques et les mises à jour de code qui se produisent en dehors du cycle de vie de déploiement normal.

Note

Donnez toujours la priorité aux correctifs de sécurité plutôt qu’à 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 attentivement aux tests automatisés qui peuvent être contournés. Évaluez la valeur de chaque test par rapport au temps d’exécution. Par exemple, les tests unitaires se terminent généralement rapidement. Les tests d’intégration ou de bout en bout peuvent s’exécuter pendant une longue période.

Garder les différents environnements séparés

Les données de production ne doivent pas être utilisées dans des environnements inférieurs**, car ces environnements peuvent ne pas disposer des contrôles de sécurité stricts dont dispose la production. Évitez de vous connecter depuis une application hors production à une base de données de production et évitez de connecter des composants hors production aux réseaux de production.

Utiliser une exposition progressive

Utilisez une exposition progressive pour publier des fonctionnalités à un sous-ensemble d’utilisateurs en fonction de critères choisis. S’il y a des problèmes, l’impact est réduit au minimum pour ces utilisateurs. Cette approche est une stratégie courante d’atténuation des risques, car elle réduit la superficie. À mesure que la fonctionnalité évolue et que vous avez davantage confiance dans les garanties de sécurité, vous pouvez progressivement la proposer à un plus grand nombre d’utilisateurs.

Phase de maintenance

L’objectif de cette phase consiste à garantir que le niveau de sécurité ne se dégrade pas avec le temps. Le cycle de vie de développement logiciel désigne un processus agile continu. Les concepts abordés dans les phases précédentes s’appliquent à cette phase, car les besoins évoluent avec le temps.

Amélioration continue. Évaluez et améliorez en permanence la sécurité du processus de développement logiciel en tenant compte des révisions de code, des commentaires, des leçons apprises et de l’évolution des menaces, ainsi que des nouvelles fonctionnalités mises à disposition par Power Platform.

Mettez hors service les anciennes ressources qui sont obsolètes ou ne sont plus utilisées. Cela réduit le périmètre d’application.

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

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

SDL dans Microsoft Power Platform

Power Platform repose sur une culture et une méthodologie de conception sécurisée. La culture et la méthodologie sont constamment renforcées par les pratiques Cycle de vie du développement de la sécurité (SDL) et de modélisation des menaces de premier plan de Microsoft.

Le processus d’évaluation robuste de la modélisation des menaces garantit que les menances sont identifiées pendant la phase de conception, réduites et validées pour s’assurer qu’elles ont été atténuées.

La modélisation des menaces tient également compte de toutes les modifications apportées aux services qui sont déjà en ligne grâce à des examens réguliers continus. S’appuyer sur le modèle STRIDE aide à résoudre les problèmes les plus courants liés à la conception non sécurisée.

Le SDL de Microsoft est équivalent au Modèle de maturité de l’assurance logicielle OWASP (SAMM). Les deux sont construits sur le principe que la conception sécurisée fait partie intégrante de la sécurité des applications Web. Pour plus d’informations, consultez la rubrique 10 principaux risques de l’OWASP : atténuations dans Power Platform.

Facilitation de Power Platform

Le cycle de vie de développement de la sécurité Microsoft recommande des pratiques sécurisées que vous pouvez appliquer à votre cycle de vie de développement. Pour plus d’informations, consultez la rubrique Cycle de vie du développement de la sécurité Microsoft.

Defender pour DevOps et les outils SAST (Static Application Security Testing) sont inclus dans GitHub Advanced Security et Azure DevOps. Ces outils peuvent vous aider à suivre un score de sécurité pour votre organisation.

Avec la fonctionnalité de vérificateur de solution, vous pouvez exécuter une vérification d’analyse statique enrichie de vos solutions par rapport à un ensemble de règles de meilleures pratiques et identifier rapidement ces schémas problématiques. Consultez Utiliser le vérificateur de solution pour valider vos solutions.

Voir aussi

Liste de contrôle de sécurité

Référez-vous à l’ensemble complet des recommandations.

Liste de contrôle de sécurité