Проверка подлинности и авторизация для служб Azure для работы с медицинскими данными

  • Статья

Аутентификация

Службы azure Health Data Services — это коллекция защищенных управляемых служб, использующих Azure Active Directory (Azure AD), глобальный поставщик удостоверений, поддерживающий OAuth 2.0.

Чтобы службы azure Health Data Services могли получить доступ к ресурсам Azure, таким как учетные записи хранения и центры событий, необходимо включить управляемое системой удостоверение и предоставить соответствующие разрешения управляемому удостоверению. Дополнительные сведения см. в статье Управляемые удостоверения Azure.

Службы azure Health Data Services не поддерживают других поставщиков удостоверений. Однако вы можете использовать собственный поставщик удостоверений для защиты приложений и позволить им взаимодействовать со службами данных работоспособности, управляя клиентскими приложениями и элементами управления доступом к данным пользователей.

Клиентские приложения регистрируются в Azure AD и могут использоваться для доступа к службам azure Health Data Services. Элементы управления доступом к данным пользователей выполняются в приложениях или службах, реализующих бизнес-логику.

Роли приложений

Пользователям, прошедшим проверку подлинности, и клиентским приложениям служб azure Health Data Services должны быть предоставлены соответствующие роли приложений.

Служба FHIR служб Azure Health Data Services предоставляет следующие роли:

  • Читатель данных FHIR: может считывать (и искать) данные FHIR.
  • Модуль записи данных FHIR: может считывать, записывать и обратимо удалять данные FHIR.
  • Средство экспорта данных FHIR: может считывать и экспортировать данные (оператор $export).
  • Средство импорта данных FHIR: может считывать и импортировать данные (оператор $import).
  • Участник данных FHIR. Может выполнять все операции плоскости данных.
  • FHIR Data Converter. Может использовать преобразователь для преобразования данных.
  • FHIR SMART User. Роль позволяет пользователю считывать и записывать данные FHIR в соответствии со спецификациями SMART IG версии 1.0.0.

Служба DICOM служб медицинских данных Azure предоставляет следующие роли:

  • Владелец данных DICOM: может считывать, записывать и удалять данные DICOM.
  • Чтение данных DICOM. Может считывать данные DICOM.

Службе MedTech не требуются роли приложения, но она использует "Центры событий Azure Приемник данных" для получения данных, хранящихся в концентраторе событий подписки клиента.

Авторизация

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

  • Для службы FHIR маркер доступа зависит от службы или ресурса.
  • Для службы DICOM маркер доступа предоставляется ресурсу dicom.healthcareapis.azure.com , а не определенной службе.
  • Для службы MedTech маркер доступа не требуется, так как он не предоставляется пользователям или клиентским приложениям.

Шаги для авторизации

Существует два распространенных способа получения маркера доступа, подробно описанные в документации по Azure AD: поток кода авторизации и поток учетных данных клиента.

Ниже описано, как получить маркер доступа для служб azure Health Data Services с помощью потока кода авторизации:

  1. Клиент отправляет запрос на конечную точку авторизации Azure AD. Azure AD перенаправляет клиент на страницу входа, где пользователь проходит проверку подлинности, используя соответствующие учетные данные (например, имя пользователя и пароль или двухфакторную проверку подлинности). После успешной проверки подлинности клиенту возвращается код авторизации. Azure AD позволяет возвращать этот код авторизации только на зарегистрированный URL-адрес ответа, настроенный при регистрации клиентского приложения.

  2. Клиентское приложение обменивает код авторизации на маркер доступа в конечной точке маркера Azure AD. Когда клиентское приложение запрашивает маркер, приложению может потребоваться предоставить секрет клиента (который можно добавить во время регистрации приложения).

  3. Клиент отправляет запрос к службам azure Health Data Services, GET например запрос на поиск всех пациентов в службе FHIR. Запрос включает маркер доступа в заголовке HTTP запроса, например Authorization: Bearer xxx.

  4. Службы azure Health Data Services проверяют, содержит ли маркер соответствующие утверждения (свойства в маркере). Если он действителен, он завершает запрос и возвращает данные клиенту.

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

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

Маркер доступа

Маркер доступа — это подписанная в кодировке Base64 коллекция свойств (утверждений), которые передают сведения об удостоверении, ролях и привилегиях клиента, предоставленных пользователю или клиенту.

Службы Azure Health Data Services обычно ожидают веб-маркер JSON. Он состоит из трех частей:

  • Заголовок
  • Полезные данные (утверждения)
  • Подпись, как показано на изображении. Дополнительные сведения см. в статье Маркеры доступа Azure.

Подпись веб-маркера JASON.

Используйте интернет-инструменты, такие как https://jwt.ms , для просмотра содержимого маркера. Например, можно просмотреть сведения о утверждениях.

