Partager via

Contrôle de sécurité : 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 Microsoft avec le modèle de modèle de menace Azure incorporé 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 incorporé 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 incorporé 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 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 sdlC (Software Development Lifecycle) ou le processus de votre entreprise incluent 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) dans lesquels 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érez correctement une nomenclature logicielle (SBOM) en identifiant les dépendances amont requises pour la phase de développement, de génération, 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 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 la base de données advisory.

  • 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 natif de GitHub pour analyser le code source lors de l’approvisionnement du code en externe.
  • Utilisez Microsoft Defender pour le cloud afin d’intégrer l’évaluation des vulnérabilités pour 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 Azure et contexte supplémentaire :

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

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

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Utilisez Software Delivery Shield pour effectuer une analyse de la sécurité de la chaîne d’approvisionnement logicielle de bout en bout. Cela inclut le service Système d’exploitation assuré (logiciel open source) pour l’accès et l’incorporation des packages OSS qui ont été vérifiés et testés par Google, ainsi que les packages Java et Python validés qui sont créés à 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 à Google Cloud Build, Cloud Deploy, Artifact Registry et Artifact Analysis dans le cadre des workflows CI/CD.

Si vous gérez votre code source via la plateforme GitHub, assurez-vous de la sécurité de la chaîne d’approvisionnement logicielle grâce à la fonctionnalité ou aux 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 du code natif de GitHub pour analyser le code source lors de l’approvisionnement du code en externe.
  • Le cas échéant, utilisez Microsoft Defender pour le cloud pour intégrer l’évaluation des vulnérabilités de votre image conteneur dans le workflow 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 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é : Assurez-vous que l’infrastructure et le pipeline DevOps suivent les meilleures pratiques de sécurité dans tous les environnements, y compris vos phases 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 du benchmark de sécurité Microsoft Cloud à vos contrôles de sécurité d’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 erreurs de configuration dans les zones principales d’Azure DevOps telles que Organisation, Projets, Utilisateurs, Pipelines (Build & Release), Connections et Build Agent 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 des contrôles similaires pour sécuriser les niveaux d’autorisation Organisation.
  • Assurez-vous que votre infrastructure DevOps est déployée de manière cohérente entre les projets de développement. Suivez la conformité de votre infrastructure DevOps à grande échelle à l’aide de Microsoft Defender pour le cloud (par exemple, tableau de bord de conformité, Azure Policy, gestion de la posture cloud) ou de 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 « permanent » aux comptes humains tels que les développeurs ou les testeurs en utilisant des fonctionnalités telles que les identifications managées 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 Du benchmark de sécurité cloud Microsoft, notamment la sécurité réseau, la gestion de la posture et des vulnérabilités, et 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 des postures 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 du benchmark de sécurité cloud Microsoft 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é d’AWS Well-architected Framework pour sécuriser vos environnements DevOps dans AWS.
  • Protégez les artefacts et l’infrastructure de prise en charge 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 soutenue de manière cohérente dans tous les projets de développement. Suivez la conformité de votre infrastructure DevOps à grande échelle à l’aide d’AWS Config ou de votre propre solution de case activée de conformité.
  • Utilisez CodeArtifact pour stocker et partager en toute sécurité les packages logiciels utilisés pour le développement d’applications. Vous pouvez utiliser CodeArtifact avec des outils de génération et des gestionnaires de package populaires tels que Maven, Gradle, npm, yarn, pip et twine.
  • Configurez les autorisations d’identité/rôle et les stratégies d’autorisation dans AWS IAM, les services natifs et les outils CI/CD de votre pipeline pour vous assurer que les modifications apportées aux pipelines sont autorisées.
  • Supprimer les clés, les informations d’identification et les secrets du code et des scripts utilisés dans les travaux de workflow CI/CD et les conserver 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 Du benchmark de sécurité cloud Microsoft, notamment la sécurité réseau, la gestion de la posture et des vulnérabilités, et la sécurité des points de terminaison pour sécuriser votre environnement. Utilisez AWS Inspector pour l’analyse des vulnérabilités des vulnérabilités dans l’environnement EC2 ou en conteneur en tant qu’environnement de build.

