Содержание

Интенсивность записи событий и выбор накопителей

Индексация данных. Влияние на производительность и требования к накопителям

Поиск и анализ. Последовательный vs случайный доступ

Объемы данных и масштабирование хранилища

Отказоустойчивость и надежность хранения

Многоуровневое хранение. Горячие, теплые, холодные и архивные данные

Типы накопителей. HDD, SSD, NVMe, SATA – плюсы и минусы

Варианты хранилищ. Локальные диски, SAN/NAS, облачные базы данных, озера данных

Разделение вычислений и хранения (Compute-Storage Separation)

Масштабы инфраструктуры. Малые, средние и крупные компании

Подходы к хранению данных в облачных SIEM

Выводы и рекомендации

У коллег весной вышла резонансная статья про особенности выбора жестких дисков для систем поиска аномалий в сетевом трафике на примере PT NAD. Я подумал, что тоже могу добавить что-нибудь в эту копилку. Тем более, что еще в 2018-м году в рамках какого-то закрытого SOC Day для заказчиков я рассказывал про особенности организации хранилищ для событий безопасности в центрах мониторинга безопасности. Пришло время сдуть пыль с архивного хранилища, дополнить его свежей кровью и выложить на суд общественности.

Итак, если коллеги рассказывали про хранение данных для систем поиска сетевых аномалий, то я буду рассуждать про решения класса SIEM (Security Information and Event Management), которые собирают и хранят огромные объемы событий безопасности и для которых правильный выбор накопителей и архитектуры хранилища (а вот про это коллеги не рассказывали, сфокусировавшись только на накопителях) критически влияет на скорость записи событий, быстроту поиска, масштабируемость и надежность всей системы мониторинга. Я попробую рассмотреть ключевые факторы, влияющие на этот выбор, – от интенсивности записи и индексации до уровней хранения и облачных решений, а также проанализирую плюсы и минусы различных вариантов, давая рекомендации под разные сценарии. И хотя в заголовке статьи упоминается только SIEM, описанные рекомендации подойдут для многих средств защиты, активно пишущих, хранящих и обрабатывающих события ИБ.

Еще одно важное замечание. Данный материал не является рекламой какого-то конкретного продукта или какого-то вендора. Поэтому любое упоминание в нем названий тех или иных решений является не более чем примером конкретного подхода к хранению и работе с данными, принятому в том или ином средстве мониторинга ИБ.

Интенсивность записи событий и выбор накопителей

Влияние интенсивности записи

Высокий поток входящих событий (EPS – events per second, событий в секунду), который так характерен для современных SIEM, предъявляет повышенные требования к производительности дисковой системы. При постоянной интенсивной записи накопитель должен обеспечивать высокую скорость операций ввода-вывода (input/output per second, IOPS) и пропускную способность. Традиционные жесткие диски HDD имеют ограниченные значения IOPS (порядка нескольких сотен) и могут стать узким местом при больших значениях EPS. Например, на форуме ArcSight (позже Micro Focus, а еще позже OpenText, признанной в России нежелательной организацией) отмечалось, что диски 7.2k HDD (7200 оборотов в секунду) подходят только для очень низких значений EPS, а для серьезной нагрузки лучше применять более быстрые 10k–15k SAS-диски или даже SSD. Как писал этот производитель – «лучше переборщить с производительностью, чем страдать от ее недостатка». Современные SSD способны выдерживать на порядки больше операций ввода/вывода (десятки тысяч IOPS и выше) и обеспечивать низкую задержку, что важно при быстрой записи множества мелких событий, которые «сыпятся» в SIEM ежесекундно.

Учёт износа и нагрузки

SSD-диски, особенно enterprise-класса, рассчитаны на большой объем перезаписи, но при экстремальных нагрузках нужно обязательно учитывать ресурс перезаписи (Terabytes Written, TBW), который может быть достигнут быстрее ожидаемого; чем он выше, тем лучше. HDD не имеют ограничений по циклам записи, но у них есть риск механического износа при непрерывной работе. А вот современные SSD обычно отказывают реже, чем HDD, так как у них нет движущихся частей, хотя могут постепенно терять емкость по мере износа ячеек памяти. Для повседневного использования обычно достаточно значения в 100-200 TBW, а вот для высоконадежных корпоративных приложений, к которым относятся и SIEM, TBW должен превышать значение 1000 (он указан в спецификации на накопитель). Превышение этого значения может привести к снижению производительности (увеличению задержек и снижению скорости записи), повышению частоты ошибок с целостностью данных и возможная их потеря.

Есть также еще такое значение, как DWPD (Data Writes Per Day, число записей в день), которое даёт более чёткое представление о том, сколько данных можно записать ежедневно, прежде чем будет достигнут предел TBW. Рассчитывается это значение по формуле:

DWPD = (TBW × 1000) / (365 × гарантийный срок (лет) × ёмкость SSD (ГБ)).

