Credentials & Secrets Management

Credential Handling #

Because StrongDM is a protocol-aware proxy, we are able to inject credentials during the “last mile” hop between the proxy and the target database or server. As a result, sensitive credentials are always inaccessible to users: they are never transferred to a client in any form.

Credentials are unlocked at runtime using a “dual key” system: only when a cryptographically valid proxy instance requests decryption on behalf of a cryptographically valid user session are they unlocked. Neither the user nor the proxy instance alone are sufficient to decrypt the credential.

We call the system that StrongDM uses to handle this “credential leasing”.

Credential Leasing #

Users in the StrongDM system may be granted access to a Datasource or Server via Roles, or via temporary access directly granted to the User.

From the perspective of a Datasource or Server, access is conducted via the Leased Credential.

Example: When Bob connects to a MySQL instance, executing SHOW PROCESSLIST will list the connection within that instance as originating from leased-credential and the IP of the gateway or relay most proximate to that MySQL instance. Within StrongDM, any logged queries will be attributed to Bob.

StrongDM’s Secret Stores #

Internally, the StrongDM Secret Stores are implemented using AWS Key Management Service. The StrongDM implementation fully leverages authenticated encryption with associated data (AEAD) via the KMS Encryption Context. All credential decryption events are written to a tamper-hardened audit log that is owned by a separate AWS account. You can read more about KMS at: https://docs.aws.amazon.com/kms/latest/cryptographic-details/intro.html.

Third-party Secret Stores #

Secret store integrations provide the option to store resource credentials in a third-party tool controlled by you rather than saving them with StrongDM. If your organization already manages and rotates credentials with a supported secret store provider, nothing about that workflow will have to change.

Security Considerations for Privileged Accounts #

Not even your users with the Administrator permission level can access resource credentials directly. Even if an Administrator account in your organization is compromised, this particular consequence is mitigated. However, it is possible for a malicious Administrator or Database Administrator (DBA) to change the address of a resource to point to a server under their control. Depending on the type of resource and authentication method, the attacker may be able to recover plaintext credentials for the original resource when authentication attempts are made to the new server using the legitimate resource credentials.

In addition, a malicious Administrator or DBA can create a resource that points to a sensitive address, such as the AWS Instance Metadata Service, and recover credentials that way.

These attack vectors are impossible to block completely, so it’s critical to maintain the security of your StrongDM Administrator and DBA accounts.