Détecter les vulnérabilités d’un cluster régulé par AKS pour PCI DSS 3.2.1 (partie 5 sur 9)

Cet article décrit les considérations relatives à un cluster Azure Kubernetes Service (AKS) configuré conformément à la norme de sécurité des données du secteur des cartes de paiement (PCI-DSS 3.2.1).

Cet article fait partie d’une série. Lisez l’introduction.

Comme n’importe quelle solution cloud, une charge de travail PCI est soumise à des menaces liées au réseau, à l’identité et aux données. Parmi les exemples courants de sources qui tirent parti des vulnérabilités du système et de la charge de travail figurent les virus ou les mises à jour logicielles qui génèrent des résultats indésirables. Détectez les menaces tôt et veillez à les éliminer à temps. Générez des alertes critiques pour les activités de charge de travail et étendez ces alertes aux principaux processus système. L’antivirus ou les outils de supervision de l’intégrité des fichiers doivent toujours être en cours d’exécution. Élaborez un plan de réponse adapté et une équipe qui examine les alertes et entreprend des actions.

Tenir à jour un programme de gestion des vulnérabilités

Condition requise 5 Protéger tous les systèmes contre les programmes malveillants et mettre à jour régulièrement les logiciels ou programmes antivirus

Prise en charge des fonctionnalités AKS

AKS ne se comporte pas comme un hôte d’application traditionnel. Les machines virtuelles de nœuds dans un cluster AKS ont une exposition limitée et sont conçues pour ne pas être accessibles directement. Étant donné que les machines virtuelles de nœuds n’équivalent pas aux machines virtuelles traditionnelles, vous ne pouvez pas utiliser les outils de machine virtuelle courants. Les recommandations de cette section sont donc appliquées via des constructions Kubernetes natives. L’application de ces conditions requises directement au niveau de la machine virtuelle peut entraîner une non prise en charge de votre cluster.

Vous devez déployer le logiciel anti-programme malveillant de votre choix dans les DaemonSets qui s’exécuteront dans un pod sur chaque nœud.

Vos responsabilités

Assurez-vous que le logiciel est spécialisé dans Kubernetes et les conteneurs. Il existe plusieurs options de logiciel tiers. Prisma Cloud et Aquasec figurent parmi les choix courants. Il existe également des options open source telles que Falco. Il vous incombe de vous assurer que des processus sont en place pour vous assurer que le logiciel tiers est à jour. En outre, la surveillance et la génération d’alertes des solutions relèvent de votre responsabilité.

Condition requise 6 Développer et maintenir des systèmes et des applications sécurisés

Prise en charge des fonctionnalités AKS

À l’instar d’autres services Azure, AKS suit les processus Microsoft SDL (Security Development Lifecycle) pour la sécurité tout au long des phases du processus de développement. Les différents composants sont analysés à partir des premières phases de développement et les failles de sécurité sont comblées le plus tôt possible.

Les images AKS suivent une approche de contrat de niveau de service FedRAMP, qui nécessite que les vulnérabilités dans les images soient corrigées dans les 30 jours. Pour appliquer cette spécification, toutes les images sont nettoyées via un pipeline DevSecOps.

Chaque semaine, AKS fournit de nouvelles images pour les pools de nœuds. Il vous incombe de les appliquer pour garantir l’application des correctifs et la mise à jour des nœuds Worker des groupes de machines virtuelles identiques. Pour plus d’informations, consultez mise à niveau d’image de nœud Azure Kubernetes Service (AKS).

Pour le plan de contrôle AKS, AKS installe ou met à niveau les correctifs de sécurité. Ils sont miss à jour toutes les 24 heures.

Le plan de contrôle AKS et les nœuds de travail sont renforcés en utilisant les référentiels du Center for Internet Security (CIS), notamment AKS CIS, Ubuntu CIS et Windows CIS.

AKS s’intègre à Azure Container Registry. Utilisez Azure Container Registry avec des fonctionnalités de scan continu dans Microsoft Defender pour le cloud pour identifier les images et applications vulnérables à divers niveaux de risque. Pour plus d’informations sur l’analyse des images et le contrôle des risques, consultez Microsoft Defender pour les conteneurs.

