中神通公司技术论坛 - Powered by Discuz! Board

标题: 关于云计算安全的合规性应遵从文件有哪方面的内容？ [打印本页]

作者: linda 时间: 2014-4-3 17:32 标题: 关于云计算安全的合规性应遵从文件有哪方面的内容？

转载自起点网

HIPAA
《美国健康保险可携与责任法》信息技术和生命科学技术将是21世纪颇受关注的两个技术领域，它们都将为解决人类最根本的需求——健康需求而服务。在医疗保健领域，信息系统的应用越来越广泛，如医院信息管理系统、远程医疗诊断、网上就医、急救调度响应、疫情监控系统、医疗保险系统等。
与其他行业一样，医疗保健对信息系统的应用和依赖，也将不可避免地带来相应的信息安全问题，如病人的病例保密问题、网上就医系统的可靠性问题、急救调度响应系统的可用性问题等。目前，美国已就此类问题专门颁布了相应的HIPAA法案和技术标准，我国在这方面的工作也将逐步展开。
HIPAA是美国前总统克林顿签署的健康保险携带和责任法案（Health Insurance Portability and Accountability Act）的缩写。该法案对多种医疗健康产业都具有规范作用，包括交易规则、医疗服务机构的识别、从业人员的识别、医疗信息安全、医疗隐私、健康计划识别、第一伤病报告、病人识别等。该法案的主要目标如下：
保证劳动者在转换工作时，其健康保险可以随之转移；
保护病人的病例记录等个人隐私；
促进国家在医疗健康信息安全方面电子传输的统一标准。
在HIPAA法案的相关标准中，有关医疗信息安全和电子签名标准的规范条例是其中的重要组成部分。目前，HIPAA安全条例还没有正式公布，但业内人士相信该条例将会在2001年上半年出台。到那时，在美国所有涉及医疗保健的机构中，包括医院、健康计划部门、保健服务商、相关票据交换所、医疗信息系统提供商、医科大学、甚至只有一个内科医生的办公室等，对任何形式的个人健康保健信息的存储、维护和传输都必须遵循HIPAA的安全条例规定，并且大部分组织必须在两年内达到要求。对于违反HIPAA安全条例的行为，可以处以最高为25万美元的罚款和最长为10年的监禁。
在技术方面，HIPAA安全条例是中立的、可升级的。系统安全可在系统的建立、实现、监控、测试和管理过程中不断提高，并且每个环节都可采用多种工具。该条例是一种开放的安全标准，每个医疗机构可以选择适合自身的技术和解决方案。医疗机构必须保存HIPAA安全标准要求的相关文档，并接受对这些资料和相关过程的定期复查。
HIPAA安全条例将安全标准分为四类，以保护信息系统的保密性、一致性和可用性：
管理流程(Administrative Procedures) 建立和落实安全策略；
物理防护(Physical Safeguards) 述如何保护计算机系统实体以及相关的环境和设备，免受自然灾害或人为破坏；
技术安全服务(Technical Security Services) 描述对数据访问的保护和监控；
技术安全机制(Technical Security Mechanisms) 在网络中保护信息和限制数据访问的机制。
保密性即保护数据免受非法访问，如病人的病例属于个人隐私，应予以保密。虚拟专用网VPN采用目前最强的加密算法之一——3DES加密后，可在一个不可信网络的两端建立一个可信的通信管道，基本保证数据的安全性。
数据一致性是指保护数据免受非法修改和删除。数据伪装是常见的对数据一致性的攻击，恰当地配置网络防火墙和路由器可以阻挡大部分攻击。此外，采用“基线”机制，对数据进行基线记录或摘要算法签名，并定期进行基线记录比较或签名比较，检查数据是否被篡改，可有效地保证数据一致性。
可用性是指系统和数据处于可访问和运行阶段的时间长度。目前，最受关注的系统可用性威胁来自于拒绝服务攻击。此外，物理环境的安全问题也应引起重视。
电子签名标准是HIPAA安全条例的另一个重要方面。采用电子签名对在一致性、不可抵赖性和用户认证等方面将起到重要作用。其中，一致性保证数据从发送者到接收者的过程中不被篡改；不可抵赖性证明消息确实由发送者发送并且发送者无法否认；用户认证确保发送者的身份。电子签名中包括对称加密算法（如3DES）、公开密钥算法（如PGP）、摘要算法（如MD5）等。
HIPAA安全条例通过建立医疗保健相关行业的一些通用安全概念，明确了公共准则，制订了操作规范。其现实意义在于，真正认识到信息安全在医疗行业的重要性，并用法案和条例的形式予以规范。HIPAA法案标志着美国在医疗信息系统安全等相关方面发展到了一定的高度，我国医疗信息行业也需要在这些方面继续努力。
PCI DSS
全称Payment Card Industry (PCI) Data Security Standard,第三方支付行业(支付卡行业PCI)数据安全标准，是由PCI安全标准委员会的创始成员(visa、mastercard、American Express、Discover Financial Services、JCB等)制定，力在使国际上采用一致的数据安全措施。
PCI DSS对于支付网关的安全方面作出标准的要求，其中包括安全管理、策略、过程、网络体系结构、软件设计的要求的列表等，全面保障交易安全。
目前支付公司都会被要求通过PCI DSS安全认证，目前有一些第三方支付公司是没有通过这个认证，所以商户在接入的时候要特别注意
PCI DSS 2.0的下载链接：http://yunpan.cn/QIn3Q95Am6bBi
PCI DSS 3.0新增的内容：
最近，支付卡行业数据安全标准（PCI DSS）更新到新版本——PCI DSS 3.0。在某些领域，新要求可能会影响支持该标准的商家和服务提供商（云计算及其他服务）的合规计划。其中，与云计算相关的受影响最大的领域是，持卡人数据环境（CDE）与云计算交互使用的情况。
商家将会发现，云计算中的PCI DSS合规一直是很复杂且具有挑战性的话题，以至于PCI安全标准委员会发布了一整份文档来描述如何在PCI环境下使用云计算。然而，PCI 3.0有几个方面可能让这个已经很复杂的情况变得更加复杂。这并不是因为3.0版本有新语言或专门应对云计算情况的新要求（事实并非如此），或者因为它取代了上面提到的指导文件（并不存在）。相反，这种混乱是因为一些新要求所产生的影响，对于云计算来说很难解决和维护。
PCI DSS 3.0有什么不同？
对于在PCI监管的基础设施中的云计算的使用，PCI DSS 3.0有三个新要求与之最为相关：
Req. 2.4：“对PCI DSS范围内的系统组件进行库存管理。”
Req. 1.1.3：“显示跨系统和网络所有持卡人数据流的当前视图。”
Req. 12.8.5：“明确哪些PCI DSS要求由每个服务提供商管理以及哪些由企业实体管理。”
值得注意的是，这些并不是唯一的新要求，它们也不是对在PCI环境中使用云计算的唯一要求。然而，对于正在使用云计算并已经建立了PCI合规来解决CDE内的使用的企业而言，这三个要求可能在未来几个月中会造成很大的混乱。了解这里的原因需要更深入到每一个要求。
盘点和IaaS
利用云计算的企业必须要注意的第一个要求是盘点系统组件。PCI DSS标准在PCI 3.0文档的第10页描述了“系统组件”的含义，但我们想要强调的关键点是它包括了虚拟机。对任何虚拟环境进行过彻底盘查的企业都知道这有多么困难，但请记住，在云计算部署（特别是基础设施即服务）中，这可能比企业直接控制的虚拟环境更加复杂，尤其是当由服务供应商提供支持时。试想一下，服务提供商支持人员决定克隆一个实例来帮助测试补丁兼容性，或者动态地重新定位镜像来响应性能瓶颈问题。这意味着客户现在必须更加勤奋地追踪CDE内实例的创建和销毁，以保持库存的更新。
为了做好准备，企业有几种选择。最坏的情况下，大多数IaaS供应商将会提供其环境中镜像的原始清单以便进行计费，或者通过其控制面板提供清单。虽然这个清单可能不是企业想要的（例如，它并不会显示镜像的目的或者其中有何软件），但至少这是一个开始。如果你的企业有来自服务提供商的专门技术人员来支持你的账户（例如你是特定供应商的大客户），在创建库存清单时考虑列出供应商的帮助支持。如果你不是大客户或者你的云服务提供商不合适（或成本太高），考虑采用自动化功能；例如，在你的虚拟“黄金镜像”预配置盘查代理，可能有助于捕捉你不知道的新实例或克隆。
数据流和SaaS
下一个挑战涉及在某些云计算环境中映射数据流，特别是软件即服务（SaaS）。与平台即服务（PaaS）和IaaS不同，在SaaS中，应用本身是一个“黑盒子”，这意味着SaaS客户被故意从应用运行的底层机制屏蔽。例如，当你登录到LinkedIn或Facebook时，你知道你的用户ID穿行在哪台服务器或者多少不同的数据库连接到内部后端环境？你关心吗？或许你不在乎，只要你能正确登录。现在，镜像能解决这个要求，它不仅能了解如何进行整个过程，而且还能记录数据采用的确切路径。
现在，请记住，该标准中并没有说数据流图要“知道不可知的情况”，当企业对远程基础设施没有充分可视性，达到这种详细程度并不总是现实的。在另一方面，图表上有箭头指向互联网称，“PAN发送到远程计费供应商”，并不能达到评估员的标准，所以需要寻找一个中间立场，来彻底满足评估，同时没有那么繁琐，让企业可以实现。对此，你可以从记录你所知道的并让供应商完成测试开始。如果他们不能（或者不愿意）帮助向下钻取以及更详细，请确保记录这个事实。你应该向评估者提供证据证明你已经作出最大努力来收集具体数据，这可以让评估人员了解你已经完全考虑过这个要求。
服务提供商矩阵
PCI总是要求企业检查其服务供应商的PCI合规状态，但现在它还要求企业记录哪些PCI要求由供应商负责，哪些由企业自己负责。
这可能听起来像是一件容易的事，但请记住，云供应商（无论是SaaS、PaaS或者IaaS）以及更传统的服务供应商都属于这一类。这意味着企业现在必须确定谁负责特定的PCI DSS控制：企业还是供应商。虽然一些服务提供商（特别是经常服务于商家社区的提供商）已经有他们所提供的控制的现成的清单，其他提供商可能并不会完全认同特定企业对责任划分的观点。这意味着企业需要与服务提供商反复协商来建立一个双方都同意的清单。
PCI DSS 3.0对于商家最重要的五方面影响：
遵守PCI合规的大多数安全专家肯定已经知道，PCI安全标准委员会（SSC）已经发布了支付卡行业数据安全标准（PCI DSS）3.0版。
正如在过去所做的那样，SSC发布了PCI DSS 2.0版到3.0版的变更汇总。如果你是商家或者评估者，从现在到1月份，这两份文件（这个概要以及新版本本身）都应该列在你的阅读清单中，因为1月份新要求将会生效。
当在2010年推出PCI DSS 2.0版时，该委员会预计，该标准的不断成熟化会减少对变更的需要，换句话说，随着标准不断演变，以及新版本的推出，对新要求的需求应该会减少。因此，并不奇怪的是，PCI DSS 3.0版的变更主要是说明和增补信息，（大部分）并不是新要求。
这就是说，与从PCI DSS 1.2.1版到2.0版的过渡不同，3.0版只有一些变更的（新）要求，这些变更反映了商家和攻击者的技术使用方式的变化。具体来说，从PCI DSS 1.2.1版到PCI DSS 2.0版只有两个变更，从2.0版到3.0版则包含20个。当然，我们不能深入讲解每个变更，基于这些变化的范围（在新要求和增补信息或说明之间），我们试图总结了最受商家关注的五个方面。具体来说，对于大部分商家（还有评估人员）来说，下面是可能带来最大影响的五个变更。
第一个方面：穿透测试
也许对现有要求的最明显的变更是穿透测试要求（11.3），包括验证用于隔离持卡人数据环境（CDE）和其他环境的方法的要求（11.3.4）。这一变化的适用范围我们已经在其他文章中讨论过，这部分更新可能给商家带来的挑战在于这个要求：穿透测试活动（内部和外部）现在应该“以行业认可的穿透测试法为基础”，例如专门提到的NIST SP 800-115（《信息安全测试与评估技术指导》）。
好消息是，要求11.3到2015年6月30日才生效，商家们还有一段时间来适应这个变更。坏消息是，很多商家可能难以遵守这个要求，至少在最初阶段。为什么这么具有挑战性呢？主要是因为穿透测试是一个专门的学科，很多商家（特别是较小型商家）没有内部人员能够有效执行穿透测试。商家通常会利用外部服务提供商来满足穿透测试要求；很多这些服务提供商（不点名）的产品并没有基于任何规范的方法。当然，也有服务提供商利用了侧重过程的标准，例如SP 800-115，其中详细说明了在测试阶段需要遵守的具体程序，或者利用以执行为重点的技术标准，例如Penetration Testing Execution Standard或者（对于应用）OWASP Testing Guide（提供技术指导）；但总的来说，这并不是规范的情况。
正因为如此，商家必须要谨慎选择穿透测试服务以确保他们选择的供应商采用的程序遵守行业认可的方法。作为首要工作，所有准备PCI DSS 3.0合规计划的商家都应该采用行业认可的方法（你企业认为合适的方法）作为穿透测试请求建议。
第二个方面：系统组件清单
虽然在媒体方面没有很多讨论，但从实际角度来看，另一个可能带来潜在巨大影响的新要求（2.4）是：“保留一份PCI DSS范围内系统组件的清单。”这里的“系统组件”在该标准的第10页（PCI DSS要求的范围）有详细介绍，但本质上它是指持卡人数据环境内的所有硬件（虚拟或物理主机及网络设备），以及软件组件（自定义或商业产品、现成的应用，无论是内部还是外部）。
该要求的测试程序明确要求评估员“检查系统清单，确认已保留一份软硬件组件列表，并包含各自的功能/用途描述”；也就是说，商家不仅需要记录持卡人数据环境中所有组件，还需要描述这些组件的功能以及用途。11.1.1要求（与此相关）现在要求商家“保留一份授权的无线接入点清单，包括业务理由记录”。
我们都知道，保持清单的更新并不容易。历来，商家对保持清单（包括持卡人数据位置、可以访问加密密钥和持卡人数据的人员，以及防火墙规则和描述）的要求一直难以满足。为什么呢？因为这种清单经常变化，经常需要手动工作来准确反映环境实际组件情况。因此，在没有自动化的大型或复杂的环境，维持硬件和软件组件的可靠清单几乎成为不可能完成的任务（任何曾经试图努力维护过这种清单的人都能证明这一点），至少是不容易。
当涉及虚拟化（因为系统组件也包括虚拟镜像）或者当环境分布在多个地理位置（大多数分布式零售店都是这样）时，更是加剧了这种复杂性。同时，当专有的供应商提供的系统是由外部人员（例如应用供应商或系统集成商）维护时，也会提高复杂性。对于一个本身就难以满足的要求，这些因素无疑是雪上加霜。毫无疑问，商家们的IT和合规团队将需要花大量时间来开发和钻研方法以创建和管理这种清单。
第三个方面：供应商关系
12.8.5和12.9要求现在要求明确由各个服务提供商和实体管理的PCI DSS的信息。例如，如果企业使用托管数据中心供应商，该数据中心的物理访问限制可能由该供应商管理，而对这些位置访问权的管理方面可能是由客户企业管理。在这种情况下，PCI DSS 3.0要求商家明确同意并以书面形式确认这种与供应商或服务供应商的职责分配。
这种要求意味着，现在商家不仅需要维护供应商清单（这是3.0之前的要求），以及当其服务与其CDE交互时追踪其合规状态（也是3.0之前的要求），而且要明确对于PCI DSS要求，每个适用的供应商的相应的责任分配，还必须与供应商签署书面协议。
维持和管理这些不同的要求在实践中可能具有挑战性。为什么呢？主要有两个原因：首先，它涉及检查所有CDE相关的供应商（理想情况下，商家有这个清单，因为他们应该在追踪供应商的PCI合规状态）；第二，它涉及准确分析每个特定供应商的使用情况。在实践中，商家必须明确知道供应商或服务供应商在做什么（以确定其范围），控制职责应该如何划分，以及如何创建文档来描述这些事情。接下来是有趣的部分：让相关的服务供应商（注意，他们看待问题的方式可能与你不同）同意并签署书面协议。曾经参与过供应商协商的人会告诉你，协商这些问题（特别是在已经与服务供应商签署合同后）将是耗时的工作，而且可能会出现争议（这取决于供应商）。
第四个方面：反恶意软件
要求5.1.2现在要求商家：“对于通常不受恶意软件影响的系统，需要执行定期评估以确定并评估不断进化的恶意软件威胁”。这意味着，如果你使用的系统通常不会受到恶意软件感染（例如大型机或Unix服务器），你需要部署一个程序确保保持这种状态，如果这些平台出现一些恶意软件，你需要知道这个情况。要求5.3现在要求必须从管理层获得明确授权，才能禁用或更改杀毒机制的运作，并且，这种授权是有时间限制的。
对于不同的企业，这些要求可能会有一定的影响，特别是第二个要求。在PCI DSS 2.0中，该标准仅要求部署防病毒软件，并且它是运行的，还有更新或最新版本，且必须具有生成日志的能力。这些要求是可以满足的，无论谁安装这个工具，它是如何被安装（在合理范围内，只要它不影响上述要求）或如何被配置。但现在事情不是这样了。现在，商家必须防止用户禁用或更改杀毒机制（这可能需要特定的配置），并需将杀毒系统配置为利用这种能力。这可能同时需要更高水平的技术规划（因为这可能会影响防病毒工具和OS配置）以及部署策略来在整个CDE验证这种能力。毫无疑问，大多数商家将会通过更多文书工作来满足这一要求，但这种变化并不会像上述要求那么难以应对。
第五个方面：物理访问和PoS机
9.3要求现在要求商家控制现场人员对敏感区域的物理访问，这种访问必须获得授权，且根据个人的工作职能，同时，当访问终止时，访问权应随即被撤销。9.9要求现在要求商家“保护通过直接接触卡本身便可捕获支付卡数据的设备，以避免设备被篡改和替换”。大多数商家可能已经在试图满足9.9要求，但如果有商家仍然在零售点使用服务器机柜来存放纸巾，现在可能是时候停止这种行为了。
不过，满足9.9要求可能有点麻烦。为什么呢？试想一下，从商家的角度来看，哪里最有可能适用：零售点、餐馆、医生办公室、食品车、出租车和其他独特的零售环节。这些零售商习惯于“定期检查”销售点终端设备（PoS）吗？例如检查序列号以确保设备没有被更换。不太可能。想象一下，对跨多个地理位置分散的零售点进行这种检查需要付出多少努力。同样地，用于该要求的测试程序特别明确验证政策/程序包含“保存一份设备列表”。有多少商家现在有自己的PoS设备列表？虽然这肯定是一个很好的做法，但现实是，很少有商家这样做。对于站点管理员或零售场所管理者，这一切很可能是全新的概念，可能需要相当多的社会化、准备和人员培训来全面展开。
总结
正如你所知道的，对于这些新的和更新的要求，有些商家需要做很多工作。请注意，上述这些并不是唯一的变化，当然，具体使用环境和企业文化将会影响企业对这些要求的满足。然而，这些是对商家影响最大的PCI DSS 3.0变化，至少在过渡期内是这样。在某些情况下，这些影响是很明显的（例如穿透测试），可能对于有些人来说，只有在着手执行这些要求（例如盘点系统组件）时，才会意识到这些影响。无论如何，商家必须现在开始规划以确保他们已经准备好应对这些变化。否则，在2014年或2015年的第一次PCI DSS 3.0评估可能不会是一次愉快的经历。
ISO 27001信息安全管理体系
即国际标准组织 (ISO) 27001 标准。ISO 27001 是被广泛采用的全球安全标准，明确了信息安全管理系统的要求。它提供了一种基于定期风险评估的管理公司和客户信息的系统方法。为了达到认证要求，公司必须显示其拥有系统化且可持续使用的方法，用于管理影响公司与客户信息的机密性、完整性与可用性的信息安全风险。
该体系的文档，请在网络上搜索相关的标准及文档
FedRAMP (SM)
联邦风险和授权管理项目，也称为 FedRAMP，将会采用一个"cloud-first"政策，这样会使云服务提供商（CSPs）实现基本的安全需求标准化，比如说谷歌和微软，在签订政府的合约之前，将不得不聘请第三方评估机构来验证：公司的云服务是否满足基本的云安全要求。

