Consommez des artefacts logiciels tiers dans votre chaîne d’approvisionnement uniquement lorsqu’il est vérifié et marqué comme sûr à utiliser, par des processus bien définis. Ce modèle est un side-car opérationnel pour le processus de développement. Le consommateur de ce modèle appelle ce processus pour vérifier et bloquer l’utilisation de logiciels susceptibles d’introduire des vulnérabilités de sécurité.
Contexte et problème
Les solutions cloud s’appuient souvent sur des logiciels tiers obtenus à partir de sources externes. Les fichiers binaires open source, les images conteneur publiques, les images de système d’exploitation du fournisseur sont quelques exemples de ces types d’artefacts. Tous ces artefacts externes doivent être traités comme non approuvés.
Dans un flux de travail classique, l’artefact est récupéré à partir d’un magasin en dehors de l’étendue de la solution, puis intégré au pipeline de déploiement. Il existe des problèmes potentiels dans cette approche. La source peut ne pas être approuvée, l’artefact peut contenir des vulnérabilités, ou il peut ne pas convenir d’une autre façon à l’environnement du développeur.
Si ces problèmes ne sont pas résolus, l’intégrité des données et les garanties de confidentialité de la solution peuvent être compromises ou provoquer une instabilité en raison d’une 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
Disposer d’un processus qui valide le logiciel pour la sécurité avant de l’introduire dans votre charge de travail. Pendant le processus, chaque artefact subit une rigueur opérationnelle approfondie qui la vérifie dans des conditions spécifiques. Seulement une fois que l’artefact satisfait à ces conditions, le processus le marque comme approuvé .
Le processus de mise en quarantaine est une mesure de sécurité, qui se compose d’une série de points de contrôle utilisés avant qu’un artefact soit consommé. Ces points de contrôle de sécurité veillent à ce qu’un artefact passe d’un état non approuvé à un état approuvé.
Il est important de noter que le processus de quarantaine ne modifie pas la composition de l’artefact. Le processus est indépendant du cycle de développement logiciel et est appelé par les consommateurs, selon les besoins. En tant que consommateur de l’artefact, bloquez l’utilisation des artefacts jusqu’à ce qu’ils soient passés en 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 requête et obtient les artefacts du magasin spécifié.
Un processus de vérification personnalisé est effectué dans le cadre de la mise en quarantaine, ce qui inclut la vérification des contraintes d’entrée et la vérification des attributs, de la source et du type par rapport aux normes établies.
Certaines de ces vérifications de sécurité peuvent être l’analyse des vulnérabilités, la détection des programmes malveillants, et ainsi de suite, sur chaque artefact envoyé.
Les vérifications réelles dépendent du type d’artefact. L’évaluation d’une image de système d’exploitation diffère de l’évaluation d’un package NuGet, par exemple.
Si le processus de vérification réussit, 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 l’expiration dans le rapport au-delà de laquelle le rapport doit être non valide 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 fonction des informations, les consommateurs peuvent choisir d’effectuer des actions pour utiliser l’artefact approuvé. Ces actions sont en dehors de l’étendue 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 approuvée. Votre choix doit être aligné sur les normes approuvées par l’organisation pour les artefacts achetés auprès de fournisseurs tiers. Les fournisseurs doivent être en mesure 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 les artefacts approuvés et non approuvés. Utilisez des contrôles d’identité et de réseau pour restreindre l’accès aux utilisateurs autorisés.
Avoir un moyen fiable d’appeler le processus de quarantaine. Vérifiez que l’artefact n’est pas consommé par inadvertance tant qu’il n’est pas marqué comme approuvé. 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 du développeur, en commitant les modifications apportées à un référentiel GitHub, en ajoutant une image à un registre privé, et ainsi de suite.
Une alternative à l’implémentation d’un modèle de quarantaine consiste à l’externaliser. Il existe des praticiens en quarantaine qui se spécialisent dans la validation des actifs publics comme modèle d’entreprise. É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é ont besoin d’un plus grand contrôle, l’implémentation de votre propre processus est recommandée.
Automatisez le processus d’ingestion d’artefact et également le processus de publication de l’artefact. Étant donné que les tâches de validation peuvent prendre du temps, le processus d’automatisation doit être en mesure de continuer jusqu’à ce que toutes les tâches soient terminées.
Le modèle sert de première opportunité de validation momentanée. La réussite de la mise en quarantaine ne garantit pas que l’artefact reste fiable indéfiniment. L’artefact doit continuer à subir une analyse continue, la validation de pipeline et d’autres vérifications de sécurité de routine qui servent de validations de dernière opportunité avant de promouvoir la mise en production.
Le modèle peut être implémenté par des équipes centrales d’une organisation ou d’une équipe de charge de travail individuelle. S’il existe de nombreuses instances ou variantes du processus de mise en quarantaine, ces opérations doivent être normalisées et centralisées par l’organisation. Dans ce cas, les équipes de charge de travail partagent le processus et tirent parti de la gestion des processus de déchargement.
Quand utiliser ce modèle
Utilisez ce modèle quand :
La charge de travail intègre un artefact développé en dehors de l’étendue de l’équipe de charge de travail. Voici quelques exemples courants :
Artefact Open Container Initiative (OCI) à partir de registres publics tels que DockerHub, GitHub Container Registry, Microsoft Container Registry
Bibliothèque de logiciels ou package à partir de sources publiques telles que la galerie NuGet, l’index de package Python, le référentiel Apache Maven
Package IaC (Infrastructure-as-Code) externe, tel que des modules Terraform, des livres de recettes Community Chef, des modules vérifiés Azure
Une image de système d’exploitation ou un programme d’installation logicielle fourni par le fournisseur
L’équipe de charge de travail considère l’artefact comme un risque qui vaut la peine d’atténuer. L’équipe comprend les conséquences négatives de l’intégration d’artefacts compromis et de la valeur de la quarantaine dans l’assurance d’un environnement approuvé.
L’équipe a une compréhension claire et partagée des règles de validation qui doivent ê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 vérifications de validation est appliqué chaque fois qu’une image de système d’exploitation est ingérée en quarantaine, le processus de vérification global des images de système d’exploitation devient incohérent.
Ce modèle peut ne pas être utile lorsque :
L’artefact logiciel est créé par l’équipe de charge de travail ou une équipe partenaire approuvée.
Le risque de ne pas vérifier que l’artefact est moins coûteux que le coût de la construction et de la maintenance du processus de mise en quarantaine.
Conception de la charge de travail
Un architecte et l’équipe de charge de travail doivent évaluer la façon dont le modèle de quarantaine peut être utilisé dans le cadre des pratiques DevSecOps de la charge de travail. Les principes sous-jacents sont abordés dans les piliers Azure Well-Architected Framework.
| Pilier | Comment ce modèle prend en charge les objectifs piliers |
|---|---|
| La première responsabilité de la validation de la sécurité est servie par le modèle de quarantaine. La validation sur un artefact externe est effectuée dans un environnement segmenté avant d’être consommée par le processus de développement. - cycle de vie de développement sécurisé se :02 - SE :11 Test et validation |
|
| l’excellence opérationnelle permet de fournir qualité de la charge de travail grâce à processus standardisés et à la cohésion de l’équipe. | Le modèle de quarantaine prend en charge les pratiques de déploiement sécurisées (SDP) en s’assurant que les artefacts compromis ne sont pas consommés par la charge de travail, ce qui peut entraîner des violations de sécurité pendant les déploiements d’exposition progressive. - pratiques de développement de logiciels - de test et de validation OE :11 |
Comme pour toute décision de conception, envisagez tout compromis sur les objectifs des autres piliers qui pourraient être introduits avec ce modèle.
Exemple
Cet exemple applique le flux de travail de solution à un scénario dans lequel l’équipe de charge de travail souhaite intégrer des artefacts OCI à partir de registres publics à une instance Azure Container Registry (ACR), qui appartient à l’équipe de charge de travail. L’équipe traite cette instance comme un magasin d’artefacts approuvé.
L’environnement de charge de travail utilise Azure Policy pour Kubernetes pour appliquer la gouvernance. Elle limite les extractions de conteneurs uniquement à partir de leur instance de Registre approuvée. En outre, les alertes Azure Monitor sont configurées pour détecter les importations dans ce registre à partir de sources inattendues.
Une demande d’image externe est effectuée par l’équipe de 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 d’image demandée sont vérifiées.
La requête est stockée dans Azure Cosmos DB.
Point de contrôle de sécurité : une piste d’audit est conservée dans la base de données, en conservant le suivi de la traçabilité et des validations de l’image. Cette piste est également utilisée pour les rapports historiques.
La requête est gérée par un orchestrateur de flux de travail, qui est une fonction Azure durable. L’orchestrateur utilise une approche de collecte de points pour exécuter toutes les validations.
point de contrôle de sécurité : l’orchestrateur a une identité managée avec un accès juste-suffisant pour effectuer les tâches de validation.
L’orchestrateur effectue une demande d’importation de l’image dans la mise en quarantaine d’Azure Container Registry (ACR) considérée comme un magasin non approuvé.
Le processus d’importation sur le Registre de quarantaine obtient l’image du référentiel externe non approuvé. Si l’importation réussit, le registre de quarantaine a une copie locale de l’image pour exécuter des validations.
point de contrôle de sécurité : le registre de mise en quarantaine protège contre la falsification et la consommation de 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 courantes (CVE), l’évaluation de la facture logicielle (SBOM), la détection des programmes malveillants, la signature d’images et d’autres.
L’orchestrateur décide du type de vérification, de l’ordre d’exécution et de l’heure d’exécution. Dans cet exemple, il utilise Azure Container Instance comme exécuteur de tâches et les résultats se trouvent dans la base de données d’audit Cosmos DB. Toutes les tâches peuvent prendre beaucoup de temps.
Point de contrôle de sécurité : cette étape est le cœur du processus de mise en quarantaine qui effectue toutes les vérifications de validation. Le type de vérification peut être des solutions personnalisées, open source ou achetées par le fournisseur.
L’orchestrateur prend une décision. Si l’image réussit toutes les validations, l’événement est noté dans la base de données d’audit, l’image est envoyée au registre approuvé et la copie locale est supprimée du registre de quarantaine. Sinon, l’image est supprimée du registre de quarantaine pour empêcher son utilisation accidentelle.
point de contrôle de sécurité : l’orchestrateur gère la segmentation entre les emplacements de ressources approuvés et non approuvés.
Note
Au lieu de prendre la décision de l’orchestrateur, l’équipe de charge de travail peut assumer cette responsabilité. Dans cette alternative, l’orchestrateur publie les résultats de validation via une API et conserve l’image dans le registre de quarantaine pendant une période donnée.
L’équipe de charge de travail prend la décision après avoir examiné les résultats. Si les résultats répondent à leur tolérance de risque, ils extrayent l’image du référentiel de quarantaine dans leur instance de conteneur. Ce modèle d’extraction est plus pratique lorsque ce modèle est utilisé pour prendre en charge plusieurs équipes de charge de travail avec différentes tolérances de risque de sécurité.
Tous les registres de conteneurs sont couverts par Microsoft Defender pour conteneurs, qui analyse en permanence les problèmes récemment détectés. Ces problèmes sont présentés dans Microsoft Defender Vulnerability Management.
Étapes suivantes
Les conseils suivants peuvent être pertinents lors de l’implémentation de ce modèle :
Recommandations pour la sécurisation d’un cycle de vie de développement fournit des conseils sur l’utilisation d’unités de code approuvées à travers toutes les phases du cycle de vie du développement.
Meilleures pratiques pour une chaîne d’approvisionnement logicielle sécurisée en particulier lorsque vous avez des dépendances NuGet dans votre application.
Protection contre les packages publics malveillants à l’aide d’Azure Artifacts.