患者数据在云中的隐私和安全性

美国法律下云提供者和用户各自的责任

本文的目标是帮助云服务的提供者和用户了解并遵从美国医疗法律在安全性和隐私方面的要求。本文首先会让您对相关法律有一个基本了解,然后会讨论这些法律对云服务的具体要求,涵盖的内容包括数据控制、访问、完整性以及可用性;共享的多租户环境;事故准备和响应;以及数据安全性。(不应将本文中的任何内容视为法律建议。)

Erin Gilmer, 律师

http://www.ibm.com/developerworks/i/p-egilmer.jpgErin Gilmer 是德克萨斯州奥斯汀的一名患者志愿者和律师,专门研究 HIPAA 和 HITECH。她获得了美国科罗拉多大学法学院的法律学位,并于 2008 年加入德克萨斯州律师协会。2005 年,Gilmer 女士以最高荣誉 从美国科罗拉多大学毕业,获得了心理学和经济学学位(偏国际方向),并辅修了政治学。Gilmer 女士之前在德克萨斯州律师协会和几个非盈利组织工作过,其中包括德克萨斯州残障权利署和德克萨斯州法律服务中心。Gilmer 一手创办且目前领导着 Health 2.0 Austin



2013 年 3 月 11 日

新的技术(从电子医疗记录到医疗设备,再到移动和 Web 应用程序)为医生改善患者的健康状况和救治生命提供了很大的帮助。医生们使用这些技术来收集较之前多很多的信息,从而通过所收集的数据了解患者的健康状况。这些技术及其包含的数据不断地连接和交互,通过日益复杂并且风险和漏洞也随之渐增的系统发送健康信息。医生不再是这些私密的健康信息的惟一被授权人。如今,还有其他人(比如管理数据存储的人)可以访问这些信息因而也有责任保护这些信息。

认识到健康信息的敏感性之后,美国政府于 1996 年颁布了医疗信息流通与责任法案 (Health Information Portability and Accountability Act, HIPAA) 并在 2003 年颁布了医疗信息技术促进经济和临床健康法案 (Health Information Technology for Economic and Clinical Health, HITECH Act)(参见 参考资料)。这些法律要求负责敏感健康信息的实体实施某些措施来确保隐私和安全性,并在患者信息的隐私和安全性遭受危害时通知患者。

当用户迁移到云服务时,对于履行义务和维护(泄露了其私密的健康详细信息)患者的信任的实体来说,理解这些标准以及严格遵从这些标准至关重要。为了给解决与云服务相关的问题提供一个基础,本文首先会让您对 HIPAA 和 HITECH 有一个基本的了解,包括这些法律、规则以及法规适用的对象。然后,为了帮助防止云服务的用户和云提供者与 HIPAA 和 HITECH 要求发生冲突,本文讨论了数据控制、访问、完整性以及可用性的问题;共享的多租户环境的具体要求;事故准备及响应;以及数据安全性。

HIPAA 和 HITECH Act

对于 HIPAA 的讨论通常都会忽略一系列复杂的法律、规则以及法规的复杂性。经常提到的两个术语是隐私安全性,但没有考虑到 HIPAA 和 HITECH 的细微差别部分,因此会模糊合规性的意义。

HIPAA

受保护的健康信息

根据 HIPAA,有些信息被认为是受保护的健康信息 (protected health information, PHI)。PHI 包含患者的过去、现在或未来身体或精神上的健康情况;对患者提供的医疗服务;患者过去、现在或未来的医疗支付情况;以及能够确定身份的信息,即标识符。PHI 包括个人的身份信息 (PII),比如姓名、地址、与患者相关的日期(出生日期或服务日期)、电话号码、传真号码、电子邮件地址、URL、IP 地址、社会保险号、帐号、车牌号、医疗记录号、健康计划受益人号、设备标识符及其序列号、车辆标识符和序列号、生物计量标识符以及照片。换言之,PHI 包括了能够追溯到某个患者的所有惟一的标识号、代码或特征。

