Определение размеров систем управления журналами требует знания количества контролируемых устройств и предполагаемой частоты событий для каждого класса систем.
Основные расчеты хранения журналов
Это важно, поскольку существует слишком много переменных, чтобы предсказать среднее или пиковое количество событий в день (EPS) для любой конкретной системы. Я бы предупредил любого клиента, что если поставщик, с которым он работает, предоставит ему "волшебные" расчеты и цены, не собрав необходимую информацию о скоростях и подаче данных для конкретного клиента, он может рассчитывать на то, что впоследствии потратит гораздо больше денег, как только поставщик заступит на порог. В общем, плохое планирование приведет к неизбежным затратам в дальнейшем.
EPS - одна из метрик, используемых многими поставщиками систем управления журналами и SIEM для определения таких факторов, как лицензирование, хранение и пиковая нагрузка на систему. Другой используемой переменной может быть число событий в день (Events Per Day, EPD), особенно когда речь идет о размерах хранилища и применении лицензий. Вот почему при планировании централизованного управления журналами или SIEM-решения крайне важно провести аудит точного количества устройств и типов продуктов.
Например, брандмауэр PIX, ведущий журнал через Syslog с использованием уровня регистрации уведомлений, может иметь от 1 до 20 eps, в зависимости от местоположения, восприимчивости к недоверенным сетям, количества фильтров, служб 3DES (SSH или IPSEC), правильной конфигурации и многих других факторов, специфичных для каждой конфигурации и сетей, которые он призван защищать. Если бы этот же брандмауэр вел журнал с информационным или отладочным уровнем регистрации, то он генерировал бы в 3-5 раз больше событий, чем журнал информационного уровня.
Далее, размер события имеет решающее значение для правильного проектирования управления журналом, поскольку у каждого производителя устройств будет свой формат журнала, размер события, транспортный механизм, уровни регистрации и т. д. Разница между сообщением размером 300 байт и сообщением размером 700 байт существенна, если вы собираете >1000 EPS (~26 ГБ/день против ~60 ГБ/день). Сообщения Syslog в соответствии с RFC 3164 не могут быть больше 1024 байт, но структурированные или "нормализованные" данные о событиях могут достигать более 5 000 байт (с обогащением и фрагментацией). В некоторых случаях, когда поставщик говорит вам, что он нормализует все данные о событиях, это упрощает планирование размеров и емкости, поскольку каждое сообщение о событии, независимо от поставщика, будет иметь одинаковый размер (не говоря уже о том, что его легче читать, искать, индексировать и т. д.). Некоторые поставщики даже позволяют клиентам нормализовать данные и резервировать поле в схеме нормализации для присоединения исходного "сырого" события. Это отлично подходит для разбирательств и криминалистики, но почти вдвое увеличивает требования к хранению!
Например, если нормализованное событие занимает 1500 байт (независимо от того, было ли исходное событие всего 600 байт), то конечный размер события с присоединенным "исходным" событием размером 500 байт составит около 2 Кбайт.
Один из способов измерения количества событий и их размеров для Syslog заключается в использовании инструмента анализа протоколов, такого как WireShark, Etherpeek или TCPdump, для захвата событий на отправляющем или принимающем хосте или на проброшенном порту коммутатора второго уровня. Отфильтруйте захват только для UDP 514.
Анализ не требует захвата полезной нагрузки и может выполняться в течение 24 часов. После завершения захвата возьмите общее количество пакетов UDP 514 и разделите это число на 86400 (количество секунд в сутках), что даст вам приблизительное среднее значение общего количества событий в секунду (eps).
Кроме того, вычислить EPS, генерируемый файлом журнала, гораздо проще, поскольку вам нужно просто подсчитать количество строк, захваченных в файл журнала за 24-часовой период, и, опять же, разделить это число на количество секунд в сутках (86 400). Затем нужно умножить EPD или EPS на размер сообщения, чтобы определить объем хранилища.
Пример расчета системы хранения
Переменные:
- Событие RAW = ~600 байт
- Событие NORM = ~1500 байт
- DAY = 86 400 секунд
- EPS = События в секунду
- EPD = События в день
- SIZE = Объем в байтах
- DISK = Необходимое дисковое пространство
- COMPRESS = Предположим, что соотношение 10:1
Сначала необходимо определить EPD, поэтому:
EPS x DAY = EPD
(т. е. 1000 EPS x 86 400 секунд = 86 400 000 EPD или 86,4 MEPD).
Затем мы должны определить, сколько дискового пространства это даст в зависимости от того, являются ли эти события RAW или нормализованными:
EPD x RAW = SIZE
(т.е. 86,4 MEPD x 600 = 51 840 000 000 байт)
~ или ~
EPD x NORM = SIZE
(т. е. 86,4 MEPD x 1500 = 129 600 000 000 байт)
Затем нам нужно сжать эти события со сжатием 10:1, чтобы получить приблизительную ежедневную потребность в дисках. Для этого мы делим максимальный ежедневный размер, выделенный для событий, на 10:
SIZE / COMPRESS = DISK (RAW)
(т. е. 52 ГБ / 10 = 5 184 000 000 байт)
~ или ~
SIZE / COMPRESS = DISK (NORM)
(т. е. 129 ГБ / 10 = 12 960 000 000 байт)
Наконец, мы определяем годовую потребность в дисковом пространстве, рассчитав ежедневную потребность в диске на 365:
DISK (RAW) x 365 = YEAR
(т.е. 5 184 000 000 x 365 = 1 892 160 000 000 или 1,8 терабайт)
~ или ~
DISK (NORM) x 365 = YEAR
(т. е. 12 960 000 000 x 365 = 4 730 400 000 000 или 4,7 терабайта)
После определения EPS для каждого устройства по всем категориям устройств это число можно просуммировать по количеству контролируемых устройств в целом, чтобы получить расчетное среднее значение EPS.
Для определения объема памяти, необходимого для этой меры EPS, используйте описанную выше формулу, которая выглядит следующим образом:
EPD * RAW / 10 * 365 = YEAR (в сжатом виде)
~ или ~
EPD * NORM / 10 * 365 = YEAR (сжатый)
Надеюсь, это поможет вам определить необходимый объем памяти.