Зная, какое число событий ожидается в SIEM в сутки и какого они объема (а это зависит от числа и типа источников, можно оценивать, подойдет ли SSD для выбранной задачи или нет.

Промежуточные рекомендации

Для высокоинтенсивных потоков в десятки тысяч EPS рекомендуется использовать SSD или NVMe-накопители для зоны активной записи. Например, в практике того же Splunk (был куплен Cisco, сохранив определенную самостоятельность) для индексаторов, которые принимают входящие данные из разных источников, преобразуют их в события, сохраняют в индексах (хранилищах) и потом выполняют поиск по ним, советуют минимум 800 IOPS на хранилище, что фактически подразумевает SSD/NVMe или массив из нескольких HDD в RAID10 (про RAID и его влияние на хранение мы еще поговорим дальше). SSD/NVMe через PCIe-шину дают более высокую скорость (в 10-25 раз выше, чем по интерфейсу SATA) и могут быть оправданы, если система должна обрабатывать сотни тысяч событий в секунду с минимальными задержками (явно подходит далеко не для каждого пользователя SIEM). HDD можно применять при низкой нагрузке (малое значение EPS) или в качестве вторичного/архивного хранилища, где скорость записи не критична. В целом, лучше закладывать запас по производительности дисковой подсистемы, например, предпочесть 10k SAS или SSD, если нет уверенности в низком EPS. Это предотвратит задержки при пиковых нагрузках и потерю событий при перегрузке дисков.

Кстати, не забывайте, что количество событий в день не будет равно числу событий в секунду (EPS), умноженных на 86400 (число секунд в сутках). А всё потому, что события поступают в систему не равномерно, бывают спады, а также всплески. Например, среднее значение EPS для коммутатора Cisco составляет 5.09, пиковое – 51.88, а среднее пиковое – 26.35 (разница на порядок). Для маршрутизатора Cisco разброс будет еще больше – 0.6, 380.5 и 154.2 событий в секунду соответственно. Поэтому формула расчета событий в день учитывает число пиковых событий в день, коэффициент «про запас» (обычно 110%) и коэффициент «на вырост» (тоже 110%).

Индексация данных. Влияние на производительность и требования к накопителям

Индексация vs. простое хранение

SIEM обычно (хотя при том многообразии SIEM, присутствующих на рынке, использовать слово «обычно» не совсем и правильно) индексирует поступающие логи (выделяет поля, строит обратные индексы по ключевым словам и пр.), чтобы ускорить последующий поиск. Индексация значительно ускоряет поисковые запросы, но создает дополнительную нагрузку на CPU и диски во время записи: помимо сохранения сырого события, система записывает индексные структуры. Это приводит к увеличению объема операций ввода-вывода и требований к накопителям. При интенсивной индексации накопитель становится критичным компонентом – например, Elastic (ELK/OpenSearch) или Splunk настоятельно рекомендуют использовать именно SSD для узлов индексирования. На практике HDD при индексации дают значительно большую задержку: тесты ElasticSearch показали, что на HDD поиск и индексирование могут быть до 10 раз медленнее, с заметными скачками задержек, чем на SSD. Отсюда и рекомендация: «нетрудно понять, почему для узлов с поисковыми нагрузками рекомендуются SSD».

Объем индексов и емкость

Индексация требует дополнительного места для хранения индексных данных. Степень накладных расходов зависит от структуры логов и схемы индексирования. В некоторых SIEM индекс может занимать ~10–30% от исходного объема данных (после сжатия основного лога). Например, в Splunk сжатые сырые данные плюс индексы обычно составляют около 15% от исходного необработанного объема (благодаря сжатию сырых, raw-логов). То есть 100 ГБ необработанных логов могут в итоге занимать ~15 ГБ на диске после индексации и сжатия. Однако при обилии полей или полном тексте индекс может быть и больше. Поэтому нужно предусмотреть достаточную емкость с учетом роста индексов.

Минусы и компромиссы

Полная индексация поступивших в SIEM данных ускоряет поиск, но повышает требования к дискам и CPU. Возможен компромисс: индексировать не все данные, а только ключевые поля (остальное разбирать при запросе). Это снизит нагрузку на запись и сэкономит место, но поиски по неиндексированным полям будут медленнее (фактически последовательный перебор). Итоговое решение будет зависеть от сценария работы SOC: если аналитики часто выполняют сложные поиски по разным полям, что характерно для процессов Threat Hunting, индексировать стоит больше (и закладывать быстрые диски); если есть данные, которые редко запрашиваются (например, сохраняемые для целей соответствия требованиям регуляторов), их можно хранить почти без индексов (как «сырые» события в холодном хранилище, о которых мы еще поговорим дальше) для экономии.

Промежуточные рекомендации

При высоких требованиях к скорости поиска инвестируйте в накопители с высокими IOPS, то есть SSD/NVMe, для зоны индексирования. Убедитесь, что подсистема выдерживает параллельную запись сырых логов и индексов, – например, Splunk для полноценного индексатора рекомендует дисковую систему ~800–1200 IOPS и выше. Если бюджет ограничен (покажите мне тех, у кого он безграничен), можно ограничить индексирование менее критичных полей либо использовать гибридное хранилище: недорогой диск для сырого журнала + SSD для индексов (в некоторых решениях разделяют путь хранения индексов и сырых данных). Но такой разделяемый подход сложнее в управлении. В целом, чем больше индексируется данных, тем более быстрые и надежные диски нужны на этапе записи.

Поиск и анализ. Последовательный vs. случайный доступ

Последовательный доступ

Последовательный поиск предполагает чтение данных блочно, в порядке записи (например, простое «пролистывание» логов по времени). HDD достаточно хорошо справляются с последовательным чтением: на вращающемся диске 7200k пропускная способность может достигать ~150–200 МБ/с, и при линейном сканировании даже большой файл журналов регистрации ИБ-событий будет читаться с приемлемой скоростью. Например, если мы хотим найти среднее время отклика приложения А за последние 24 часа. Поэтому для линейного перебора больших архивов (например, экспортированных на ленту или в единый текстовый файл) HDD пригодны – их главный недостаток (долгое позиционирование головки) мало влияет, если чтение непрерывное.

Случайный доступ

Интерактивный поиск по условиям (например, найти все события с определенным IP за месяц) приводит к случайному чтению множества мелких фрагментов. Это как искать иголку в стоге сена. Здесь HDD теряют эффективность: время поиска по позиции (~5–10 мс на каждый произвольный доступ) суммируется. Даже если HDD выдаёт 200 МБ/с последовательно, при случайных чтениях в худшем случае он выполняет всего ~100–200 IOPS (операций в секунду), что эквивалентно нескольким мегабайтам случайного чтения в секунду. SSD же способны выполнять десятки тысяч IOPS с микросекундными задержками, то есть случайный доступ для них почти так же быстр, как последовательный. Практически это означает, что поисковые запросы с произвольными фильтрами выполняются на SSD/NVMe на порядки быстрее, чем на HDD. Например, поиск событий среди 80 ГБ на HDD занимает около ~4,5 с (зависит от модели), а на SSD значительно быстрее, миллисекунды, с меньшими колебаниями задержки.

Типы поисковых задач

В реальных SIEM-запросах часто комбинируются операции: сначала отфильтровать по времени (почти последовательный диапазон), затем по условию (случайные обращения к индексам/данным). Если система мониторинга заранее индексирует данные, поиск читает в основном индексы (случайный доступ) и небольшие фрагменты результатов. Если же данных много и они не индексированы, выполняется «полный скан» – для HDD это долго. Для регулярного оперативного поиска большой разницы нет – везде выиграет SSD. Однако при аналитических задачах, где нужно периодически прогонять большие объемы данных (например, построение отчетов за квартал), можно комбинировать: активные индексы на SSD, а bulk-данные на HDD с обработкой вне рабочей нагрузки.

Промежуточные рекомендации

Подход к хранению должен учитывать характер доступа.

• Недавние и часто запрашиваемые данные (например, последние 1-3 месяца) стоит держать на хранилище, оптимизированном под случайный доступ – обычно это локальные SSD/NVMe или высокопроизводительный SAN. Это «горячее» хранилище, обеспечивающее секунды или минуты на запрос.

• Архивные данные, которые обычно сканируются редко и целиком (например, для редких расследований или требований соответствия регуляторике), можно хранить на более медленном носителе (HDD, ленточная библиотека, облачный архив). Нужно понимать, что поиск по ним будет медленным (часы), но приемлемым для редких случаев.

• Смешанный доступ. Если ожидается, что даже по старым данным будут выборочные запросы, рассматривайте многоуровневую архитектуру: например, ElasticSearch ILM позволяет старые индексы держать в «замороженном» виде на объектном хранилище, но с возможностью поиска через промежуточный кэш. AWS Elastic UltraWarm хранит индексы на S3, предоставляя поиск с задержкой (секунды). Подобные гибридные подходы позволяют искать и по «холодным» данным, просто медленнее (про различные архитектуры хранилищ для SIEM мы еще поговорим дальше).

В итоге, если оперативный поиск по данным – приоритет, используйте максимально быстрые накопители. Если важнее экономия и емкость для исторических логов – их можно держать на медленном хранении, согласившись на длительное последовательное сканирование при необходимости. Хороший SIEM предлагает сквозной поиск сразу во всех зонах хранения (горячей и холодной) – это реализовано в современных платформах, хотя скорость поиска по архиву ниже.

Объемы данных и масштабирование хранилища

Рост объемов и масштабируемость

Объем логов растет с каждым годом, и требуемый период хранения тоже (регуляторы требуют от одного года до трех лет и более для ряда отраслей). Хранилище должно масштабироваться под эти объемы. Есть два подхода: вертикальный (использовать более емкие диски) и горизонтальный (распределять данные по кластерам узлов). Для малых объемов (порядка нескольких терабайт) достаточно одного сервера с необходимым RAID-массивом. Но при сотнях терабайт и выше одиночный сервер не справится по емкости или по операциям ввода/вывода – потребуется распределенное хранилище или кластер.

Горизонтальное масштабирование

Многие SIEM реализуют кластерный подход: данные распределяются между несколькими узлами. Например, Elastic Stack разбивает данные на шарды (логическое и физическое разделение индекса) по времени или другим ключам, и к ним можно добавлять узлы (со своими дисками) для увеличения и емкости, и производительности параллельно. Splunk реализует Indexer Cluster – несколько индексаторов держат реплики данных. В таком случае при росте EPS или объема данных просто добавляют новые узлы с локальным хранением.

• Плюс: линейная масштабируемость, нет строгих ограничений на общий объем (кроме бюджета).

• Минус: сложность – нужна репликация между узлами (для отказоустойчивости), балансировка запросов, управление множеством серверов.

Вертикальное масштабирование (вглубь)

Предполагает использование более крупных хранилищ: например, можно приобрести серверы с десятками дисков или подключить внешние массивы/шкафы (JBOD/SAN). Современные диски большой емкости (HDD 16-18 ТБ, SSD 7+ ТБ) позволяют разместить сотни терабайт в одном стойке. Однако рано или поздно мы упремся в предел контроллера или файловой системы. Практика показывает, что эффективно обслуживать более ~500 ТБ в рамках одного узла затруднительно – сложность бэкапа, перестройки RAID при отказе, окна обслуживания и пр. Поэтому обычно для больших объемов комбинируют подходы: кластер из узлов, каждый с емким локальным хранилищем.

Разделение по времени и данным

Для масштабирования часто применяют шардинг по времени: например, создаются ежедневные/ежемесячные индексы, и данные за каждый период могут храниться на определенном узле (или наборе узлов). Это упрощает перенос старых данных на другие носители (tiering). Также можно разделять по типам данных – например, логи Active Directory хранятся в одном кластере, сетевые потоки – в другом (если их использование сильно различается). Но такое разделение усложняет корреляцию междоменных данных.

При экстремальных объемах (петабайты) в ход идут технологии data lake или data lake house: распределенные файловые системы (HDFS), колоночные базы (ClickHouse, Hadoop-based). Например, один из отечественных SIEM использует кластер на основе СУБД ClickHouse, который масштабируется на несколько узлов и обеспечивает хранение сотен тысяч EPS в одной зоне. Он поддерживает разбиение по секциям (time partitioning) и распределенный SQL-поиск. Другой пример – Exabeam Data Lake, позволяющий хранить логи в Hadoop с масштабированием по нодам. На самом деле уже на терабайтных объемах традиционные подходы к хранению могут буксовать и переход к data lake / data lake house становится вполне оправданным.

• Плюс таких решений: практически неограниченная емкость, встроенная отказоустойчивость (за счет репликации в HDFS, например), относительно дешевые узлы.

• Минусы: сложность в настройке, часто более медленный интерактивный поиск (компромисс между глубиной хранения и скоростью запроса).

Промежуточные рекомендации

Выбор стратегии масштабирования зависит от масштабов организации.

• Малые и средние объемы (до десятков ТБ): можно обойтись одним сервером или парой серверов. Главное – предусмотреть запас емкости для реализации политики ротации данных. Например, для 5000–10000 EPS и 30 дней хранения один из простых отечественных SIEM рекомендует всего 2,5 ТБ диска и может работать в инсталляции «All-in-One» на одном сервере.

• Растущие объемы: закладывайте модульность. Лучше несколько серверов средней емкости, чем один монолит: так можно добавлять их по мере роста числа событий безопасности и скорости их поступления. Для ~30k EPS один из известных SIEMов предлагает выносить хранилище на отдельный сервер с ~14 ТБ диска, отделив его от узлов сбора/корреляции – это предотвращает деградацию сбора при «тяжелых» поисках.

• Очень большие объемы (сотни ТБ и более): рассмотрите кластеризацию. Развертывание 5–10 узлов, каждый со, скажем, 20–50 ТБ локального хранилища SSD+HDD, даст совокупно петабайтный архив. Обязательно внедряйте многоуровневое хранение (горячее/холодное) – это снижает требования к самому кластеру (не нужно, чтобы каждый узел был топовой производительности для старых данных, ненужных в реальном или близком к нему времени). Возможен подход с выносом старых данных в объектное облачное хранилище (подробнее мы поговорим об этом далее). Также не забывайте про резервное копирование: при больших объемах классический бэкап проблематичен, зачастую полагаются на репликацию или архивирование на WORM-носители.

В итоге, масштабируемость достигается сочетанием: кластеризация + tiering + правильный выбор накопителей на каждом уровне. И не забывайте планировать архитектуру с запасом – если сейчас у вас хранилище событий безопасности на 10 ТБ, то задумайтесь, что будет при 100 ТБ: как вы будете добавлять ресурсы?

Отказоустойчивость и надежность хранения

Данные SIEM часто критичны: потеря журналов безопасности может затруднить расследование инцидентов или привести к несоответствию нормативным требованиям (если для вас это актуально). Поэтому надежность хранения – ключевой фактор. Она обеспечивается на нескольких уровнях: аппаратном (стойкость самих накопителей), уровне массивов/RAID и на уровне распределения данных (репликация между узлами или в облако).

RAID и резервирование

Традиционный подход – аппаратные или программные RAID-массивы. RAID 1 (зеркало) или RAID 10 (зеркалирование + полосы) часто используются для журналов событий безопасности: они дают резерв на отказ диска и высокую скорость чтения/записи (RAID10). Например, аппаратные реализации классических SIEM (IBM Qradar или ArcSight Logger) поставлялись с RAID-массивами из HDD. Сейчас, с переходом на SSD, используются RAID-5/6 на SSD (для баланса между скоростью и отказоустойчивостью). Пример: устройство QRadar 3148 (high-end) содержит 6 SSD по ~3,84 ТБ в RAID6, обеспечивая ~13 ТБ доступного хранилища для событий.

Минус RAID: при выходе из строя диска происходит перестройка всего массива, что временно нагружает систему и может снизить производительность, особенно на больших объемах. RAID-6 и 5 также дают штраф на запись (из-за вычисления блоков чётности), поэтому для интенсивно пишущих систем, к которым и относятся SIEM, где запись событий идет непрерывно, чаще выбирают не имеющий штрафов RAID10, жертвуя объемом ради скорости и простоты.

Репликация на уровне приложения

Многие современные SIEM-кластеры дублируют данные в рамках самого приложения вместо (или дополнительно к) RAID. Например, Splunk Indexer Cluster может хранить каждое событие с репликацией (обычно 2 копии) на разных узлах. Elastic аналогично поддерживает replication factor для шард (обычно 1 реплика). Это защищает от выхода из строя целого узла.

• Плюс: даже при потере сервера данные доступны на другом за счет встроенного масштабирования.

• Минус: увеличивается общий требуемый объем (при 1 реплике – вдвое). В локальных установках можно комбинировать: каждый узел — RAID-массив (защита от сбоя диска), плюс репликация между узлами (защита от сбоя узла).

Защита от сбоев и геораспределение

Для критичных логов может потребоваться георезервирование (помните трагедию с башнями-близнецами в Нью-Йорке?) – хранение копий в другом центре обработки данных или облаке (не забывайте, что по требованиям законодательства не всегда можно использовать зарубежные облака). Это решается либо репликацией кластера между площадками, либо регулярным бэкапом/экспортом архивов в удаленное хранилище. Некоторые SIEM позволяют дублировать поступающие события в два хранилища параллельно. Например, у одного из отечественных SIEM упоминается возможность дублировать данные и разносить их территориально для надежности и использовать механизмы горячего/холодного хранения. Облачные решения, как правило, автоматически хранят данные с мультизональной отказоустойчивостью (например, Azure Log Analytics хранит копии в нескольких зонах).

Надежность накопителей

Помимо архитектурных мер, учитывается надежность самих дисков. HDD корпоративного уровня имеют больше ресурс (MTBF) и часто пролонгированную гарантию, умеют работать 24/7 под нагрузкой лучше, чем потребительские. SSD enterprise-класса характеризуются высоким DWPD (Drive Writes Per Day) – ранее уже упомянутым важным показателем количества полных перезаписей в день, которое диск выдержит на гарантийном сроке. Для SIEM с постоянной записью данных лучше выбирать SSD со значениями DWPD 1-3 и выше, чтобы износ не стал сюрпризом через год-два. Также полезна функция Power Loss Protection у enterprise-SSD (защита от сбоев питания – диск успевает сбросить данные из кэша на флеш).

Промежуточные рекомендации

• Аппаратный уровень. Используйте RAID для критичных узлов (минимум зеркало). Для больших наборов данных, где скорость критична, RAID10 из нескольких SSD или высокоскоростных HDD обеспечит и скорость, и резерв. Если бюджет ограничен, допустим RAID5/6 на SSD, но мониторьте задержки при записи.

• Кластерный уровень. При наличии нескольких узлов включайте репликацию данных между ними (RF=2). Это защищает от потери данных при падении одного сервера. Убедитесь, что реплики размещаются на узлах разных стоек/зон питания.

• Бэкапы и архивы: реализуйте регулярное резервное копирование особо важных логов (например, ежедневный дамп новых событий на ленточную библиотеку или в облачный архив). Архивирование «замороженных» данных на внешние носители – стандартная практика (в Splunk это frozen buckets – выгрузка на NAS или S3 по истечении срока оперативного хранения). Это не столько для оперативного доступа, сколько «на черный день».

• Железо. Выбирайте диски корпоративного, серверного класса. На HDD-массивах избегайте смешивания старых и новых дисков (для равномерности). На SSD следите за показателями износа. Закладывайте избыточность: например, хорошо иметь горячий резерв дисков в массиве (спаренный RAID10 или hot spare).

• Тестирование. Регулярно проводите имитацию отказа (отключение узла, диск fail), чтобы убедиться, что кластер корректно отрабатывает сбой и данные не теряются.

Надежность хранения – это баланс стоимости и риска. Для небольших внедрений RAID может быть достаточен. Для крупных – почти всегда нужна распределенная устойчивость (кластер) плюс георезерв. Не забывайте и о программной надежности, например, хранение контрольных сумм, чтобы заметить «битое» событие (некоторые SIEM при архивировании рассчитывают хэш-значения логов для контроля целостности).

Многоуровневое хранение. Горячие, теплые, холодные и архивные данные

Концепция tiered storage

Многоуровневое (tiered) хранение подразумевает разделение данных по уровням в зависимости от их «возраста» и требований к скорости доступа.

• Горячие данные – недавние, активно используемые логи, хранятся на самом быстром (и дорогом) накопителе, с минимальной задержкой доступа.

• Теплые данные – промежуточный уровень: уже не самые новые данные, но они все еще могут запрашиваться относительно часто; их можно держать на средних по скорости дисках.

• Холодные данные – старые логи, которые нужны редко (например, для аудита или по запросу) – выносятся на дешевое и медленное хранилище, возможно сжатое.

• Архив – совсем старые данные, возможно, хранятся офлайн или в виде резервных копий (вне основной системы SIEM), доступны только после специального восстановления.

Реализации в SIEM

Практически все крупные SIEM поддерживают такую иерархию. Например, Splunk делит индексы на hot, warm, cold, frozen: горячие и теплые хранятся вместе (на быстром диске), cold – на более медленном локальном или сетевом диске, frozen – выгружаются вовне (например, на S3 или в архив). Elastic (ELK) имеет схожий подход через ILM (Index Lifecycle Management): можно задать политику, что новые индексы хранятся на узлах с SSD (hot nodes), после 7 дней переводятся на warm-узлы (например, с HDD или более дешевым облачным диском), затем через месяц – на cold (может быть даже в виде snapshot на S3), и далее удаляются. LogRhythm вводит четыре уровня: Hot (SSD, 30-90 дней), Ultra-Warm (HDD, до ~180 дней), Warm (HDD, до года) с постепенно более медленным поиском, и Cold (архив с сильным сжатием на HDD, удерживается неограниченно, но поиск занимает часы).

Плюсы tiering

Главное преимущество – оптимизация затрат при сохранении достаточной доступности. Держать все данные на дорогих NVMe-накопителях неэкономично, если 90% запросов обращаются только к последнему месяцу логов. Разделение позволяет использовать быстрые диски под «активный» диапазон, а большие емкие – под историю. Например, можно хранить 90 дней на SSD (обеспечивая секунды на поиски), а всё, что старше – на SATA HDD или в облаке, где поиск займет минуты, что приемлемо. Это даёт огромное снижение стоимости хранения за ТБ. Кроме того, исключается конкуренция нагрузок: запросы по старым данным не будут сильно влиять на производительность работы с горячими данными, если физически вынесены на другой носитель или узел.

Минусы и сложности

Многоуровневое хранение добавляет сложности в управление и архитектуру SIEM или всего центра мониторинга ИБ: нужно настраивать политику перемещения данных (ролловеров индексов, архивирование), следить, чтобы поиск «знал», где и какие данные размещаются. Запросы, перекрывающие несколько уровней, выполняются по самому медленному из них – аналитик может столкнуться с непредсказуемым временем ответа, особенно если диапазон захватывает архив. Также холодные архивы обычно хранятся в сжатом виде (например, LogRhythm Cold tier сжимает по алгоритму GZIP с коэффициентом ~10:1 ), а значит их нужно развернуть перед поиском. Если архив вынесен внешне (на ленточный или облачный), то при запросе может потребоваться вообще загрузить обратно большой объем – это займет часы или даже дни. Поэтому важно четко разграничить: оперативный поиск – по горячему/теплому, исторический аудит – планировать время на поднятие данных из архива.

Промежуточные рекомендации

• Горячий уровень – хранить на SSD/NVMe, объем – в зависимости от требований SOC-аналитиков, обычно 1-3 месяца. Например, Microsoft Sentinel по умолчанию держит 90 дней в «hot cache» для быстрого KQL-поиска . Splunk часто настраивают hot+warm на 30-90 дней на локальных SSD. Убедитесь, что горячий слой реплицирован или отказоустойчив, ведь это самые важные данные в работе.

• Теплый уровень – можно использовать более емкие, но еще приемлемо быстрые накопители. Это может быть SATA SSD или гибрид, либо 10k SAS HDD, либо сетевое хранилище неплохой производительности. Цель – удлинить срок ротации в онлайн-доступе без сильной потери скорости. Например, Elastic рекомендует warm-ноды на более дешевых SSD или даже HDD; LogRhythm Ultra-Warm/Warm – на HDD с 7200 об/мин, поиск – от секунд до минут. Хороший компромисс – warm-данные держать с одним репликой (если кластер), а hot – с двумя, для экономии.

• Холодный уровень – здесь ставится во главу угла стоимость хранения. Отличный вариант – облачные объекты или дешевые диски. Данные сильно сжимаются, могут агрегироваться. Поиск по ним должен быть возможен, но медленный. Например, Sentinel использует Azure Data Lake Storage для cold-данных до 2 лет; один из отечественных SIEM позволяет выносить данные на «недорогие диски» с холодным хранилищем, где поиск есть, но медленнее. При организации холодного слоя убедитесь, что метаданные (каталоги) все еще доступны SIEM – иногда применяют механизм «вторичного поиска» (например, Elastic Frozen tier требует загрузки снапшота).

• Архив/уровень заморозки – данные, хранящиеся дольше срока, требуемого для работы с ними в реальном или близком к нему времени, можно выгружать во внешнее хранилище и удалять из системы. Например, после 1-2 лет журналы регистрации сохраняются в виде файлов на ленте или долгосрочном облачном архиве (Amazon Glacier, Azure Archive). Здесь упор на максимальную экономию и долговечность хранения (WORM-модели, соответствие регуляторным требованиям). По сути, архив – это бэкап: прямого поиска нет, сначала нужно вернуть данные в систему (разморозить). Такой уровень нужен, если требование хранения 5-7 и более лет, но нет необходимости оперативно искать настолько старые события. Планируйте процессы восстановления из архива и тестируйте их. В качестве отвлечения – в рамках одного из расследований инцидента специалисты Positive Technologies обнаружили, что хакеры сидели в инфраструктуре 11 (!) лет.

Примеры реализации уровней в разных SIEM

Splunk – классический пример внедрения tiering: горячие/теплые «корзины» на быстрых дисках (часто SSD), холодные «корзины» на более медленных дисках или NFS (существует параметр отдельного пути для cold), а замороженные – например, выгрузка на S3 или HDFS внешне. Elastic – hot/warm/cold-архитектура (как у Elastic Cloud: hot – SSD, warm – более дешевые, cold – через searchable snapshots на S3). Microsoft Sentinel на стороне Microsoft применяет внутреннее tiering: hot в Log Analytics, warm в Azure Data Explorer, cold в Data Lake, причем пользователь платит меньше за холодные данные, но запросы к ним немного дороже и медленнее. Один из отечественных SIEM прямо указывает, что благодаря горячему/холодному хранилищу удается хранить данные долго без взрывного роста стоимости – администратор может задать, что, к примеру, спустя 1 день данные переводятся на холодное хранение на дешевых дисках.

Итого: используйте многоуровневое хранение, если объем логов велик или требования к разному «возрасту» данных различаются. Это позволит соблюсти баланс между скоростью (на горячих данных) и стоимостью (для хранения истории). Но тщательно документируйте политики ротации и убедитесь, что вы или служба ИБ (смотря кто отвечает за инфраструктуру SIEM или SOC), знакомы с тем, какие данные доступны сразу, а какие требуют времени на подъем – это управляет ожиданиями при расследованиях.

Типы накопителей. HDD, SSD, NVMe, SATA – плюсы и минусы

HDD (жесткие диски)

Классические магнитные диски с вращающимися пластинами.

• Плюсы. Очень низкая стоимость за объем – HDD емкостью 8–16 ТБ доступны и отработаны годами. Хорошо подходят для последовательных записи/чтения больших объемов (бэкапы, архивы). Долговременное хранение на отключенном HDD возможно (в отличие от SSD, где слишком долгий простой может привести к потере заряда ячеек – хотя эксперты регулярно это оспаривают).

• Минусы. Медленный случайный доступ (в сотни раз медленнее SSD по IOPS). Высокая задержка ~5-10 мс на операцию. Ограниченная способность к параллельной работе – один диск обслуживает ограниченное число потоков. Больший физический размер и энергопотребление на единицу данных. Склонность к механическим отказам (износ шпинделя, головок) – хотя средний срок службы enterprise-HDD тоже измеряется годами, они боятся ударов, вибрации. Для SIEM с HDD часто приходится составлять RAID из многих дисков, чтобы добиться приемлемых IOPS и пропускной способности. Например, для достижения ~800 IOPS могут понадобиться ~8 дисков 7200RPM в RAID10.

SSD (твердотельные SATA/SAS)

Накопители на флеш-памяти, подключаемые по интерфейсу SATA (6 Гбит/c) или SAS (12 Гбит/с).

• Плюсы. Очень быстрый доступ (0.1 мс), высокая устойчивость к случайным нагрузкам. IOPS в десятки и сотни тысяч (даже бюджетные SATA SSD дают 50k+ IOPS, enterprise – больше). Высокая скорость последовательного чтения/записи ~500 МБ/c на SATA (упирается в пропускную способность интерфейса). Нет механических частей – не боятся вибраций, меньше тепла. Компактнее (2.5” форм-фактор легко размещается в серверах).

• Минусы. Цена за ГБ выше, чем у HDD (хотя за последние годы сильно снизилась, но HDD всё еще дешевле примерно в 3-5 раз на объемы в десятки ТБ). Ограниченный ресурс записи – флеш-память изнашивается. Для нагрузок SIEM важно выбирать SSD с высоким ресурсом (DWPD), иначе диск может израсходовать ресурс за несколько лет интенсивной записи. Также производительность SSD может деградировать по мере заполнения (если диск переполнен, замедляется очистка блоков) – рекомендуется иметь запас (over-provisioning, свободное место). SATA-интерфейс ограничивает максимум ~100k–200k IOPS и 600 МБ/с даже у лучших SSD, что ниже возможностей самой флеш-памяти.

NVMe SSD

Это твердотельные накопители, общающиеся по протоколу NVMe через шину PCI Express. Обычно это форм-фактор M.2 или U.2/U.3 в серверах.

• Плюсы. Максимальная производительность. NVMe-протокол разработан специально для SSD, без ограничений SATA. На PCIe x4 Gen3 диски дают до ~3.5 ГБ/с, на Gen4 – до 7–8 ГБ/с. IOPS превышают 1 миллион. Параллелизм – поддерживаются тысячи очередей, что актуально для многопоточных SIEM нагрузок. NVMe-накопители сильно опережают SATA: как отмечает Kingston, NVMe обеспечивает «в 25 раз большую пропускную способность, чем SATA, и команды выполняются в 2 раза быстрее за счет низких задержек». NVMe-диски имеют низкие задержки, практически устраняют узкое место хранения в средних инсталляциях (обычно упираются уже в CPU или сеть).

• Минусы. Цена за ГБ пока самая высокая среди распространенных накопителей (хотя разница с SATA SSD сократилась). NVMe требовательны к охлаждению – при интенсивной работе выделяют тепло, могут троттлить (снижать скорость при перегреве) без достаточного обдува. Вместимость NVMe-SSD пока чуть меньше, хотя есть модели 15-30 ТБ, но они дорогие. Не все серверы поддерживают много NVMe-дисков: часто нужно наличие свободных PCIe-слотов или разъемов U.2, что может ограничить масштабирование. Тем не менее, NVMe быстро становится новым стандартом – даже SATA SSD все чаще заменяются NVMe (через U.2 или EDSFF накопители).

SATA vs SAS vs NVMe

SATA и SAS – интерфейсы для подключения дисков. SAS чуть надежнее, допускает двухпортовое подключение (важно в корпоративных массивах) и имеет выше пропускную способность (12 ГБит/с ~ 1.2 ГБ/с теоретически). Но по сути SATA SSD и SAS SSD на одинаковой флеш памяти не сильно отличаются в IOPS (SAS может дать небольшой прирост и лучшую очередность). NVMe же кардинально превосходит по шине. Таким образом, сравнительный порядок: HDD – дешевая емкость, но низкие IOPS; SATA/SAS SSD – быстрые, для большинства случаев SIEM достаточно, баланс цены и скорости; NVMe SSD – для максимальных нагрузок и будущего запаса, дороже.

Численные ориентиры (порядок величин) по производительности:

• Типичный 7.2k HDD: ~100 IOPS (случайное обращение к диску) , ~150 МБ/с (последовательно). 15k HDD: до 200–250 IOPS.

• SATA SSD: ~90k–100k IOPS, 500 MБ/с (последовательно), обычно не больше 6 ГБит/с).

