Опубликовано: 23.09.2026 | Источник: CNews (новости)

MDM и родительский контроль в ВКР: безопасная цифровая среда для школьников

В марте 2026 года глава Минпросвещения публично поддержал идею полностью запретить использование сотовых телефонов и смартфонов для россиян до определённого возраста. Верхний лимит пока не назван, механизм не оформлен. Но сам сигнал важен: общество движется не к запрету, а к управляемому использованию мобильных устройств детьми. Именно здесь появляется техническая ниша — MDM-платформы, системы родительского контроля, DNS-фильтрация, возрастная верификация. Для выпускника ИТ-специальности это готовый сюжет для ВКР, который закрывает сразу три требования комиссии: актуальность, практическую значимость и измеримый результат. Ниже — как превратить новостной повод в защищаемую работу и не утонуть в нормоконтроле.

Частые вопросы студентов по теме

Темы ВКР, привязанные к новостному кейсу

• Тема 1. MDM-платформа родительского контроля для Android

  Актуальность. Обсуждение возрастного запрета телефонов (март 2026) создаёт регуляторный заказ на управляемые политики вместо жёстких блокировок.

  Цель. Разработать сервис удалённой конфигурации детских устройств через Android Management API.

  Задачи:

  1. Анализ API и каналов управления (Android Management API, Play EMM API).
  2. Проектирование модели ролей (родитель / ребёнок / школа).
  3. Реализация бэкенда и клиента, интеграция политик через JSON-политики.
  4. Тестирование на эмуляторах и реальных устройствах, оценка покрытия.

  Структура. Глава 1 — анализ MDM-рынка и требований; Глава 2 — проектирование (C4-диаграммы, модель угроз STRIDE) и реализация; Глава 3 — тестирование, метрики Precision/Recall, экономическая эффективность.

• Тема 2. Фильтрация трафика школьной сети на уровне DNS

  Актуальность. Полный запрет устройств нереализуем, но контролируемый доступ через школьный Wi-Fi — реалистичная альтернатива.

  Цель. Построить DNS-фильтр с категоризацией доменов и защитой от обхода (DoH/DoT, VPN).

  Задачи: обзор протоколов, классификатор доменов (правила + ML), прототип на Pi-hole/AdGuard Home + кастомный классификатор, нагрузочное тестирование (RPS, latency).

  Структура. Глава 1 — протоколы и обходы; Глава 2 — архитектура (BPMN обработки запроса, UML-компоненты); Глава 3 — метрики, A/B-сравнение с готовыми решениями.

• Тема 3. On-device классификатор нежелательного контента

  Актуальность. Приватность требует считать на устройстве, а не отправлять данные в облако. Это прямо отражает требования 152-ФЗ.

  Цель. Реализовать мобильный классификатор (TFLite/PyTorch Mobile) для скриншотов и текста с метрикой F1 ≥ 0.9.

  Задачи: сбор и разметка датасета, обучение, квантизация модели, интеграция в Android с AccessibilityService, замер задержки.

  Структура. Глава 1 — обзор подходов и этических ограничений; Глава 2 — ML-пайплайн и архитектура приложения; Глава 3 — метрики модели, TCO, сравнение с облачным вариантом.

Как встроить материал статьи в главы ВКР

Новость от 25 марта 2026 — не повод механически вставить ссылку. Дайте ей роль обоснования. В Главе 1 (аналитической) опишите регуляторный ландшафт: обсуждение Минпросвещения, отсутствие верхнего возрастного лимита, зарубежные аналоги (СОППА, GDPR-K, Android Family Link). Постройте диаграмму Исикавы «Почему запрет не решает задачу», а затем — C4-контекст предполагаемой системы.

В Главе 2 (проектной) основное внимание — архитектуре. Обязательные схемы: C4 (Context → Container → Component), UML-диаграмма последовательности «родитель меняет политику → сервер → устройство», модель угроз STRIDE. Если работа по ГОСТ 34.601-90, распишите стадии по документу, иначе проверьте актуальность — в 2024 году введён ГОСТ 34.601-2023, уточните в методичке кафедры, какой вас просят использовать.

Пример политики MDM (Android Management API)

{
  "name": "enterprises/LC00xxx/policies/parental-control-v1",
  "playStoreMode": "WHITELIST",
  "applications": [
    {"packageName": "ru.school.diary", "installType": "FORCE_INSTALLED"},
    {"packageName": "com.example.chat", "installType": "BLOCKED"}
  ],
  "networkConfiguration": {
    "privateDns": {
      "privateDnsMode": "STRICT",
      "privateDnsServers": ["dns-family.example.ru"]
    }
  },
  "passwordRequirements": {"passwordMinimumLength": 8},
  "keyguardDisabledFeatures": ["DISABLE_CAMERA"]
}

Приведите этот фрагмент в приложении к Главе 2 и объясните каждое поле. Комиссия любит такие детали — они доказывают, что вы работали с реальным API, а не переписывали документацию.

Метрики, которые сделают защиту убедительной

Любая тема по ИБ «тонет», если результат нельзя измерить. Введите бинарную матрицу ошибок и посчитайте:

• Precision = TP / (TP + FP) — доля корректно заблокированного нежелательного контента.
• Recall = TP / (TP + FN) — что система пропустила.
• F1 = 2 × Precision × Recall / (Precision + Recall) — сводная оценка.
• False Positive Rate на whitelist-доменах — критично для доверия родителей.
• P95 задержки фильтрации (мс) — отклик не должен мешать прокрутке страниц.
• Энергопотребление клиента (mAh/час) — вы наверняка захотите обосновать, почему on-device лучше облака.

Соотнесите эти метрики с характеристиками ISO/IEC 25010: производительность, надёжность, безопасность, удобство. Таблица соответствия «метрика → характеристика стандарта» закрывает половину вопросов на защите.

Чему вы научитесь

1. Проектировать отказоустойчивую архитектуру управления парком мобильных устройств.
2. Настраивать политики MDM через реальные API, а не «на словах».
3. Оценивать качество фильтрации через Precision/Recall и FPR.
4. Оформлять ТЗ и диаграммы по ГОСТ 34 и UML/C4 без разночтений.
5. Обосновывать выбор on-device vs cloud с точки зрения 152-ФЗ и TCO.

Источник: Некоторым россиянам хотят полностью запретить пользоваться сотовыми телефонами и смартфонами. Кого коснется (опубликовано 2026-03-25)