Логи помогают расследовать утечки. Но могут сами стать источником утечкиКогда в системе происходит инцидент, один из первых вопросов звучит так:
«Что записано в логах?»Журналы позволяют восстановить последовательность событий:
кто вошёл в систему;к какому объекту обращался;какую операцию выполнил;был ли запрос успешным;с какого устройства или адреса поступило обращение;как отреагировали средства защиты.Без этих данных сложно выявить атаку, определить затронутые системы и понять масштаб инцидента.
Но разработчики иногда записывают в логи слишком много.
Например:
полное тело API-запроса;пароль или код подтверждения;access- и refresh-токены;ключи шифрования и другие секреты;полные ФИО, должность, адрес электронной почты;строки подключения к базам данных.В результате хранилище логов превращается в дополнительную базу с конфиденциальной информацией.
Причём доступ к ней нередко имеет больше сотрудников, чем к основной системе.
Что действительно стоит фиксировать?Обычно для расследования нужны:
время события;тип операции;результат: успешно или отказ;идентификатор пользователя или сервиса;идентификатор объекта;источник запроса;система, обработавшая событие;идентификатор сессии или корреляции.Если сессию необходимо отслеживать, OWASP рекомендует рассмотреть хеширование её идентификатора вместо записи исходного значения.
Важно соблюдать баланс!Если записывать слишком мало, расследовать инцидент будет невозможно. Если записывать всё подряд, сама система журналирования станет новым активом с высоким риском.
Полезные материалы:
OWASP Logging Cheat Sheet NIST SP 800-92: управление журналами безопасностиЛоги: хороший пример того, почему информационная безопасность и privacy не стоит рассматривать отдельно: данные, необходимые для защиты системы, тоже нужно классифицировать, минимизировать и защищать.
Подробнее об инфраструктуре, инцидентах и технических мерах защиты поговорим на нашем продукте Cyber in Privacy
Регистрация RPPAedu.pro | Level UP: IT
