Летом 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:

```
import (
«context»
«gitlab.somedomain.net/platform/golang/logger»
)

if err != nil {
  logger.Info(ctx, «some event was succesful»)
}
```

Есть платформенная либа для записи событий — есть платформенный пайплайн поставки логов. Лог-записи со всех сервисов и систем 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 — панели управления микросервисами. 

Что умеет IT-Crowd?

В нём хранится информация о командах с их микросервисами, о дежурных, выводятся все инструменты мониторинга, данные о потреблении ресурсов и о подах, средах разработки, ссылки на проект в Gitlab, GRPC и Swagger. Также здесь можно базово редактировать конфигурацию Kubernetes. Одна из самых приятных фич для безопасника — указание перечня чувствительных данных, которые микросервис обрабатывает. Делается это с помощью одноименных меток для микросервиса. Благодаря им аналитики ИБ могут легко отфильтровать, где и какие данные обрабатываются, а также к таким сервисам применяются отдельные требования безопасности. Все наши команды и сервисы имеют одинаковые названия и в проектах gitlab, и в ITC, в подах и в любых других пространствах. Это помогает нам не теряться в тысячах микросервисов и не погружаться в хаос. 

Как нам приходят алерты?

Чтение перечня «попавшихся» микросервисов происходит с помощью первой cron-job, отвечающей за получение списка сервисов и проверку на валидность кейса. В логику cron-job заложены следующие проверки:

• не находится ли микросервис в вайт-листе (в будущем планируем отдельно перепроверять сервисы из вайт-листа раз в квартал);

• нет ли активного тикета на исправление логов, если есть — кейс отклоняется; 

• не было ли алертов по сервису за последние три дня, если да — кейс отклоняется. Сделано это для того, чтобы не спамить одним и тем же алертом каждый день; 

• нет ли необработанного алерта на этот сервис.

Если все условия пройдены, то микросервис записывается в базу Sauron-logs, такие кейсы мы называем инцидентами. Следом в дело вступает вторая cron-job, отвечающая за отправку алерта в канал с ботом нашего корпоративного мессенджера Chatzone. При этом отсчет времени для всех алертов начинается с полуночи каждого дня. Это сделано с привязкой к времени начала дежурства нового специалиста и отправки ему не более одного алерта на сервис в день. Когда вторая cron-job получает из базы новое событие ИБ, подтягивается шаблон алерта:

В алерте указано название микросервиса и ссылка на UI с поиском по отфильтрованным за последние сутки логам. Дежурный переходит по ссылке и проверяет отобранные логи на наличие чувствительной информации. 

Всего существует три сценария обработки:

1. подтвердить кейс по кнопке «Создать тикет»;

2. завайтлистить сервис, если в собранных логах указана только публичная информация, например, адреса ПВЗ без чувствительных данных о заказах, ведь все наши ПВЗ доступны на картах. Вайт-листинг ведётся в ITC-карточке сервиса в разделе ETCD;

3. отменить кейс как false positive по кнопке «закрыть», и тогда сервис будет на мьюте следующие три дня (см. правила проверок выше).

Напоминаю — до этого момента вся рутина выполнялась автоматикой без участия дежурных и вышеупомянутого SAST????

Как мы работаем над устранением проблемы?

После подтверждения кейса бот отправляет в тред к алерту сообщение со ссылкой на задачу с доработкой. За это отвечает Демон Мефистофель, постоянно прослушивающий подобные события. Все тикеты на доработку сервисов информационная безопасность ведёт в отдельном JIRA-проекте RISK. Он представляет из себя внутренний аналог Bug-bounty-репортов, но с одной особенностью — если владельцы сервиса не выполняют в срок RISK-тикет, то без снятия эскалации ИБ-специалистом у них не получится провести деплой сервиса по платформенному пайплайну. За это отвечает отдельная блокирующая пайплайн джоба. Если вам интересно почитать про то, как мы выстроили процесс управления рисками, приглашаю в соседнюю хабра-статью от коллег.

Какую информацию бот заполняет в RISK-тикетах?

• Weakness — CWE-532;

• Service name и itc_id — получаем их первой cron job;

• исполнителя и ответственного сотрудника ИБ. Благодаря ITC magic (а, если точнее, то API), бот по названию сервиса получает информацию о владельцах сервиса. В Security-поле проставляется сотрудник, заапрувивший алерт (скоро добавим выставление в это поле ответственных ИБ-бизнес-партнёров. О том, какие функции они выполняют у нас в команде, можете почитать в соседней статье);

• шаблон описания тикета, из динамической подстановки там только поиск с «нехорошими логами» за последние сутки;

• прочие стандартные поля для репорта;

• стандартный срок выполнения задачи.

Что происходит дальше?

Если найденные данные критичны, мы эскалируем риск. Первое — сразу просим отключить запись всех логов на сервис. Второе — меняем срок исполнения работ до двух суток. Базово мы выставляем требование удаления плохих заголовков и данных (реже просим маскировать их в виде «phone: 8-800-535--»).
Если логи проливались в debug-режиме, то мы проводим работу и с ним, и со стандартной глубиной логирования info. Также мы сверяем метки чувствительных данных в карточке сервиса на ITC и просим проверить логи в других сервисах команды. Понять, что чувствительные данные в логах больше не льются, очень просто — после релиза не будет лог-записей с кастомными заголовками, а значит и в поиске будет пусто. 

Итоги

А какие есть аналоги получившемуся решению? Существует довольно известный сканер секретов trufflehog. Предлагаю сравнить его с Sauron-logs по ключевым функциям.

В результате получается, что trufflehog можно использовать в качестве хорошего вдохновителя, но чтобы получилось хорошо, его надо будет дорабатывать. Другим валидным сценарием будет использование trufflehog для поиска секретов через SAST-решения. В случае с Sauron-logs получился инструмент, приземлённый под наши потребности и процессы. 

Позволяет ли решить Sauron-logs вышеупомянутую проблему с CWE-532? Да. По итогу мы пресекаем возможную утечку через журнал логов.

Ozon является площадкой для огромного количества услуг (продажа товаров клиентам — только самая массовая из них) и для их качественной работы обрабатывается широкий спектр чувствительных данных. С помощью Sauron-logs у нас получилось решение для точечного поиска и скрытия такой информации. Мы продолжим расширять наш словарь и оттачивать его для снижения количества фолсов. Также можно двигаться в сторону маскирования чувствительных данных в моменте дообогащения, чтобы проактивно скрывать их автоматикой. Теоретически такой сканер можно внедрить и в другие рабочие инструменты, но уже со своими особенностями. 

Для лучшего понимания и наглядности продукта подготовил схематичное изображение с ключевыми функциями Sauron-logs. Да простят меня системные аналитики за такую самодеятельность. 

Таким получилось наше собственное решение по контролю чувствительных данных в логах, и именно так проявилась моя детская любовь к Вселенной Джона Р.Р. Толкиена.