电子受保护健康信息 (Electronic protected health information, EPHI) 实际上是一种 PHI 或是以电子形式创建、接收、维护或传输的个人身份健康信息。Privacy Rule 适用于所有形式的 PHI(无论是手写的、打印的、电子的还是口头的),而 Security Rule 只适用于 EPHI。

HIPAA 包含面向某些健康信息的特定隐私标准和安全性标准,即 HIPAA Privacy Rule ("Privacy Rule") 和 HIPAA Security Rule ("Security Rule")。HIPAA 将这些规则应用于所涵盖的实体,包括医疗提供者、健康计划以及医疗结算中心。

根据美国卫生与公众服务部 (U.S. Department of Health & Human Services, HHS) 的网站(参见 参考资料):

HIPAA Privacy Rule 提供了联邦政府对所涵盖实体持有的个人健康信息的保护,并为患者提供了与该信息有关的各种权利。同时,Privacy Rule 也作了均衡,以便允许为了患者的治疗以及其他重要目的而公布个人健康信息。

而 Security Rule 则 “指定了一系列针对监管、物理以及技术保护措施,供所涵盖的实体用来确保电子受保护健康信息的机密性、完整性和可用性”。

HITECH Act

HITECH Act 是对 HIPAA Privacy 和 Security Rule 的扩展,该法案提高了对违反 HIPAA 的处罚。之前,HHS 民权办公室 (Office for Civil Rights, OCR) 的管辖权只限于所涵盖实体对隐私权的触犯。根据 HITECH Act,HIPAA Privacy 和 Security Rule 可通过扩展适用于业务伙伴 (BA),即代表所涵盖的某个实体(或作为向该实体提供的一项服务)执行某些涉及到 PHI 的使用或泄露的功能或活动的个人或实体。如今,OCR 也具有对 BA 的执法管辖权。BA 通常都会提供诸如索赔处理或管理、数据分析、使用评估或实践管理等服务。直接代表所涵盖的某个实体或通过另一个 BA 间接代表某个实体而存储 PHI 的云提供者也可视为是一个 BA。


作为 BA 的云提供者

云提供者作为一个承载 EPHI 的 BA 有其自己的独特之处。在 HIPAA 颁布之时,“云” 的概念还未出现,而且可能还没有任何预见。越来越多的所涵盖的实体和其他 BA 都选择在云中存储健康信息。这么做的常见原因包括成本节省、存储管理、平台优势、资源可用性、备份和恢复以及 IT 维护的减少(参见 参考资料)。但是,若将 EPHI 存储在云中,用户实际上就将其泄露给了云提供者,云提供者也就成为了一个 BA。出于该原因,云提供者必须也要遵从 HIPAA 和 HITECH 的规定。

业务伙伴协议与云

当将 EPHI 存储在云中时,清晰的业务伙伴协议 (BAA) 的重要性不容低估。BAA 本质上是一种服务水平协议 (SLA),内含关于 HIPAA 和 HITECH 合规性的特定规定。所涵盖的实体必须要与其提供 EPHI 的 BA 签订 BAA。同样,BA 也必须与其传递信息的对象签订 BAA。这些 BAA 必须包括 BA 遵从 HIPAA Privacy 和 Security Rules 的具体保证。BAA 还应该包括与服务的访问和使用、服务的期限、终止条件以及终止后数据的处理等相关的条款和条件。此外,BAA 应该包括一个隐私策略,概括出信息处理的做法以及云提供者如何收集、使用和管理用户信息。最为重要的是,虽然 EPHI 的安全性和保护责任可以转移或共享,但 BAA 应明确指出数据的所有权 不可以转让给云提供者。

HIPAA 允许所涵盖的实体无需取得患者的同意就可以为了治疗、支付和医疗操作交换 EPHI。不过,应该只公开为了实现这种交换目的所必需的最少量 EPHI。因此,所涵盖的实体可以彼此之间或与 BA 交换 EPHI。但是,在将这些信息发布给 BA 之前,所涵盖的实体必须得到满意的保证,即 BA 会恰当地保护所涵盖实体提供的所有 EPHI。而这正是通过业务伙伴协议 (BAA) 完成的。