Vos responsabilités

Condition requise 5.1

Déployez un logiciel antivirus sur tous les systèmes fréquemment affectés par un logiciel malveillant, en particulier les ordinateurs personnels et les serveurs.

Vos responsabilités

Il vous incombe de protéger la charge de travail, l’infrastructure et les pipelines de déploiement en choisissant un logiciel anti-programme malveillant approprié.

Étant donné que l’accès aux machines virtuelles (VM) des nœuds AKS est restreint, protégez le système à chaque couche où des logiciels malveillants pourraient être injectés dans les machines virtuelles des nœuds. Incluez la détection et la prévention sur les nœuds de cluster, les images conteneur et les interactions d’exécution avec le serveur d’API Kubernetes. En plus du cluster, protégez ces composants qui interagissent avec le cluster et qui peuvent avoir un logiciel antivirus installé de manière traditionnelle :

• Serveurs de rebond
• Agents de build

Alignez vos activités d’analyse avec le Security Development Lifecycle (SDL). Suivre le SDL permet de garantir que l’analyse des différents composants de l’architecture commence dans les premières étapes du développement et que les lacunes de sécurité sont couvertes le plus tôt possible.

Condition requise 5.1.1

Assurez-vous que les programmes antivirus sont capables de détecter, supprimer et protéger contre tous les types connus de logiciels malveillants.

Vos responsabilités

En savoir plus sur l’ensemble de fonctionnalités de chaque offre de logiciels et la profondeur de l’analyse qu’elle peut effectuer. Le logiciel doit bloquer les menaces courantes et surveiller les nouvelles menaces. Assurez-vous que le logiciel est régulièrement mis à jour, testé et remplacé s’il n’est pas approprié. Considérez les logiciels développés par des fournisseurs réputés.

• Outils de surveillance détectant les vulnérabilités de cluster.

  Dans AKS, vous ne pouvez pas exécuter directement des solutions de machine virtuelle traditionnelles basées sur des agents sur des machines virtuelles de nœud. Vous devez déployer le logiciel anti-programme malveillant dans les DaemonSets qui s’exécuteront dans un pod sur chaque nœud.

  Choisissez des logiciels spécialisés pour Kubernetes et les charges de travail conteneurisées. Il existe plusieurs options de logiciel tiers. Prisma Cloud et Aquasec figurent parmi les choix courants. Il existe également des options open source telles que Falco.

  Une fois déployées, elles s’exécutent en tant qu’agents dans le cluster qui analyse tous les pools de nœuds utilisateur et système. Même si AKS utilise des pools de nœuds système pour ses fichiers binaires système de runtime, le calcul sous-jacent reste de votre ressort.

  L’objectif de l’exécution de l’agent est de détecter les activités inhabituelles du cluster. Par exemple, une application tente-t-elle d’appeler le serveur d’API ? Certaines solutions génèrent un journal des appels d’API entre les pods, génèrent des rapports et génèrent des alertes. Veillez à consulter ces journaux et à prendre les mesures nécessaires.

  Installez les agents de sécurité immédiatement après le démarrage du cluster pour réduire au minimum les écarts non surveillés entre le cluster et le déploiement des ressources AKS.

  Les agents de sécurité s’exécutent avec des privilèges élevés, et ils analysent tout ce qui s’exécute sur le cluster et pas seulement la charge de travail. Ils ne doivent pas devenir une source d’exfiltration de données. En outre, les attaques par chaîne d’approvisionnement sont courantes pour les conteneurs. Utilisez des stratégies de défense en profondeur et assurez-vous que le logiciel et toutes les dépendances sont approuvés.

  Exécutez également un logiciel antivirus sur des ressources externes qui participent à des opérations de cluster. Voici quelques exemples : des zones de rebond, des agents de build et des images conteneur qui interagissent avec le cluster.

  Quand l’agent effectue une analyse, il ne doit pas bloquer ni interférer avec les opérations critiques du cluster, par exemple en verrouillant des fichiers. Une configuration incorrecte peut entraîner des problèmes de stabilité et faire que votre cluster n’est plus pris en charge.

  Important

  L’implémentation de référence fournit un déploiement d’espace réservé DaemonSet pour exécuter un agent anti-programme malveillant. L’agent s’exécute sur chaque machine virtuelle de nœud dans le cluster. Placez votre choix de logiciel anti-programme malveillant dans ce déploiement.

