Multi-Tenancy (Advanced)

Configuring Database User Accounts

SQL Server

Since Multi-Tenancy requires the ability for the software to create databases, the dbcreator role is required on SQL Server. For example:

For the user role of the primary Tenant, it is important to assign DB owner to the main database:

If desired, you can further refine the rights to include only the ability to modify the schema and access the data.

With the dbcreator role, the databases created by the account will automatically be owned by the same user. For example, here are the properties for the user after the first Tenant has been created:

To create the first account on a secondary database server, only the dbcreator server role is required. No user mapping has to be defined.

Oracle

Multi-Tenancy in Oracle is similar to SQL Server but with a few important differences. Where SQL Server has a single user account per database server, Oracle uses one user account per Tenant. The user that Deep Security was installed with maps to the primary Tenant. That user can be granted permission to allocate additional users and tablespaces.

If Multi-Tenancy is enabled, the following Oracle permissions must be assigned:

Tenants are created as users with long random passwords and given the following rights:

For secondary Oracle servers, the first user account (a bootstrap user account) must be created. This user will have an essentially empty tablespace. The configuration is identical to the primary user account.

APIs

Deep Security Manager includes a number of REST APIs for:

1. Enabling Multi-Tenancy
2. Managing Tenants
3. Accessing Monitoring Data
4. Accessing Chargeback (Protection Activity) Data
5. Managing Secondary Database Servers

In addition the legacy SOAP API includes a new authenticate method that accepts the Tenant Account Name as a third parameter.

For additional information on the REST APIs please see the REST API documentation.

Upgrade

Upgrade is unchanged from previous versions. The installer is executed and detects an existing installation. It will offer an upgrade option. If upgrade is selected the installer first informs other nodes to shutdown and then begins the process of upgrading.

The primary Tenant is upgraded first, followed by the Tenants in parallel (5 at a time). Once the installer finishes, the same installer package should be executed on the rest of the Manager nodes.

In the event of a problem during the upgrade of a Tenant, the Tenant's State (on the Administration > Tenants page) will appear as Database Upgrade Failed (offline). The Tenants interface can be used to force the upgrade process. If forcing the upgrade does not work please contact support.

Supporting Tenants

In certain cases, a Primary Tenant may require access to a Tenant's user interface. The Tenants list and Tenant properties pages provide an option to "Authenticate As" a given Tenant, granting them immediate read-only access.

Users are logged in as a special account on the Tenant using the prefix "support_". For example, if Primary Tenant user jdoe logs on as a Tenant, an account is created called "support_jdoe" with the "Full Access" role. The user is deleted when the support user times out or signs out of the account.

The Tenant can see this user account created, sign in, sign out and deleted along with any other actions in the System events.

Users in the primary Tenant also have additional diagnostic tools available to them:

1. The Administration > System Information page contains additional information about Tenant memory usage and the state of threads. This may be used directly or helpful to Trend Micro support.
2. The server0.log on the disk of the Manager nodes contains additional information on the name of the Tenant (and the user if applicable) that caused the log. This can be helpful in determining the source of issues.

In some cases, Tenants will require custom adjustments not available in the GUI. This usually comes at the request of Trend Micro support. The command line utility to alter these settings accepts the argument:

-Tenantname "account name"

to direct the setting change or other command line action at a specific Tenant. If omitted, the action is on the primary Tenant.

Load Balancers

By default, multi-node Manager provides the address of all Manager nodes to all agents and virtual appliances. The agents and virtual appliances use the list of addresses to randomly select a node to contact and continue to try the rest of the list until no nodes can be reached (or are all busy). If it can't reach any nodes, it waits until the next heartbeat and tries again. This works very well in environments where the number of Manager nodes is fixed and avoids having to configure a load balancer in front of the Manager nodes for availability and scalability.

In Multi-Tenant environments, it may be desirable to add and remove Manager nodes on demand (perhaps using auto-scaling features of cloud environments). In this case, adding and removing Managers would cause an update of every agent and virtual appliance in the environment. To avoid this update, the load balancer setting can be used.

Load balancers can be configured to use different ports for the different types of traffic, or if the load balancer supports port re-direction it can be used to expose all of the required protocols over port 443 using three load balancers:

In all cases, the load balancer should be configured as TCP load balancer (not SSL Terminating) with sticky-sessions. This ensures a given communication exchange will happen directly between Agent/Virtual Appliance and the Manager from start to finish. The next connection may balance to a different node.

Multi-Tenant with Deep Security Virtual Appliance

If Deep Security is being deployed in a VMware environment, it is possible to configure the vCenter and vShield connector in the Primary Tenant and the vCloud connector in Tenants. If this is configured properly, the Primary Tenant sees the ESXi servers, Deep Security Virtual Appliances and other infrastructure components while Tenants only see the VMs that belong to them in the vCloud environment. They can further activate these VMs without deploying any agent technology.

To enable this type of environment, you must go to Administration > System Settings > Agents and select the Allow Appliance protection of vCloud VMs checkbox.

For more information on vCloud integration, see the Installation Guide.

Technical Details

Each Tenant database has an overhead of around 100MB of disk space (due to the initial rules, policies and events that populate the system).

Tenant creation takes between 30 seconds and four minutes due to the creation of the schema and the population of the initial data. This ensures each new Tenant has the most up to date configuration and removes the burden of managing database templates, especially between multiple database servers.