泄露

HHS 将对 EPHI 的 泄露 定义为 “一种未经允许的使用或披露...损害了受保护健康信息的安全性或隐私,以至于这种使用或披露对受影响的个人带来了财务、声誉上的巨大风险或其他伤害”。

自 2009 年起,在大规模的医疗记录泄露中,有近 2100 万的个人 EPHI 受到了损害,大规模泄露是指影响 500 多人的泄露(参见 参考资料)。在大规模泄露中,21% 的泄露会影响到 BA。此外,涉及 500 条记录以内的数以万计的泄露已经报告给了 OCR。

大规模泄露最常见的原因是偷盗 (55%),然后是 EPHI 未经授权的访问或披露 (20%)、信息丢失 (11%)、遭黑客攻击 (6%)、不当处理 (5%) 以及未知/其他 (3%)。图 1 给出了详细的分类:

图 1. 医疗数据的泄露
大规模医疗数据泄露的最常见原因

法规指南

由于云是一种新的概念,法规指南还在制定当中。撰写本文之时,HHS 还未发布 HITECH 实现的最终规则。美国国家标准技术研究所 (National Institute of Standards of Technology, NIST) 已经发布了一些指南,最近,美国国家医疗信息技术协调办公室 (Office of the National Coordinator for Health Information Technology, ONC) 也发布了一些。如果没有联邦政府级别的指南,像医疗信息管理系统协会 (Health Information Management Systems Society, HIMSS) 和云安全联盟 (Cloud Security Alliance, CSA) 这样的协会就会发布指南。有几种行业标准都在开发当中,包括 HITRUST Common Security Framework (CDF)、CSA Common Control Matrix (CCM)、互联网安全中心 (Center for Internet Security, CIS) 基准,以及美国国家安全局 (National Security Agency, NSA) 配置指南。

但是这些数字可能会有误导性。偷盗 不再意味着只是纸质图表的偷盗,还包括笔记本电脑的偷盗。同样,信息丢失 也有可能指的是闪存盘的丢失。并且这些数字反映了数据泄露在过去的状态;越来越多的信息开始实现电子化并以新的格式(包括在云中)存储的事实必然会更改这些统计数字的构成。随着到云中的迁移,出现了对 EPHI 的新的恶意攻击方法。现在,这些攻击威胁着离站存储的 EPHI,其中对那些最初承载 EPHI 的实体具有较少的控制。

无论数据泄露如何发生,违反 HIPAA 在州政府和联邦政府一级都会受到刑事和民事的处罚,根据 HITECH Act 的处罚力度更是有所提高。在联邦范围内,民事处罚最多可达每年 150 万美元,刑事处罚则包括 10 年监禁和最多 250,000 美元的罚款。这还未将州政府一级的处罚考虑在内。

与云有关的问题

将数据传输到云中带来了独特的问题,这些问题使得所涵盖实体、传统的 BA 以及如今的云提供者自身的 HIPAA 合规性更为复杂了。这其中包括控制、访问、可用性、共享的多租户环境、事故准备和响应以及数据保护的问题,在本文的其余部分中,我将一一进行讨论。虽然在云中存储 EPHI 具有很多好处,但是用户和云提供者都必须要知道这些问题是如何影响 HIPAA 和 HITECH 合规性的。


数据的控制

当用户依赖于云提供者存储其数据时,也就从应用程序级别开始放弃了对数据的直接控制。自此,随着云部署模型与数据的地理位置混合在一起(带来了谁能访问数据的问题),更是进一步牺牲了数据控制。了解谁能控制数据以及谁负责该数据,这对于了解如何维护合规性十分重要。由于在将 EPHI 传输到云中时发生了这种控制上的转移,所以用户和提供者都应该在服务提供之前在 BAA 中明确指出谁负责数据的隐私和安全性。

通过 IaaS、PaaS 和 SaaS 控制用户的数据