• Maintien de la sécurité des conteneurs. Exécutez des outils d’analyse de conteneur dans le pipeline pour détecter les menaces qui peuvent provenir d’images conteneur, par exemple l’analyse des vulnérabilités CI/CD dans Microsoft Defender pour les conteneurs. Les choix tiers incluent Trivy et Clair. Quand vous créez des images, efforcez-vous toujours d’obtenir des images Distroless. Ces images contiennent uniquement les binaires essentiels dans l’image Linux de base et réduisent la surface d’exposition pour les attaques. Utilisez une solution d’analyse continue comme l’évaluation des vulnérabilités dans Microsoft Defender pour les conteneurs afin d’analyser en continu les images déjà au repos dans vos référentiels.

Condition requise 5.1.2

Pour des systèmes considérés comme n’étant pas couramment ciblés ou affectés par des logiciels malveillants, procédez à des évaluations périodiques visant à identifier et évaluer l’évolution des programmes malveillants pour vérifier que ces systèmes ne nécessitent toujours pas de logiciel antivirus.

Vos responsabilités

Les vulnérabilités courantes peuvent affecter les composants en dehors du cluster. Effectuez le suivi des failles de sécurité en regardant CVEs et d’autres alertes de sécurité à partir de la plateforme Azure. Recherchez les mises à jour Azure pour obtenir de nouvelles fonctionnalités qui peuvent détecter des vulnérabilités et exécuter des solutions antivirus sur les services hébergés par Azure.

Par exemple, le stockage d’objets BLOB doit avoir un filtrage de réputation des programmes malveillants pour détecter les téléchargements suspects. Microsoft Defender pour le stockage inclut un filtrage basé sur la réputation des malwares. Déterminez également si une solution antivirus est requise pour un tel service.

Condition requise 5.2

Vérifiez que tous les mécanismes antivirus :

• sont constamment mis à jour.
• sont soumis à des analyses périodiques.
• génèrent des journaux d’audit qui sont conservés conformément à la spécification 10.7 de PCI DSS.

Vos responsabilités

• Assurez-vous que le cluster est protégé contre les nouvelles attaques à l’aide de la dernière version du logiciel antivirus. Il existe deux types de mise à jour dont il faut tenir compte :
  • Le logiciel antivirus doit suivre les dernières mises à jour des fonctionnalités. L’une des méthodes consiste à planifier les mises à jour dans le cadre de vos mises à jour de plateforme.
  • Les mises à jour de l’intelligence de la sécurité doivent être appliquées dès qu’elles sont disponibles pour détecter et identifier les menaces les plus récentes. Optez pour les mises à jour automatiques.
• Vérifiez que les analyses des vulnérabilités sont en cours d’exécution, comme prévu.
• Conservez tous les journaux générés suite aux analyses, qui indiquent les composants sains et non sains. La période de rétention recommandée est indiquée dans la Condition requise 10,7, qui est une année.
• Mettez en place un processus qui trie et corrige les problèmes détectés.

Pour plus d’informations sur la manière dont les mises à jour antivirus de Microsoft Defender pour Endpoint sont appliquées, veuillez consulter Mises à jour de l’intelligence de sécurité et du produit Microsoft Defender Antivirus.

Condition requise 5.3

Les fonctionnalités antivirus doivent être en cours d’exécution active, et ne peuvent pas être désactivées ou modifiées par les utilisateurs, sauf quand c’est autorisé par la direction au cas par cas pendant une période limitée.

Vos responsabilités

