Kompleksnye-sistemy-informacionnoj-bezopasnosti (1)

1.

Комплексные системы
информационной безопасности
Сделано студентов: Меньшов Г. А.
КТ МТУСИ
Дисциплина: Информатика
ИССЛЕДОВАТЕЛЬСКАЯ РАБОТА
RUST · TRUST SCORE · АНТИФЛУД

2.

Актуальность исследования
Современные информационные системы должны обеспечивать не только
проверку учётных данных, но и анализ поведения пользователя во время
работы с приложением. Прикладные атаки всё чаще строятся на
автоматизации: злоумышленник многократно отправляет одинаковые
запросы, перегружает сервис, пытается вызвать повторное выполнение
операции или имитирует активность реального пользователя.
Проблема
Решение
Традиционные средства защиты
Модель Trust Score — числовая
работают на уровне сети и хоста,
оценка доверия, изменяющаяся в
но не анализируют поведение
зависимости от событий
внутри сервиса.
безопасности.
Реализация
Веб-сервис на Rust с аутентификацией, журналированием и антифлудпротоколом.

3.

Цели и задачи работы
Цель работы
Задачи
Разработать и описать программный прототип системы
01
информационной безопасности на языке Rust с использованием модели
Trust Score и антифлуд-протокола.
Изучить теоретические основы КСИБ
Объект и предмет
02
Объект — система информационной безопасности веб-приложения.
Определить роль адаптивной оценки доверия
Предмет — методы адаптивной оценки доверия и алгоритмы защиты от
массовых повторных запросов.
03
Разработать антифлуд-протокол
04
Реализовать программный код
05
Провести тестирование и сделать выводы

4.

1.1 Комплексная система
информационной безопасности
КСИБ — совокупность организационных, программных и технических мер,
обеспечивающих конфиденциальность, целостность и доступность информации. Её
отличительная черта — не одно средство защиты, а сочетание уровней контроля:
идентификации, разграничения доступа, регистрации событий, обнаружения аномалий
и реагирования на инциденты.
Сетевой и хост-уровень
Межсетевые экраны и антивирусная защита — традиционные средства,
работающие вне прикладного уровня.
Прикладной уровень
Анализ действий пользователя внутри сервиса — особенно важен, когда
вредоносная активность формально выполняется авторизованным субъектом, но
отклоняется от нормального поведения по частоте или интенсивности.
Вывод
Современная защита строится не только на факте успешного входа, но и на
непрерывном анализе поведения субъекта в процессе работы.

5.

1.2 Модель Trust Score: адаптивная защита
Модель Trust Score основана на присвоении пользователю числового показателя доверия в диапазоне от 0 до 100. На старте
пользователь получает максимальное доверие. Каждое событие безопасности влияет на текущую оценку: успешный вход и безопасное
действие увеличивают доверие, а подозрительная активность, ошибочные попытки входа, имитация атаки и флуд-запросы —
уменьшают его.
Преимущество модели
Правила изменения Trust Score
Переход от статического контроля доступа к адаптивному. Если
Успешный вход — небольшое повышение
обычная система принимает решение только один раз — в
Безопасное действие — увеличение показателя
момент входа — то модель доверия оценивает пользователя на
Подозрительное действие — снижение на несколько
протяжении всей сессии. Это позволяет обнаруживать случаи,
единиц
когда субъект вошёл легитимно, но затем начал выполнять
Имитация атаки — существенный штраф
аномальные действия.
Флуд-запросы — дополнительный штраф
При критически низком уровне — блокировка учётной
записи

6.

1.3 Антифлуд-протокол
Защита от массовых повторных запросов — отдельная задача прикладной безопасности. Если система будет обрабатывать каждый запрос, это
может привести к перегрузке сервиса, множественному выполнению операции или искажению бизнес-логики.
Первый
запрос
Дубликаты
1–2с
Порог 20
Антифлуд-протокол решает две задачи одновременно: защита доступности путём дедупликации повторных обращений и формирование
сигнала безопасности для модели Trust Score. Система не просто отбивает лишние запросы — она связывает их с оценкой доверия к субъекту.

7.

2.1 Структура программного прототипа
Практическая часть выполнена в виде веб-приложения на языке Rust. Выбор Rust обусловлен безопасностью
работы с памятью на этапе компиляции, строгой типизацией и пригодностью для разработки
высокопроизводительных сетевых сервисов.
Axum
Фреймворк для обработки HTTP-запросов и маршрутизации
SQLite
База данных для хранения пользователей и журналов событий
Askama
Шаблонизатор для рендеринга страниц интерфейса
tower-sessions
Механизм хранения пользовательской сессии на стороне сервера
Проект модулен: main.rs — запуск и маршруты, db.rs — работа с БД, trust.rs — расчёт доверия, guard.rs —
антифлуд, views.rs — бизнес-логика обработчиков.

