Partage via


Recommandations pour les pratiques de déploiement sécurisées

S’applique à cette recommandation de liste de contrôle Azure Well-Architected Framework Operational Excellence :

OE :11 Définissez clairement les pratiques de déploiement sécurisées de votre charge de travail. Mettez l’accent sur les idéaux des méthodes de mise en production petites, incrémentielles et contrôlées par la qualité. Utilisez des modèles de déploiement modernes et des techniques d’exposition progressive pour contrôler les risques. Comptez les déploiements de routine et les déploiements d’urgence ou de correctif logiciel.

Ce guide décrit les recommandations relatives à l’utilisation de pratiques de déploiement sécurisées (SDP). Les processus et procédures de déploiement sécurisés définissent comment apporter et déployer des modifications en toute sécurité dans votre charge de travail. L’implémentation de SDP vous oblige à réfléchir aux déploiements à l’aide de l’objectif de la gestion des risques. Vous pouvez réduire le risque d’erreur humaine dans vos déploiements et limiter les effets des déploiements problématiques sur vos utilisateurs en implémentant SDP.

Stratégies de conception

Il existe quatre recommandations importantes à garder à l’esprit lors de l’implémentation de pratiques de déploiement sécurisées :

  • Sécurité et cohérence : toutes les modifications apportées à la charge de travail de production sont intrinsèquement risquées et doivent être effectuées avec un accent sur la sécurité et la cohérence.

  • Exposition progressive : vous pouvez réduire le rayon d’explosion potentiel des problèmes causés par le déploiement en adoptant un modèle de déploiement d’exposition progressive.

  • Modèles d’intégrité : les déploiements doivent passer des contrôles d’intégrité avant que chaque phase d’exposition progressive puisse commencer.

  • Détection des problèmes : lorsque des problèmes sont détectés, le déploiement doit être immédiatement arrêté et lancé par la récupération.

Les sections suivantes fournissent des recommandations détaillées sur chacun de ces points.

Garantir la sécurité et la cohérence des déploiements

Que vous déployiez une mise à jour du code de votre application, une infrastructure en tant que code (IaC), un drapeau de fonctionnalité ou une mise à jour de configuration, vous introduisez un risque dans la charge de travail. Il n’existe aucun déploiement à faible risque en production. Chaque déploiement doit suivre un modèle standard et doit être automatisé afin d'assurer la cohérence et de minimiser le risque d'erreur humaine. Il est essentiel que votre chaîne d’approvisionnement et vos pipelines de déploiement de charge de travail soient fiables, sécurisés et ont des normes de déploiement clairement définies. Traitez chaque déploiement comme un risque possible et faites passer chaque déploiement au même niveau de gestion des risques. Malgré les risques, vous devez continuer à déployer des modifications régulières dans votre charge de travail. L’échec du déploiement des mises à jour régulières introduit d’autres risques, tels que les vulnérabilités de sécurité qui doivent être traitées par le biais de déploiements. Pour plus d’informations, consultez Recommandations pour la conception d’une chaîne logistique de développement de charge de travail.

Les petits déploiements fréquents sont préférables aux déploiements de grande taille peu fréquents. Les petites modifications sont plus faciles à résoudre lorsque des problèmes surviennent et que des déploiements fréquents aident votre équipe à renforcer la confiance dans le processus de déploiement. Il est également important que vous appreniez de la production en examinant vos processus de charge de travail lorsque vous rencontrez une anomalie pendant le déploiement. Vous pouvez trouver des faiblesses dans la conception de votre infrastructure ou déploiement. Lorsque des problèmes se produisent pendant les déploiements, assurez-vous que les postmortems sans blâme font partie de votre processus SDP pour capturer des leçons sur l’incident.

Adopter un modèle d’exposition progressif

Lorsque des problèmes de déploiement surviennent, l'objectif est de les détecter le plus tôt possible afin d'en minimiser l'impact sur les utilisateurs finaux. Implémentez un modèle de déploiement progressif, également appelé modèle d’exposition progressif, pour atteindre cet objectif. Les déploiements Canary sont un exemple courant d’exposition progressive. Dans ce modèle de déploiement, un petit groupe d’utilisateurs internes ou externes reçoit d’abord la nouvelle fonctionnalité. Une fois que le premier groupe a exécuté la nouvelle version sans problème, la fonctionnalité est déployée successivement sur des groupes plus grands jusqu’à ce que la population de l’utilisateur entière exécute la nouvelle version. Les indicateurs de fonctionnalité sont généralement utilisés pour activer la nouvelle version pour les utilisateurs cibles dans les déploiements canary.

