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

28 марта 2026 года Индонезия первой в Юго-Восточной Азии отрезала детей младше 16 лет от крупных цифровых платформ. С точки зрения юриста это запрет, с точки зрения инженера — внезапно появившееся нефункциональное требование к аутентификации десятков миллионов пользователей. Платформам придётся не просто «поставить галочку», а встроить проверку возраста в контур входа, сохранив приватность и не уронив время отклика.

Для выпускника ИТ-направления это подарок: появляется внешний заказчик в лице регулятора, измеримые требования и честное поле для сравнения технологий. Тема, привязанная к таким ограничениям, защищается не «потому что интересно», а потому что за ней стоит реальное давление рынка и права. Ниже — три готовых направления, разбор по главам и метрики, которые не стыдно показать комиссии.

Три темы ВКР, которые вырастают из этой новости

Тема 1. Микросервис возрастной верификации на OpenID Connect

Актуальность. Индонезийский сценарий требует подтверждения возраста на входе, а не постфактум. Значит, проверка становится частью identity-контура и должна работать на пиковых нагрузках.

Цель. Спроектировать и реализовать сервис проверки возраста с опорой на внешний провайдер идентификации и настраиваемой политикой доступа.

• сравнить модели подтверждения возраста (самодекларация, документ, банковский идентификатор, доказательство с нулевым разглашением);
• построить модель угроз и определить требования по ISO/IEC 25010;
• реализовать прототип на OIDC + policy engine;
• провести нагрузочное тестирование и зафиксировать SLO.

Структура. Глава 1 — регуляторные режимы и обзор подходов к age assurance (в том числе IEEE 2089-2021). Глава 2 — архитектура: C4-диаграммы, последовательность OIDC-потока, схема данных. Глава 3 — стенд, сценарии k6, расчёт стоимости владения.

Тема 2. Платформа родительского согласия и фильтрации контента

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

Цель. Разработать сервис управления возрастными профилями и политиками доступа к контенту.

• формализовать онтологию возрастных профилей и категорий контента;
• спроектировать REST/GraphQL API и события для внешних платформ;
• реализовать policy engine (OPA или аналог) с версионированием правил;
• оценить деградацию при отказах смежных сервисов.

Структура. Глава 1 — правовые модели согласия и обзор решений. Глава 2 — проектирование: ER-диаграмма, схемы алгоритмов по ГОСТ 19.701-90. Глава 3 — тестирование правил, A/B-проверка точности фильтрации, экономика внедрения.

Тема 3. Система сбора метрик эффективности регуляторных ограничений

Актуальность. Регулятору нужны доказательства, что мера работает. Значит, востребованы системы обезличенной телеметрии и оценки влияния — с корректной обработкой персональных данных.

Цель. Построить конвейер сбора и визуализации агрегированных метрик по возрастным когортам.

• спроектировать схему данных с псевдонимизацией;
• собрать ETL-конвейер и хранилище;
• рассчитать метрики (охват, удержание, доля обходов ограничения);
• оценить качество данных по ISO/IEC 25012 и неопределённость выводов.

Структура. Глава 1 — методы оценки регуляторного воздействия. Глава 2 — архитектура конвейера и модель данных. Глава 3 — проверка на синтетическом датасете, оценка погрешностей, ограничения метода.

Аналитическая глава: как превратить новость в обоснование выбора

Первая глава чаще всего проваливается из-за пересказа статей вместо сравнения. Работает другое: берёте конкретный кейс (Индонезия, март 2026) и выводите из него требования, а затем проверяете, какие технологии эти требования закрывают.

Сравнение подходов к подтверждению возраста

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

Обоснование стека

Формулировка «выбрали PostgreSQL, потому что надёжная» не работает. Работает цепочка: требование → критерий → альтернативы → вывод. Например: нужна транзакционность аудита → критерий ACID и поддержка партиционирования → альтернативы PostgreSQL, MySQL, MongoDB → вывод с указанием, чем именно пренебрегли. Ограничения собственного выбора — самый сильный аргумент в дипломе, он показывает инженерную зрелость.

Проектная часть: схемы, алгоритмы, интеграция

Вторая глава держится на трёх артефактах: контекстная C4-диаграмма, последовательность проверки возраста и модель данных. Блок-схему алгоритма принятия решения оформляйте по ГОСТ 19.701-90 — комиссия это замечает и ценит, а времени на перерисовку уходит немного.

Поток проверки через OIDC

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

{
  "sub": "anon_8f21c4...",
  "age_over_16": true,
  "assurance_level": "high",
  "verified_by": "state_idp",
  "exp": 1775000000
}

Обратите внимание: в токене нет даты рождения и ФИО. Это осознанное решение в пользу минимизации данных, и его нужно защитить в тексте — в том числе сослаться на статьи о приватности и на практике обосновать, почему полные данные не запрашиваются.

Аудит и целостность журналов

Регуляторный сценарий требует ответа на вопрос «кто и когда получил доступ». Значит, в проекте появляется неизменяемый журнал: событие, метка времени, хеш предыдущей записи. Простая схема на PostgreSQL с ограничением на UPDATE/DELETE уже даёт защищаемый результат и легко описывается в третьей главе.

Тестирование и метрики: где взять цифры

Самый частый провал на защите — фраза «система работает быстро». Нужны числа, инструменты и условия замера. Ниже опорный набор, который покрывает и безопасность, и производительность.

Тестовые данные не обязательно искать в проде. Генератор синтетических профилей с заданным распределением возрастов даёт воспроизводимость, а это как раз то, чего не хватает большинству работ. Обязательно опишите методику: сколько запросов, какой профиль нагрузки, сколько прогонов, как считали процентили.

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

• Проектировать распределённые системы с внешними провайдерами идентификации и продумывать деградацию при их отказе.
• Обосновывать стек через требования и критерии, а не через личные предпочтения.
• Снимать метрики производительности и оформлять их в читаемые таблицы и графики.
• Работать с регуляторными требованиями как с источником нефункциональных требований.
• Оформлять техническую документацию по ГОСТ 34 и ГОСТ 19 без последующих переделок.

Вопросы, которые задают чаще всего

Источник: Индонезия ввела запрет на социальные сети для детей младше 16 лет (опубликовано 2026-03-29)