Microsoft Entra ID et exigence PCI-DSS 6

Article
10/29/2023

Condition requise 6 : Développer et maintenir des systèmes et des logiciels sécurisés
Condition requise d’approche définie

6.1 Des processus et mécanismes destinés à développer et gérer des systèmes et des logiciels sécurisés sont définis et compris.

Conditions requises d’approche définie par PCI-DSS	Aide et recommandations relatives à Microsoft Entra
6.1.1 Toutes les stratégies de sécurité et procédures opérationnelles qui sont identifiées dans la condition requise 6 sont : Documentées Tenues à jour En place Connues de toutes les parties concernées	Utilisez l’aide et les liens ci-dessous pour produire la documentation et répondre aux conditions requises selon la configuration de votre environnement.
6.1.2 Les rôles et responsabilités liés à l’exécution des activités mentionnées dans la condition requise 6 sont documentés, attribués et compris.	Utilisez l’aide et les liens ci-dessous pour produire la documentation et répondre aux conditions requises selon la configuration de votre environnement.

6.2 Des logiciels personnalisés et sur mesure sont développés de manière sécurisée.

Conditions requises d’approche définie par PCI-DSS	Aide et recommandations relatives à Microsoft Entra
6.2.1 Les logiciels personnalisés et sur mesure sont développés en toute sécurité de cette manière : En fonction des normes du secteur et/ou des meilleures pratiques pour un développement sécurisé. Conforme à la norme PCI-DSS (par exemple, authentification et connexion sécurisées). Intégration de la prise en compte des problèmes de sécurité des informations à chaque étape du cycle de vie du développement de logiciels.	Procurez-vous et développez des applications qui utilisent des protocoles d'authentification modernes, tels que OAuth2 et OpenID Connect (OIDC), qui s'intègrent à Microsoft Entra ID. Créez des logiciels à l’aide de la plateforme d’identités Microsoft. Meilleures pratiques et recommandations relatives à la plateforme d’identité Microsoft
6.2.2 Le personnel de développement de logiciels travaillant sur des logiciels sur mesure et personnalisés est formé au moins une fois tous les 12 mois de cette manière : Sur la sécurité des logiciels en rapport avec leur fonction de travail et leurs langages de développement. Comprend la conception de logiciels sécurisée et les techniques de codage sécurisés. Comprend comment utiliser les outils pour détecter les vulnérabilités dans les logiciels si des outils de test de sécurité sont utilisés.	Utilisez l’examen suivant pour fournir une preuve de compétence sur la plateforme d'identités Microsoft : Examen MS-600 : Création d’applications et de solutions avec Microsoft 365 Core Services Utilisez la formation suivante pour vous préparer à l’examen : MS-600 : Implémenter l’identité Microsoft
6.2.3Les logiciels personnalisés et sur mesure sont examinés avant d’être mis en production ou remis aux clients, afin d’identifier et de corriger les vulnérabilités de codage potentielles de cette manière : Les révisions de code garantissent que le code est développé conformément aux directives de codage sécurisé. Les révisions de code recherchent à la fois les vulnérabilités logicielles existantes et émergentes. Les corrections appropriées sont implémentées avant la publication.	Non applicable à Microsoft Entra ID.
6.2.3.1 Si des révisions de code manuelles sont effectuées pour des logiciels personnalisés et sur mesure avant la mise en production, les modifications du code sont : Examiné par des personnes autres que l’auteur du code d’origine et qui connaissent bien les techniques de révision de code et les pratiques de codage sécurisées. Examiné et approuvé par les responsables avant le lancement.	Non applicable à Microsoft Entra ID.
6.2.4 Les techniques d’ingénierie logicielle ou d’autres méthodes sont définies et utilisées par le personnel de développement logiciel pour prévenir ou atténuer les attaques logicielles courantes et les vulnérabilités associées dans des logiciels personnalisés et sur mesure. Cela comprend, sans s’y limiter : Attaques par injection, notamment SQL, LDAP, XPath ou d’autres défauts de commande, de paramètre, d’objet, d’erreur ou de type injection. Attaques sur les données et les structures de données, comme les tentatives de manipulation de mémoires tampons, de pointeurs, de données d’entrée ou de données partagées. Attaques contre l’utilisation du chiffrement, notamment les tentatives d’exploitation d’implémentations de chiffrement, d’algorithmes, de suites de chiffrement ou de modes de fonctionnement faibles, non sécurisés ou inappropriés. Attaques contre la logique métier, comme les tentatives d’abus ou de contournement des fonctionnalités d’application par le biais de la manipulation d’API, de protocoles et de canaux de communication, de fonctionnalités côté client ou d’autres fonctions et ressources système ou application. Comprend le scripting intersites (XSS) et la falsification de requête intersites (CSRF). Attaques sur les mécanismes de contrôle d’accès, comme les tentatives de contournement ou d’abus d’identification, d’authentification ou d’autorisation, ou les tentatives d’exploitation des faiblesses dans l’implémentation de ces mécanismes. 6.3.1 Les attaques contre toute vulnérabilité « à haut risque » identifiée dans le processus d’identification de vulnérabilité, comme définies dans la condition requise 6.3.1.	Non applicable à Microsoft Entra ID.

