Летом 2023 года во время выступления на одной из ИБ-конференций представителю вендора задали вопрос: «А как бороться с секретами и другой чувствительной информацией в логах? Контролировать миллионы записей в сутки довольно трудно». К моему удивлению, вендор ответил, что на текущий момент в России нет таких решений. Удивился я потому, что мы уже отладили к тому времени инструмент для решения именно этой проблемы. Но давайте обо всем по порядку.
Обозначение проблемы и введение
В IT-компаниях любого масштаба производится огромное количество автоматических и ручных процессов. Чтобы понимать, что происходит «под капотом» у системы во время её работы, разработчики используют сообщения о важных событиях, которые называются логами. Как правило, логируются ошибки сервиса, действия пользователей и важные события на стороне сервера. Примером такого лога будет сообщение, что сотрудник не вошёл в систему или не смог обновить фотографию своего профиля из-за появившейся ошибки. Веб-интерфейс с такими логами обычно доступен всем разработчикам (или они просто лежат в базе данных, куда легко попасть), потому что в нём они постоянно проверяют работоспособность продуктов.
Одно дело, когда логи касаются событий отвлечённых и рутинных, как в примере выше. Но совсем другое, когда в таких записях хранятся чувствительные данные. Тут возникает риск неправомерного доступа к данным со стороны внутреннего нарушителя.
Внутренний нарушитель — лицо (сотрудник), имеющее права доступа к рабочим учетным записям и системам компании. Примером риска со стороны внутреннего нарушителя будет предумышленная кража данных сотрудником.
Чувствительные данные — перечень данных, безопасность которых контролируется ИБ. В Ozon команда информационной безопасности следит за безопасностью не только персональных данных, но и любой информации, которая относится к нашим клиентам, сотрудникам, партнёрам и процессам.
Классификация и сценарии использования уязвимости
В международной классификации эта уязвимость называется CWE-532: Внесение чувствительной информации в лог-файл</p>" data-abbr="Insertion of sensitive information into log file">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 с поиском по отфильтрованным за последние сутки логам. Дежурный переходит по ссылке и проверяет отобранные логи на наличие чувствительной информации.
Всего существует три сценария обработки:
подтвердить кейс по кнопке «Создать тикет»;
завайтлистить сервис, если в собранных логах указана только публичная информация, например, адреса ПВЗ без чувствительных данных о заказах, ведь все наши ПВЗ доступны на картах. Вайт-листинг ведётся в ITC-карточке сервиса в разделе ETCD;
отменить кейс как false positive по кнопке «закрыть», и тогда сервис будет на мьюте следующие три дня (см. правила проверок выше).
Напоминаю — до этого момента вся рутина выполнялась автоматикой без участия дежурных и вышеупомянутого SAST
Интересные статьи
Интересные статьи