Un autre modèle de déploiement courant est une approche bleue-verte. Dans ce modèle, deux ensembles identiques, ou pools, de l’infrastructure de charge de travail sont déployés. Les deux pools peuvent gérer une charge de production complète. Le premier pool (bleu) exécute la version actuelle du déploiement où tous les utilisateurs atterrissent. Le deuxième pool (vert) est mis à jour avec la nouvelle fonctionnalité et testé en interne. Après les tests internes, un sous-ensemble du trafic de production est acheminé du pool bleu vers le pool vert. Comme les déploiements canary, le déploiement est progressif, car vous déplacez davantage le trafic vers le pool vert dans les vagues de déploiement successivement plus grandes. Une fois le déploiement terminé, le pool de mises à jour devient le pool bleu et le pool vert est prêt pour le déploiement suivant. Les deux pools sont séparés logiquement les uns des autres pour se protéger contre les dysfonctionnements. Vous pouvez déployer une variante du modèle bleu-vert dans une charge de travail qui utilise le modèle de conception Empreintes de déploiement en déployant sur un tampon à la fois.

Dans ces deux modèles, le temps entre chaque phase du déploiement doit être suffisamment long pour vous permettre de surveiller les métriques d’intégrité de la charge de travail. Vous devez fournir suffisamment de temps de cuisson, de temps entre les groupes de déploiement, pour vous assurer que les utilisateurs de différentes régions ou utilisateurs qui effectuent différentes tâches ont le temps d’utiliser la charge de travail dans leur capacité normale. Les temps de cuisson doivent être mesurés en heures et en jours plutôt que en minutes. Les temps de cuisson doivent également augmenter pour chaque groupe de déploiement afin que vous puissiez tenir compte des différents fuseaux horaires et modèles d’utilisation au cours de la journée.

Développer des modèles d’intégrité de charge de travail robustes

Développez un modèle d’intégrité robuste dans le cadre de votre plateforme d’observabilité et de vos stratégies de fiabilité. Votre modèle d’intégrité doit fournir une visibilité approfondie des composants et de l’intégrité globale de la charge de travail. Au cours d'un déploiement, si vous recevez une alerte concernant une modification de l'état de santé d'un utilisateur final, le déploiement doit être immédiatement interrompu et une enquête sur la cause de l'alerte doit être menée afin de déterminer la marche à suivre. S’il n’y a aucun problème signalé par les utilisateurs finaux et que tous les indicateurs de santé restent verts tout au long du temps de cuisson, le déploiement doit continuer. Veillez à inclure des métriques d’utilisation dans votre modèle d’intégrité pour vous assurer qu’un manque de problèmes signalés par l’utilisateur et les signaux d’intégrité négatifs ne cachent pas un problème. Pour plus d’informations, consultez Création d’un modèle d’intégrité.

Implémenter des mécanismes de détection des défaillances

Lorsque votre déploiement provoque un problème dans l’un des groupes de déploiement, le déploiement doit s’arrêter immédiatement. Une enquête sur la cause du problème et la gravité des effets doivent être effectuées dès que l’alerte est reçue. La récupération à partir du problème peut inclure :

  • Restaurez le déploiement en annulant les modifications apportées dans le déploiement et en revenant à la dernière configuration de travail connue.

  • Avancer le déploiement en traitant le problème au milieu du déploiement. Vous pouvez résoudre les problèmes de déploiement intermédiaire en appliquant un correctif logiciel ou en minimisant le problème.

  • Déploiement de nouvelles infrastructures à l’aide de la dernière configuration de travail connue.

La restauration des modifications, en particulier la base de données, le schéma ou d’autres modifications de composant avec état, peuvent être complexes. Vos instructions SDP doivent fournir des instructions claires sur la façon de gérer les modifications de données en fonction de la conception du patrimoine de données pour votre charge de travail. De même, la progression vers l’avant doit être gérée avec soin pour s’assurer que SDP n’est pas négligé et que le correctif logiciel ou d’autres efforts de réduction sont effectués en toute sécurité.

