Azure 上のコンシューマー ヘルス ポータル

Azure App Service
Azure Functions
Azure Web アプリケーション ファイアウォール

この記事では、コンシューマー ヘルス ポータルの一般的なアーキテクチャについて説明します。これは、Azure Well Architected Framework の柱に沿っています。 このアーキテクチャは、特定のニーズに合わせてカスタマイズすることもできます。

アーキテクチャ

コンシューマー ヘルス ポータルのアーキテクチャの図。

このアーキテクチャの Visio ファイルをダウンロードします。

ワークフロー

  • このソリューションでは、Azure Front Door のグローバル フットプリントと Azure Web Application Firewall (WAF) のエッジ セキュリティ機能を使用して受信データを認証します。
  • 認証されたデータは、Azure API Management (APIM) によって、Azure App Service のユーザーのフロントエンド インターフェイス、または Azure Functions でホストされている API にルーティングされます。

このアーキテクチャで使用される主要なバックエンド データ サービスは Azure Cosmos DB です。 Azure Cosmos DB は、スケーラビリティとセキュリティに加えて、マルチモデル機能によって、あらゆる種類のコンシューマー ヘルス ポータルに柔軟性をもたらします。 レコード形式ではないデータは、オブジェクトとして Azure Blob Storage に保存されます。 このデータには、医療画像、コンシューマーが撮影した写真、アップロードされたドキュメント、アーカイブされたデータなどが含まれます。 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 Application Firewall は、OWASP の脆弱性、SQL インジェクション、クロスサイト スクリプティングなどの一般的な Web ベースの攻撃からアプリケーションを保護します。 これは、ライセンスを必要としない従量課金制のクラウドネイティブなテクノロジです。

  • Azure API Management は、API の公開、ルーティング、セキュリティ保護、ログ、分析を支援します。 API がエンドユーザーによってのみ使用されている場合も、外部との相互運用性のためにサードパーティと統合されている場合も、API Management により、API の拡張および表示方法に柔軟性を持たせることができます。

  • Azure App Service は、HTTP ベースの Web サービスをホストするために使用されるサービスです。 さまざまな言語がサポートされており、Linux または Windows で実行できます。CI/CD パイプラインと完全に統合されており、コンテナー ワークロードを PaaS 型サービスとして実行することもできます。 App Service では、Azure の ID、セキュリティ、ログの各サービスとのネイティブ統合に加えて、スケールアップとスケールアウトの両方が可能です。 コンプライアンスを維持しながら、コンシューマー ヘルス ポータルのスケーリングのニーズを満たすことができます。 このアーキテクチャでは、フロントエンド Web ポータルをホストします。

  • Azure Function Apps は、Azure 上のサーバーレス プラットフォーム ソリューションです。開発者は、基になるシステムを維持する必要なく、"オンデマンド コンピューティング" コードを記述できます。 このアーキテクチャでは、Azure Functions は、API と、非同期で実行する必要がある処理 (定期的なジョブの実行や一定期間にわたる統計の計算など) をホストできます。

  • Azure Cosmos DB は、フル マネージドのマルチモデル NoSQL データベース サービスです。1 桁の応答時間を提供し、あらゆる規模でパフォーマンスを保証します。 コンシューマー ヘルス システムの各ユーザーには、自分に関連するデータだけが提供されます。これは、NoSQL データ構造を使用するのが妥当であることを示しています。 Azure Cosmos DB は、ほぼ無制限のスケールとマルチリージョン読み取り/書き込みを提供します。 このような型のコンシューマー ヘルス システムによって収集されるデータの量が大幅に増加する中で、Azure Cosmos DB は、アクティブ ユーザーが 100 人でも 1,000,000 人でも、適切なセキュリティ、スピード、スケールを提供できます。

  • Azure Key Vault は、シークレット、キー、証明書を安全に保存し、これらにアクセスするために使用される Azure ネイティブ サービスです。 Key Vault は、HSM に支えられたセキュリティと、Microsoft Entra に統合されたロールベースのアクセス制御による監査されたアクセスを実現します。 アプリケーションは、キーやシークレットをローカルに保存してはいけません。 このアーキテクチャでは、Azure Key Vault を使用して、API キー、パスワード、暗号化キー、証明書などのすべてのシークレットを保存します。

  • Azure Active Directory B2C は、サービスとしての企業-消費者間 ID を大規模に提供します。アクティブ ユーザー数に応じてスケーリングするためのコストがかかります。 このソリューションのようなコンシューマー向けアプリケーションでは、ユーザーは新しいアカウントを作成する代わりに、自分の ID を持ち込むこともできます。 これは、ソーシャル ID から、電子メール アカウント、任意の SAML プロバイダー ID サービスまで何でもかまいません。 この手法により、ユーザーにとってより簡単なオンボード エクスペリエンスが提供されます。 ソリューション プロバイダーは、ユーザーの ID を参照するだけで済み、それらをホストして管理する必要はありません。

  • Azure Monitor ログ ツールである Azure Log Analytics は、診断またはログ情報に使用できます。また、このデータのクエリを実行して、並べ替え、フィルター処理、視覚化を行うこともできます。 このサービスは使用量に応じて課金されます。このソリューションのすべてのサービスからの診断ログと使用状況ログをホストするのに最適です。

  • Azure Monitor のもう 1 つの機能である Azure Application Insights は、Azure のネイティブ アプリケーション パフォーマンス管理 (APM) サービスです。 フロントエンドの App Service に簡単に統合できます。また、すべての AzureFunctions コードに統合して、アプリケーションのライブ監視を有効にすることもできます。 Application Insights では、アプリケーションをホストしているコンピューティング プラットフォームだけでなく、アプリケーション自体から直接発生したパフォーマンス、ユーザビリティの異常、障害を簡単に検出できます。

  • Azure Communication Services はクラウドベースのサービスです。用意されている REST API およびクライアント ライブラリ SDK を利用することで、通信を手軽にアプリケーションに組み込むことができます。 基になる技術 (メディアのエンコードやテレフォニーなど) の専門家でなくても、アプリケーションに通信を追加できます。 このソリューションでは、予約確認やリマインダーなど、コンシューマー ヘルス ポータルに関連するメール、テキスト、自動音声通話の送信に使用できます。

  • Azure Notification Hub は、任意のモバイル プラットフォームに通知を送信できる、シンプルでスケーラブルなプッシュ通知エンジンです。 モバイル アプリを使用するコンシューマー ヘルス ポータルは、Azure Notification Hub と統合することで、アプリをモバイルにインストールしているユーザーに、コスト効率よく通知をプッシュできます。 このアーキテクチャでは、ユーザーに予定を知らせる、切断されたデバイスの情報を入力する、特定の健康目標を達成するなどの目的で通知を送信できます。

  • Microsoft Defender for Cloud) は、このクラウドネイティブ ソリューション全体のセキュリティ監視とセキュリティ態勢管理の中核です。 Microsoft Defender for Cloud は、Azure プラットフォーム上のほぼすべての主要サービスと統合されます。 セキュリティ アラート、異常検出、ベスト プラクティスの推奨事項、規制コンプライアンス スコア、脅威検出などの機能を備えています。 このソリューションでは、HIPAA HITRUST コンプライアンス監視と、Azure セキュリティ ベスト プラクティスの全体的な監視に加えて、次の機能セットを使用します。

