Consommez des artefacts logiciels tiers dans votre chaîne d’approvisionnement uniquement lorsqu’ils sont vérifiés et marqués comme sûrs à l’utilisation, par des processus bien définis. Ce modèle est un complément opérationnel au processus de développement. Le consommateur de ce modèle invoque ce processus pour vérifier et bloquer l’utilisation de logiciels qui pourraient potentiellement introduire des vulnérabilités de sécurité.
Contexte et problème
Les solutions cloud reposent souvent sur des logiciels tiers obtenus à partir de sources externes. Les binaires open-source, les images de conteneurs publiques, les images OS de fournisseurs sont des exemples de ces types d’artefacts. Tous ces artefacts externes doivent être traités comme non fiables.
Dans un flux de travail classique, l’artefact est récupéré à partir d’un magasin extérieur au périmètre de la solution, puis intégré dans le pipeline de déploiement. Il y a des problèmes potentiels dans cette approche. La source pourrait ne pas être fiable, l’artefact pourrait contenir des vulnérabilités, ou il pourrait ne pas être adapté de quelque manière que ce soit pour l’environnement de développement.
Si ces problèmes ne sont pas traités, les garanties d’intégrité et de confidentialité des données de la solution pourraient être compromises, ou causer une instabilité due à l’incompatibilité avec d’autres composants.
Certains de ces problèmes de sécurité peuvent être évités en ajoutant des vérifications à chaque artefact.
Solution
Dotez-vous d’un processus qui valide le logiciel pour la sécurité avant de l’introduire dans votre charge de travail. Au cours du processus, chaque artefact subit une rigueur opérationnelle approfondie qui le vérifie contre des conditions spécifiques. Ce n’est qu’après que l’artefact satisfait à ces conditions, que le processus le marque comme fiable.
Le processus de mise en quarantaine est une mesure de sécurité, qui consiste en une série de points de contrôle employés avant qu’un artefact soit consommé. Ces points de contrôle de sécurité assurent qu’un artefact passe d’un statut non fiable à un statut fiable.
Il est important de noter que le processus de quarantaine ne change pas la composition de l’artefact. Le processus est indépendant du cycle de développement logiciel et est invoqué par les consommateurs, selon les besoins. En tant que consommateur de l’artefact, bloquez l’utilisation des artefacts jusqu’à ce qu’ils aient passé la quarantaine.
Voici un flux de travail de quarantaine classique :
Le consommateur signale son intention, spécifie la source d’entrée de l’artefact et bloque son utilisation.
Le processus de quarantaine valide l’origine de la demande et obtient les artefacts du magasin spécifié.
Un processus de vérification personnalisé est effectué dans le cadre de la quarantaine, qui comprend la vérification des contraintes d’entrée et la vérification des attributs, de la source et du type contre des normes établies.
Certaines de ces vérifications de sécurité peuvent être l’analyse de vulnérabilité, la détection de logiciels malveillants, etc., sur chaque artefact soumis.
Les vérifications réelles dépendent du type d’artefact. Par exemple, évaluer une image OS est différent d’évaluer un paquet NuGet.
Si le processus de vérification est réussi, l’artefact est publié dans un magasin sécurisé avec des annotations claires. Sinon, il reste indisponible pour le consommateur.
Le processus de publication peut inclure un rapport cumulatif qui montre la preuve de vérification et la criticité de chaque vérification. Incluez une expiration dans le rapport au-delà de laquelle le rapport doit être invalide et l’artefact est considéré comme non sécurisé.
Le processus marque la fin de la quarantaine en signalant un événement avec des informations d’état accompagnées d’un rapport.
En se basant sur les informations, les consommateurs peuvent choisir de prendre des mesures pour utiliser l’artefact fiable. Ces actions sont hors du champ d’application du modèle de Quarantaine.
Problèmes et considérations
En tant qu’équipe qui consomme des artefacts tiers, assurez-vous qu’il est obtenu à partir d’une source fiable. Votre choix doit être aligné sur les normes approuvées par l’organisation pour les artefacts qui sont acquis auprès de fournisseurs tiers. Les fournisseurs doivent être capables de répondre aux exigences de sécurité de votre charge de travail (et de votre organisation). Par exemple, assurez-vous que le plan de divulgation responsable du fournisseur répond aux exigences de sécurité de votre organisation.
Créez une segmentation entre les ressources qui stockent des artefacts fiables et non fiables. Utilisez des contrôles d’identité et de réseau pour restreindre l’accès aux utilisateurs autorisés.
Dotez-vous d’un moyen fiable d’invoquer le processus de quarantaine. Assurez-vous que l’artefact n’est pas consommé par inadvertance jusqu’à ce qu’il soit marqué comme fiable. La signalisation doit être automatisée. Par exemple, les tâches liées à la notification des parties responsables lorsqu’un artefact est ingéré dans l’environnement de développement, l’engagement de modifications dans un référentiel GitHub, l’ajout d’une image à un registre privé, etc.
Une alternative à la mise en œuvre d’un modèle de quarantaine est de l’externaliser. Il existe des praticiens de la quarantaine spécialisés dans la validation d’actifs publics comme business model Évaluez les coûts financiers et opérationnels de l’implémentation du modèle par rapport à l’externalisation de la responsabilité. Si vos exigences de sécurité nécessitent plus de contrôle, il est recommandé de mettre en place votre propre processus.
Automatisez le processus d’ingestion d’artefacts ainsi que le processus de publication de l’artefact. Comme les tâches de validation peuvent prendre du temps, le processus d’automatisation doit pouvoir continuer jusqu’à ce que toutes les tâches soient terminées.
Le modèle sert de validation momentanée à la première opportunité. Le fait de passer la quarantaine avec succès ne garantit pas que l’artefact reste digne de confiance indéfiniment. L’artefact doit continuer à subir des analyses continues, des validations de pipeline et d’autres contrôles de sécurité de routine qui servent de validations de dernière opportunité avant de promouvoir la publication.
Le modèle peut être mis en œuvre par des équipes centrales d’une organisation ou une équipe individuelle en charge d’une charge de travail. Si plusieurs instances ou variations du processus de quarantaine existent, ces opérations devraient être standardisées et centralisées par l’organisation. Dans ce cas, les équipes en charge des charges de travail partagent le processus et bénéficient du transfert de la gestion du processus.
Quand utiliser ce modèle
Utilisez ce modèle dans les situations suivantes :
La charge de travail intègre un artefact développé en dehors du champ d’action de l’équipe en charge de la charge de travail. Voici quelques exemples courants :
Un artefact de l’Open Container Initiative (OCI) provenant de registres publics tels que DockerHub, le registre de conteneurs GitHub, le registre de conteneurs Microsoft.
Une bibliothèque logicielle ou un paquet provenant de sources publiques telles que la Galerie NuGet, l’Index des Paquets Python, le référentiel Apache Maven
Un paquet externe Infrastructure-as-Code (IaC) tel que les modules Terraform, les livres de cuisine Chef de la communauté, les modules vérifiés Azure
Une image OS fournie par le vendeur
L’équipe responsable de la charge de travail considère l’artefact comme un risque qui mérite d’être réduit. L’équipe comprend les conséquences négatives de l’intégration d’artefacts compromis et la valeur de la quarantaine pour assurer un environnement de confiance.
L’équipe a une compréhension claire et partagée des règles de validation qui devraient être appliquées à un type d’artefact. Sans consensus, le modèle pourrait ne pas être efficace.
Par exemple, si un ensemble différent de contrôles de validation est appliqué chaque fois qu’une image OS est ingérée en quarantaine, le processus global de vérification des images OS devient incohérent.
Ce modèle peut ne pas avoir d’utilité dans les cas suivants :
L’artefact logiciel est créé par l’équipe responsable de la charge de travail ou une équipe partenaire de confiance.
Le risque de ne pas vérifier l’artefact est moins coûteux que le coût de construction et de maintien du processus de quarantaine.
Conception de la charge de travail
Un architecte et l’équipe responsable de la charge de travail devraient évaluer comment le modèle de quarantaine peut être utilisé dans le cadre des pratiques DevSecOps de la charge de travail. Les principes sous-jacents sont couverts dans les piliers du cadre bien architecturé Azure.
| Pilier | Comment ce modèle soutient les objectifs des piliers. |
|---|---|
| Les décisions relatives à la conception de la sécurité permettent de garantir la confidentialité, l’intégrité et la disponibilité des données et des systèmes de votre charge de travail. | La première responsabilité de la validation de la sécurité est assurée par le modèle de quarantaine. La validation d’un artefact externe est effectuée dans un environnement segmenté avant qu’il ne soit consommé par le processus de développement. - SE :02 Cycle de vie du développement sécurisé - SE:11 Test et validation |
| L’excellence opérationnelle permet de fournir une qualité de charge de travail grâce à des processus standardisés et à la cohésion d’équipe. | Le modèle de quarantaine soutient les pratiques de déploiement sécurisé (SDP) en s’assurant que les artefacts compromis ne sont pas consommés par la charge de travail, ce qui pourrait conduire à des violations de sécurité lors de déploiements à exposition progressive. - OE:03 Pratiques de développement de logiciels - OE:11 Test et validation |
Comme pour toute autre décision de conception, il convient de prendre en compte les compromis par rapport aux objectifs des autres piliers qui pourraient être introduits avec ce modèle.
Exemple
Cet exemple applique le flux de travail de la solution à un scénario où l’équipe en charge de la charge de travail souhaite intégrer des artefacts OCI de registres publics à une instance Azure Container Registry (ACR) appartenant à l’équipe responsable de la charge de travail. L’équipe traite cette instance comme un magasin d’artefacts de confiance.
L’environnement de la charge de travail utilise Azure Policy pour Kubernetes pour appliquer la gouvernance. Il restreint les tirages de conteneurs uniquement à partir de leur instance de registre de confiance. De plus, des alertes Azure Monitor sont configurées pour détecter toute importation dans ce registre à partir de sources inattendues.
Une demande d’image externe est faite par l’équipe en charge de la charge de travail via une application personnalisée hébergée sur Azure Web Apps. L’application collecte les informations requises uniquement auprès des utilisateurs autorisés.
Point de contrôle de sécurité : l’identité du demandeur, le registre de conteneurs de destination et la source de l’image demandée sont vérifiés.
La demande est stockée dans Azure Cosmos DB.
Point de contrôle de sécurité : un audit est maintenu dans la base de données, gardant une trace de la lignée et des validations de l’image. Cette trace est également utilisée pour les rapports historiques.
La demande est gérée par un orchestrateur de flux de travail, qui est une fonction Azure durable. L’orchestrateur utilise une approche de dispersion et de rassemblement pour exécuter toutes les validations.
Point de contrôle de sécurité : l’orchestrateur a une identité gérée avec juste assez d’accès pour effectuer les tâches de validation.
L’orchestrateur fait une demande pour importer l’image dans le registre Azure Container Registry (ACR) de quarantaine considéré comme un magasin non fiable.
Le processus d’importation sur le registre de quarantaine obtient l’image du référentiel externe non fiable. Si l’importation réussit, le registre de quarantaine dispose d’une copie locale de l’image pour exécuter les validations.
Point de contrôle de sécurité : le registre de quarantaine protège contre les altérations et la consommation de la charge de travail pendant le processus de validation.
L’orchestrateur exécute toutes les tâches de validation sur la copie locale de l’image. Les tâches incluent des vérifications telles que la détection des vulnérabilités et des expositions communes (CVE), l’évaluation du logiciel de nomenclature (SBOM), la détection de logiciels malveillants, la signature d’image, etc.
L’orchestrateur décide du type de contrôles, de l’ordre d’exécution et du moment de l’exécution. Dans cet exemple, il utilise Azure Container Instance comme exécutants de tâches et les résultats sont dans la base de données d’audit Cosmos DB. Toutes les tâches peuvent prendre un temps significatif.
Point de contrôle de sécurité : cette étape est au cœur du processus de quarantaine qui effectue toutes les vérifications de validation. Le type de contrôles pourrait être des solutions personnalisées, open-source ou achetées auprès de fournisseurs.
L’orchestrateur prend une décision. Si l’image passe toutes les validations, l’événement est noté dans la base de données d’audit, l’image est poussée vers le registre de confiance, et la copie locale est supprimée du registre de quarantaine. Sinon, l’image est supprimée du registre de quarantaine pour éviter son utilisation accidentelle.
Point de contrôle de sécurité : l’orchestrateur maintient une segmentation entre les emplacements de ressources de confiance et non fiables.
Remarque
Au lieu que l’orchestrateur prenne la décision, l’équipe responsable de la charge de travail peut assumer cette responsabilité. Dans cette alternative, l’orchestrateur publie les résultats de la validation via une API et conserve l’image dans le registre de quarantaine pendant une période.
L’équipe responsable de la charge de travail prend la décision après avoir examiné les résultats. Si les résultats correspondent à leur tolérance au risque, ils tirent l’image du registre de quarantaine dans leur instance de conteneur. Ce modèle de tirage est plus pratique lorsque ce modèle est utilisé pour soutenir plusieurs équipes responsables de charges de travail avec différentes tolérances au risque de sécurité.
Tous les registres de conteneurs sont couverts par Microsoft Defender for Containers, qui scanne continuellement à la recherche de nouveaux problèmes. Ces problèmes sont affichés dans la gestion des vulnérabilités de Microsoft Defender.
Étapes suivantes
Les recommandations suivantes peuvent s’avérer utiles pendant l’implémentation de ce modèle :
Les recommandations pour sécuriser un cycle de vie de développement fournissent des conseils sur l’utilisation d’unités de code de confiance à travers toutes les étapes du cycle de vie de développement.
Les bonnes pratiques pour une chaîne d’approvisionnement logicielle sécurisée, surtout lorsque vous avez des dépendances NuGet dans votre application.
La documentation Azure Artifacts est une bibliothèque d’informations liée à la gestion des paquets logiciels avec Azure Artifacts.