26 марта 2026 года стало известно: Ajax — один из самых титулованных футбольных клубов Европы — столкнулся с массовой утечкой данных. Под удар попали сведения примерно о 300 тысячах человек: болельщики, держатели абонементов, покупатели билетов, потенциально — платёжные и контактные данные. Это не «где-то у банков». Это спортивный клуб, у которого защита ПДн обычно строится по остаточному принципу: маркетинговая CRM, интеграции с билетными сервисами, подрядчики. Для выпускника направления «Информационная безопасность» это идеальный кейс: свежая дата, измеримый масштаб, понятные регуляторные последствия (152-ФЗ, GDPR в европейской проекции, штрафы, репутация). Ниже — как превратить новость в защищаемую работу, а не в пересказ.
Да, но новость — это только «повод» для главы 1. Комиссии важны: модель нарушителя, модель угроз (STRIDE или MITRE ATT&CK), спроектированные меры защиты и доказанная эффективность. Пересказ статьи securitylab без технической части — гарантированное «удовлетворительно».
Реалистичный минимум: Wazuh или ELK-стек как SIEM, PostgreSQL с шифрованием на уровне колонок (pgcrypto), Keycloak для RBAC/MFA, Python для скриптов детектирования. Не уходите в самописные шифры — это отдельная ошибка, которую ловят на защите.
Нужны метрики с baseline: MTTD (среднее время обнаружения), MTTR (среднее время реагирования), precision/recall детектора, покрытие инцидентов по MITRE ATT&CK. Сравнивайте «до» и «после» внедрения — без сравнения цифры ни о чём не говорят.
Диаграммы — по ГОСТ 19.701-90 (схемы алгоритмов, программ, данных), структурные — по ГОСТ 34.601-90 применительно к АС. UML/C4 допустимы, если есть расшифровка нотации и подписи. Уточните требования кафедры: где-то требуют именно ГОСТ, где-то допускают UML.
Актуальность: инцидент в Ajax показал, что классический периметр не спасает — нужен поведенческий мониторинг выгрузок и доступов к БД с ПДн. Цель: повысить скорость обнаружения аномального доступа к персональным данным. Задачи: анализ инцидента и таксономия по MITRE ATT&CK; проектирование архитектуры сборщика логов; реализация правил корреляции; нагрузочное тестирование и замер MTTD/MTTR. Структура: Гл.1 — анализ угроз и обзор SIEM; Гл.2 — проектирование и реализация; Гл.3 — эксперименты и метрики.
Актуальность: 300 тысяч записей — это результат либо избыточных прав операторов, либо отсутствия шифрования «в покое». Цель: снизить поверхность атаки за счёт принципа наименьших привилегий и криптографической защиты. Задачи: построение матрицы доступа; внедрение MFA; шифрование чувствительных колонок; тестирование на проникновение по OWASP Top 10. Структура: Гл.1 — теория RBAC и OWASP; Гл.2 — реализация; Гл.3 — пентест и выводы.
Актуальность: у спортивных клубов часто нет формальной модели угроз, хотя регуляторные требования уже действуют. Цель: построить повторяемый процесс оценки рисков и план обработки. Задачи: идентификация активов и угроз; квантификация риска; выбор контрмер по ISO/IEC 27002; валидация на кейсе Ajax. Структура: Гл.1 — стандарты и 152-ФЗ; Гл.2 — методика; Гл.3 — пилотное внедрение и результаты.
Возьмите из статьи только факты — дату, клуб, оценочное число пострадавших. Дальше начинается ваша работа: постройте модель нарушителя (внешний атакующий, инсайдер-подрядчик, скомпрометированный сервисный аккаунт), сопоставьте с MITRE ATT&CK, покажите релевантные пункты OWASP Top 10 (A01: Broken Access Control, A02: Cryptographic Failures). Обязательно сошлитесь на 152-ФЗ ст. 19 — обязанность оператора принимать правовые, организационные и технические меры. Это снимает вопрос «а при чём тут стандарты».
Комиссия любит схемы, которые можно «прочитать». Постройте: DFD уровня 1 (потоки ПДн от формы регистрации до хранения), C4-диаграмму контейнеров (веб-приложение, API, БД, SIEM), UML-sequence для процесса аутентификации с MFA. Для процесса обработки инцидента подойдёт BPMN. Если кафедра требует ГОСТ — оформите структурную схему по ГОСТ 34.601-90 и схему данных по ГОСТ 19.701-90.
# Упрощённая схема потоков ПДн в клубе (для DFD уровня 1)
[Болельщик] --(форма покупки билета)--> [Веб-портал]
[Веб-портал] --(API-запрос)--> [Сервис заказов]
[Сервис заказов] --(INSERT с шифрованием)--> [(PostgreSQL + pgcrypto)]
[Сервис заказов] --(событие аудита)--> [Сборщик логов]
[Сборщик логов] --(нормализованные события)--> [SIEM/Wazuh]
[SIEM/Wazuh] --(алерт при аномалии)--> [SOC-аналитик]Считайте не «стало лучше», а конкретику. Минимальный набор: MTTD до/после, MTTR, precision и recall детектора аномального экспорта, число ложноположительных срабатываний в сутки, покрытие техник ATT&CK. Ниже — пример правила детектирования массовой выгрузки, которое ложится в раздел «Реализация».
# Детектор аномального экспорта ПДн из CRM клуба
# Логи нормализуются и пишутся в Elasticsearch
THRESHOLD_ROWS = 5000 # порог выгруженных записей
WINDOW_SEC = 600 # окно наблюдения: 10 минут
def detect_mass_export(events):
"""
events: список словарей вида
{"user": "operator_12", "rows": 1200, "ts": 1711400000,
"action": "export"}
Возвращает список подозрительных сессий.
"""
suspicious = []
for user, batch in group_by_user_window(events, WINDOW_SEC):
total = sum(e["rows"] for e in batch
if e["action"] in ("export", "download"))
if total >= THRESHOLD_ROWS:
suspicious.append({
"user": user,
"rows": total,
"window_s": WINDOW_SEC,
"severity": "HIGH",
"mitre": "T1530" # Data from Information Repositories
})
return suspicious| Метрика | Формула | Baseline | Цель |
|---|---|---|---|
| MTTD | Σ(t_обнаружения − t_инцидента) / N | 45 мин | ≤ 5 мин |
| MTTR | Σ(t_закрытия − t_обнаружения) / N | 8 ч | ≤ 1 ч |
| Precision | TP / (TP + FP) | — | ≥ 0.85 |
| Recall | TP / (TP + FN) | — | ≥ 0.90 |
| Покрытие ATT&CK | N_детектируемых техник / N_релевантных | — | ≥ 0.60 |
Ошибка 1. Пересказ новости вместо анализа. Три абзаца про Ajax, а дальше «была утечка, надо защищаться». Комиссия это видит мгновенно. Выход: сразу после фактов — таблица «угроза → техника ATT&CK → контрмера → метрика проверки».
Ошибка 2. Нет модели нарушителя и модели угроз. Студент пишет «внедрим шифрование и RBAC», но не показывает, от кого и от чего это защищает. Без STRIDE или ATT&CK глава про проектирование повисает в воздухе.
Ошибка 3. Метрики без сравнения. «MTTD = 5 минут» звучит красиво, но если до внедрения никто не мерил — это не результат, а самооценка. Замеряйте baseline на стенде до и после.
Если тема близка, но непонятно, с чего начать практическую часть, — на консультации мы разберём ваш случай за 120 часов до защиты и подскажем, как связать инцидент, архитектуру и метрики в единую логику. Первая встреча бесплатная, помощь с дипломом — по любой из тем выше.
Источник: 300 тысяч пострадавших: один из самых известных футбольных клубов Европы столкнулся с утечкой данных (опубликовано 2026-03-26)