代替

  • Azure Health Data Services の一部として Azure FHIR Service は、HL7 または FHIR 通信標準を使用して、医療記録の相互運用性に使用できます。 アプリケーションが他のシステムから医療記録を受信したり、それらを送信したりする必要がある場合は、このサービスを使用する必要があります。 たとえば、このソリューションが医療プロバイダー向けのポータルの場合、Azure API for FHIR をプロバイダーの電子医療記録システムと直接統合できます。

  • Azure IoT Hub は、デバイス データを取り込むために微調整されたサービスです。 ポータルが、ウェアラブル デバイスやその他の医療機器からデータを収集するソリューションのフロントエンドである場合は、IoT Hub を使用してこのデータを取り込みます。 詳細については、「リモート患者モニタリング ソリューション」のアーキテクチャの INGEST (取り込み) プロセスを参照してください。

  • Microsoft 365 Email は、電子メールと通信に使用される業界トップクラスのサービスです。 多くの組織がこのサービスに既に投資しており、より充実した機能を備えた Azure Communication Services の代わりに使用できます。 このソリューションでは、予約確認メールやリマインダー メールなど、コンシューマー ヘルス ポータルに関連するメールの送信に使用できます。

シナリオの詳細

健康およびライフ サイエンス業界全体にわたり、組織は "デジタル ヘルス" 戦略を採用しつつあります。 デジタル ヘルス ソリューションの中心的な柱の 1 つであり、必須コンポーネントでもあるのが、"コンシューマー ヘルス ポータル" です。 コンシューマー ヘルス ポータルは、ウェアラブル デバイスからの進行状況と統計情報の追跡、医療プロバイダーとの連携、さらには健康的な食習慣の追跡にも使用できます。