• NVMe SSD: >1,000k (1 млн) IOPS на топовых моделях, 3000+ МБ/с (последовательно).

• Задержки: HDD ~5 мс, SATA SSD ~0.1 мс, NVMe ~0.02 мс (в некоторых случаях).

Эти различия объясняют, почему рекомендуется использовать SSD для поисковых задач в SIEM – выигрыш может составлять порядок величины и более.

Численные ориентиры (порядок величин) по цене

Сравнивать решения по цене – занятие неблагодарное, особенно сейчас и в России, где цена на многую электронику выше, чем те же устройства можно было бы купить на Западе или Востоке. Но чтобы доказать тезис о том, что HDD все еще дешевле SSD, приведу приблизительные диапазоны цен на накопители в пересчете за 1 ТБ:

• HDD:

  • Для холодных данных/архивов: Потребительские модели большой ёмкости (8-16 ТБ и более) являются самыми экономичными. Цена за 1 ТБ для них может находиться в диапазоне от 1 500 до 3 000 рублей.

  • Для горячих/тёплых данных: Серверные HDD (7200, 10k, 15k RPM) дороже, но предлагают большую надёжность и производительность. Цена за 1 ТБ может варьироваться от 3 000 до 10 000 рублей и выше, в зависимости от ёмкости и скорости.

