Partager via

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

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 vérifications 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 ID du PCI-DSS 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 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 Azure et contexte supplémentaire :

Conseils AWS : utilisez des outils de modélisation des menaces tels que l’outil de modélisation des menaces 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 AWS et contexte supplémentaire :

Conseils GCP : utilisez des outils de modélisation des menaces tels que l’outil de modélisation des menaces 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 GCP 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 ID du PCI-DSS 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 vie du développement logiciel (SDLC) ou le 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) lorsque 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 au moins inclure les aspects suivants :

  • Gérer correctement une nomenclature logicielle (SBOM) en identifiant les dépendances en amont requises pour la phase de développement, de construction, d’intégration et de déploiement du service/des ressources.
  • 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, assurez la sécurité de la chaîne d’approvisionnement logicielle à l’aide des fonctionnalités ou des outils suivants de GitHub Advanced Security 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 la base de données consultative.

  • 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 de code native de GitHub pour analyser le code source lors de l’approvisionnement externe du code.
  • Utilisez Microsoft Defender pour le cloud pour intégrer l’évaluation des vulnérabilités de votre image de conteneur dans le flux de travail 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 Azure et contexte supplémentaire :

Conseils AWS : si vous utilisez des plateformes CI / CD AWS telles que CodeCommit ou CodePipeline, assurez la sécurité de la chaîne d’approvisionnement logicielle à l’aide de CodeGuru Reviewer pour analyser le code source (pour Java et Python) via les flux de travail CI/CD. Des plates-formes telles que CodeCommit et CodePipeline prennent également en charge les extensions tierces pour mettre en œuvre des contrôles similaires afin d’inventorier, d’analyser et de corriger les composants logiciels tiers et leurs vulnérabilités.

Si vous gérez votre code source via la plateforme GitHub, assurez la sécurité de la chaîne d’approvisionnement logicielle à l’aide de la fonctionnalité ou des outils suivants de GitHub Advanced Security 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 de code native de GitHub pour analyser le code source lors de l’approvisionnement externe du code.
  • Le cas échéant, utilisez Microsoft Defender pour le cloud pour intégrer l’évaluation des vulnérabilités de votre image de conteneur dans le flux de travail CI/CD.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : utilisez Software Delivery Shield pour effectuer une analyse de bout en bout de la sécurité de la chaîne d’approvisionnement logicielle. Cela inclut le service Assured OSS (Open Source Software) permettant d’accéder et d’intégrer les packages OSS qui ont été vérifiés et testés par Google, ainsi que les packages Java et Python validés qui sont construits à l’aide des pipelines sécurisés de Google. Ces packages sont régulièrement analysés, analysés et testés pour détecter les vulnérabilités. Ces fonctionnalités peuvent être intégrées dans Google Cloud Build, Cloud Deploy, Artifact Registry, Artifact Analysis dans le cadre des flux de travail CI/CD.

Si vous gérez votre code source via la plateforme GitHub, assurez la sécurité de la chaîne d’approvisionnement logicielle à l’aide de la fonctionnalité ou des outils suivants de GitHub Advanced Security 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 de code native de GitHub pour analyser le code source lors de l’approvisionnement externe du code.
  • Le cas échéant, utilisez Microsoft Defender pour le cloud pour intégrer l’évaluation des vulnérabilités de votre image de conteneur dans le flux de travail CI/CD.

