В эпоху информатизации проблема безопасности данных выходит на первый план, и особенно жесткие требования предъявляются к защите медицинской информации. Относительно недавно разработанные протоколы передачи данных уже содержат в себе средства защиты, соответствующие современным требованиям. Но что можно сказать о динозаврах из тех времен, когда никто всерьез не задумывался о том, что данные пациента могут представлять интерес для злоумышленников? У разработчика не всегда есть возможность использовать новейшие протоколы, однако это не значит, что защитить данные невозможно.
В настоящее время команда Ауриги занимается разработкой SDK для медицинского протокола HL7 v2.x. В процессе предварительных исследований и создания архитектуры SDK, мы обнаружили проблемы безопасности, которые сумели исправить в рамках своего проекта. В данной статье мы рассмотрим риски передачи персональных данных на примере протокола HL7 v2.x и предложим архитектурные решения для исправления ситуации.
Версии протокола HL7
Health Level 7 (HL7) – это один из базовых протоколов взаимодействия медицинских приложений и устройств, который широко применяется на разных уровнях: от общения лабораторного устройства с базой данных и до взаимодействия между разными медицинскими учреждениями.
Протокол HL7 имеет несколько версий.
- HL7 v1.x – устаревшая версия, практически не используется в настоящее время;
- HL7 v2.x – текстовый протокол, простой в реализации и использовании;
- HL7 v3.x – намного более сложный протокол с гибкой и богатой семантикой, поддержкой шифрования и электронной подписи;
- HL7 FHIR (Fast Healthcare Interoperability Resources) – новый, простой, основанный на открытых стандартах протокол.
Учитывая, что HL7 FHIR пока находится в разработке, а HL7 v3.x слишком сложна для понимания, HL7 v2.x до сих пор имеет наиболее широкое распространение. Однако этой версии свойственен ряд серьезных недостатков, главный из которых – проблемы с безопасностью практически на всех уровнях.
Защита данных
Предположим, вы реализовали интерфейс между медицинскими системами. Теперь необходимо провести ряд тестов, направленных на проверку реализации технологических и бизнес-требований. Тестирование невозможно без тестовых данных, которые команда тестировщиков получает обычно из рабочей системы. На данном этапе большое значение приобретает защита данных, ведь ноутбуки разработчиков, жесткие диски или флэш-накопители могут быть потеряны или украдены. Кроме того, возможны хакерские атаки на компьютеры разработчиков, в том числе изнутри компании.
Защитить данные пациентов позволяет де-идентификация/анонимизация тестовых данных. Существуют разные подходы к созданию де-идентифицированных данных, например:
- Удаление прямых идентификаторов (имя, номер социального страхования)
- Использование искусственных идентификаторов, или псевдонимов (псевдонимизация)
- Подавление или обобщение квази-идентификаторов (дата рождения, индекс)
В свою очередь, процесс анонимизации может быть связан с целым рядом проблем, когда невозможно удалить важные данные (например, ID, возраст пациента, дату исследований), крайне сложно удалить идентификационные данные с картинок (скриншотов) или необходимо соблюдать целостность данных. В этих ситуациях целесообразно применить шифрование, т.е. обратимое кодирование данных в нечитаемый формат.
В результате так называемой атаки ре-идентификации может произойти восстановление идентификации данных на основе оставшейся информации и ее связанности.
- Раскрытие личности – происходит, когда злоумышленник может привязать конкретный элемент данных к конкретному физическому лицу из-за недостаточной де-идентификации, за счет ре-идентификации путем связывания или инверсии псевдонима.
- Раскрытие атрибута – происходит, если часть конфиденциальной информации можно вывести без привязки к конкретному элементу в наборе данных.
- Дедуктивное раскрытие – происходит, когда данные могут быть получены с высокой степенью достоверности из статистических свойств опубликованных данных.
- Атаки на криптографию – происходит, когда для де-идентификации используются криптографические алгоритмы без понимания процесса.
Защита каналов передачи данных
Наиболее простое и дешевое решение для организации защиты соединения через открытые сети – это VPN (Virtual Private Network). При этом достаточно данные LLP (Low Level Protocol, протокол передачи HL7-сообщений) переслать по VPN. В настоящее время многие облачные платформы, такие как Amazon, предоставляют VPN-соединения как часть своих сервисов. Возможна организация каналов передачи по протоколам HTTPS, SFTP, FTPS, SMIME. Для работы по этим протоколам существуют даже специальные драфты от HL7. Однако эти стандарты появились много позже массового внедрения HL7, и во многих случаях для изменения практики требуются слишком большие вложения.
Защита для серверов внутри сети медицинского учреждения также необходима. Устанавливать VPN-соединение внутри локальной сети непрактично, а иногда и затратно. Разные сетевые уровни модели OSI предоставляют различные протоколы для организации той или иной стороны защиты соединения и передаваемых данных.
Основные протоколы защиты на уровне приложения – это HTTPS, FTPS (FTP по TLS), SFTP(Safe SSH) и SMIME. Основная проблема защиты данных на уровне приложения заключается в том, что ее сложно реализовать: сложно хранить специфические для приложения пароли, аудит и правила, а также определить специфичные для приложения права доступа. Кроме того, перенасыщение свойств безопасности уровня приложения может оказаться дорого и раздражать пользователей.
Защита каналов передачи возможна также и на транспортном уровне. Здесь появляются такие протоколы как SSH (распространен на Unix системах), SSL, TLS. Транспортный уровень и клиентский агент требуют усилий на обеих сторонах канала. HL7 – это двухсторонний протокол, и вы не всегда контролируете обе стороны.
Защищайте данные правильно
Исходя из нашего опыта работы с медицинским протоколом HL7 и анализа основных ошибок в построении безопасности, мы выработали следующие рекомендации для надежной защиты данных:
- Не используйте SSN (номер социального страхования) и другие персональные данные, такие как ID
- Не шифруйте важную информацию селективно
- Защищайте сеть, а не отдельное приложение
- Разграничьте доступ для всех пользователей
- Введите правильную парольную политику (достаточно сложные пароли и адекватная частота их смены)
- Избегайте избыточной защиты — она работает медленнее (криптографические функции затратны по времени, логирование каждого шага отнимает много ресурсов), раздражает пользователя (частые запросы пароля, задержки) и непродуктивна (стопроцентной защиты не бывает)
Эти рекомендации носят общий характер и вполне могут быть адаптированы для различных проектов, даже не связанных с разработкой ПО для медицинских устройств.
