Как я могу зашифровать содержимое FHIR / REST

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

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

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

Я предполагаю, что одним из возможных способов может быть добавление специального типа контента, который запрашивает зашифрованный контент (на основе S / MIME?) В заголовок HTTP-запроса. После этого FHIR / REST-сервер должен понять из заголовка Accept HTTP-запроса, что контент должен быть зашифрован перед ответом. Думаю, это должно сработать, если сам URL-адрес нечувствителен?

Я также предполагаю, что, возможно, даже открытый ключ для шифрования контента может быть передан в специальном заголовке HTTP-запроса, и сервер может использовать его для шифрования? Или ключи могут быть переданы при настройке системы?

Это осуществимый и приемлемый подход? Обсуждалось ли шифрование полезной нагрузки в работе HL7-FHIR?


person Larsie    schedule 23.10.2015    source источник


Ответы (1)


Это особо не обсуждалось. Один из механизмов - использование двоичного ресурса. Просто заархивируйте и зашифруйте пакет / ресурс, который вы хотите передать, а затем закодируйте его в формате base-64 как двоичный ресурс. (Я предлагаю заархивировать, потому что это упрощает установку типа mime для двоичного файла.) Этот ресурс тогда будет в фокусе MessageHeader, который предоставит необходимые метаданные для обеспечения надлежащей доставки содержимого через несколько переходов.

Это может быть хорошим обсуждением для начала на сервере списка безопасности HL7, поскольку у них, вероятно, появятся некоторые дополнительные мысли и рекомендации. (И также может гарантировать, что где бы что-то ни приземлялось с точки зрения окончательной рекомендации, это документировалось как часть спецификации:>)

person Lloyd McKenzie    schedule 23.10.2015
comment
Требуется ли для этого кодировка содержимого base64? Есть ли другой механизм, такой как размещение зашифрованного содержимого в многостраничном mime-сообщении? - person Jeremy; 15.04.2019
comment
Вообще-то, нет. Двоичные файлы должны быть закодированы в base64 только в том случае, если вы передаете их в Bundle с другим контентом. Если вы отправляете или получаете их напрямую, вы можете передавать необработанный двоичный файл. - person Lloyd McKenzie; 16.04.2019
comment
Привет. Некоторые коллеги рассматривали здесь аналогичный вариант, и мне интересно, рекомендуется ли это. Я видел chat.fhir.org/#narrow/stream/ 179166-Implementers / topic /, что тоже может быть решением. Мы можем спросить в сообществе FHIR Security об этом по сравнению с TLS с взаимной аутентификацией, но я смотрел на время этого ответа и хотел узнать, является ли это рекомендуемым способом решения проблемы шифрования контента. - person costateixeira; 02.07.2020
comment
Вы не найдете широкой поддержки шифрования, кроме TLS, поэтому, если вы можете заставить это работать, это, безусловно, предпочтительный вариант. Для шифрования «части» информации потребуется настраиваемое поведение системы. Кроме того, он не очень хорошо сочетается с парадигмой RESTful прямых публикаций и прямых запросов, к которым системы обычно должны пытаться перейти (потому что эти подходы требуют меньше переговоров и, как правило, лучше масштабируются). - person Lloyd McKenzie; 02.07.2020