Руководство по Озеру данных Cato

Эта статья обсуждает Подробности генерации событий и хранения Данных для Озера данных Cato и вашего Аккаунта.

Обзор

Озеро данных Cato содержит Данные, записанные разными Услугами на платформе Cato, такими как Сетевое оборудование, Безопасность, Доступ и так далее. Данные, такие как информация о Событиях, добавляются в Озеро данных в реальном времени и сохраняются в течение определенного периода времени, как указано в контракте клиента. Cato использует единицы Озера данных для определения хранения Данных клиента в соответствии с:

  • Ежечасная скорость событий (в настоящее время в единицах 2,5 миллиона событий в час)
  • Срок хранения (например, 3 месяца, 6 месяцев и т. д.)

Данные, превышающие условия единицы Озера данных, отбрасываются. Например, если в течение часа происходит более 2,5 миллиона событий или данные старше 3 месяцев.

Как часть платформы Cato, Аккаунты получают одну единицу Озера данных, которая включает ограничение скорости событий 2,5 миллиона событий в час и срок хранения 3 месяца. Клиенты могут выбрать покупку дополнительных единиц Озера данных для увеличения ежечасной скорости событий и/или увеличения срока хранения событий.

Клиенты также могут использовать различные Интеграции, чтобы пересылать свои Данные во внешние облачные хранилища и SIEM без дополнительных затрат.

Эта информация в этой статье применяется к Учетным записям Cato начиная с 1 января 2024 года(*).

Подход к хранению событий

События сохраняются в реальном времени и могут отслеживаться в Приложении Управления Cato (CMA) на странице Событий (Домашняя > События).

  • Cato сохраняет основной набор ключевых событий безопасности и соединения для каждого клиента
  • Клиенты могут выбирать, в рамках политик, дополнительные события, которые будут генерироваться и сохраняться
  • Лицензии клиентов определяют Ежечасное ограничение скорости на максимальное количество Событий, которые генерируются и сохраняются

    • События, превышающие это количество, отбрасываются до конца часа

Для получения дополнительной информации об оптимизации сгенерированных Событий, см. Лучшие практики для хранения и поглощения журналов Событий Cato

Измерение Ежечасно генерируемых и отбрасываемых событий

Озеро данных подлежит ограничению скорости на основе количества Событий, генерируемых в час.

Количество Событий, которые были созданы для вашей учетной Записи за последний час, отслеживается счетчиком.

  • В начале каждого часа счетчик сбрасывается
  • Когда количество Событий достигает порогового значения, установленного для клиента, дальнейшие События отбрасываются в оставшееся время этого часа

    Однако, Cato продолжает сохранять системные События, связанные с Процессами Cato

  • Cato обычно позволяет превышение порога, чтобы уменьшить вероятность отклонения событий

Ограничение скорости событий

Подробности о стандартном ограничении скорости событий для Cato основаны на единицах Озера данных, принадлежащих Аккаунту:

  • Cato разрешает до одного блока Озеро данных бесплатно (в настоящее время 2,5 миллиона событий в час)
  • Если генерируется больше событий, чем лицензированных блоков Озеро данных, избыточные события отклоняются на оставшуюся часть часа
  • Чтобы предотвратить отклонение событий, клиентам предлагается приобрести дополнительные блоки Озеро данных

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

Хранение Событий

Для контрактов и продлений, начиная с 1 января 2024 года, срок хранения событий составляет 3 месяца.

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

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

  • Для более детальной информации о приобретении дополнительного времени хранения данных, пожалуйста, свяжитесь с вашим представителем Cato.

Cato поддерживает следующие параметры хранения событий:

Единицы Озера Данных

По умолчанию, каждая учетная запись имеет следующие единицы Озера Данных:

  • Ежечасный уровень событий (в настоящее время в единицах по 2,5 миллиона событий в час)
  • Время хранения (т.е. 3 месяца, 6 месяцев и т.д.)

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

Увеличение лимита частоты событий

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

Каждая единица Озера данных покупается для увеличения ограничения частоты на 2,5 миллиона событий в час. Так, например:

  • Два блока Озеро данных разрешают дополнительные 2,5 миллиона событий в час (до 5 миллионов событий в час всего)
  • Три блока разрешают дополнительные 5 миллионов событий в час (до 7,5 миллионов событий в час всего)

Увеличение срока хранения событий

Единицы Озера Данных доступны в трех вариантах, в зависимости от требуемого срока хранения:

  • Блок на три месяца
  • Блок на шесть месяцев
  • Блок на двенадцать месяцев

Выбранный вариант применяется ко всем единицам данных, смешивание блоков невозможно.

Примеры

Таблица ниже иллюстрирует использование единиц Озера данных для покрытия потребностей клиента в хранении событий.

Пиковое количество событий, сгенерированных за час Требуемый срок хранения Требуются дополнительные блоки Озеро данных Требуемый тип блока Озеро данных
До 2,5 миллиона 3 месяца 0 Н/Д
До 2,5 миллиона 6 месяцев 1 Блок на 6 месяцев
До 5 миллионов 3 месяца 1 Блок на 3 месяца
До 7,5 миллионов 12 месяцев 2 Блок на 12 месяцев

Оценка требований к единицам Озера Данных на основе истории событий

