Contrôle de sécurité v3 : sécurité DevOps

  • Article

La sécurité DevOps couvre les contrôles liés à l'ingénierie et aux opérations de sécurité dans les processus DevOps, y compris le déploiement de contrôles de sécurité critiques (tels que les tests statiques de sécurité des applications, la gestion des vulnérabilités) avant la phase de déploiement afin de garantir la sécurité tout au long du processus DevOps ; elle inclut également des sujets communs comme la modélisation des menaces et la sécurité dans l'approvisionnement en logiciels.

DS-1 : Effectuer une modélisation des menaces

ID des contrôles CIS v8 ID NIST SP 800-53 r4 PCI-DSS ID(s) v3.2.1
16.10, 16.14 SA-15 6.5, 12.2

Principe de sécurité : Effectuez une modélisation des menaces pour identifier les menaces potentielles et énumérer les contrôles d'atténuation. Assurez-vous que votre modélisation des menaces répond aux objectifs suivants :

  • Sécurisez vos applications et services au stade de l'exécution de la production.
  • Sécurisez les artefacts, le pipeline CI/CD sous-jacent et les autres environnements d'outils utilisés pour la génération, les tests et le déploiement.

La modélisation des menaces doit au moins inclure les aspects suivants :

  • Définir les exigences de sécurité de l'application. Vérifier que ces exigences sont correctement traitées dans la modélisation des menaces.
  • Analyser les composants et connexions de données de l’application, ainsi que leurs relations. Vérifier que cette analyse comprend également les connexions en amont et en aval en dehors de la portée de votre application.
  • Répertorier les menaces potentielles et les vecteurs d’attaque qui peuvent être exposés à vos composants d’application, connexions de données, services en amont et en aval.
  • Identifier les contrôles de sécurité applicables qui peuvent être utilisés pour atténuer les menaces énumérées et identifier les lacunes des contrôles (par exemple, les vulnérabilités de sécurité) qui peuvent nécessiter des plans de traitement supplémentaires.
  • Énumérer et concevoir les contrôles qui peuvent atténuer les vulnérabilités identifiées.

Conseils Azure: Utilisez des outils de modélisation des menaces tels que l'outil de modélisation des menaces de Microsoft avec le modèle de modèle de menace Azure intégré pour piloter votre processus de modélisation des menaces. Utilisez le modèle STRIDE pour énumérer les menaces internes et externes et identifier les contrôles applicables. Assurez-vous que le processus de modélisation des menaces inclut les scénarios de menace dans le processus DevOps, notamment l'injection de code malveillant par le biais d'un référentiel d'artefacts non sécurisé avec une stratégie de contrôle d'accès mal configurée.

Si l'utilisation d'un outil de modélisation des menaces n'est pas applicable, vous devez, au minimum, utiliser un processus de modélisation des menaces basé sur un questionnaire pour identifier les menaces.

Veillez à ce que les résultats de la modélisation ou de l'analyse des menaces soient consignés et mis à jour en cas de changement majeur de l'impact sur la sécurité de votre application ou du paysage des menaces.

Implémentation et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :

DS-2 : Garantir la sécurité de la chaîne d’approvisionnement logicielle

ID des contrôles CIS v8 ID NIST SP 800-53 r4 PCI-DSS ID(s) v3.2.1
16.4, 16.6, 16.11 SA-12, SA-15 6.3, 6.5

Principe de sécurité : Assurez-vous que le cycle de développement logiciel (SDLC) ou processus de votre entreprise inclut un ensemble de contrôles de sécurité pour régir les composants logiciels internes et tiers (y compris les logiciels propriétaires et open source) où vos applications ont des dépendances. Définissez des critères de déclenchement pour empêcher l’intégration et le déploiement de composants vulnérables ou malveillants dans l’environnement.

