近期,支付卡行业数据安全标准进行了一次更新,它已升级至下一个主要版本,PCI DSS 3.0版。在一些地区,新版本中的需求会在一定程度上影响到商家的合规性计划和支持商家的服务供应商(云及其他),而有些地区则很可能会受到最大程度的影响,即必须针对云做出相应改变,在这些地区持卡人数据环境(CDE)会与云技术的使用产生交集。 很多商家一直以来都认为云的PCI DSS合规都是一个复杂和极具挑战性的命题,因此PCI安全标准委员会专门为在PCI环境中使用云而出台了一个完整的文档。但是,PCI 3.0版在几个方面让原本就已经很复杂的情况变得更为复杂了。
这并不是因为3.0版使用了专为解决云问题的新语言或需求(……
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
近期,支付卡行业数据安全标准进行了一次更新,它已升级至下一个主要版本,PCI DSS 3.0版。在一些地区,新版本中的需求会在一定程度上影响到商家的合规性计划和支持商家的服务供应商(云及其他),而有些地区则很可能会受到最大程度的影响,即必须针对云做出相应改变,在这些地区持卡人数据环境(CDE)会与云技术的使用产生交集。
很多商家一直以来都认为云的PCI DSS合规都是一个复杂和极具挑战性的命题,因此PCI安全标准委员会专门为在PCI环境中使用云而出台了一个完整的文档。但是,PCI 3.0版在几个方面让原本就已经很复杂的情况变得更为复杂了。这并不是因为3.0版使用了专为解决云问题的新语言或需求(事实上,它并没有解决),或者是因为它取代了上面提及的之前的指导性文档(事实上,新版本中也没有包含这些内容)。相反,产生这些混乱的原因在于,当涉及云时,同时满足一些新需求和维护原需求往往会导致更为复杂情形的产生。
PCI DSS 3.0版有些什么不同之处?
在PCI DSS 3.0中有三个新需求是最值得强调的,因为它们是与在PCI监管的基础设施中使用云技术最为相关的:
- 需求2.4: “为PCI DSS在范围内维护一个系统组件库。”
- 需求1.1.3: “[维护]显示跨系统和网络的所有持卡人数据流的当前图表。”
- 需求12.8.5: “维护每一个PCI DSS需求分别是由每个服务供应商和每个实体所管理的信息。”
请注意,这些并不是新版文档中唯一的新需求——它们也不是在云使用情况下对PCI有影响的唯一需求。但是,对于正在使用云服务和已经开发了一个PCI合归规定以解决CDE环境中应用的企业来说,在之后的几个月中有三个需求可能会导致最混乱的情形发生。应当了解为什么需要更深入地钻研每一个需求。
编制目录和IaaS
企业使用云所必须了解的第一个需求就是,编制系统组件目录。PCI DSS标准在PCI 3.0版文档的第十页“系统组件”一节中,简单介绍了这个概念,但是从我们的目的出发需要指出的是,它特别地包括了虚拟机。那些曾试图保留一个可靠的任何虚拟环境库的企业都知道这是多么困难的一项任务,但是请记住,在一个云部署中(尤其是基础设施即服务IaaS),它可能要比企业直接控制的虚拟环境要更为复杂得多,特别是当或如果它是由服务供应商支持的时情况更是如此。可考虑让相关的服务供应商支持雇员来决定是否复制一个实例以帮助测试补丁兼容性的影响,或者在对性能瓶颈做出响应时动态地重新定位镜像。这意味着客户现在必须更关注在CDE中跟踪实例的创建和销毁以确保库存信息的真实性和时效性。
为了实现这一目标,企业可以有几种选择。在最坏的情况下,大部分的IaaS供应商将在他们的环境中或通过他们的控制面板提供一个镜像的原始列表。虽然这份列表可能并不是所有企业所需要的(例如,该列表可能并没有说明镜像的目的或者镜像中包含了哪些软件),但是这至少是一个好的开始。如果你的组织拥有由服务供应商指派的、为你提供帐户支持服务的技术人员(当然,前提是你是某个特定服务供应商眼中的大客户),那么你就可考虑在创建库时争取供应商提供相关的帮助。如果你并不是供应商眼中的大客户或者你的云服务供应商是不配合的(或者成本过高的),那么可以考虑采用自动化功能予以辅助;例如,在你的虚拟“黄金镜像”中包含一个预配置的编制库存目录的代理,这样就可能有助于捕获新实例。
数据流和SaaS
下一个挑战的领域必须与在某些云环境中的数据流映射相关,尤其是软件即服务(SaaS)。与平台即服务(PaaS)和IaaS不同,请记住在SaaS环境中,应用程序本身就是一个“黑盒子”,这意味着SaaS客户会有意识地与应用程序如何运行的底层机制隔离了。例如,当你登录LinkedIn或Facebook时,你是否知道你的用户ID运行在哪个具体的服务器上吗?或者你知道它在后端环境中连接着多少个不同的数据库?你是否会关心这些问题呢?我想,只要应用程序能够让你正确登录,你应该就不会关心这些细枝末节的技术信息的。现在可以类比地想象一下,了解如何运行以及数据所占有具体文档确切路径的需求。
现在,请记住,在标准中没有说明数据流图表必须“知道不可知的”,因此当企业还不具有充分了解远程基础设施的能力时,深入这一详细程度总是不现实的。在另一方面,一个具有单箭头且指向互联网的图表表明,“PAN发送至远程计费供应商,”审核员并不会行动起来以符合期望的预定标准,所以需要找到一个中间立场以便于能够彻底地满足审核员,但这也没有那么繁重以至于没有一家组织能够生产并维持之。与之相反,从记录你所知道的信息开始,并促使供应商帮助完善剩余部分。如果他们不能(或者不愿意)帮助用户深入钻研和变得越来越精细化,那么请一定要记录这一事实而留给后来者。为审核员提供你在你的那部分工作中收集更多具体数据所付出最大努力的证据,将有助于建立你已深思熟虑的需求。
服务供应商矩阵
一贯以来,PCI都要求企业为他们的服务供应商的PCI合规性状态保留标签,但是现在它还要求企业特别地、分门别类地记录哪些PCI需求应由供应商负责,而哪些则由那些企业负责。
虽然,咋听之下PCI似乎是提出了一个很简单的要求,但是请记住云供应商(这里无需考虑SaaS、PaaS或是IaaS部署)与更多的传统服务供应商都属于此列。这意味着,企业现在必须明确是谁在为具体的PCI DSS控制而负责:是企业还是供应商。一些服务供应商(尤其是那些为商家社区频繁地提供服务的供应商)能够拿出他们所提供控制的现成列表,但是其他的一些则可能完全不认同会有多少家企业会同意分担责任。这意味着,可能需要有一些谈判和来回反复来建立一个双方都认同的列表。
结论
这里需要再次指出的是,这三个需求并不是PCI DSS 3.0为使用云的商家而引入的唯一变化。但是,它们为精明的安全性和合规性从业人士指明了方向,以便于为新标准的推出而做一些事先准备和前期规划。
相关推荐
-
应用安全项目:PCI DSS是否是良好的指南?
当实施应用安全项目时,PCI DSS是否是充分的指南?组织是不是应该采取托管PCI合规清单以外的措施?
-
分解合规性责任:云计算vs.内部部署
如果公司的应用程序位于内部服务器,那么,公司只负责满足法规遵从需求。公司的业务将应用程序和数据移动到云,但是,这并没有改变所有的合规性责任。