Implémentation GCP 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 ID du PCI-DSS 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é : assurez-vous que l’infrastructure et le pipeline DevOps respectent les bonnes pratiques de sécurité dans tous les environnements, y compris vos phases de création, 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 du Microsoft Cloud Security Benchmark à vos contrôles de sécurité de l’infrastructure DevOps, hiérarchisez les contrôles suivants :

  • Protégez les artefacts et l’environnement sous-jacent pour vous assurer que les pipelines CI/CD ne deviennent pas des moyens d’insérer du code malveillant. Par exemple, passez en revue votre pipeline CI/CD pour identifier les configurations incorrectes dans les zones principales d’Azure DevOps, telles que l’organisation, les projets, les utilisateurs, les pipelines (build et mise en production), les connexions et l’agent de build pour identifier les configurations incorrectes telles que l’accès ouvert, l’authentification faible, la configuration de connexion non sécurisée, etc. Pour GitHub, utilisez des contrôles similaires pour sécuriser les niveaux d’autorisation de l’organisation.
  • Assurez-vous que votre infrastructure DevOps est déployée de manière cohérente dans tous les projets de développement. Suivez la conformité de votre infrastructure DevOps à grande échelle à l’aide de Microsoft Defender pour le cloud (tel que le tableau de bord de conformité, Azure Policy, Cloud Posture Management) ou vos propres outils de surveillance de la conformité.
  • 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, à l’aide de fonctionnalités telles que les identifications gérées par Azure et 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 travaux de flux de travail CI/CD et conservez-les dans un magasin de clés ou Azure Key Vault.
  • Si vous exécutez des agents de génération/déploiement auto-hébergés, suivez les contrôles Microsoft Cloud Security Benchmark, notamment la sécurité du réseau, la gestion de la posture et des vulnérabilités, ainsi que la sécurité des points de terminaison pour sécuriser votre environnement.

Remarque : Reportez-vous aux sections Journalisation et détection des menaces, DS-7 et Gestion de la posture et des vulnérabilités pour utiliser des services tels qu’Azure Monitor et Microsoft Sentinel afin d’activer la gouvernance, la conformité, l’audit opérationnel et l’audit des risques pour votre infrastructure DevOps.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Dans le cadre de l’application de Microsoft Cloud Security Benchmark aux contrôles de sécurité de votre infrastructure DevOps, tels que GitHub, CodeCommit, CodeArtifact, CodePipeline, CodeBuild et CodeDeploy, hiérarchisez les contrôles suivants :

  • Reportez-vous à ces conseils et au pilier de sécurité AWS Well-architected Framework pour sécuriser vos environnements DevOps dans AWS.
  • Protégez les artefacts et l’infrastructure de support sous-jacente pour vous assurer que les pipelines CI/CD ne deviennent pas des moyens d’insérer du code malveillant.
  • Assurez-vous que votre infrastructure DevOps est déployée et maintenue de manière cohérente dans l’ensemble des projets de développement. Suivez la conformité de votre infrastructure DevOps à grande échelle à l’aide d’AWS Config ou de votre propre solution de vérification de la conformité.
  • Utilisez CodeArtifact pour stocker et partager en toute sécurité des packages logiciels utilisés pour le développement d’applications. Vous pouvez utiliser CodeArtifact avec des outils de construction et des gestionnaires de packages populaires tels que Maven, Gradle, npm, yarn, pip et twine.
  • Configurez les autorisations d’identité/de rôle et les politiques d’autorisation dans AWS IAM, les services natifs et les outils CI/CD dans votre pipeline pour vous assurer que les modifications apportées aux pipelines sont autorisées.
  • Supprimez les clés, les informations d’identification et les secrets du code et des scripts utilisés dans les tâches de flux de travail CI/CD et conservez-les dans le magasin de clés ou AWS KMS
  • Si vous exécutez des agents de génération/déploiement auto-hébergés, suivez les contrôles Microsoft Cloud Security Benchmark, notamment la sécurité du réseau, la gestion de la posture et des vulnérabilités, ainsi que la sécurité des points de terminaison pour sécuriser votre environnement. Utilisez AWS Inspector pour l’analyse des vulnérabilités dans EC2 ou l’environnement conteneurisé en tant qu’environnement de génération.

