April 8, 2022
Posted by Miryam Brand
Today, the surge of automation and containerization can be found in organizations of all sizes. No matter which industry, hybrid multicloud workloads that operate within agile DevOps environments are now central to maintaining a competitive edge, creating great end-user experiences, and increasing employee efficiency.
On the other side of the coin, these organizations also still have to deal with sensitive data, services, and other digital resources, such as Personally Identifiable Information (PII) or financial data. Keeping this data safe and secure goes wrong quite often; data breaches are some of the worst, yet most common, negative consequences of our increasingly hyper-connected world.
One of the conventional ways to protect sensitive data is to encrypt it. But encryption introduces a whole new level of complexity, as it results in having a slew of encryption keys to store, manage, and protect.
Growth Of Authentication And Secrets
Identities are the new perimeter and are fundamental to a modern security strategy. Validating the identity of a user, whether human or machine, is the first step to ensuring that only those with the appropriate privileges can connect to the resources they need. This process is now much more complex because of the surge of automation where the number of active workloads fluctuates dynamically, with demand. This means both humans, as well as machines (workloads), need to validate the identity (authentication) and justification (authorization) of the source that’s attempting to connect.
The number of authentications has proliferated in other dimensions as well. Business applications and programs are no longer one large block of code. Rather, they operate using microservices and subcomponents, each of which needs its own secrets to authorize each use. For example, a user might need a password to authenticate and use a particular service, but that service also needs its own authentication process to access necessary database information and/or other microservices.
The credentials we’re referring to here can actually take the form of classic username/password pairs, API keys, SSH keys, certificates, and many others. We collectively refer to these data protectors as “secrets”; the authentication and authorization methods to access important and in many cases sensitive information.
How to Store and Protect SSH Keys, Certificates, And Other Secrets
With so many secrets in use, it is clear they need to be protected to avoid being compromised and to comply with various regulations. But in practice, it happens too often developers create shortcuts during testing and embed secrets in code or configuration files, which inevitably end up in public repositories.
79.5% of breaches involved stolen credentials to gain the initial foothold. (Verizon DBIR 2021)
Secret Realms
Most organizations consist of many different business units, different teams working on different products, using different tools, and different on-premise and cloud platforms. When developer teams individually manage the secure storage and lifecycle of secrets, it creates isolated secret realms (silos) throughout the enterprise. As a result, Security teams become challenged with auditing and accounting for all these different islands. Meanwhile, developer teams are limited in sharing or migrating projects to other teams, and their required secrets.
Security Teams
Security teams are responsible for the security posture of the entire organization. Therefore, they need visibility into all secret realms and be able to validate developer workflows and their security practices. Another dilemma for security teams is how to enforce the organization’s security without hindering developer creativity and business agility.
The Encryption Key Paradox
Traditionally, in order to ensure SSH keys or API keys were stored securely, and only be accessed by authorized identities, they had to be encrypted and managed with Role-Based Access Control (RBAC). The keys to these secrets needed to be protected by a dedicated, highly secure vault, that required a Hardware Security Module (HSM), for example. But then how do you ensure these keys are protected? That’s the paradox of Root of Trust, also known as the “secret zero problem”. Who can you truly trust to be at the end of the security chain?
Choices And Challenges
Now let’s explore some of the key considerations when evaluating Secrets Management solutions.
On-premise Vaults: Complex and Costly
There are vault solutions available for your data center, either in Open Source Software (OSS) or paid Enterprise versions. It is a popular choice for many organizations because of the incumbent/legacy tools in the market, and the many community-created plugins for the different DevOps tools that exist. The challenge with this approach is that these solutions are quite complex to fit into hybrid multicloud architectures. In addition to the underlying computing, networking, and storage infrastructure, you are responsible to purchase, deploy, and maintain the high-availability components such as load balancers. The scalability is usually reactionary, and over time, there is mostly either too much or too little capacity. And all these components require continuous maintenance, with associated software upgrades, service outages, and so on. All of this results in massive operation complexity and cost.
Cloud Vaults: Secret Store Sprawl
Cloud service providers (CSPs) such as AWS, Azure, and GCP provide their own vault services, with the basic scaling and availability features that you expect from a cloud service. However, the challenge with leveraging one of these offerings is that they are largely proprietary, and focused on supporting workloads that run within their own environment. If you use just one cloud platform and have no on-premise infrastructure, this approach may work. But most organizations have hybrid multicloud architectures, and now face the challenge of vault solution sprawl with individual islands of secret vaults.
Moreover, trust should be a major concern when looking at cloud vaults, or cloud-hosted vault instances. Cloud Vaults require you to share your master keys with the CSP. This means rogue admins or hackers can access your keys. In addition, CSPs can be forced to disclose the keys, and with that, the data they protect, through government orders such as the CLOUD Act. If you don’t own your keys, you don’t own your secrets.
PAM: Won’t Cover All Bases
Some Privileged Access Management (PAM) vendors now offer integrations for DevOps environments. Their PAM products have a long history of providing privileged human users with a locked-up password, which is only one piece of the full spectrum of secrets. And while some PAM vendors are adding some secrets management capabilities, they are often not fully integrated with their classic human access management. In addition, they lack critical secrets management features such as dynamic secrets that provide just-in-time access to ephemeral resources, or other critical features specific to secrets management.
Centralized Secrets Management Enables Agile Enterprises
The Akeyless Vaultless® Platform provides a true SaaS-based Secrets Management solution that enables security teams with centralized oversight and control of all secrets, for all humans and machines, across hybrid multicloud environments. It empowers DevOps and Cloud Transformation initiatives while enforcing continuous security compliance. Meanwhile, the multi-tenancy feature allows different teams and business units to manage their own secret realms autonomously.
Akeyless’ patented, FIPS 140-2 certified DFC™ technology enables a Zero-Knowledge platform, where customers have exclusive ownership of their secrets, without the overhead and cost of hardware HSMs.
With Akeyless, Secrets Management is delivered from the cloud and consumed as a service, so it is fast to deploy and eliminates the operational overhead associated with on-premise vault clusters. Our SaaS solution eliminates maintenance outages, and auto-scales for demand peaks, with built-in multi-regional high availability, and disaster recovery OOTB.