这次改革的目的，第一是要提高IT领域的采购计划，第二，这也是在政府转移计算机服务的进程之中，比如说电子邮件系统、基于云计算的系统。政府的技术项目在最近几个月已经关闭，因为它们的运行已经超过了预算而且落后于正常的日程安排，所以政府提高了IT行业的安全性标准的优先级,这样做的主要目标是要建立一个统一的安全框架，以便制定的规则和政策能在多个项目之间顺利的执行。
项目将如何工作？
此项目将会使云产品和云服务的安全性标准化，并加速其通过。目的是要设置一个政府能够完全掌控的云安全程序，这也就意味着，供应商在对云计算的项目进行投标时，不用再重复云计算服务安全性的审批过程了。
在这项经由第三方评估机构认可的列表中，包含了超过 160 个安全控件，来帮助企业进行安全性的身份验证，其中就包括垃圾邮件筛选器和加密标准。
项目的优势是什么？
减少评估多个机构之间相同的的云计算产品的冗余性。对于公司来说，卖给政府产品的时间会大大的缩短。
增加重复使用现有的跨机构的安全评估。
节省大量成本、时间和资源。
增强了政府和云服务提供商 (CSPs) 之间的透明度。
提高了联邦安全授权过程的可信赖性、可靠性、一致性和质量。
该项目是由公众服务管理者参与管理，它也是国土安全部的管理的一部分。如果该项目能成为云计算服务安全的一项标准，相信不仅仅是对为政府工作的云服务提供商（CSPs）甚至对整个行业来说，都是值得期待的，那将是云计算领域的一场伟大的胜利。相信不久的将来，我们就会看到这是不是一个很好的项目。
DIACAP 和 FISMA
美国政府机构可以通过来达到并且维持联邦信息安全管理法案 (FISMA) 的要求。基础设施已经通过独立评估员的评估，适合在各级政府系统内作为系统负责人批准流程的一部分。许多市政和国防部 (DoD) 的单位已经按照 NIST 800-37 中定义的风险管理框架 (RMF) 流程和 DoD 信息保证认证和鉴定流程 (DIACAP)，成功为托管的系统获得安全性授权。安全基础设施已经帮助联邦机构在遵守联邦标准严苛的安全性要求的同时扩展云计算使用案例，以及在云中部署敏感政府数据和应用程序。
ITAR
遵守美国国际武器贸易条例 (ITAR)。作为管理全面 ITAR 合规性项目的一部分，受 ITAR 出口条例规范的公司必须掌控防止意外出口，方法是限制美国公民对受保护数据的访问，以及限制该数据在美国境内的实际位置。提供了位于美国境内的实体环境，能够访问的仅限美国公民，从而允许有资质的公司在传输、处理和存储受保护的文章和数据时受到 ITAR 限制。（美国）环境由独立第三方来审计，以验证是否采取了适当控制来支持客户达到出口合规性项目要求。
FIPS 140-2
FIPS是美国联邦信息处理标准(Federal Information Processing Standard)的缩写。
基于美国信息技术管理改革法案(公法 104-106)，商务部长批准了美国国家标准和技术委员会(NIST)制定的针对联邦计算机系统的标准和方针。这些标准和方针由NIST发布，并作为联邦信息处理标准(FIPS)在政府机构广泛采用。NIST针对强制性的联邦政府需求制定FIPS标准，比如安全和互操作性，同时针对那些尚未形成可接受的工业标准或解决方案的需求，制定FIPS标准。

欢迎光临中神通公司技术论坛 (http://trustcomputing.com.cn/bbs/)