通过 IaaS,云提供者可以提供处理、存储、网络以及其他资源,这让用户得以部署和运行任意软件。用户控制操作系统、存储、部署好的应用程序,还可能控制一些联网组件,因此必须承担更多的责任。PaaS 让用户得以使用受提供者支持的语言和工具在云基础架构上部署其自己或已获得的应用程序,但这只给用户留下了对这些应用程序的控制。通过 SaaS,用户使用的是云提供者的应用程序,因而控制更少。在每个级别上,所涵盖的实体或 BA 都在选择牺牲控制来换取实现所提供服务的收益的机会。(本文对云服务级别模型的描述主要是以 CSA 的 “Security Guidance for Critical Areas of Focus in Cloud Computing” 为基础;参见 参考资料。)

应用程序和基础架构

云计算服务级别模型包括:软件即服务 (software as a service, SaaS)、平台即服务 (platform as a service, PaaS) 和基础架构即服务 (infrastructure as a service, IaaS),这些模型为用户提供了不同级别的控制,通常都会涉及相应的安全性权衡。用户和提供者都必须为各自的组织找到正确的平衡点,以及丧失数据控制后他们愿意承担的风险。虽然这些模型中没有一个会给用户提供对基础的云基础架构的控制,但用户的确可以在使用 IaaS 时拥有更多的控制,在分别使用 PaaS 和 SaaS 时拥有较少的控制。当在任何应用程序或基础架构级别签订协议时,有一点仍不清楚的是,数据的责任是部分还是全部转移给云提供者,这是因为原始数据所有者不再拥有完全的控制。HIPAA 和 HITECH 合规性的具体要求之一就是,无论谁拥有 EPHI 数据的控制权,其承担的数据安全性、数据泄露监视、审计以及风险管理等的责任都会增加。

部署模型

无论是在应用程序还是在基础架构级别,云部署模型本身都会影响数据的控制。对于一个公共云 模型,基础架构对公众开放,因而在部署数据时就会失去固有的控制。另一方面,私有云 的基础架构只对单个用户开放。社区云 则只对特定社区开放,混合 云使用了公共和私有云两种模型。对于最高级别的控制以及最佳的隐私和安全性,应该为 EPHI 使用私有云模型。不过,公共云也可用来存储 EPHI,而事实上,美国疾病控制中心 (Centers for Disease Control) 就为症状监测数据使用了这样一种模型(参见 参考资料)。但是,使用公共云会使 EPHI 的缺陷更容易公开,所以选择使用此模型的用户务必考虑周全。

很多云提供者都认识到了 EPHI 的独特性质,并将其部署模型更改为提供专为存储 EPHI 打造的云服务。比如,有些提供者已经隔离出部分云服务专门用于 EPHI 相关的数据。不过,也有很多提供者还没有这么做,这些服务有可能会遇到用户不愿付费的风险。因而,在应用程序以及基础架构级别,用户会通过部署公共、私有、社区以及混合云模型来选择他们愿意承担的风险等级。无论用户是在何处部署,根据他们对该数据所拥有的控制权,云提供者仍有义务按照 HIPAA 和 HITECH 的规定保持 EPHI 的隐私和安全。

地理位置

云服务允许将数据存储在多个位置,这在发生突发事件(比如停电、火灾、故意破坏、系统故障或自然灾害)时会很有帮助。将数据存储于用户操作位置之外的位置(或者,在多个位置产生冗余或进行备份)就可以再次保证关键的业务操作不会发生中断。

但是,不知道数据存储于何处的用户会失去对 EPHI 的另一个级别的控制。知道数据所在位置对于了解应该遵从哪些法律、规则和法规至关重要。某些地理位置有可能会使 EPHI 受国际法律的约束,有可能会改变 HIPAA 和 HITECH 法案规定下数据访问权的持有人。


数据访问

如果用户在多个级别失去了对数据的控制,那么问题就成了谁将能够访问该数据以及如何管理访问。根据最低必要原则,对 EPHI 的访问必须仅限于那些需要访问它的人。但是由于由云提供者维护的数据有可能存储于多个位置,且每个位置都有各自的员工,如果没有与第三方签约,这就有可能比较复杂。根据所涉及的实体的数量,越来越多的个人都会有机会访问云中的 EPHI,这就增加了数据的安全性风险。