8.

2.2 Реализация Trust Score и антифлуд-защиты
Модуль trust.rs
Функция apply_trust_delta задаёт
изменение показателя в зависимости
от типа события:
После каждого изменения новая
величина записывается в базу данных.
ub fn apply_trust_delta(current: i32, event: TrustEvent,
flood_penalty: i32) -> i32 {
let mut trust = current;
match event {
TrustEvent::LoginSuccess => trust = (trust + 1).min(100),
TrustEvent::ActionSafe => trust = (trust + 1).min(100),
TrustEvent::ActionSuspicious => trust = (trust 5).max(0),
TrustEvent::ActionAttack => trust = (trust - 15).max(0),
TrustEvent::FloodDetected => trust = (trust flood_penalty).max(0),
TrustEvent::LoginFailed => trust = (trust - 2).max(0),
}
При критически низком уровне учётная
запись блокируется.
trust
}

9.

Модуль
guard.rs
Для каждой пары user_id и action_name в
конкурентной структуре DashMap хранятся время
начала окна, количество запросов и флаг флуда.
Решения:
pub fn check(&self, user_id: i64, action: &'static str) -> GuardDecision {
let now = Instant::now();
let window = Duration::from_millis(self.cfg.window_ms);
let mut entry = self.states.entry((user_id,
action)).or_insert(WindowState {
window_start: now,
count: 0,
flood_flag: false,
});
if now.duration_since(entry.window_start) > window {
entry.window_start = now;
entry.count = 1;
entry.flood_flag = false;
return GuardDecision::AllowFirst { count: 1 };
}
entry.count += 1;
if entry.count >= self.cfg.threshold && !entry.flood_flag {
entry.flood_flag = true;
return GuardDecision::FloodDetected { count: entry.count };
}
GuardDecision::DuplicateBlocked { count: entry.count }
}
В views.rs решения используются
напрямую: при FloodDetected снижается
Trust Score и возвращается 429 Too Many
Requests.

10.

2.3 Тестирование прототипа
После регистрации и
входа пользователь
Сценарий 1:
Штатная работа
выполняет
безопасные действия.
Trust Score
сохраняется высоким.
В журнале:
REGISTER_SUCCESS,
LOGIN_SUCCESS,
ACTION_EXECUTED.
с

11.

Сценарий 2:
Подозрительное
поведение
Пользователь выполняет действие,
классифицированное как suspicious.
Показатель доверия снижается. В журнале
фиксируется изменение trust_before и
trust_after.

12.

Сценарий 3:
Массовые запросы
Серия одинаковых POST-запросов: первый
обрабатывается, последующие блокируются. После 20
запросов — FLOOD_DETECTED, Trust Score уменьшается.

13.

Сценарий 4:
Блокировка
За счёт повторения атакующих действий trust_score
достигает критического диапазона — аккаунт блокируется.
При следующей попытке система отказывает в доступе.

14.

3 Инструкция по запуску
Откройте терминал и перейдите в папку проекта (например, cd путь/к/проекту). Убедитесь, что в папке есть
Cargo.toml.
Запустите приложение командой:
cargo run
После сборки в терминале появится адрес локального сервера (например, http://127.0.0.1:3000). Откройте его
в браузере, чтобы увидеть веб-прототип. Если появятся ошибки — исправьте их и запустите команду снова.

15.

3 Инструкция по запуску
На сай те будет страница с
окнами входа и регистрации.
После регистрации новый
пользователь создаё тся в
базе данных security.db : в её
записи сохраняются текущие
очки доверия пользователя и
хеш его пароля.

16.

Заключение
В ходе работы разработана и описана система информационной безопасности,
сочетающая адаптивную оценку доверия и защиту от флуд-активности на уровне вебприложения. Поставленная цель достигнута.
Теоретический вклад
Практический результат
Показано, что современная КСИБ
Создан прототип на Rust: регистрация,
должна учитывать не только
вход, хранение Trust Score,
классические механизмы
журналирование событий и антифлуд-
аутентификации, но и анализ
протокол, обрабатывающий только
поведения субъекта в рамках активной
первый запрос из серии одинаковых
сессии.
действий.
Перспективы развития
Добавление ролей, двухфакторной аутентификации, хранение антифлуд-состояния
во внешнем хранилище и расширение набора поведенческих правил.
Прототип подтвердил корректную работу: система выполняет только первый
запрос, фиксирует флуд, пересчитывает Trust Score и блокирует учётную запись
при критическом уровне доверия.