使用 Amazon Bedrock 为医疗 API 构建智能安全防护

如果你管理着 Fast Healthcare Interoperability Resources（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"（必须在账户设置中设置 CloudWatch Logs 角色 ARN）。有关说明，请参阅在 API Gateway 中设置 CloudWatch API 日志记录。

预计部署时间：10-15 分钟。预计每月成本因使用量而异。有关当前费率，请参阅 Amazon Bedrock 定价页面。AWS HealthLake 费用另计。

架构概述

你可以洞察谁在访问 FHIR 数据，以及该访问是否正常。Amazon Bedrock 中的基础模型会根据用户的历史行为、角色以及所请求数据的敏感度来评估每个请求。结果是一份你可以据此行动的纯英文风险评估。

你现有的授权控制保持不变。你继续通过 AWS Lambda authorizer 强制执行基于角色的访问控制（RBAC）并验证 JSON Web Token（JWT）——这是证明用户身份的签名令牌。在此基础上，你获得了能够捕获静态规则无法发现的模式的行为分析。例如，用户在其权限范围内访问数据，但访问量异常或访问时间异常，都会触发警报。

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

图 1：Amazon Bedrock 驱动的 FHIR API 安全监控系统架构

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

AWS HealthLake 然后将 FHIR 数据作为符合 HIPAA 资格的全托管 FHIR R4 数据存储提供服务。FHIR processor 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 会继续正常服务请求。监控层不会阻塞临床工作流程。

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

Amazon Bedrock Guardrails – 一个 AWS::Bedrock::Guardrail 资源随 AWS CloudFormation 模板一起部署。它检测并匿名化发送给 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。

Structured Outputs – 该解决方案中的 Amazon Bedrock 调用使用 Structured Outputs 和 JSON schema 以及 enum 约束字段（限制为固定有效值集的字段）。这减少了自由文本解析，并有助于确认模型响应符合可预测的格式，降低了意外 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（故障开放）方法。fail-open 意味着如果分析器遇到错误，它会记录失败但不会阻止原始 API 请求。我们选择这种方式而不是 fail-closed（故障关闭）方法（会在出错时阻止请求），因为分析器中断不应为临床工作流造成可用性问题。FHIR API 在监控层恢复期间继续正常服务请求。

异常分析器使用 Amazon Bedrock Converse API 与结构化输出（Structured Outputs）来强制执行具有枚举约束风险级别（LOW、MEDIUM、HIGH）的 JSON 模式。Amazon Bedrock Guardrails 资源在提示词和响应中匿名化 PHI，Amazon Comprehend Medical 在审计日志记录之前 redact PHI。对于 HIGH 风险事件，Amazon SNS 发送仅包含哈希引用 ID 的无 PHI 告警。参见随附代码示例中的 anomaly_analyzer/handler.py 获取完整实现。

数据敏感度分类

FHIR 资源的敏感度各不相同。心理健康 Observation 比常规血压读数具有更高的敏感度。某些临床数据类型（如药物滥用治疗记录）可能根据适用法规需要额外的保障措施。请注意，敏感度分类为访问决策提供信息，但不能替代同意管理，应根据组织政策实施。

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

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

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

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

敏感度分类器使用具有固定有效值集（PUBLIC、INTERNAL、CONFIDENTIAL、RESTRICTED）的结构化输出（Structured Outputs）来保证有效分类。如果分类失败，函数默认为 CONFIDENTIAL（fail-secure）。参见随附代码示例中的 sensitivity_classifier/handler.py。

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

计划 AWS Lambda 函数使用 Amazon EventBridge Scheduler 每月运行一次。它检索报告期的访问日志，并将其发送到 Amazon Bedrock，同时提供生成合规摘要的说明。输出包括按资源类型划分的总请求计数、按角色细分 unique 用户活动、标记的访问事件及其解决方案，以及改善安全状况的建议。

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

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

合规报告器使用结构化输出（Structured Outputs）和将每个部分映射到安全控制类别的模式。报告使用 AWS Key Management Service（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 User Guide 以了解基础模型能力，并查看 AWS HealthLake User Guide 以评估 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，并使用所需的基础设施部署 AWS CloudFormation 堆栈（Amazon API Gateway、AWS Lambda 函数、Amazon DynamoDB 表、Amazon EventBridge 规则、Amazon Cognito、Amazon SNS、Amazon S3 以及 Amazon Bedrock Guardrails 资源）。检查您的电子邮件并确认 Amazon SNS 订阅。

自定义异常分析器和敏感度分类器 AWS Lambda 函数中的提示词，以匹配组织的风险容忍度、临床角色和数据敏感度定义。

（可选）为端到端测试创建 AWS HealthLake 数据存储。请注意，AWS HealthLake 每小时收费约 $0.694，因此仅在主动测试时创建并及时删除。然后通过 Amazon EventBridge 发送测试事件，并通过检查每个 Lambda 函数的 Amazon CloudWatch Logs 来验证端到端流程。

部署后，通过发送不同模式的 FHIR API 请求来测试异常检测：

通过在正常工作时间外请求大量记录来模拟异常访问模式。使用有效的 JWT 令牌向 API Gateway 端点发送 GET 请求以获取 500 个 Patient 资源。异常分析器应将其标记为 MEDIUM 或 HIGH 风险。

通过在工作时间请求少量记录来模拟正常访问模式。分析器应分配 LOW 风险级别。

模拟一次跨角色访问尝试，让账单用户请求临床数据（如实验室 Observations）。这可以测试模型是否能识别角色与资源的不匹配。

每个测试完成后，检查 Amazon CloudWatch Logs 中的异常分析器 Lambda 函数日志，验证 Amazon SNS 是否为 HIGH 风险事件发送了告警。配套代码示例中的 README 包含了每个测试场景的具体 API 端点和 curl 命令。

如果您已在生产环境中运行 FHIR API，可以将此监控层与现有的 Amazon API Gateway 和 AWS Lambda 授权器集成，而无需修改请求路径。将异步的 Amazon EventBridge-to-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 数据管理能力。