通过

Microsoft Entra ID 和 PCI-DSS 要求 6

  • 项目

要求 6：开发和维护安全系统及软件
定义的方法要求

6.1 定义并了解开发和维护安全系统及软件的过程和机制。

PCI-DSS 定义的方法要求 Microsoft Entra 指南和建议
6.1.1要求 6 中确定的所有安全策略和操作过程需：
已载明
保持最新状态
在使用中
为所有受影响方所知晓		 根据环境配置，使用此处的指导和链接生成相应文档以满足要求。
6.1.2 记录、分配并了解执行要求 6 中的活动的角色和职责。 根据环境配置，使用此处的指导和链接生成相应文档以满足要求。

6.2 以安全方式开发定制和自定义软件。

PCI-DSS 定义的方法要求 Microsoft Entra 指南和建议
6.2.1 以安全方式开发定制和自定义软件，要求如下：
基于安全开发的行业标准和/或最佳做法。
遵循 PCI DSS（例如，进行安全的身份验证和日志记录）。
在软件开发生命周期的每个阶段都考虑到信息安全问题。		 采购和开发使用新式身份验证协议的应用程序。这些协议包括 OAuth2 和 OpenID Connect (OIDC) 等，可与 Microsoft Entra ID 集成。
使用 Microsoft 标识平台生成软件。 Microsoft 标识平台最佳做法和建议
6.2.2 定制和自定义软件的软件开发人员每 12 个月至少接受一次培训，培训内容如下：
与其工作职能和开发语言相关的软件安全性。
包括安全软件设计和安全编码技术。
如果使用安全测试工具，包括如何使用这些工具来检测软件中的漏洞。		 通过以下考试提供 Microsoft 标识平台熟练程度证明：考试 MS-600：使用 Microsoft 365 核心服务构建应用程序和解决方案使用以下培训为考试做准备：MS-600：实现 Microsoft 标识
6.2.3 在将定制和自定义软件发布到生产环境或向客户发布之前进行评审，以识别和更正潜在的编码漏洞，具体操作如下：
通过代码评审确保根据安全编码准则开发代码。
通过代码评审查找现有和新出现的软件漏洞。
在发布之前进行适当的更正。		 不适用于 Microsoft Entra ID。
6.2.3.1 如果在将定制和自定义软件发布到生产环境之前执行人工代码评审，则代码变更需：
由原始代码作者以外的人员进行审查，并且该人员需了解代码评审技术和安全编码做法。
在发布之前由管理人员进行审查并获得批准。		 不适用于 Microsoft Entra ID。
6.2.4 软件开发人员需定义和使用软件工程技术或其他方法，以防止或缓解定制和自定义软件中的常见软件攻击和相关漏洞，包括但不限于：
注入攻击，包括 SQL、LDAP、XPath 或其他命令、参数、对象、故障或注入型缺陷。
对数据和数据结构的攻击，包括试图操控缓冲区、指针、输入数据或共享数据。
对加密用法的攻击，包括试图利用较弱、不安全或不适当的加密实现、算法、密码套件或操作模式。
对业务逻辑的攻击，包括试图通过操控 API、通信协议和通道、客户端功能或其他系统/应用程序功能和资源来滥用或绕过应用程序功能。 这包括跨站脚本 (XSS) 和跨站请求伪造 (CSRF)。
对访问控制机制的攻击，包括试图绕过或滥用标识、身份验证或授权机制，或者试图利用此类机制实现中的弱点。
通过在漏洞识别过程（详见要求 6.3.1）中识别的所有“高风险”漏洞进行的攻击。		 不适用于 Microsoft Entra ID。

6.3 识别并解决安全漏洞。

PCI-DSS 定义的方法要求 Microsoft Entra 指南和建议
6.3.1 识别和管理安全漏洞的要求如下：
利用行业认可的安全漏洞信息来源（包括国际和国家/地区计算机应急响应团队 [CERT] 提供的警报）识别新的安全漏洞。
根据行业最佳做法和对潜在影响的考虑，为漏洞指定风险等级。
风险等级应至少确定被认为属于“高风险”或对环境有严重影响的所有漏洞。
涵盖定制和自定义软件以及第三方软件（例如操作系统和数据库）的漏洞。		 了解各种漏洞。 MSRC | 安全更新程序：安全更新程序指南
6.3.2 维护包含定制和自定义软件以及合并到该类软件中的第三方软件组件的清单，以便管理漏洞和补丁。 针对使用 Microsoft Entra ID 进行身份验证的应用程序生成报告，以获得包含这些应用程序的清单。 applicationSignInDetailedSummary 资源类型
企业应用程序中列出的应用程序
6.3.3 通过安装适用的安全修补程序/更新来保护所有系统组件免受已知漏洞的危害，具体要求如下：
严重或高风险安全修补程序/更新（根据要求 6.3.1 中的风险评级过程确定）需在发布后的一个月内完成安装。
所有其他适用的安全修补程序/更新均需在实体确定的适当时间范围内完成安装（例如，在发布后的三个月内）。		 不适用于 Microsoft Entra ID。

