Я строю SOC’и уже давно и вижу, как с каждым годом всё чаще в них можно встретить SOAR-решения (Security Orchestration Automation and Response). Это понятно: специалистов не хватает и нужно максимально автоматизировать процессы по управлению и реагированию на инциденты ИБ.

Интересно, что большинство SOAR в SOC’ах — отечественные решения. Но есть и множество иностранных вендоров, которые пытаются зайти на российский рынок. Наша команда протестировала Cortex XSOAR от вендора Palo Alto Networks. И я готов поделиться результатами.

Под катом вас ждёт описание самого Cortex XSOAR, его архитектуры и работы. В начале – короткая справка о SOAR для тех, кто никогда не работал с этими решениями.

Что такое SOAR

Аббревиатура SOAR расшифровывается как Security Orchestration Automation and Response. Пройдёмся по каждому из понятий.

Оркестрация (Orchestration)

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

Автоматизация (Automation)

Уже сейчас можно сказать, что автоматизация неизбежно станет будущим для сферы информационной безопасности. Мало того, что она значительно сокращает среднее время обнаружения и реагирования на инциденты ИБ — она ещё и позволяет проще и точнее управлять ими. Если ручные операции по реагированию сейчас занимают несколько часов, то с технологиями автоматизации это время сокращается до нескольких минут.

Реагирование (Response)

Ежедневное реагирование на множество типовых инцидентов — серьезное бремя для операторов SOC’а. Инструменты решения SOAR позволяют значительно ускорить процесс реагирования благодаря заготовленным сценариям (плейбукам).

Проще говоря, SOAR — это решение, которое позволяет реализовать и автоматизировать многие операционные ИБ-задачи (управление и реагирование на инциденты ИБ, обработка уязвимостей, проверка актуальности сертификатов и др.), объединяя необходимые для этого ИБ- и ИТ-системы. Но, прежде чем без оглядки автоматизировать всё подряд, необходимо проделать большую работу: повысить прозрачность инфраструктуры, подготовить плейбуки и протестировать все действия по автоматизации.

Общее описание Cortex XSOAR

Теперь рассмотрим SOAR детальнее — на примере Cortex XSOAR.

 

Cortex XSOAR решает все задачи, которые обычно решают современные SOAR: управление заявками, контроль KPI/SLA, автоматизация действий сотрудников, а также совместное расследование инцидентов , проактивный поиск угроз (Threat Hunting) и связь с мировыми киберразведывательными данными (Threat Intelligence).

Система получает оповещения и индикаторы компрометации из различных источников обнаружения (от SIEM-систем до EDR/XDR и почтовых сообщений), наполняет базы знаний и запускает автоматические процессы для реагирования на инциденты.

Также в Cortex XSOAR есть функционал для взаимодействия пользователей в реальном времени (Real-Time Collaboration). Само взаимодействие осуществляется с помощью интерактивного «инцидент-чата» (War Room), где, например, можно прямо из командной строки привлечь внимание коллеги к тому или иному кейсу.

Стоит отметить, что Cortex XSOAR также является и IRP-решением, а это значит, что  у него есть функционал управления инцидентами (Case Management), который позволяет кастомизировать карточки инцидентов, собирать доказательства (evidence) и объединять информацию из нескольких инцидентов.

Внутренее тестирование и пример с пилота

Для начала хочу поделиться результатами тестирования решения в нашей внутренней демолаборатории и примером с одного из пилотов для нашего заказчика.

Для тестирования мы выбирали сценарии из самых часто встречающихся кейсов. Все эти сценарии нам удалось успешно реализовать в системе. При этом интеграции (ArcSight SIEM, Virus Total, Active Directory, Почтовый сервис Exchange, Check Point Firewall, Redmine Service desk, сканер уязвимостей Rapid7 Nexpose) уже были доступны «из коробки», что очень упростило нам задачу. В части кастомизации мы разработали парсер фидов ФинЦЕРТ, приходящих по почте во вложении. Ниже привожу описание сценариев.