• SATA SSD. SSD-накопители дороже HDD, но гораздо быстрее, особенно при случайном доступе. Их цена за 1 ТБ обычно находится в диапазоне от 7 000 до 15 000 рублей. Серверные SATA SSD, предназначенные для круглосуточной работы, могут стоить дороже.

• NVMe SSD. Это самые дорогие, но и самые производительные накопители. Они обеспечивают максимальную скорость и низкие задержки, превосходя SATA в разы. Цена за 1 ТБ для них начинается примерно от 10 000 рублей и может достигать 20 000 рублей и более для enterprise-моделей с высоким ресурсом перезаписи (DWPD).

• Облачные объектные хранилища (холодное хранение). Стоимость хранения в облаках рассчитывается по модели OPEX (операционные расходы) и обычно указывается за ГБ в месяц. Цена за 1 ТБ в месяц в холодных классах хранения (например, Amazon S3 Glacier, Azure Archive) составляет всего несколько сотен рублей. Для примера, цена за хранение 1 ТБ в месяц в российских облаках может составлять от 100 до 1 500 рублей в зависимости от класса хранения и провайдера. Важно помнить, что к этой стоимости могут добавляться плата за запросы и исходящий трафик, особенно если данные часто запрашиваются.

Гибридные варианты

Существуют также гибридные HDD (SSHD) – с маленьким NAND-кэшем, и решения, где SSD используются как cache перед HDD массивом (например, tiered storage в SAN – «auto-tiering»). Такие системы могут давать часть преимуществ SSD, прозрачно подменяя часто запрашиваемые блоки из HDD на SSD-кэш. Однако в контексте SIEM это применяется редко, т.к. сценарий доступа нетривиальный (большинство SAN настроены под блоки, а не под логические записи логов). Более уместно вручную разделять данные на уровни и размещать на нужных носителях, чем полагаться на автоматический tiering контроллера.

