← 返回信息流

AWS AI Blog新闻

使用Amazon Bedrock为医疗保健API构建智能安全

aws.amazon.com作者：Durgesh Nath教程产品AI评分：50/100

本文介绍如何使用Amazon Bedrock为FHIR API添加上下文感知的安全监控。通过将安全监控与API请求路径分离，利用Bedrock的模型进行异常检测、数据敏感性分类和合规报告生成，同时不影响临床工作流的延迟。文章提供了详细的架构说明、实现步骤和代码示例，包括Lambda函数、API Gateway、HealthLake等组件的配置。

如果您管理快速医疗互操作性资源（FHIR）API，就必须在开放的患者数据访问与严格的数据保护要求之间取得平衡。静态安全规则需要随着临床工作流的演变而不断更新，而手动维护这些规则会造成合规性缺口。借助 Amazon Bedrock（一项通过单一 API 提供基础模型（FM）访问权限的完全托管服务），您可以为医疗保健 API 构建智能安全防护。该安全防护能够监控访问模式、自动分类数据敏感性，并以自然语言生成合规性报告。这种方法有助于减少文档编写工作量、减少手动规则维护，并让您的安全监控能够随着临床工作流的变化而自适应调整。

在本文中，您将了解如何使用 Amazon Bedrock 为 FHIR API 添加上下文感知的安全监控。首先，我们解释将安全监控与 FHIR API 请求路径分离的架构，这样您就可以在不影响 API 延迟的情况下添加行为分析。然后，我们逐步介绍如何使用 Amazon Bedrock 和 Structured Outputs 实现异常检测，从而捕获静态规则无法发现的访问模式。接下来，我们演示自动化的数据敏感性分类，该功能消除了对硬编码映射表的需求。最后，我们展示如何以自然语言生成合规性报告，从而缩短审计准备时间。该解决方案使用 AWS Lambda、Amazon API Gateway、AWS HealthLake、Amazon EventBridge、Amazon Cognito、Amazon Bedrock Guardrails 和 Amazon Comprehend Medical。它还附带一个配套代码示例，包含完整的 AWS CloudFormation 模板、五个 AWS Lambda 函数以及可适应您环境的部署脚本。

前提条件

  • 一个具有管理访问权限的有效 AWS 账户。
  • 已安装并配置 AWS Command Line Interface（AWS CLI）v2（aws configure）。
  • Amazon Bedrock 现在会自动授予对受支持模型的访问权限。请通过查看 Amazon Bedrock 模型访问页面，确认这些模型在您的 AWS 区域中可用。
  • 一个经过验证的 Amazon Simple Notification Service（Amazon SNS）安全警报通知电子邮件地址。
  • 如果您的 AWS 账户从未将 Amazon API Gateway 与 Amazon CloudWatch Logs 集成使用过，则必须先在账户的 API Gateway 设置中设置 CloudWatch Logs 角色 ARN。否则，部署将失败并显示错误“CloudWatch Logs role ARN must be set in account settings”。有关说明，请参阅在 API Gateway 中设置 CloudWatch API 日志记录。
  • 预计部署时间：10-15 分钟。预计每月费用因使用情况而异。请参阅 Amazon Bedrock 定价页面了解当前费率。AWS HealthLake 费用另计。

架构概述

您可以了解谁在访问 FHIR 数据，以及这些访问是否看起来正常。Amazon Bedrock 中的基础模型会根据用户的历史行为、角色以及所请求数据的敏感性来评估每个请求。评估结果是以通俗英语呈现的风险评估，您可以据此采取行动。

您现有的授权控制保持不变。您继续通过 AWS Lambda 授权方强制执行基于角色的访问控制（RBAC）并验证 JSON Web Tokens（JWT），即用于证明用户身份的数字签名令牌。在此基础上，您还获得了静态规则无法捕获的行为分析能力。例如，如果用户在权限范围内访问数据，但访问量异常或访问时间异常，系统就会触发警报。

下图展示了安全监控如何与主 API 路径分离运行，从而不会给临床工作流增加延迟。

Architecture diagram showing FHIR API requests flowing through Amazon API Gateway and a Lambda authorizer, with asynchr…
Architecture diagram showing FHIR API requests flowing through Amazon API Gateway and a Lambda authorizer, with asynchr…

以下是“先请求后分析”流程的工作方式。Amazon API Gateway 接收传入的 FHIR 请求，并强制执行限流和请求验证。AWS Lambda 授权方验证 JWT，并检查存储在 Amazon DynamoDB 中的细粒度权限。