Сценарий «Вредоносное заражение»

Действие

Описание

Способ выполнения

Интеграции

1

Заполнение карточки инцидента

SOAR получает корреляционное событие от SIEM (в нашем случае получение события осуществляется через почтовое уведомление, но также этот процесс можно реализовать через инструмент API), в результате, формируется карточка инцидента и заполняются следующие поля: ID-правила, категория, источник обнаружения, дата выявления, артефакты.

Автоматизация в SOAR

ArcSight SIEM

2.

Обогащение инцидента (действия выполняются параллельно)

2.1

Проверка вредоносности файла

Выявленная хеш-сумма файла направляется на проверку в Virus Total для подтверждения его вредоносности.

Автоматизация в SOAR

Virus Total

2.2

Поиск в событиях выявленного IoC

Осуществляется проверка всех логов SIEM на предмет наличия в них выявленной хеш-суммы за необходимый период времени. В случае, если хеш-сумма была выявлена в событиях на других хостах, данные по хосту заносятся в карточку инцидента.

Автоматизация в SOAR

ArcSight SIEM

2.3

Сбор данных по хосту

Из AD осуществляется сбор данных по хостам, которые задействованы в инциденте (доменное имя, учетные записи). Полученные данные фиксируются в карточке инцидента.

Автоматизация в SOAR

Active Directory

3.

Оповещение об инциденте и назначение ответственного

После проведения обогащения осуществляется отправка карточки инцидента на группу аналитиков для проведения базового анализа.

Автоматизация в SOAR

Почтовый сервис Exchange

4.

Базовый анализ инцидента

Осуществляется подтверждение того, что событие не является сбоем, ложным срабатыванием или не вызвано легитимным действием в инфраструктуре. В случае классификации события как инцидента ответственный специалист подтверждает меры реагирования (5.1-5.3). Если событие не является инцидентом, ответственный специалист закрывает инцидент.

Требуется привлечение сотрудника

 

5.

Реагирование (действия выполняются параллельно)

5.1

Сетевая изоляция хоста

На Firewall отправляется команда о блокировке хостов на уровне сети. Переход к следующему шагу осуществляется только после получения статуса об успешном выполнении задачи.

Автоматизация в SOAR с подтверждением

Check Point Firewall

5.2

Блокировка учетной записи

В AD отправляется команда на блокирование УЗ. Переход к следующему шагу осуществляется только после получения статуса об успешном выполнении задачи.

Автоматизация в SOAR с подтверждением

Active Directory

5.3

Удаление файла с хоста

Формируется задача в Service Desk на удаление файла с хоста, повторную проверку антивирусным средством и смену пароля УЗ. Переход к следующему шагу осуществляется только после получения статуса из Service Desk о закрытии обращения.

Автоматизация в SOAR

Redmine Service desk

6.

Подтверждение устранения инцидента

Ответственный специалист подтверждает успешное сдерживание и устранение инцидента и закрывает инцидент в SOAR.

Требуется привлечение сотрудника

 

Сценарий «Управление уязвимостями»

Действие

Описание

Способ выполнения

Интеграции

1

Заполнение карточки инцидента

Сканер уязвимостей присылает почтовое уведомление о наличии критических уязвимостей по результатам сканирования. В системе создается инцидент.

Автоматизация в SOAR

Почтовый сервис Exchange

2.

Сбор данных по уязвимостям

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

Автоматизация в SOAR

Сканер уязвимостей Rapid7 Nexpose

3.

Обогащение данными из AD

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

Автоматизация в SOAR

Active Directory

4.

Оповещение о выявленных уязвимостях

Оповещается группа ответственных о выявленных уязвимостях.

Автоматизация в SOAR

Почтовый сервис Exchange

5.

Анализ уязвимостей

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

Требуется привлечение сотрудника

 

6.

Создание заявки на устранение уязвимостей