Vous êtes responsable de la configuration de la surveillance et des alertes de l’agent de sécurité. Générez des alertes critiques non seulement pour la charge de travail, mais également pour les processus système de base. L’agent doit toujours être en cours d’exécution. Répondez aux alertes déclenchées par le logiciel anti-programme malveillant.

• Conservez une trace du journal des activités d’analyse. Vérifiez que le processus d’analyse n’enregistre pas les données du titulaire de la carte récupérées à partir du disque ou de la mémoire.
• Définissez des alertes pour les activités qui peuvent provoquer une expiration inattendue de la conformité. Les alertes ne doivent pas être désactivées par inadvertance.
• Restreignez les permissions pour modifier le déploiement de l’agent, ainsi que tous les autres outils de sécurité critiques. Conservez ces autorisations distinctes des autorisations de déploiement de la charge de travail.
• Ne déployez pas de charges de travail si les agents de sécurité ne s’exécutent pas comme prévu.

Condition requise 5.4

Vérifiez que les politiques de sécurité et les procédures opérationnelles pour la protection de systèmes contre les programmes malveillants sont documentées, utilisées et communiquées à toutes les parties concernées.

Vos responsabilités

Il est essentiel de conserver une documentation complète sur le processus et les stratégies, en particulier des détails sur la solution antivirus utilisée pour protéger le système. Incluez des informations telles que l’emplacement du cycle de produit des mises à jour de sécurité, la fréquence des analyses et des informations sur les fonctionnalités d’analyse en temps réel.

Prévoyez des stratégies de rétention pour le stockage des journaux. Vous souhaiterez peut-être disposer d’un stockage à long terme pour des raisons de conformité.

Maintenez la documentation sur les procédures de fonctionnement standard pour l’évaluation et la correction des problèmes. Les personnes qui utilisent des environnements réglementés doivent être sensibilisées, informées et encouragées au moyen d’incentives à prendre en charge les assurances de sécurité. Ceci est important pour les personnes qui font partie du processus d’approbation du point de vue de la stratégie.

Condition requise 6.1

Établissez un processus pour identifier les vulnérabilités de sécurité, en utilisant des sources externes de bonne réputation pour la sécurité des informations sur la vulnérabilité, et affectez un classement du risque (par exemple élevé, moyen ou faible) aux vulnérabilités de sécurité nouvellement découvertes.

Vos responsabilités

Prévoyez des processus qui vérifient les vulnérabilités détectées et sont classés de manière appropriée. Microsoft Defender pour le cloud affiche des recommandations et des alertes, basées sur le type de ressource, sa gravité et son environnement. La plupart des alertes comportent des tactiques MITRE ATT&CK® qui peuvent vous aider à comprendre l’intention de la chaîne d’arrêt. Assurez-vous de disposer d’un plan de correction pour examiner et atténuer le problème.

Dans AKS, vous pouvez utiliser Azure Container Registry en association avec l’analyse continue pour identifier les images et applications vulnérables à différents niveaux de risque. Vous pouvez voir ces alertes dans Microsoft Defender pour le cloud.

Pour plus d’informations, consultez Protection des conteneurs dans Defender pour le cloud.

Exigence 6.2

Assurez-vous que tous les logiciels et les composants de système sont protégés de vulnérabilités connues en installant les correctifs de sécurité applicables fournis par le fournisseur. Installer les correctifs de sécurité critiques dans le mois qui suit leur commercialisation.

Vos responsabilités

• Pour empêcher les attaques par chaîne d’approvisionnement de fournisseurs tiers, assurez-vous que toutes les dépendances sont approuvées. Il est important de choisir des fournisseurs réputés et de confiance.

• Chaque semaine, AKS fournit de nouvelles images pour les pools de nœuds. Ces images ne sont pas appliquées automatiquement. Appliquez-les dès qu’elles sont disponibles. Vous pouvez mettre à jour manuellement ou automatiquement via la mise à jour de l’image de nœud. Pour plus d’informations, consultez mise à niveau d’image de nœud Azure Kubernetes Service (AKS)

  Pour le plan de contrôle AKS, AKS installe ou met à niveau les correctifs de sécurité.

