End-of-Life (EoL)
Multi-Tenant Overview
Cortex XSOAR multi-tenant deployments for MSSPs that
require strict data segregation between tenant accounts
Cortex XSOAR multi-tenant deployments
are designed for MSSPs that require strict data segregation between
tenant accounts and the flexibility to easily share critical security
data to those tenant accounts, such as known malicious/benign indicators.
Multi-tenancy also enables MSSPs to manage many tenants from
a single console and to easily switch between tenant environments
and from a tenant environment to the main environment, where the
MSSP can get a bird’s-eye, global view status, for example, all
open incidents and indicators across all tenants.
Who Should Use Multi-Tenancy?
Large enterprises that have multiple SOCs often also
consider using multi-tenancy, however, in most cases we do not recommend
it. The main reason is that enterprise customers expect some degree
of collaboration between the SOCs, which, in many respects contradicts
the product’s architecture. We therefore suggest in most cases not
to use XSOAR multi-tenancy for enterprises and instead use XSOAR
Enterprise with proper RBAC implementation and where necessary add additional
single servers (e.g., one server per SOC). There are exceptions
to these recommendations and we encourage you to consult with XSOAR
product managers and customer success to discuss your requirements.
Multi-Tenancy Limitations
When using XSOAR multi-tenancy in an enterprise setting
there are several limitations that can negatively impact the enterprise
productivity.
- Complete isolation among tenants. This means that data is not easily shared between tenants. For example, collaborating on an incident requires extra steps (such as mirroring between tenants).
- Tenants cannot change definitions that were set by the main account (e.g., playbooks, etc.).
- Multi-tenancy architecture is more complex than XSOAR Enterprise server architecture. It requires heavier IT and computing resources. In general, server maintenance is more difficult and requires a strong IT team.
- For example, re-indexing a single tenant is a complex procedure and troubleshooting is often very complex.
- Backup and restore, as well as the DR mechanism are more complex than single server deployments.
- Since MT environments are more complex, some infrastructure features are introduced only after they are introduced in Enterprise environments.
Multi-Tenancy Architecture
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.
Engines
Direct access to remote networks might be blocked by
network devices, such as proxies or firewalls. Cortex XSOAR Engines
are installed in a remote network and act as proxies, which enable
you to access those remote networks. You can install a single engine,
or multiple engines, as a load-balancing group.In MSSP networks,
engines are often used to enable the network connectivity between
the MSSP’s network and the customer’s local network. Therefore,
the engines are installed within the customer’s networks (normally
on a local VM situated either in the customer’s DMZ or the security
management network) and are programmed to communicate directly to
the MSSP’s main server. Once the communication starts a bi-directional
tunnel is created between the MSSP and the customer’s network allowing
the MSSP to connect to the customer’s relevant resources (e.g. AD,
mail server, firewall management server, etc.).
Recommended For You
Recommended Videos
Recommended videos not found.