По сформированным рекомендациям создается заявка в Service Desk. После получения статуса о ее закрытии плейбук завершается автоматически.

Автоматизация в SOAR

Redmine Service desk

Сценарий «Обработка IoC»

Действие

Описание

Способ выполнения

Интеграции

1

Регистрация инцидента

Осуществляется парсинг файла с IoC, полученного по почте, после чего заводится карточка инцидента с заполнением следующих полей: категория, источник обнаружения, дата выявления, артефакты (IoC).

Автоматизация в SOAR

Почтовый сервис Exchange

2.

Проверка наличия IoC в логах

Выполняется проверка в логах Firewall и SIEM полученных артефактов. В случае отсутствия таковых инцидент автоматически закрывается.

Автоматизация в SOAR

ArcSight SIEM, Firewall

3.

Обогащение

В случае выявления IoC в логах собираются данные из AD и SIEM о задействованных хостах (IP, доменное имя, УЗ), а также информация о действиях с этими IoC на хостах.

Автоматизация в SOAR

Active Directory, SIEM

4.

Оповещение об инциденте и назначение ответственного

Оповещается группа ответственных о выявленных инцидентах по результатам обработки IoC.

Автоматизация в SOAR

Почтовый сервис Exchange

5.

Базовый анализ инцидента и формирование стратегии реагирования

Осуществляется анализ инцидента и формирование стратегии реагирования: блокировка IP и УЗ, удаление файлов, перезаливка ОС хостов.

Требуется привлечение сотрудника

 

6.

Создание заявки на реагирование

По сформированным рекомендациям создается заявка в Service Desk. После получения статуса о закрытии заявки плейбук автоматически завершается.

Автоматизация в SOAR

Redmine Service desk

По итогу могу сказать, что все работы, связанные с настройкой интеграций и реализацией плейбуков, прошли очень гладко. «Коробочные» интеграции отлично справлялись со своей задачей, гибкий функционал плейбуков позволил реализовать весь желаемый WorkFlow. В плейбуках были представлены как полностью автоматизированные процессы в части обогащения данных, так и полуавтоматизированные (автоматизация в SOAR с подтверждением) в части блокировки адресов и учетных записей. Небольшой «ложкой дёгтя» для нас стала задача по разработке кастомного парсера фидов ФинЦЕРТ. В стандартных образах контейнеров не нашлось необходимых нам пайтоновских библиотек и пришлось собирать свой собственный. Конечно, задачу мы решили, но далеко не «малой кровью». Хочу отметить, что документация вендора не располагала описанием данных манипуляций, но спасибо сообществу Docker и всем добрым людям, которые делятся информацией в интернете :)

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

Ниже плейбук, разработанный в Cortex XSOAR.

 

Коротко о самом сценарии.

Любой пользователь в организации, которому пришло подозрительное, на его взгляд, письмо, может переслать его в виде вложения на почтовый ящик системы Cortex XSOAR. Пользователю приходит уведомление о том, что по его обращению заведён инцидент. Далее система парсит вложение и переносит все необходимые данные в карточку инцидента. Следующим шагом является обогащение дополнительной информацией от различных систем, таких как SIEM, различные TI-платформы и песочницы. Далее XSOAR осуществляет внутренний анализ полученной информации и задает уровень критичности инцидента — на основании этого уровня определяется, будет ли создана заявка в Service Desk. После того, как уровень критичности инцидента задан, система назначает ответственного за реагирование сотрудника и высылает ему на почту сводный отчет по результатам выполнения процессов внутренней аналитики.

Конечным этапом является закрытие инцидента (в ручном режиме) с присвоением ему статуса «true positive» или «false positive». Пользователю, который являлся инициатором расследования, приходит уведомление о конечном статусе инцидента.

