What is secrets management?

Organizations today automate many key business processes and workflows by using tools such as robotic process automation (RPA) and recently, AI agents and AI assistants. Much like human users, these nonhuman entities need credentials—often called “secrets”—to access organizational resources.

Nonhuman users often require elevated privileges to complete their tasks. For example, an automated backup process might have access to confidential files and system settings.

These privileged nonhuman accounts are high-value targets for hackers, who can abuse their access rights to steal data and damage critical systems while evading detection. In fact, hijacking valid accounts is the most common cyberattack vector today, according to the IBM® X-Force® Threat Intelligence Index. These attacks represent 30% of all incidents that X-Force has responded to recently.

Secrets management systems and processes allow organizations to create, control and secure the secrets nonhuman entities use to access IT resources. By using secrets management tools to manage and protect nonhuman credentials throughout their entire end-to-end lifecycle, organizations can streamline automated workflows while preventing data breaches, tampering, theft and other unauthorized access.

A secret is a digital credential contained within an application or service that permits nonhuman users to communicate with and perform actions on a service, database, application or other IT resource. Secrets help organizations strengthen their security posture by ensuring that only authorized users have access to sensitive data and systems.

Examples of secrets include, but are not limited to:

• Service account credentials: Service accounts allow apps and automated workflows to interact with operating systems. Service account credentials can include passwords, security tokens, Kerberos tickets and other secrets.
  
  
• API keys: API keys allow users, apps and services to verify themselves to application programming interfaces (APIs).
  
  
• Encryption keys: Encryption keys allow users to encrypt and decrypt data.
  
  
• Authentication and authorization tokens: Tokens, such as those used in the OAuth protocol, are pieces of information that can verify a user’s identity and determine the specific resources it can access.
  
  
• SSH (Secure Shell) keys: SSH keys are used by SSH servers to identify a user or device through public-key cryptography.
  
  
• SSL/TLS certificates: A digital certificate that can be used to establish private communications between a server and a client using the Secure Sockets Layer/Transport Layer Security (SSL/TLS) protocol.
  
  
• Arbitrary secrets: Sensitive data, including any type of structured or unstructured data that can be used to access an application or resource.
  
  
• Other private keys: These can include public key infrastructure (PKI) certificates, hash-based message authentication code (HMAC) keys and signing keys.

Enterprise-grade secrets management tools help organizations detect, prevent and remediate unauthorized access to and misuse of sensitive data and systems, such as personally identifiable information (PII). Organizations can reduce the risk of data breaches and data theft, avoiding the loss of valuable data, potential fines and reputation damage.

Secrets management is 1 of the pillars of privileged access management (PAM), the subset of identity and access management (IAM) that focuses on securing privileged accounts and users.

The other 3 pillars of PAM include:

• Privileged account and session management (PASM), which handles account lifecycle management, password management and session monitoring.
  
  
• Privilege elevation and delegation management (PEDM), which involves automatically evaluating, approving and denying privileged access requests. 
  
  
• Cloud infrastructure entitlement management (CIEM), which oversees IAM processes in cloud computing environments.

Secrets management is important to the DevOps methodology, which emphasizes automated, continuous software delivery.

DevOps teams often use multiple configuration or orchestration tools to manage entire digital ecosystems, workflows and endpoints. The tools often use automation and scripts that require access to secrets to initiate. Without an enterprise-grade secrets management service, haphazard use of secrets might increase system vulnerability.

Many organizations integrate secrets management functions into the continuous integration and continuous delivery pipeline, or CI/CD pipeline. This helps ensure that all the moving parts—developers, tools and automated processes—have secure access to the sensitive systems they need when they need it.

Secrets management is considered a core component of DevSecOps, an evolution of the DevOps methodology that continuously integrates and automates security throughout the DevOps lifecycle.

The secrets management process typically relies on secrets management tools. These tools, which can be deployed on-premises or as cloud-delivered services, can help centralize, automate and streamline the creation, use, rotation and protection of secrets.

Some common capabilities of secrets management tools include:

• Centralized and standardized secrets management
• Dynamic secret creation and automated secret rotation
• Access controls
• Activity monitoring and auditing

With an enterprise-grade secrets management service, organizations can manage multiple types of secrets in a single pane of glass.

Instead of leaving individual users to manage secrets in small silos, secrets management solutions can store secrets in a secure, central location called a “secrets vault.”