• Toutes les 24 heures, les nœuds AKS téléchargent et installent automatiquement les correctifs de système d’exploitation et de sécurité, individuellement. Votre pare-feu ne doit pas bloquer ce trafic si vous souhaitez recevoir ces mises à jour.

  Envisagez d’activer les fonctionnalités de création de rapports sur l’agent de sécurité pour obtenir des informations sur les mises à jour appliquées. Certaines mises à jour de sécurité nécessitent un redémarrage. Veillez à passer en revue les alertes et à agir pour garantir un temps d’arrêt minimal ou nul de l’application avec ces redémarrages. Une option open source pour effectuer des redémarrages de manière contrôlée est Kured (démon de redémarrage Kubernetes).

• Étendez le processus de mise à jour corrective aux ressources situées en dehors du cluster que vous approvisionnez, telles que les serveurs de rebond et les agents de build.

• Restez à jour avec les versions de AKS prises en charge. Si votre conception utilise une version qui a atteint la fin de sa vie, mettez-la à niveau vers une version actuelle. Pour plus d’informations, voir Versions de AKS prises en charge.

Condition requise 6.3

Développez des applications logicielles internes et externes (y compris l’accès administratif aux applications par le web) en tenant compte des points suivants :

• Conformité à la norme PCI DSS (par exemple, authentification et connexion sécurisées)
• Respect des normes/bonnes pratiques du secteur.
• Intégration de la sécurité des informations tout au long du cycle de vie du développement de logiciels, qui s’applique à tous les logiciels développés en interne ainsi qu’aux logiciels personnalisés et aux logiciels développés par un tiers.

Vos responsabilités

Intégrez et hiérarchisez les choix de sécurité dans le cadre du cycle de vie et des opérations de la charge de travail.

Plusieurs frameworks sectoriels correspondent au cycle de vie, tel que l’infrastructure NIST. Les fonctions NIST (identifier, protéger, détecter, répondre et récupérer) fournissent des stratégies pour les contrôles de prévention de chaque phase.

Microsoft SDL (Security Development Lifecycle) fournit les meilleures pratiques, les outils et les processus de sécurité au cours des phases du processus de développement. Les pratiques Microsoft SDL sont suivies pour tous les services Azure, y compris AKS. Nous suivons également l’infrastructure Operational Security Assurance (OSA) pour l’exploitation des services Cloud. Vérifiez que vous disposez d’un processus similaire. Ces pratiques sont publiées pour vous aider à sécuriser vos applications.

• Microsoft SDL
• Microsoft OSA

Condition requise 6.3.1

Supprimez les comptes de développement, de test et/ou les comptes d’application personnalisés, les ID d’utilisateur et les mots de passe avant l’activation des applications ou leur mise à la disposition des clients.

Vos responsabilités

Dans le cadre de la création du cluster, plusieurs utilisateurs Kubernetes locaux sont créés par défaut. Ces utilisateurs ne peuvent pas être audités, car ils ne représentent pas une identité unique. Certaines d’entre elles ont des privilèges élevés. Désactivez ces utilisateurs à l’aide de la fonctionnalité Désactiver les comptes locaux de AKS.

Pour plus d’informations, reportez-vous à l’aide de la norme PCI-DSS 3.2.1.

Condition requise 6.3.2

Examinez le code personnalisé avant la mise en production ou la mise à la disposition des clients afin d’identifier toute vulnérabilité de codage éventuelle (en utilisant des processus manuels ou automatiques) pour inclure au moins ce qui suit :

• Les modifications de code sont examinées par des individus autres que l’auteur initial du code et par des individus compétents en matière de techniques de revue de code et de pratiques de codage sécurisées.
• Les revues de code garantissent que le code est développé conformément aux bonnes pratiques de codage sécurisé.
• Les corrections appropriées sont implémentées avant la publication.
• Les résultats de la revue du code sont passés en revue et approuvés par les responsables avant le lancement.

Vos responsabilités

Tous les logiciels installés dans le cluster proviennent de votre registre de conteneurs. Comme pour le code d’application, mettez en place des processus et des personnes pour examiner minutieusement les images Azure et tierces (Dockerfile et OCI). En outre :