Целью данного плейбука являлась разработка автоматизированного процесса обогащения и системной аналитики для подтверждения инцидента. Я считаю, что данный плейбук достаточно полезен и эффективно помогает расследованию. Настроить его в Cortex XSOAR было очень легко. Для конечной реализации можно добавить процессы реагирования, например, блокировку отправителя фишинговой ссылки.

Как и в случае внутреннего тестирования, сам процесс интеграции и разработки плейбука прошел очень легко. Немного помучались с «коробочным» парсером почтовых вложений, т. к. изначально он не хотел применять корректную кодировку для русского языка, но саппорт вендора очень сильно нас выручил и довольно быстро показал, что и где нужно поправить в коде.

Описание интерфейса и его особенностей

На этом описание практических примеров заканчивается, и я предлагаю перейти к не менее интересной теме — интерфейсу и его особенностям, чтобы глубже понять возможности функционала Cortex XSOAR.

Установка клиентского ПО не требуется. Подключение осуществляется через веб-интерфейс. Присутствуют персональные пользовательские настройки. Интерфейс на английском языке, но я не думаю, что для большинства это будет стоп-фактором :)

При входе в интерфейс нас встречает вкладка Home, которая по умолчанию переносит во вкладку Dashboards.

В свою очередь вкладка Dashboards состоит из нескольких разделов по умолчанию:

  • Incidents

  • Threat Intel Management

  • System Health

  • My Dashboard

  • SLA

Рассмотрим некоторые из них.

В разделе Incidents представлена визуализация различной статистики о приходящих или генерирующихся в системе инцидентах. Раздел полностью кастомизируется. Присутствует функционал добавления новых дашбордов.

В разделе Threat Intel Management представлена визуализация различной статистики об индикаторах компрометации. Раздел также полностью кастомизируется.

И, конечно же, можно добавлять свои кастомные разделы. В общем, в плане визуализации всё достаточно гибко.

Вкладка Reports:

В данной вкладке представлен функционал генерации различных стандартных отчетов в разных форматах. Также присутствует функционал создания кастомных отчетов.

Вкладка Incidents:

В данной вкладке представлены поступившие или сгенерированные системой инциденты. Есть функционал создания инцидента вручную. При нажатии на любой из ID инцидентов пользователь попадает во вкладку детальной информации (Layout) по выбранному инциденту, а именно — в стартовую панель Incident Info.

Панель Incident Info включает в себя основную информацию о типе, источнике, используемом плейбуке, выявленных индикаторах, а также о данных расследования инцидента.

В каждом Layout'e имеются стандартные панели:

  • Incident Info

  • War Room

  • Work Plan

  • Evidence Board

  • Related Incidents

  • Canvas

Layout'ы полностью кастомизируются под каждый тип инцидента.

Немного об остальных панелях детальной информации инцидента.

Панель War Room:

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

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

Вы могли заметить, что результаты выполнения процессов логирует DBot.

DBot — это бот для машинного обучения, который получает информацию об индикаторах, чтобы определить, являются они вредоносными или нет. Также он помогает упростить процесс расследования инцидента, сбора и анализа информации и артефактов, обнаруженных в записях War Room и полученной информации об угрозах от фидов, а также предлагает порядок действий на основе истории реагирования на похожие инциденты.

Панель Work Plan:

Панель Work Plan включает в себя плейбук, используемый для обработки данного типа инцидента. При нажатии на каждый из блоков задач (Task) плейбука пользователь может увидеть результаты её отработки и информацию о входных и выходных данных. Также можно вручную поменять плейбук на другой и сразу же его запустить.

Панель Evidence Board:

Данная панель хранит ключевые артефакты для текущего и будущего анализа. Пользователь может просматривать и управлять объектами улик, которые были обнаружены в War Room'e и обозначены как улики.

Панель Related Incidents:

Панель отвечает за визуальное представление инцидентов со схожими характеристиками. Просмотр связанных инцидентов в едином представлении позволяет консолидировать расследование за счет дедупликации и сопоставления связанных инцидентов с просматриваемым инцидентом. Связывание инцидентов помогает оценить эффективность предпринятых действий.

