Security tips for CipherTrust Teradata Protection

It is recommended to have at least two dedicated servers - Web Server and Application Server between the Teradata DB and Internet. This is shown in the following diagram:

• Web Server: The Internet-facing Web Server should be dedicated, that is, a separate virtual machine with separate address space, IP, firewall, and so on). You must assume the Web Server will be penetrated and ensure that it does not contain DB credentials, encryption key names, or any sensitive data. It can contain static content, such as static web pages, graphics, and videos, but it should not contain business logic or have direct access to the Teradata database. It should have such security features as firewalls, but you should not overload it with functionality.

  The Web Server’s access to the Teradata DB should be through an Application Server. The Web Server’s access to the secure data should come in the form of REST or SOAP API calls to the Application Server, which are fairly traceable, testable, and can be limited in scope.

• Application Server should be dedicated and should not be accessible from the Internet. It will have Teradata DB credentials and the name of encryption keys, but not the encryption keys themselves. It will contain the organization’s business logic and when the Application Server receives REST/SOAP requests from the Web Server, it will retrieve the required data from the Teradata DB, and send it to the Web Server which will send it along to the requester.

• Teradata DB should be dedicated and inaccessible from the Internet. It should pass data only to the Application Server with the appropriate credentials. It should contain the Vormetric Application Encryption (VAE) agent.

To support separation of duties, each of the above servers should be administered by a different administrator, a Web Administrator, Application Server Administrator, and Database Administrator. The Web Administrator will not have access to the database and key name. The Database Administrator has access to the encrypted data, but lacks the key name to decrypt the data. The Application Server Administrator could decompile the middleware and extract the database credentials and the key name(s), but this is not a straight-forward process as long as the application logic is compiled.

Each administrator should perform their administrative duties on their respective servers using a UNIX/Linux or OSX machine, not a Windows machine, which is more vulnerable to hacking. Furthermore, this administrator machine should have an air gap (physical and electronic isolation) from other computers.

The connection from these server administration machines to the dedicated servers should use the following security enhancements:

• Disable unused services, such as printer daemons, mail servers, and so on.

• Restrict the IP addresses that can log in. For example, only allow connections from corporate headquarters. This can be configured in the SSH configuration and settings.

• Change the SSH port from the default 22 to a random port number (example: 50712). In /etc/ssh/sshd_config, change port 22 to port 50712.

• Disallow SSH password login and use a key pair login instead. Refer to Disallow SSH Password Login for details.