随后，AWS HealthLake 作为符合 HIPAA 要求的完全托管 FHIR R4 数据存储来提供 FHIR 数据。FHIR 处理器 AWS Lambda 函数捕获访问详细信息，并通过 Amazon EventBridge 将其路由到三个异步 AWS Lambda 函数：异常分析器、敏感性分类器和合规性报告器。每个函数都通过 Amazon Bedrock Guardrails 资源调用 Amazon Bedrock，该资源会在提示词和响应中对受保护健康信息（PHI）进行匿名化处理。异常分析器还会额外使用 Amazon Comprehend Medical 在写入审计日志之前对 PHI 进行编辑脱敏。Amazon CloudWatch 在整个流程中捕获结构化日志，用于审计跟踪。

您将受益于完全异步的分析。Amazon EventBridge 在 FHIR 响应已经返回给客户端之后，才将访问事件路由到分析器 AWS Lambda 函数。您的 API 延迟不受影响，同时您还能获得持续的安全监控。

如果分析器暂时不可用，FHIR API 会继续正常处理请求。监控层不会阻断临床工作流。

HIPAA 保障措施

该解决方案实施了多层PHI保护，防止受保护健康信息通过监控管道泄露：

  • Amazon Bedrock Guardrails – 通过AWS CloudFormation模板部署了AWS::Bedrock::Guardrail资源。它能够检测并匿名化发送至Amazon Bedrock的提示词和模型响应中的个人身份信息（PII）实体（姓名、社会安全号码、地址、电话号码、病历号）。社会安全号码和护照号码将被完全阻止，而非匿名化处理。
  • Amazon Comprehend Medical – 在将Amazon Bedrock响应写入Amazon CloudWatch Logs之前，异常分析器会将文本传递给Amazon Comprehend Medical中的DetectPHI API。检测到的PHI实体将被替换为类型标签（例如[NAME]、[DATE]），从而确保审计日志在不包含实际患者数据的情况下仍可用于合规审查。
  • IP泛化 – 异常分析器的提示词从不向Amazon Bedrock发送原始IP地址。相反，它基于RFC 1918范围将来源分类为“内部”或“外部”，防止PII进入模型上下文。
  • 无PHI告警 – 当异常分析器触发Amazon SNS告警时，通知仅包含哈希引用ID和风险等级。安全团队使用引用ID从审计日志中检索完整详情，这有助于防止电子邮件通知包含PHI。
  • 结构化输出 – 该解决方案中的Amazon Bedrock调用使用带有JSON模式和枚举约束字段（字段限制为固定的有效值集合）的结构化输出。这减少了自由文本解析，并有助于确认模型响应符合可预测的格式，降低了意外PHI出现在下游处理中的风险。
  • 净化错误消息 – FHIR API错误响应向客户端返回通用消息，而非内部异常详情，后者可能无意中包含来自AWS HealthLake响应的患者数据。

使用Amazon Bedrock进行异常检测

您可以通过分析不同临床用户群体的行为模式，检测基于规则的系统无法发现的复杂访问异常。分析器AWS Lambda函数是该架构的核心。每次API调用都会生成一个访问事件，基础模型会根据用户的角色、访问历史和请求性质对该事件进行评估。

设想一位医生通常在办公时间内访问5-15份患者病历。如果同一位医生在凌晨3点下载了500份病历，静态规则需要为每种角色和时间组合设置明确的阈值。借助Amazon Bedrock，您可以评估完整上下文，并获得带有通俗易懂解释的风险评估。

临床用户群体多种多样：医生、护士、计费人员、研究人员和第三方集成。每个群体都有不同的正常访问模式，且这些模式会随时间变化。进行回顾性研究的研究人员可能在单次会话中合法访问数千份病历。基础模型通过检查用户的角色、请求性质以及访问是否遵循正常认证模式，将其与未授权访问区分开来。

异常检测构建的是每个用户的行为基线，而非应用群体级别的阈值。这种方法降低了系统性标记夜班临床医生、国际研究人员或经常在标准办公时间之外工作的值班医生的合法访问模式的风险。

不同的调用方类型具有不同的风险特征。SMART on FHIR应用程序、患者门户和健康信息交换（HIE）连接各有不同的预期行为。访问事件包含OAuth client_id，因此分析器可以维护特定于应用的基线，并根据集成类型应用差异化的风险评分。

组织还可以进一步丰富访问事件的临床上下文，例如值班安排、急诊科激活状态或护理团队分配。例如，在大规模伤亡事件期间，医生在凌晨3点访问500份病历，不应与常规夜晚的相同模式触发相同的风险评估。提示词设计在可用时会容纳这些额外上下文。