• Commencez à analyser les images de conteneur à partir des étapes initiales lors de la création du cluster. Faites du processus d’analyse une partie de vos pipelines d’intégration continue/de déploiement continu.

  Vérifiez que vos pipelines de déploiement sont contrôlés de manière à ce que les images d’amorçage de cluster et votre charge de travail passent par une porte de vérification et/ou de quarantaine. Conservez l’historique du fonctionnement et des processus qui ont été utilisés avant leur extraction sur le cluster.

• Réduisez la taille de l’image. En général, les images contiennent plus de binaires que nécessaire. La réduction de la taille de l’image présente des avantages en termes de performances, mais limite également la surface d’attaque. Par exemple, l’utilisation d’images distroless permettra de minimiser la surface d’attaque des images Linux de base.

• Utilisez les outils d’analyse statique qui vérifient l’intégrité du fichier Dockerfile et des manifestes. Les options tierces incluent Dockle et Trivy.

• Utilisez uniquement des images signées.

• Comprenez (et acceptez) l’image de base fournie par Azure et la manière dont elle est conforme aux benchmarks CIS. Pour plus d’informations, consultez Benchmarks du Centre pour la sécurité Internet.

Azure Container Registry avec une analyse continue dans Microsoft Defender pour le cloud permettra d’identifier les images vulnérables et les différents risques qu’elles peuvent constituer pour la charge de travail. Pour plus d’informations sur l’analyse des images et le contrôle des risques, consultez Sécurité des conteneurs.

Condition requise 6.4

Suivez les processus et procédures de contrôle des changements pour toutes les modifications apportées à des composants de système.

Vos responsabilités

Veillez à documenter les processus de contrôle des modifications et à concevoir les pipelines de déploiement en fonction de ces processus. Incluez d’autres processus pour détecter les situations où les processus et les pipelines réels ne s’alignent pas.

Condition requise 6.4.1, 6.4.2

• Séparez les environnements de test/développement des environnements de production et appliquer la séparation à l’aide de contrôles d’accès.
• Séparation des obligations entre les environnements de développement/test et de production.

Vos responsabilités

Gérez des environnements de production et de préproduction distincts et des rôles qui fonctionnent dans ces environnements.

• N’utilisez pas votre cluster de production à des fins de développement et de test. Par exemple, n’installez pas Bridge to Kubernetes dans vos clusters de production. Utilisez des clusters dédiés pour des charges de travail hors production.

• Assurez-vous que vos environnements de production n’autorisent pas l’accès réseau aux environnements de pré-production, et vice versa.

• N’utilisez pas les identités système dans les environnements de pré-production et de production.

  Utilisez les groupes Microsoft Entra pour des groupes tels que les administrateurs de cluster ou les principaux de pipeline. N’utilisez pas de groupes généralisés ou communs en tant que contrôles d’accès. N’utilisez pas ces groupes entre les clusters de pré-production et de production. Une méthode consiste à utiliser le nom du cluster (ou un autre identifiant opaque) dans le nom du groupe, afin d’être explicite sur les appartenances.

  Utilisez les rôles RBAC (contrôle d’accès en fonction du rôle) Azure de manière appropriée entre les environnements. En général, plus de rôles et de droits sont attribués dans les environnements de préproduction.

  Les identités en préproduction uniquement (accordées à des pipelines ou à des équipes d’ingénierie logicielle) ne doivent pas bénéficier d’un accès en production. À l’inverse, toutes les identités en production uniquement (comme les pipelines) ne doivent pas être autorisées à accéder aux clusters de préproduction.

  N’utilisez pas la même identité managée assignée par l’utilisateur pour une ressource en préproduction et en production. Cette recommandation s’applique à toutes les ressources qui prennent en charge les identités managées assignées par l’utilisateur, et pas seulement à la ressource déployée dans votre cluster. En règle générale, les ressources Azure qui nécessitent des identités doivent avoir leur propre identité distincte plutôt que de les partager avec d’autres ressources.