云提供者和用户必须通过实现和管理访问特权的创建和修改来共同确保安全性。而这首先需要决定某个用户或计算机系统是否具有执行某些活动(比如读取一个文件或运行一个程序)的权利。

为个人赋予访问权限

用户的责任之一就是定义谁具有云中存储数据的访问权限,而云提供者的责任则是执行这些决定。但是在一般情况下,能够访问 EPHI 的所有员工都应该通过员工审查程序。用户、云提供者以及与云提供者一同工作的人都应该创建能准确反映分配给每个人的职责和责任的工作描述,并实现监管。

能访问云中 EPHI 的所有员工(无论是云提供者的员工还是用户的员工)在接受 Privacy and Security 规则的正式培训之前,都应该被赋予惟一的用户名并知道该如何保管好登录信息。应该根据每个用户自身的角色赋予其访问权限,并且访问权限也应根据需要立即修改或取消。

身份验证

根据 HIPAA,必须实施一定的程序来验证寻求 EPHI 访问权的个人或实体是否名副其实。这可以通过登录系统来完成,包括员工的惟一用户名和密码以及其他的度量。但是由于管理用户系统以及云提供者系统的多个登录帐号十分繁琐,有些云提供者提供了与用户内部的身份验证系统的集成。这可以通过轻量级目录访问协议 (Lightweight Directory Access Protocol, LDAP) 机制或通过使用单点登录 (SSO) 技术实现。但是,这些方法本身又引入了其他的安全性风险。

云提供者还会使用安全性断言标记语言 (Security Assertion Markup Language, SAML) 来执行实时的身份验证、授权交易,以及赋予和撤销用户访问权。但是,根据 NIST Guidelines on Security and Privacy in Public Cloud Computing(参见 参考资料),只有 SAML 可能还不够,云提供者还可能会使用可扩展访问控制标记语言 (eXtensible Access Control Markup Language, XACML) “来调整云用户的特权以及维护对资源访问的控制”。

审计访问

就访问权而言最为重要的是,云提供者和用户都需要就访问审计的过程达成一致。Security Rule 要求定期审查信息系统活动的记录(比如审计日志、访问报告以及安全事故跟踪报告),以便能发现 EPHI 的任何不当公开。并且,还必须要实现软硬件和/或程序机制来记录和检查包含或使用了 EPHI 的信息系统中的活动。ITECH Act 则更是要求监视对 EPHI 的泄露。这是对 HIPAA 和 HITECH 规定的一个十分重要的考虑,因为它适用于事故响应和泄露提示法律以及最终停止并缓减泄露的能力。

完整性

EPHI 的完整性受谁能访问数据的影响。用户和提供者不仅需要确立谁能访问存储在云中的 EPHI,而且同样重要的是,要维护好数据的完整性以免遭受伪造。实际上,完整性是 Security Rule 的首要目标之一。Security Rule 将完整性定义为 “数据或信息未在不经授权的情况下发生更改或遭受破坏的属性”。当将 EPHI 存储在云中时,对 EPHI 的访问也就相应地增加。因此,确保数据的完整性就愈加困难。


共享的多租户环境

公共云服务能够提供成本节约,这是因为基础架构常常包含了共享的多租户环境,用户可以借此与不认识的其他用户共享组件及资源。但是这种特性也带来了很多相关的风险,包括一个用户有机会访问另一个用户的数据,以及有可能会将数据混合。此外,在一个共享的多租户环境中,一个用户的使用可能会降低另一个用户资源的可用性和性能,并且云提供者的升级或修补有可能会妨碍用户的业务运营。此外,共享的基础架构还会带来云提供者可能无法将一个租户的活动与另一个租户的活动分离的风险。而这会对数据的实时监视和审计以及数据删除产生影响,二者对于保持对 HIPAA 和 HITECH 的合规性至关重要。为了解决这些问题,云提供者应该明确定义其隔离措施,包括虚拟化技术、应用程序级别隔离或数据库级别隔离。


数据的可用性

