Летом 2023 года во время выступления на одной из ИБ-конференций представителю вендора задали вопрос: «А как бороться с секретами и другой чувствительной информацией в логах? Контролировать миллионы записей в сутки довольно трудно». К моему удивлению, вендор ответил, что на текущий момент в России нет таких решений. Удивился я потому, что мы уже отладили к тому времени инструмент для решения именно этой проблемы. Но давайте обо всем по порядку.  В IT-компаниях любого масштаба производится огромное количество автоматических и ручных процессов. Чтобы понимать, что происходит «под капотом» у системы во время её работы, разработчики используют сообщения о важных событиях, которые называются логами. Как правило, логируются ошибки сервиса, действия пользователей и важные события на стороне сервера. Примером такого лога будет сообщение, что сотрудник не вошёл в систему или не смог обновить фотографию своего профиля из-за появившейся ошибки. Веб-интерфейс с такими логами обычно доступен всем разработчикам (или они просто лежат в базе данных, куда легко попасть), потому что в нём они постоянно проверяют работоспособность продуктов.  Одно дело, когда логи касаются событий отвлечённых и рутинных, как в примере выше. Но совсем другое, когда в таких записях хранятся чувствительные данные. Тут возникает риск неправомерного доступа к данным со стороны внутреннего нарушителя.  Внутренний нарушитель — лицо (сотрудник), имеющее права доступа к рабочим учетным записям и системам компании. Примером риска со стороны внутреннего нарушителя будет предумышленная кража данных сотрудником. Чувствительные данные — перечень данных, безопасность которых контролируется ИБ. В Ozon команда информационной безопасности следит за безопасностью не только персональных данных, но и любой информации, которая относится к нашим клиентам, сотрудникам, партнёрам и процессам.  В международной классификации эта уязвимость называется CWE-532: Insertion of sensitive information into log file и входит в группу самых влиятельных уязвимостей OWASP TOP-10 2021 в категории A09:2021 — Security Logging and Monitoring Failures. Но что злоумышленник может с ней сделать? Самое очевидное — парсинг или выгрузка журнала событий, в которых есть чувствительная информация. Пример — сервис рассылок электронных писем пишет в логах e-mail’ы, на которые отправлялись сообщения. В день он отправляет тысячу писем, значит в течение некоторого времени злоумышленники так могут украсть всю активную клиентскую базу этой компании. Также по таким логам злоумышленник может посмотреть, в каких разделах с чувствительными данными он может оставить за собой «след», если попробует что-то сделать с данными оттуда (в сценариях разведки или перемещения). Другой возможный сценарий — небезопасное обращение с JWT-токенами и паролями, которые выводит в логи сервис авторизации. Так учётные записи могут быть скомпрометированы, причём неважно, обычный это пользователь или админ системы. Примеры, которые я описал выше, не выдуманы, к сожалению, они имеют подтверждения из реальной жизни, новости собраны здесь, тут и тут.  Альтернативным примером уязвимости, вызванной некорректной работой лог-файлов будет также Log4j, нашумевшая в конце 2021 года. Уязвимость была найдена в популярном фреймворке обработки логов для Java-приложений. Если в логе записи присутствует значение в формате {jndi: URL}, то сервер мог исполнить произвольный код, что приводит к RCE-уязвимости. То есть, если разработчики неосознанно логировали текст ошибок и запросов пользователей в полном виде (где чаще всего можно было проэксплуатировать уязвимость), злоумышленники могли захватить контроль над системой. Что и было сделано с продуктами Apple, Oracle, Amazon, JetBrains и многих других (источник – тут). Как мы видим, вред от уязвимости может быть большим, но как рекомендуют с ней управляться? На сайте многоуважаемых MITRE перечислены следующие рекомендации: Серьёзно обдумайте чувствительность данных, записанных в лог-файлы. Не пишите секреты в логи.  Отключите режим записи debug-логов перед деплоем. Настройте конфигурации так, чтобы ПО соответствующе переключалось из debug- в production-состояние.  Защищайте логи от неавторизованного чтения и записи.  Средства статического анализа кода (SAST) в состоянии найти некоторые примеры данного CWE без необходимости выполнения кода.  Кажется, что всё очевидно! Просто не пиши в логи явки и пароли, а где написал, то, вероятно, тебе поможет SAST, который предназначен для поиска других багов. Но как их отлавливать в реальности? Как структурировано и с минимальным участием специалистов решить эту проблему для корпораций с тысячами микросервисов? Наша команда сделала собственное решение: бот Тёмного Властелина Sauron-logs — инструмент для алертинга и оперативного реагирования на подобные кейсы. Начну с того, что для удобства сбора событий для всех наших языков разработаны платформенные библиотеки, которые позволяют записывать события определенной глубины логирования.  Базовый пример кода на Go: Есть платформенная либа для записи событий — есть платформенный пайплайн поставки логов. Лог-записи со всех сервисов и систем Ozon хранятся в нашем собственном централизованном хранилище Logging. Точка входа всех данных — file.d.  File.d разработан нашей Платформой для быстрой обработки потоков данных. Продукт выложен в опенсорс, можете познакомиться с ним по ссылке – https://github.com/ozontech/file.d/blob/master/README.md. Данные в него поступают из dockerd через STDOUT в необработанном однострочном виде. Далее они дообогащаются метаинформацией о кубере и прочими кастомными заголовками.  Благодаря эффективности file.d сканировать регулярными выражениями входящие потоки данных можно «прямо на ходу» без потери производительности и лага. Поиск проводится по следующим категориям данных: номера телефонов, e-mail, паспортные данные и СНИЛС, индивидуальные предприниматели (ими могут быть наши селлеры или партнёры),  геолокации — улицы, города, адреса и прочие объекты, токены (сканируются для отдела продуктовой безопасности и работают на полной автоматике без проверки аналитиками).  Всё, что было отловлено, получает новый кастомный заголовок и параметр с типом выявленных данных для простоты дальнейшей аналитики. Названия сервисов, которым добавили кастомный заголовок в лог-запись, Платформа передаёт в Sauron-logs. Дальнейшая аналитика по сервису проводится при помощи IT-Crowd — панели управления микросервисами.  В нём хранится информация о командах с их микросервисами, о дежурных, выводятся все инструменты мониторинга, данные о потреблении ресурсов и о подах, средах разработки, ссылки на проект в Gitlab, GRPC и Swagger. Также здесь можно базово редактировать конфигурацию Kubernetes. Одна из самых приятных фич для безопасника — указание перечня чувствительных данных, которые микросервис обрабатывает. Делается это с помощью одноименных меток для микросервиса. Благодаря им аналитики ИБ могут легко отфильтровать, где и какие данные обрабатываются, а также к таким сервисам применяются отдельные требования безопасности. Все наши команды и сервисы имеют одинаковые названия и в проектах gitlab, и в ITC, в подах и в любых других пространствах. Это помогает нам не теряться в тысячах микросервисов и не погружаться в хаос.  Чтение перечня «попавшихся» микросервисов происходит с помощью первой cron-job, отвечающей за получение списка сервисов и проверку на валидность кейса. В логику cron-job заложены следующие проверки: не находится ли микросервис в вайт-листе (в будущем планируем отдельно перепроверять сервисы из вайт-листа раз в квартал); нет ли активного тикета на исправление логов, если есть — кейс отклоняется;  не было ли алертов по сервису за последние три дня, если да — кейс отклоняется. Сделано это для того, чтобы не спамить одним и тем же алертом каждый день;  нет ли необработанного алерта на этот сервис. Если все условия пройдены, то микросервис записывается в базу Sauron-logs, такие кейсы мы называем инцидентами. Следом в дело вступает вторая cron-job, отвечающая за отправку алерта в канал с ботом нашего корпоративного мессенджера Chatzone. При этом отсчет времени для всех алертов начинается с полуночи каждого дня. Это сделано с привязкой к времени начала дежурства нового специалиста и отправки ему не более одного алерта на сервис в день. Когда вторая cron-job получает из базы новое событие ИБ, подтягивается шаблон алерта: В алерте указано название микросервиса и ссылка на UI с поиском по отфильтрованным за последние сутки логам. Дежурный переходит по ссылке и проверяет отобранные логи на наличие чувствительной информации.  Всего существует три сценария обработки: подтвердить кейс по кнопке «Создать тикет»; завайтлистить сервис, если в собранных логах указана только публичная информация, например, адреса ПВЗ без чувствительных данных о заказах, ведь все наши ПВЗ доступны на картах. Вайт-листинг ведётся в ITC-карточке сервиса в разделе ETCD; отменить кейс как false positive по кнопке «закрыть», и тогда сервис будет на мьюте следующие три дня (см. правила проверок выше). Напоминаю — до этого момента вся рутина выполнялась автоматикой без участия дежурных и вышеупомянутого SAST🙂 После подтверждения кейса бот отправляет в тред к алерту сообщение со ссылкой на задачу с доработкой. За это отвечает Демон Мефистофель, постоянно прослушивающий подобные события. Все тикеты на доработку сервисов информационная безопасность ведёт в отдельном JIRA-проекте RISK. Он представляет из себя внутренний аналог Bug-bounty-репортов, но с одной особенностью — если владельцы сервиса не выполняют в срок RISK-тикет, то без снятия эскалации ИБ-специалистом у них не получится провести деплой сервиса по платформенному пайплайну. За это отвечает отдельная блокирующая пайплайн джоба. Если вам интересно почитать про то, как мы выстроили процесс управления рисками, приглашаю в соседнюю хабра-статью от коллег. Деплой сервиса — развёртывание и запуск кода в его рабочей среде (грубо говоря, на серверах). Платформенный пайплайн — «официальный» и чаще всего обязательный для всех разработчиков сценарий поэтапной проверки и развертывания нового кода сервиса, этот пайплайн управляется командой Платформы Ozon Tech. Git Джоба — проверка сервиса на соответствие разным параметрам — отсутствие ошибок в коде, автотесты, проверка его безопасности и т.д. Этапы пайплайнов строятся из джоб. Ну и в финале Bug Bounty-репорты — выявленные этичными хакерами/исследователями проблемы безопасности в рамках нашей программы вознаграждений, подробнее можете прочитать здесь — https://app.bugbounty.bi.zone/companies/ozon/main Какую информацию бот заполняет в RISK-тикетах? Weakness — CWE-532; Service name и itc_id — получаем их первой cron job; исполнителя и ответственного сотрудника ИБ. Благодаря ITC magic (а, если точнее, то API), бот по названию сервиса получает информацию о владельцах сервиса. В Security-поле проставляется сотрудник, заапрувивший алерт (скоро добавим выставление в это поле ответственных ИБ-бизнес-партнёров. О том, какие функции они выполняют у нас в команде, можете почитать в соседней статье); шаблон описания тикета, из динамической подстановки там только поиск с «нехорошими логами» за последние сутки; прочие стандартные поля для репорта; стандартный срок выполнения задачи. Если найденные данные критичны, мы эскалируем риск. Первое — сразу просим отключить запись всех логов на сервис. Второе — меняем срок исполнения работ до двух суток. Базово мы выставляем требование удаления плохих заголовков и данных (реже просим маскировать их в виде «phone: 8-800-535--»). Если логи проливались в debug-режиме, то мы проводим работу и с ним, и со стандартной глубиной логирования info. Также мы сверяем метки чувствительных данных в карточке сервиса на ITC и просим проверить логи в других сервисах команды. Понять, что чувствительные данные в логах больше не льются, очень просто — после релиза не будет лог-записей с кастомными заголовками, а значит и в поиске будет пусто.  А какие есть аналоги получившемуся решению? Существует довольно известный сканер секретов trufflehog. Предлагаю сравнить его с Sauron-logs по ключевым функциям.  Sauron-logs trufflehog Что выполняет Проводит поиск чувствительных данных в логах и автоматизирует процесс реагирования со стороны ИБ. Проводит поиск секретов в SQL, S3-хранищах, Git и другим файловых системах. Какие данные ищет Проводится поиск по 6 категориям чувствительных данных с учетом специфики нашего бизнеса. Выявленные секреты не валидируются (проверка вручную). Есть возможность создания своих поисков. Из коробки есть поиск более 300 секретов для разных сервисов (в основном ключи API и пароли). В реальности для нашего РФ-рынка применимы не более 10% сервисов и набор данных специфичен. Из плюсов — все найденные секреты валидируются по API площадки-держателя, что сводит количество false positive к минимуму. Есть возможность создания своих поисков и хранилищ. Как работает Поиск и проверка на повтор проводятся без участия человека, он проверяет алерты с подготовленным поиском, заводит тикеты на доработку. Из коробки запускается через командную строку, принимает на вход тип хранилища и путь к нему. Выводит отчет с выявленными секретами. Процесс реагирования на выявленные секреты отсутствует. Дополнительные функции Есть вайт-листинг, заложены внутренние логики для отсутствия повтора алертов и алертов на сервисы с активными задачами. Для встраивания в процессы необходимы доработки. Теоретически возможна интеграция к журналу логов, но эффективность такого решения остается под вопросом. В результате получается, что trufflehog можно использовать в качестве хорошего вдохновителя, но чтобы получилось хорошо, его надо будет дорабатывать. Другим валидным сценарием будет использование trufflehog для поиска секретов через SAST-решения. В случае с Sauron-logs получился инструмент, приземлённый под наши потребности и процессы.  Позволяет ли решить Sauron-logs вышеупомянутую проблему с CWE-532? Да. По итогу мы пресекаем возможную утечку через журнал логов. Ozon является площадкой для огромного количества услуг (продажа товаров клиентам — только самая массовая из них) и для их качественной работы обрабатывается широкий спектр чувствительных данных. С помощью Sauron-logs у нас получилось решение для точечного поиска и скрытия такой информации. Мы продолжим расширять наш словарь и оттачивать его для снижения количества фолсов. Также можно двигаться в сторону маскирования чувствительных данных в моменте дообогащения, чтобы проактивно скрывать их автоматикой. Теоретически такой сканер можно внедрить и в другие рабочие инструменты, но уже со своими особенностями.  Для лучшего понимания и наглядности продукта подготовил схематичное изображение с ключевыми функциями Sauron-logs. Да простят меня системные аналитики за такую самодеятельность.  Таким получилось наше собственное решение по контролю чувствительных данных в логах, и именно так проявилась моя детская любовь к Вселенной Джона Р.Р. Толкина.