Сервис пишет в журнал полный access-токен для диагностики. Какую защитную границу нужно изменить, чтобы логи не стали каналом утечки?
Полные access-токены нельзя записывать в журналы: их следует удалять или маскировать до передачи записи в систему логирования. Для трассировки нужно использовать отдельный идентификатор запроса либо короткий защищённый отпечаток токена, не позволяющий восстановить или предъявить его как учетные данные.
Логи являются отдельной границей доверия: они часто агрегируются, копируются, дольше хранятся и доступны большему числу сотрудников и систем, чем исходный сервис.
Централизованное журналирование появилось как средство диагностики распределённых систем и расследования инцидентов. По мере роста числа сервисов отдельные локальные журналы стали объединять в общие платформы наблюдаемости.
Это решило проблему поиска событий между компонентами, но создало новый риск: диагностические данные начали пересекать границы сервисов и попадать в хранилища с иной политикой доступа, хранения и резервного копирования.
Bearer-токен даёт возможность предъявить себя сервису от имени его владельца, пока токен действителен. Если такой токен попал в журнал, компрометация log-платформы, резервной копии или учётной записи оператора может превратиться в компрометацию пользовательской сессии.
Опасность сохраняется даже при отсутствии внешнего доступа к логам. Токены могут оказаться в системах поиска, уведомлениях, выгрузках для разработчиков и автоматических отчётах. Маскирование только в интерфейсе просмотра недостаточно, если исходная запись уже содержит секрет.
Секрет нужно исключать на источнике — до сериализации события и отправки его в сборщик логов. Это относится не только к заголовку авторизации, но и к cookie, параметрам URL, телу запроса, дампам исключений и объектам, которые могут содержать учетные данные.
Для связывания событий следует применять correlation ID или request ID, не являющийся секретом. Если требуется определить, каким токеном были выполнены операции, можно хранить специально вычисленный отпечаток, например keyed-хеш с ключом вне системы логирования; обычный хеш всё равно может позволить проверять догадки о коротких или предсказуемых значениях.
Контроль должен включать несколько уровней: безопасные структурированные логгеры, запрет опасных полей по умолчанию, тесты на утечку секретов, ограничение доступа к логам, шифрование при передаче и хранении, короткие сроки хранения и аудит обращений. Эти меры уменьшают вероятность и последствия утечки, но не заменяют отзыв уже скомпрометированного токена.
Автоматическое обнаружение секретов в log-платформе полезно как аварийный барьер, однако оно может пропустить новый формат или дать ложные срабатывания. Поэтому основная защита должна находиться в коде и библиотеках формирования событий, а не только в последующей фильтрации.
Команда расследовала редкие ошибки авторизации и добавила в журналы заголовки запросов. Вскоре тот же поток событий стал доступен подрядчику поддержки, а журналы начали реплицироваться в долговременное хранилище. В результате диагностическое изменение расширило жизненный цикл и круг доступа к действующим токенам.
Рассматривались три варианта. Можно было оставить токены и усилить права на журналы, но это не устраняло риск копий и человеческих ошибок. Можно было хранить обычный хеш токена, что облегчало поиск событий, но позволяло проверять известные или низкоэнтропийные значения.
Выбрали удаление токена на входе в логгер и добавление request ID; для редких расследований ввели отдельный защищённый механизм сопоставления событий с ограниченным сроком действия. После изменения журналы сохранили диагностическую ценность, но перестали быть готовым источником учетных данных.
Нет универсальной гарантии. Частичное отображение может облегчить сопоставление событий, но оставшиеся фрагменты нельзя считать безопасными без анализа формата и энтропии токена. Для bearer-токена безопаснее не записывать значение вообще; если нужна корреляция, применяют отдельный неаутентифицирующий идентификатор.
Потому что журнал обычно имеет больше копий и более длительный срок жизни, чем оперативные данные сервиса. Доступ может появиться через резервные копии, экспорт, интеграции мониторинга, отладочные выгрузки или компрометацию одной привилегированной учётной записи. Ограничение доступа необходимо, но предотвращение записи секрета снижает сам масштаб возможной утечки.
Нужно считать его потенциально скомпрометированным: отозвать или дождаться истечения токена согласно модели жизненного цикла, удалить или изолировать журналы по процедуре реагирования, проверить доступы и выяснить область распространения копий. Затем исправить источник записи, добавить автоматические проверки и убедиться, что новые события больше не содержат секрет.