Prepare a database for Deep Security Manager

You can watch Deep Security 12 - Database Considerations on YouTube to review the database requirements, configuration, and authentication setup.

Before you install Deep Security Manager, you must prepare a database for Deep Security Manager to use. Refer to your database provider's documentation for instructions on database installation and deployment, but also consider the following for integration with Deep Security:

Check the Hardware requirements.
Choose your database type. For a list of supported databases, see Database.

Depending on which database you choose, see Microsoft SQL Server, Oracle Database, or PostgreSQL recommendations.

Microsoft SQL Server Express is supported only in limited deployments. For details, see Microsoft SQL Server Express considerations.
Synchronize both time and time zone. Use the same time source on both the database and Deep Security Manager servers.
Allow network connections between Deep Security Manager and the database. See Port numbers, URLs, and IP addresses.

During installation, enter the database connection and authentication credentials for the database that you have prepared.

After installation, see Database maintenance.

Hardware requirements

Dedicated server

The database should be installed on a dedicated server that is separate from the manager nodes. It is also important that the database and the Deep Security Manager be co-located on the same network with a 1 GB LAN connection to ensure unhindered communication between the two. (WAN connections are not recommended.) The same applies to additional Deep Security Manager nodes. 2 ms latency or less is recommended for the connection from the manager to the database.

To achieve this if you install the manager and database on VMs, make sure they are always run in the same ESXi host.

In the vCenter Web Client, go to Host and Clusters and select the cluster.
Go to the Manage tab and click VM/Host Rules > Add.
Type a name for the rule.
Select Enable rule.
From Type select Keep Virtual Machines Together.
Click Add and select the manager and database VMs.

Database load balancing, mirroring, and high availability (HA) is recommended for scalability and service uptime. See documention for vendors such as Amazon Aurora, PostgreSQL, and Microsoft SQL Server.

Use database mirroring with HA, not database replication. Failover must not change the database schema. Some types of replication add columns to database tables during replication, which changes the schema and causes critical database failures.

For databases hosted in the cloud, multiple availability zones ("multi-AZ") can increase network latency, and are not recommended.

Hardware recommendations

Many Deep Security Manager operations (such as updates and recommendation scans) require high CPU and memory resources. Trend Micro recommends that each manager node has four cores and sufficient RAM in high scale environments.

The database should be installed on hardware that is equal to or better than the specifications of the best Deep Security Manager node. For the best performance, the database should have 8-16 GB of RAM and fast access to the local or network attached storage. Whenever possible, a database administrator should be consulted on the best configuration of the database server and a maintenance plan should be put in effect.

Microsoft SQL Server

General requirements

You must create an empty database that will be used by Deep Security.
Enable "Remote TCP Connections"(see https://docs.microsoft.com/en-us/previous-versions/bb909712(v=vs.120)?redirectedfrom=MSDN).
Grant db_owner rights to the Deep Security Manager's database user.

If you use Microsoft SQL Server, Deep Security Manager must connect as either a Microsoft Active Directory domain or SQL user. Windows workgroup authentication is no longer supported.

Transport protocol

The supported transport protocol is TCP for newly-installed versions of Deep Security 10.2 or later versions.
If you are upgrading from Deep Security 10.1 or a previous version and you are using a named pipe as the transport protocol, DSM will continue to use a named pipe when you upgrade. Trend Micro recommends that you use TCP and encrypt communications. (See Encrypt communication between the Deep Security Manager and the database.)

Oracle Database

Start the "Oracle Listener" service. Verify that it accepts TCP connections.
Don't use special characters in Deep Security Manager's database user name. Although Oracle allows special characters when configuring the database user object if they are surrounded by quotes, Deep Security does not support special characters for the database user.
Grant the CONNECT and RESOURCE roles and UNLIMITED TABLESPACE, CREATE SEQUENCE, CREATE TABLE and CREATE TRIGGER permissions to the Deep Security Manager's database user.
If using multi-tenancy, also grant CREATE USER, DROP USER, ALTER USER, GRANT ANY PRIVILEGE and GRANT ANY ROLE to the Deep Security Manager's database user.
Oracle container database (CDB) configuration is not supported with Deep Security Manager multi-tenancy.

Oracle RAC (Real Application Clusters) support

Deep Security supports:

SUSE Linux Enterprise Server 11 SP3 with Oracle RAC 12c Release 1 (v12.1.0.2.0)
Red Hat Linux Enterprise Server 6.6 with Oracle RAC 12c Release 1 (v12.1.0.2.0)

The default Linux Server Deep Security policy is compatible with the Oracle RAC environment, with the exception of Firewall settings. You can disable Firewall or customize the Firewall settings according to the instructions in Firewall settings with Oracle RAC.

Database maintenance

Database maintenance is necessary to ensure the health of your Deep Security deployment.

Index maintenance

To improve Deep Security Manager performance, we recommend that you perform regular index maintenance on the Deep Security database to keep it from becoming overly fragmented. Follow your organization's best practices for reindexing databases, or refer to your database vendor's documentation for guidance:

PostgreSQL: See https://www.postgresql.org/docs/10/sql-reindex.html for details on the PostgreSQL reindex command. Note that this command will block some operations, so it’s best to run it offline, during upgrades. When run offline on a previous snapshot, it takes approximately 45 minutes to complete.
Microsoft SQL: Refer to documentation from Microsoft for index maintenance best practices: https://docs.microsoft.com/en-us/sql/relational-databases/indexes/reorganize-and-rebuild-indexes?view=sql-server-ver15.
Oracle Database: Follow Oracle’s best practices on managing indexes. For example, see https://docs.oracle.com/cd/B28359_01/server.111/b28310/indexes002.htm#ADMIN11713.

There are also open source websites that provide scripts that can help you with this task.

Backups and disaster recovery

Separate from high availability or load balancing, best practices include regular database backups and a disaster recovery plan. Backups can be used to restore the database if there is a serious failure. See your vendor's documentation and Back up and restore your database.

For PostgreSQL databases, basic tools like pg_dump or pg_basebackup are not suitable to back up and restore in an enterprise environment. Consider other tools such as Barman.