Атаку нельзя остановить, если её не видно. В OWASP Top 10 есть отдельная категория про недостаток логирования и мониторинга: многие взломы обнаруживают через месяцы, и часто не сами компании, а третьи лица. Этот модуль про то, что логировать, как реагировать и что требует закон о персональных данных.
Что логировать
События безопасности, по которым можно восстановить картину:
- Вход: успехи и неудачи, MFA, сброс и смена пароля, выход.
- Отказы в доступе (ошибки авторизации): много отказов от одного пользователя признак перебора id.
- Ошибки валидации ввода и подозрительные значения.
- Административные действия: смена ролей, настройки, выгрузки данных.
- Критичные бизнес-операции: платежи, смена реквизитов, экспорт.
- Ошибки приложения и падения.
В каждой записи: время (UTC, синхронизированное), кто (id пользователя, сервис), откуда (IP, устройство), что и над чем, результат, id запроса для связи с другими логами.
Чего не логировать
- Пароли (даже неверные: часто это почти верный пароль или пароль от другого аккаунта).
- Токены, идентификаторы сессий, API-ключи, ключи шифрования.
- Полные номера карт и CVV (требование PCI DSS), данные документов.
- Избыточные персональные данные: логи тоже обработка ПДн по 152-ФЗ.
Маскирование лучше делать централизованно в логгере, а не надеяться на каждого разработчика.
Безопасность самих логов
- Инъекция в логи: перевод строки во вводе позволяет подделать запись (
user=admin\nlogin success). Экранировать управляющие символы или писать структурированные логи (JSON), где значение остаётся значением. - Log4Shell показал, что даже логгер может выполнить код, если интерпретирует подстановки в данных.
- Логи отправляются в центральное хранилище, у приложения нет прав их изменять и удалять (защита от отказа от действий и заметания следов).
- Доступ к логам ограничен и сам журналируется.
- Срок хранения определён: достаточно для расследования, не больше нужного.
Обнаружение
Логи без алертов бесполезны. SIEM или система логов с правилами: всплеск неудачных входов, вход с нового устройства у администратора, массовая выгрузка данных, много ошибок 403 от одного пользователя, обращения к адресу метаданных облака. Алерты должны иметь владельца и инструкцию, иначе их перестают читать.
Реагирование на инцидент
Классическая схема NIST SP 800-61:
- Подготовка: план, роли, контакты, доступы, учения.
- Обнаружение и анализ: подтвердить инцидент, оценить масштаб и критичность.
- Сдерживание, устранение, восстановление: изолировать узлы, отозвать учётные данные, закрыть уязвимость, восстановиться из чистых копий, усилить мониторинг.
- Действия после инцидента: разбор без поиска виноватых, улучшения, обновление модели угроз.
Важно сохранять доказательства (логи, образы дисков) до того, как начать «чинить», и вести хронологию.
152-ФЗ кратко
Федеральный закон «О персональных данных» касается любой компании, которая обрабатывает данные о людях в РФ.
- Оператор определяет цели и способы обработки и отвечает за неё. Обработка поручается другим лицам только по договору.
- Основания: согласие субъекта, исполнение договора с ним, требование закона и другие. Согласие должно быть конкретным и информированным, с 1 сентября 2025 года оно оформляется отдельно от других документов.
- Минимизация: собирать только нужное для заявленной цели и удалять по её достижении.
- Локализация: при сборе данных граждан РФ запись, хранение и другие основные операции ведутся в базах на территории РФ.
- Уведомления Роскомнадзора: о намерении обрабатывать ПДн, о трансграничной передаче.
- Защита: уровень защищённости по постановлению Правительства № 1119, состав мер по приказу ФСТЭК № 21, особые требования к специальным категориям (здоровье) и биометрии.
- Утечка: уведомить Роскомнадзор в течение 24 часов о факте инцидента и в течение 72 часов о результатах внутреннего расследования. С 2025 года за утечки действуют повышенные штрафы, за повторные вплоть до оборотных.
- Субъект вправе узнать, какие данные о нём обрабатываются, и потребовать уточнения или удаления.
Для AppSec это значит: знать, где лежат ПДн, не тащить их в логи и тестовые среды, шифровать, ограничивать доступ и иметь готовый план на случай утечки. Юридические детали всегда сверяйте с юристом: закон часто меняется.
Частые ошибки
- Логи есть, но никто их не смотрит.
- Пароли и токены в логах.
- Прод-данные с ПДн в тестовой среде.
- Нет плана реагирования, и в момент инцидента роли выясняют на ходу.
- «Почистили» сервер до сбора доказательств.
Что спросят на собесе
- Какие события безопасности вы логируете и чего никогда не пишете в логи.
- Что такое инъекция в логи и как от неё защититься.
- Опишите этапы реагирования на инцидент.
- Что делать в первые часы после обнаружения утечки ПДн.
- Какие требования 152-ФЗ влияют на разработку.