Промежуточные рекомендации по выбору дисков

• Для горячего хранения и индексаторов: SSD однозначно. Если бюджет позволяет – NVMe (особенно в масштабах >30k EPS или при плотной виртуализации). На NVMe-массиве вы «спите спокойно» даже при всплесках запросов. Если NVMe дорого или нет поддержки – берите enterprise SATA/SAS SSD (несколько штук в RAID10, чтобы нарастить IOPS и объем).

• Для теплого хранения: можно использовать более емкие SATA SSD или даже высокообортные HDD. Например, ряд SIEM-решений использует HDD на теплом уровне, поскольку поиск в таких данных осуществляется реже и допустимо, чтобы он занимал несколько минут, а не секунд. В LogRhythm warm-tier рассчитан на HDD и поиск в течение минут. Здесь можно экономить – использовать существующие SAN или большие RAID6 массивы.

• Для холодного хранения: ориентир – цена за ТБ. Большие SATA HDD идеально подходят, особенно в сочетании со сжатием. Также могут применяться ленточные библиотеки (LTO) или облачные «холодные» классы хранения (Glacier, Azure Archive), но это, скорее, архив. Если холодный уровень все же подразумевает онлайн-доступ (пусть и медленный), лучше выбрать большие HDD в недорогом сервере или NAS.

• Интерфейс: в новых внедрениях, по возможности, избегайте устаревших интерфейсов. NVMe – приоритет, SATA SSD – только если инфраструктура не готова к NVMe. HDD обычно SAS или SATA не столь важно, важнее RPM (10-15k лучше, чем 7,2k). Если есть SAN с FibreChannel/iSCSI – убедитесь, что бэкэнд SAN способен на нужные IOPS (часто SAN на HDD не дадут выигрыша, лучше локальные SSD).

• Учет нагрузки: если логов очень много, можно распределять типы накопителей по ролям: например, отдельно вынести дисковый массив под индекс (SSD RAID), а raw-логи складывать параллельно на HDD (как вариант). Но обычно так не делают вне очень специфичных случаев – SIEM-платформы сами научились оптимизировать решение этой задачи.

В целом, тренд таков, что SSD и флеш вытесняют HDD для активных данных SIEM. Многие современные устройства полностью перешли на SSD (QRadar, Splunk appliance и т.д.). HDD остаются актуальны в ролях архивов и холодного хранения. NVMe по мере удешевления станет стандартом и для средних решений – уже сейчас разница в цене оправдана экономией на масштабировании (например, вместо 10 серверов с SATA SSD можно поставить 5 с NVMe, получив ту же производительность). Поэтому при проектировании на перспективу старайтесь закладывать именно флеш-хранилища для «горячих» задач, а «механические» – только там, где нужно много дешевого места.

Варианты хранилищ. Локальные диски, SAN/NAS, облачные базы данных, озера данных

Локальное хранение (DAS – Direct Attached Storage)

Когда диски напрямую подключены к серверу SIEM (внутренние или через прямой JBOD).

• Плюсы. Максимальная производительность – данные поступают прямо на сервер, минуя сетевые накладные расходы. Минимальная задержка, полный контроль со стороны приложения (можно напрямую настроить файловую систему, нет посредников). Проще конфигурация – не требуется дорогого внешнего хранилища. Локальные NVMe/SSD сейчас доминируют в высокопроизводительных кластерах SIEM (Elastic, Splunk) – каждый узел имеет свое хранилище, а отказоустойчивость достигается репликацией на уровне приложения.

• Минусы. Ограниченная масштабируемость одним узлом – сервер имеет физические слоты под диски, сколько поместилось – столько и есть. Если нужно расширить емкость, приходится добавлять еще один сервер (что и предполагается в горизонтальном масштабировании). Резервирование – если сервер падает, доступ к его дискам пропадает (поэтому нужна репликация на уровне кластера или внешних бэкапов). Также подводный камень – использование локальных дисков усложняет единый поиск, если у вас несколько отдельных SIEM-инстансов (но кластерные решения это решают).

Сетевое хранилище SAN

SAN (Storage Area Network) – подключение блочного устройства хранения по сети (iSCSI, Fibre Channel). Например, отдельная дисковая полка или all-flash массив, предоставляющая LUN (логический/виртуальный том) серверам.

• Плюсы. Масштабируемость – можно нарастить объем независимо от серверов, просто докупив дисков в массив. Централизованное управление – RAID, снапшоты, дедупликация и прочие функции на стороне SAN. Можно нескольким серверам дать доступ к одному хранилищу (хотя для SIEM нечасто нужно параллельное использование). В больших ЦОДах SAN – привычная инфраструктура, позволяющая, например, быстро перераспределить свободное место между приложениями.

• Минусы. Стоимость – хорошие SAN очень дороги (контроллеры, лицензионные опции). Задержки – хоть FibreChannel и быстрый, добавляется ~0.5-1 мс на передачу + возможные прослойки. Подверженность узким местам: общая шина SAN при перегрузке одним приложением (SIEM) может влиять на другие. Требует квалификации для обслуживания. В контексте SIEM, SAN часто не рекомендуют для горячих данных, если только это не специализированный all-flash SAN. Splunk, например, поддерживает SAN, но указывает минимальные IOPS (800+) и предупреждает о рисках, что SAN может не дать стабильной скорости. Если SAN используется, то лучше выделенный под SIEM-нагрузку, или с QoS.

NAS (сетевое файловое хранилище)

Предоставляет доступ на уровне файловой системы (NFS, CIFS).

• Плюсы. Легкость подключения – по сути смонтировал как папку. Удобно для хранения архивов, резервных копий, больших экспортных файлов. Можно расширять емкость прозрачно.

• Минусы. Производительность NFS/SMB обычно ниже блочного SAN. Протоколы не всегда хорошо работают под нагрузкой множества мелких операций (высокий overhead, проблемы кеширования). Большинство SIEM не используют NAS для горячих данных из-за этого. Однако NAS часто применяют для cold/archive уровня – например, хранение «замороженных» корзин Splunk на NFS. Надежность тоже зависит от сети. Были случаи, когда сбой NFS приводил к зависанию индексаторов Splunk , что критично. Поэтому NAS – только для архивов или в сценариях с небольшой нагрузкой.

Облачные базы данных / хранилища

Все чаще SIEM предлагают опцию хранить данные в облачной среде: будь то облачная СУБД, объектное хранилище или специализированное хранилище логов.

• Плюсы. Не нужно заботиться об инфраструктуре – провайдер (AWS / Azure / GCP / Яндекс / Cloud.ru / K2 Облако и т.п.) отвечает за надежность, масштабирование. Легко увеличить срок хранения: просто покупаете больше места (или оно автоматически масштабируется). Практически все облачные решения имеют встроенную репликацию и резервирование (мульти-AZ хранение), обеспечивая высокую отказоустойчивость без усилий со стороны клиента. Кроме того, облачные хранилища позволяют эластично масштабировать производительность – например, увеличить пропускную способность запросов, добавив вычислительные ресурсы.

• Минусы. Стоимость и скорость доступа. Облачные провайдеры берут плату за объем хранения и за операции/трафик (особенно при выходе данных). Интерактивный анализ больших объемов может быть дорог, если каждый запрос перечитывает гигабайты из S3 (плата за запросы и выгрузку). Но вновь стоит упомянуть, что в условиях возросшей конкуренции цены на облачные хранилища постоянно снижаются и, в ряде случаев, может быть даже так, что при переносе всей инфраструктуры обработки событий в облако она может оказаться дешевле подключения накопителей в on-prem-инфраструктуре (но экономику надо считать с калькулятором в руках). Задержки – доступ к облачным данным может быть чуть медленнее, чем к локальным (но в пределах миллисекунд или их десятков, если тот же регион). Ограниченный контроль: вы зависите от решений провайдера – если у Azure Log Analytics задержка, вы мало что сделаете. Также есть вопросы регуляторики – не все компании могут хранить чувствительные логи в публичном облаке. Ну и не стоит забывать про санкционную тематику в современном геополитическом окружении. Уход иностранных облаков из России не забудут еще долго.

Варианты облачных хранилищ в контексте SIEM

• Облачные Data Lake / Object Storage. Например, AWS S3, Azure Data Lake, Google Cloud Storage. Часто используются для холодного хранения. В них данные хранить дешевле, но для поиска нужно либо выгружать в анализатор, либо использовать технологии типа Amazon Athena (SQL по S3) или Azure Data Explorer, который поверх данных в ADLS. Пример: Sentinel автоматически может перемещать логи в Azure Data Lake (более дешевый уровень хранения) и уже там искать через внешние таблицы.

  • Плюс: крайне дешево в пересчете на ГБ*месяц, практически бесконечная масштабируемость.

  • Минус: скорость запросов ниже, сложные корреляции делаются сложнее, что частично решается кэшем (это не про деньги).

• Облачные аналитические базы (managed). Это сервисы как Azure Data Explorer (Kusto), Amazon OpenSearch/Splunk Cloud, Snowflake и др. Они предоставляют полностью управляемый движок, заточенный под большие данные. Например, Chronicle (Google Cloud SIEM) построен на собственной колоночной базе, которая хранит годы логов и обеспечивает поиск за секунды, абстрагируясь от инфраструктуры. Snowflake – облачный data warehouse, некоторые организации выгружают в него логи для исторического анализа (он хорошо сжимает и относительно быстро выполняет SQL-запросы).

  • Плюс: высокоуровневый интерфейс (SQL/KQL), провайдер оптимизирует под капотом (кэш, индексы).

  • Минус: стоимость вычислений – такие сервисы дорогие при постоянных запросах, обычно выгодны для ad-hoc анализа.

• Специализированные облачные хранилища логов ИБ. Например, Sumo Logic, Splunk Cloud, Devo, Elastic Cloud – вы отправляете логи и платите за хранение и поиск, а они используют собственные оптимизированные хранилища (чаще всего под капотом либо S3 + вычисления, либо собственные колоночные СУБД). Про такие решения я уже писал в прошлом году и поэтому повторяться не буду.

  • Плюс: все прозрачно для пользователя, он просто ищет через знакомый интерфейс.

  • Минус: менее гибко в настройке специфики (но для большинства это приемлемо).

