Опубликовано: 15.10.2026 | Источник: Xakep.ru

Неофициальные клиенты Telegram в ВКР: архитектура контроля целостности клиентского ПО

В коде Telegram для iOS заметили служебную пометку, связанную с предупреждением о неофициальном клиенте. По данным издания «Код Дурова», в профиле пользователя может появиться отметка, если он работает через стороннюю сборку мессенджера. Отдельного анонса не было — нововведение найдено на этапе разбора кода, но сам факт показателен: крупный вендор переходит от «молчаливого» ограничения сторонних клиентов к публичной маркировке доверия к устройству.

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

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

Тема 1. Сервис аттестации клиентских приложений: проектирование и оценка накладных расходов

Актуальность. Публичная маркировка неофициальных сборок означает, что у сервиса появляется состояние «устройство не подтверждено». Это уже не внутренняя эвристика, а часть пользовательского интерфейса и продуктовой логики — значит, её нужно проектировать, документировать и тестировать.

Цель: разработать подсистему подтверждения подлинности клиентского приложения и оценить её влияние на задержки рукопожатия и на нагрузку серверной части.

Задачи:

• построить модель угроз для клиента мессенджера (пересборка, хук, эмулятор, реверс-инжиниринг протокола);
• сравнить платформенные механизмы аттестации (Play Integrity, App Attest, DeviceCheck) и собственные схемы на основе подписи сборки и SBOM;
• спроектировать протокол обмена attestation-токенами между клиентом и сервером проверки;
• реализовать прототип и провести нагрузочное тестирование с фиксацией p95/p99.

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

Тема 2. Детектирование модифицированных клиентов: сравнительный анализ методов

Актуальность. Пока одни вендоры маркируют неофициальные клиенты, другие пытаются их распознавать. Разрыв между «обнаружить» и «показать пользователю» — это отдельная инженерная задача с высокой ценой ошибки: ложное срабатывание бьёт по доверию сильнее, чем пропуск.

Цель: сравнить методы выявления модифицированных клиентов и определить условия, при которых каждый из них применим.

Задачи: классифицировать признаки (криптографические, поведенческие, сетевые); собрать метрики precision/recall на синтетическом наборе; оценить устойчивость к обходу; сформулировать рекомендации по комбинированию методов.

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

Тема 3. Маркировка недоверенных устройств в корпоративном мессенджере: политики и экономика внедрения

Актуальность. Ровно тот же механизм, но повёрнутый в сторону бизнеса: компания хочет видеть, с каких устройств сотрудники пишут в защищённый чат. Это уже про DLP, управление рисками и внутренние регламенты.

Цель: разработать набор политик для недоверенных клиентов и оценить экономический эффект внедрения.

Задачи: описать ролевую модель и уровни доверия; спроектировать конфигурируемые политики (предупреждение, ограничение вложений, read-only, блокировка); рассчитать TCO и срок окупаемости; подготовить эксплуатационную документацию.

Структура: Глава 1 — анализ угроз и нормативной базы; Глава 2 — проектирование подсистемы политик; Глава 3 — экономическое обоснование и оценка рисков.

Аналитическая глава: сравниваем методы, а не «технологии вообще»

Самая частая слабость первого раздела — перечисление инструментов без критериев. Привяжите сравнение к статье: вендор решает задачу «отличить официальную сборку от сторонней и сообщить об этом». Разложите это на четыре подхода и сравните по фиксированному набору критериев.

Вывод для главы формулируйте не как «метод X лучше», а как «метод X применим при условии Y, поскольку даёт precision Z при допустимой задержке». Такой вывод потом защищается на вопросы комиссии: он опирается на критерии, а не на вкус автора.

Проектная часть: что именно рисовать и описывать

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

• Клиент — формирует attestation-токен и обновляет его при изменениях среды;
• Сервис проверки — валидирует подпись, сверяет сборку со списком разрешённых;
• Хранилище состояний — хранит уровень доверия устройства и историю переходов;
• Сервис политик — решает, что делать с недоверенным клиентом (предупреждение, ограничения);
• Слой представления — та самая отметка в профиле, о которой пишет источник.

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

{
  "device_id": "uuid-v4",
  "client_build": "sha256:9f2c...",
  "platform": "ios",
  "attestation": "base64-token",
  "issued_at": "2026-03-30T10:15:00Z",
  "policy_hint": "unverified"
}

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

Тестирование и метрики: чем доказывать работоспособность

Здесь диплом либо становится сильным, либо рассыпается. Привяжите набор метрик к ISO/IEC 25010 и не пытайтесь измерить «всё»: выберите 5–7 показателей и доведите их до чисел.

Наблюдаемость удобно строить на OpenTelemetry: трассируйте цепочку «клиент → сервис проверки → сервис политик» и вынесите метрики в единый дашборд. Сборку и развёртывание стенда опишите в виде CI/CD-пайплайна — даже простой pipeline «сборка → тесты → деплой в Kubernetes» в третьей главе выглядит убедительно и легко защищается.

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

• Проектировать подсистемы доверия: от модели угроз до пользовательского индикатора.
• Обосновывать выбор стека через критерии, а не через популярность технологии.
• Строить нагрузочные сценарии и превращать их в таблицы с метриками.
• Оформлять техническую документацию по ГОСТ 34.602-89 и 19.201-78 без переписывания учебника.
• Связывать инженерные решения с экономикой: TCO, срок окупаемости, стоимость ложного срабатывания.

Частые вопросы

Обязательно ли писать рабочий код для такой темы?

Нет, но нужен артефакт, который можно продемонстрировать: прототип сервиса проверки, модель на синтетических данных или имитационный стенд. Если тема аналитическая (сравнение методов детектирования), достаточно воспроизводимого набора тестов и расчётов precision/recall.

Где брать данные, если реальных логов мессенджера нет?

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

Как оформить диаграммы архитектуры?

UML-диаграммы компонентов и последовательности — оптимальный вариант: они легко читаются и соответствуют ГОСТ 19.701-90 по составу обозначений. Не смешивайте на одной схеме уровень развёртывания и уровень классов, иначе комиссия задаст вопрос, на который не будет ответа.

Насколько сложна тема в реализации?

Сервис аттестации средней сложности: нужны базовые навыки работы с подписями, HTTP-API и контейнерами. Самая трудоёмкая часть — не код, а методика измерений и корректное описание модели угроз.

Источник: СМИ: в Telegram появятся отметки об использовании неофициального клиента (опубликовано 2026-03-30)