本文介绍了 Azure 上消费者健康数字门户的示例体系结构，该体系结构可促进医疗保健提供商和患者之间的通信。 此外，此平台还可以存储病历、医学影像，并且允许病人跟踪健康数据等。
体系结构
下载此体系结构的 Visio 文件。
工作流
- 此解决方案使用 Azure Front Door 的全局占用情况和 Azure Web 应用程序防火墙 (WAF) 的边缘安全功能对入站数据进行身份验证。
- 然后，经过身份验证的数据由 Azure API 管理 (APIM) 路由到 Azure 应用程序服务上用户的前端接口，或 Azure Functions 中托管的 API。
此体系结构中使用的主要后端数据服务是 Azure Cosmos DB。 除了可伸缩性和安全性之外，Azure Cosmos DB 的多模型功能还为任何类型的消费者健康状况门户提供了灵活性。 任何非记录格式的数据都作为对象存储在 Azure Blob 存储中。 这些数据可能包括医学影像、消费者拍摄的照片、上传的文档、存档数据等等。 Blob 存储为大量非结构化数据提供了一种经济实惠的存储方式。 这类数据在 Azure Cosmos DB 中的存储并没有被优化，可能会对其成本和性能产生负面影响。
组件
Azure HIPAA HITRUST 9.2 蓝图是一种使用 Azure Policy 的 Azure 蓝图。 它有助于评估 HIPAA HITRUST 9.2 控制，并为 Azure 工作负载部署一组核心策略。 虽然这并不能完全覆盖 HIPAA HITRUST 的符合性，但它是一个很好的开始，并在适用和必要时增加更多的控制。 在这个蓝图和 Microsoft Defender for Cloud 界面中，还可以直观地看到策略计划的符合性。
Azure Front Door 用于管理大规模边缘流量，并通过在世界各地提供终结点为最终用户提高性能。 这是一种云原生技术，不需要任何许可；只需为使用的内容付费。 在此工作负载方案中，Azure Front Door 充当流向消费者健康门户的所有流量的入口点。
Azure Web 应用程序防火墙可以保护应用程序免受常见的基于 Web 的攻击，例如 OWASP 漏洞、SQL 注入、跨站脚本等。 这是一种云原生技术，不需要任何许可，即用即付。
Azure API 管理有助于发布、路由、保护、记录和分析 API。 无论 API 是仅由最终用户使用，还是与第三方集成以实现外部互操作性，API 管理都允许灵活地扩展和呈现 API。
Azure 应用程序服务用于托管基于 HTTP 的 Web 服务。 它支持多种语言，可以在 Linux 或 Windows 上运行，与 CI/CD 管道完全集成，甚至可以将容器工作负载作为 PaaS 产品/服务运行。 除了与 Azure 中的标识、安全性和日志记录服务进行本机集成外，应用程序服务还允许纵向扩展和横向扩展。 它可以满足消费者健康门户的缩放需求，同时保持合规性。 在此体系结构中，它托管前端 Web 门户。
Azure 函数应用是 Azure 上的一个无服务器平台解决方案，可让开发人员编写按需计算代码，而无需维护任何底层系统。 在此体系结构中，Azure Functions 可以托管 API 以及需要异步完成的任何工作，例如运行定期作业和计算特定时间段内的统计信息。
Azure Cosmos DB 是一种完全托管的多模型 NoSQL 数据库产品/服务，提供个位数的响应时间，并保证任何规模的性能。 消费者健康系统中的每个用户将只有与自己有关的数据，这证明了使用 NoSQL 数据结构的合理性。 Azure Cosmos DB 具有几乎无限的规模，以及多区域读取和写入。 随着这些类型的消费者健康状况系统收集的数据量急剧增长，无论是有 100 个还是有 100 万个活跃用户，Azure Cosmos DB 都可以提供适当的安全性、速度和规模。
Azure 密钥保管库是一项 Azure 本机服务，用于安全地存储和访问机密、密钥和证书。 密钥保管库可实现 HSM 支持的安全性，以及通过 Microsoft Entra 集成的基于角色的访问控制进行审核访问。 应用程序不应在本地存储密钥或机密。 此体系结构使用 Azure 密钥保管库存储所有机密，例如 API 密钥、密码、加密密钥和证书。
Azure Active Directory B2C 提供大规模的企业到消费者标识即服务，其成本随活跃用户的计数变化相应调整。 在面向消费者的应用程序（如本解决方案）中，用户可能希望自带标识，而不是创建新帐户。 它可以是从社交 ID 到电子邮件帐户的任何内容，也可以是任何 SAML 提供程序标识服务。 此方法为用户提供了更轻松的加入体验。 解决方案提供商只需引用用户标识，无需进行托管和维护。
Azure Log Analytics 是一种 Azure Monitor 日志工具，可用于诊断或记录信息，以及查询此数据以对其进行排序、筛选或可视化。 此服务按使用量定价，非常适合托管此解决方案中所有服务的诊断和使用情况日志。
Azure Application Insights（Azure Monitor 的另一项功能）是 Azure 中的本机应用程序性能管理 (APM) 服务。 它可以轻松集成到前端应用程序服务中，并集成到所有 Azure Functions 代码中，以便实时监视应用程序。 Application Insights 可以轻松地检测直接从应用程序本身产生的（而不仅仅是从托管应用程序的计算平台产生的）性能、可用性异常和故障。
Azure 通信服务是具有 REST API 和客户端库 SDK 的基于云的服务，可用于帮助将通信集成到应用程序中。 无需成为媒体编码或电话等基础技术方面的专家，即可向应用程序添加通信。 在本解决方案中，它可用于发出与消费者健康门户相关的任何电子邮件、短信或自动电话呼叫，例如预约确认或提醒。
Azure 通知中心是一种简单且可缩放的推送通知引擎，能够将通知发送到任何移动平台。 使用移动应用的消费者健康门户可以与 Azure 通知中心集成，以经济高效的方式将通知推送到已将应用安装在自己的移动设备上的用户。 在此体系结构中，可以发送通知来提醒用户注意自己的约会、为断开连接的设备输入信息、达到某些健康目标，等等。
Microsoft Defender for Cloud 是整个云原生解决方案的安全监视和状态管理的核心。 Microsoft Defender for Cloud 与 Azure 平台上的几乎所有主要服务集成。 其功能包括安全警报、异常情况检测、最佳做法建议、法规符合性分数和威胁检测。 除了 HIPAA/HITRUST 合规性监视和总体 Azure 安全最佳做法监视之外，此解决方案还使用了以下功能集：
备选方法
Azure FHIR 服务 作为 Azure 运行状况数据服务的一部分，可使用 HL7 或 FHIR 通信标准实现医疗记录的互操作性。 如果应用程序需要接收或传输来自其他系统的医疗记录，应使用此服务。 例如，如果此解决方案是医疗服务提供商的门户，则 Azure API for FHIR 可以直接与提供商的电子病历系统集成。
Azure IoT 中心是一项为引入设备数据而微调的服务。 如果门户是从可穿戴设备或任何其他医疗设备收集数据的解决方案的前端，应使用 IoT 中心引入这些数据。 有关详细信息，请阅读远程患者监视解决方案体系结构的“引入”过程。
Microsoft 365 电子邮件是一项用于电子邮件和通信的行业领先的服务。 许多组织已经对这项服务进行了投资，它可以作为功能更全面的 Azure 通信服务的替代方案。 在本解决方案中，它可用于发出与消费者健康门户相关的任何电子邮件，例如预约确认或提醒电子邮件。
方案详细信息
在整个医疗保健和生命科学行业，各组织都在采用数字健康战略。 数字健康解决方案的一个核心要素和必要组件是消费者健康门户。 消费者健康门户可用于跟踪可穿戴设备的进度和统计信息、与医疗服务提供商联系，甚至跟踪健康的饮食习惯。
可能的用例
- 跟踪可穿戴设备的统计信息。
- 访问医疗记录并与医疗服务提供商联系。
- 输入药物的时间和剂量，可用于补药数据或自我跟踪药物。
- 与针对减轻体重或糖尿病的健康饮食教练互动。
注意事项
这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改善工作负荷质量的指导原则。 有关详细信息，请参阅 Microsoft Azure 架构良好的框架。
可用性
此解决方案目前设计为单区域部署。 如果你的场景需要多区域部署以实现高可用性、灾难恢复甚至邻近性，可能需要具有以下配置的配对 Azure 区域。
Azure Cosmos DB 已扩展为启用多区域配置。
Azure API 管理已通过 CI/CD 部署到次要区域。 你也可以应用 API 管理的多区域部署功能。
Azure 应用程序服务和 Functions 分别部署到多个区域。 此部署可以通过在 CI/CD 管道中创建并行部署来完成。 有关进一步的指导，请阅读高可用性多区域 Web 应用程序。
根据 RTO（恢复时间目标）的要求，Azure Blob 存储可以配置为异地冗余存储 (GRS)，也可以配置为允许直接从备用区域读取的读取访问异地冗余存储 (RA-GRS)。 有关详细信息，请参阅 Azure 存储冗余一文。
Azure 密钥保管库服务中内置了多层可用性和冗余。
安全性
安全性针对蓄意攻击及滥用宝贵数据和系统提供保障措施。 有关详细信息，请参阅安全性支柱概述。
以下各节介绍此解决方案中使用的每个服务的安全最佳做法。
Azure Front Door
Azure Front Door 的 Web 应用程序防火墙 (WAF) 应用于缓解许多不同的常见攻击。 一个很好的基准是首先使用最新版本的 Open Web Application Security Project (OWASP) 核心规则集 (CRS)，然后根据需要添加自定义策略。 尽管 Azure Front Door 设计为吸收大量流量，但请考虑使用此服务提供的缓存机制，以尽可能减少后端系统的流量负载。 为了进行故障排除和支持潜在的安全调查，应同时为 Azure Front Door 和 Web 应用程序防火墙配置日志记录。 有关详细信息，请参阅 Azure Front Door 的安全做法。
Azure API 管理
流向 APIM 的所有流量都应进行身份验证，可以使用 Azure AD B2C APIM 身份验证，也可以使用令牌标识的会话。 配置 Azure API 管理以存储资源日志。 有关详细信息，请参阅 Azure API 管理的安全做法。
Azure 应用程序服务
流向此体系结构的所有流量，包括应用程序服务，都应通过 TLS 进行端到端保护。 应用程序服务应拒绝不安全的协议，以收紧攻击面。 此外，APIM 应将客户端的身份验证传回给应用程序服务，让它根据自己的客户端身份验证和授权进行验证。 所有应用程序服务中使用的机密都应存储在密钥保管库中，并尽可能使用托管服务标识。 应用程序服务还应存储诊断日志，以支持任何安全诊断工作，并且应与适用于应用程序服务的 Microsoft Defender 集成。 有关详细信息，请参阅 Azure 应用程序服务的安全做法
Azure Functions
此解决方案中对 Azure Functions 发出的所有请求都应要求使用 HTTPS，使用 Azure API 管理对请求进行身份验证，并尽可能使用托管标识。 将所有密钥存储在 Azure 密钥保管库中，而不是将它们留在函数代码中。 与任何应用程序一样，确保在输入时验证数据，并与 Microsoft Defender for Cloud 集成。 最后，始终配置 Azure Functions 的日志记录和监视。 有关详细信息，请参阅 Azure Functions 的安全做法。
Azure Blob 存储
在可能的情况下，请使用 Microsoft Entra ID 来授权用户访问权限，从而限制对 Blob 存储的访问；同时使用托管服务标识来限制对 Blob 存储的资源访问。 如果这些身份验证类型可能不适用于你的应用程序，请在最细粒度的级别使用共享访问签名 (SAS) 令牌，而不是帐户密钥。 轮换帐户密钥后，SAS 令牌将失效。
确保对 Blob 存储也使用基于角色的访问控制。 使用 Azure 存储防火墙禁止网络流量，但来自受信任的 Microsoft 服务的流量除外。 始终将 Azure 存储与 Microsoft Defender for Cloud 集成并配置监视。 有关详细信息，请参阅 Azure Blob 存储的安全做法。
Azure Cosmos DB
应为 Azure Cosmos DB 管理启用基于角色的访问控制。 应适当保护对 Azure Cosmos DB 中数据的访问。 可以将 Azure Cosmos DB 配置为存储控制平面操作的诊断日志和存储资源日志。 有关更多详细信息，请参阅 Azure Cosmos DB 的安全做法。
Azure Key Vault
除了特权访问控制之外，对 Azure 密钥保管库发出的请求还应使用 Microsoft Entra ID 或 MSI 进行身份验证。 除了在 Azure Monitor 中记录密钥保管库操作之外，还将密钥保管库与 Microsoft Defender for Cloud 集成。 有关详细信息，请参阅 Azure 密钥保管库的安全做法。
Azure AD B2C
使用 Azure AD B2C 中的内置功能来防御威胁，例如拒绝服务和基于密码的攻击。 配置审核日志以允许安全调查，并为 B2C 生成的任何威胁管理日志创建日志警报。 有关详细信息，请参阅 Azure AD B2C 的安全做法。
Azure Log Analytics
应为 Log Analytics 实施基于角色的访问控制，仅允许授权用户访问发送到工作区的数据。 有关详细信息，请参阅 Azure Log Analytics 的安全做法。
Azure Application Insights
在将任何个人数据发送到 Application Insights 之前，都应对其进行模糊处理。 还应实施 Application Insights 的基于角色的访问控制，仅允许授权用户查看发送到 Application Insights 的数据。 有关详细信息，请参阅 Azure Application Insights 的安全做法。
此外，请参阅 Azure 通知中心的安全做法。
成本优化
成本优化是关于寻找减少不必要的费用和提高运营效率的方法。 有关详细信息，请参阅成本优化支柱概述。
此体系结构的定价在很大程度上因最终使用的服务层级、容量、吞吐量、对数据进行的查询类型、用户数以及业务连续性和灾难恢复而变化。 起价大约为 2,500 美元/月，并基于此价格进行调整。
若要开始使用，可以在此处查看 Azure 计算器通用估算。
根据工作负载的规模和对企业功能的要求，使用 Azure API 管理的消耗层可以降低成本。
作者
本文由 Microsoft 维护， 它最初是由以下贡献者撰写的。
主要作者：
- Matt Hansen | 云计划架构师
后续步骤
- 详细了解 Azure FHIR 服务
- 详细了解 Azure 运行状况数据服务。
- 详细了解在外部发布内部 API。