Тип утверждения Значение Примечания
aud https://xxx.fhir.azurehealthcareapis.com Определяет целевого получателя маркера. Аудитория — это идентификатор вашего приложения в id_tokens, назначенный приложению на портале Azure. Приложение должно проверить это значение и отклонить маркер, если значение не совпадает.
iss https://sts.windows.net/{tenantid}/ Определяет службу маркеров безопасности (STS), которая создает и возвращает маркер, а также клиент Azure AD, в котором пользователь прошел аутентификацию. Если маркер был выдан конечной точкой версии 2.0, URI заканчивается на /v2.0. GUID, который указывает, что пользователь является потребителем с учетной записью Майкрософт: 9188040d-6c67-4c5b-b112-36a304b66dad. Приложение должно использовать часть утверждения GUID, чтобы ограничить набор клиентов, которые могут входить в приложение, если это применимо.
iat (метка времени) Значение Issued At (Выпущено в) показывает, когда произошла проверка подлинности этого маркера.
nbf (метка времени) Утверждение "nbf" (не ранее) определяет время, до которого маркер JWT НЕ ДОЛЖЕН приниматься в обработку.
exp (метка времени) Утверждение "exp" (время окончания срока действия) указывает время окончания срока действия или время, после которого маркер JWT НЕ ДОЛЖЕН приниматься в обработку. Обратите внимание, что ресурс может отклонить маркер до этого времени, например, если требуется изменение проверки подлинности или обнаружен отзыв маркера.
aio E2ZgYxxxx Внутреннее утверждение, в котором Azure AD сохраняет данные для повторного использования маркеров. Можно пропустить.
appid e97e1b8c-xxx Идентификатор приложения клиента, использующего маркер. Приложение может действовать самостоятельно или от имени пользователя. Идентификатор приложения, как правило, представляет объект приложения, но может также представлять и объект субъекта-службы в Azure AD.
appidacr 1 Указывает на способ проверки подлинности клиента. Для общедоступного клиента значение равно 0. При использовании идентификатора и секрета клиента значение равно 1. Если для аутентификации использовался сертификат клиента, то значение равно 2.
idp https://sts.windows.net/{tenantid}/ Фиксирует поставщика удостоверений, который проверил подлинность субъекта маркера. Это значение идентично значению утверждения издателя, если учетная запись пользователя не находится в том же клиенте, что и издатель , например гости. Если утверждение отсутствует, это означает, что вместо него можно использовать значение iss. Для личных учетных записей, используемых в контексте организации (например, личная учетная запись, приглашенных в клиент Azure AD), утверждение поставщика удостоверений может быть "live.com" или URI STS, содержащий клиент учетной записи Майкрософт 9188040d-6c67-4c5b-b112-36a304b66dad.
oid Например, tenantid Неизменяемый идентификатор объекта в системе идентификации Майкрософт. В данном случае это учетная запись пользователя. Этот идентификатор однозначно идентифицирует пользователя в разных приложениях. Два разных приложения, выполняющие вход одного и того же пользователя, получают одинаковое значение в утверждении oid. Microsoft Graph возвращает этот идентификатор в качестве свойства идентификатора для определенной учетной записи пользователя. Так как объект oid позволяет нескольким приложениям сопоставлять пользователей, для получения этого утверждения требуется область профиля. Примечание. Если один пользователь существует в нескольких клиентах, он содержит разные идентификаторы объекта в каждом клиенте . Они считаются разными учетными записями, даже если пользователь входит в каждую учетную запись с одинаковыми учетными данными.
rh 0.ARoxxx Внутреннее утверждение, используемое Azure для повторной проверки маркеров. Его следует игнорировать.
sub Например, tenantid Принцип, о котором маркер утверждает информацию, например пользователя приложения. Это значение неизменяемо и не может быть переназначано или использовано повторно. Субъект — это попарный идентификатор, который уникален для определенного идентификатора приложения. Таким образом, если один пользователь входит в два разных приложения, используя два разных идентификатора клиента, эти приложения получают два разных значения для утверждения субъекта. Этот результат может потребоваться или не требуется в зависимости от вашей архитектуры и требований к конфиденциальности.
tid Например, tenantid Идентификатор GUID, представляющий клиент Azure AD пользователя. Для рабочих и учебных учетных записей значением GUID является неизменяемый идентификатор клиента организации, к которой принадлежит пользователь. Для личных учетных записей значение равно 9188040d-6c67-4c5b-b112-36a304b66dad. Для получения этого утверждения требуется область профиля.
uti bY5glsxxx Внутреннее утверждение, используемое Azure для повторной проверки маркеров. Его следует игнорировать.
ver 1 Указывает версию маркера.

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

Чтобы получить маркер доступа, можно использовать такие средства, как Postman, расширение клиента REST в Visual Studio Code, PowerShell, CLI, curl и библиотеки проверки подлинности Azure AD.

Шифрование

При создании новой службы служб azure Health Data Services ваши данные по умолчанию шифруются с помощью ключей, управляемых Корпорацией Майкрософт .

  • Служба FHIR обеспечивает шифрование неактивных данных, когда данные сохраняются в хранилище данных.
  • Служба DICOM обеспечивает шифрование неактивных данных, когда данные образов, включая внедренные метаданные, сохраняются в хранилище данных. Когда метаданные извлекаются и сохраняются в службе FHIR, они шифруются автоматически.
  • Служба MedTech после сопоставления и нормализации данных сохраняет сообщения устройства в службу FHIR, которая шифруется автоматически. В случаях, когда сообщения устройства отправляются в Центры событий Azure, которые используют службу хранилища Azure для хранения данных, данные автоматически шифруются с помощью шифрования службы хранилища Azure (Azure SSE).

Дальнейшие действия

В этом документе вы узнали о проверке подлинности и авторизации служб Azure Health Data Services. Сведения о развертывании экземпляра служб Azure Health Data Services см. в статье.

Развертывание рабочей области Azure Health Data Services с помощью портал Azure

FHIR® является зарегистрированным товарным знаком HL7 и используется с разрешения HL7.