Remarque : Reportez-vous aux sections Journalisation et détection des menaces, DS-7 et Gestion de la posture et des vulnérabilités pour utiliser des services tels qu’AWS CloudTrail, CloudWatch et Microsoft Sentinel afin d’activer la gouvernance, la conformité, l’audit opérationnel et l’audit des risques pour votre infrastructure DevOps.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Dans le cadre de l’application du Microsoft Cloud Security Benchmark à vos contrôles de sécurité de l’infrastructure DevOps, hiérarchisez les contrôles suivants :

  • Protégez les artefacts et l’environnement sous-jacent pour vous assurer que les pipelines CI/CD ne deviennent pas des moyens d’insérer du code malveillant. Par exemple, examinez votre pipeline CI/CD pour identifier toute erreur de configuration dans des services tels que Google Cloud Build, Cloud Deploy, Artifact Registry, Connections et Build Agent afin d’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 des contrôles similaires pour sécuriser les niveaux d’autorisation de l’organisation.
  • Assurez-vous que votre infrastructure DevOps est déployée de manière cohérente dans tous les projets de développement. Suivez la conformité de votre infrastructure DevOps à grande échelle à l’aide du centre de commande de sécurité Google Cloud (tel que le tableau de bord de conformité, la politique organisationnelle, l’enregistrement des menaces individuelles et l’identification des erreurs de configuration) ou de vos propres outils de surveillance de la conformité.
  • Configurez les autorisations d’identité/de rôle et les stratégies de droits dans les services natifs Cloud Identity/AD et les outils CI/CD dans 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 identifiants gérés par Google.
  • Supprimez les clés, les informations d’identification et les secrets du code et des scripts utilisés dans les tâches de flux de travail CI/CD et conservez-les dans un magasin de clés ou Google Secret Manager.
  • Si vous exécutez des agents de génération/déploiement auto-hébergés, suivez les contrôles Microsoft Cloud Security Benchmark, notamment la sécurité du réseau, la gestion de la posture et des vulnérabilités, ainsi que la sécurité des points de terminaison pour sécuriser votre environnement.

Remarque : Reportez-vous aux sections Journalisation et détection des menaces, DS-7 et Gestion de la posture et des vulnérabilités pour utiliser des services tels qu’Azure Monitor et Microsoft Sentinel ou la suite d’opérations de Google Cloud et Chronicle SIEM et SOAR pour activer la gouvernance, la conformité, l’audit opérationnel et l’audit des risques pour votre infrastructure DevOps.

Implémentation GCP 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 ID du PCI-DSS v3.2.1
16.12 SA-11 6.3, 6.5

Principe de sécurité : assurez-vous que les tests de sécurité des applications statiques (SAST), les tests flous, les tests interactifs, les tests d’applications mobiles font partie des contrôles de contrôle dans le flux de travail 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 dans votre pipeline (par exemple, dans votre infrastructure en tant que modèle de code) afin que le code source puisse être analysé automatiquement dans votre flux de travail CI/CD. Azure DevOps Pipeline ou GitHub peuvent intégrer les outils ci-dessous et des outils SAST tiers dans le flux de travail.

  • GitHub CodeQL pour l’analyse du code source.
  • Microsoft BinSkim Binary Analyzer pour l’analyse binaire Windows et *nix.
  • Analyseur d’informations d’identification Azure DevOps (extension Microsoft Security DevOps) et analyse des secrets natifs GitHub pour l’analyse des informations d’identification dans le code source.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Intégrez SAST dans votre pipeline afin que le code source puisse être analysé automatiquement dans votre flux de travail CI/CD.

Si vous utilisez AWS CodeCommit, utilisez AWS CodeGuru Reviewer pour l’analyse du code source Python et Java. AWS Codepipeline peut également prendre en charge l’intégration d’outils SAST tiers dans le pipeline de déploiement de code.

Si vous utilisez GitHub, les outils ci-dessous et les outils SAST tiers peuvent être intégrés dans le flux de travail.

  • GitHub CodeQL pour l’analyse du code source.
  • Microsoft BinSkim Binary Analyzer pour l’analyse binaire Windows et *nix.
  • Analyse des secrets natifs GitHub pour l’analyse des informations d’identification dans le code source.
  • AWS CodeGuru Reviewer pour l’analyse du code source Python et Java.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : intégrez SAST (tel que Software Delivery Shield, Artifact Analysis) dans votre pipeline (par exemple, dans votre infrastructure en tant que modèle de code) afin que le code source puisse être analysé automatiquement dans votre flux de travail CI/CD.