6.4 保护面向公众的 Web 应用程序免受攻击。

PCI-DSS 定义的方法要求 Microsoft Entra 指南和建议
6.4.1 对于面向公众的 Web 应用程序，需要不断解决新的威胁和漏洞，并且保护这些应用程序不受已知攻击的影响，具体做法如下：通过人工或自动应用程序漏洞安全评估工具或方法审查面向公众的 Web 应用程序，要求如下：
– 至少每 12 个月审查一次，并在发生重大变更后进行审查。
- 由专门研究应用程序安全性的实体执行。
– 至少包括要求 6.2.4 中的所有常见软件攻击。
- 按照要求 6.3.1 对所有漏洞进行评级。
- 更正所有漏洞。
– 在更正后重新评估应用程序
或者
安装一个可持续检测和防止基于 Web 的攻击的自动化技术解决方案，要求如下：
– 安装在面向公众的 Web 应用程序前面，以检测和防止基于 Web 的攻击。
– 主动运行，并随时更新（如适用）。
– 生成审核日志。
– 配置为阻止基于 Web 的攻击或生成会立即受到调查的警报。		 不适用于 Microsoft Entra ID。
6.4.2 对于面向公众的 Web 应用程序，需部署可持续检测和防止基于 Web 的攻击的自动化技术解决方案，且至少满足以下要求：
安装在面向公众的 Web 应用程序的前面，并配置为检测和防止基于 Web 的攻击。
主动运行，并随时更新（如适用）。
生成审核日志。
配置为阻止基于 Web 的攻击或生成会立即受到调查的警报。		 不适用于 Microsoft Entra ID。
6.4.3 在使用者的浏览器中加载和执行的所有付款页脚本都按如下方式进行管理：
实现某种方法以确认每个脚本都已获得授权。
实现某种方法以确保每个脚本的完整性。
维护一份包含所有脚本的清单，并书面说明为什么每个脚本都是必需的。		 不适用于 Microsoft Entra ID。

6.5 安全地管理对所有系统组件进行的变更。

PCI-DSS 定义的方法要求 Microsoft Entra 指南和建议
6.5.1 对生产环境中的所有系统组件的变更都需要遵循规定的程序，其中包括：
变更的原因和说明。
安全影响文档。
授权方提供的记录在案的变更批准。
进行测试，以验证变更不会对系统安全性产生负面影响。
对于定制和自定义软件变更，所有更新都需在部署到生产环境之前测试是否符合要求 6.2.4。
解决故障并返回到安全状态的程序。		 在变更控制过程中包括对 Microsoft Entra 配置的变更。
6.5.2 完成重大变更后，确认所有适用的 PCI-DSS 要求均在所有新的或变更后的系统和网络上执行到位，并根据需要更新相关文档。 不适用于 Microsoft Entra ID。
6.5.3 将预生产环境与生产隔离开，并通过访问控制强制实施这种隔离。 根据组织要求隔离预生产和生产环境的方法。 单个租户中的资源隔离
多个租户的资源隔离
6.5.4 将生产环境和预生产环境之间的角色和职能分开，以实现问责制，从而只部署经过审查和批准的变更。 了解特权角色和专用预生产租户。 Microsoft Entra 最佳做法
6.5.5 实时 PAN 不用于预生产环境，除非这些环境包含在 CDE 中，并根据所有适用的 PCI-DSS 要求进行保护。 不适用于 Microsoft Entra ID。
6.5.6 在将系统投入生产之前，从系统组件中移除测试数据和测试帐户。 不适用于 Microsoft Entra ID。

后续步骤

PCI-DSS 要求 3、4、9 和 12 不适用于 Microsoft Entra ID，因此没有相应的文章。 若要查看所有要求，请转到 pcisecuritystandards.org：官方 PCI 安全标准委员会网站。

要将 Microsoft Entra ID 配置为符合 PCI-DSS 要求，请参阅以下文章。