Поделиться через


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

Проверка подлинности

Azure Health Data Services — это коллекция защищенных управляемых служб, использующих идентификационную систему Microsoft Entra, глобального поставщика удостоверений, поддерживающего OAuth 2.0.

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

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

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

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

Служба FHIR® в Службах данных здравоохранения Azure предоставляет следующие роли:

  • Чтение данных FHIR: чтение и поиск данных FHIR.
  • Писатель данных FHIR: чтение, запись и мягкое удаление данных FHIR.
  • FHIR Data Exporter: чтение и экспорт данных (оператор $export).
  • Импортер данных FHIR: чтение и импорт данных (оператор $import).
  • Участник данных FHIR: выполнять все операции с данными.
  • FHIR Data Converter: используйте преобразователь для преобразования данных.
  • FHIR SMART User: позволяет пользователю считывать и записывать данные FHIR в соответствии со спецификациями SMART IG V1.0.0.

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

  • Владелец данных DICOM: чтение, запись и удаление данных DICOM.
  • Чтение данных DICOM: чтение данных DICOM.

Авторизация

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

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

Действия по авторизации

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

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

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

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

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

  4. Услуги данных здравоохранения Azure проверяют, содержит ли токен соответствующие утверждения (свойства в токене). Если это допустимо, он завершает запрос и возвращает данные клиенту.

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

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

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

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

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

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

Снимок экрана: подпись веб-токена

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

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

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

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

Шифрование

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

  • Служба FHIR обеспечивает шифрование данных в состоянии покоя при их хранении в хранилище.
  • Служба DICOM обеспечивает шифрование неактивных данных при сохранении данных изображений, включая внедренные метаданные, в хранилище данных. При извлечении и сохранении метаданных в службе FHIR он шифруется автоматически.

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

Развернуть рабочую область Служб данных о состоянии здоровья Azure с помощью портала Azure

Предоставление доступа к службе FHIR с помощью Azure Active Directory B2C

Примечание.

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

DICOM® является зарегистрированным товарным знаком Национальной ассоциации производителей электрических технологий для публикаций по стандартам, касающихся цифровых коммуникаций медицинской информации.