Remarque : reportez-vous aux sections Journalisation et détection des menaces, DS-7 et Gestion des postures 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 benchmark de sécurité cloud Microsoft à vos contrôles de sécurité d’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 toute mauvaise configuration dans des services tels que Google Cloud Build, Cloud Deploy, Artifact Registry, Connections et Build Agent 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 des contrôles similaires pour sécuriser les niveaux d’autorisation Organisation.
  • Assurez-vous que votre infrastructure DevOps est déployée de manière cohérente entre les projets de développement. Suivez la conformité de votre infrastructure DevOps à grande échelle à l’aide de Google Cloud Security Command Center (par exemple, Tableau de bord de conformité, Stratégie organisationnelle, Enregistrement des menaces individuelles et Identification des configurations incorrectes) ou de vos propres outils de surveillance de la conformité.
  • Configurez les autorisations d’identité/rôle et les stratégies de droits d’utilisation dans les services natifs Cloud Identity/AD 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 « 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 Google.
  • 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 Google Secret Manager.
  • Si vous exécutez des agents de génération/déploiement auto-hébergés, suivez les contrôles Du benchmark de sécurité cloud Microsoft, notamment la sécurité réseau, la gestion de la posture et des vulnérabilités, et 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 permettre 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 PCI-DSS ID(s) 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 gestion 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 à 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 workflow CI/CD. Azure DevOps Pipeline ou GitHub peut intégrer les outils ci-dessous et les 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 à votre pipeline afin que le code source puisse être analysé automatiquement dans votre workflow 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 au 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 (par exemple, 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 workflow CI/CD.

Des services tels que Cloud Build, Cloud Deploy, Artifact Registry prennent en charge l’intégration à Software Delivery Shield et à l’analyse des artefacts, 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 PCI-DSS ID(s) v3.2.1
16.12 SA-11 6.3, 6.5

Principe de sécurité : Vérifiez que les tests de sécurité des applications dynamiques (DAST) font partie des contrôles de gestion dans le 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 runtime 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 prend en charge l’intégration d’outils DAST tiers dans le workflow CI/CD.

Implémentation Azure et contexte supplémentaire :

Conseils AWS : Intégrez DAST à votre pipeline afin que l’application runtime puisse être testée automatiquement dans votre workflow CI/CD défini 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 workflow CI/CD.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Intégrez DAST (comme Cloud Web Security Scanner) à votre pipeline afin que l’application runtime puisse être testée automatiquement dans votre workflow 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 vulnérabilités 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 workflow 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 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 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 en tant que garde-fous par défaut ou décaler vers la gauche avant la phase de déploiement. Veillez en particulier à ce que les contrôles suivants soient en place dans votre processus DevOps : Automatiser 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. Déployez et appliquez des bases de référence de configuration via des images personnalisées, des modèles Azure Resource Manager et/ou Azure Policy configuration invité.

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 conteneurs pour l’évaluation des vulnérabilités des images dans votre Azure Container Registry privée. En outre, vous pouvez utiliser Microsoft Defender pour le cloud pour intégrer les analyses d’images conteneur dans le cadre de vos workflows CI/CD.

Pour les services azure serverless, adoptez des contrôles similaires pour garantir que les contrôles de sécurité « shift-left » (décalage vers la gauche) se placent à 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 organization. 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 référence de configuration sécurisée pour les images AMI EC2 afin d’éliminer les informations d’identification, les autorisations et les packages inutiles. Déployez et appliquez des bases de référence de configurations via des images AMI personnalisées, des modèles CloudFormation et/ou des règles de configuration AWS.

Utilisez AWS Inspector pour l’analyse des vulnérabilités des machines virtuelles et des environnements conteneurisés, en les sécurisant 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é « passent à gauche » à l’étape précédant 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 une machine virtuelle protégée, qui renforce les instances de machine virtuelle. Il assure la sécurité de 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 conteneur 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 les images de nœud de système d’exploitation Container-Optimized. Le service évalue toutes les modifications et les tentatives d’accès à distance pour détecter les attaques au runtime en quasi-temps réel.

Utilisez Artifact Registry pour configurer un stockage d’artefacts de build privé sécurisé afin de contrôler qui peut accéder, afficher ou télécharger des artefacts avec des rôles et des autorisations IAM natifs du Registre, et pour obtenir une durée de fonctionnement cohérente sur l’infrastructure sécurisée et fiable de Google.

Pour les services sans serveur GCP, adoptez des contrôles similaires pour garantir que les contrôles de sécurité « shift-left » (décalage vers la gauche) se placent à 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 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é : Vérifiez 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 et 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 CI/CD GitHub, y compris les travaux de génération, de test et de déploiement, doivent également être surveillés pour identifier les résultats anormaux.

Ingérez les journaux et les événements ci-dessus dans Microsoft Sentinel ou d’autres outils SIEM via un flux de journalisation ou une API pour vous assurer que les incidents de sécurité sont correctement surveillés et triés à des fins de 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 hors production et les outils CI/CD (tels qu’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 (comme AWS CodePipeline, AWS CodeBuild, AWS CodeDeploy, AWS CodeStar) et du workflow CI/CD GitHub, y compris les travaux de génération, de test et de déploiement, doivent également être surveillés pour identifier les résultats anormaux.

Ingérer les journaux et les événements ci-dessus dans AWS CloudWatch, Microsoft Sentinel ou d’autres outils SIEM via un flux de journalisation ou une API pour vous assurer que les incidents de sécurité sont correctement surveillés et triés à des fins de gestion.

Implémentation AWS et contexte supplémentaire :

Conseils GCP : Activez et configurez les fonctionnalités de journalisation d’audit dans les environnements d’outils hors 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 CI/CD GCP (tels que Cloud Build, Google Cloud Deploy, Artifact Registry) et du workflow CI/CD GitHub, y compris les travaux de génération, de test et de déploiement, doivent également être surveillés pour identifier les résultats anormaux.

Ingérer les journaux et les événements ci-dessus dans Microsoft Sentinel, le Centre de commandes Google Cloud Security, Chronicle ou d’autres outils SIEM via un flux de journalisation ou une API pour vous assurer que les incidents de sécurité sont correctement surveillés et triés à des fins de gestion.

Implémentation gcp et contexte supplémentaire :

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