Централизованный аудит и мониторинг безопасности медицинских систем: практическое руководство

Зачем нужен централизованный аудит медицинских систем

Медицинские учреждения ежегодно теряют миллионы рублей из-за инцидентов безопасности. Утечка 10 000 записей пациентов обходится клинике в среднем в 3,8 млн рублей с учётом штрафов, репутационных потерь и затрат на расследование. Разрозненное логирование эту проблему не решает.

Типичная ситуация: в больнице работают МИС, PACS-сервер, лабораторная система и три интеграционных движка. Каждый компонент пишет логи в свой файл. Системный администратор узнаёт о подозрительной активности через неделю после инцидента, когда последствия уже наступили. Ручной анализ логов с шести серверов занимает часы, а сопоставить события из разных источников без единой временной шкалы практически невозможно.

Централизованный сбор и корреляция логов меняют картину. SIEM-система получает события от всех источников, нормализует их и применяет правила обнаружения в реальном времени. Попытка медсестры открыть карту пациента, с которым у неё нет назначенной консультации, фиксируется за секунды. Массовая выгрузка DICOM-изображений на внешний IP-адрес блокируется до того, как данные покинут периметр.

152-ФЗ и GDPR требуют регистрировать события доступа к персональным данным и хранить эти записи не менее 6 месяцев. Централизованный аудит закрывает это требование из коробки: все логи собираются в единое защищённое хранилище с контролем целостности. Подробнее о юридических аспектах и шаблонах политик рассказано в разделе о соответствии законодательству.

Практический план аудита инфраструктуры с готовыми чек-листами разобран в руководстве по аудиту безопасности IT-инфраструктуры. Там же описана методология выбора между внутренним и внешним аудитом.

Особенности протоколов HL7 v2, FHIR и DICOM с точки зрения безопасности

Три протокола закрывают разные задачи обмена медицинскими данными, и каждый создаёт уникальные векторы атак. HL7 v2 работает в legacy-системах и передаёт данные в текстовом виде с разделителями. FHIR использует REST API и JSON. DICOM оперирует бинарными потоками изображений. Разберём, какие события нужно логировать для каждого.

HL7 v2: что логировать в legacy-системах

HL7 v2-сообщения состоят из сегментов, разделённых символами. Ключевые для аудита сегменты: MSH (заголовок с типом сообщения и временной меткой), PID (идентификатор пациента), PV1 (информация о визите), EVN (тип события). Сообщение типа A04 сигнализирует о регистрации пациента, A08 - об изменении данных, A03 - о выписке.

Типовые атаки на HL7 v2 включают инъекции в поля сообщений, подделку идентификаторов пациентов и повторное воспроизведение легитимных сообщений. Логировать нужно полное содержимое MSH, PID-3 (ID пациента), PID-5 (ФИО), PV1-7 (лечащий врач), EVN-2 (время события) и IP-адрес источника.

Настройка логирования на Mirth Connect выполняется через каналы. В свойствах канала включите опцию «Store message history», затем в разделе Scripts добавьте JavaScript-код для отправки событий в syslog:

var logMessage = {
    event: "HL7_MESSAGE",
    msgType: msg['MSH']['MSH.9'].toString(),
    patientId: msg['PID']['PID.3'].toString(),
    sourceIp: sourceMap.get('ipAddress')
};
logger.info(JSON.stringify(logMessage));

Для Rhapsody аналогичная логика настраивается через Communication Points. Подробный разбор мониторинга HL7-потоков с готовыми конфигурациями для Mirth Connect и Rhapsody дан в руководстве по мониторингу HL7-интеграций.

FHIR: аудит REST API и контроль доступа

FHIR-серверы предоставляют REST API для операций с ресурсами: Patient, Observation, MedicationRequest. Каждый запрос содержит HTTP-метод, URL ресурса, токен доступа OAuth 2.0 и ID пользователя. Стандарт FHIR определяет ресурс AuditEvent для логирования событий безопасности.

Обязательные поля AuditEvent: type (rest, query), action (C, R, U, D), agent (пользователь), entity (ресурс), outcome (успех/отказ). Пример записи для чтения карты пациента:

{
  "resourceType": "AuditEvent",
  "type": { "code": "rest" },
  "action": "R",
  "agent": [{ "who": "Practitioner/123" }],
  "entity": [{ "what": "Patient/456" }]
}

Логирование FHIR-взаимодействий настраивается через перехватчики на уровне API-шлюза или самого FHIR-сервера. Для HAPI FHIR включите AuditEventInterceptor в конфигурации сервера. Для облачных FHIR-сервисов используйте встроенные механизмы аудита и направляйте события в SIEM через webhook.

