Skip to main content

The Security of the PrivX Key Manager

You can use the PrivX Key Manager to help strengthen the data security of your ICT environment. Naturally, the functions of the Key Manager system are also implemented securely. To guarantee the confidentiality, integrity, and authenticity of sensitive information, Key Manager can be configured to use encrypted connections for all data-transfer purposes. Key Manager provides strong authentication to the managed hosts.

Private Keys Are Never Copied from Managed Hosts​

One of the design philosophies of Key Manager is that private keys are never copied anywhere from the managed hosts. Private keys are always generated on the managed hosts and never transferred from their original location. Only public keys and key fingerprints are sent to the Key Manager system. Thus, a possible compromise of the Key Manager system does not directly compromise any of the managed private keys.

Principle of Least Privilege​

Key Manager adheres to the least-privilege principle whenever possible. Both the Key Manager back- end and front-end processes run using non-privileged accounts on the Key Manager system. On most managed-host platforms, Key Manager can be configured to manage the host using non-privileged accounts that have only been given permissions for running key-management tasks.

Encrypted and Authenticated Management Connections​

The management connection between the managed hosts and the Key Manager back end is encrypted and authenticated using the Secure Shell (SSH) protocol.

An advantage that comes with the SSH standard is that Key Manager identifies both endpoints of each management connection. Key Manager back ends and the Key Manager agents are authenticated using public-key authentication.

Encrypted Database​

Critical data in the database (stored passwords and passphrases) is encrypted. The encryption secret used for securing the database is also obfuscated. Access to the database is protected with TLS and strict access control - as is the whole Key Manager system. The database may be replicated, backed up, and restored using existing database procedures. All such operations should be planned and executed securely.

Secure User Interfaces​

Key Manager offers an encrypted and authenticated web-based GUI. Administrators use standard web browsers to access the Key Manager GUI securely, with no additional plug-ins or Java required. Connections from administrator workstations to the Key Manager GUI are TLS-encrypted with server-side X.509 certificate authentication. The GUI also supports certificate-based client authentication. Similarly, the Key Manager command-line client uses TLS-encrypted connections.

Audit Trails about Administrator Actions​

All actions made by an administrator are logged in audit trails and stored in the database for troubleshooting and accountability purposes.

Role-based Access Control for Key Manager Administrators​

Key Manager allows you to maintain granular administration privileges. Administrator permissions can be defined as different roles in admin groups, for example Superuser, Auditor, and Key Operators. The roles determine which hosts each administrator is able to manage and view, and which actions (for example, configuring, auditing or authorizing a key) they are allowed to perform.

Key Manager provides tools for creating dedicated administrator roles with permissions tailored for specific tasks. Only administrators with appropriate privileges may access the database for critical information, such as authorization and configuration data. All administrator actions are logged in audit trails, therefore the movements of data and access to it are secured in Key Manager operations.

Unavailability of Key Manager Does Not Disrupt Infrastructure​

Key Manager does not constitute a single point of failure from an availability perspective. The support for active/active high-availability through back-end groups ensures that hosts are managed as long as there is one functional Key Manager back end in the back-end group. The SSH clients and servers that are managed by Key Manager will continue to operate even if the entire Key Manager system is off-line. The only immediate impact from a complete Key Manager system outage is that no new user keys can be installed and alerts are not triggered.

The management of SSH user keys continues automatically after the Key Manager system is restored: Key monitoring and deployment activities resume automatically, and key alerts will be triggered for suspicious behavior that occurred during the downtime period.

The Security of the Hosts in the Managed Environment​

No new ports are opened on the hosts in the managed environment, no new software is accessible from the network before authentication, and private keys are not transferred from the hosts on which they were generated.

For hosts managed using agent-based connections, the Key Manager agent runs on each managed host as a privileged application. Therefore a local privilege escalation attack would theoretically be possible. This risk is mitigated by the following factors:

  • The careful design of the management agent

  • The minimal footprint of the agent

  • The management agent only reads those files that unprivileged users should not be able to modify, without writing changes to them

  • It is possible to configure the agent to run using a non-privileged account with elevated privileges for specific commands. This requires that a correctly configured sudoers file is in place for the account. Instructions for setting up a sudoers file is provided in the product manuals.

The Security of Agentless Management Connections​

For each host that is managed using agentless connections, Key Manager stores a management key (a regular SSH authorized key) that is authorized to a root (or equivalent) account on the managed host. Anyone who is able to access that management key would be able to log on to that managed host as that privileged user. This risk is mitigated by the following factors:

  • The private key for the agentless connection is protected with a passphrase, and stored in an encrypted fashion in the Key Manager Database.

  • Private keys are not shared across managed hosts. A unique private key is generated for each managed host connection.

  • Key Manager can be configured to automatically set allow-from restrictions on all management keys, which ensures that only Key Manager back ends are allowed to connect using management keys.