Secret Server Security Model
Delinea's Secret Server is a password vault that holds the keys to the kingdom. It is therefore critical that you understand the security model of Secret Server.
What the Security Model Covers
What Is Covered
The following are part of Secret Server’s security model:
- Access to data must be authenticated and authorized.
- Access to or modification of data must have auditing for accountability.
- Data is confidential and secured at rest.
- Data is confidential and secured in transit.
- The system can be highly available.
What Is Not Covered
The following are not a part of Secret Server’s security model:
- Protecting against the leakage of the existence of secret data. An attacker that can read from storage will be able to tell that secret data exists, even if it is encrypted at rest.
- Protecting against memory dumps. For example, an attacker with privileged access on the web server of an distributed engine can inspect the memory of the application and potentially compromise the confidentiality of the protected data.
- Protecting against control of the web server or database server. An attacker who can manipulate the web server or database can undermine the system’s security. For example, a database administrator could delete all data, and Secret Server would not be able to recover unless restored from a backup.
Confidentiality
Data is secured in transit and at rest. You should secure communications between a client and the application using Transport Layer Security (TLS). TLS sets up a secure channel for communication between the client and application and protects data in transit and against eavesdroppers. Access to the Secret Server’s web interface and APIs should both be secured with TLS. Our database storage at rest secures sensitive data with AES encryption in CBC mode. Communication with the database storage can be further secured by using Microsoft’s SQL Server’s TLS capabilities.
Availability
Secret Server can operate within a highly available configuration. You can deploy multiple web server nodes such that traffic is load balanced across them. If a web server fails, then the system relies on nodes that are still available. Likewise, you can deploy multiple distributed engines for any given site to distribute workload.
Accountability
Access to and modification of data is audited, enforcing accountability for a user attempting to access or modify sensitive data.
Authentication
Access to the web interface and APIs require authentication. Users must provide their login credentials and, if applicable, their two-factor authentication, to access the system. Without authentication, the client is unable to access any data. Authentication should be protected against eavesdroppers using TLS.
Authorization
Secret Server uses authorization to protect sensitive data that is shared in the vault. It specifically allows for RBAC (Role-Based Access Controls) that provides fine grained control over the data and controls that users have access to and ability to modify. Administrators must review the permissions that they are assigning to their users to protect against internal threats from users who have unnecessary permissions in the system. You should always use a least privilege model to assign permissions.