Overview of Multi-tenancy support in FortiSOAR

FortiSOAR provides additional features and out-of-the box configuration for a multi-tenant environment, enhancing its native support for multi-tenancy for managed security services providers (MSSPs). The FortiSOAR platform supports multi-tenancy in either of the following forms as well as a hybrid of both forms:

• Distributed Tenancy support: Used by MSSPs to provide services to remote tenants. In this case, each tenant will have its own FortiSOAR instance that will also automatically communicate to a master FortiSOAR instance having visibility across all the tenants. For more information, see the Distributed Tenancy Support chapter.
• Shared Tenancy support: Used by master (teams like the SOC team) to provide services to local tenants. In this case, you have only a single FortiSOAR instance, wherein multiple tenants will access a single FortiSOAR instance. For more information, see the Shared Tenancy Support chapter.

When multi-tenancy is enabled for the FortiSOAR platform, all alerts, incidents, and other forms of records created are associated with a tenant. RBAC and ownership rules applied to each tenant govern who has visibility to which records, thereby restricting visibility of one tenant's records to the other, but at the same time, providing the service provider a single consolidated view across tenants.

From version 6.4.1 onwards, tenants act like a wrapper that can contain multiple agents, which can connect to various disparate networks and remotely execute action. In the case of dedicated tenants, a default agent is automatically created and added to the dedicated tenant as part of the tenant creation process. In the case of shared tenancy, you do not require to create an agent for that tenant, since everything in case of a shared tenant runs on the master instance only using the master agent. If you require to run some actions on a separate network, then you can add and configure another agent, associate that with the shared tenant. The RBAC of this agent will be controlled by correct team assignment. Further, you can also add multiple agents to both shared and dedicated tenants. For more information on agents and how to run remote actions using agents, see the Segmented Network support in FortiSOAR chapter in the "Administration Guide."

Licensing for Multi-Tenancy

For multi-tenancy support, you require a FortiSOAR license that has been enabled for multi-tenancy. Therefore, when you are generating a license in FortiCare, ensure that you generate a license that has multi-tenancy support, i.e., a license with edition set to "MT | MT_Tenant". For more information about licensing, see the Licensing FortiSOAR chapter in the "Deployment Guide."

For a master node, you will be issued a license with type "MT" (master), and for a tenant node, you will be issued a license with type "MT_Tenant" (tenant). You can deploy the FortiSOAR license using the FortiSOAR Admin CLI (csadm) as follows:

SSH to your FortiSOAR VM and login as a root user and run the # csadm license --deploy-multi-tenant-license <License File Path> command, for a license that is enabled for multi-tenancy. For more information on csadm, see the FortiSOAR Admin CLI chapter in the "Administration Guide."

You will see a Multi Tenancy section in your System page by clicking the Settings icon on the top-right corner of FortiSOAR, only if your FortiSOAR license has been enabled for multi-tenancy.

After your license is deployed, FortiSOAR runs a Publish on the instance. If during this time, you try to open the FortiSOAR UI, you might see a "Publish In Progress" message. Also, you cannot revert the environment to a non-multitenant environment once you have deployed the license.

Notes for upgraded multi-tenant configurations

• You can upgrade a FortiSOAR distributed multi-tenant configuration to 7.3.1 from 7.2.1 or 7.2.2 only. For the upgrade procedure, see the "Upgrade Guide."
• In case of a distributed deployment, both the master and the tenant nodes must be upgraded. A version mismatch will not work if either of them upgrades to 7.3.1.
• From version 6.4.1 onwards, each dedicated tenant automatically creates an agent that can be used to remotely execute actions. You can add multiple agents to a tenant, therefore, tenants become a wrapper that can contain various agents that can connect to various disparate networks. For more information on agents, see the Segmented Network support in FortiSOAR chapter in the "Administration Guide."

Recommended Resource Requirements for Virtual Machines (VM)

For Master and Tenant

Minimum Specifications

• 8 available vCPUs
• 22 GB available RAM
• 500 GB available disk space: Recommended to have high-performance storage, preferably SSDs.
• 1 vNIC

Recommended Specifications

• 8 available vCPUs
• 32 GB available RAM
• 1 TB available disk space: Recommended to have high-performance storage, preferably SSDs.
• 1 vNIC

For Secure Message Exchange

Minimum Specifications

• 4 available vCPUs
• 8 GB available RAM
• 100 GB available disk space: Recommended to have high-performance storage, preferably SSDs.
• 1 vNIC

Recommended Specifications

• 8 available vCPUs
• 16 GB available RAM
• 100 GB available disk space: Recommended to have high-performance storage, preferably SSDs.
• 1 vNIC

Architecture

The overall architecture of the FortiSOAR Distributed Multi-Tenancy Model:

A brief description of how FortiSOAR supports the Distributed Multi-Tenancy model follows:

• A master FortiSOAR node is installed and configured at the MSSP (Service Provider) location.
• A FortiSOAR tenant node is installed and configured for each tenant (customer) location, same as configured for the master node.
  Note: Each of these FortiSOAR installations (both master as well as tenants) are fully functional standalone instances. They are additionally enabled for automatic replication of data between them, and also for remotely executing workflows at the tenant node from the master node itself.
  • Communication between the master and tenant nodes are done over a secure channel using the Secure Message Exchange.
    Each tenant node communicates with the secure message exchange on a dedicated space that is access controlled with credentials that are unique to each tenant.
    The secure message exchange ensures a guaranteed message delivery irrespective of whether the target node is up or not at the time the message is sent. The messages are queued and delivered to the target node once it comes online. This prevents message loss during network disruptions.

An example: The master FortiSOAR node is monitoring the tenants' FortiSOAR instance, and if for example, the investigation requires to run a playbook to get the reputation of a particular IP address from the tenants' end, then this facility allows the master node to run the playbook remotely at the tenant's end. The playbook will be run at the tenant node, using the tenant's credentials, for the 3rd-party connector for checking the IP reputation, and the remediation actions (if any), specified in the playbook, will also be done on the tenants' end.