The Anatomy of Cloud Identity Security

Originally published by CyberArk.

Written by Alyssa Miles.

There’s currently a cybersecurity adage with varying verbiage and claimed origins – the point, however, is unmistakable:

“Attackers don’t break in. They log in.“

This saying underscores the strategic shift associated with cloud adoption’s prominence in shaping the digital landscape. New environments have created new attack methods to gain access by logging in rather than infiltrating a perimeter. As technologies continue to advance, we cannot expect previous security methods to tackle these new challenges.

Before cloud environments, attackers had to break into on-premises infrastructures with a protected perimeter. Networks, servers, hardware and software were all safely within this perimeter, monitored and managed by IT. Now, organizations are effectively demolishing it. They are utilizing cloud technology and storing data on several different clouds.

Once attackers gain entry to these multi-cloud estates, any movement can mean organizational destruction. Keeping the cloud secure is vital to an organization’s business success.

But what exactly does it mean to secure the cloud? Let’s first rewind to equip ourselves collectively with the basics of cloud identity security.

Defining Cloud Environments and Deployment Types

The cloud is comprised of internet-based computing services for storage, processing and software access.

Though it sounds simple enough, when tasked with protecting “the cloud,” this answer becomes somewhat more complex. Your mission also includes protecting the various forms of cloud deployment models. Responsibilities are often unclear, but your organization is always responsible for your data, regardless of your cloud type.

Cloud environments have four different cloud deployment models, each with unique benefits and security risks. These models are:

Public Cloud: The Open Playground on the Internet

Think of the public cloud as a vast, shared playground accessible to anyone with an internet connection. Third-party vendors, such as Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP), provide cloud services in this model.

Private Cloud: The On-premises Infrastructure

Unlike the public cloud, the private cloud is like having your own exclusive club – an infrastructure dedicated solely to your organization. In this model, cloud resources are provisioned and managed within a private network, offering enhanced security, control and customization. A private cloud also increases management responsibility.

Hybrid Cloud: Not Fully Committed to the Public, But Also Not Fully On-premises

As the name suggests, the hybrid cloud combines on-premises infrastructure and cloud services, interconnected to create a unified environment. This model allows organizations to leverage the scalability and flexibility of the public cloud while maintaining control over sensitive data and applications in the private cloud. But, a hybrid cloud also increases technical complexity.

Multi-cloud: Everything, Everywhere, All at Once

In the multi-cloud model, organizations harness the power of multiple cloud providers. All hybrid clouds are multi-clouds – but not all multi-clouds are hybrid clouds. By spreading workloads across multiple clouds, organizations can mitigate risks, avoid vendor lock-in and optimize performance and cost.

Understanding Cloud Services and Resources

Now that we’ve covered cloud deployment models let’s get closer to learning how to secure the cloud by first discussing what needs to be secured.

All cloud environments contain two elements:

1. Management platform and services

Management consoles (accessed via the web UI, CLI or API) are the main access points into the cloud. Cloud management platforms (CMPs) are your organization’s tools to monitor and control your cloud environments. Capabilities and integrations can vary widely across vendors, but your organization will require some form of CMP, depending on the type of cloud model. All the resources in the cloud are called cloud services.

2. Infrastructure workloads

The second element is infrastructure workloads. Cloud resources, including virtual machines, containers, serverless functions, cloud-native apps and storage created by different cloud services, can run specific apps, services and workloads.

There are services to administer and create these various workloads, but what’s unique about these resources is that they, too, require a separate layer of identity security controls, separate from that of the platform or services.

The Shared Responsibility Model

To comprehensively grasp cloud services and resources, it’s crucial to delineate the respective responsibilities of organizations and cloud service providers (CSPs). Enter the shared responsibility model, which created for this reason. This is how CSPs communicate responsibility for the management and security of services. Some things are their problem, and some things are yours.

You will always be responsible for who can access the management console, cloud services and infrastructure workloads, which is where cloud identities come in.

Exploring Cloud Identity Types

Identities refer to who can access what in the cloud. Each type of identity has different access needs, which means each identity poses a different level of risk to your organization.

The four different types of identities that need to be secured are:

1. Cloud Operations Identities

Having evolved from traditional IT roles such as infrastructure operations, networking engineers or database admins, cloud operations identities are roles like cloud operators, architects and site reliability engineers. Within cloud operations, full cloud administrators have complete administrative access and the ultimate permission to affect every service and resource within the CSP account. There are also service-level admin roles, like engineers with specializations in networking or databases, that can only administer a smaller scope of services and resources.

2. Developer Identities

The umbrella of developer identities includes any human engineers who write code. Developers will self-administer various cloud services, create cloud-native applications, push workloads into the cloud and access supporting resources.

3. Application and Audit Team Identities

Other application teams, aside from developers and any audit teams checking compliance, will require access to cloud environments. Though they will require lesser privileges, like read-only access to various services, read-only access can still pose a security threat to your organization.

4. Machine Identity Workloads

The cloud-native applications, services, automation tools and processes that run your business are considered machine identities – and they now outweigh human identities by a factor of 45:1. Some risks for machine identities include access keys coded into software and released to the public.

The ‘How’ of Cloud Identity Security

Now that we’ve discussed the what and where of building secure, well-architected cloud environments, tackling the how requires adhering to a couple of essential guiding principles:

Zero Standing Privileges

The dream scenario of access is to reduce its availability and impact, giving someone access to the one thing they need to do and nothing else. However, these logistics are often viewed as unrealistic in the highly complex world of cloud security, especially in keeping up with cloud innovation and required velocity. The principle of zero standing privileges (ZSP) is the best solution to these challenges. You can remove persistent privileges to limit implicit trust and provide several levels of control to verify access.

Time, Entitlements and Approvals (TEA)

Designing a better user experience while keeping security foundational can be a significant challenge, especially for roles that require velocity, like developers. The key to this balanced cloud strategy is TEA:

Time: How much time is access granted?

Entitlements: What level of access have you granted?

Approvals: What level of checks have you undertaken on access?

You can achieve ZSP by controlling the time of sessions, dynamically provisioning least privilege entitlements and ensuring proper approvals are in place. To dive deeper into implementing ZSP and increasing the adoption of security controls, check out this fireside chat with CIO Mentor and Advisor Simon Ratcliffe and CyberArk VP of Engineering Shay Saffer.

As threat actors continue to refine log-in attack methods during the escalating adoption of cloud technology, it becomes increasingly clear that relying solely on legacy security measures is no longer sufficient. Embracing a cloud-first mentality and prioritizing identity security in the cloud is the next step in fortifying defenses in this perimeter-less era.