Тенанты в KUMA (Multitenancy)

Термины

• Multitenancy — "множественное владение", использование общих ресурсов разными пользователями изолировано друг от друга. 
• Tenant (тенант) —  огранизация / филиал организации (в рамках KUMA).
• General tenant — основной тенант (Main), который имеет доступ ко всем данным и настройкам своих филиалов, может осуществлять централизованное управление филиалами.

Права на создание нового и редактирование существующего тенанта — только у пользователя с ролью General admin.

Для редактирования ресурсов в определенном тенанте, помимо прав администратора тенанта добавьте еще права аналитика к УЗ 

Отключить GeneralMain тенант нельзя (можно переименовать), так как некоторые разделы в KUMA доступны только ему, например, Audit события KUMA складваются только в нем.

Принцип работы

KUMA Core (ядро SIEM) — это web консоль и компонент управления всеми микросервисами KUMA. В каждой инсталляции один сервер Core. Все остальные микросервисы можно распределять по инфраструктуре, как удобней,удобно, даже без разделения по тенантам. 

Разделение по тенантам позволяет регулироватьразграничить доступ пользователей KUMA кпо темсобытиям или(как инымбазовым событиям,так правилами корреляционным), контенту (правила парсинга, корреляции и т.п.д.). Например,Тенант может бытьназначаться такаяКоллектору архитектураили –Коррелятору, тенанты,а изолированныеХранилищу другможно отназначить другаТенант на(если уровнеэто архитектурно тербуется), когда оно отдельное со своими дисками и мощностями.

Ниже схематично представлен путь событий ив сетевогоединое взаимодействия.Хранилище (Тенант Main), где пользователь Тенанта А может видеть только свои события (Тенанта А):

В этомслучае случаеиспользования нескольких Тенантов в Core  находятся только конфигиконфигурации для всех микросервисов и алерты со всех тенантов. Пользователи подключаются к Core и отправляют поисковые запросы к хранилищам своих тенантов. Но при этом в Core летят не все события, а только результаты поиска пользователей. Трафик в этом случае минимальный. Одна Core обеспечивает единую точку администрирования всей инфраструктуры KUMA.

Отдельные Коррелятор и/или Хранилище имеет смысл если не хочется значительно нагружать каналы связи между Головным офисом и Филиалом, либо архитектурные / организационные требования.

Кросс-тенантный коррелятор

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

Ресурсы, используемые в корреляторе, должны принадлежать тому же тенанту,тенанту , что и сам коррелятор.коррелятор Иначе(т.е. приправила сохранениикорреляции системаиз будетТенанта выдаватьА ошибку.могут прилинковаться к коррелятору Тенанта А). Исключение Shared тенант, ресурсы общего тенанта могут быть использованы в любом корреляторе.