该实现采用故障开放（fail-open）方法。故障开放意味着如果分析器遇到错误，它会记录失败但不会阻止原始API请求。我们选择此方案而非故障关闭（fail-closed）方法（后者会在出错时阻止请求），因为分析器中断不应给临床工作流带来可用性问题。FHIR API在监控层恢复期间继续正常处理请求。

异常分析器使用带有结构化输出的 Amazon Bedrock Converse API，通过枚举约束的风险等级（LOW、MEDIUM、HIGH）强制执行JSON模式。Amazon Bedrock Guardrails资源会对提示和响应中的PHI进行匿名化处理，Amazon Comprehend Medical则在审计日志记录前对PHI进行脱敏。对于高风险事件，Amazon SNS发送仅包含哈希引用ID且不含PHI的警报。完整实现请参见随附代码示例中的 anomaly_analyzer/handler.py。

数据敏感性分类

FHIR资源的敏感性各不相同。心理健康观察记录的敏感性高于常规血压读数。某些临床数据类型，如药物滥用治疗记录，可能根据适用法规需要额外的保护措施。请注意，敏感性分类用于辅助访问决策，但不能替代同意管理，后者应根据您组织的政策实施。

您可以使用Amazon Bedrock按敏感性级别对FHIR资源进行分类，而无需硬编码映射表。当资源在AWS HealthLake中创建或更新时，Amazon EventBridge规则会触发分类函数。该函数将资源元数据发送至Amazon Bedrock，由其评估资源类型、临床代码和类别，然后分配敏感性级别：PUBLIC、INTERNAL、CONFIDENTIAL或RESTRICTED。

例如，Amazon Bedrock将带有血糖LOINC代码（2345-7）的Observation分类为INTERNAL，将带有HIV检测结果代码（7018-2）的Observation分类为RESTRICTED。模型根据代码的临床含义进行区分。当出现新的代码系统或资源类别时，分类会自动适应，无需修改代码。

Amazon DynamoDB将分类结果与资源ID一同存储。当用户请求该资源时，AWS Lambda授权器会在授予访问权限前检查用户的许可级别是否与资源的分类匹配。这就在标准RBAC之上提供了一个动态的、内容感知的授权层。

对于分类任务，您使用Amazon Bedrock上的Anthropic Claude Haiku 4.5基础模型（FM），该模型延迟低、成本低。对于更复杂的访问模式分析（准确性比速度更重要），您使用Amazon Bedrock上的Anthropic Claude Sonnet 4.5基础模型。对于每月处理100,000次FHIR API调用的组织，Amazon Bedrock成本预计在数十美元范围内，具体取决于提示长度和模型选择。有关当前按token计费的价格，请参阅Amazon Bedrock定价页面。您可以在AWS Billing and Cost Management控制台中监控使用情况和成本。

敏感性分类器使用结构化输出，并带有固定有效值集合（PUBLIC、INTERNAL、CONFIDENTIAL、RESTRICTED），以确保分类结果有效。如果分类失败，函数默认使用CONFIDENTIAL（故障安全）。请参见随附代码示例中的 sensitivity_classifier/handler.py。

合规报告

医疗审计要求记录谁在何时出于何种目的访问了哪些数据。安全团队通常需要花费数天时间汇总日志、交叉引用用户活动并撰写叙述性摘要。您可以使用Amazon Bedrock自动将原始访问日志转换为可读的合规报告。

一个预定的AWS Lambda函数通过Amazon EventBridge Scheduler每月运行一次。它检索报告期内的访问日志并将其发送至Amazon Bedrock，附带生成合规摘要的指令。输出包括按资源类型统计的请求总数、按角色细分的独立用户活动、被标记的访问事件及其处理结果，以及改善安全态势的建议。

提示词指示基础模型按安全控制类别（管理性、物理性和技术性）组织报告。这种结构有助于安全团队系统地审查发现。每个被标记的事件都包含原始风险评估、处理状态以及所采取措施的时间线。

这种方法自动化了日志汇总、交叉引用和叙述性撰写等手动步骤，减少了合规团队在每份报告上花费的时间。

合规报告器使用结构化输出，其模式将每个部分映射到安全控制类别。报告保存到带有AWS KMS加密的Amazon Simple Storage Service（Amazon S3），一年后归档至Amazon S3 Glacier。请参见随附代码示例中的 compliance_reporter/handler.py。

清理资源

