Addressing Vault Sprawl: How To Manage Multiple Secret Vaults

Secret vaults ensure that sensitive and privileged credentials are well protected, rotated, and only used–or checked out–when necessary. This makes them a critical and foundational tool for credential protection in modern infrastructures.

However, as organizations have continued to evolve and embrace hybrid- and multi-cloud deployments, one key issue has arisen: vault sprawl. Vault sprawl is what happens when organizations end up using multiple vaults to manage their secrets. At a high level, the sprawl typically includes some combination of:

• Cloud-owned vaults - vaults used by major CSP providers
• Non-cloud aligned vaults - vaults primarily used on-premises
• Traditional PAM - vaults included in traditional PAM tools

Addressing vault sprawl is a critical part of getting to least privilege and zero standing permissions. Without addressing it, organizations may end up with manual processes and inconsistently applied access policies.

The TL;DR

When it comes to enterprise-scale organizations, it’s inevitable that multiple vaults will be deployed by different teams across the organization. If your PAM provider can’t integrate with multiple vaults, you’re fundamentally set up to fail. Your IAM team either can’t enforce security policies across all vaults or wastes too much time trying. Furthermore, if your PAM provider locks you into using their vault, it becomes impossible for you to pick best-in-class options. That's why StrongDM takes an integration-first approach to support all vaults.

Vault Sprawl: How We Got Here

Most organizations have implemented a secret vault as part of their privileged access management (PAM) deployment. Unfortunately, problems arise when they begin to expand their stack beyond the tool set supported by their traditional PAM provider. This is because secret vaults have historically been vendor-specific. That means your chosen PAM vendor likely has their own secret vault, which only works with the specific set of tools that that PAM integrates with. So as your organization's grows, you’re forced to adopt additional secret vaults in order to protect the credentials for those new tools, including cloud resources.

The below table is an example of the disparate nature of secret stores:

Furthermore, the adoption of multiple vaults may happen outside of the IT or security teams’ purview. Here’s a common example:

• Developer teams need infrastructure to build applications
• The team spins up its own deployment in AWS, begins using AWS Secrets Manager
• Sensitive data is added to the cloud, to support development and testing
• Security and IT have no visibility into this activity

All of this results in two challenges: increased risk and increased overhead. For example, if you have a hybrid cloud architecture, you may have:

• Traditional PAM Vendor’s Secret Vault
• AWS Secret Vault
• Azure Secret Vault

Each vault only serves technology within its purview. In this case, the IAM team will need to manage each vault independently of each other, and apply the appropriate policies to each vault. It essentially triples the management workload and increases the risk of secrets being misused and mismanaged.

Another example is mergers and acquisitions (M&A). Organizations that get acquired come with their own tech stack, processes, and access rules. That means the organization that is purchasing the new company is inheriting new technologies, including secret vaults, that they will need to get control of immediately. This often includes cloud vendors, and visibility into usage and access is sorely needed.

Multiple Vaults Multiplies Risk, Workload

Vault sprawl can create significant issues for organizations, ranging from an increased attack surface to increased overhead for your IAM,security and audit teams. The inability of legacy vaults to provide holistic secrets management means that security teams no longer have full visibility into how secrest are used, much less the ability to manage them. This can manifest in a few key ways.

Increased risk. With no visibility into how secrets are used and managed, the deployment supported by a particular vault cannot meet the security standards set by the organization. This can result in significant risk depending on the data and technologies being supported by that vault.

Inconsistent policies. Having to manage multiple vaults can also result in inconsistent implementation of your access policies, especially in the case that different vaults are used by different teams. For example, a development team could spin up a new cloud deployment and use its associated vault, outside of the purview of the organization’s IT or security teams. 

Increased overhead. By definition, having to manage multiple vaults will also increase the overhead and costs associated with your access management strategy. Now your team is forced to manually support multiple vaults instead of protecting the business.

Getting To Centralized Management Of Secret Vaults

There are only two ways to centralize management of secret vaults:

• Standardize on the set of tools supported by a particular vendor
• Use an access management tool that integrates with multiple vaults

The first option isn’t feasible. It locks you into a stack that a particular vendor provides or supports, fundamentally preventing you from adopting any new technologies you may need in order to support your organization. It also puts an unnecessary burden on DevOps teams who tried to do the right thing by incorporating a secret vault in the first place. 

The second option provides a path for centralized management. By using a tool that integrates with all of the proprietary vaults, you can centralize the management of multiple vaults and greatly reduce the complexity and overhead associated with managing secrets. This is especially valuable in hybrid and multi-cloud environments, where you’re required to use multiple vaults based on where your backend infrastructure is hosted (on-premises or the cloud). This is where StrongDM comes in.

StrongDM: Universal Management Of Secret Vaults

One critical feature of StrongDM is Strong Vault. Strong Vault is an encrypted, central repository where secrets, keys, and credentials can be kept. Furthermore, StrongDM can enable you to centralize the management of multiple secret vaults.

Integrates with legacy vaults. StrongDM is secret vault-agnostic and integrates with all legacy vaults, so organizations are free to use their vault(s) of choice. This enables organizations to keep their secrets where they already live, but manage them from a centralized location.

All modern tools are supported. StrongDM integrates with a large variety of modern and legacy tools, including databases, Kubernetes, containers, and more. That means that you can extend secrets management beyond the tools supported by the vault of your legacy PAM.

Centralized management and visibility. Critically, StrongDM provides a single control plane for managing secrets across multiple vaults and secret stores. This enables your security and IT teams to spend less time managing multiple vaults and more time proactively protecting the business.

Connect with no credentials. StrongDM is unique as a modern PAM in that credentials for infrastructure are never provided to end users or end-user workstations. The combination of managing secrets with credential-less access means that end users get a simple and streamlined user experience while never having access to the actual credentials.

Centralizing management of secrets is foundational to implementing zero standing privileges. The complexity of multiple vaults makes it impossible for IAM teams to have the necessary visibility to reduce risk, or to dynamically manage access across your infrastructure.

StrongDM Vault: See it in action

Want to see Strong Vault in action? You can book a demo here. Just want to learn more? Download the StrongDM technical paper.