Клиенты с устоявшейся историей генерации событий могут просмотреть график событий в CMA, чтобы увидеть, сколько событий создается. Они могут использовать пики на этом графике, чтобы рассмотреть свои требования к ограничению частоты событий.

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

Data_SKUs_Event_History_1.png

В примере графика ниже, количество событий в час превышает 2,5 миллиона каждый час, и наивысший пик приближается к 3 миллионам. Это больше, чем может быть покрыто стандартным ограничением частоты событий для 1 единицы Озера Данных. 1 дополнительная единица покроет эти требования к хранению, позволяя генерировать до 5 миллионов событий в час.

Data_SKUs_Event_History_2.png

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

Data_SKUs_Event_History_2_hover.png

Дополнительные моменты, которые нужно учитывать:

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

Оценка потребностей в событиях без учета истории событий

Этот раздел помогает создать первоначальную приближенную оценку пиковых событий в час, чтобы понять, сколько единиц озера данных требуется. Мы рекомендуем постоянно отслеживать реальные уровни событий и производить корректировку по мере необходимости. Фактические события, генерируемые в час, зависят от нескольких переменных, таких как трафик и конфигурация логирования политики. Для получения дополнительной информации смотрите Лучшие практики для хранения и обработки журналов событий Cato.

Генерация событий коррелируется как с общим используемым пропускным каналом в сети, так и с количеством поддерживаемых пользователей SDP. Клиенты без истории генерации событий могут оценить свои вероятные потребности в ограничениях по событийному потоку, добавив общую ширину канала для сайта и количество пользователей SDP. Кроме того, включенные для аккаунта услуги также могут влиять на требования к событиям. Например, если включен брандмауэр LAN, это увеличит требования к событиям пропорционально объему LAN-трафика и тому, какой трафик генерирует события.

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

  1. Найдите строку в таблице Общая пропускная способность, которая соответствует пиковым лицензированным пропускным способностям сети. Считайте предполагаемое пиковое количество событий в час, которое будет сгенерировано
  2. Найдите строку в таблице Клиенты SDP, которая соответствует количеству используемых клиентов SDP. Считайте предполагаемое пиковое количество событий в час, которое будет сгенерировано
  3. Сложите суммы из шагов 1 и 2.
  4. Разделите общее количество событий в час на 2,5 миллиона и округлите в большую сторону, чтобы оценить количество необходимых блоков Озеро данных для пропускной способности сайта и клиентов SDP.
  5. Если вы используете несколько служб Cato, которые генерируют большое количество событий, таких как CASB или LAN Firewall, добавьте 1 блок Озеро данных. (1 блок для пропускной способности, 1 блок для пользователей SDP и 1 блок для CASB и RBI)

Таблицы генерации событий

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

Общая пропускная способность Предполагаемое пиковое количество событий в час Клиенты SDP Предполагаемое пиковое количество событий в час
До 2,5 Гбит/с 1 000 000 До 3К 1 000 000
2,5-6 Гбит/с 5 000 000 3К-7К 5 000 000
6-9 Гбит/с 7 500 000 7К-11К 7 500 000
9-12 Гбит/с 10 000 000 11К-15К 10 000 000
12-15 Гбит/с 12 500 000 15К-19К 12 500 000
15-18 Гбит/с 15 000 000 19К-23К 15 000 000
18-21 Гбит/с 17 500 000 23К-27К 17 500 000
21-24 Гбит/с 20 000 000 27К-31К 20 000 000
24-27 Гбит/с 22 500 000 31К-35К 22 500 000
27-30 Гбит/с 25 000 000 35К-39К 25 000 000
30-33 Гбит/с 27 500 000 39К-43К 27 500 000

Пример оценки

В таблице выше:

  • Общая пропускная способность 3 Гбит/с на всех площадках будет генерировать предполагаемый пик в пять миллионов событий в час
  • Общее количество клиентов SDP 5 000 будет генерировать дополнительный предполагаемый пик в два с половиной миллиона событий в час
  • Таким образом, клиент может ожидать пик 5+2,5= 7,5 миллиона событий в час (2 блока)
  • Клиент использует сервисы CASB и RBI (1 блок)
  • Это может быть покрыто покупкой трёх дополнительных блоков хранилища Озеро данных соответствующей продолжительности.

Оценка фактического необходимого срока хранения

Единица измерения для Озера данных — количество событий, создаваемых в час. Объём данных не используется при расчёте или покупке дополнительных единиц и не учитывается CMA.

Тем не менее, клиенты могут захотеть оценить возможные последствия, если планируют экспорт данных на внешнее хранилище или в SIEM. Клиенты могут сделать приблизительную оценку объёма вовлечённых данных, предположив, что одна единица Озера данных (2,5 миллиона событий в час) примерно соответствует 180 ГБ в месяц хранилища данных, как показано в таблице ниже.

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

Следующая таблица показывает очень приблизительную оценку общего объема ГБ в зависимости от срока хранения:

События в час Дополнительные блоки Озеро данных ГБ в месяц (предполагаемые) 3 месяца 6 месяцев 12 месяцев
2,5 миллиона 0 180 540 1080 2160
5 миллионов 1 360 1080 2160 4320
7,5 миллиона 2 540 2160 4320 8640

(*) Some contracts with Cato may include terms that differ from the information in this article

Была ли эта статья полезной?

Пользователи, считающие этот материал полезным: 4 из 4

0 комментариев