Родительский контроль смартфонов в дипломе: архитектура системы фильтрации контента для детей
25 марта 2026 года глава Минпросвещения Кравцов анонсировал обсуждение возрастного ограничения на смартфоны. Пока чиновники спорят о возрасте, инженеры уже видят под этой новостью конкретную техническую задачу: как технически обеспечить тот самый «безопасный режим», который хотят узаконить. Речь не о запретах, а о системах родительского контроля, MDM-профилях, фильтрации трафика и сборе телеметрии использования устройства. Для выпускника направления «Информационная безопасность», «Программная инженерия» или «Прикладная информатика» это готовая тема ВКР с внятной постановкой, измеримым результатом и понятной защитой перед комиссией. Ниже — разбор, как превратить новостной повод в защищаемый дипломный проект.
Частые вопросы до начала работы
Моя тема должна быть про «запрет телефонов» или про техническую систему?
Про систему. Комиссия оценивает инженерное решение, а не пересказ инициативы министра. Формулируйте цель как «разработать модуль фильтрации контента для мобильных устройств несовершеннолетних пользователей», а новость используйте как обоснование актуальности во введении и первой главе.
Где брать данные, если нельзя собирать реальный трафик школьников?
Никто и не разрешит — это персональные данные. Используйте открытые датасеты: категоризированные списки доменов (например, публичные фиды блок-листов), синтетические логи, собственный тестовый стенд из двух-трёх устройств с согласия владельца. В главе 1 честно опишите методику обезличивания и сошлйтесь на 152-ФЗ.
Какой стек выбрать, чтобы успеть за семестр?
Минимально работающий контур: DNS-фильтр (Blocky, AdGuard Home, Pi-hole) + агент на устройстве (Android DevicePolicyManager или iOS Screen Time API) + серверная часть на FastAPI/Spring Boot + БД PostgreSQL. Такой набор даёт и архитектуру, и код, и метрики, и не требует писать собственную ОС.
Как считать эффективность фильтрации, если «правильного ответа» нет?
Собирайте размеченный вручную набор из 300–500 запросов с метками «разрешено/запрещено» и считайте precision, recall, F1 и долю ложных блокировок (FPR). Плюс задержка решения p95 — она критична, потому что ребёнок откроет сайт раньше, чем сработает фильтр.
Темы ВКР, которые вырастают из этой новости
-
Тема 1. Система централизованного родительского контроля на базе MDM/EMM.
Актуальность: обсуждение возрастных ограничений подталкивает школы и родителей к управляемым устройствам — а это классическая задача управления парком мобильных устройств.
Цель: разработать прототип MDM-контура для настройки и сопровождения детских устройств.
Задачи: анализ EMM-протоколов; проектирование профилей политик; реализация API выдачи политик; тестирование на стенде из N устройств.
Структура: Гл. 1 — обзор MDM/EMM и требований; Гл. 2 — архитектура C4 и реализация сервиса политик; Гл. 3 — нагрузочное тестирование, метрики применения политик, время доставки. -
Тема 2. Модуль фильтрации интернет-трафика с классификацией контента.
Актуальность: запрет смартфонов не решит проблему доступа к нежелательному контенту — нужен работающий фильтр.
Цель: разработать и оценить модуль фильтрации DNS/HTTP-запросов для детских профилей.
Задачи: обзор методов категоризации (block-list, ML-классификатор); проектирование пайплайна; реализация; оценка precision/recall на размеченном наборе.
Структура: Гл. 1 — анализ подходов и OWASP-рисков мобильных приложений; Гл. 2 — проектирование и код; Гл. 3 — эксперименты, FPR/FNR, задержка p95. -
Тема 3. Аналитическая платформа цифровой гигиены школьника.
Актуальность: родителю нужен не запрет, а понятная картина: сколько времени, какие категории, где всплески.
Цель: построить сборщик обезличенной телеметрии использования устройства и дашборд для родителя.
Задачи: выбор схемы инструментирования (OpenTelemetry-совместимые метрики); хранение временных рядов; агрегация и визуализация; проверка точности агрегатов.
Структура: Гл. 1 — обзор подходов к сбору телеметрии и требования ISO/IEC 25010; Гл. 2 — архитектура и реализация; Гл. 3 — валидация метрик и оценка нагрузки на устройство. -
Тема 4. Механизм подтверждения возраста и родительского согласия в приложении.
Актуальность: возрастное ограничение требует технической проверки возраста и согласия законного представителя.
Цель: спроектировать модель диалога «устройство — приложение — родитель» с фиксацией согласия.
Задачи: анализ правовых требований; проектирование схемы BPMN; реализация API согласий; аудит и неизменяемый журнал.
Структура: Гл. 1 — правовое поле и стандарты; Гл. 2 — проектирование и реализация; Гл. 3 — тесты безопасности и проверка целостности журнала.
Как встроить кейс в главы работы
Глава 1. Обоснование: право, стандарты, риски
Новость от 25 марта 2026 года — идеальный «крючок» для первого абзаца введения и подраздела 1.1. Но дальше нужна инженерная рамка. Разложите требования по трём уровням: правовой (152-ФЗ, требования к согласию законного представителя), нормативный (ГОСТ 34.601 для стадий разработки, ISO/IEC 25010 для атрибутов качества — функциональная полнота, защищённость, производительность) и прикладной (OWASP MASVS как чек-лист для мобильного клиента). Хороший ход — построить матрицу трассировки: «требование из новости → требование к системе → метрика проверки». Комиссия такие таблицы любит: видно, что вы не пересказываете пресс-релиз.
Глава 2. Проектирование и реализация
Начните с контекстной диаграммы C4 (уровень 1): актор «Ребёнок», актор «Родитель», система «Платформа контроля», внешние системы — DNS-резолвер, сервис push-уведомлений, хранилище политик. Затем уровень 2 — контейнеры: мобильный агент, API-шлюз, сервис политик, сервис телеметрии, БД, очередь. Диаграмму последовательности UML стройте на сценарий «ребёнок открывает сайт, которого нет в белом списке»: это ядро защиты, по нему видно и задержку, и точки отказа.
Ниже — минимальный фрагмент серверной политики: именно такие артефакты принято выносить в приложения к диплому.
# policy.yaml — политика детского профиля (фрагмент для главы 2)
profile: "child-default"
version: 3
dns:
resolver: "10.20.0.53"
block_mode: "nxdomain" # nxdomain | nullroute | redirect
allow_categories: ["education", "science", "reference"]
deny_categories: ["adult", "gambling", "violence", "social_unknown"]
allowlist_extra:
- "school-42.edu.ru"
blocklist_extra:
- "*.shortlink-redirect.example"
time_policy:
school_hours: { from: "08:00", to: "15:00", max_minutes_per_app: 10 }
night_curfew: { from: "22:00", to: "07:00", allow_emergency_calls: true }
telemetry:
exporter: "otlp-http"
endpoint: "https://collector.local:4318/v1/metrics"
attributes: ["device_id_hash", "policy_version"] # без PII
Обратите внимание на два архитектурных решения, которые стоит защищать словами: (1) фильтрация вынесена частично на устройство, частично на сеть — это снижает зависимость от постоянного онлайна; (2) политика версионируется, чтобы можно было откатиться при ложной блокировке и объяснить поведение системы в конкретный момент.
Глава 3. Метрики, тесты, доказательство эффективности
Самый частый провал на защите — «система работает». Работает — это не метрика. Считайте как минимум четыре группы показателей и сведите их в таблицу.
| Группа | Метрика | Как измерять | Ориентир |
|---|---|---|---|
| Качество фильтрации | Precision / Recall / F1 | Размеченный набор 300–500 запросов, ручная валидация | F1 ≥ 0,9 при FPR ≤ 3% |
| Производительность | Задержка решения p95 | Нагрузочный прогон, замер на резолвере | ≤ 30 мс дополнительно к DNS |
| Влияние на устройство | Расход батареи, CPU-время агента | Замер за 8 часов в двух режимах: с агентом и без | Прирост расхода ≤ 5% |
| Надёжность | Время применения политики, доля успешных доставок | MQTT/push-канал, логи доставки | p95 ≤ 60 с, успех ≥ 99% |
Отдельно покажите устойчивость к обходу: смена DNS-сервера вручную, использование DoH, VPN. Это ровно тот раздел, который превращает курсовую в диплом. Опишите контрмеры — принудительный DoH-резолвер внутри профиля, блокировка выхода на внешние DNS, проверка состояния агента по heartbeat.
Чему вы научитесь на такой теме
- Проектировать распределённую систему контроля с разделением ответственности между устройством и сервером.
- Оформлять архитектуру в нотации C4 и UML так, чтобы её читала комиссия, а не только вы.
- Строить измеримые эксперименты: размечать данные, считать F1 и FPR, а не «на глаз».
- Работать с требованиями приватности: обезличивание, минимизация атрибутов телеметрии, журналирование согласий.
- Готовить ТЗ и приложения по ГОСТ 34 — с перечнем функций и требований к надёжности.
- Каждая задача из введения имеет отражение в главе 2 или 3 и в выводах.
- Все рисунки пронумерованы, подписаны и упомянуты в тексте до их появления.
- Метрики в третьей главе совпадают с теми, что заявлены в постановке задачи.
- Ссылки на источники оформлены единообразно, дата обращения указана.
- Приложения содержат код и конфигурации, на которые есть ссылки в тексте.
- Текст проверен на заимствования, заимствованный код — оформлен как цитата.
- Презентация укладывается в регламент: 10 слайдов, архитектура, метрики, вывод.
- Уходят в публицистику. Половина первой главы превращается в рассуждения о вреде гаджетов. Лечится матрицей «требование → метрика»: каждое утверждение должно заканчиваться проверяемым требованием к системе.
- Не учитывают обход защиты. Система, которая падает при смене DNS на телефоне, выглядит беспомощно на защите. Добавьте раздел с моделью нарушителя — «ребёнок-ученик, технически грамотный, готов менять настройки».
- Игнорируют приватность. Сбор IMEI, геолокации и переписки без обоснования — прямой путь к вопросам от комиссии. Хэшируйте идентификаторы и собирайте только агрегаты.
- Забывают про ложные блокировки. Заблокированный образовательный ресурс — самый болезненный сценарий. Покажите механизм апелляции или временного разрешения со стороны родителя.
Источник: Дали ребёнку телефон, чтобы не мешал? Министр просвещения считает, что это проблема — и хочет это запретить (опубликовано 2026-03-25)