Security Rule 的宗旨之一就是 EPHI 的可用性,尤其是在面对突发事件或其他事故时。将 EPHI 移到云中的好处之一就是云服务可以通过多种方式提高数据的可用性。在多个位置存储冗余数据的云服务可以更好地从突发事件中恢复。此外,可按需提供的资源容量带来了服务要求提高时的弹性,而且还能使平台最小化修补和维护期间的定期服务中断。而且,云服务还能减少拒绝服务攻击,这会使得当目标中充满多个伪请求时致使数据不可用,从而避免了实时合法化请求的响应。

最后,云服务还可以使用一个 Web 浏览器或是由云提供者提供的应用程序通过 Internet 或虚拟专用网 (virtual private network, VPN) 交付,换言之,即接口服务。但是,接口会给 EPHI 带来数据在传输、伪造或数据损坏期间被截获的风险,以及在客户端和服务器端进行身份验证的风险。开放 Web 应用程序安全性项目 (Open Web Application Security Project, OWASP) 列出了在应用程序架构和设计以及整个软件开发生命周期内不容忽视的前 10 个 Web 应用程序漏洞(参见 参考资料)。


事故准备和响应

事故响应是 HIPAA 和 HITECH 合规性的关键问题。无论部署多少保证措施,我们都知道并不是所有的事故(无论是灾难、未经授权的访问、偷盗、黑客攻击、丢失、员工失误等)都是可以预防的,Privacy and Security Rules 强调了:

  • 事故响应以及减少损失的重要性
  • 在关键业务运营期间限制中断
  • 维护 EPHI 的安全性和隐私

事故准备

在发生事故之前,用户和提供者都必须准备好一些策略和程序,比如应急计划。他们必须前瞻性地监视有无威胁和漏洞。Security Rule 要求的第一个保障措施是执行风险评估。用户应该为内部存储的数据以及存储在别处(比如在云中)的数据定期执行自己的风险评估。而云提供者则应该执行其基础架构的风险评估。发现的任何漏洞都应该使用文档记录。至于云提供者,这些漏洞应该报告给用户,以便他们能够决定相关风险是否能够接受或如何解决这个漏洞。

除了确定 EPHI 的位置以及执行风险评估外,用户还必须确保数据及时备份。更具体地说,就是要创建并维护 EPHI 的一个 “可恢复的副本”。云服务提供了离站数据备份,可帮助满足这一要求。但是有些问题仍然存在,比如数据在何处备份,如何获取所备份数据的访问权限,最近是何时备份的以及保存多久。

而且,正如之前所提到的,访问管理十分重要。用户和云提供者都必须监视访问,并确保只有经过授权且能通过身份验证的人才能访问 EPHI。不再具有访问权限的用户应该从用户列表中删除。

最后,云提供者和用户均应不断测试有无漏洞,并相应地修改自己的策略和程序。云提供者应立即向其用户报告他们所做的任何更改以及测试后发现的任何问题。

事故响应

云提供者在事故响应中的作用不可或缺,应负责事故验证、事故分析、防范、数据收集、保留、问题补救以及服务恢复。正如之前所提到的,对审计日志的访问是攻击分析和事故响应中的首要步骤之一。在提供者查阅了这些日志以及其他的签定信息后,他的防范措施就可以向前推进了,同时必须谨记要确保 EPHI 的机密性、完整性以及可用性。借助于冗余或备份数据,云提供者就可以恢复到之前的状态。

用户应该概述一下在事故发生时希望云提供者怎么做,尤其是,如何验证事故以及如何收集分析事故所需信息。此外,用户和云提供者还应该讨论恢复时间目标以及恢复点目标,并应确保二者都会以协调的方式进行响应。


数据保护

处于传输、静止以及备份中的数据可以通过几种方式进行保护。大多数保护措施应该由云提供者负责,这是因为他们能够控制 EPHI。这些措施包括监视有无数据泄露、加密、密钥管理和数据删除。

监视有无数据泄露