Des services tels que Cloud Build, Cloud Deploy, Artifact Registry prennent en charge l’intégration avec Software Delivery Shield et Artifact Analysis, qui peuvent analyser le code source et d’autres artefacts dans le flux de travail CI/CD.

Implémentation GCP 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 ID du PCI-DSS v3.2.1
16.12 SA-11 6.3, 6.5

Principe de sécurité : assurez-vous que les tests de sécurité dynamique des applications (DAST) font partie des contrôles de contrôle dans le flux de travail 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 dans votre pipeline afin que l’application d’exécution puisse être testée automatiquement dans votre ensemble de flux de travail CI/CD 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 prend en charge l’intégration d’outils DAST tiers dans le flux de travail CI/CD.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : intégrez DAST dans votre pipeline afin que l’application d’exécution puisse être testée automatiquement dans votre ensemble de flux de travail CI/CD dans AWS CodePipeline ou GitHub. Les tests de pénétration automatisés (avec validation manuelle assistée) doivent également faire partie du DAST.

AWS CodePipeline ou GitHub prend en charge l’intégration d’outils DAST tiers dans le flux de travail CI/CD.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : intégrez DAST (tel que Cloud Web Security Scanner) dans votre pipeline afin que l’application d’exécution puisse être testée automatiquement dans votre flux de travail CI/CD défini dans les services tels que Google Cloud Build, Cloud Deploy ou GitHub. Cloud Web Security Scanner peut être utilisé pour identifier les failles de sécurité dans vos applications Web de charge de travail hébergées sur App Engine, Google Kubernetes Engine (GKE) et Compute Engine. Les tests de pénétration automatisés (avec validation manuelle assistée) doivent également faire partie du DAST.

Google Cloud Build, Google Cloud Deploy, Artifact Registry et GitHub prennent également en charge l’intégration d’outils DAST tiers dans le flux de travail CI/CD.

Implémentation GCP 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 ID du PCI-DSS 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, au stade du développement, des tests et du déploiement. Utilisez Microsoft Cloud Security Benchmark pour évaluer les contrôles (tels que la sécurité réseau, la gestion des identités, l’accès privilégié, etc.) qui peuvent être définis comme garde-fous par défaut ou décalés vers la gauche avant l’étape de déploiement. En particulier, assurez-vous que les contrôles suivants sont en place dans votre processus DevOps :- Automatisez le déploiement à l’aide d’Azure ou d’outils tiers dans le flux de travail CI/CD, la gestion de l’infrastructure (infrastructure en tant que code) et les tests pour réduire l’erreur humaine 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. Déployez et appliquez des bases de configuration via des images personnalisées, des modèles Azure Resource Manager et/ou une configuration d’invité Azure Policy.

Conseils pour les services Azure Container :

  • Utilisez Azure Container Registry (ACR) pour créer votre registre de conteneurs privé où l’accès granulaire peut être restreint via Azure RBAC, de sorte que seuls les services et comptes autorisés peuvent accéder aux conteneurs dans le registre privé.
  • Utilisez Defender pour les conteneurs pour l’évaluation de la vulnérabilité des images dans votre registre de conteneurs Azure privé. En outre, vous pouvez utiliser Microsoft Defender pour le cloud pour intégrer les analyses d’images de conteneur dans le cadre de vos flux de travail CI/CD.

Pour les services serverless Azure, adoptez des contrôles similaires pour garantir que les contrôles de sécurité sont placés en fonction de la fonction Shift Left (Maj-gauche) à l’étape précédant le déploiement.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Utilisez Amazon Elastic Container Registry pour partager et contrôler l’accès à vos images par différents utilisateurs et rôles au sein de votre organisation. Et utilisez AWS IAM pour vous assurer que seuls les utilisateurs autorisés peuvent accéder à vos images personnalisées.

Définissez les bases de configuration sécurisées pour les images d’AMI EC2 afin d’éliminer les informations d’identification, les autorisations et les packages inutiles. Déployez et appliquez des bases de configuration via des images AMI personnalisées, des modèles CloudFormation et/ou des règles AWS Config.

