На одной из конференций услышал интересный подход к организации сбора событий информационной безопасности. Обычно логи сразу направляют в SIEM, где они хранятся и обрабатываются. Но в такой схеме организация сильно зависит от конкретного вендора: сменить систему сложно, а иногда и невозможно без больших затрат.
В предложенном решении архитектура строится иначе: события сначала собираются в единый поток с помощью открытых инструментов, попадают в шину данных и только после этого передаются в SIEM. Такой подход создаёт дополнительный уровень гибкости — в любой момент можно заменить конечную систему на другую, не ломая весь процесс.
Что в итоге получает компания:
• независимость от конкретного производителя SIEM;
• возможность параллельно использовать разные аналитические инструменты;
• соответствие требованиям законодательства (в том числе 250-го указа Президента — использование отечественного ПО в сфере ИБ).
Опенсорс-решения, которые могут использоваться в такой архитектуре:
• Vector — лёгкий агент для сбора логов и метрик с серверов, контейнеров и приложений.
• Apache Kafka — распределённая шина данных, которая обеспечивает надёжную доставку событий и возможность подключать несколько потребителей.
• Elasticsearch / OpenSearch — поисковые движки и хранилища, удобные для аналитики и быстрых запросов по логам.
• ClickHouse — колоночная база данных для быстрых агрегаций и долгосрочного хранения больших объёмов событий.
• MinIO или другое S3-хранилище — надёжное место для долговременного хранения «сырых» событий в неизменяемом виде.
Но важно понимать: подобное решение требует высокой компетенции специалистов. Настроить и поддерживать связку открытых компонентов заметно сложнее, чем эксплуатировать «коробочную» систему. Если нет опытной команды, можно столкнуться с потерей событий или нестабильной работой.
Архитектура интересная и перспективная, особенно если компания хочет минимизировать зависимость от одного вендора и быть готовой к любым изменениям на рынке. Но вместе с гибкостью приходит и дополнительная ответственность, — нужен сильный штат администраторов и инженеров.
Добавить комментарий