DICOM: мониторинг передачи медицинских изображений

DICOM-сессии устанавливаются через ассоциации между SCU (клиент) и SCP (сервер). Основные команды: C-STORE (передача снимка), C-FIND (поиск), C-MOVE (перемещение), C-GET (получение). Каждая ассоциация содержит Calling AE Title, Called AE Title, IP-адреса и порты.

PACS-серверы логируют DICOM-ассоциации в формате, специфичном для вендора. Orthanc записывает JSON-логи с полями: ID ассоциации, AE Title, IP, команда, Study Instance UID, объём переданных данных. Аномалии для детектирования: более 50 C-STORE за минуту от одного пользователя, доступ в нерабочее время (с 22:00 до 06:00), ассоциации с IP-адресов из нехарактерных геолокаций.

Архитектура централизованного сбора логов

Проверенная архитектура для медицинской инфраструктуры строится на четырёх уровнях: агенты сбора, буферный слой, парсеры и хранилище. Такая схема выдерживает пиковые нагрузки в 50 000 событий в секунду и гарантирует доставку логов даже при кратковременных сбоях сети.

Выбор агентов и форматов логов

Для Linux-серверов с Mirth Connect и PACS-системами используйте Filebeat. Он потребляет 30-50 МБ оперативной памяти и умеет перечитывать файлы после перезапуска. Для Windows-серверов с МИС подойдёт Winlogbeat, собирающий Event Log и файловые логи. NXLog закрывает сценарии, где нужна маршрутизация и преобразование на агенте.

Формат логов - JSON с единой схемой полей. Минимальный набор: timestamp, event_type, source_system, user_id, patient_id (хешированный), action, outcome, raw_message. Пример конфигурации Filebeat для HL7-логов:

filebeat.inputs:
- type: log
  paths:
    - /var/log/mirth/*.log
  json.keys_under_root: true
  fields:
    event_type: hl7_message
    source_system: mirth_connect
  fields_under_root: true

Для передачи логов используйте Kafka как буфер. Это решает проблему потери данных при пиковых нагрузках на Elasticsearch. Топик logs-medical с партициями по количеству источников обеспечивает параллельную обработку и переживает рестарт любого компонента цепочки.

Настройка Logstash для парсинга медицинских логов

Logstash получает сырые события из Kafka, парсит их и обогащает перед записью в Elasticsearch. Для HL7 v2 используйте фильтр dissect вместо grok - он быстрее на порядок и не требует компиляции регулярных выражений:

filter {
  dissect {
    mapping => {
      "message" => "MSH|%{msh_field_sep}|%{msh_app}|%{msh_facility}|%{msh_date}|%{msh_type}^%{msh_subtype}"
    }
  }
  mutate {
    add_field => { "hl7_msg_type" => "%{msh_type}^%{msh_subtype}" }
  }
}

Для DICOM-логов из Orthanc извлекайте ключевые теги: StudyInstanceUID, PatientID, Modality, AccessionNumber. Обогащайте события геоданными через GeoIP-фильтр по IP-адресу источника. Добавляйте справочную информацию: сопоставление AE Title с названием отделения, ID врача с ФИО.

Интеграция с SIEM-системами: Splunk, ELK Stack, QRadar

Три SIEM-системы закрывают разные бюджеты и сценарии. ELK Stack - опенсорсное решение с платными функциями безопасности в Elastic Security. Splunk - коммерческий продукт с мощным языком поиска SPL. QRadar - выбор организаций с требованиями к сертификации ФСТЭК. Разберём интеграцию для каждой.

Splunk: приложение для HL7 и корреляция событий

Splunk App for HL7 устанавливается из Splunkbase и добавляет автоматический парсинг HL7-сообщений. После установки создайте индекс medical_logs и настройте источник данных на Kafka-топик. Приложение распознаёт сегменты MSH, PID, PV1 и делает их доступными для поиска.

Correlation search для обнаружения подозрительной активности - множественные неудачные попытки доступа к картам пациентов за 5 минут:

index=medical_logs event_type=access outcome=failure
| stats count by user_id, patient_id
| where count > 5
| table _time, user_id, patient_id, count

Настройте расписание поиска каждые 5 минут и привяжите алерт с отправкой уведомления офицеру безопасности. Для отслеживания изменений критичных полей используйте поиск по HL7-сообщениям типа A08 и сравнивайте значения полей до и после обновления.

ELK Stack: Elastic Security и правила обнаружения

Elastic Agent заменяет Filebeat в новых развёртываниях и управляется централизованно через Fleet. Установите агента на серверы с медицинскими системами, подключите интеграции для сбора логов и настройте политику отправки в Elasticsearch.

Правила обнаружения в Elastic Security создаются через Kibana. Пример EQL-запроса для выявления неавторизованного доступа к FHIR API:

sequence by user_id, patient_id
  [authentication where event.outcome == "success"]
  [fhir where action == "read" and resource == "Patient"]
  [authorization where role != "physician" and role != "nurse"]
until 60 seconds

Это правило срабатывает, когда пользователь успешно аутентифицируется, читает карту пациента, но его роль не врач и не медсестра. Готовое решение для развёртывания ELK Stack с настройкой ILM-политик и дашбордов описано в руководстве по ELK Stack 2026.

QRadar: интеграция через Universal LEEF и DSM Editor

QRadar принимает логи в формате LEEF (Log Event Extended Format). Для HL7 и DICOM создайте custom DSM через DSM Editor. Определите поля: HL7_MsgType, PatientID, AccessionNumber, DICOM_StudyUID. Настройте Log Source на приём событий по syslog или через Universal LEEF REST API.

Правила корреляции в QRadar строятся через Rule Wizard. Правило для массовой выгрузки DICOM: если количество C-STORE от одного источника превышает порог за временное окно, создаётся offense с magnitude 7. QRadar Advisor with Watson анализирует offense и предлагает шаги по реагированию на основе встроенной базы знаний.

Правила обнаружения подозрительной активности: от теории к практике

Ядро мониторинга безопасности - правила, которые превращают поток логов в actionable-алерты. Разберём три ключевых сценария с готовыми сигнатурами и логикой корреляции.

Обнаружение неавторизованного доступа к записям пациентов

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

Сигнатура для SIEM: пользователь прочитал карту пациента, с которым у него нет активной связи «лечащий врач» или «назначенная консультация». В FHIR эта связь проверяется через ресурсы Encounter и CareTeam. В HL7 v2 - через сегмент PV1 с полем лечащего врача. Пример реализации в Splunk:

index=medical_logs event_type=patient_access
| lookup physician_patients physician_id AS user_id patient_id
| where isnull(relationship)
| stats values(patient_id) as accessed_patients by user_id

Алерт должен включать ID пользователя, список пациентов, к которым получен доступ, временные метки и название отделения. Критичность - высокая, эскалация - офицеру безопасности в течение 15 минут.

Выявление несанкционированных изменений в медицинских данных

Изменение диагноза, результатов анализов или назначений после фиксации - индикатор компрометации или внутреннего злоупотребления. Мониторинг строится на HL7-сообщениях A08 (update) и FHIR PATCH-запросах.

Критичные поля для отслеживания: диагноз (DG1 в HL7), назначения (ORC), результаты лабораторных исследований (OBX). Правило сравнивает значения полей до и после изменения. Если изменено поле из списка критичных и изменение выполнено не лечащим врачом - алерт.

Для DICOM-изображений контролируйте целостность через сравнение хешей. При получении изображения вычисляйте SHA-256 и сохраняйте в отдельный индекс. Периодическая сверка текущих хешей с эталонными выявляет модификацию или подмену файлов в PACS-хранилище.

Аномалии в DICOM-трафике: утечка изображений

Массовая выгрузка снимков - признак подготовки утечки. Правило отслеживает аномалии по трём метрикам: количество C-STORE за временное окно, суммарный объём переданных данных, геолокация IP-адреса назначения.

Базовый порог: более 100 C-STORE за 10 минут от одного пользователя. Уточняющий контекст: объём данных превышает 500 МБ, IP-адрес получателя находится за пределами РФ, время операции - нерабочее. При совпадении трёх условий создаётся инцидент с немедленной блокировкой учётной записи через SOAR.

Готовые конфигурации для алертинга на основе логов с примерами EQL-запросов и настройкой Watcher в Elasticsearch разобраны в руководстве по мониторингу и алертингу.

Автоматическая корреляция событий и реагирование

Обнаружение без автоматического реагирования оставляет окно между алертом и действиями администратора. За это время злоумышленник успевает завершить атаку. Автоматизация замыкает цикл: SIEM обнаруживает угрозу, SOAR выполняет плейбук, система блокирует доступ.

Настройка алертов и уведомлений

Разделите алерты на три уровня. Критические (P1): массовая утечка данных, обнаружение вредоносного ПО, компрометация учётной записи администратора. Высокие (P2): неавторизованный доступ к картам VIP-пациентов, изменение критичных полей. Средние (P3): аномалии трафика, превышение порогов, подозрительная активность в нерабочее время.

Каналы доставки: P1 - телефонный звонок и push-уведомление дежурной смене SOC, P2 - Telegram/Slack офицеру безопасности, P3 - email с ежедневной сводкой. Шаблон уведомления должен содержать: тип инцидента, затронутые системы, ID пользователя, временную метку, рекомендованные действия.

Сценарии автоматизации реализуются через интеграцию SIEM с SOAR-платформой или скриптами. Пример плейбука для блокировки учётной записи: SIEM отправляет webhook в скрипт на Python, скрипт вызывает API контроллера домена для отключения учётной записи и создаёт тикет в Jira с полным контекстом инцидента. Время от алерта до блокировки - менее 30 секунд.

Штрафы за нарушение требований к защите персональных данных достигают 6 млн рублей по 152-ФЗ и 4% годового оборота по GDPR. Централизованный аудит закрывает требования к регистрации событий и хранению логов. Разберём, что именно нужно логировать и как оформить документацию.

Чек-лист требований к аудиту по 152-ФЗ

Приказ ФСТЭК №21 требует регистрировать: вход и выход из системы, доступ к персональным данным, изменение прав доступа, запуск и остановку программных средств, попытки несанкционированного доступа. Срок хранения логов для ИСПДн - не менее 6 месяцев.

Журналы аудита должны быть защищены от модификации и удаления. Технически это решается записью в WORM-хранилище или использованием блокчейн-подобных структур с хешированием каждой записи. Доступ к логам предоставляется только офицеру безопасности и администратору СЗИ через ролевую модель.

GDPR требует демонстрировать подотчётность (accountability). Логируйте: факт получения согласия на обработку, каждый случай доступа к данным, передачу данных третьим лицам, выполнение запросов на удаление (right to erasure). Срок хранения логов определяется Data Protection Impact Assessment (DPIA).

При запросе на забвение система должна не только удалить данные пациента, но и сохранить лог-запись о факте удаления с указанием основания, времени и исполнителя. Эта запись остаётся в аудите даже после полного удаления персональных данных из основных систем.

Готовые шаблоны политик и конфигураций

Для ускорения внедрения используйте следующие шаблоны:

Политика аудита информационной безопасности - документ, определяющий перечень регистрируемых событий, сроки хранения, ответственных лиц и порядок реагирования на инциденты.
Регламент мониторинга инцидентов - процедура эскалации, матрица критичности, шаблоны отчётов для руководства.
Конфигурации Filebeat и Logstash - готовые файлы для сбора и парсинга HL7, FHIR и DICOM-логов.
Правила SIEM - экспортируемые пакеты правил для Splunk, Elastic и QRadar с описанными выше сигнатурами.

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

Типовые проблемы и их решение

При внедрении централизованного аудита медицинских систем команды сталкиваются с повторяющимися проблемами. Вот основные и проверенные способы их решения.

Высокая нагрузка на SIEM. Поток в 20 000 событий в секунду от DICOM-серверов может положить Elasticsearch. Решение: фильтрация на стороне агента. Filebeat отбрасывает события уровня DEBUG, оставляя только INFO, WARN, ERROR и security-события. Kafka с партиционированием по source_system распределяет нагрузку равномерно. Logstash с persistent queues защищает от потери данных при всплесках.

Потеря логов при сбоях сети. Filebeat хранит указатель последнего прочитанного смещения в registry-файле. При обрыве связи он продолжает читать файл и буферизирует события до восстановления соединения. Kafka добавляет репликацию топиков с factor=3 - потеря данных возможна только при одновременном выходе из строя трёх брокеров.

Ложные срабатывания. Правило «доступ в нерабочее время» генерирует лавину алертов из-за ночных дежурств. Решение: добавьте контекст расписания. Интегрируйте график смен из HR-системы и исключите из правила пользователей, у которых подтверждённая смена в текущий временной слот. Снижение ложных срабатываний на 70% после внедрения контекста - типовой результат.

Сложность парсинга HL7. Стандарт HL7 v2 имеет десятки версий и диалектов. Вместо написания grok-шаблонов под каждый вариант используйте готовые библиотеки: HAPI для Java, hl7apy для Python. Logstash-плагин logstash-filter-hl7 парсит сообщения автоматически, определяя версию и структуру из заголовка MSH.

Развёртывание централизованного аудита занимает 2-4 недели при наличии готовых конфигураций. Начните с пилотного проекта на одном источнике, отладьте парсинг и правила, затем масштабируйте на всю инфраструктуру. Результат: время обнаружения инцидентов сокращается с дней до минут, compliance-аудит проходится с первого раза, а утечки данных выявляются до того, как становятся новостью.