本文說明取用者健康情況入口網站的典型架構，其符合 Azure Well Architected Framework 的要素。 您可以選擇自定義此架構，以符合您的特定需求。
架構
工作流程
- 此解決方案會使用 Azure Web 應用程式防火牆 （WAF） 的 Azure Front Door 和邊緣安全性功能的全域使用量來驗證輸入數據。
- 然後，Azure API 管理 （APIM） 會將已驗證的數據路由傳送至 Azure App 服務 上使用者的前端介面，或裝載在 Azure Functions 中的 API。
此架構中使用的主要後端數據服務是 Azure Cosmos DB。 除了 Azure Cosmos DB 的延展性和安全性之外，Azure Cosmos DB 的多模型功能也允許任何類型的取用者健康情況入口網站彈性。 任何不是記錄格式的數據，都儲存在 Azure Blob 儲存體 做為物件。 此數據可能包括醫療影像、取用者拍攝的照片、上傳的檔、封存的數據等等。 Blob 記憶體可為大量非結構化數據提供負擔得起的記憶體。 這類數據類型並未針對 Azure Cosmos DB 中的記憶體進行優化，而且可能會對其成本和效能造成負面影響。
元件
Azure HIPAA HITRUST 9.2 藍圖是使用 Azure 原則 的 Azure 藍圖。 其可協助評估 HIPAA HITRUST 9.2 控件，並部署 Azure 工作負載的核心原則集。 雖然這不會提供 HIPAA HITRUST 的完整合規性涵蓋範圍，但您可以在適用且必要的情況下，開始並新增更多控件。 此藍圖和介面中的原則計劃合規性也可以可視化 適用於雲端的 Microsoft Defender。
Azure Front Door 可用來管理大規模邊緣流量，並藉由呈現世界各地的端點來提升終端使用者的效能。 這項技術為雲端原生，不需要任何授權;您只需支付您所使用的費用。 在此工作負載案例中，Azure Front Door 可作為所有流量到取用者健康情況入口網站的輸入點。
Azure Web 應用程式防火牆 保護應用程式免於常見的 Web 型攻擊，例如 OWASP 弱點、SQL 插入、跨網站腳本和其他攻擊。 這項技術是雲端原生的，不需要任何授權，而且是隨用隨付。
Azure API 管理 有助於發佈、路由、保護、記錄和分析 API。 不論 API 僅供終端使用者使用，或與第三方整合以進行外部互操作性，API 管理都可讓您彈性地擴充和呈現 API。
Azure App 服務 是用來裝載 HTTP 型 Web 服務的服務。 它支援各種不同的語言、可在 Linux 或 Windows 上執行、與 CI/CD 管線完全整合，甚至可以以 PaaS 供應專案的形式執行容器工作負載。 除了在 Azure 中原生整合身分識別、安全性和記錄服務之外，App Service 還允許相應增加和向外延展。 它能夠符合取用者健康情況入口網站的調整需求，同時維持合規性。 在此架構中，它會裝載前端入口網站。
Azure Function Apps 是 Azure 上的無伺服器平台解決方案，可讓開發人員撰寫 隨選計算 程式代碼，而不需要維護任何基礎系統。 在此架構中，Azure Functions 可以裝載 API，以及任何需要以異步方式完成的工作，例如在特定時段內執行定期作業和計算統計數據。
Azure Cosmos DB 是完全受控、多模型、NoSQL 資料庫供應專案，可提供單一位數回應時間，並保證任何規模的效能。 取用者健康情況系統中的每個使用者只會有與本身相關的數據，這可讓 NoSQL 數據結構使用合理。 Azure Cosmos DB 具有幾乎無限制的規模，以及多區域讀取和寫入。 Azure Cosmos DB 隨著這類取用者健康系統所收集的數據量大幅成長，無論有 100 或 1,000,000 位作用中使用者，都可以提供適當的安全性、速度和規模。
Azure 金鑰保存庫 是 Azure 原生服務，可用來安全地儲存和存取秘密、金鑰和憑證。 金鑰保存庫 允許 HSM 支援的安全性，並透過 Microsoft Entra 整合式角色型訪問控制來稽核存取。 應用程式不應該將金鑰或秘密儲存在本機。 此架構會使用 Azure 金鑰保存庫 來儲存所有秘密，例如 API 金鑰、密碼、密碼編譯密鑰和憑證。
Azure Active Directory B2C 會大規模提供企業對取用者身分識別即服務，其成本會隨著作用中的用戶計數一起調整。 在這類解決方案的取用者面向應用程式中，使用者可能會想要攜帶自己的身分識別，而不是建立新的帳戶。 它可以是任何專案，從社交標識碼、電子郵件帳戶或任何 SAML 提供者身分識別服務。 此方法為使用者提供更簡單的上線體驗。 解決方案提供者只需要參考使用者身分識別，而且不需要裝載和維護它們。
Azure Log Analytics 是 Azure 監視器記錄工具，可用於診斷或記錄資訊，以及查詢此數據來排序、篩選或可視化數據。 此服務會依耗用量來定價，而且非常適合用來裝載此解決方案中所有服務的診斷和使用記錄。
Azure 應用程式 Insights 是 Azure 監視器的另一項功能，是 Azure 中的原生應用程式效能管理 （APM） 服務。 它可以輕鬆地整合到前端 App Service 中，並整合到所有 Azure Functions 程式代碼中，以啟用應用程式的實時監視。 Application Insights 可以輕鬆地偵測直接從應用程式本身產生的效能、可用性異常和錯誤，而不只是從裝載它們的計算平臺。
Azure 通訊服務 是具有 REST API 和用戶端連結庫 SDK 的雲端式服務，可協助您將通訊整合到應用程式。 您可以新增對應用程式的通訊，而不需成為媒體編碼或電話語音等基礎技術的專家。 在此解決方案中，它可用於傳送任何與消費者健康情況入口網站相關的電子郵件、文字或自動通話，例如約會確認或提醒。
Azure 通知中樞 是簡單且可調整的推播通知引擎，可讓您將通知傳送至任何行動平臺。 使用行動應用程式的取用者健康情況入口網站可以與 Azure 通知中樞整合，以符合成本效益的方式將通知推播給已在其行動裝置上安裝應用程式的使用者。 在此架構中，可以傳送通知來提醒使用者約會、輸入已中斷連線裝置的資訊、達到特定健康情況目標等等。
適用於雲端的 Microsoft Defender） 是此整個雲端原生解決方案的安全性監視和狀態管理的核心。 適用於雲端的 Microsoft Defender 與 Azure 平台上幾乎所有的主要服務整合。 其功能包括安全性警示、異常偵測、最佳做法建議、法規合規性分數，以及威脅偵測。 除了 HIPAA/HITRUST 合規性監視，以及整體 Azure 安全性最佳做法監視之外，此解決方案還使用下列功能集：
替代項目
Azure FHIR 服務作為 Azure Health Data Services 的一部分，可用於醫療記錄的互操作性，使用 HL7 或 FHIR 通訊標準。 如果您的應用程式需要從其他系統接收或傳輸醫療記錄，則應該使用此服務。 例如，如果此解決方案是醫療提供者的入口網站，Azure API for FHIR 可以直接與提供者的電子醫療記錄系統整合。
Azure IoT 中樞 是針對內嵌裝置數據而微調的服務。 如果入口網站是從可穿戴裝置或任何其他醫療設備收集數據的解決方案前端，則 IoT 中樞 應該用來內嵌此數據。 如需詳細資訊，請參閱遠端病患監視解決方案架構的 INGEST 程式。
Microsoft 365 電子郵件 是一項領先業界的服務，用於電子郵件和通訊。 許多組織已經投資此服務，而且可作為功能更完整的 Azure 通訊服務 替代方案。 在此解決方案中，它可用來傳送任何與消費者健康情況入口網站相關的電子郵件，例如約會確認或提醒電子郵件。
案例詳細資料
在整個健康與生命科學產業中，組織都採用 數位健康 策略。 數位健康解決方案的核心要素和必要元件之一是 消費者健康入口網站。 消費者健康入口網站可用於追蹤可穿戴裝置的進度和統計數據、與醫療提供者接觸，甚至追蹤健康飲食習慣。
潛在使用案例
- 追蹤可穿戴裝置的統計數據。
- 獲得醫療記錄的存取權，並與醫療提供者接觸。
- 輸入時間和劑量的藥物，可用於重新填充數據或自我追蹤藥物。
- 與健康飲食教練互動，以減肥或糖尿病。
考量
這些考量能實作 Azure Well-Architected Framework 的要素，其為一組指導原則，可以用來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework (部分機器翻譯)。
可用性
此解決方案目前設計為單一區域部署。 如果您的案例需要多區域部署以進行高可用性、災害復原，或甚至鄰近性，您可能需要 具有下列設定的配對 Azure 區域 。
Azure Cosmos DB 已擴充，以啟用 多區域設定。
Azure API 管理 會使用 CI/CD 部署到次要區域。 您也可以套用 API 管理 的多區域部署功能。
Azure App 服務和 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 App Service
此架構的所有流量，包括 App Service，都應該使用 TLS 保護端對端。 App Service 應 拒絕不安全的通訊協定 ，以收緊受攻擊面。 此外，APIM 應該將客戶端的驗證傳回至 App Service，以允許它根據自己的 客戶端驗證和授權進行驗證。 App Service 中使用的所有秘密都應該儲存在 金鑰保存庫，盡可能使用受控服務識別。 App Service 也應該 儲存診斷記錄 ，以支援任何安全性診斷工作，並應與 適用於 App Service 的 Microsoft Defender 整合。 如需詳細資訊，請參閱 Azure App 服務 的安全性做法
Azure Functions
此解決方案中 Azure Functions 的所有要求都應該需要 HTTPS、使用 Azure API 管理 來驗證要求，以及盡可能使用受控識別。 將所有金鑰儲存在 Azure 金鑰保存庫 中，而不是將它們留在函式程式碼中。 和任何應用程式一樣，請務必在輸入時驗證數據，並與 適用於雲端的 Microsoft Defender 整合。 最後，一律設定 Azure Functions 的記錄和監視。 如需詳細資訊 ，請參閱 Azure Functions 的安全性做法。
Azure Blob 儲存體
可能的話，請使用 Microsoft Entra ID 來授權使用者存取權，以及 受控服務識別 來存取 Blob 記憶體，以限制對 Blob 記憶體的存取。 如果這些驗證類型可能不適用於您的應用程式，請使用 最細微層級的共用存取簽章 （SAS） 令牌，而不是帳戶密鑰。 輪替帳戶金鑰之後，SAS 令牌會失效。
請務必也針對 Blob 記憶體使用 角色型存取控制 。 使用 Azure 儲存體 防火牆來禁止來自受信任 Microsoft 服務的流量以外的網路流量。 一律整合 Azure 儲存體 與 適用於雲端的 Microsoft Defender 並設定監視。 如需詳細資訊，請參閱 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 監視器中記錄 金鑰保存庫 動作之外，整合 金鑰保存庫 與 適用於雲端的 Microsoft Defender。 如需詳細資訊，請參閱 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 應用程式 Insights 的安全性做法。
此外，請參閱 Azure 通知中樞的安全性做法。
成本最佳化
成本最佳化是關於考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱成本最佳化要素的概觀。
此架構的定價基本上會根據您最終使用的服務層級、容量、輸送量、對數據執行的查詢類型、用戶數目，以及商務持續性和災害復原而定。 它可以從大約2,500美元/mo開始，並從那裡進行調整。
若要開始使用，您可以在這裡檢視 Azure 計算機一般估計值。
根據工作負載的規模和企業功能需求而定，使用 Azure API 管理 的取用層可能會降低成本。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主體作者：
- Matt Hansen |雲端計劃架構師
下一步
- 深入瞭解 Azure FHIR 服務
- 深入瞭解 Azure Health Data Services。
- 深入瞭解從 外部發佈內部 API。