在你的API平台上实施HIPAA技术保障措施

本文是API开发者建立HIPAA安全规则中规定的技术保障措施的方法指南。

健康保险可携性和责任法案，简称HIPAA，是一套关于在信息系统中处理健康相关数据的法律。它定义了保障措施，这是你在为客户处理健康数据时必须遵守的规则。

有三个保障类别：

行政保障措施，涵盖贵公司的个人和流程
物理保障措施，与运行处理健康数据的软件的硬件有关
技术保障措施，即你的软件必须执行的要求。

如果你想让你的API符合HIPAA的要求，就必须正确处理所有这三类保障。在一篇配套文章中，我们介绍了这些关键要求以及如何建立符合HIPAA的API平台。在这篇文章中，我们将详细介绍如何实施技术保障措施的实际细节。

有九项技术保障措施，其中四项是必须的，五项是可以解决的。必要的保障措施在任何情况下都必须实施；可寻址的保障措施应在合理的情况下实施。如果你不能实施可解决的保障措施，你需要记录原因，并解释为什么你没有实施它们，这在数据泄露的情况下至关重要。

虽然物理保障措施不是本文的主题，但请记住，你需要将你的基础设施托管在符合HIPAA的供应商那里。否则，某些技术保障措施有可能通过物理访问服务器而被绕过。如果你正计划进行内部部署，你需要自己遵循物理保障措施。

必要的技术保障措施

让我们从四个必要的保障措施开始。这些是你需要遵循的最低要求，以便从技术角度符合HIPAA。

独特的用户识别

你的系统的每一个用户都需要有一个独特的标识符，以便系统上的每一个动作都可以追溯到做这个动作的用户。做到这一点的一个简单方法是使用一个普遍的唯一标识符（UUID）。每一种主要的编程语言都有一个用于创建UUID的库。UUID生成器遵循标准化的算法，创建的字符串是全球唯一的，不需要集中的权威机构。

符合HIPAA的管理认证服务，如AWS Cognito，将为你做这件事。Cognito的用户池会在注册时给每个新用户一个唯一的ID。

如果你必须自己实现唯一的用户识别，你可以在这里找到UUID的实现方法：

紧急访问程序

你将需要一种方法，在紧急情况下访问受保护的医疗数据。紧急情况，在这里指的是，你的系统或应用程序发生了一些不好的事情；例如，你的电力中断了，或者你受到了网络攻击。在这种情况下，数据需要通过另一种方式来访问。

为了实现这种紧急访问，你需要解决两个问题。第一个是某种类型的异地备份，即使你的数据中心被烧毁，也能让你访问数据。第二个是一个警报系统，通知你目前正在发生紧急情况。

对于像亚马逊DynamoDB这样的管理数据库，这意味着你需要为你的表激活时间点恢复。一旦开启，你的表的最后35天的数据会每5分钟备份一次，并且可以恢复。

如果你用CloudFormation定义你的表，你只需要为此添加两个属性：

XML

Type: 'AWS::DynamoDB::Table'
Properties:
  TableName: phiTable
  PointInTimeRecoverySpecification:
    PointInTimeRecoveryEnabled: true

对于其他著名的数据库，你可以在这里找到关于如何设置备份的指南：

审计控制

审计控制是关于记录谁访问了医疗数据。它与独特的用户识别一起工作。如果你被审计，你需要向审计人员指出审计日志数据，向他们表明一切都被正确跟踪。

做到这一点的一个简单方法是为医疗保健数据建立专门的数据存储，并记录所有访问。这样一来，你就可以确保在你的应用程序中添加新功能时，没有开发者会忘记实施日志记录。另外，当你把医疗数据和非医疗数据一起存储时，你就不会有太多的审计日志了。

另一种方法是实施事件源。在这种数据架构模式中，你只把变化保存在一个不可变的列表中，并即时生成表格。这样一来，三个更新实际上是你的事件源数据库中的三条记录，而不仅仅是最终结果。你可以看到你的数据在每个时间点上发生了什么，以及谁造成了这些变化。

你可以在这里找到关于如何启用突出数据库的访问日志的信息：

认证

让你的所有用户都经过认证，这样就不会发生匿名访问医疗数据的情况。最好的做法是在可以访问医疗数据的地方使用密码和多因素认证。如果你的用户的一个认证因素被盗，例如，一个未上锁的智能手机，他们需要能够证明他们随后没有访问受保护的数据。

使用像AWS Cognito这样的管理服务可以节省你的时间，因为它开箱就符合HIPAA标准。Auth0和Okta也是非常好的管理认证服务，它们也符合HIPAA。

对于你自己的实施，你可以在这里找到主要API平台的认证库：

