Руководство по Озеру данных 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, добавьте 1 единицу озера данных.

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

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

Общая пропускная способность

Оценочное количество пиковых событий в час

SDP Клиенты

Оценочное количество пиковых событий в час

До 2.5Гбит/с

1,000,000

До 3K

1,000,000

2,5-6Гбит/с

5,000,000

3K-7K

5,000,000

6-9Гбит/с

7,500,000

7K-11K

7,500,000

9-12Гбит/с

10,000,000

11K-15K

10,000,000

12-15Гбит/с

12,500,000

15K-19K

12,500,000

15-18Гбит/с

15,000,000

19K-23K

15,000,000

18-21Гбит/с

17,500,000

23K-27K

17 500 000

21-24 Гбит/с

20 000 000

27K-31K

20 000 000

24-27 Гбит/с

22 500 000

31K-35K

22 500 000

27-30 Гбит/с

25 000 000

35K-39K

25 000 000

30-33 Гбит/с

27 500 000

39K-43K

27 500 000

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

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

  • Общая пропускная способность 3 Гбит/с на всех сайтах генерировала бы ориентировочную пиковую нагрузку в пять миллионов событий в час

  • Всего 5 000 клиентов SDP создавали бы дополнительную ориентировочную пиковую нагрузку в два с половиной миллиона событий в час

  • Таким образом, клиент может ожидать пиковую нагрузку в 5+2,5= 7,5 миллионов событий в час (2 единицы)

  • Клиент использует сервисы CASB и RBI (1 единица)

  • Это можно компенсировать, купив ещё три единицы хранения Озера данных на соответствующий срок.

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

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

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

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

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

События в час

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

ГБ в месяц (приблизительно)

3 месяца

6 месяцев

12 месяцев

2,5 миллиона

1

180

540

1080

2160

5 million

2

360

1080

2160

4320

7.5 million

3

540

2160

4320

8640

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

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

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

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