• Utilisez l’accès juste-à-temps (JIT) pour l’accès à privilèges élevés, y compris sur des clusters de préproduction, si possible. Utilisez les stratégies d’accès conditionnel sur les clusters de préproduction et de production.

Condition requise 6.4.3

Les données de production (PAN actifs) ne sont pas utilisées à des fins de test ou de développement.

Vos responsabilités

Vérifiez que les données CHD ne soient pas transmises à l’environnement de dév/test. Avoir une documentation claire qui fournit la procédure de déplacement des données de production vers dev/test. La suppression des données réelles doit être incluse dans cette procédure et être approuvée par les parties responsables.

Condition requise 6.4.4

Suppression des données et comptes de tests dans les composants de système avant que le système ne devienne actif ou passe en phase de production.

Vos responsabilités

Supprimez les données de configuration par défaut, les exemples de données et les données de test connues dans le système avant le déploiement en production. N’utilisez pas de données du titulaire de la carte à des fins de test.

Condition requise 6.4.5

Les procédures de contrôle de changement pour l’implémentation des correctifs de sécurité et des modifications de logiciel doivent inclure ce qui suit :

• 6.4.5.1 Documentation de l’impact.
• 6.4.5.2 Documentation du changement approuvée par les parties autorisées.
• 6.4.5.3 Test de fonctionnalité pour vérifier que le changement ne compromet pas la sécurité du système.
• 6.4.5.4 Procédures de suppression.

Vos responsabilités

Ces points d’aide correspondent aux conditions requises précédentes :

• Documentez les modifications d’infrastructure attendues à la suite de l’application des correctifs de sécurité et des modifications logicielles. Ce processus est plus facile avec l’approche de l’infrastructure en tant que code (IaC). Par exemple, avec un fichier Bicep ou un modèle Azure Resource Manager (modèle ARM), vous pouvez prévisualiser les modifications du déploiement en utilisant l’opération what-if. Pour plus d’informations, consultez Opération what-if du déploiement Bicep pour les modifications de votre infrastructure.

• Mettez en place des portes dans vos pipelines de déploiement qui valident l’approbation des modifications pour les déploiements réguliers. Documentez la justification des déploiements d’urgence où les portes peuvent avoir été contournées.

  Définissez les niveaux et la profondeur des modifications. Assurez-vous que l’équipe accepte la définition de modifications importantes, par opposition aux modifications mineures. Si possible, automatisez la découverte de certaines de ces modifications. Les réviseurs de la charge de travail, de l’infrastructure et du pipeline doivent avoir une compréhension claire des niveaux et être validés par rapport à ces critères.

• Testez les limites de la sécurité. Assurez-vous que les transactions synthétiques testent les problèmes de sécurité (autoriser et refuser). Assurez-vous également que ces tests synthétiques s’exécutent dans des environnements de pré-production.

• Prévoyez un processus de réécriture au cas où un correctif de sécurité a des résultats inattendus. Une stratégie courante consiste à déployer tout en maintenant l’état précédent en utilisant des déploiements bleu-vert. Pour les charges de travail, y compris les bases de données, prévoyez une stratégie qui fonctionne pour votre topologie spécifique et qui est limitée à vos unités de déploiement.

Condition requise 6.5

Traitez les vulnérabilités de code les plus fréquentes dans les processus de développement de logiciel, afin d’inclure les éléments suivants :

• Former les développeurs au moins une fois par an pour perfectionner leurs techniques de codage sécurisé, afin qu’ils sachent notamment comment éviter les vulnérabilités de codage courantes.
• Développer des applications basées sur les directives de codage sécurisé.

Vos responsabilités

Il est essentiel que les équipes responsables des applications et les équipes responsables de l’exploitation soient sensibilisées, informées et encouragées pour prendre en charge les activités d’analyse de la charge de travail et de l’infrastructure. Voici quelques ressources :

• Instructions de codage sécurisé
• DevOps sécurisé
• Ressources de cycle de vie de développement sécurisé

Condition requise 6.6

Pour les applications web accessibles par le public, traitez les nouvelles menaces et vulnérabilités de façon continue. Vérifiez que ces applications sont protégées contre les attaques connues par une des méthodes suivantes :

