Проектирование системы мониторинга и защиты сегмента промышленного интернета вещей на базе открытого программного обеспечения

Введение

Стремительное распространение технологий промышленного интернета вещей (IIoT) в критически важных отраслях, включая фармацевтическую логистику, создаёт новые вызовы в области информационной безопасности. Системы мониторинга «холодильной цепи», обеспечивающие непрерывный контроль условий хранения термолабильных лекарственных средств, становятся привлекательной целью для злоумышленников: компрометация таких систем может привести не только к финансовым потерям, но и к угрозе жизни и здоровью пациентов вследствие порчи препаратов. При этом большинство существующих решений в области защиты IIoT-сегментов либо обладают избыточной стоимостью и сложностью, либо не учитывают отраслевую специфику фармацевтической логистики и требования нормативных документов (ГОСТ Р 58603-2019, ФЗ-61, Приказ Минздрава РФ № 642н, принципы ALCOA+).

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

В 2025 году доля кибератак на фармацевтические компании и организации здравоохранения в России в I квартале выросла с 10% до 40% от общего числа инцидентов, а в августе число DDoS-атак на отечественные фармкомпании увеличилось на 82% по сравнению с аналогичными периодами 2024 года.

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

1. Аналитическое описание проблемы и объекта информатизации

Особенности IIoT-мониторинга и протокола MQTT

Системы IIoT-мониторинга отличаются от классических IT-инфраструктур преобладанием машинно-машинного (M2M) трафика, высокой частотой генерации сообщений и асимметричностью модели «многие-к-одному». В контексте фармацевтического склада система обязана обеспечивать гарантированную доступность телеметрии, исключать фальсификацию исторических записей и поддерживать синхронизацию времени. Архитектура должна поддерживать временные ряды (TSDB), контейнеризацию, минимальное потребление ресурсов и оперативный алертинг.

Протокол MQTT является де-факто стандартом для IIoT благодаря архитектуре «издатель-подписчик» и легковесности. Однако его спецификация не регламентирует защиту на уровне приложения: отсутствует сквозное шифрование payload, криптографическая целостность сообщений и встроенная защита от replay-атак. Безопасность сегмента критически зависит от конфигурации брокера (TLS 1.2+, строгие ACL, rate limiting) и наличия дополнительных контрольных механизмов, таких как HMAC-подпись полезной нагрузки и поведенческий мониторинг [2].

Объект информатизации и нормативные требования

Объектом информатизации является сегмент системы мониторинга «холодильной цепи» на складе фармацевтической продукции. Функциональное назначение – поддержание температурного режима +2…+8 °C и влажности 45–75%. Архитектура включает уровень источников данных (датчики), уровень обмена (MQTT-брокер), уровень обработки (TSDB, детектор аномалий) и уровень представления (визуализация, алертинг).

Нормативная база требует строгого соблюдения целостности данных:

1. ФЗ-61 – прослеживаемость движения препаратов, защита телеметрии от подмены.
2. Приказ Минздрава № 642н (GDP) – валидация компьютеризированных систем, ведение неизменяемого аудиторского следа.
3. ГОСТ Р 58603-2019 – требования к протоколу MQTT, шифрованию и ACL.
4. Принципы ALCOA+ – атрибутируемость, своевременность, оригинальность и точность данных, что реализуется через WORM-политики хранения, NTP-синхронизацию и криптографические подписи [2, 4, 5, 6].

2. Оценка угроз и формирование требований

Объекты воздействия

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

• MQTT-брокер и сетевой трафик MQTT.
• База данных временных рядов и журналы событий.
• Система визуализации и алертинга.
• Платформа контейнеризации и сетевая инфраструктура.
• Физические датчики температуры/влажности и IoT-контроллеры.
• Серверное оборудование и конфигурационные параметры компонентов.

Модель нарушителя

Рассматриваются внешние нарушители (преступные группы, хакеры, конкуренты, вредоносное ПО) и внутренние (операторы, системные администраторы, бывшие сотрудники). Ключевыми целями атак являются: хищение коммерческой тайны, фальсификация данных мониторинга для сокрытия порчи препаратов, нарушение непрерывности «холодильной цепи» и вывод системы из строя (DoS).

Актуальные угрозы

