Author Eric Evans
Photo by Chris Barbalis on Unsplash
Introduction
Many security breaches are caused through the exposure of sensitive data. Sensitive data exposure occurs when sensitive data such as credentials and secret data is not adequately protected. The exposure of this sensitive data can create a very high security risk, since this type of data inherently carries a high level of impact associated with them. The use of secrets in scenarios such as application development, cloud engineering, and infrastructure setup/maintenance is almost inevitable with modern application patterns such as microservices.
What are Secrets?
Secrets are commonly defined as sensitive data that leads to other sensitive data. Examples of secrets are passwords, application programming interface (API) keys, and cryptographically significant data such as certificates. Secrets are commonly used to authenticate applications or services to use other applications and services. For example, it is not uncommon to have applications use API keys to perform actions on platform as a service (PaaS) services such as Atlassian or Salesforce.
The Problem with Secrets
The problem with secrets is that they are easy to create, but hard to manage. If a good secrets management strategy is not defined from the beginning of a project, it is susceptible to secret sprawl. Secret sprawl is the action of defining secrets in ways that are not recommended such as: hardcoding secrets in applications, committing secrets to Git (and making them public on sites such as Bitbucket and GitHub), and communication secrets through unsecure means such as through email. As secrets are spread throughout channels such as the ones enumerated above, it becomes hard to answer questions such as “Where are my secrets?,” “Are my secrets being used?,” “Who has access to my data?,” and so on. In addition, secret sprawl creates a nightmare for operations and security teams who must maintain credentials and perform actions such as rotation and revocation of this sensitive data. This also makes compliance extremely difficult (such as maintaining the cryptoperiod for cryptographic material)
Secrets Management
With acknowledging the problem that secrets can create, the question is then posed - what can be done about secret sprawl? The answer is to centralize both the storage and management of secrets. This can be accomplished easily through the use of a secrets manager. A secrets manager typically stores secrets using key/value pairs and has mechanism(s) for access control of secrets such as policies and access control lists (ACLs).
What Makes a Good Secrets Manager?
A good secrets manager will have the following capabilities:
A mechanism for access control (such as those listed earlier in this article)
The ability to integrate with existing identity management solutions such as those provided by Amazon Web Services (AWS), Microsoft Active Directory (AD), or the wide variety of other options.
Capabilities to audit the use of secrets – useful for accountability purposes and identifying what secrets are being used, and when.
The assurance that sensitive secret data is protected at rest, in transit, and while it is being processed.
Dynamic secret generation for ephemeral secrets such as AWS access keys, or Google Cloud Service Account keys.
Other secrets managers go above and beyond the storage and management of secrets and provide other capabilities such as authentication brokering (facilitating privileged access management) or encryption as a service.
Which Secret Manager is the Right One?
As with other security tooling, the right secrets manager depends on the use case. Cloud native solutions such as AWS Secrets Manager or GCP Secret Manager are great options for simple use cases. On-premise, cloud agnostic, or those who want a more feature rich secrets manager may opt for the use of HashiCorp Vault. In any case, when evaluating secrets managers, the points above should be considered – and remember that having a secrets manager is better than not securing secrets at all.
Stay safe everyone!
About the author: Eric Evans is a Senior Cloud Security Consultant at ScaleSec, where he enjoys innovating and making the cloud a safer place. Originally a software developer his passion is now focused on DevOps & CyberSecurity.