Établir des protocoles pour les déploiements d’urgence

  • Implémentez le contrôle de version sur vos artefacts de build pour vous assurer que vous pouvez restaurer et restaurer le cas échéant.

  • Utilisez un flux de mise en production ou une structure de branchement basée sur les jonctions, qui applique une collaboration étroitement synchronisée au sein de l’équipe de développement, au lieu d’une structure de branchement basée sur Gitflow ou basée sur un environnement.

  • Automatisez autant de votre SDP que possible. Pour obtenir des instructions détaillées sur l’automatisation des processus iaC et d’intégration continue des applications et de livraison continue (CI/CD), consultez Recommandations pour implémenter l’automatisation.

  • Utilisez des pratiques CI pour intégrer régulièrement des modifications de code dans des référentiels. Les pratiques CI peuvent vous aider à identifier les conflits d’intégration et à réduire la probabilité de fusions importantes et risquées. Pour plus d’informations, consultez le guide d’intégration continue.

  • Utilisez des indicateurs de fonctionnalité pour activer ou désactiver de manière sélective de nouvelles fonctionnalités ou modifications en production. Les indicateurs de fonctionnalité peuvent vous aider à contrôler l’exposition du nouveau code et à restaurer rapidement le déploiement en cas de problèmes.

  • Déployez des modifications dans des environnements intermédiaires qui reflètent votre environnement de production. Les environnements pratiques vous permettent de tester les modifications dans un paramètre contrôlé avant le déploiement dans l’environnement actif.

  • Établissez des vérifications de prédéploiement, notamment la révision du code, les analyses de sécurité et les vérifications de conformité, pour vous assurer que les modifications sont sécurisées à déployer.

  • Implémentez des disjoncteurs pour arrêter automatiquement le trafic vers un service qui rencontre des problèmes. Cela peut aider à prévenir une dégradation supplémentaire du système.

Protocoles SDP d’urgence

Établissez des protocoles prescriptifs qui définissent la façon dont votre SDP peut être ajusté pour un correctif logiciel ou pour des problèmes d’urgence tels qu’une violation de sécurité ou une exposition aux vulnérabilités. Par exemple, vos protocoles SDP d’urgence peuvent inclure :

  • Accélération de la promotion et de l’étape d’approbation.

  • Accélération des tests de fumée et des tests d’intégration.

  • Réduction du temps de cuisson.

Dans certains cas, l’urgence peut limiter la qualité et les portes de test, mais les portes doivent toujours être exécutées aussi rapidement que possible comme un exercice hors bande. Assurez-vous que vous définissez qui peut approuver l’accélération SDP en cas d’urgence et les critères qui doivent être remplis pour que l’accélération soit approuvée. Alignez vos protocoles SDP d’urgence avec votre plan d’intervention d’urgence pour vous assurer que toutes les urgences sont gérées en fonction des mêmes protocoles.

À propos de l’installation

La création et la maintenance des pratiques de déploiement sécurisées sont complexes. Votre réussite dans l’implémentation complète de normes robustes dépend de la maturité de vos pratiques dans de nombreux domaines de développement logiciel. L’utilisation de l’automatisation, iaC uniquement pour les modifications d’infrastructure, la cohérence dans les stratégies de branchement, l’utilisation d’indicateurs de fonctionnalité et de nombreuses autres pratiques peuvent contribuer à garantir un déploiement sécurisé. Utilisez ce guide pour optimiser votre charge de travail et informer vos plans d’amélioration à mesure que vos pratiques évoluent.

Facilitation Azure

  • Azure Pipelines et GitHub Actions prennent en charge les déploiements à plusieurs étapes à l’aide de portes d’approbation, ce qui peut vous aider à concevoir votre déploiement progressif d’exposition pour les déploiements.

  • Utilisez des emplacements intermédiaires Azure App Service pour échanger facilement entre les versions du code. Les emplacements intermédiaires sont utiles pour les tests dans les environnements intermédiaires et peuvent être utilisés pour les déploiements bleu-vert.

  • Stockez et gérez vos indicateurs de fonctionnalités d’application web dans Azure App Configuration. À l’aide de ce service, vous pouvez créer, modifier et déployer des fonctionnalités dans un plan de gestion unifié.

  • Déployez des applications de charge de travail sur votre machine virtuelle à l’aide d’applications de machine virtuelle.

  • Utilisez des équilibreurs de charge Azure pour implémenter des stratégies de déploiement et exposer l’intégrité de vos applications de charge de travail à l’aide de ressources natives.

  • Utilisez l’extension Intégrité de l’application pour signaler l’intégrité des applications à partir d’une instance de groupe de machines virtuelles identiques. L’extension sonde un point de terminaison d’application local, et met à jour l’état d’intégrité en fonction des réponses TCP/HTTP(S) reçues de la part de l’application.

  • Utilisez Azure Logic Apps pour créer une nouvelle version de l’application chaque fois qu’une mise à jour est effectuée. Azure gère un historique des versions d’application et peut rétablir ou promouvoir une version précédente.

  • De nombreux services Azure Database fournissent des fonctionnalités de restauration à un point dans le temps qui peuvent vous aider à restaurer. Les services qui prennent en charge la restauration dans le temps sont les suivants :

Exemple

Pour obtenir un exemple d’utilisation de ce modèle de déploiement, consultez le guide d’architecture des clusters Azure Kubernetes Service (AKS).

Liste de contrôle d’excellence opérationnelle

Reportez-vous à l’ensemble complet de recommandations.