首先，如果这个问题已经讨论过很多次，我很抱歉。我阅读了许多有关 PCI 合规性的帖子，但有些小事情我不太确定。
假设有一位诚实的软件开发人员 GoodGuy 先生。他开发了主要的软件架构，公司信任他并给予他合理需要的所有访问权限。该软件存储用于定期支付管理的信用卡号码，软件使用信用卡网关收取续订金额。
GoodGuy 先生可以编写一些代码来为用户解密卡，无论软件具有何种安全级别（安全服务器位置中的加密密钥、每个用户的密钥或任何东西），软件本身都可以以某种方式解密卡卡数据。这意味着，即使开发人员是诚实的，他也可以访问卡数据。
这与卡的详细信息无关。它可以是任何东西，如在线文件存储服务、医疗数据或任何东西。开发人员如何确保他无法随心所欲地访问数据，但让软件可以访问它们（无需用户参与）
PS：我是这里的GoodGuy先生，我无意做坏事。我想知道其他公司如何处理这个问题。他们信任开发商吗？就算他辞职了，他也可以带着钥匙文件。刷新所有存储的卡在这里也不是一个选项，因为它可以发送许多现有的销售。
PCI DSS第 6、7 和 8 节都涉及这个问题。
例如，需要代码审查的 6.3.2 的一部分：
代码更改由原始代码作者以外的个人以及熟悉代码审查技术和安全编码实践的个人审查。
6.4 带变更控制：
分配到开发/测试环境的人员和分配到生产环境的人员之间的职责分离。
7.1 控制访问...在许多环境中，编写代码的开发人员从不访问使用实时数据的操作系统：
将系统组件和持卡人数据的访问权限仅限于工作需要此类访问权限的个人。
再加上一点 8.7 来限制那些有权访问的人：
检查数据库和应用程序配置设置以验证所有用户对数据库的访问、用户查询和用户操作（例如，移动、复制、删除）仅通过编程方法（例如，通过存储过程）。
现在，综上所述，一个值得信赖的内部人士能否受到完美的防御？不，因为“受信任”的定义非常明确。这在所有地方都是正确的（有多少间谍被“信任”？John Anthony Walker 浮现在脑海。）但是有一些最佳实践可以防御这种威胁，减轻它们，并且 PCI DSS 将一些要求正式化为这些做法（对于信用卡......其他秘密是自己的！）
（@Stephen-Touset 指出，3.5.2 要求：
始终以以下一种（或多种）形式存储用于加密/解密持卡人数据的密钥和私钥：
其中一种方法是：
在安全加密设备中（例如主机安全模块 (HSM) 或 PTS 批准的交互点设备）
这样做的好处是将实际的密钥材料从日常用户和管理员那里托管出来。）
在一个不小的程度上，这是（正如你提到的）信任问题，而不是技术问题。我们尽量小心，雇用不会滥用职权的值得信赖的人。
也就是说，可以实施许多控制措施来限制未经授权的访问，和/或验证对个人的信任是否正确，实际上没有被滥用。
以下是其中一些控件：
可能会列出无数其他控件，但这些是其中大多数将属于的一些主要类别。
防止这种情况的成本是巨大的，因此很少在资金充足的大型开发团体之外进行。上面提到的代码审查、安全审查等都是好主意，但在实践中，客户更感兴趣的是获得正常运行的代码，而不是在审查过程发生时延迟几个月使用他们的资产。
我的公司处理的大多数情况是中型企业，他们愿意花费资源来编写供内部使用的定制软件，但不会为了他们的客户联系跟踪系统或项目管理而在一些缓慢的 ISO 合规开发委员会上大肆挥霍数据库可以改进。
实际上，除了只与您信任的软件供应商打交道外，几乎没有办法防止这种滥用。当然，这不是一个解决方案，但它至少让客户的想法正确，并可能引导他们谨慎选择业务合作伙伴——软件供应商是业务合作伙伴，是任何公司都会拥有的最亲密的合作伙伴之一。大多数时候，人们似乎对此视而不见。
想想过去几年出现的谷歌、苹果、微软等和 NSA 参与的丑闻。甚至是谷歌的自我导向隐私侵犯。开发人员正在确保有人可以窃取他们客户的数据，并且以某种方式安全审查流程——这些特定组织足够大，可以负担得起——没有发现。它真的是“Quis custodiet ipsos custodes？” 问题（点燃。“谁看守卫兵？”）。
在我自己的情况下，我们已经确定我们永远不会自己持有客户数据。这意味着我们在客户站点本地建立廉价的小型服务器，这些服务器直接为业务服务。这是一个网速飞快、硬件便宜的时代；小型企业不需要云服务即可从世界任何地方访问其数据。为了确保安全和数据冗余，我们提供了在线备份，但它所有加密的 blob，所以我们无法读取它。
如果我们愿意，我们当然可以在他们的服务器上打开漏洞并滥用他们的信任。但是没有办法阻止邪恶的人这样做。作为我公司的所有者，我决定安全与可用性（对我们和客户）的最佳平衡是让他们保存他们的数据，而我们只保留它的加密备份。
我在上面提到了“云”。这可能是迄今为止任何人都想象过的对数据安全的最大威胁，而且一旦客户数据失控，保证保护客户数据的方法完全为零。“占有是 90% 的法律”是一个很好的教训，因为在现代它 90% 的数据安全。
对于一名开发人员身兼多职（DBA、系统管理员、技术支持、网站管理员等）的中小型企业，满足 PCI DSS 要求的任务过于繁重。防止开发人员获取敏感数据的可能解决方案是使用第三方 API，其中敏感数据的处理和存储发生在受信任的第三方网站上，而不是您自己的网站上。
在信用卡交易和定期支付管理的情况下，您可以使用符合 PCI DSS 标准的 PayPal，而不是滚动您自己的系统。当然，代码仍然需要经过审核，以确保客户在交易过程中确实被重定向到第三方网站。
归根结底，您必须开始信任受雇为您完成工作的人（受信任的开发人员或受信任的第三方）。否则，你必须自己做所有事情。