Клиентский портал здравоохранения на базе Azure

Служба приложений Azure
Функции Azure
Брандмауэр веб-приложения Azure

В этой статье описывается типичная архитектура портала работоспособности потребителей, которая соответствует основам Azure Well Architected Framework. Вы можете настроить эту архитектуру в соответствии с конкретными потребностями.

Архитектура

Схема архитектуры портала работоспособности потребителей.

Скачайте файл Visio для этой архитектуры.

Рабочий процесс

  • В этом решении для проверки подлинности входящих данных используется глобальная версия службы Azure Front Door и функции безопасности Брандмауэра веб-приложений Azure (WAF).
  • Затем данные, прошедшие проверку подлинности, перенаправляются службой управления API Azure (APIM) в интерфейсную часть для пользователей Службы приложений Azure или в API, размещенные на платформе Функций Azure.

В качестве основной серверной службы данных в этой архитектуре используется Azure Cosmos DB. Возможности нескольких моделей Azure Cosmos DB в дополнение к масштабируемости и безопасности позволяют гибко использовать любой тип портала работоспособности потребителей. Любые данные, не находящиеся в формате записи, хранятся в службе Хранилища BLOB-объектов Azure в качестве объекта. Эти данные могут включать медицинские изображения, созданные потребителем фотографии, отправленные им документы, архивные данные и т. д. Хранилище 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 защищает приложения от распространенных веб-атак, таких как уязвимости OWASP, внедрение кода SQL, межсайтовые сценарии и др. Это ориентированная на облако технология, которая не требует какого-либо лицензирования: вы платите только за фактически используемые ресурсы.

  • Управление API Azure помогает в публикации, маршрутизации, обеспечении безопасности, ведении журналов и аналитике API. Независимо от того, используется ли API только конечным пользователем или интегрируется со сторонним решением для внешнего взаимодействия, служба управления API обеспечивает гибкость в плане расширения и представления API.

  • Служба приложений Azure — это платформа, используемая для размещения веб-служб на основе HTTP. Она поддерживает широкий спектр языков, может работать на Linux или Windows, полностью интегрируется с конвейерами CI/CD и даже может запускать рабочие нагрузки контейнеров в качестве решения PaaS. Служба приложений поддерживает как вертикальное, так и горизонтальное увеличение масштаба, а также встроенную интеграцию со службами управления идентификаторами, обеспечения безопасности и журналов в Azure. Она удовлетворяет потребности в масштабировании на медицинском портале для потребителей, не жертвуя при этом соответствием требованиям. В данной архитектуре на этой платформе размещен интерфейсный веб-портал.

  • Приложения-функции Azure — это бессерверная платформа Azure, которая позволяет разработчикам писать код для вычислений по запросу без необходимости обслуживания и поддержки каких-либо базовых систем. В этой архитектуре на платформе Функций Azure могут быть размещены API и любые рабочие нагрузки, которые должны выполняться асинхронно, такие как выполнение периодических заданий и расчет статистики за определенный период.

  • Azure Cosmos DB — это полностью управляемое решение NoSQL для базы данных, обеспечивающее малое время отклика и гарантирующее производительность в любом масштабе. У каждого пользователя медицинской системы для потребителей должен быть доступ только к данным, связанным непосредственно с ним, что оправдывает использование структуры данных NoSQL. Azure Cosmos DB имеет почти неограниченное масштабирование, а также многорегионное чтение и запись. При резком росте объема данных, собранных этими типами систем здравоохранения потребителей, Azure Cosmos DB может обеспечить соответствующую безопасность, скорость и масштаб, независимо от наличия 100 или 100 000 000 активных пользователей.

  • Azure Key Vault — это собственная служба Azure, которая используется для безопасного хранения секретов, ключей и сертификатов и доступа к ним. Key Vault обеспечивает безопасность с поддержкой HSM и аудит доступа через интегрированные элементы управления доступом на основе ролей Microsoft Entra. Приложения не должны хранить ключи или секреты локально. Эта архитектура использует Azure Key Vault для хранения всех секретов, таких как ключи API, пароли, криптографические ключи и сертификаты.

  • Azure Active Directory B2C предоставляет идентификаторы типа "бизнес — потребитель" в качестве услуги в большом масштабе, и затраты на него масштабируется вместе с числом активных пользователей. В таких приложениях, как это решение для потребителей, вместо создания новой учетной записи пользователи могут захотеть принести собственное удостоверение. Это может быть любой идентификатор из социальных сетей, учетная запись электронной почты или любой службы идентификации поставщика SAML. Этот метод упрощает процедуру подключения для пользователя. Поставщику решения достаточно ссылаться на идентификаторы пользователей, не размещая и не обслуживая их.

  • Azure Log Analytics, средство журналирования Azure Monitor, можно использовать для организации доступа к диагностической информации и журналам, а также для запроса соответствующих данных для сортировки, фильтрации и визуализации. Эта служба оплачивается по мере потребления ресурсов и идеально подходит для размещения журналов диагностики и использования со всех служб в одном решении.

  • Application Insights Azure, еще один компонент Azure Monitor, — это собственная служба управления производительностью приложений (APM) в Azure. Ее можно легко интегрировать с интерфейсной Службой приложений, а также с любым кодом Функций Azure для динамического мониторинга приложений. Application Insights может легко отслеживать производительность, аномалии в плане удобства использования и сбои, возникающие непосредственно в приложениях, а не только на вычислительной платформе, на которой они размещены.

  • Службы коммуникации Azure — это облачные службы с интерфейсами REST API и пакетами SDK клиентской библиотеки, доступными для интеграции взаимодействия с приложениями. Вы можете добавить связь к приложениям, не будучи экспертом в базовых технологиях, таких как кодировка мультимедиа или телефония. В этом решении его можно использовать для отправки сообщений электронной почты, текстов или автоматических телефонных звонков, связанных с порталом работоспособности потребителей, например подтверждения встречи или напоминания.

  • Центр уведомлений Azure — это простая и масштабируемая платформа рассылки push-уведомлений, позволяющая отправлять уведомления на любую мобильную платформу. Медицинский портал для потребителей, использующий мобильное приложение, может интегрироваться с Центром уведомлений Azure для экономичной отправки уведомлений пользователям, которые установили это приложение на своих мобильных устройствах. В этой архитектуре уведомления позволяют напоминать пользователям о запланированных визитах к врачу, о необходимости ввести данные отключенного устройства, об установленных медицинских целях и т. д.

  • Microsoft Defender для облака) — это основной компонент мониторинга безопасности и управления состоянием для всего этого облачного решения. Microsoft Defender для облака интегрируется почти со всеми основными службами на платформе Azure. Возможности этой системы включают оповещения системы безопасности, обнаружение аномалий, рекомендации, оценки соответствия нормативным требованиям и обнаружение угроз. Помимо мониторинга соответствия требованиям HIPAA/HITRUST и общего мониторинга рекомендаций по безопасности Azure, это решение использует следующие наборы функций:

Альтернативные варианты

  • Служба Azure FHIR в составе служб данных Работоспособности Azure может использоваться для взаимодействия медицинских записей с использованием стандартов связи HL7 или FHIR. Эту службу следует использовать, если приложению требуется получать медицинские записи из других систем или передавать их туда. Например, если это решение является порталом для поставщиков медицинских услуг, API Azure для FHIR может напрямую интегрироваться с системой управления электронными медицинскими записями поставщика.

  • Центр Интернета вещей Azure — это служба, которая настроена для приема данных с устройств. Если портал является внешним интерфейсом решения, собирающего данные с носимого или любого другого медицинского устройства, для их приема следует использовать Центр Интернета вещей. Дополнительные сведения см. в описании процесса приема в рамках архитектуры решений для удаленного мониторинга пациентов.

  • Microsoft 365 Email — это ведущая в отрасли служба, используемая для сообщений электронной почты и коммуникаций. Многие организации уже инвестировали в эту службу, и ее можно использовать в качестве альтернативы более полнофункциональный Службы коммуникации Azure. В этом решении ее можно задействовать для отправки любых сообщений электронной почты, связанных с работой медицинского портала для потребителей, таких как подтверждения визитов и напоминания.

Подробности сценария

Организации, работающие в сфере здравоохранения и медико-биологических наук, принимают стратегию цифровой медицины. Одним из ключевых и необходимых компонентов любого решения в сфере цифровой медицины является клиентский портал здравоохранения, т. е. медицинский портал для потребителей. Портал здоровья потребителей может использоваться для отслеживания хода выполнения и статистики с носимого устройства, взаимодействия с медицинским поставщиком или даже отслеживания здоровых привычек питания.

Потенциальные варианты использования

  • Отслеживание статистики, поступающей с носимого устройства.
  • Доступ к медицинским данным и взаимодействие с медицинским специалистом.
  • Ввод времени и доз приема лекарств, на основе которых можно автоматически пополнять их запасы и самостоятельно отслеживать их прием.
  • Взаимодействуйте с инструктором по здоровому питанию для борьбы с лишним весом или диабетом.

Рекомендации

Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая является набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.

Availability

В настоящее время это решение предназначено для развертывания в одном регионе. Если для сценария требуется развертывание с несколькими регионами для обеспечения высокой доступности, аварийного восстановления или даже близкого взаимодействия, может потребоваться парный регион Azure со следующими конфигурациями.

  • Azure Cosmos DB расширен для включения конфигурации с несколькими регионами.

  • Управление API Azure развертывается с помощью CI/CD в дополнительный регион. Вы также можете применить возможность развертывания с несколькими регионами Управление API.

  • Служба приложений и Функции Azure развертываются отдельно в нескольких регионах. Это развертывание можно выполнить в рамках конвейера CI/CD, создав параллельное развертывание. Дополнительные рекомендации см. в статье о веб-приложении с высокой доступностью для нескольких регионов.

  • В зависимости от требований к RTO (целевому времени восстановления) Службу хранилища BLOB-объектов Azure можно настроить как геоизбыточное хранилище (GRS) или геоизбыточное хранилище с доступом на чтение (RA-GRS), что позволяет считывать данные непосредственно из альтернативного региона. Дополнительные сведения см. в статье об избыточности службы хранилища Azure.

  • В службе Azure Key Vault предусмотрено несколько встроенных уровней доступности и избыточности.

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".

