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

Термины

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

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

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

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

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

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

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

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

Пользователи подключаются к Core и через него отправляют поисковые запросы в хранилище (или хранилища) своего тенанта.

Выбор тенанта производится в соответсвующем разделе:

Core выступает единой точкой администрирования всей инфраструктуры KUMA, при этом в Core передаются не все события, а только результаты поисковых запросов пользователей, поэтому сетевой трафик минимален.

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

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

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

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