Multi-Tenant Overview
Cortex XSOAR multi-tenant deployments for Managed Security
Service Provider (MSSPs) that require strict data segregation between
tenant accounts.
Cortex XSOAR multi-tenant deployments
are designed for MSSPs (managed security service providers) and
enterprises that require strict data segregation, but also need
the flexibility to share and manage critical security practices
across tenant accounts.
Multi-tenancy enables you to manage multiple tenants from a single
console. From the main account, you have a bird’s-eye view of all
incidents and indicators across all tenants. You can create integrations
and scripts for use across multiple tenant accounts, run commands
across multiple tenant accounts, and switch easily between tenant
environments.
Cortex XSOAR provides complete data segregation between customers
in a multi-tenant deployment, and no incident data is stored on
the main account. Each tenant runs as a separate process, and the
data separation meets data privacy standards and compliance requirements.
In a multi-tenant deployment, content is either created or modified
at the main account level and pushed to tenants or is created within
individual tenant accounts. Marketplace content packs are always
installed on the main account and pushed to tenant accounts. You
can define propagation labels per tenant, which allow you to selectively
push content to one or more tenants. With a Threat Intel Management
license and Elasticsearch, indicators can be shared across tenant
accounts, saving investigation time and making it easy to block
bad actors across your MSSP or enterprise.
Multi-Tenant for MSSPs
A multi-tenant deployment enables MSSPs to manage multiple
accounts and maintain complete data separation if needed. You can
centrally manage resources and reporting from the main account,
push custom content to one or more tenants, search across incidents,
and run commands across multiple tenants, without exposing any data
across tenants.
Example Use Case
An MSSP has a pool of analysts in a central SOC. The analysts
operate at the master and the tenant level. Each customer is a tenant,
and the data for each tenant account is stored separately. This
MSSP’s customers require keeping all data on-prem, so their deployment
has only one tenant per host. Content specific to individual tenants
is created on the tenant level, and content common to multiple tenants
is pushed from the main account. The MSSP can provide customers
with direct access to their tenant account, on a read only or read/write
basis. The MSSP uses a Threat Intel Management license and Elasticsearch
to share indicator information across multiple tenant accounts.
Multi-Tenant for Enterprise
For most large enterprises, we recommend Cortex XSOAR
Enterprise with RBAC implementation since this deployment can accomplish
the majority of data segregation requirements. In some cases, however,
a large enterprise with multiple divisions but with one centralized
SOC managing those divisions may want to consider a multi-tenant
deployment. We encourage you to consult with Cortex XSOAR product
managers and the customer success team to discuss your business
use case.
When using Cortex XSOAR multi-tenancy in an enterprise setting
there are several limitations:
- Data is not easily shared between tenants. For example, collaborating on an incident requires extra steps (such as mirroring between tenants). The exception is indicator data which can be shared if you have a Cortex XSOAR Threat Intel Management license and have a multi-tenant deployment with Elasticsearch.
- Tenants cannot change definitions that were set by the main account (e.g., playbooks, etc.).
- Multi-tenancy architecture is more complex than Cortex XSOAR Enterprise server architecture and requires greater IT and computing resources. Also, server maintenance is more complex, since all accounts on a server may be affected when maintenance is performed on the server.
Example Use Case
A large enterprise has acquired multiple business divisions in
different geographic regions. Each division has a separate database,
but the enterprise maintains one centralized SOC to manage all incidents.
Hosted Service
Cortex XSOAR offers a hosted service for multi-tenant
deployments. Multi-tenant hosted accounts are only available
for Enterprise, and are not available for MSSPs (managed security
service providers). The Cortex XSOAR hosted service enables you
to use Cortex XSOAR for security orchestration, incident management,
and investigation, without the infrastructure required for a multi-tenant
on-premise deployment. Palo Alto Networks provides the service infrastructure
layer, and you manage only the Cortex XSOAR application.
Multi-Tenancy Architecture
Multi-tenancy architecture is based on the platform’s
ability to run multiple instances (processes and data) of XSOAR 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 you can choose to run tenants on additional hosts. While tenant
incidents can be searched from the main account, no incident data
is stored on the main account.
Multi-tenant can be deployed with the Bolt database or Elasticsearch
(which offers the option of High Availability, using multiple app
servers).
BoltDB Architecture
Elasticsearch Architecture
High Availability Architecture
From Cortex XSOAR 6.1 and later, you can implement a multi-tenant high
availability deployment. High availability keeps your system
running even if one component of the system fails. To enable high
availability (HA) in Cortex XSOAR, you must install Cortex XSOAR with Elasticsearch with
multiple app servers or migrate to Elasticsearch with multiple
app servers.
Main Account
The main account is used to access and administer your environment.
Analysts can use the main account UI to access any tenant they have
permissions for, and content configured in the main instance can
be shared with some or all tenants. The main account and the hosts
communicate over a secure SSL channel.
Tenants
A tenant, also known as an account, is an instance of Cortex
XSOAR which serves a customer and can be located either on the main
host or other hosts. Each tenant must meet the hardware requirements
of CPU, memory, and storage for Cortex XSOAR. Tenants have their
own database partitions on the host. For Elasticsearch, each tenant
has its own index in the cluster.
Each tenant has customer-specific data such as indicators, incidents,
layouts, etc. stored separately (for Bolt deployment, different
partitions, for ES different indexes).
Hosts
Hosts are proxy servers that host tenants, and that allow the
main server access to the tenant accounts. Hosts are physical Cortex
XSOAR instances located across your deployment. You should use hosts
for horizontal scaling and distributed architecture.
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, multi-tenant deployments can add another host on which to run tenants. You can move tenants between hosts.
- Geography: You may have customers or corporate divisions in multiple countries or even continents. To increase responsiveness, you may choose to locate a host or multiple hosts in each location.
- Compliance: In some cases, for regulatory reasons, you might be required to run the tenant within the country where an office is located or even within a client or division’s internal network. For the latter, XSOAR supports installing a single host running a single tenant that can be installed on premises.
Engines
Cortex XSOAR Engines are installed in a remote network
and act as proxies, which enable you to access remote networks.
They enable communication between 3rd-party integrations, which
might sit in a different part of the network or 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.
In multi-tenant deployments, engines are often used to enable
the network connectivity between an 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 Cortex XSOAR account. 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.).
Each tenant has its own public key which the engines use to connect
directly to the tenants.
RBAC
The system supports two basic types of users: local
users that are created and managed within the system, and network-account
users that are authenticated against a mapped user-group membership
within an external directory service or other user-management system
by means of a configured integration.
Comprehensive RBAC (Role Based Access
Control) for analysts and customer accounts enables different levels of
access for MSSP and customer admins. RBAC is used at both the master
level and the host level to ensure the correct access.
Roles can be defined at the master or tenant level. If a role
is used by multiple tenants, it is defined at the master level.
If there is specific role behavior per tenant, the role is defined
at the tenant level. For example, if an analyst on tenant A needs
different permissions than an analyst on tenant B, those roles are
created at the tenant level.