Utilisez AWS Inspector pour analyser les vulnérabilités des machines virtuelles et des environnements conteneurisés, en les protégeant contre les manipulations malveillantes.

Pour les services sans serveur AWS, utilisez AWS CodePipeline conjointement avec AWS AppConfig pour adopter des contrôles similaires afin de garantir que les contrôles de sécurité se déplacent vers la gauche avant le déploiement.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Google Cloud inclut des contrôles pour protéger vos ressources de calcul et les ressources de conteneur Google Kubernetes Engine (GKE). Google inclut la machine virtuelle protégée, qui renforce les instances de machine virtuelle. Il assure la sécurité du démarrage, surveille l’intégrité et utilise le module vTPM (Virtual Trusted Platform Module).

Utilisez Google Cloud Artifact Analysis pour analyser les vulnérabilités dans les images de conteneurs ou de système d’exploitation, ainsi que d’autres types d’artefacts à la demande ou automatiquement dans vos pipelines. Utilisez la détection des menaces de conteneur pour surveiller en permanence l’état des images de Container-Optimized nœud du système d’exploitation. Le service évalue toutes les modifications et les tentatives d’accès à distance pour détecter les attaques d’exécution en temps quasi réel.

Utilisez Artifact Registry pour configurer un stockage d’artefacts privé sécurisé afin de garder le contrôle sur les personnes autorisées à accéder, afficher ou télécharger des artefacts avec des rôles et des autorisations IAM natifs du registre, et pour obtenir un temps de fonctionnement constant sur l’infrastructure sécurisée et fiable de Google.

Pour les services serverless GCP, adoptez des contrôles similaires pour garantir que les contrôles de sécurité se déplacent vers la gauche de l’étape précédant le déploiement.

Implémentation GCP 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 ID du PCI-DSS 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 votre étendue de journalisation et de surveillance inclut les environnements hors production et les éléments de flux de travail CI/CD utilisés dans DevOps (et 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 les environnements d’outils CI/CD hors production (tels qu’Azure DevOps et GitHub) utilisés tout au long du processus DevOps.

Les événements générés à partir d’Azure DevOps et du workflow GitHub CI/CD, y compris les travaux de génération, de test et de déploiement, doivent également être surveillés pour identifier tout résultat anormal.

Ingérez les journaux et les événements ci-dessus dans Microsoft Sentinel ou d’autres outils SIEM par le biais d’un flux de journalisation ou d’une API pour vous assurer que les incidents de sécurité sont correctement surveillés et triés pour la gestion.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Activez et configurez AWS CloudTrail pour les fonctionnalités de journalisation d’audit dans les environnements de non-production et d’outils CI/CD (tels que AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, AWS CodeStar) utilisés tout au long du processus DevOps.

Les événements générés à partir des environnements CI / CD AWS (tels que AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, AWS CodeStar) et du flux de travail CI/CD GitHub, y compris les tâches de génération, de test et de déploiement, doivent également être surveillés pour identifier tout résultat anormal.

Ingérez les journaux et les événements ci-dessus dans AWS CloudWatch, Microsoft Sentinel ou d’autres outils SIEM par le biais d’un flux de journalisation ou d’une API pour vous assurer que les incidents de sécurité sont correctement surveillés et triés pour être traités.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : activez et configurez les fonctionnalités de journalisation d’audit dans les environnements d’outils de non-production et CI/CD pour des produits tels que Cloud Build, Google Cloud Deploy, Artifact Registry et GitHub, qui peuvent être utilisés tout au long du processus DevOps.

Les événements générés à partir des environnements GCP CI/CD (tels que Cloud Build, Google Cloud Deploy, Artifact Registry) et du workflow GitHub CI/CD, y compris les tâches de génération, de test et de déploiement, doivent également être surveillés pour identifier tout résultat anormal.

Ingérez les journaux et les événements ci-dessus dans Microsoft Sentinel, Google Cloud Security Command Center, Chronicle ou d’autres outils SIEM par le biais d’un flux de journalisation ou d’une API pour vous assurer que les incidents de sécurité sont correctement surveillés et triés pour être traités.

Implémentation GCP et contexte supplémentaire :

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