由于用户将数据的控制权交给了云提供者,所以他们必须依赖于云提供者使用的流程来监视系统有无数据泄露。这包括防火墙的使用、网络入侵检测、服务器日志监视以及最终用户访问文件监视。不管他们使用何种方法,云提供者都应该定期执行检查来确保这些方法正常运行。并且如果检测出了泄露或发现了漏洞,云提供者必须将其报告给用户。

加密

实体可以加密数据,使得未经授权的个人不可用、不可读或无法破译这些数据。根据 Security Rule,EPHI 加密包括 “使用算法流程将数据转换为表单,在该表单中,如果不使用保密流程或密钥,能够理解意义的概率就很低”,并且没有泄露启用解密的这个保密过程或密钥。根据 OCR,用户和云提供者可以使用由 NIST 测试过的有效加密过程。对于处于静止状态的数据,数据加密应该与 NIST Special Publication 800-111 一致;对于传输中的数据,数据加密在符合 NIST Special Publications 800-52 和 800-77 时才会有效(参见 参考资料)。

密钥管理

加密密钥管理方案是确保数据安全的另一种方式。这个工具可以由用户使用或由云提供者提供。虽然有些已经采用了密钥管理,但行业标准仍在形成当中,比如电气与电子工程师协会 (Institute of Electrical and Electronics Engineers, IEEE) 的标准,以及密钥管理互通协议 (Key Management Interoperability Protocol, KMIP) 的开发者 “结构化信息标准促进组织 (Organization for the Advancement of Structured Information Standards, OASIS)” 的标准。已经使用了密钥管理方案的用户必须考虑几个要点,比如如何保持密钥存储区的安全性、限制对密钥存储区的访问,以及确保实现了备份和恢复解决方案。

数据删除

根据 Security Rule,所涵盖的实体以及 BA 都必须 “实施策略和程序,解决受保护的电子健康信息和/或存储这些信息的硬件或电子媒介的最终处置”。因此,如果需要,云提供者必须要确保正确删除 EPHI 且不能重新创建(包括从备份副本中重建)。这类数据清理会涉及到通过覆盖、消磁或其他方式从存储媒介删除 EPHI。若遵循 NIST Guidelines for Media Sanitization,OCR 则会考虑清理、清除或毁坏存储或记录 EPHI 的媒介。在公共云中,通过物理方式并置或混合的数据可能会复杂化数据损毁坏并会需要额外的工作。


结束语

随着数据存储世界的改变以及更多 EPHI 迁移到云中,HIPAA 和 HITECH 的要求也在不断演变。用来确保 EPHI 完全受到保护的 Privacy and Security Rules 现在也适用于 BA(包括云提供者)。在用户(不管是所涵盖的实体还是 BA)和云提供者(本身也是 BA)之间,随着 EPHI 从一个实体转移到另一个实体,责任也发生了相应的变化。责任可以从用户完全转移到云提供者,也可以由二者共享。随着这些变化而来的是因合规性而带来的要求。

在云中,控制、访问、可用性、共享的多租户环境、事故准备和响应以及数据保护的问题开始出现。通过了解这些问题,云提供者和用户就能认识到各自的责任。

最后,责任不仅对 HIPAA 和 HITECH 合规性非常重要,对诚信也很重要。医生将那些公开了个人最隐秘的详细信息且其 EPHI 可能存储于云中的患者的关键信息委托给 BA。如果患者的 EPHI 遭到破坏,患者就会对医生失去信任,进而会贻误治疗。因此,HIPAA 和 HITECH 的重要性远不止于法律。EPHI 不仅仅是数据;它还代表了个人、人的身体状况以及生命。

参考资料

学习

获得产品和技术

  • 以最适合您的方式 评估 IBM 产品:下载产品试用版,在线试用产品,在云环境下使用产品,或者在 SOA 沙盒 中花费几个小时来学习如何高效实现面向服务的架构。

讨论

  • 加入 developerWorks 社区。查看开发人员推动的博客、论坛、群组和维基,并与其他 developerWorks 用户交流。

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Cloud computing
ArticleID=860993
ArticleTitle=患者数据在云中的隐私和安全性
publish-date=03112013