Сообщить об ошибкеКороткий ответ
Явного единственно правильного решения по объёму и глубине такой системы нет: разумный подход — многоуровневое хранение (горячее хранилище с полным детализированным логом на короткий период для расследований, холодное дешёвое архивное хранилище на требуемый compliance-период), централизованная нормализация событий из разных источников в единый формат для SIEM, и алертинг, настроенный на небольшое число высокоуверенных правил, а не на пересылку всего потока как «алертов».
Как это работает подробнее
разные источники (аудит Kubernetes, CloudTrail, VPC Flow Logs, вывод сканеров уязвимостей) генерируют огромный объём событий в разных форматах; SIEM получает пользу только если эти события нормализованы (общие поля: кто, что, когда, откуда) и обогащены контекстом, иначе аналитик тонет в необработанном потоке. Хранение полного необработанного лога долго и дорого, поэтому применяют тиринг: дорогое индексированное хранилище для недавних данных (быстрый поиск при инциденте) и дешёвое архивное (объектное хранилище) для соответствия требованиям retention без необходимости быстрого поиска.
Сравнение
- Компромисс. максимально подробный лог и алертинг на каждое отклонение дают наилучшую видимость при расследовании, но стоят дорого в хранении и создают высокий уровень шума/усталости от алертов у команды; минималистичный подход (только критичные события, короткий retention) дешевле и проще поддерживать, но рискует не дать достаточных данных при сложном расследовании задним числом или нарушить требование регулятора по сроку хранения. Правильный баланс зависит от требований конкретного compliance-стандарта, бюджета на хранение/SIEM-лицензии и зрелости команды, способной обрабатывать алерты — нет универсального объёма логирования, подходящего всем организациям одинаково.
Что использовать на практике
- Практика. алертинг строят не на «любое подозрительное событие», а на конкретные, проверенные сценарии с низким уровнем ложных срабатываний (например, «создание нового IAM-пользователя с админ-правами вне рабочего процесса IaC», «массовое скачивание объектов из S3 нетипичным для сервиса объёмом»), остальные события доступны для ручного или retroactive поиска, но не генерируют шумные алерты по умолчанию. Retention период определяется требованиями конкретного compliance-стандарта и бюджетом.
- Проверка. Ожидаемое поведение: создание администратором нового IAM-пользователя через обычный процесс CI/Terraform не генерирует алерт, так как коррелированное событие terraform.apply присутствует в окне; ручное создание такого же пользователя напрямую через консоль/CLI в обход IaC-процесса вызывает алерт high severity — это проверяется двумя тестовыми сценариями создания пользователя и наблюдением разницы в срабатывании правила.
Подводные камни
- Ошибка. пересылать в SIEM абсолютно все доступные логи без нормализации и приоритизации, получая систему, в которой невозможно найти реальный инцидент среди шума; настраивать алерты на слишком общие условия («любое действие root/admin»), что приводит к alert fatigue и игнорированию алертов командой; хранить все данные в горячем дорогом хранилище без тиринга, что делает систему экономически неустойчивой при росте объёма логов.