На основе Банка данных угроз ФСТЭК России с учетом специфики IIoT и контейнеризованных сред выявлено 19 актуальных угроз, сгруппированных по 8 классам:

1. Угрозы утечки информации: перехват телеметрии, несанкционированное копирование данных.
2. Угрозы НСД: доступ к оборудованию, виртуальным каналам, контейнерам и привилегированным средам.
3. Угрозы модификации (искажения): подмена телеметрических данных, фальсификация журналов аудита, изменение настроек СЗИ и параметров IoT-контроллеров.
4. Угрозы подмены: эксплуатация слабостей протоколов, подмена образов Docker-контейнеров.
5. Угрозы отказа в обслуживании: DoS-атаки на MQTT-брокер и каналы передачи данных.
6. Угрозы нецелевого использования: майнинг или нецелевая эксплуатация вычислительных ресурсов edge-сервера.
7. Угрозы нарушения функционирования: нарушение изоляции контейнеров, несвоевременное выявление инцидентов.
8. Угрозы внедрения вредоносного кода: заражение IoT-устройств и внедрение вредоносного ПО в контейнерную среду [1, 3].

Функциональные и технические требования

На основе моделирования сформирован перечень из 19 ключевых требований, объединяющих положения отраслевых стандартов и методические рекомендации ФСТЭК:

Сетевая безопасность: Принудительный TLS 1.2+, сегментация на 4 изолированные Docker-сети с фильтрацией nftables, внедрение IDS Suricata с кастомными правилами для MQTT.

Целостность и аутентификация: Строгий ACL на брокере, криптографическая HMAC-SHA256 подпись каждого пакета, валидация временных меток (окно ±5 сек), WORM-политика в InfluxDB.

Мониторинг и реагирование: Непрерывный сбор телеметрии (интервал 30 сек), статистический Python-детектор аномалий, автоматизированная блокировка подозрительных IP через nftables и эскалация оповещений в корпоративный мессенджер.

Доступность: QoS ≥ 1 для критичных потоков, механизм LWT для контроля «отвалов» датчиков.

3. Проектирование системы защиты информации

Обоснование выбора технологического стека

Выбор компонентов осуществлялся методом взвешенной суммы по 5 группам критериев (безопасность – вес 0,35; функциональные – 0,25; технические – 0,20; эксплуатационные – 0,15; экономические – 0,05). В результате сравнительного анализа открытого ПО обоснован следующий стек:

• MQTT-брокер: Eclipse Mosquitto (интегральная оценка 4,47/5). Выбран за минимальное потребление ОЗУ (<256 МБ), полную поддержку ACL, TLS и стабильную работу в Docker [8].
• База данных: InfluxDB (4,63/5). Лидер благодаря нативной поддержке WORM-политик, высокой скорости записи временных рядов и интеграции с Telegraf/Grafana [10].
• Визуализация: Grafana (4,83/5). Обеспечивает гибкие дашборды, RBAC, аудит действий и многоканальный алертинг [9].
• Сетевая IDS: Suricata (4,76/5). Высокопроизводительная многопоточная система с поддержкой глубокого анализа прикладного уровня (MQTT-парсер) и Lua-скриптов [11].
• Контейнеризация: Docker + Compose (4,47/5). Оптимальный баланс простоты оркестрации, сетевой изоляции и поддержки профилей безопасности AppArmor [7].

Архитектура эшелонированной обороны

Система разделена на четыре изолированные виртуальные сети Docker. Маршрут данных и точки применения защиты выстроены по принципу эшелонированной обороны:

Точка 1: Периметровая защита (Mosquitto). Аутентификация устройств, строгий ACL на уровне топиков, rate limiting для предотвращения флуда.

Точка 2: Верификация целостности (Прикладной уровень). Проверка HMAC-SHA256 подписи payload и валидация timestamp для исключения replay-атак и инъекции ложных показаний.

Точка 3: Сетевой мониторинг и поведенческий анализ. Зеркалирование трафика в Suricata для сигнатурного поиска атак. Параллельно работает Python-детектор, выявляющий статистические аномалии (например, "плавный дрейф" температуры).

Точка 4: Защита хранения и визуализации. RBAC в Grafana, WORM-политика в InfluxDB, запрет ретроспективного редактирования журналов.

Оценка эффективности спроектированной системы защиты информации

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