В следующих разделах описаны рекомендации по обеспечению безопасности для каждой из служб в этом решении.

Azure Front Door

Для нейтрализации ряда распространенных атак можно использовать Брандмауэр веб-приложений (WAF) Azure Front Door. Лучше всего начать с последней версии базовых наборов правил Open Web Application Security Project (OWASP), а затем по мере необходимости добавить пользовательские политики. Хотя служба Azure Front Door предназначена для обработки больших объемов трафика, вы можете использовать доступные в ней механизмы кэширования, позволяющие уменьшить трафик в серверные системы, где это возможно. Для устранения неполадок и помощи в ходе возможного расследования безопасности необходимо настроить журналирование как для Azure Front Door, так и для брандмауэра веб-приложений. Дополнительные сведения см. в рекомендациях по безопасности для Azure Front Door.

Управление API Azure

Весь трафик к APIM должен проходить проверку подлинности через систему аутентификации APIM Azure AD B2C или сеансы, идентифицированные токеном. Настройте службу Управления API Azure для хранения журналов ресурсов. Дополнительные сведения см. в рекомендациях по безопасности для службы Управления API Azure.

Служба приложений Azure

Весь трафик к этой архитектуре, включая службу приложений, должен быть защищен с применением сквозного протокола TLS. Служба приложений должна запрещать использование незащищенных протоколов, чтобы сократить зону атаки. Кроме того, служба APIM должна возвращать результаты проверки подлинности клиента Службе приложений, чтобы та могла провести собственную аутентификацию и авторизацию клиента. Все секреты, используемые в Службе приложений, должны храниться в Key Vault с использованием удостоверения управляемой службы, если это возможно. Служба приложений также должна хранить журналы диагностики на случай каких-либо диагностических операций и должна быть интегрирована с Microsoft Defender для Службы приложений. Дополнительные сведения см. в рекомендациях по безопасности для Службы приложений Azure.

Функции Azure

Все запросы к Функциям Azure в этом решении должны требовать использования протокола HTTPS, использовать службу Управления API Azure для проверки подлинности запросов и управляемые удостоверения там, где это возможно. Храните все ключи в Azure Key Vault, а не в коде Функции. Как и в любом приложении, обязательно проверьте данные на входе и выполните интеграцию с Microsoft Defender для облака. Наконец, обязательно настройте ведение журнала и мониторинг для Функций Azure. Дополнительные сведения см. в рекомендациях по безопасности для Функций Azure.

Хранилище BLOB-объектов Azure

По возможности ограничьте доступ к хранилищу BLOB-объектов с помощью идентификатора Microsoft Entra для авторизации доступа пользователей и управляемых удостоверений службы для доступа к ресурсу к хранилищу BLOB-объектов. Если эти типы проверки подлинности могут не работать для приложения, используйте маркер подписанного URL-адреса (SAS) на самом детальном уровне вместо ключа учетной записи. Маркеры SAS становятся недействительными после смены ключей учетной записи.

Также необходимо использовать управление доступом на основе ролей для хранилища BLOB-объектов. Используйте службу Брандмауэров хранилища Azure, чтобы запретить сетевой трафик, кроме трафика от Доверенных служб Майкрософт. Всегда интегрируйте службу хранилища Azure с Microsoft Defender для облака и настройте мониторинг. Дополнительные сведения см. в рекомендациях по безопасности для Хранилища BLOB-объектов Azure.

Azure Cosmos DB

Для управления Azure Cosmos DB необходимо включить элементы управления доступом на основе ролей. Доступ к данным в Azure Cosmos DB должен быть надлежащим образом защищен. Azure Cosmos DB можно настроить для хранения журналов диагностики для операций уровня управления и хранения журналов ресурсов. Дополнительные сведения см. в рекомендациях по безопасности для Azure Cosmos DB.

Azure Key Vault

Запросы, сделанные в Azure Key Vault, должны проходить проверку подлинности с помощью идентификатора Microsoft Entra или MSI в дополнение к привилегированным элементам управления доступом. Интегрируйте Key Vault с Microsoft Defender для облака в дополнение к журналированию операций с Key Vault в Azure Monitor. Дополнительные сведения см. в рекомендациях по безопасности для 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.

Оптимизация затрат

Оптимизация затрат заключается в поиске способов уменьшения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в разделе Обзор критерия "Оптимизация затрат".

Расценки на эту архитектуру по большей части определяются уровнями служб, которые вы используете, емкостью, пропускной способностью, типами запросов к данным, числом пользователей, а также непрерывностью бизнес-процессов и аварийным восстановлением. Цена начинается приблизительно с 2500 долларов в месяц и зависит от масштаба.

Для начала вы можете ознакомиться с общей оценкой в калькуляторе Azure.

В зависимости от масштаба рабочей нагрузки и требований к корпоративным функциям сократить затраты может использование категории "Потребление" службы "Управление API" Azure.

Соавторы

Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участник.

Автор субъекта:

Следующие шаги