Learn about Cortex XSOAR multi-tenant deployments that provide data segregation while enabling you to manage multiple tenants from a main tenant.
Cortex XSOAR multi-tenant is designed for managed security service providers (MSSPs) that require strict data segregation, but also need the flexibility to share and manage critical security practices across tenants.
Note
This multi-tenant module should be read in conjunction with the Cortex XSOAR on-prem documentation, as most of the features apply to multi-tenant.
The following options are available for multi-tenants:
Option | Description |
|---|---|
Multi-tenant for MSSPs | A multi-tenant deployment enables MSSPs to manage multiple tenants and maintain complete data separation if needed. You can centrally manage resources and reporting from the main tenant, push custom content to one or more tenants, search across incidents from multiple child tenants, and run commands across multiple child 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 main and child tenants. Each customer is a tenant, and the data for each child tenant is stored separately. Specific content for individual tenants is created on the tenant level, and content common to multiple tenants is pushed from the main tenant. The MSSP can provide customers with direct access to their child tenant, on a read-only or read/write basis. |
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. However, in some cases, you may want to use a multi-tenant deployment where you have a large enterprise with multiple divisions but with one centralized SOC managing those divisions. We encourage you to consult with the Cortex XSOAR Customer Success team to discuss your business use case. Example Use Case A large enterprise has acquired multiple business divisions. Each division has a separate database, but the enterprise maintains one centralized SOC to manage all incidents. NoteWhen using Cortex XSOAR multi-tenant for enterprise:
|
Multi-tenant architecture
Multi-tenancy architecture is based on the platform’s ability to run separate instances (processes and data) of Cortex XSOAR, linking each child tenant to a main tenant. Each deployment consists of a main tenant and child tenants.
Component | Description |
|---|---|
Main Tenant | The main tenant, also referred to as the parent tenant, is used to access and administer your environment. Analysts with permissions can view and edit child tenant data directly from the main tenant or can easily switch to work directly on the child tenant. Content configured on the main tenant can be shared with some or all tenants, using propagation labels. The main tenant communicates over a secure SSL channel. If the child tenant has a self-signed certificate, you can use it for secure communication instead of SSL. For more information, see Use a signed certificate instead of SSL verification. |
Child tenant | A child tenant is an instance of Cortex XSOAR that serves an end customer, such as the customer of an MSSP, and is associated with the main tenant. Each tenant has customer-specific data such as indicators, incidents, and layouts, which are stored separately. |
Note
The multi-tenant license includes a main tenant. You can install as many child tenants using the installer.
Engines
Engines are installed on a remote network and act as proxies, which enable you to access remote networks. They enable communication between the Main Tenant and third-party integrations, which might be located in a different part of the network or be blocked through a firewall. 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 end customer’s local network. The engines are installed within the customer’s networks (normally on a local virtual machine situated either in the user's DMZ or the security management network) and are programmed to communicate directly with the main tenant. 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 (for example, AD, mail server, and firewall management server).
Multi-tenant deployment
Multi-tenancy enables you to install the main tenant and child tenants from the Cortex Gateway and then manage the child tenants from the main tenant.
In the main tenant (Main Account), you can see all incidents and indicators across all child tenants. You can create integrations and scripts for use across multiple child tenants, run commands across multiple child tenants, and switch easily between tenant environments.
Cortex XSOAR provides complete data segregation between customers in a multi-tenant deployment, and no incident or indicator data is stored on the main tenant. Each child tenant runs separately, 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 tenant level and pushed to tenants or is created within individual child tenants. Content packs are always installed on the main tenant and pushed to child tenants. You can define propagation labels per child tenant, which allows you to selectively push content to the required child tenants.
Role Based Access Control (RBAC)
Comprehensive RBAC for analysts and customer accounts enables different levels of access for MSSP and customer admins. RBAC is used at the main tenant level and the child tenant level to ensure the correct access.
In Cortex XSOAR on-prem MSSP, the users and roles of the child tenant are inherited from the user group set up in the Main Tenant. In the user group from the main tenant, the Available Tenants include the list of child tenants that are paired with the main tenant.
These are the options for managing roles and user groups:
Roles, users and user groups inherited from the main tenant, cannot be edited in the child tenant.
When logging into a child tenant with user and password configured in the main tenant, you cannot update the password in the User Details tab of the User Preferences settings. All fields are disabled.
Users created in child tenants, regardless of the linked user group, can only access the child tenant they were created in ( they can assume a user group or a role propagated from the main tenant).
If you are using single sign-on, the mapping between your SSO provider and Cortex XSOAR is done through user groups.
Note
SSO authentication configuration is not distributed to child tenants from the main tenant. This should be configured per child tenant.