Prepare a database for Deep Security Manager
Before you install Deep Security Manager, you must prepare a database and user account 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 considerations.
- 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 for database-specific considerations.
Microsoft SQL Server Express is supported only in certain limited deployments. For details, see Microsoft SQL Server Express considerations.
- For high availability, the Deep Security database is compatible with database failover protection so long as no alterations are made to the database schema. For example, some database replication technologies add columns to the database tables during replication which can result in critical failures. For this reason, database mirroring is recommended over database replication.
- The database time must be synchronized with the time on the Deep Security Manager computer. Ensure that the database and the manager use the same time zone and that they are synchronizing their time to the same time source.
- Allow communication from the Deep Security Manager computer to the database computer. See Port numbers.
- During the Deep Security Manager installation, you will be asked for database connection details. Enter the database hostname under "Hostname" and the database that you created for Deep Security under "Database Name".
The installation supports both SQL and Windows Authentication. When using Windows Authentication, click the "Advanced" button to display additional options.
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.
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.
- You must create an empty database that will be used by Deep Security.
- Enable "Remote TCP Connections"(see http://msdn.microsoft.com/en-us/library/bb909712(v=vs.90).aspx).
- Grant db_owner rights to the Deep Security Manager's database user.
- The recommended transport protocol is TCP.
- If using Named Pipes to connect to a SQL Server, a properly authenticated Microsoft Windows communication channel must be available between Deep Security Manager host and the SQL Server host. This may already exist if:
- The SQL Server is on the same host as Deep Security Manager.
- A trust relationship exists between the two hosts.
- Both hosts are members of the same domain.
If no such communication channel is available, Deep Security Manager will not be able to communicate to the SQL Server over named pipes.
It is important to have good database maintenance strategies in place. Refer to the Microsoft SQL Server documentation for guidelines, including Options in the Back Up Database Task for Maintenance Plan.
- 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 (v126.96.36.199.0)
- Red Hat Linux Enterprise Server 6.6 with Oracle RAC 12c Release 1 (v188.8.131.52.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.
- PostgreSQL is supported for new Deep Security 10.1 installations only. There is no supported migration path for moving from an earlier version of Deep Security with another database to Deep Security 10.1 with a PostgreSQL database.
- For information on how to install and configure a PostgreSQL database, refer to the PostgreSQL documentation. If you need additional help with setting up PostgreSQL, there are options available for professional support.
- To prepare a PostgreSQL database for use with Deep Security Manager:
CREATE DATABASE "<database>";
CREATE ROLE "<username>" WITH PASSWORD '<password>';
GRANT ALL ON DATABASE "<database>" TO "<username>";
GRANT CONNECT ON DATABASE "<database>" TO "<username>";
- Based on your security requirements, consider using TLS to secure traffic between the Deep Security Manager and PostgreSQL. To turn on TLS after Deep Security Manager has been installed, see Encrypt communication between the Deep Security Manager and the database.
If using multi-tenancy
If using multi-tenancy, users also need the right to create new databases and roles:
ALTER ROLE <username> CREATEDB CREATEROLE;
By default, PostgreSQL log files are not rotated, which can lead to the log files using a large amount of disk space. When using PostgreSQL with Deep Security, we recommend that you use these four parameters in the postgresql.conf file to configure log rotation:
log_rotation_age and log_rotation_size control when a new log file is created. For example, setting log_rotation_age to 1440 will create a new log file every 1440 minutes (1 day), and setting log_rotation_size to 10000 will create a new log file when the previous one reaches 10 000 KB.
log_filename controls the name given to every log file. You can use time and date format conversion in the name. For a complete list, see http://pubs.opengroup.org/onlinepubs/009695399/functions/strftime.html.
When log_truncate_on_rotation is set to "on", it will overwrite any log file that has the same name as a newly created log file.
There are several combinations of parameters that you can use to achieve a log rotation to suit your requirements. Here is one example:
- log_filename = 'postgresql-%a.log' (every log file has the first 3 letters of the weekday in its name)
- log_rotation_age = 1440 (a new log file is created daily)
- log_rotation_size = 0. (setting is disabled to prevent the overwriting of the daily log file every time this limit is exceeded)
- log_truncate_on_rotation = on (enable log file overwrite)
By default, the PostgreSQL deadlock_timeout setting in the postgresql.conf file is configured to 1 second. This means every time a query waits on a lock for more than 1 second, PostgreSQL will launch a check for deadlock condition and will log an error if the logging setting has been configured that way (by default, it is). This can lead to performance degradation on bigger systems, where it can be normal for queries to wait for more than 1 second during load times. On large systems, consider increasing the deadlock_timeout setting. The PostgreSQL documentation contains this recommendation: "Ideally the setting should exceed your typical transaction time [...]".