Les contrôles de sécurité de la chaîne d’approvisionnement logicielle doivent inclure au moins les éléments suivants :

  • Identifiez les dépendances en amont requises lors de la phase de développement, de génération, d’intégration et de déploiement.
  • Inventoriez et suivez les composants logiciels internes et tiers à la recherche d’une vulnérabilité connue lorsqu’un correctif est disponible en amont.
  • Évaluez les vulnérabilités et les logiciels malveillants dans les composants logiciels à l’aide de tests d’application statiques et dynamiques pour les vulnérabilités inconnues.
  • Vérifiez que les vulnérabilités et les logiciels malveillants sont atténués à l’aide de l’approche appropriée. Il peut s’agir d’un code source local ou d’un correctif en amont, de l’exclusion des fonctionnalités et/ou de l’application de contrôles de compensation, si l’atténuation directe n’est pas disponible.

Si des composants tiers fermés sont utilisés dans votre environnement de production, votre visibilité au niveau de la sécurité peut être limitée. Vous devez prendre en compte d’autres contrôles tels que le contrôle d’accès, l’isolement réseau et la sécurité des points de terminaison pour réduire l’impact si une activité ou une vulnérabilité malveillante est associée au composant.

Conseils Azure : Pour la plateforme GitHub, vérifiez la sécurité de la chaîne d’approvisionnement par le biais des outils ou des fonctionnalités GitHub Advanced Security suivants ou de la fonctionnalité native de GitHub :

  • Utilisez Dependency Graph pour analyser, inventorier et identifier toutes les dépendances de votre projet et les vulnérabilités associées via Advisory Database.
  • Utilisez Dependabot pour vérifier que la dépendance vulnérable est suivie et corrigée, puis que votre référentiel reçoit automatiquement les dernières versions des packages et des applications dont il dépend.
  • Utilisez la fonctionnalité d'analyse du code native de GitHub pour analyser le code source lorsque celui-ci provient d’une source externe.
  • Utilisez Azure Defender pour le cloud pour intégrer l'évaluation de la vulnérabilité de votre image conteneur dans le workflow CI/CD.

Pour Azure DevOps, vous pouvez utiliser des extensions tierces afin d’implémenter des contrôles similaires pour inventorier, analyser et corriger les composants logiciels tiers et leurs vulnérabilités.

Implémentation et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :

DS-3 : Sécurisation de l’infrastructure DevOps

ID des contrôles CIS v8 ID NIST SP 800-53 r4 PCI-DSS ID(s) v3.2.1
16.7 CM-2, CM-6, AC-2, AC-3, AC-6 2.2, 6.3, 7.1

Principe de sécurité : Veillez à ce que l'infrastructure DevOps et le pipeline respectent les meilleures pratiques de sécurité dans tous les environnements, y compris les étapes de génération, de test et de production. Cela comprend généralement les contrôles de sécurité pour l’étendue suivante :

  • Référentiels d'artefacts qui stockent le code source, les paquets et images construits, les artefacts du projet et les données commerciales.
  • Serveurs, services et outils qui hébergent des pipelines CI/CD.
  • Configuration du pipeline CI/CD.

Conseils Azure : Dans le cadre de l'application d'Azure Security Benchmark aux contrôles de sécurité de votre infrastructure DevOps, donnez la priorité aux contrôles suivants :

  • Protégez les artefacts et l'environnement sous-jacent pour s'assurer que les pipelines CI/CD ne deviennent pas des points d'insertion de code malveillant. Par exemple, passez en revue votre pipeline CI/CD pour identifier toute mauvaise configuration dans les principaux domaines d’Azure DevOps, tels que l’organisation, les projets, les utilisateurs, les pipelines (build & release), les connexions et l’agent de build pour identifier les erreurs de configuration telles que l’accès ouvert, l’authentification faible, la configuration de connexion non sécurisée, etc. Pour GitHub, utilisez les contrôles similaires pour sécuriser les niveaux d’autorisation de l’organisation
  • Configurez les autorisations d'identité/rôle et les stratégies d'habilitation dans Azure AD, les services natifs et les outils CI/CD de votre pipeline pour vous assurer que les modifications apportées aux pipelines sont autorisées.
  • Évitez de fournir un accès privilégié « permanent » aux comptes humains tels que les développeurs ou les testeurs en utilisant des fonctionnalités telles que les identifications gérées par Azure, l'accès juste à temps.
  • Supprimez les clés, les informations d’identification et les secrets du code et des scripts utilisés dans les tâches de workflow CI/CD, puis conservez-les dans le magasin de clés ou Azure Key Vault.
  • Si vous exécutez des agents de build/déploiement auto-hébergés, suivez les contrôles Azure Security Benchmark incluant la sécurité du réseau, la gestion de la posture et de la vulnérabilité, et la sécurité des points de terminaison pour sécuriser votre environnement.

