Deep Security 11 has reached end of support. Use the version selector (above) to see more recent versions of the Help Center.
Prepare a database for Deep Security Manager on AWS
We recommend that you use the AWS Quick Start Deep Security on AWS to automatically deploy Deep Security on AWS. If you use that method, you can disregard the database preparation steps described here because the Quick Start takes care of database configuration for you. For information on the Quick Start, see Deploy the Deep Security AMI from AWS Marketplace.
If you are not using the Quick Start, you must install a database, create a database instance for Deep Security, and create a user account for Deep Security before you install Deep Security Manager. You can install your own database or you can use the Amazon RDS Management Console to create a database instance (Microsoft SQL RDS or Oracle RDS). Refer to the Amazon RDS Documentation for instructions, but keep the following considerations in mind for integration with Deep Security:
- Check the Hardware recommendations.
- 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 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.
By default, the AWS Marketplace AMI uses Coordinated Universal Time (UTC). We recommend that you also use UTC for your database. If you change this setting, be sure your manager and database match.
- Allow communication from the Deep Security Manager computer to the database computer. See Port numbers, URLs, and IP addresses.
- 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, the "Advanced" option is not available with the AWS Marketplace version of Deep Security Manager.
- Database maintenance is a crucial part of Deep Security operations.
Hardware recommendations
We recommend that you use an AWS RDS instance (Microsoft SQL RDS or Oracle RDS), but you can also use a stand-alone database server.
If you choose to use a stand-alone database server, keep these recommendations in mind:
- 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
- You must create an empty database that will be used by Deep Security.
- The recommended transport protocol is TCP.
- Enable "Remote TCP Connections". (See https://docs.microsoft.com/en-us/previous-versions/bb909712(v=vs.120)?redirectedfrom=MSDN)
- The AWS Marketplace version of Deep Security Manager does not support Named Pipes.
- The database account used by the Deep Security Manager must have db_owner rights.
- If using Multi-Tenancy, the database account used by the Deep Security Manager must have dbcreator rights. For information on multi-tenancy, see Set up a multi-tenant environment.
Oracle Database
- Start the "Oracle Listener" service and make sure it accepts TCP connections.
- The database account used by the Deep Security Manager must be granted the CONNECT and RESOURCE roles and UNLIMITED TABLESPACE, CREATE SEQUENCE, CREATE TABLE and CREATE TRIGGER system privileges.
- If using multi-tenancy, the database account used by the Deep Security Manager must be granted the CREATE USER, DROP USER, ALTER USER, GRANT ANY PRIVILEGE and GRANT ANY ROLE system privileges.
- Avoid special characters for the 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.
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.
Connection settings used during Deep Security Manager installation
During the Deep Security Manager installation, you will be asked for Database connection details. Enter the Database hostname under "Hostname" and the pre-created database for Deep Security under "Database Name".
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.
- 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
It's important to have a backup strategy in place for the Deep Security database in case of failure. Consult your database vendor's documentation for instructions on how to back up your database and see Back up and restore your database for instructions on how to restore the database, if necessary.
