Multi-Tenancy Architecture
The components of a multi-tenant deployment and the architecture
of how the components communicate and interact.
Multi-tenancy architecture is based on
the platform’s ability to run multiple instances (processes and
data) of the XSOAR server on a single server. Each deployment consists
of a main server and tenant accounts. All tenant accounts can reside
on the same (main) server or an MSSP can choose to run tenants on
additional hosts. Tenants are deployed across hosts for several
reasons.
- Scalability: full horizontal scalability - when a server or host is maxed out due to an excess of tenants on the same host, MSSPs can add another host on which to run tenants. MSSPs can easily move tenants between hosts.
- Geography: a global MSSP may have customers in multiple countries or even continents. To increase responsiveness, the MSSP may choose to locate a host or multiple hosts in each location.
- Compliance: in some cases MSSPs are asked to run the tenant within the country where the customers’ offices are located or even within the customer’s internal network. For the latter, XSOAR supports installing a single host running a single tenant that can be installed on the customer’s premises.
Components
Main host
The main host is the main instance in the architecture, from
which you access and administer tenants (accounts), and create and
manage hosts.
Host
A host is an instance of Cortex XSOAR that acts as a proxy between
the main host and tenants. In a multi-tenant deployment, hosts are
not required, but enable you to scale your deployment by managing
a collection of tenants. Data is not stored on host machines.
Tenant
A tenant is also an instance of Cortex XSOAR which serves a customer,
or account, and can be located either on the main or other hosts.
The tenant has customer-specific data such as indicator, incidents,
layouts, etc. which is stored in the tenant’s index of the database.
Tenants share indicators with the main host using a shared database
index. The tenant can also inherit content, such as playbooks, indicators,
incident types, etc. from the main host using propagation labels.
Engines
Engines are smaller installations of Cortex XSOAR that are used
to enable communication between 3rd-party integrations, which might
sit in a different part of the network or might be blocked through
firewalls, and the main host. Engines can be installed on their
own or as part of an engine group, which distributes the load from
an integration, or several integrations, between multiple engines.
Data Segmentation
Cortex XSOAR content, including playbooks, automation
scripts, incident/indicator layouts, among others, are managed on
the main host and propagated to tenants.
Indicator Sharing
Each tenant account has a dedicated shared index in Elasticsearch,
which enables tenant accounts to share local indicators to a dedicated
Elasticsearch index, from which other tenants can ingest those indicators
(as configured on the main host). By storing local indicators on
a shared index, data segregation is maintained between tenants,
but they are able to benefit from the locally discovered threat intel.
Communication
The main host and hosts communicate with each other
using TLS 2.1 over port 443 (this is the default port, but can be
configured). In addition, all hosts working with Elasticsearch communicate
with the database over port 9200.
Requests to the tenants are sent through the hosts (main or other)
on port 443. The hosts forward the requests to the tenants, which
listen on ports 18501 and higher.
