A popular topic of conversation in my day-to-day work is how to secure privileged access to cloud management consoles and workloads. And that’s no surprise, considering more and more applications and workloads are migrating to the cloud.
Up until recently, the answer has typically been clear when it comes to identity security and privileged access management (PAM). It’s simple: first, you manage credentials by securing them in a vault. The next step is to rotate them. I’ll even give you extra points if you implement session management for recording and isolation between the end user machines and target systems.
This advice has been the same for quite a while now, and for good reason. It works. But new best practices – like zero standing privileges (ZSP) – are emerging to secure federated privileged access in the cloud.
[Author’s note: In this blog, I will focus solely on access to cloud management consoles.]
A Cloud Access Revolution
Things become a bit more complicated when we start talking about PAM for cloud consoles such as AWS, Azure or GCP. But why would a strategy that’s worked for years suddenly not be as straightforward for the cloud?
One primary reason is that cloud service provider (CSP) consoles behave much like SaaS applications. A key benefit is that they are easily accessible from anywhere via a web browser with internet connectivity.
This accessibility is something that CSP console end users – notably, developers and cloud engineers – love and have come to expect. At the same time, this benefit clashes with the user experience (UX) that PAM best practices have previously constrained them to.
Let’s dive into an example of this challenge…
Imagine an application running in AWS, Azure or GCP that’s not functioning as expected. Our DevOps engineer, Chuck, needs to gain access to the CSP console or command line interface (CLI) to diagnose and fix the issue. Chuck must first access the PAM solution that securely manages the CSP credentials, following the previously mentioned best practices. Once he obtains access to that solution, he must connect to the cloud console via session management.
There’s a bit of irony in this user experience – the CSP console is supposed to be a SaaS application available anywhere from a web browser.
From Chuck’s point of view, restrictions are preventing him from working natively on his system with his own credentials. Not to mention, things become even more difficult if he wants to use the CSP CLI like many developers. If you’re still with me, let’s acknowledge that this scenario doesn’t exactly spotlight smooth accessibility.
Suppose we flip the script and look at this from the security perspective. In that case, a certain number of standing credentials with privileged entitlements must be available at any given time for end users (and potentially attackers) to utilize. Not a great scenario either.
The Time, Entitlements and Approvals (TEA) Concept Enters the Picture
So, how do we design a better experience for our developers and cloud engineers while keeping security foundational? Combining the concept of time, entitlements and approvals (TEA) is an approach we can use to our advantage. With TEA, we no longer need to manage standing credentials for “what if” scenarios and force developers and cloud engineers to use them.
From the example above, let’s see how TEA can provide a better experience for our DevOps engineer, Chuck. When Chuck needs to gain access to the CSP console to diagnose and fix the app issue, he no longer needs to go to another solution to utilize standing credentials through a proxy. Instead, he can log in to the CSP console or CLI natively with his own federated identity.
In addition to this improved user experience, Chuck’s federated identity has ZSP to the CSP console. This setup means that no entitlements are available by default, providing an essential layer of security. Only after the necessary approvals are met (automatic, contextual, manual) will privilege access be granted. This access is only approved for the window of time required and with specific entitlements (aka the principle of least privilege (PoLP)). An audit will also readily pinpoint the work Chuck performed during this period because he logged in with his federated identity. Once the approved session expires, those entitlements are automatically revoked, taking Chuck back to ZSP and securing our environment.
Reimagining PAM and Its TEA UX Makeover
PAM has been an essential pillar of cybersecurity for years and will continue to be even as more development moves to the cloud. However, this doesn’t mean PAM shouldn’t adapt. Concepts such as ZSP, just-in-time (JIT) and dynamic access are paving the way for the evolution of PAM.
It’s (TEA) time to give developers and cloud engineers their desired user experience – one that capitalizes on the benefits that SaaS and CSP consoles provide while still enforcing the necessary level of security. And it all comes down to the right combination of time, entitlements and approvals.
Let the evolution of PAM continue.
Mike Bykat is a global solution strategy architect for Cloud Security at CyberArk.
