Skip to main content

Key Manager Server Security Precautions

It is assumed that the usual standards of corporate security are followed when integrating Key Manager into an existing ICT environment.

The following is a list of security precautions that are good to know before installing Key Manager:

  • Root access should only be required for server maintenance and troubleshooting. Access to root accounts on Key Manager Server machines should be limited to only those administrators who require

  • The Key Manager superuser account (created during the initial Key Manager Server setup) should only be used for creating the initial Administrator accounts and for troubleshooting purposes.

  • The SSH server on agentless hosts must be able to accept management connections from the Key Manager Server. This requires an open SSH port on agentless hosts. To perform key management operations on an agentless host, Key Manager must be given an user account that has root privileges, or sufficient privileges provided using sudo settings.

  • Before setting up any machines in the Key Manager deployment, you should decide whether you want to configure Key Manager to use secure database connections. Database connections are unsecured by default, which leaves them vulnerable to data sniffing. Especially for production deployments, we strongly suggest that you secure database connections.

    Instructions for securing database connections with SSL are provided in Setting Up SSL Connection to Oracle Databases and Setting Up SSL Connection to PostgreSQL Databases.

  • If your corporation has an external certificate authority (CA), we recommend that you acquire trusted certificates from your CA. Certificates are used for secure TLS/SSL database connections, for authenticating Key Manager Servers to Key Manager administrators, and for command-line client connections.

    For evaluation deployments, it may be sufficient to create self-signed certificates.

  • When managing agent-based hosts, the Tectia SSH Server running on the Key Manager back end must be able to accept connections using public key authentication to its SSH port (default port 22). Key Manager agents require root privileges, or sufficient privileges through sudo settings, for key management operations to be performed on the host.

  • Password authentication on the Key Manager Server machines may be disabled for added security. It is also recommended that login be disabled for all users except the Key Manager user.

  • There should be no unnecessary ports open on the Key Manager Server machines, or on the hosts in the managed environment.

  • If you opt to run Key Manager Server components on virtual machines, make sure that the system clocks are synchronized correctly on the virtual machines. Consult the documentation of your virtualization software vendor for further information on timekeeping for virtual machines.

Please note that this document does not detail general security precautions that are required when incorporating a system such as the PrivX Key Manager into a production environment. These issues include:

  • hardening the Key Manager host on the operating-system level,

  • the physical security of the Key Manager and especially its Key Manager Server and

  • the security on administrator workstations connecting to the Key Manager Server through the Key Manager graphical user interface (for example, turning off browser password caching).

In case you identify any further issues compromising system security, please inform us. See the instructions at http://www.ssh.com/.

For more information about sufficiently privileged accounts, see the Administrator Manual.