Структурированное журналирование и SIEM

Структурированное журналирование централизует поддерживаемые события Gateway и демонов, добавляет поля для поиска и применяет политику хранения. Рассчитайте хранилище для приёма и хранения событий, наблюдайте за состоянием ClickHouse и планируйте обновления движка до прекращения поддержки старых образов.

Используйте структурированное журналирование, если командам нужна единая управляемая поверхность поиска вместо разрозненных текстовых файлов. Экспорт SIEM подходит, когда службе безопасности нужен сокращённый поток аудита во внешнем сборщике. Эти функции связаны, но различаются: журналы приложений и платформы помогают эксплуатационной диагностике, а SIEM передаёт очищенные с учётом конфиденциальности события аудита для анализа безопасности. Включение одной функции не делает другую резервной копией.

Владелец платформы предоставляет ёмкость ClickHouse и ограничения хранения, владельцы сервисов определяют полезные поля и классификацию данных, а владелец безопасности одобряет назначения SIEM и аутентификацию. Успех означает, что известное событие можно принять, найти, сохранить на нужный срок, сопоставить без секретов и при необходимости безопасно доставить внешнему сборщику один раз.

Назначения SIEM доставляют события аудита через долговременную исходящую очередь. Отключение SIEM приостанавливает новую доставку, но сохраняет конфигурацию назначения и исторические окончательные записи. Проверяйте подписи, повторы, идемпотентность и ёмкость получателя.

Журналы и полезная нагрузка SIEM не должны содержать пароли, токены, закрытые ключи, URI подключения к базам данных, запросы к моделям, результаты моделей или необработанные учётные данные привязок. Для сопоставления используйте идентификаторы запросов и стабильные идентификаторы ресурсов.

Решения до подключения данных

Определите, какие сервисы могут записывать события, какие поля разрешены, как долго хранятся данные, кто может выполнять поиск и какие события требуют внешнего экспорта. Оценивайте объём по числу событий в секунду, среднему размеру события и сроку хранения, а не по произвольному TTL. Более долгий срок сохраняет больше истории инцидентов, но увеличивает стоимость хранилища и последствия сбора чувствительных данных.

Осознанно выберите режим схемы:

Режим	Когда использовать	Компромисс
reject	Качество полей должно строго проверяться при приёме	Отправители должны правильно обрабатывать отклонённые события
strip	Важны известные поля, а неизвестные пользовательские данные нужно удалить	Неожиданный диагностический контекст теряется
loose	Командам нужны гибкие очищенные пользовательские поля	Управление и единообразие поиска требуют большей дисциплины

Создавайте отдельную среду журналирования для каждого приложения или значимой границы доверия. Не используйте один токен приёма для несвязанных команд: эти токены доступны только для записи и должны отзываться независимо.

Процесс структурированного журналирования

1. Включите функцию и проверьте состояние ClickHouse.
2. Создайте среду журналирования для одного приложения или границы доверия.
3. Подключите схему, если нужна валидация полей, либо осознанно используйте режим loose.
4. Задайте ограничения хранения, запросов и событий, соответствующие ожидаемому трафику.
5. Создайте токен приёма только для записи и сохраните его в менеджере секретов приложения.
6. Отправьте синтетическое событие с известными полями и идентификатором запроса.
7. Найдите событие и проверьте временную метку, важность, labels и состояние хранения.

Ограничения запросов и событий независимы. Пакетный приём может принять корректные события и отклонить некорректные элементы, поэтому клиент должен проверить структурированный ответ, а не считать весь пакет успешным.

Официальный TypeScript SDK умеет собирать события в пакеты, повторять отправку, принудительно отправлять буфер и передавать контекст трассировки или запроса для сервисов Node.js. Независимо от клиента настройте резервное поведение при временной недоступности Gateway и ограничьте локальную буферизацию, чтобы сбой журналирования не исчерпал память или диск приложения.

Хранение и ёмкость

TTL среды — только одна граница. Фоновая очистка Gateway также применяет глобальные ограничения числа строк и приблизительного объёма диска. Отслеживайте доступность ClickHouse, нагрузку слияния, рост диска, отклонённый приём и возраст самого нового события. Планируйте хранение по требованиям расследования инцидентов и соответствия нормам, а не оставляйте его неограниченным.

Отключение структурированного журналирования скрывает обычные поверхности продукта и отклоняет новые события, сохраняя данные и конфигурацию. Включайте функцию снова только после выяснения причины неисправного состояния или ограничения по тарифу.

Достаточная ёмкость — это не просто работающий процесс ClickHouse. Убедитесь, что временная метка новейшего события движется, поиск возвращает свежие данные, политика хранения удаляет старые разделы, а причины отказов приёма понятны. Gateway может приостановить приём при исчерпании настроенной ёмкости, сохранив существующий поиск; предупреждение должно появиться до достижения этой границы.

Доставка SIEM

Настройте каждый HTTPS-сборщик с самым узким поддерживаемым способом аутентификации. Проверьте доверие к сертификату, подпись запроса, идемпотентность получателя, допустимый размер пакета, поведение повторов и долговременную историю доставки. Исходящая очередь фиксирует ход доставки, поэтому временный сбой сборщика не требует вручную пересоздавать события.

Если SIEM отключён или право по тарифу потеряно, конфигурация назначения и исторические окончательные записи сохраняются. До возобновления обычной работы подтвердите последнее принятое получателем событие и возраст очереди Gateway.

Для операторов: контракт доставки SIEM

Назначения SIEM должны использовать HTTPS и могут аутентифицироваться через токен Bearer, HMAC-SHA256 или один проверенный пользовательский заголовок. Запросы HMAC содержат временную метку и подпись точного исходного тела JSON; получатель должен сравнивать подписи за постоянное время и отклонять устаревшие метки. Не помещайте учётные данные в URL, строку запроса, журналы или тестовые тикеты.

Gateway доставляет события через долговременную исходящую очередь и повторяет временные сетевые ошибки, тайм-ауты, ограничения частоты и ошибки сервера. Другие ошибки клиента могут стать окончательными. Используйте Send test event для проверки назначения; синтетический тест не создаёт событие аудита или элемент очереди доставки. Удаление назначения удаляет ожидающие строки, а отключение приостанавливает доставку до последующего возобновления.

Правила обработки данных

Определите список полей, которые приложения могут отправлять. Маскируйте данные у источника, потому что последующее хранение и экспорт увеличивают последствия утечки секрета. Используйте идентификаторы ресурсов, запросов и трассировок и ограниченные категории ошибок вместо необработанных учётных данных, запросов к моделям, дампов переменных среды или произвольных тел запросов.

Если секрет попал в журналирование, остановите дальнейшую отправку, отзовите или замените секрет у источника, ограничьте доступ к затронутой среде и следуйте принятому в организации процессу удаления данных и реагирования на инцидент. Удаление результата из интерфейса поиска не доказывает, что все сохранённые разделы, экспорты или внешние копии SIEM очищены.