Озера данных (Data Lakes) и новые форматы

Тут речь о хранении событий в виде файлов (например, Apache Parquet или ORC) на распределенном хранилище с возможностью последующего анализа инструментами больших данных. Идея заключается в использовании недорогого «озера» (HDFS или облачного хранилища) и «подвозе» к нему вычислений по необходимости (Spark, Trino, Presto). Проекты вроде Apache Iceberg, Delta Lake дают возможность вести таблицы событий на объектном хранилище, обновлять их, и использовать SQL-движки. SIEM пока редко полностью строят на таких технологиях, но движение в эту сторону идет. Например, Splunk реализовал концепцию SmartStore – горячие данные на локальном диске, а основной объем индексов в S3 (подкачиваются по требованию). Это фактически гибрид локального кеша и озера данных. Для очень больших организаций возможно построение собственных озер для логов, а SIEM выполняет роль «корреляции и интерфейса» поверх (например, хранить сырые логи в Hadoop, а в SIEM загружать результаты агрегатов). Однако это сложный путь, оправданный редко (чаще проще воспользоваться готовыми облачными SIEM с подобным бэкендом).

Локальное vs. Облако – решение

Если компания уже имеет мощную on-prem инфраструктуру (SAN, сервера) и внутренние или внешние ограничения по безопасности и приватности, локальное хранение предпочтительно, но нужно тщательно спроектировать масштабируемость (кластер, резервы, рост). Облако привлекательно для малых и средних компаний (не надо больших капиталовложений на железо, оплата по использованию) и для тех, кому нужен глобальный масштаб без дополнительной возни. Например, LimaCharlie – облачная SecOps платформа – дает 1 год хранения телеметрии бесплатно, реализуя хранилище и поиск на базе GCP (Google Cloud). Пользователь избавлен от забот о дисках и выборе их типа – он просто ищет нужные события по годовым логам, а провайдер (LimaCharlie) под капотом использует масштабируемую платформу (возможно, BigQuery или аналог). Microsoft Sentinel – другой пример: в Azure автоматически масштабируется Log Analytics Workspace, хранящий данные (на самом деле, у Microsoft это Kusto-кластера + Azure-блобы). Пользователь платит за объем и не думает о том, HDD или SSD там используются – хотя косвенно это отражается на цене горячих vs. архивных данных.

SAN/NAS vs DAS

Практика показывает, что для чувствительных к производительности систем (а SIEM именно такая) DAS или кластер с локальными дисками чаще предпочтительнее SAN/NAS, если нет специфичной причины. В официальном блоге одного из SIEM-вендоров отмечается: «подсистема хранения должна иметь высокую производительность и масштабируемость, поддерживать сквозной поиск по горячему и холодному хранилищу» – проще этого достичь на распределенном кластере с локальными дисками или специализированном высокоскоростном хранилище, чем на общем NAS. SAN могут быть эффективны, особенно если это флеш-массив, но важно удостовериться, что он гарантирует нужные IOPS. В тех случаях, когда уже сделаны инвестиции в SAN, можно его задействовать как warm/cold слой или под базу корреляции, но горячие данные (индексы) целесообразно держать локально на сервере SIEM.

Разделение вычислений и хранения (Compute-Storage Separation)

Традиционные архитектуры SIEM предполагали тесную связь между вычислительными ресурсами (CPU/RAM) и хранилищем данных. Каждый узел кластера был самодостаточным: он индексировал данные, хранил их на локальных дисках и выполнял поисковые запросы. Такой подход эффективен, пока объёмы данных не достигают петабайтных масштабов (а иногда даже и на меньших объемах), где его недостатки становятся очевидными:

1. Высокая стоимость. Хранение терабайтов и петабайтов данных на высокопроизводительных SSD/NVMe-дисках становится непомерно дорогим.

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

3. Сложность масштабирования. Чтобы добавить хранилище, необходимо масштабировать весь вычислительный узел, даже если в этом нет необходимости.

В ответ на эти вызовы была разработана архитектура разделения вычислений и хранения (Compute-Storage Separation). Суть подхода заключается в том, что вычислительные узлы (индексаторы и поисковые головы) и хранилище данных становятся независимыми компонентами.

Как это работает на практике?

• Горячее хранение. Небольшой объем данных (например, за последние 7-14 дней), которые активно записываются и часто запрашиваются, по-прежнему хранятся на быстрых локальных дисках вычислительных узлов (SSD/NVMe). Это обеспечивает минимальную задержку для самых частых операций.

• Холодное/архивное хранение. Основной объём исторических данных, которые нужны для редких запросов или долговременного анализа, переносится в централизованное объектное хранилище. Это может быть локальное S3-совместимое хранилище (например, MinIO) или облачные сервисы (Amazon S3, Google Cloud Storage, Azure Blob Storage).

Когда пользователь выполняет поисковый запрос, SIEM-система сначала проверяет локальное, быстрое хранилище. Если данные не найдены, она автоматически обращается к централизованному объектному хранилищу. Вычислительные узлы «забирают» только те данные, которые необходимы для выполнения запроса, обрабатывают их и возвращают результат. Таким образом, они не хранят все данные у себя, а используют объектное хранилище как «единое озеро» данных.

Преимущества архитектуры

• Значительное снижение TCO (Total Cost of Ownership). Стоимость хранения данных в объектном хранилище может быть в 5-10 раз ниже, чем на локальных SSD.

• Гибкое масштабирование. Вы можете независимо масштабировать вычислительные ресурсы и ёмкость хранилища. Если вам нужно больше производительности, вы добавляете узлы-индексаторы. Если вам нужно больше места для данных – просто увеличиваете объём в объектном хранилище.

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

Примеры реализации

• Splunk SmartStore. Это классический пример данной архитектуры. SmartStore позволяет разнести вычислительные ресурсы (индексаторы и поисковые узлы) и хранилище данных. Индексаторы Splunk хранят на локальных дисках только «горячие» и «тёплые» данные, а основной объём переносит в S3-совместимое хранилище, которое Splunk называет удаленным хранилищем.

• Elasticsearch с Searchable Snapshots. Эта функция позволяет проводить поиск по данным, которые хранятся в «snapshots» (снимках), расположенных в S3-совместимом хранилище. Это идеальное решение для доступа к архивным данным без необходимости их восстановления на локальные диски кластера.

• Кастомные решения. При внедрении SIEM-системы на базе OpenSearch или ClickHouse можно вручную настроить подобную архитектуру, используя локальные диски для «горячих» данных и объектные хранилища для «холодных», управляя перемещением данных через политики их жизненного цикла.

Таким образом, разделение вычислений и хранения — это современный и экономически эффективный подход, который позволяет построить масштабируемую SIEM-платформу, способную обрабатывать и хранить петабайты данных без неоправданно высоких затрат.

Промежуточные рекомендации

• Локальные SSD/NVMe – выбор №1 для высокопроизводительного поиска и хранения активных данных. Проектируйте кластер с распределением данных между узлами, вместо шардинга на уровне SAN.

• SAN – использовать, если он предоставляет гарантированную производительность (например, all-flash SAN) и если нужна централизованность. Он может хорошо подойти для корпоративных сред, где SIEM – одна из многих систем на общей инфраструктуре хранения. Тогда следите за QoS и выделенными пулами.

• NAS – в основном для резервных копий и архивов. Либо для маленьких внедрений, где, скажем, хочется просто хранить логи на существующем файловом сервере – но тогда не ожидайте высокой скорости поиска.

• Облачные хранилища – отличное решение для распределенных компаний (где события приходят из разных филиалов – удобнее сразу в облако, чтобы не тащить централизованно) и для тех, кто хочет уменьшить операционную сложность. Если выбираете облачный SIEM – фактически вы отдаете вопрос выбора накопителей на откуп провайдеру, но вы все равно должны понимать уровни (хотя бы на уровне тарифа: часто «горячее хранение 3 месяца включено, холодное – отдельно в объектное хранилище»). В частном облаке (self-hosted в AWS/Azure) вы можете сами строить нужную схему, например, поднять кластер Elastic на EC2 с EBS-томами (SSD) для горячего хранения, а старые индексы складывать на S3 – это аналог DAS+объектное хранилище, но в облаке.

• Data Lake – рассматривать как дополнительный архивный слой или для очень специфичных сценариев с большими данными. Прямо строить SIEM только на Spark/S3 – риск замедлить расследования. Лучше гибрид: основное – поиск в SIEM, а огромные исторические данные – параллельно складывать в data lake для больших аналитических задач (например, ML по годам логов и т.п.).

Иными словами, каждый тип хранилища имеет свою нишу: локальные диски – скорость; SAN – удобство в традиционных ЦОДах; облако – масштаб и минимальная административная нагрузка; data lake – долгий архив/анализ больших данных. Чаще всего в современном проекте SIEM сочетаются сразу несколько схем: например, локальный SSD-кластер для 90 дней, автоматический экспорт старше 90 дней на S3 (облако) для хранения данных около года, и бэкап раз в квартал на ленту для архивирования на 3+ лет. Выбор зависит от приоритетов организации (CAPEX vs. OPEX, требования по соответствию, наличие экспертизы и т.п.).

Масштабы инфраструктуры. Малые, средние и крупные компании

Малые компании (несколько сотен сотрудников, 1000–5000 EPS)

Часто имеют ограниченные бюджеты и штат (вообще их имеют все, но у маленьких это прям совсем проблема). Для них важна простота и низкая стоимость, при достаточном покрытии нужд в области мониторинга. Возможное решение:

• Аппаратно. Можно развернуть SIEM на одном сервере (all-in-one). Как упоминалось выше, многие SIEM «начального уровня» допускают 5000–10000 EPS на одном узле с 16 CPU, 32 ГБ RAM, 2.5 ТБ диска (но все зависит от производителя SIEM). Такой сервер (физический или виртуальный) с парой SSD в RAID1 покрывает 1–3 месяца хранения.

• Хранилище. Либо пара быстрых дисков локально, либо использовать существующее хранилище. В малых внедрениях иногда делают просто: логи пишутся в реляционную БД или файлы на NAS. Но лучше всё же выделенный диск. Можно использовать недорогие SATA SSD – даже одного SSD на 4 ТБ может хватить на несколько месяцев логов (с учетом сжатия). Резервировать можно на уровне бэкапов (сохранять дампы на USB/NAS раз в неделю).