考えられるユース ケース

  • ウェアラブル デバイスの統計情報を追跡する。
  • 医療記録にアクセスし、医療プロバイダーと連携する。
  • 服薬時間と服用量を入力する。これは、薬剤の補充データや自己追跡に使用できます。
  • 減量や糖尿病のための健康的な食事の指導者と対話する。

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

可用性

現在、このソリューションは単一リージョン デプロイとして設計されています。 実際のシナリオで、高可用性、ディザスター リカバリー、または近接性のために複数リージョンでのデプロイが必要な場合は、次の構成で、ペアになっている Azure リージョンが必要になる場合があります。

  • 複数リージョン構成を有効にするように Azure Cosmos DB を拡張します。

  • CI/CD を使用して、Azure API Management をセカンダリ リージョンにデプロイします。 API Management の複数リージョンのデプロイ機能を適用することもできます。

  • Azure App Service と Functions を複数リージョンに別々にデプロイします。 このデプロイは、並列デプロイを作成することで、CI/CD パイプライン内で実行できます。 詳細なガイダンスについては、「可用性の高い複数リージョンの Web アプリケーション」を参照してください。

  • RTO (目標復旧時間) の要件に応じて、Azure Blob Storage を geo 冗長ストレージ (GRS) として構成することも、代替リージョンから直接読み取ることができる読み取りアクセス geo 冗長ストレージ (RA-GRS) として構成することもできます。 詳細については、Azure Storage の冗長性に関する記事をご覧ください。

  • Azure Key Vault サービスには、複数層の可用性と冗長性が組み込まれています。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。

以下のセクションでは、このソリューションで使用される各サービスのセキュリティのベスト プラクティスについて説明します。

Azure Front Door

Azure Front Door の Web Application Firewall (WAF) を使用して、さまざまな一般的な攻撃を軽減する必要があります。 適切なベースラインとして、最初は最新バージョンの Open Web Application Security Project (OWASP) コア ルール セット (CRS) を使用し、必要に応じてカスタム ポリシーを追加します。 Azure Front Door は大量のトラフィックを吸収するように設計されていますが、可能であれば、このサービスで利用できるキャッシュ メカニズムを使用して、バックエンド システムへのトラフィックの負荷を軽減することを検討してください。 トラブルシューティングを行い、考えられるセキュリティ調査をサポートするには、Azure Front Door と Web Application Firewall の両方のログを構成する必要があります。 詳細については、Azure Front Door のセキュリティ プラクティスに関する記事をご覧ください。

Azure API Management

