Безопасность IoT-систем в ВКР: избегаем массовых взломов на примере робота-пылесоса
В марте 2026 года Брюс Шнайер описал показательный инцидент: один владелец робота-пылесоса DJI Romo попытался удалённо управлять своим устройством, а в результате получил доступ к 7 000 чужих роботов по всему миру. Причина — небезопасная конфигурация MQTT-брокера, которая позволяла любому авторизованному (и даже неавторизованному) клиенту подписываться на чужие топики и отправлять команды. Это не единичный случай, а закономерность: IoT-устройства часто проектируются без учёта угроз на уровне архитектуры. Для выпускников IT-направлений этот кейс — отличная отправная точка, чтобы показать в ВКР умение проектировать защищённые системы, тестировать их и обосновывать инженерные решения. Работодатели и государственные экзаменационные комиссии всё чаще ждут от дипломников не просто «написать приложение», а продемонстрировать системный подход к безопасности, наблюдаемости и надёжности.
Темы ВКР, которые можно раскрыть через инцидент с Romo
1. Разработка защищённой архитектуры IoT-платформы для управления роботизированными устройствами
Актуальность: случай с 7000 взломанных пылесосов показывает, что отсутствие разграничения доступа между устройствами и неправильная настройка брокеров приводят к катастрофическим последствиям. Необходимо разработать архитектуру, где каждое устройство аутентифицируется индивидуально, а команды подписываются.
Цель: спроектировать и прототипировать защищённую IoT-платформу с использованием паттернов Hub-and-Spoke, TLS-взаимодействий и политик авторизации.
Задачи:
- Проанализировать типовые уязвимости роботизированных IoT-устройств.
- Сравнить протоколы MQTT и CoAP с учётом требований безопасности.
- Разработать модель угроз и выбрать средства защиты (сертификаты X.509, OAuth 2.0 для constrained environments).
- Реализовать прототип брокера с авторизацией и провести тестирование.
Структура: Глава 1 — анализ предметной области; Глава 2 — проектирование архитектуры; Глава 3 — реализация, тестирование и оценка экономической эффективности.
2. Анализ защищённости MQTT-протокола в системах умного дома и разработка рекомендаций
Актуальность: инцидент с Romo произошёл из-за того, что MQTT-брокер был открытым. Студент-дипломник может провести систематический анализ безопасности стандартного стека IoT и предложить правила безопасной настройки.
Цель: определить типовые векторы атак на MQTT-инфраструктуру и разработать чек-лист для производителей и интеграторов.
Задачи:
- Изучить спецификации MQTT 3.1.1 и MQTT 5.0.
- Создать лабораторный стенд из трёх устройств и провести пентесты.
- Оценить риски по методике STRIDE или OCTAVE.
- Сформулировать требования к конфигурации брокера, аутентификации и шифрованию.
Структура: Глава 1 — теория и протоколы; Глава 2 — экспериментальный стенд и методика тестирования; Глава 3 — результаты, рекомендации, технико-экономическая оценка.
3. Проектирование системы мониторинга и реагирования на инциденты для инфраструктуры IoT
Актуальность: массовое заражение 7000 устройств позволило бы выявить аномалии в реальном времени, если бы трафик MQTT мониторился. Такая система должна собирать метрики с устройств и брокеров, сигнализировать о подозрительных подписках.
Цель: разработать прототип системы мониторинга на базе OpenTelemetry и SIEM-логики с оповещением об аномалиях.
Задачи:
- Определить метрики безопасности MQTT: частота подписок, количество rejected connections, корреляция топиков.
- Разработать архитектуру сбора метрик (агенты, брокер метрик, хранилище).
- Интегрировать OpenTelemetry Collector с Mosquitto и настроить экспорт в Prometheus.
- Провести нагрузочное тестирование и проверить эффективность детектирования.
Структура: Глава 1 — аналитический обзор SIEM и OpenTelemetry; Глава 2 — проектирование системы; Глава 3 — реализация, тестирование, оценка RTO/RPO.
Аналитическая глава: как вписать инцидент в обзор и обоснование стека
В первом разделе диплома обычно сравнивают существующие решения. Инцидент с DJI Romo можно использовать в качестве подтверждения того, что классические подходы «доверять всему внутри периметра» не работают. При сравнении архитектурных решений уделите внимание:
- Микросервисы и оркестрация. Даже для IoT-бэкенда уместно рассмотреть Kubernetes на шлюзе, чтобы автоматически масштабировать обработку телеметрии и применять сетевые политики NetworkPolicy.
- Протоколы. Покажите таблицу сравнения MQTT и CoAP по критериям безопасности, энергопотребления, надёжности.
- Инструменты наблюдаемости. OpenTelemetry как стандарт сбора метрик и трейсов позволяет выявлять аномалии до того, как они приведут к взлому.
| Слой | Традиционное решение | Защищённое решение |
|---|---|---|
| Транспорт | MQTT без TLS | MQTT over TLS, взаимные сертификаты |
| Авторизация | Общий пароль / открытый брокер | Индивидуальные токены, OAuth 2.0 или X.509 |
| Мониторинг | Журналы только при аудите | Continuous monitoring через OpenTelemetry, алерты в SIEM |
| Обновления | Ручная прошивка | CI/CD с подписанными OTA-образами |
Не забывайте ссылаться на стандарты: при описании функциональных и нефункциональных требований используйте ISO/IEC 25010 (качество ПО), а при оформлении технического задания — ГОСТ 34.602-89.
Проектная часть: схемы, алгоритмы и интеграция защиты
Во второй главе нужно показать, как вы проектируете свою систему. Статья о взломе робота-пылесоса даёт готовый сценарий, который следует разобрать как негативный пример.
- UML-диаграммы. Нарисуйте диаграмму вариантов использования для трёх ролей: владелец устройства, сервис провайдера, злоумышленник. Затем постройте диаграмму последовательности аутентификации и авторизации, чтобы показать, как исключить несанкционированный доступ.
- Алгоритмы. Приведите псевдокод или блок-схему проверки прав подписчика на MQTT-топик. Пример в
pre:
def can_subscribe(client_id, topic, subscriptions):
if client_id not in registry:
return False
if not any(pattern.match(topic) for pattern in subscribed_patterns(client_id)):
log_event(topic, status="denied")
return False
return True- Интеграция. Опишите, как ваши компоненты взаимодействуют с брокером MQTT, как обеспечивается резервирование и восстановление после сбоев. Укажите целевые значения RTO и RPO (например, RTO ≤ 15 минут, RPO ≤ 5 минут).
Тестирование и метрики: нагрузка, безопасность, наблюдаемость
В третьей главе нужно показать, что предлагаемое решение действительно работает и экономически оправдано.
Метрики по ISO/IEC 25010
Выберите подхарактеристики, которые вы будете оценивать: производительность, безопасность, надёжность. Составьте таблицу с критериями и методами проверки. Например:
| Показатель | Метод | Целевое значение |
|---|---|---|
| Время отклика MQTT на команду | Нагрузочное тестирование с помощью MQTT Benchmark | < 300 мс при 1000 устройств |
| Процент заблокированных несанкционированных подписок | Пентест, попытка подписки на чужой топик | 100% |
| Доступность сервиса | Непрерывный мониторинг в течение 7 дней | > 99,5% |
Нагрузочное тестирование и метрики атак
Смоделируйте сценарий, аналогичный инциденту: один клиент получает доступ к чужому топику. Затем примените ваше решение и зафиксируйте, что попытка блокируется. В расчётной части можно привести предотвращённый ущерб: если каждый из 7000 роботов стоит 30 000 руб., то общий ущерб при использовании уязвимости достигает 210 млн руб. Ваше решение снижает риск до пренебрежимо малого уровня. Такие расчёты хорошо подкрепляют диплом.
Чему вы научитесь
- Проектировать безопасную архитектуру IoT-систем с учётом требований стандартов.
- Обоснованно выбирать протокол, стек и инфраструктуру, опираясь на данные, а не на вкусовые предпочтения.
- Пользоваться инструментами наблюдаемости (OpenTelemetry, Prometheus) для обнаружения аномалий.
- Грамотно оформлять техническую документацию: ТЗ по ГОСТ 34.602-89, диаграммы UML, описание тестов.
- Выстраивать защиту перед комиссией с помощью конкретных метрик и расчётов.
Типичные ошибки студентов
- Подмена терминов. Пишут «SaaS», когда речь о «PaaS», или называют «моделированием угроз» просто перечисление страхов. Чтобы избежать, строго следуйте определению выбранной методологии (например, STRIDE или OCTAVE).
- Отсутствие метрик. Говорят «стало лучше», но не приводят цифр. Используйте ISO/IEC 25010 и конкретные замеры до/после. Это закрывает вопрос «Где брать метрики».
- Игнорирование ГОСТ при оформлении ТЗ. Техническое задание в приложении должно соответствовать ГОСТ 34.602-89. Часто студенты не включают ТЗ вообще. Лучше набросать хотя бы согласованный раздел «Требования к системе».
FAQ
Сложно ли реализовать такой проект в ВКР?
Всё зависит от объёма. Можно сократить до прототипа: Mosquitto + скрипт на Python, демонстрирующий авторизацию и разграничение доступа. Научная ценность будет в обосновании и тестировании. Даже если код не идеален, грамотный анализ и выводы — главное.
Вуз требует обязательный код, а я не программист?
Для ВКР по ИТ код обычно обязателен, но не обязательно сложное приложение. Достаточно рабочего прототипа: MQTT-клиент с аутентификацией, скрипт для сбора метрик или настройка одного брокера с правильными политиками. Материалы статьи и примеры можно взять за основу, но только с указанием источника.
Как оформить UML-диаграммы, если не пользуешься дорогими инструментами?
Подойдут бесплатные Draw.io, PlantUML, Visual Paradigm Community. Диаграмму нужно проверить на соответствие требованиям вашего вуза (часто используются нотации ГОСТ по ЕСПД, но чаще достаточно UML). В любом случае подпишите название диаграммы и опишите её в тексте.
Где брать тестовые данные для моделирования массового взлома?
Сгенерируйте синтетические данные: 7000 фейковых ID и топиков — это простая программа. Для нагрузочного тестирования возьмите публичные брокеры MQTT (HiveMQ, Eclipse) или поднимите свой. Важно описать генерацию данных в разделе «Методика тестирования».
Чек-лист «Что проверить перед сдачей»
- Есть ли ссылка на статью и корректно ли оформлен источник?
- Все ли задачи ВКР соответствуют полученным выводам?
- Присутствуют ли схемы (хотя бы одна) и подписи к ним?
- Прописано ли соответствие ГОСТ 34.602-89 в техническом задании?
- Использованы ли метрики ISO/IEC 25010 для оценки качества?
- Проверено ли, что в работе нет необоснованных англицизмов?
Вы потратили 30 минут на чтение, а на проектирование архитектуры и тестирование уйдёт не одна неделя. Мы можем снять с вас рутину: помогаем с аналитической частью, чертежами и таблицами. Уже на бесплатной консультации специалист подскажет, как написать ВКР без потери качества. Если нужно — возьмём доработку с планом на 120 часов.
Источник: Hacking a Robot Vacuum (опубликовано 2026-03-19)