The Cloud Security Layer Cake: Modern Use Cases for PAM

Warm. Rich. Chocolatey. The way I see it, a proper chocolate layer cake is the best sensory experience a human can have. Let’s go a bit further still: good chocolate cake is the height of human achievement.

In the world of enterprise IT, one could say the same of a diverse, purpose-built IT infrastructure. Every enterprise application – whether internal or customer-facing – must run on the right server, virtual machine (VM), container or database for the task at hand.

And like a perfect chocolate cake, modern enterprise infrastructure is multi-layered. One foundational IT layer is the Linux and Windows servers that still effectively power tried and true applications on-premises. Another layer is composed of the cloud-hosted VMs where organizations ‘lift and shift’ applications in search of operational efficiencies. SaaS applications that empower the workforce are yet another layer. The same applies to the containers and serverless functions powering an enterprise’s cloud-native applications. And then, of course, there’s the most powerful (and highest-risk) layer of modern IT – the cloud management layer – where engineers and admins launch or change configurations via console or command-line interface (CLI).

Securing the identities with high-risk access to each of these layers requires tailored controls, identity security and privileged access management (PAM) programs that organizations charge with securing their highest-risk access can be carefully crafted to address every layer of modern IT infrastructure.

Essentially, PAM can help secure every layer of the cake. Here’s how…

Layer 1: PAM Controls for System-level Access to Workloads Running Inside VMs

It doesn’t matter how good a cake is if the foundation can’t support it. Many enterprises still directly manage much of the Linux, Windows, database and even mainframe infrastructure that powers their tried-and-true applications. This is especially true in highly regulated industries and verticals where low-latency computing is essential, like finance, energy and manufacturing. Even when organizations do move these established systems to the cloud for operational savings, many take a ‘lift-and-shift’ approach. These systems still work well, so there’s no need to re-architect them beyond moving them from on-prem servers to cloud-hosted VMs.

Whether they live on-premises or in the cloud, securing the privileged credentials and SSH keys that grant administrative access to these workloads will always be essential. This is especially true of built-in accounts on servers and VMs, such as Root accounts on Linux servers.

Foundational PAM best practices like automated credential rotation and least privilege access not only can reduce the risk of credential theft. Sometimes, these controls may even be required for IT security compliance or cyber insurance coverage.

Baking tip: Like good cake, good identity security programs need several layers. In addition to securing credentials, it’s essential to apply additional PAM best practices like monitoring and isolating privileged sessions. This can help deter insider threats while preventing ransomware and other malware from ever reaching VMs.

“Like good cake, good identity security programs need several layers. In addition to securing credentials, it’s essential to apply additional PAM best practices like monitoring and isolating privileged sessions.”

Layer 2: PAM Controls for Operational Access to Workloads Running ON VMs

Most VMs are short-lived. This is one of the foundational value propositions of cloud computing; organizations can run workloads on rented VMs without spending time and money on infrastructure maintenance. While high-risk administration on specific VMs may sometimes be necessary organizations generally don’t create dedicated system-level accounts (and the associated risk) for access to these short-lived machines.

PAM programs play an important role in securing access to ephemeral workloads. When access to specific, self-managed systems is needed, operational privileged access can be elevated just-in-time (JIT) to reduce the risk of credential theft, helping reduce standing privileges. IT and development teams can natively elevate access without SSH Keys or passwords using attribute-based access control (ABAC). Identity security teams can tag workloads for a specific project using CSP tagging features, allowing end users to natively connect only to resources tagged with this attribute. And since users don’t have passwords with standing privileges, there is a significantly reduced risk of credential theft.

Baking tip: The absence of credentials does not equate to the absence of trust. To embrace Zero Trust concepts for cloud access, embrace the ‘never trust, always verify’ paradigm. PAM Best practices like enforcement of least privilege and session isolation reduce trust. Meanwhile, the tried-and-true advice to implement adaptive multi-factor authentication (MFA) can help verify.

Layer 3: Access to Cloud Service Provider Services IN the Cloud

PAM teams already know: with great power comes great responsibility. Protecting the most powerful access in the public cloud is essential. And that includes the access elite engineers use to launch, configure and decommission the services powering their applications. Whether these engineers access this cloud management layer via web consoles or CLIs, their access must be protected.

JIT elevation can help reduce the risk of credential theft in these scenarios. But once access is elevated, development teams have, to borrow their parlance, ‘god-level’ entitlements to spin up – or take down – anything they want.

Many organizations are embracing the emerging security concept of zero standing privileges (ZSP) to safeguard development teams without slowing them down. In this model, engineers can elevate access JIT only to roles scoped with just enough permissions for the job at hand (or, in other words, least privilege access).

ZSP provides meaningful, defense-in-depth risk reduction. First, developers do not have credentials with always-on access, so those credentials can’t be stolen. Second, even if developers become malicious insiders or have their access compromised, their permissions are limited, reducing the blast radius of an attack.

Baking tip: Empower developers with ZSP, instead of slowing them down. In an outage or critical situation (‘critsit’), engineers need the ability to use their preferred tooling to request elevated entitlements and save the day. Integration with preferred development tooling is critical for these cases and any meaningful adoption of PAM controls. The same is true for session monitoring controls to deter internal threats and maintain audit trails for compliance purposes.

“Empower developers with ZSP, instead of slowing them down. In an outage or critical situation (‘critsit’), engineers need the ability to use their preferred tooling to request elevated entitlements and save the day.”

Layer 4: High-Risk Access to SaaS Apps

Risk isn’t confined to infrastructure and software environments. It also exists in cloud-hosted web applications used by every workforce member, from software engineers to HR and finance administrators. Unfortunately, this access also presents a significant security risk, considering attackers can use it to gain access to sensitive data.

Organizations can protect this final layer of high-risk access in the cloud with web browser session protection and monitoring controls. Session protection can defend against session hijacking and cookie theft attacks. Just as with infrastructure or console access, monitoring high-risk sessions can provide a complete audit trail of user activity to satisfy compliance requirements and deter internal misuse.

Baking tip: To get the cloud security recipe right, adjust controls according to the risk level of data in a SaaS application. For example, compromised access to apps containing IP or EHR data pose more risk than access to a training application. Just like with the PAM controls securing access to high-risk infrastructure, requiring step-up authentication to the most sensitive web apps is a simple best practice that can significantly reduce risk.

Bonus Layer: Secrets Management (the Icing on the Cake)

Humans aren’t the only identities requiring privileged access in multi-cloud environments. Machine identities like serverless functions, application accounts and RPA bots also use credentials to authenticate autonomous processes. In fact, it’s estimated that machine identities outnumber human identities in today’s software-heavy world by a factor of 45:1.

Organizations must govern application secrets consistently to reduce the risk of attackers compromising hardcoded credentials. Centralizing governance and credential rotation in a single cloud-agnostic hub can help mitigate this risk.

Baking tip: For the tastiest frosting, cater to the tastes of your development teams. Many engineers prefer to use native tooling from AWS, Azure and GCP. Allowing for the rapid ‘retrofit’ of credential management to cloud-native secret stores can keep developers happy – and secrets secure.

Intelligent privilege controls are vital ingredients within every layer of a multi-cloud environment. With a layered approach to securing privileged access, organizations can develop a powerful recipe: user-friendly security that doesn’t slow down engineering velocity. That’s quite the achievement – although maybe not as impressive as a warm, rich chocolate cake – but an impressive output, nonetheless.

To learn more about all layers of the multi-cloud identity security cake, feast your eyes on the CyberArk executive POV, “Why Cloud Identity Security and Why It Seems So Hard.”

Sam Flaster is a director of product marketing at CyberArk.