为避免持续产生费用，测试完成后请删除此解决方案创建的资源。运行随附代码示例中的清理脚本：./src/scripts/cleanup.sh dev us-east-1。这将删除由 AWS CloudFormation 管理的资源，包括 API Gateway REST API、全部五个 AWS Lambda 函数、两个 Amazon DynamoDB 表、Amazon EventBridge 事件总线和规则、Amazon Cognito 用户池、Amazon SNS 主题、Amazon S3 合规报告存储桶以及 Amazon CloudWatch 日志组。如果您为端到端测试单独创建了 AWS HealthLake 数据存储，请手动删除。AWS HealthLake 在激活状态下每小时收费约 0.694 美元（约每月 500 美元）。

结论

您现在拥有一个能够随访问模式变化而适应环境的安全监控概念验证模式。在本文中，您学习了如何使用 Amazon Bedrock 基础模型检测异常访问模式、自动分类数据敏感级别，以及生成自然语言安全审计报告。

如果您正在评估此方案，请先查看本文中的架构图和代码示例。浏览 Amazon Bedrock 用户指南以了解基础模型功能，并查阅 AWS HealthLake 用户指南以评估 FHIR R4 数据管理如何适配您的环境。

  • 运行 aws configure 设置您的 AWS 凭证和目标 AWS 区域（例如 us-east-1）。验证 Anthropic 的 Claude Sonnet 4.5 和 Anthropic 的 Claude Haiku 4.5 在您的目标区域中可用。
  • 运行部署脚本：./src/scripts/deploy.sh your-email@example.com dev us-east-1。该脚本将打包 Lambda 代码，上传至 Amazon S3，并使用所需基础设施（Amazon API Gateway、AWS Lambda 函数、Amazon DynamoDB 表、Amazon EventBridge 规则、Amazon Cognito、Amazon SNS、Amazon S3 和 Amazon Bedrock Guardrails 资源）部署 AWS CloudFormation 堆栈。检查您的电子邮件并确认 Amazon SNS 订阅。
  • 自定义异常分析器和敏感度分类器 AWS Lambda 函数中的提示词，以匹配组织的风险容忍度、临床角色和数据敏感度定义。
  • （可选）创建 AWS HealthLake 数据存储用于端到端测试。请注意，AWS HealthLake 每小时收费约 0.694 美元，因此仅在积极测试时创建并及时删除。然后通过 Amazon EventBridge 发送测试事件，并通过检查每个 Lambda 函数的 Amazon CloudWatch 日志来验证端到端流程。
  • 通过在正常工作时间之外请求大量记录来模拟异常访问模式。使用有效的 JWT 令牌向您的 API Gateway 端点发送 GET 请求以获取 500 个 Patient 资源。异常分析器应将其标记为 MEDIUM 或 HIGH 风险。
  • 通过在营业时间内请求少量记录来模拟正常访问模式。分析器应分配 LOW 风险级别。
  • 模拟跨角色访问尝试，例如计费用户请求临床数据（如实验室 Observation）。这用于测试模型是否能识别角色与资源不匹配的情况。

每次测试后，检查异常分析器 Lambda 函数的 Amazon CloudWatch 日志，并验证 Amazon SNS 是否针对 HIGH 风险事件发送了警报。随附代码示例中的 README 包含每个测试场景的具体 API 端点和 curl 命令。

如果您已在生产环境中运行 FHIR API，可以将此监控层与现有的 Amazon API Gateway 和 AWS Lambda 授权器并行集成，而无需修改请求路径。将异步的 Amazon EventBridge 到 Bedrock 流程添加为并行监控通道，并调整提示词以反映组织特定的角色定义和风险配置文件。

为进一步扩展解决方案，可考虑将 Amazon SNS 警报与现有的安全信息和事件管理（SIEM）工具集成，以实现集中监控。您还可以为常见医疗保健场景添加提示词模板，例如研究数据访问审查、紧急破例（break-the-glass）覆盖和大批量数据导出风险评估。您还可以调整提示词以反映组织特定的风险配置文件，或通过调整 AWS Lambda 并发设置和 Amazon DynamoDB 吞吐量来扩展架构以适应高容量环境。

如需更深入的指导，请参阅 Amazon Bedrock 用户指南、AWS HealthLake 用户指南、Amazon API Gateway 开发人员指南和 Amazon CloudWatch 用户指南。

欢迎在评论区分享您的经验和问题。联系 AWS 代表讨论您的医疗保健安全实施方案。

延伸阅读

  • 在 AWS Healthcare Blog 上发现医疗保健解决方案和客户案例。
  • 在 Amazon Bedrock 用户指南中了解如何使用基础模型。
  • 在 AWS HealthLake 用户指南中探索 FHIR 数据管理功能。

关于作者

阅读原文