• Облако. Малые организации нередко выбирают облачные SIEM (типа Azure Sentinel, Splunk Cloud, Sumo Logic) чтобы не держать инфраструктуру (правда, в России с таким классом решений пока сложно, но все может скоро поменяться). Это снижает расходы на железо. Например, Sentinel имеет относительно низкий порог входа – платишь за гигабайты логов в месяц, не надо серверов. Если в малой компании есть ИТ-админ, но нет экспертизы по железу для SIEM, облако – хороший путь.

• Многоуровневое хранение. В малых средах, как правило, не нужно – объемы невелики, все логи можно держать на одном типе хранилища в пределах срока хранения (например, 3–6 месяцев на одном SSD-массиве). Архив старше – если нужен – можно просто вручную выгружать на внешний диск.

Пример. Небольшая фирма может развернуть Elastic Stack на одном мощном ПК с 2 SSD: один под ОС и hot-индексы, другой под реплики или cold (либо оба в RAID1). Это обеспечит прием, хранение и поиск, скажем, 100 ГБ логов в день со сроком хранения 30 дней без особых изысков.

Средние компании (тысячи сотрудников, десятки тысяч EPS)

Тут уже появляются более строгие требования и большие данные.

• Аппаратно. Скорее всего, потребуется несколько серверов – хотя бы разделить сбор/корреляцию и хранение. По примеру одного отечественного SIEM: при 30k EPS рекомендуется отдельный Storage-сервер с 24 CPU, 64 ГБ RAM, 14 ТБ диска, плюс отдельный Core/Collector. Здесь возможно появление кластера: например, 2 узла хранения в кластере для отказоустойчивости или шардирования (чтобы 30k EPS распределить).

• Хранилище. Для среднего масштаба критична производительность и емкость. Часто выбор падает на комбинацию: более быстрые диски для индексов, и емкие для основного хранения. Например, на Storage-сервере может быть пул SSD (для горячих 1-2 месяцев) и пул HDD (для оставшихся 6-12 месяцев). Или использование SAN: средние организации могут уже иметь SAN с достаточной производительностью. Можно разместить warm/cold на SAN, а hot на локальных SSD. Все зависит от инфраструктуры. Очень важно закладывать масштабирование: если сейчас 30k EPS, через год может быть 50k EPS – система должна расшириться (еще диски или узлы). Средние компании часто рассматривают гибридные облачные схемы: например, основное хранение on-prem, а резервное копирование логов – в облако, или наоборот (часть источников сразу шлют в облако).

• Надежность. Для среднего бизнеса критична непрерывность – уже не допустимо, чтобы SIEM теряла данные при сбое. Поэтому: RAID для каждого хранилища, репликация или кластер (минимум актив/пассив нода). Например, можно иметь 2 сервера-реплики Elastic в разных стойках. Или кластер из 3 узлов с RF=2, что даст пережить выход из строя одного. Стоимость такого дублирования нужно учитывать в бюджете.

• Tiering. Полезно настроить политики ротации с переносом на более дешевое хранилище, чтобы не перегружать дорогие SSD старыми данными. Например, ArcSight Logger можно настроить хранить 3 месяца на локальном быстром диске, а старше – экспортировать в CSV на сетевое хранилище, откуда их можно при необходимости загрузить обратно. Или Elastic ILM – 7 дней hot (SSD), 90 дней warm (HDD), старше – удаление или snapshot.

Пример: средняя организация с 50k EPS, срок хранения – 1 год. Решение: кластер из 3 индексаторов Splunk, каждый с 8 ТБ NVMe (для горячих ~90 дней), плюс настроен SmartStore на S3 для данных старше 90 дней (холодный слой). Это даёт оперативный поиск по кварталу и возможность подтянуть старые данные из S3 при надобности. Отказоустойчивость через реплики между индексаторами. Такое решение дороже, но обеспечивает и скорость, и объем (S3 практически бесконечен по объему для года логов). Альтернативно, on-prem: 3 сервера, каждый 2 TB SSD + 20 TB HDD; горячие корзины на SSD (реплицируются), холодные на общем NAS (каждый пишет свою копию, + NAS бэкапится). Тут больше своих костылей, но меньше зависимости от облака. Выбор пути – по приоритетам компании.

Крупные компании ( >100К EPS, множество филиалов)

Это уже очень большие данные (миллиарды событий в день) и высокие требования по аналитике.

• Аппаратно. Практически всегда распределенная кластерная архитектура. Одной установкой не обойтись. Нужны и балансировщики, и множество хранилищ. Например, крупный банк может иметь 20 узлов Elastic (hot) и 50 узлов Hadoop (для холодного хранения) или несколько географических кластеров SIEM, объединенных надстройкой. Часто крупные компании идут к облачным или гибридным решениям – потому что масштабы сравнимы с облачными по нагрузке.

• Хранилище. При таких масштабах стоимость и масштабируемость выходят на первый план. NVMe, конечно, дает потрясающую производительность, но обеспечить, скажем, 5 петабайт NVMe – финансово тяжело даже для банка. Поэтому для крупного предприятия делают сложные многоуровневые хранилища:

  • Горячие данные (скажем, 30-60 дней) – на выделенном кластере быстрых узлов (NVMe SSD, распределенное хранение с репликами).

  • Теплые (до 6-12 месяцев) – на большем кластере емких узлов (может, SATA SSD или HDD, но много узлов параллельно; либо on-prem HDFS).

  • Архив – вынос в дешевые места (ленты офлайн или облако).

  • Очень важна автоматизация: при таких объемах вручную администрировать неудобно, нужно чтобы система сама удаляла/архивировала согласно политике ротации данных.

• Отказоустойчивость. Большие организации требуют не просто защиты от отказа сервера, но и устойчивости к отказу целого ЦОДа или региона. Поэтому могут быть геораспределенные кластеры. Например, Splunk на 2 площадки с репликацией между ними, Elastic – кросс-кластерная репликация. Либо основной SIEM on-prem, а резервный поток отправляется в облако (так, на случай катастрофы есть копия логов). Все это увеличивает требования к хранилищам (нужен запас емкости под реплики).

• Производительность поиска. На масштабе предприятия даже SSD могут быть загружены, т.к. присутствуют многопользовательская аналитика, цепочки правил, тяжёлые корреляции. Поэтому приходится шардировать и выносить поиск ближе к данным. Возможен подход «разделяй и властвуй»: кластеры по доменам (сетевые логи отдельно, системные отдельно) и над ними федеративный поиск. Это накладывает свои требования: каждое хранилище по отдельности меньше, но их много. При федеративном поиске (напрямую из нескольких систем) сеть может стать узким местом – но тут уже архитектурные тонкости.

Примеры.

Microsoft сама перевела свою корпоративную инфраструктуру на Sentinel (облачный SIEM) для масштаба ~20 млрд событий в день, ~100 тысяч EPS. Решение: выделенный кластер Log Analytics, warm-хранение на Azure Data Explorer, cold – на Data Lake, и масштабируемое потребление через Event Hub для всплесков. Т.е. крупная компания задействует все возможности облака (эластичность, разделение слоев).

Международная компания может использовать Google Chronicle, который хранит петабайты логов на облачной инфраструктуре Google, предоставляя поиск по годам данных без необходимости вообще думать про диски, но это «подписочная» модель и в России не применима в текущих геополитических условиях.

Если же крупная компания по тем или иным причинам держит SIEM on-prem, то архитектура напоминает большие данные: например, 5 управляемых узлов-корреляторов + 10 нод хранения (SSD) + 20 узлов Hadoop (HDD) как архив, плюс резерв в другом ЦОДе аналогично. Такие проекты требуют серьезных инвестиций и планирования – буквально строится мини-приватное облако под задачи хранения логов.

Выбор по масштабу. В итоге, малые – простота (одноуровневое локальное хранение или облако), средние – баланс (можно комбинировать локальные SSD и внешнее хранилище, частичное облако), крупные – сложные многоуровневые распределенные системы (либо аутсорсить в облако). При переходе от одного уровня к другому имеет смысл переоценивать подход: то, что работает для 5k EPS, может не масштабироваться на 100k EPS. Всегда учитывайте перспективу роста: лучше сразу заложить кластер из 2 нод для «средней» компании, чем начинать с одной (без репликации), а потом в авральном режиме переделывать.

Подходы к хранению данных в облачных SIEM

В последние годы многие организации выбирают облачные SIEM-сервисы – это решения, где сбор и анализ событий находятся в инфраструктуре облачного провайдера. Примеры: Microsoft Sentinel (Azure), IBM QRadar on Cloud, Google Chronicle, Splunk Cloud, Elastic Cloud (Security Analytics), LimaCharlie, Sumo Logic, Arctic Wolf и другие. Их подходы к хранению отличаются от on-prem, но концептуальные принципы те же – просто реализованы как управляемый сервис. В России данные сервисы недоступны, но так как и своих аналогичных сервисов у нас пока не появилось, то имеет смысл посмотреть, как это реализованы за пределами нашей необъятной Родины.

Microsoft Sentinel (Azure). Построен на основе Azure Monitor/Log Analytics. Данные изначально поступают в Log Analytics Workspace (где хранятся ~90 дней как горячие). Под капотом Azure использует движок Kusto (Azure Data Explorer) для быстрых запросов KQL. Sentinel предоставляет опцию Long-Term Retention: можно настраивать правила, чтобы логи старше N дней автоматически экспортировались в Azure Storage (блобы) или в Azure Data Explorer для длительного хранения. У Microsoft реализовано: «90 дней горячие в Kusto, теплое хранение в Azure Data Explorer, холодное – в Data Lake до двух лет». Это соответствует классическому tiering, но в форме услуги. Причем пользователь платит разные тарифы: за hot-хранение (дороже) и архив (дешевле). Sentinel также интегрируется с архивным поиском – можно выполнять запросы по данным в холодном хранилище, но они будут выполняться медленнее и с дополнительными затратами. В плане надежности Azure реплицирует данные на уровне сервиса (3 копии в зоне, опция Geo-репликации для хранилища). Пользователь может не волноваться о RAID – Microsoft обеспечивает >99,9% доступность и долговременность хранения данных.