Панель Canvas:

Данная панель позволяет визуально отображать инцидент, его элементы и путь развития, сочетая аналитические данные с машинным обучением. В разделе «Add entity to canvas» система предоставляет рекомендуемые индикаторы и инциденты, которые могут быть связаны или иметь отношение к текущему инциденту.

Вкладка Indicators:

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

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

Вкладка Playbooks:

В данной вкладке пользователь может создавать и редактировать плейбуки (сценарии реагирования). Плейбуки представляют собой блок-схему последовательных/параллельных действий, которые в системе называются задачами (Tasks). Пользователь может как использовать стандартные задачи, так и создавать свои собственные. Также есть возможность настройки саб-плейбуков («плейбук в плейбуке»), что довольно удобно. Функционал плейбуков позволяет автоматизировать многие процессы безопасности, включая процесс расследования и управления заявками. Плейбуки очень удобно экспортируются и импортируются.

Вкладка Automation:

Вкладка представляет собой библиотеку скриптов, используемых системой для автоматизации различных задач как внутри системы, так и при работе со сторонними источниками. Скрипты пишутся на Python, JavaScipt или PowerShell. Вы можете запускать их как вручную, выполняя соответствующие команды в панели War Room, так и с помощью плейбуков, добавляя команды в виде блоков задач (Task). Как и в случае с плейбуками, скрипты легко экспортируются и импортируются.

Вкладка Jobs:

Данная вкладка включает в себя функционал создания/редактирования «джобов» — процессов, являющихся триггерами начала работы указанных в них плейбуков. Джобы могут срабатывать как по времени, так и при изменении содержимого фидов.

Вкладка Marketplace:

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

Последняя основная вкладка Settings включает в себя следующие разделы:

Раздел Integrations

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

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

Как и в случае с автоматизациями, интеграции пишутся на Python, JavaScript или PowerShell.

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

Раздел Users and roles

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

Раздел Advanced

Тут представлены подразделы, отвечающие за создание/редактирование сущностей, связанных с обработкой инцидентов (полей, типов инцидентов, типов индикаторов, карточек и т. п.).

Раздел About

Раздел включает в себя подразделы, отображающие данные о версии продукта, лицензии и информацию, помогающую в траблшутинге.

Выводы

Мне понравился гибкий механизм создания новых интеграций и их настройки из веб-интерфейса. Благодаря этому механизму не возникло никаких проблем в ходе настройки взаимодействия с внешними системами. Очень помогла подробная документация по настройке интеграций, в которой описаны все возможности скриптов «из коробки». Здорово, что решение обладает огромным пулом стандартных коннекторов к различным системам, которые доступны в Marketplace. Жаль, что пока там не представлены российские решения, но никто не мешает вам стать первым, кто опубликует их:) И конечно же, если вы хотите самостоятельно разрабатывать свои коннекторы, то как минимум нужно знание Python и Docker.

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

Я считаю, что WorkFlow в Cortex XSOAR очень гибкий. Решение имеет обширный функционал формирования сценариев обработки инцидентов и достаточно удобный функционал «drilldown» в саб-плейбуки.

Из минусов я бы отметил настройки безопасности, которые, как мне показалось, менее гранулярные в части разграничения доступа к объектам, чем у некоторых аналогов. Например, нет возможности предоставить доступ только к конкретным плейбукам или типам инцидентов. Также в системе нет встроенной CMDB для централизованного управления активами инфраструктуры, что может доставлять неудобства. Хотя, конечно, этот функционал можно реализовать с помощью интеграции с внешними CMDB.

В целом хочу сказать, что мне и моим коллегам продукт понравился. Надеюсь, статья была вам полезна. А чтобы сделать самостоятельные выводы — welcome тестировать :)

В качестве постскриптума — для тех, кому интересно — привожу правила лицензирования и информацию об архитектуре.

Правила лицензирования

