In the context of application security, a secret is any piece of information that proves the possessor is who and what it claims to be during the process of authentication and authorization. If malicious actors get access to secrets, they gain unintended access to your systems which they can use for various purposes, including stealing corporate secrets and customer information or even holding your data for ransom.
A classic example is the username and password that allows an application access to its database, but a secret can also be API keys, credentials, certificates, and private keys, among other types of information. Because secrets are used to control access to an organization’s assets, securely storing and protecting them is crucial to reducing the organization’s risk of being compromised.
Secrets management is the process an organization uses to:
When organizations move from monolithic to microservices architectures, the number of independent application and infrastructure components – each with its own credentials – increases, meaning there are many more secrets to manage.
Let’s take a closer look at two options for securely storing secrets:
The vault approach involves installing a third-party secrets-management tool. The vault solution encrypts each secret to prevent unauthorized users from accessing it. The vault exposes an API to give users access to secrets based on established policies. When users of the API authenticate with it, they can only access the secrets for which they have been authorized.
Cons:
Pros:
There are plenty of tools on the market for developers to use to store and manage encrypted secrets. For an example of how to use a centrally automated secrets-management tool, read our blog, “Protecting SSL Private Keys in NGINX with HashiCorp Vault.”
Another approach is to use a cloud provider for secrets management as a service. One benefit is that the secrets management tool usually integrates tightly with other cloud services such as managed databases. Cloud provider services may also offer features such as automatic rotation, though future research is required to see whether that option results in downtime.
Con:
Pros:
Secrets must be managed carefully to prevent disruption to the application when they are unlocked and accessed. A best practice is to never check secrets into a source control system. Storing secrets there opens an organization up to possible disaster if secrets are accidentally accessed or compromised when a team or individual updates the code or application. For this reason, if a secret is ever checked into source control, even briefly, it must be treated as compromised. The sensitive data must be removed from the repository and scrubbed from the source control system’s history.