Implémentation et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :

DS-4 : Intégrer des tests de sécurité d’application statiques dans le pipeline DevOps

ID des contrôles CIS v8 ID NIST SP 800-53 r4 PCI-DSS ID(s) v3.2.1
16.12 SA-11 6.3, 6.5

Principe de sécurité : Assurez-vous que les tests statiques de sécurité des applications (SAST) sont inclus dans les contrôles de déclenchement du workflow CI/CD. Le déclenchement peut être défini sur la base des résultats des tests pour empêcher les paquets vulnérables d'être validés dans le référentiel, d'être intégrés aux paquets ou d'être déployés dans la production.

Conseils Azure : Intégrez SAST à votre pipeline afin que le code source puisse être analysé automatiquement dans votre workflow CI/CD. Azure DevOps Pipeline ou GitHub peuvent intégrer les outils ci-dessous et des outils SAST tiers dans le workflow.

  • GitHub CodeQL pour l’analyse du code source.
  • Microsoft BinSkim Binary Analyzer pour l’analyse binaire Windows et *nix.
  • Azure DevOps Credential Scanner et l’analyse de secret native GitHub pour la recherche d'informations d'identification dans le code source.

Implémentation et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :

DS-5: Intégrer des tests de sécurité d’application dynamiques dans le pipeline DevOps

ID des contrôles CIS v8 ID NIST SP 800-53 r4 PCI-DSS ID(s) v3.2.1
16.12 SA-11 6.3, 6.5

Principe de sécurité : Assurez-vous que les tests dynamiques de sécurité des applications (DAST) sont inclus dans les contrôles de déclenchement du workflow CI/CD. Le déclenchement peut être défini sur la base des résultats des tests afin d'empêcher l'intégration de la vulnérabilité aux paquets ou le déploiement dans la production.

Conseils Azure : Intégrez DAST à votre pipeline afin que l'application d'exécution puisse être testée automatiquement dans votre workflow CI/CD défini dans Azure DevOps ou GitHub. Les tests de pénétration automatisés (avec validation manuelle assistée) doivent également faire partie du DAST.

Azure DevOps Pipeline ou GitHub permettent d'intégrer des outils DAST tiers au workflow CI/CD.

Implémentation et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :

DS-6 : Appliquer la sécurité de la charge de travail tout au long du cycle de vie de DevOps

ID des contrôles CIS v8 ID NIST SP 800-53 r4 PCI-DSS ID(s) v3.2.1
7.5, 7.6, 7.7, 16.1, 16.7 CM-2, CM-6, AC-2, AC-3, AC-6 6.1, 6.2, 6.3