When an authorized user needs access to a sensitive system, they can obtain the corresponding secret from the vault. The secrets management tool can automatically verify, authorize and grant users the permissions they need to carry out their workflows.

Standardization can help prevent secret sprawl. Secret sprawl is when secrets are stored in various places throughout an organization, often hardcoded into applications or as plain text in a shared document. Secret sprawl makes it hard to protect secrets from malicious actors and track how secrets are used.  

Secrets created in a secrets manager can be either static or dynamic. A static secret is a secret that stays valid for a long time, usually until it is manually changed or hits a predetermined expiration date.

In contrast, a dynamic secret is created by the secrets manager on demand, at the moment it is needed. Dynamic secrets expire fairly quickly. They can even be single-use.

A use case for a dynamic secret would be to protect a confidential resource by dynamically generating API keys each time that resource is read or accessed. This helps ensure that malicious actors cannot steal and reuse API keys.

Many secrets managers can also automate secret rotation—that is, the act of changing secrets regularly. Secret rotation can be automated on schedule or on demand without the need to redeploy or disrupt applications. Time-to-live (TTL) or a lease duration can be defined for a secret at its creation to shorten the amount of time the secret exists.

Secrets can be granted only to specific entities or groups to organize and tighten access. Access to secrets is often granted by using the principle of least privilege—that is, each process is granted only the most restrictive set of privileges needed to perform a task. Users can access only those secrets that are required to perform their authorized tasks.

Many secrets managers can track how users and applications interact with and use secrets to verify that secrets are being handled appropriately throughout their lifecycles. This allows the organization to conduct real-time, end-to-end monitoring of authentications and authorizations.

Secrets managers can quickly identify unauthorized attempts to view or use secrets and cut off access, thereby stopping hackers, insider threats and other bad actors. 

Beyond using secrets management solutions, many organizations follow common core practices in their secrets management processes. These practices include:

• Secrets are generated and stored in the environment where a service is deployed, such as dev, test and production environments. Some organizations use different secrets management tools for each environment. Others use one central solution and isolate each environment’s secrets in a dedicated segment. The secrets never leave their environments and are secured by using strict access control measures.
  
  
• User access to secrets is granted at the minimum level required for any user to fulfill their responsibilities. Overentitlement—whether intentional or not—can lead to data breaches.
  
  
• Secrets are rotated regularly in accordance with system requirements.
  
  
• Users do not store secrets in source code, configuration files or documentation.
  
  
• Security policies can be enhanced by requiring encryption of all sensitive data. The encryption keys can be protected with a key management service (KMS).
  
  
• The organization continually monitors secrets, with audit logs tracking every request: who asked for the secret, for which system, whether the request was successful, when the secret was used, when it expired and when and if the secret has been updated. Anomalies are investigated immediately. 

As IT ecosystems become more complex, secrets management becomes increasingly difficult to control effectively. Common secrets management challenges can include:

Decentralized ecosystems where admins, developers and users manage their secrets separately can introduce risks, as security gaps and secrets use might not be properly monitored or audited.

Centralized secrets management solutions can offer organizations more visibility into and control over secrets.

When passwords or other secrets are embedded as plain text in source code or scripts, attackers can easily discover them and use them to access sensitive information.

Hardcoded secrets can appear in many places, including CI/CD toolchains, Internet of Things (IoT) devices, container orchestration platforms such as Kubernetes, application servers, vulnerability scanners and robotic process automation (RPA) platforms.

Regular rotation of secrets can help prevent theft and abuse, but rotation can be inconsistent or ineffective without a secrets management system. If a secret remains unchanged for too long, a hacker might be able to unlock it by trial-and-error guesses or a brute-force attack.

The longer a password is used, the more users have access and the greater the chance of a leak.

Growing IT systems can lead to secret sprawl, with secrets spread across many siloed parts of the system. Secret sprawl can be especially concerning in hybrid multicloud ecosystems, where organizations mix public and private cloud environments delivered by multiple cloud providers.

Organizations might have thousands, even millions, of secrets across all their cloud-native applications, containers, microservices and other IT resources. This sprawl creates a massive security burden and expands the potential attack surface.

Across services, visibility might be limited, and secret management can quickly become unwieldy if tracked manually or by disparate systems. The lack of a centralized secrets management service might make enforcing proper secrets hygiene more difficult or impossible.

When an organization lacks a secrets management system, secrets might be shared manually—such as through emails or texts—where threat actors can intercept them.