Система критериев охватывает четыре взаимосвязанные группы:

Критерий 1. Полнота покрытия угроз (K₁). Отражает способность проектных решений нейтрализовать перечень актуальных угроз. Показатель рассчитывается как отношение количества угроз, для которых реализованы хотя бы два независимых механизма защиты, к общему числу актуальных угроз:

, (1)

Где:

N_покр – число угроз, закрытых минимум двумя механизмами защиты;

N_всего – общее число актуальных угроз.

Критерий 2. Соответствие нормативным требованиям (K₂). Отражает долю функциональных и технических требований из таблицы 2.11, полностью реализованных в спроектированной архитектуре:

, (2)

Где:

N_вып – число выполненных требований;

N_общ – общее число идентифицированных требований.

Критерий 3. Ресурсная эффективность (K₃). Отражает влияние механизмов защиты на потребление вычислительных ресурсов. Оценивается расчётным методом на основе официальных характеристик компонентов:

, (3)

Где:

N_нагр – средняя ресурсная нагрузка (%).

Критерий 4. Функциональная полнота (K₄). Отражает долю функций коммерческих платформ промышленной кибербезопасности, реализованную в спроектированной системе на базе открытого ПО:

, (4)

Где:

F – функций, покрытых системой;

n – количество функций.

Весовые коэффициенты критериев определены с учётом приоритетов фармацевтической отрасли, где на первом месте стоит непрерывность процесса и нормативное соответствие:

• W₁ (Покрытие угроз) = 0,30;
• W₂ (Нормативное соответствие) = 0,35;
• W₃ (Ресурсная эффективность) = 0,15;
• W₄ (Функциональная полнота) = 0,20.

Оценка по Критерию 1. Полнота покрытия угроз

Анализ покрытия актуальных угроз реализованными механизмами защиты представлен в таблице 3.

Таблица 1

Матрица покрытия актуальных угроз механизмами защиты

Расчёт показателя K₁ по формуле (1):

, (5)

Целевое значение (≥ 85%) достигнуто. Пять угроз, покрытых частично, относятся к категориям, нейтрализация которых требует организационных мер (обучение персонала, регламенты), не входящих в область проектирования технической подсистемы защиты.

Оценка по Критерию 2. Соответствие нормативным требованиям

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

Проведён аудит архитектуры на соответствие 19 ключевым требованиям ГОСТ Р 58603-2019, ФЗ-61, Приказа № 642н и ALCOA+. 19 требованиq реализованы, однако при всех соответствиях требованиям, продукты все равно не находятся в реестре сертифицированных средств защиты информации, поэтому этот критерий не до конца определяет точность соответствия требованиям.

Расчёт показателя K₂ по формуле (2):

, (6)

Целевое значение (≥ 90%) достигнуто с запасом.

Оценка по Критерию 3. Ресурсная эффективность

Расчёт ресурсной эффективности выполнен для нагрузки 50 датчиков (6000 сообщ./мин) на edge-сервере (4 ядра, 16 ГБ ОЗУ).

Таблица 2

Расчётная оценка ресурсной эффективности

Расчёт K₃ по формуле (3):

, (7)

Целевое значение (≥ 80%) достигнуто.

Оценка по Критерию 4. Функциональная полнота

Результаты сравнительного анализа с коммерческими платформами представлены в таблице 3.

Таблица 3

Сравнение функциональности с коммерческими аналогами

+ – 1 балл.

± – 0.5 балла.

– – 0 баллов.

Расчёт показателя K₄ по формуле (4):

, (8)

Целевое значение (≥ 70%) достигнуто. Отсутствие поддержки OT-протоколов и сертификатов ФСТЭК компенсируется спецификой объекта (используется только MQTT) и тем, что объект не является субъектом КИИ.

Расчёт итогового интегрального показателя проводится по формуле из методики оценки эффективности капитальных вложений на основе качественных и количественных критериев, согласно приказу Минэкономразвития России от 24.02.2009 № 58 (ред. от 05.02.2018):

, (9)

Где:

K_int – интегральный показатель;

W_i – весовой коэффициент;

K_i – нормированная оценка критерия;

n – количество критериев.

Расчет итогового интегрального показателя по формуле (5):

, (10)

Таблица 4

Итоговые показатели и сравнение конфигураций