Principe de sécurité: Assurez-vous que la charge de travail est sécurisée tout au long du cycle de vie dans les phases de développement, de test et de déploiement. Utilisez Azure Security Benchmark pour évaluer les contrôles (notamment la sécurité du réseau, la gestion des identités, l'accès privilégié, etc.) qui peuvent être définis comme des garde-fous par défaut ou être déplacés vers la gauche avant la phase de déploiement. En particulier, assurez-vous que les contrôles suivants sont en place dans votre processus DevOps :

  • Automatisez le déploiement en utilisant des outils Azure ou tiers dans le workflow CI/CD, la gestion de l'infrastructure (infrastructure en tant que code) et les tests pour réduire les erreurs humaines et la surface d'attaque.
  • Assurez-vous que les machines virtuelles, les images conteneur et les autres artefacts sont protégés contre les manipulations malveillantes.
  • Analyser les artefacts de la charge de travail (en d'autres termes, les images conteneur, les dépendances, les analyses SAST et DAST) avant le déploiement dans le workflow CI/CD
  • Déployez des capacités d'évaluation des vulnérabilités et de détection des menaces dans l'environnement de production et utiliser ces capacités en permanence pendant l'exécution.

Conseils Azure : Conseils pour les machines virtuelles Azure :

  • Une galerie Azure Shared Image Gallery vous permet de partager et de contrôler l’accès à vos images par différents utilisateurs, principaux de service ou groupes AD au sein de votre organisation. Utilisez le contrôle d’accès en fonction du rôle Azure (RBAC Azure) pour garantir que seuls les utilisateurs autorisés peuvent accéder à vos images personnalisées.
  • Définissez les bases de configuration sécurisées pour les machines virtuelles afin d'éliminer les informations d'identification, les autorisations et les paquets inutiles. Par le biais d'images personnalisées, d'un modèle Azure Resource Manager et/ou d'une configuration d'invité Azure Policy pour déployer et appliquer ces stratégies dans la configuration de base.

Conseils pour les services Azure Container :

  • Utilisez Azure Container Registry (ACR) pour créer votre registre de conteneurs privé où un accès granulaire peut être restreint par Azure RBAC, de sorte que seuls les services et les comptes autorisés peuvent accéder aux conteneurs dans le registre privé.
  • Utilisez Defender pour Azure Container Registry afin d’évaluer la vulnérabilité des images de votre registre privé Azure Container Registry. Vous pouvez également utiliser Azure Defender pour le cloud pour intégrer l'analyse des images conteneur dans le cadre de vos workflows CI/CD.

Pour les services sans serveur Azure, adoptez les mêmes contrôles afin de garantir que les contrôles de sécurité sont laissés au stade précédant le déploiement.

Implémentation et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :

DS-7 : Activer la journalisation et surveillance dans DevOps

ID des contrôles CIS v8 ID NIST SP 800-53 r4 PCI-DSS ID(s) v3.2.1
8.2, 8.5, 8.9, 8.11 AU-3, AU-6, AU-12, SI-4 10.1, 10.2, 10.3, 10.6

Principe de sécurité : Assurez-vous que le champ d'application de la journalisation et de la surveillance inclut les environnements de non-production et les éléments du workflow CI/CD utilisés dans le cadre de DevOps (et de tout autre processus de développement). Les vulnérabilités et les menaces ciblant ces environnements peuvent entraîner des risques significatifs pour votre environnement de production, si elles ne sont pas surveillées correctement. Les événements de la build CI/CD, le workflow de test et de déploiement doivent également être analysés pour identifier les écarts dans les tâches du workflow CI/CD.

Conseils Azure : Activez et configurez les fonctionnalités de journalisation d’audit dans des environnements de type non-production CI/CD (comme Azure DevOps et GitHub) utilisés dans le processus DevOps.

Les événements des projets Azure DevOps et GitHub CI/CD pour les tâches de génération, de test et de déploiement doivent également être analysés pour identifier toute exception résultant des tâches CI/CD.

Intégrez les journaux et les événements ci-dessus à Azure Sentinel ou d’autres outils SIEM par le biais du streaming ou de l'API afin de garantir que les incidents de sécurité sont correctement surveillés et triés pour être traités.

Suivez la directive Azure Security Benchmark - Logging and Threat Detection pour implémenter vos contrôles de journalisation et de surveillance de la charge de travail.

Implémentation et contexte supplémentaire :

Parties prenantes de la sécurité des clients (En savoir plus) :