6.3 Les vulnérabilités de sécurité sont identifiées et corrigées.

Conditions requises d’approche définie par PCI-DSS	Aide et recommandations relatives à Microsoft Entra
6.3.1 Les vulnérabilités de sécurité sont identifiées et gérées de cette manière : Les nouvelles failles de sécurité sont identifiées à l’aide de sources reconnues par le secteur pour fournir des informations sur les vulnérabilités de sécurité, comme les alertes des équipes d’intervention en cas d’urgence informatique (CERT) internationales et nationales/régionales. Les vulnérabilités se voient attribuer un classement des risques basé sur les meilleures pratiques du secteur et la prise en compte de l’éventuel impact. Le classement des risques identifie, au minimum, toutes les vulnérabilités considérées comme étant à risque élevé ou critique pour l’environnement. Les vulnérabilités pour les logiciels personnalisés et sur mesure et les logiciels tiers (comme les systèmes d’exploitation et les bases de données) sont couvertes.	Découvrez-en davantage sur les vulnérabilités. MSRC \| Mises à jour de sécurité, Guide des mises à jour de sécurité
6.3.2 Un inventaire des logiciels sur mesure et personnalisés, ainsi que des composants logiciels tiers incorporés dans des logiciels sur mesure et personnalisés, est tenu à jour pour faciliter la gestion des vulnérabilités et des correctifs.	Générez des rapports pour les applications à l'aide de Microsoft Entra ID pour l'authentification de l'inventaire. Le `applicationSignInDetailedSummary` type de ressource Applications listées dans les applications d’entreprise
6.3.3 Tous les composants système sont protégés contre les vulnérabilités connues en installant les correctifs/mises à jour de sécurité applicables comme suit : Les correctifs et mises à jour critiques ou de haute sécurité (identifiées selon le processus de classement des risques dans la condition requise 6.3.1) sont installés dans le mois suivant la publication. Tous les autres correctifs et mises à jour de sécurité applicables sont installés dans un laps de temps approprié déterminé par l’entité (par exemple, dans les trois mois suivant la publication).	Non applicable à Microsoft Entra ID.

6.4 Les applications web publiques sont protégées contre les attaques.