Azure AD B2C APIM 認証を使用するか、トークンで識別されるセッションを使用して、APIM へのすべてのトラフィックを認証する必要があります。 リソース ログを保存するように Azure API Management を構成します。 詳細については、Azure API Management のセキュリティ プラクティスに関する記事をご覧ください。

Azure App Service

App Service を含むこのアーキテクチャへのすべてのトラフィックは、TLS を使用してエンド ツー エンドで保護する必要があります。 App Service では、攻撃面を強化するために、セキュリティで保護されていないプロトコルを拒否する必要があります。 さらに、APIM はクライアントの認証を App Service に返して、App Service が独自のクライアント認証および承認に照らして検証できるようにします。 App Service で使用されるすべてのシークレットは、可能であれば、マネージド サービス ID を使用して Key Vault に保存します。 App Service は、セキュリティ診断作業をサポートするために診断ログも保存する必要があり、Microsoft Defender for App Service と統合する必要があります。 詳細については、Azure App Service のセキュリティ プラクティスに関する記事をご覧ください。

Azure Functions

このソリューションの Azure Functions へのすべての要求で、HTTPS を必須にしAzure API Management を使用して要求を認証する必要があります。さらに、可能であれば、マネージド ID を使用します。 キーを関数コードに残すのではなく、すべてのキーを Azure Key Vault に保存します。 他のアプリケーションと同様に、入力時に必ずデータを検証し、Microsoft Defender for Cloud と統合します。 最後に、Azure Functions のログと監視を常に構成します。 詳細については、Azure Functions のセキュリティ プラクティスに関する記事をご覧ください。

Azure Blob Storage

可能であれば、Microsoft Entra ID を使ってユーザー アクセスを認可し、BLOB ストレージへのリソース アクセスに管理サービス ID を使うことによって、BLOB ストレージへのアクセスを制限します。 これらの認証の種類がアプリケーションで機能しないおそれがある場合は、アカウント キーの代わりに、Shared Access Signature (SAS) トークンを最も細かいレベルで使用します。 アカウント キーの交換後、SAS トークンは無効になります。

BLOB ストレージには、ロールベースのアクセス制御も必ず使用してください。 Azure Storage ファイアウォールを使用して、"信頼された Microsoft サービス" からのトラフィック以外のネットワーク トラフィックを禁止します。 Azure Storage を Microsoft Defender for Cloud と常に統合し、監視を構成します。 詳細については、Azure Blob Storage のセキュリティ プラクティスに関する記事をご覧ください。

Azure Cosmos DB

Azure Cosmos DB の管理では、ロールベースのアクセス制御を有効にする必要があります。 Azure Cosmos DB のデータへのアクセスは、セキュリティで適切に保護する必要があります。 コントロール プレーン操作の診断ログを保存し、リソース ログも保存するように Azure Cosmos DB を構成できます。 詳細については、Azure Cosmos DB のセキュリティ プラクティスに関するページを参照してください。

Azure Key Vault

Azure Key Vault に対する要求は、特権アクセス制御に加えて、Microsoft Entra ID または MSI を使って認証する必要があります。 Azure Monitor で Key Vault の操作をログに記録するだけでなく、Key Vault を Microsoft Defender for Cloud と統合します。 詳細については、Azure Key Vault のセキュリティ プラクティスに関する記事をご覧ください。

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 Notification Hub のセキュリティ プラクティスに関する記事もご覧ください。

コストの最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

このアーキテクチャの価格は、最終的に使用するサービスのレベル、容量、スループット、データに対して実行されるクエリの種類、ユーザー数、事業継続とディザスター リカバリーによって大きく変動します。 月額約 2,500 ドルから始め、そこからスケーリングできます。

まず、Azure 料金計算ツールによる包括的な見積もりをこちらで確認できます。

ワークロードの規模とエンタープライズ機能の要件によっては、従量課金レベルの Azure API Management を使用することで、コストが削減される可能性があります。

共同作成者

この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。

プリンシパル作成者:

  • Matt Hansen | クラウド プログラム アーキテクト

次のステップ