<img src="https://ws.zoominfo.com/pixel/6169bf9791429100154fc0a2" width="1" height="1" style="display: none;">

Life's like a box of chocolates 🍫 Your access shouldn't be. Register for our new webinar.

Search
Close icon
Search bar icon

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:

Vault/Store

Supports

Tech Stack Protected

Legacy PAM

On-premises

Tools supported by Legacy PAM vendor

Note: Does not include cloud, databases, Kubernetes, etc. Learn more.

AWS Secrets Manager

Cloud only

AWS Infrastructure

GCP Secrets Manager

Cloud only

GCP Infrastructure

Azure Key Vault

Cloud only

Azure Infrastructure

Strong Vault (StrongDM)

Both

On-Premises Infrastructure including servers, databases, data stores, Kubernetes, and more
AWS Infrastructure
GCP Infrastructure
Azure Infrastructure
Oracle Cloud Infrastructure
IBM Cloud Infrastructure

Also integrates with existing secrets vaults


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.

add-secret-store-sdm

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.

 


About the Author

, Technical Marketing Expert, has held marketing leadership roles for Silicon Valley technology companies specializing in database, data management, and data analytics solutions. As head of content marketing at Splunk, Dominic contributed to boosting the company’s market visibility and its growth from a $100M to a $1.3B company. He brings relentless creativity to the task of connecting people with technical products to improve their lives. Dominic holds a B.S. degree in Public Relations from the University of Texas at Austin. To contact Dominic, visit him on LinkedIn.

StrongDM logo
💙 this post?
Then get all that StrongDM goodness, right in your inbox.

You May Also Like

Privileged Access in the Age of Cloud Authentication & Ephemeral Credentials
Privileged Access in the Age of Cloud Authentication & Ephemeral Credentials
The way that people work continues to evolve, and as a result, so do the ways that they must authenticate into their organization’s resources and systems. Where once you simply had to be hardwired into the local office network, now you must expand your perimeter to include remote and hybrid workforces, on-prem and cloud environments, and take into account a growing list of factors that impact how and where people access critical company resources.
9 Privileged Access Management Best Practices
9 Privileged Access Management Best Practices
Understanding the pillars of access control and following best practices for PAM gives you a roadmap to an implementation that is secure and comprehensive with no security gaps. This article contains nine essential privileged access management best practices recommended by our skilled and experienced identity and access management (IAM) experts.
Vendor Access Management (VAM) Explained
Vendor Access Management (VAM) Explained
Vendor Access Management (VAM) is the systematic control and oversight of vendor access to an organization's systems, applications, and data. It involves processes such as onboarding and offboarding vendors, utilizing solutions for Just-in-Time access, ensuring security, and streamlining workflows to minimize operational inefficiencies.
How to Meet NYDFS Section 500.7 Amendment Requirements
How to Meet NYDFS Section 500.7 Amendment Requirements
The New York Department of Financial Services (“NYDFS”) Cybersecurity Regulation is a set of comprehensive cybersecurity requirements that apply to financial institutions operating in New York. The goal of the regulation is to ensure that the cybersecurity programs of financial institutions have robust safeguards in place to protect customer data and the financial sector.
The Access Management Bill of Rights