Кратко о типах лицензий:

  • Cortex XSOAR Community Edition — бесплатная лицензия для внутреннего тестирования.

  • Cortex XSOAR Threat Intel Management — для компаний, которые нацелены на анализ угроз и при этом не нуждаются в частом кейс-менеджменте.

  • Cortex XSOAR Starter Edition — актуально для компаний, которым требуется неограниченный кейс-менеджмент, и при этом анализ угроз не является приоритетной задачей.

  • Cortex XSOAR — актуально для клиентов, которым нужно и то и другое в неограниченном объеме.

Бесплатную лицензию «Community Edition» можно получить, заполнив форму по ссылке. Данный тип лицензии имеет ограничения: 166 запусков автоматизаций (кроме запущенных по расписанию), генерация отчетов только по закрытым инцидентам, хранение инцидентов периодом в 30 дней, возможность получения до 5 активных фидов с ограничением в 100 индикаторов, срок действия лицензии составляет 1 месяц.

Для продажи продукт лицензируется по пользователям. В Cortex XSOAR представлены два типа пользователей: Audit user и Full user.

Audit user имеет разрешение только на чтение. Это означает, что у него нет возможности редактировать системные компоненты и данные, а также запускать команды, автоматизации и плейбуки. Audit user может просматривать инциденты, дашборды и отчеты.

С типом Full user всё просто — он имеет неограниченные права в системе.

Минимальный пакет лицензий начинается от двух пользователей, один из которых обязательно должен иметь тип Full user. По умолчанию в пакет уже входит весь необходимый функционал, а именно плейбуки и все возможные интеграции «из коробки», кастомные коннекторы также присутствуют. Ежегодное продление равно сумме закупки, то есть используется подписочная схема.

Архитектура, аппаратные и программные требования

Основные компоненты Cortex XSOAR — Server (компонент управления и обработки и хранения) и Engine (коллектор).

Ниже представлены аппаратные и программные требования к этим компонентам.

Требования к аппаратному обеспечению Cortex XSOAR Server:

Компонент

Минимальные требования для тестовой среды

Минимальные требования для продуктивной среды

CPU

8 cores

16 cores

RAM

16 GB

32 GB

HDD

500 GB SSD

1 TB SSD, минимум 3k IOPS

 Требования к аппаратному обеспечению Cortex XSOAR Engine:

Компонент

Минимальные требования для тестовой среды

Минимальные требования для продуктивной среды

CPU

8 cores

16 cores

RAM

16 GB

32 GB

HDD

20 GB SSD

20 GB SSD

 Требования к операционной системе:

Операционная система

Поддерживаемая версия

CentOS

7.x и 8

Ubuntu

16.04 и 18.04

RHEL

7.x и 8

Oracle Linux

7.x

Amazon Linux

2

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

Cortex XSOAR достаточно гибко сайзится, начиная от варианта «All in one» и заканчивая распределенными отказоустойчивыми инсталляциями.

Архитектурные возможности Cortex XSOAR позволяют использовать выделенную БД как в одиночной, так и в распределенной схеме для горизонтального масштабирования и отказоустойчивости.

Подробнее можно почитать по ссылке.

Бэкапирование и восстановление данных осуществляется по схемам Live Backup и Disaster Recovery. Подробнее — по ссылке:

Также представлена возможность использования схемы с отказоустойчивостью на уровне сервера приложений. Ниже представлен пример с выделенной одиночной БД.

В данном случае дополнительно понадобится выделить ресурсы под NFS-сервер (для синхронизации данных) и балансировщик.

Для multitenancy-инсталляций потребуется разделить главный сервер и хосты для необходимого количества тенантов. Ниже представлен пример отказоустойчивой multitenancy-инсталляции.

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

Подробнее c HA и multitenancy в Cortex XSOAR можно ознакомиться по ссылке

Комментарии (1)


  1. katerinazaber
    16.02.2022 14:14
    +2

    Спасибо, крутая статья