Процессы и архитектура AppSec

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

Валидация на границе решает, приемлемы ли данные, и allowlist разрешённого лучше denylist запрещённого. Кодирование происходит позже, когда данные попадают в HTML, SQL или в shell, и делает их безопасными для конкретного интерпретатора.

Высокая: вредоносная загрузка — антивирус, проверка реального типа, хранение вне web-root; SQLi через имя файла — параметризованные запросы; неавторизованное чтение — авторизация отдачи. Средняя: DoS большим файлом — лимит на тело POST; неавторизованная загрузка — авторизация. Низкая: перехват — TLS.

Сопоставить каждому вектору контроль: авторизация на уровне объекта по счёту отправителя; отклонять неположительные суммы; авторизовать просмотр баланса; rate-limit на перебор карт; фиксировать курс на сервере; точные decimal-типы; транзакция с блокировкой; параметризованные запросы; анти-CSRF токены; экранирование; валидация диапазона чисел.

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

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

Каждая учётная запись получает только права, нужные для её задачи, поэтому компрометация или ошибка достаёт до части данных, а не до всей системы. Принцип вырождается потому, что права выдают по запросу и не отзывают, и учётки копят разрешения до пересмотра доступов.

Диаграмма называет процессы, хранилища, потоки и границы доверия, поэтому каждая угроза привязана к конкретному элементу. STRIDE проходит по элементам — подмена, искажение, отказ от авторства, раскрытие, отказ в обслуживании и повышение привилегий.

Подтвердить воспроизводимость PoC, затем оценить импакт: к каким таблицам учётка имеет доступ, есть ли запись, достижимы ли ПДн. Если наименьшие привилегии соблюдены (только чтение публичного каталога) — инъекция реальна, но низкой критичности. Severity задаёт импакт.

Ревью ведут по радиусу поражения, а не по порядку диффа. Идентификатор сессии в URL отклоняем — он утекает через логи, referer и ссылки. Обход фактора по IP отклоняем — сетевой диапазон не личность. Долгую cookie принимаем лишь как отдельный токен с малыми правами и серверным отзывом.

Сдвигаем безопасность влево, сопоставляя этапу контроль по доступному: требования → требования ИБ; дизайн → ревью архитектуры; код → SAST; тесты → фаззинг; сборка → SCA; тест → DAST; e2e → пентест; прод → smoke-тесты; поддержка → патчинг.

Новый идентификатор выдаётся при входе и при каждой смене привилегий, а прежний аннулируется — убивает фиксацию и устаревшее повышение. Состояние сессии авторитетно на сервере, поэтому выход и отзыв реальны; действуют таймаут бездействия и абсолютный, а cookie помечена HttpOnly, Secure и SameSite.

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

Логируются события безопасности — кто, что, над чем, откуда, результат и время, а не сырые тела. Учётные данные, токены, ключи, полные номера карт и лишние персональные данные не пишутся никогда. Пишущий не удаляет — только дозапись в неперезаписываемое хранилище.

Гонка: чтение-проверка-запись не атомарны — фикс транзакцией с пессимистичной блокировкой. Валидация: отрицательный amount обходит проверку остатка. Авторизация: нет проверки владения fromId, а Actuator (heapdump) и H2 утекают данные. DoS: неограниченный BigDecimal — лимит. Добавить @ControllerAdvice.

Ключи держат в управляемом KMS или HSM, а сервис получает короткоживущие учётные данные по идентичности нагрузки, а не из образа. Конвертное шифрование заворачивает ключи данных в ключ, не покидающий KMS. Две версии живут одновременно ради ротации внахлёст, и каждый ключ служит одной цели.

Арендатор выводится из аутентифицированной сессии, а не из параметра запроса, и проверяется ниже приложения — row-level security или учётными данными на арендатора, — поэтому забытый фильтр вернёт пустоту, а не всё. Межарендный доступ даёт алерт, а границу проверяют тестами.

Спросить, что система делает и с какими критичными системами взаимодействует (платёжка, ПДн), какие данные обрабатывает, модель доступа (AD/IDM), публикацию наружу, полноту логирования, где хранятся чувствительные данные, и архитектуру (кто авторизует переход).

Базовая оценка описывает уязвимость абстрактно, а средовые и временные метрики — вашу инсталляцию. Понижайте, когда уязвимый путь недостижим, предусловия не выполняются или компенсирующий контроль блокирует её, но не из-за отсутствия эксплойта.

Умолчания ограничительные — ссылки истекают, публикация включается явно и отзывается в любой момент. Идентификаторы — длинные случайные токены, а не номера, иначе ссылки перебираются. Злоупотребление ограничивают лимитами загрузки, объёма и скачиваний на аккаунт, а публикации логируют.

Защищать на стороне приложения, не в СУБД (шифрование СУБД спасает лишь от backup-админов). Хэширование там, где нужна только проверка (пароли); асимметрию — когда один пишет, другой читает; иначе симметрию. Ключи держит приложение, поэтому админы видят лишь шифртекст. Целостность — keyed-хэш строки, сцепленный с предыдущей.

Сначала уточнить рамки (требования биржи, функции оператора, данные, ОС/БД), затем контроли: endpoint-защита, DLP, мониторинг SOC. Сегментировать сеть; изолировать АРМ оператора (без интернета) с 2FA; API за WAF; БД не публиковать. mTLS при непостоянной связи или IPsec + OAuth при постоянном канале; подписывать каждую заявку.

Сетевое расположение перестаёт быть идентичностью. Каждый вызов несёт проверяемую идентичность нагрузки — сертификаты mTLS с автоматической ротацией, — и сервис сам авторизует вызывающего на каждый запрос с контекстом пользователя. Сначала режим наблюдения, затем запрет по умолчанию.

Обосновать порядок контекстом, а не заучить. Изучить бизнес и активы, спросить IT и стейкхолдеров про реальные инциденты и требования регуляторов и строить стратегию от этих проблем. Защитимая первая очередь — Инвентаризация → Стратегия → Архитектура (нельзя защищать неизвестные активы); добавить Комплаенс, если доминирует регуляторика.