可处理的技术保障措施

可处理的技术保障措施占HIPAA要求的大多数，尽管是微不足道的52%。严格来说，它们是可选的，但你应该把它们的 "可处理 "性质看作是允许在实施上有一些灵活性的保障措施。

事实上，你可以实施，也可以找到一个能实现同样目标的替代方案，或者不实施。如果你选择不实施，你需要记录原因，并可能在进一步行动之前咨询审计专家/律师。

自动注销

保持你的用户会话尽可能短，并自动注销他们。基本的想法是，如果有人在登录后离开他们的设备，它可能会被未经授权的人使用。如果你在用户不活跃的情况下，在一两分钟后注销他们，那么发生未经授权的访问的机会就会降低。

为了做好这一点，你需要必须降低你的API连接的会话超时。客户端可以自动请求新的会话令牌，所以与GUI应用程序相比，这通常不是一个大问题。如果是GUI，用户将不得不手动重新登录。

加密和解密

所有的医疗数据都应该被加密，只有在需要时才会被解密。这意味着在休息状态下的加密，如在你的服务器或用户的设备上。这也意味着当数据在网络上传输时要进行加密。这样做的原因是显而易见的--如果数据被加密，窃取数据对攻击者没有帮助。

虽然HIPAA规定的加密要求是技术中立的，但你应该在合理范围内尽可能地对数据进行加密。这意味着ROT13是不够的，但一次性垫是过头的。检查你的技术提供什么最先进的加密机制，并坚持使用。

同样，像AWS DynamoDB这样的管理服务在休息时自动加密你的数据。

你的API应该为所有连接强制执行SSL，以符合要求。使用strict-transport安全标头来通知你的客户使用SSL。如果协议是HTTP，就不要传递任何数据。它应该只用HTTPS的位置头和3XX状态代码来重定向。也许在正文中给出一些信息，"HTTP不被支持"。

如果你不能对数据进行加密，但有其他机制可以防止对数据的访问，你应该记录下来。

完整性控制和验证电子健康保险的机制

你需要一种方法来确保医疗保健数据没有以未经授权的方式被改变或破坏。这意味着你需要对数据的完整性进行检查，例如，使用校验和或数字签名。如果一个经过认证的用户签署了更改后的数据，任何未经授权的用户的后续更改都将是明显的。

为了防止未经授权的数据破坏，你必须实施一个备份，不会同步授权用户没有数字签名的更改。如果一个恶意的用户删除了数据，它要么会显示在审计日志中，要么删除不会传播到备份中。

同样，事件源可以成为解决方案。因为数据永远不会被隐含地删除，而且所有的变化都会被记录在设计中。

如何从其他API访问ePHI数据

如果你自己的数据已经符合HIPAA标准，那么第三方API就不是一个大问题，但如果你不符合HIPAA标准，就会造成额外的费用。

当你想使用来自第三方API（如EPIC）的ePHI数据时，你也需要应用保障措施。并非所有由ePHI API提供的数据都属于HIPAA的保护范围，但如果你要求的数据属于HIPAA的保护范围，你就需要实施它。这也包括物理和管理方面的保障措施，这在本文中并没有提到。

安全代理

Moesif提供一个安全代理，你可以在自己的基础设施上托管它。这个代理将在向Moesif发送数据之前对你的数据进行加密，并在向你展示之前对其进行解密，所有这些都是通过你自己的私人加密密钥完成的。主加密密钥从不存储在Moesif服务器上；相反，安全代理支持流行的密钥存储，并自动处理密钥旋转。最后，Moesif永远不会看到你未加密的电子健康保险数据。

这种方法也是你在自己的API中可以记住的。如果客户想向你发送他们的ePHI数据，告诉他们应该先加密，或者向他们提供你自己的安全代理，他们可以在自己的基础设施上托管。

总结

如果你想实施符合HIPAA的API，你最好的行动方案是实施所有的保护措施，甚至是可选的。今天降低你的风险，避免以后出现不舒服的技术和可能的法律问题。

有些保障措施实际上是分层的，例如，实施独特的用户标识符将在建立认证之后进行。加密和解密也是如此，两者都被算作独立的保障措施，但在实践中实际上是共同作用的。

另外，备份、认证和加密是保护你整个业务的良好做法，而不仅仅是你可能持有的与健康有关的数据。因此，你的API很有可能已经有了大部分的保障措施。

你还应该检查一下云供应商的管理服务，如AWS、Azure或GCP。通常这些供应商已经做了艰苦的工作来遵守规定，你只需要选择具有正确配置的资源。

在API平台上实施HIPAA技术保障措施的方法