LimaCharlie. Это «SIEM как платформа», хостится в Google Cloud. Согласно их документации, они хранят 1 год телеметрии бесплатно в поисковом виде, используя технологию Insight на GCP. Вероятно, данные хранятся в Google BigQuery или аналогичной колоночной базе, что позволяет быстро искать по годовому объёму данных. Подход: отделение хранения от вычислений – данные лежат в облачной БД, при запросе поднимается мощность для SQL-запроса. Плюс – клиент не думает о дисках вообще, минус – после года либо плати, либо выгружай. LimaCharlie также позволяет выгружать данные в собственное хранилище клиента (например, в S3) через их API, если нужно более длительное удержание или интеграция с data lake.

Google Chronicle. Компания обещает очень длительное хранение (до нескольких лет) по фиксированной цене и очень быстрый поиск. Это достигается тем, что Chronicle – по сути, построен на внутренних технологиях Google (Spanner/BigTable) и использует огромную масштабируемую инфраструктуру. Данные автоматически индексируются, сжимаются и реплицируются. По сути, Chronicle – это облачный data lake + аналитическая платформа, оптимизированная для журналов безопасности. Пользователь только отправляет логи (через коллекторы), а поиск выполняется на их веб-интерфейсе. Плюс: не нужно думать ни о шардах, ни о дисках – Google справляется. Минус: это полностью проприетарное решение, которое и стоит соответствующе; перенос данных оттуда в другую систему – сложная задача (vendor lock-in).

Splunk Cloud / Elastic Cloud / Sumo Logic. Эти сервисы схожи: вы платите за хранение событий, и провайдер (Splunk, Elastic и т.д.) гарантирует доступность и скорость. Splunk Cloud обычно хостится на AWS – они могут выделять вам поисковые узлы (EC2) и хранить данные либо на EBS (SSD) для горячего хранения, либо на S3 (SmartStore) для warm/cold. То есть, архитектура аналогична on-prem Splunk, но управляется Splunk как сервис. Elastic Cloud – аналогично, под капотом Elasticsearch Service, с возможностью включить холодные слои (они хранятся на менее производительном хранилище или даже на объектном). Sumo Logic – изначально мультитенантный облачный SIEM, у которого данные сохраняются в собственной облачной архитектуре (ранее они упоминали использование AWS S3 и Hadoop). Клиент через веб-интерфейс выполняет запросы, а где именно лежат его логи – прозрачно (скорее всего, новые – в какой-то NoSQL/Elastic, старые – в S3).

Что объединяет эти решения

• Общее преимущество этих решений: минимум администрирования для клиента, масштаб по требованию, обновления и поддержка лежит на провайдере услуги.

• Недостатки: стоимость при больших объемах может превышать on-prem вложения в перспективе, а также передача конфиденциальных данных третьей стороне – требуется доверие и соответствие регуляторике (например, европейским компаниям надо учитывать GDPR при выгрузке логов в чужое облако, а российским – ФЗ-152 о персональных данных и ФЗ-187 – по безопасности критической инфраструктуры).

• Еще момент: срок хранения по умолчанию. Многие облачные SIEM ограничивают этот период 30-90 днями, далее потребуется, скорее всего, доплата. Например, Sentinel – 90 дней бесплатно, за больше – дополнительные $/ГБ/месяц.

Отказоустойчивость в облачных SIEM

Обычно высокая: данные реплицируются по как минимум 2-3 копиям. Например, Sentinel в бэкэнде использует хранилища с тремя репликами, Chronicle заявляет даже георезерв. Так что надежность зачастую выше, чем среднестатистическое on-prem развёртывание (где не всегда есть географическое резервирование).

Производительность

Облачные SIEM могут удивлять скоростью, поскольку провайдеры оптимизируют их под масштаб. Microsoft заявила, что после миграции на Sentinel их «скорость запросов улучшилась в среднем в 12 раз, до 100 раз на некоторых запросах» по сравнению с прежним on-prem SIEM, который упёрся в масштаб. Это преимущество облака – если нужно, задействуются больше CPU/памяти на запрос и возвращают результат быстрее (хотя за большое потребление CPU могут взиматься деньги, косвенно). Однако есть и ограничения: например, Log Analytics может иметь лимиты на объем выдачи в минуту, Chronicle – ограничения на сложность и количество запросов в секунду.

Гибкость хранения

Облачные SIEM часто предоставляют интеграции для экспорта данных: например, Sentinel позволяет подключить BYO (Bring Your Own) хранилище – отправлять копии логов в собственный Azure Data Lake или даже в сторонний (Event Hub -> сторонний потребитель). Это важно для тех, кто хочет, скажем, все логи складывать также в свой data lake помимо SIEM. LimaCharlie, Sumo Logic тоже имеют API/коннекторы для форвардинга данных. В целом, даже выбрав облачный SIEM, архитекторы часто делают двойное хранение: одна копия – у провайдера SIEM, вторая – у себя локально или в другом облаке, про запас и для возможности миграции (если финансы позволяют реализовать такое дублирование).

Облако и уровни данных

В облаке уровни абстрагированы: пользователь просто выбирает срок хранения данных. Но под капотом они соответствуют тем же концепциям. Azure предлагает Hot, Cool, Archive tiers для blob-хранилища – Sentinel может ими пользоваться, когда вы экспортируете логи (например, указать, что через 30 дней перевести блоб в Cool для экономии). Amazon Security Lake тоже сохраняет логи в S3 с заданным жизненным циклом (стандартный S3 -> Glacier). Так что принципы горячего/холодного хранения никуда не делись, просто администратор оперирует ими косвенно.

Рекомендации по облачным SIEM

• Если у вас малый/средний бизнес с ограниченной ИТ- и ИБ-командой – облачный SIEM избавит от множества забот. Можно сразу получать пользу (правила корреляции, мониторинг) вместо администрирования серверов. Убедитесь лишь, что вас устраивают условия по хранению (срок, стоимость за превышение). Например, если нужно хранить год, а сервис по умолчанию дает 3 месяца, сразу заложите бюджет на дополнительное хранение или настройте экспорт в свое хранилище.

• Для крупных предприятий облачный SIEM привлекателен масштабируемостью, но нужно внимательно считать стоимость. Иногда гибридное решение дешевле: например, хранить «обычные» логи локально, а очень дорогие в обработке – отдать облаку с его ML-анализом. Некоторые выбирают стратегию: оставить существующий on-prem SIEM для требований соответствия (медленно и дешево складировать все), а в облачный (тот же Sentinel или Chronicle) лить копию критичных потоков для быстрого обнаружения инцидентов. Это дает лучшее из двух миров, хотя и удваивает инфраструктуру.

• Облачные решения быстро эволюционируют, новые оптимизации появляются (например, AWS Security Lake и Open Cybersecurity Schema Framework – попытка стандартизовать хранение событий в облаке, чтоб разные аналитики могли к ним подключаться). Следите за трендами: возможно, вместо поднятия ещё одного локального сервера, проще подключить новый облачный модуль аналитики.

Безопасность и регуляторика

В финансовых или государственных компаниях могут быть свои требования, где можно и нельзя хранить события. Облако нужно выбирать с учетом этого (например, для персональных данных граждан Евросоюза или России – только региональные локальные хранилища), а компоненты ГИС и отдельные категории значимых объектов КИИ нельзя размещать за пределами Российской Федерации. Если никак нельзя в публичное облако, но хочется преимущества, рассматривайте приватные облака – например, развернуть решение (такое позволяет Splunk и Elastic) в частном облаке и использовать object storage внутри (Ceph, MinIO) для холодных данных. Это сложнее, но даст контроль над данными.

Выводы и рекомендации

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

• Для максимальной скорости. Используйте SSD/NVMe, локально подключенные, с достаточным запасом IOPS. Особенно для индексирующих компонентов и горячих данных. Это ускорит и запись, и поиск (подтверждено тестами: HDD существенно медленнее на поиске событий).

• Для больших объемов. Внедряйте многоуровневое хранение. Держите часто запрашиваемое на быстрых дисках, историческое – на дешевых. Это экономически эффективно. Не забывайте обеспечивать сквозной поиск или понятные процессы выборки из архива, чтобы не терять полезность данных.

• Надежность. Не экономьте на резервировании. Логи ценны, поэтому RAID или репликация попадают в разряд «must have», даже в малых организациях (по крайней мере, бэкап). В крупных кластерах стоит продумать отказоустойчивость узлов и площадок.

• Типы дисков. HDD хороши для емких архивов, но их роль в активной части SIEM уменьшается. SSD стали стандартом для рабочих данных (Splunk, QRadar теперь поставляются на SSD). NVMe – следующий шаг, его стоит выбирать, если бюджет позволяет, особенно для новых внедрений с горизонтом 3-5 лет.

• Архитектура хранения. В небольших внедрениях зачастую локальные диски проще и надежнее, чем усложнять с SAN. В крупных – распределенный кластер с локальными дисками, либо использовать возможности облака.

• Облако. Все говорит о том, что идет смещение в сторону облачных SIEM. Они уже реализовали многие рекомендации автоматически (tiering, репликация, масштабирование). Если путь облака вам подходит по условиям, он снимет головную боль управления хранилищем. Если нет – принимайте лучшие практики облака и больших данных в свою архитектуру on-prem (разделение данных, параллелизм, использование объектных хранилищ как архива).

Наконец, всегда ориентируйтесь на свои сценарии использования. Если ваша команда SOC в основном расследует инциденты за последние 7 дней – инвестируйте в быстрое хранилище именно для этой недели и не тратьте слишком много на полугодовой онлайн-доступ (можно и архивировать). Если же вам регулярно нужны годичные корреляции (например, продвинутый Threat Hunting) – придется потратиться на хранение больших объемов с приемлемой скоростью (или задействовать облако/data lake). Примеры из практики SIEM показывают, что грамотно устроенное хранение – залог успеха: быстрый доступ к нужным данным повышает эффективность обнаружения угроз. Поэтому планируйте архитектуру хранения так же тщательно, как и сами корреляционные правила SIEM.