English | EN 
Today’s rapidly evolving digital landscape demands the management of a growing array of applications, services, servers, databases, and data integrations.
Overview
Consultants, engineers and technicians see many companies every day worldwide in the process of adoption, transition and modernization towards hybrid infrastructures, multi-cloud environments and the containerization of applications that have increased the need for continuous access to platforms, systems, services and data.
Despite these advancements, many developers and DevOps engineers still rely on outdated practices, such as storing plaintext configurations, visible connection strings, and hardcoded passwords in source code and automation tools.
This occurs at different stages of the software development lifecycle, causing a real risk of being mismanaged and leading to a lack of control and governance, which in security circles is known as “secret dispersion“.
When secrets like passwords and credentials are scattered across different systems, two major problems arise:
- Makes it difficult to track and effectively manage credentials
- Increased vulnerability to cyberattacks
These vulnerabilities are significant, according to a report by Verizon, almost 50% of all data breaches are due to credential theft. This underscores the importance of implementing robust secrets management practices to protect sensitive information and reduce the risk of security breaches.
What is secrets management?
A secret can be any sensitive information such as a password, certificate, or any data we need to connect to an application, service, resource, or database that we need to protect and store securely.
Common types include: privileged account credentials, connection strings, passwords, certificates, SSH keys, SAS keys, tokens, API Keys, and more.
Secrets management is a set of security practices that allows companies to protect their IT environments by using a set of tools to centrally and securely access, store, and manage sensitive information from applications, services, databases, and other infrastructure resources so that only authenticated and other infrastructure resources so that only authenticated and authorized users can access them.
The fundamental objective is that the secrets created must be kept in secure storage with strict access controls to avoid giving access to the infrastructure of applications and services to malicious or unauthorized people and applications.
For instance, in Azure we can use (Key Vault | Microsoft Azure) and AWS offers Cloud Credential Storage – AWS Secrets Manager) for securely storing and accessing secrets.
Shared responsibility Model
As Microsoft explains in its documentation on cloud security responsibility models about the division of responsibility.
We should always keep in mind that in cloud environments, an organization’s service provider is not fully responsible for security. Instead, the cloud provider and customer share responsibility for the security of the cloud-based deployment, and the cloud provider’s shared responsibility model outlines the responsibilities of each party.
For all types of deployment in the different cloud and on-prem models, enterprises own and are responsible for protecting the security of the data and identities, on-premises resources, and cloud components they control.
The cloud components you control vary by type of service regardless of the type of deployment, you always retain the following responsibilities: Data, Endpoints, Account and Access management.
Division of Responsibility Model
Recommendations for Protecting Secrets
All manufacturers of secret management platforms and tools include a series of recommendations in their best practice guides that we must consider to apply security in all IT environments, not just in production.
- Always apply the principle of least privilege
- Provide teams with tools to simplify application security and protection
- Use secrets management tools securely and with strict access
- Manage secrets in applications, services, containers, clusters and environments with best practices
- Manage credentials in CI/CD processes and agents with best practices
- Automate secrets management and enforce consistent access policies.
- Remove secrets embedded in IaC and application source code
- Do not save keys or sensitive data in logs and audit logs
- Encrypt keys and credentials at rest and in transit
- Use temporary and revocable access tokens when needed
- Implement automatic rotation of used credentials
In short, we should never store keys or secrets for any type of environment in source code, application configuration files, or continuous integration and continuous delivery (CI/CD) pipelines.
Conclusion
All kinds of applications require constant access to various data sources, cloud services, and servers, often involving the use of different credentials for each resource. This has led to an exponential demand for credentials and permissions for these processes.
Proper secrets management is essential for ensuring the security and integrity of applications and related data. Mishandling secrets can lead to data breaches, service interruptions, and other serious consequences.
References
AWS: https://aws.amazon.com/secrets-manager/
Azure: https://azure.microsoft.com/en-us/products/key-vault
DotNet: https://learn.microsoft.com/en-us/aspnet/core/security/app-secrets
DevOps: https://learn.microsoft.com/en-us/azure/devops/pipelines/process/set-secret-variables
Google: https://cloud.google.com/security/products/secret-manager?hl=en
Kubernetes: https://kubernetes.io/docs/concepts/configuration/secret/
Microsoft: https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
RedHat: https://www.redhat.com/en/topics/devops/what-is-secrets-management
Terraform: https://spacelift.io/blog/terraform-secrets
Verizon Report: https://www.verizon.com/business/resources/reports/2023-data-breach-investigations-report-dbir.pdf