Conditions requises d’approche définie par PCI-DSS	Aide et recommandations relatives à Microsoft Entra
6.4.1 Pour les applications web publiques, les nouvelles menaces et vulnérabilités sont traitées de façon continue et ces applications sont protégées contre les attaques connues de cette manière : Examen des applications web accessibles au public via des outils ou méthodes d’évaluation de la sécurité des vulnérabilités des applications manuelles ou automatisées de cette manière : – Au moins une fois tous les 12 mois et après des modifications importantes. – Par une entité spécialisée dans la sécurité des applications. – Comprend au minimum toutes les attaques logicielles courantes dans la condition requise 6.2.4. – Toutes les vulnérabilités sont classées conformément à la condition requise 6.3.1. – Toutes les vulnérabilités sont corrigées. – L’application est réévaluée après les corrections OU Installation d’une ou plusieurs solutions techniques automatisées qui détectent et empêchent en permanence les attaques web de cette manière : – Installée devant les applications web publiques pour détecter et empêcher les attaques basées sur le web. – En cours d’exécution et à jour, le cas échéant. – Génération des journaux d’audit. – Configuré pour bloquer les attaques basées sur le web ou générer une alerte qui est immédiatement examinée.	Non applicable à Microsoft Entra ID.
6.4.2 Pour les applications web publiques, une solution technique automatisée est déployée. Elle détecte et empêche en permanence les attaques web, avec au moins les éléments suivants : Installé devant les applications web publiques et configuré pour détecter et empêcher les attaques basées sur le web. En cours d’exécution et à jour, le cas échéant. Génération des journaux d’audit. Configuré pour bloquer les attaques basées sur le web ou générer une alerte qui est immédiatement examinée.	Non applicable à Microsoft Entra ID.
6.4.3 Tous les scripts de page de paiement chargés et exécutés dans le navigateur du consommateur sont gérés de cette manière : Une méthode est implémentée pour confirmer que chaque script est autorisé. Une méthode est implémentée pour garantir l’intégrité de chaque script. Un inventaire de tous les scripts est tenu à jour avec une justification écrite de la raison pour laquelle chacun d’eux est nécessaire.	Non applicable à Microsoft Entra ID.

6.5 Les modifications apportées à tous les composants système sont gérées de manière sécurisée.

Conditions requises d’approche définie par PCI-DSS	Aide et recommandations relatives à Microsoft Entra
6.5.1 Les modifications apportées à tous les composants système dans l’environnement de production sont effectuées selon les procédures établies qui incluent : Raison et description de la modification. Documentation sur l’impact sur la sécurité. Documentation d’approbation de modification par les parties autorisées. Test pour vérifier que la modification n’a pas d’impact négatif sur la sécurité du système. Pour les modifications logicielles personnalisées et sur mesure, toutes les mises à jour sont testées pour être conformes à la condition requise 6.2.4 avant d’être déployées en production. Procédures pour résoudre les défaillances et revenir à un état sécurisé.	Incluez les modifications apportées à la configuration de Microsoft Entra dans le processus de contrôle des modifications.
6.5.2 À l’issue d’une modification importante, toutes les conditions requises PCI-DSS applicables sont confirmées comme étant en place sur tous les systèmes et réseaux nouveaux ou modifiés, avec une documentation mise à jour le cas échéant.	Non applicable à Microsoft Entra ID.
6.5.3 Les environnements de préproduction sont séparés des environnements de production et cette séparation est appliquée avec des contrôles d’accès.	Approches pour séparer les environnements de préproduction et de production, en fonction des exigences de l’organisation. Isolation des ressources dans un seul tenant (locataire/client) Isolation des ressources avec plusieurs tenants
6.5.4 Les rôles et les fonctions sont séparés entre environnements de production et de préproduction pour fournir une responsabilité de sorte que seules les modifications examinées et approuvées soient déployées.	Découvrez les rôles privilégiés et les tenants de préproduction dédiés. Meilleures pratiques pour les rôles Microsoft Entra
6.5.5 Les PAN en direct ne sont pas utilisés dans les environnements de préproduction, sauf si ces environnements sont inclus dans le CDE et protégés conformément à toutes les conditions requises PCI-DSS applicables.	Non applicable à Microsoft Entra ID.
6.5.6 Les données de test et les comptes de test sont supprimés des composants système avant la mise en production du système.	Non applicable à Microsoft Entra ID.

Étapes suivantes

Les exigences PCI-DSS 3, 4, 9, et 12 ne s'appliquent pas à Microsoft Entra ID, il n'y a donc pas d'articles correspondants. Pour consulter toutes les exigences, rendez-vous sur le site pcisecuritystandards.org : Site officiel du Conseil des normes de sécurité PCI.

Pour configurer Microsoft Entra ID pour qu'il soit conforme à PCI-DSS, consultez les articles suivants.

Partager via