• Passez en revue les applications web accessibles au public en utilisant des outils ou des méthodes d’évaluation de la sécurité des vulnérabilités des applications manuels ou automatisés. Effectuez une évaluation des vulnérabilités au moins une fois par an et après toute modification.

  Notes

  Cette évaluation est différente des analyses de vulnérabilité effectuées dans le cadre la spécification 11.2.

• Installez une solution automatisée qui détecte et empêche les attaques basées sur le web. Par exemple, un pare-feu d’applications web. Déployez-les devant les applications web accessibles au public et évaluez activement tout le trafic.

Vos responsabilités

Prévoyez des vérifications pour détecter le trafic provenant de l’Internet public à l’aide d’un pare-feu d’applications web (WAF). Dans cette architecture, Azure Application Gateway vérifie tout le trafic entrant à l’aide de son WAF intégré. Le WAF est basé sur le Core Rule Set (CRS) du projet Open Web Application Security (OWASP). Si des contrôles techniques ne sont pas en place, prévoyez des contrôles de compensation. L’une des méthodes consiste à effectuer une inspection manuelle du code.

Vérifiez que vous utilisez les versions les plus récentes de l’ensemble de règles et appliquez des règles pertinentes pour votre charge de travail. Les règles doivent s’exécuter en mode Prévention . Vous pouvez appliquer cette exigence en ajoutant une instance Azure Policy qui vérifie si le WAF est activé et fonctionne dans ce mode.

Conservez les journaux générés par le WAF Application Gateway pour obtenir des détails sur les menaces détectées. Ajustez les règles en fonction des besoins.

Réalisez de tests d’intrusion sur le code de l’application. De cette façon, les utilisateurs qui ne font pas partie de l’équipe de l’application trouveront des failles de sécurité (par exemple, l’injection SQL et la traversée de répertoire) en recueillant des informations, en analysant des vulnérabilités et en générant des rapports. Dans cet exercice, les utilisateurs peuvent avoir besoin d’accéder à des données sensibles. Pour être sût que l’intention n’est pas utilisée incorrectement, suivez les instructions fournies dans Règles d’engagement des tests d’intrusion.

Condition requise 6.7

Vérifiez que les stratégies de sécurité et les procédures opérationnelles pour le développement et la maintenance de la sécurité des systèmes et applications sont documentées, utilisées et connues de toutes les parties concernées.

Vos responsabilités

Il est essentiel de conserver une documentation complète sur les processus et les stratégies. Vos équipes doivent être formées à prioriser les choix de sécurité dans le cadre du cycle de vie des charges de travail et des opérations.

Microsoft SDL fournit les meilleures pratiques, les outils et les processus de sécurité au cours des phases du processus de développement. Les pratiques Microsoft SDL sont strictement suivies lorsque nous développons des logiciels chez Microsoft. Nous suivons également l’infrastructure Operational Security Assurance (OSA) pour l’exploitation des services Cloud. Ces pratiques sont publiées pour vous aider à sécuriser vos applications.

• Microsoft SDL
• Microsoft OSA

Gardez une documentation complète sur les tests de pénétration qui décrit l’étendue du test, les processus de triage et la stratégie de correction pour les problèmes détectés. Si un incident se produit, incorporez l’évaluation de la condition requise 6 dans le cadre de l’analyse de la cause racine. Si des failles sont détectées (par exemple, une violation de la règle OWASP), comblez ces failles.

Dans la documentation, vous trouverez des instructions claires sur l’état attendu de la protection WAF.

Les personnes qui utilisent des environnements réglementés doivent être sensibilisées, informées et encouragées au moyen d’incentives à prendre en charge les assurances de sécurité. C’est important pour les personnes qui font partie du processus d’approbation du point de vue de la stratégie.

Étapes suivantes

Restreignez l’accès aux données du titulaire de carte aux seuls individus qui doivent les connaître. Identifiez et authentifiez l’accès aux composants du système. Restreignez l’accès physique aux données du titulaire de la carte.