支付卡行业数据安全标准（PCI DSS）由 Visa、万事达卡、美国运通、Discover 和 JCP 于 2004 年制定，旨在为安全和数据保护建立一套全行业标准。为了跟上技术变革的步伐，这些标准自首次发布以来已进行了多次更新。这些标准适用于持卡人数据环境中的所有相关对象，即存储、处理或传输持卡人数据的人员、流程和技术。在技术方面，它同时涵盖了硬件和软件。
符合 PCI 要求并不容易，公司每年平均要花费 550 万美元。但是，违规的代价要高得多，平均每年要承担 1,480 万美元的罚款。借助正确的流程和工具，PCI 合规性就不会成为一项重大挑战。
PCI DSS 有 12 项要求，分别对应 6 个更普遍的目标。具体包括：
构建和维护安全的网络系统
安装和维护防火墙配置，以保护持卡人数据
对于系统密码及其他安全参数，不要使用供应商提供的默认值
保护持卡人数据
保护已存储的持卡人数据
对通过开放式公共网络进行传输的持卡人数据进行加密
确保维护好漏洞管理程序
保护所有系统免受恶意软件和漏洞攻击，并定期更新防病毒软件
开发并维护安全的系统和应用
采取强大的访问权限控制措施
根据业务须知要求，限制对持卡人数据的访问
识别和验证系统组件的访问权限
限制对持卡人数据的物理访问
定期监控和测试网络
跟踪和监控对网络资源及持卡人数据的所有访问
定期测试安全系统和流程
确保维护信息安全策略
维护旨在处理所有人员信息安全事务的策略
容器化应用的 PCI 合规性
在 PCI 所述的上述六个目标中，每一个都有相应的若干项要求，这些要求与容器和 Kubernetes 环境直接相关。请评估您的容器和 Kubernetes 安全工具，以确保它们能够满足以下要求：
1.12 标识持卡人数据环境（CDE）与其他网络（包括任何无线网络）之间的所有连接的当前网络图
1.1.4 每个互联网连接以及任何隔离区（DMZ）与内部网络区域之间的防火墙要求。
1.2 构建防火墙和路由器配置，以限制不可信网络与持卡人数据环境中的任何系统组件之间的连接。
1.2.1 将入站和出站流量限制为持卡人数据环境所需的流量，并明确拒绝所有其他流量。
1.3.2 使入站互联网流量仅限于 DMZ 内的 IP 地址。
1.3.4 不允许从持卡人数据环境向互联网传输未经授权的出站流量。
1.3.5 只允许"已建立"的连接进入网络。
2.1 在网络上安装系统之前，始终更改供应商提供的默认值并删除或禁用不必要的默认帐户。
2.2 为所有系统组件制定配置标准。确保这些标准能解决所有已知的安全漏洞问题，并与行业公认的系统强化标准保持一致。
2.2.1 每台服务器仅实现一个主要功能，以防那些需要不同安全级别的功能在同一台服务器上共存。（例如，Web 服务器、数据库服务器和 DNS 应在单独的服务器上实现。）
2.2.2 仅启用系统功能所需的必要服务、协议、守护进程等。
2.2.3 针对任何被认为不安全的必要服务、协议或守护进程，实施额外的安全功能。
2.2.5 删除所有不必要的功能（例如脚本、驱动程序、功能、子系统、文件系统）和不必要的 Web 服务器。
2.3 使用强加密技术对所有非控制台管理访问进行加密。
2.4 维护 PCI DSS 范围内的系统组件清单。
3.6.2 安全的加密密钥分发。
6.1 制定识别安全漏洞的流程，使用信誉良好的外部安全漏洞信息来源，并为新发现的安全漏洞分配风险等级（例如"高"、"中"或"低"）。
6.2 通过安装由供应商提供的相应安全补丁，确保所有系统组件和软件免受已知漏洞的影响。在发布后的一个月内安装重要安全补丁。
6.4.1 将开发/测试环境与生产环境分开，并利用访问工具进行强制分离。
6.4.2 开发/测试和生产环境之间的职责分离。
6.5.1 注入缺陷，尤其是 SQL 注入。还要考虑操作系统命令注入、LDAP 和 XPath 注入缺陷，以及其他注入缺陷。
6.5.3 不安全的加密存储。
6.5.4 不安全的通信。
6.5.6 在漏洞识别过程中识别出的所有"高风险"漏洞（如 PCI DSS 要求 6.1 中所定义）。
10.2.5 针对所有系统组件实施自动化审查跟踪，以重建对识别和身份验证机制的使用和更改（包括但不限于创建新帐户和提升权限）以及对具有 root 或管理权限的帐户的所有更改、添加或删除。
11.2.1 每季度执行一次内部漏洞扫描。消除漏洞并执行重新扫描，以验证所有"高风险"漏洞均已根据实体的漏洞排名（依据要求 6.1）得到解决。扫描必须由合格人员来执行。
11.5 部署变更检测机制（例如文件完整性监控工具），以提醒相关人员存在对关键系统文件、配置文件或内容文件未经授权的修改（包括更改、添加和删除）；同时，将软件配置为至少每周执行一次关键文件比较。
11.5.1 实施相应流程，以对变更检测解决方案所生成的任何提醒做出响应。