Exploring the Risks of Read-Only Access in the Cloud

My career began with read-only access.

In my first job, I worked night shifts in a data operations center. Our team handled incidents identified either by monitoring or from end customers. This meant I often had to perform first, second and third-line troubleshooting. If we couldn’t identify and resolve the issue, our only option was to wake up a rather exhausted escalation engineer.

To further protect that on-call engineer’s sleep, I was empowered with read-only access to the network for our data centers. I could check configurations, confirm the state of elements and, as my knowledge grew, the on-call teams observed that my escalations became requests like ‘run the following command for me, I don’t have access.’

A lot has changed since then; I now spend my time working in the cloud rather than in the on-premise world of data centers. I would never grant someone the same level of access I started with, even if it’s just read-only.

Why Even Think About Securing Read-only Access?

The James Bond film “Goldeneye” (1995!) vividly illustrates the risks that read-only access presents in the cloud. In the film’s climax, the ‘lead programmer,’ Boris, dismisses a former junior peer for not having access to the firing capabilities of the satellite superweapon used for the sinister plot. He winds up eating his words as her reduced access allows her to steer the satellite into re-entry (thus, its destruction).

[Click here for the 90s, recorded off VHS magic.]

This is my favorite way to visualize the risk of ‘we don’t need controls over the read-only access we give juniors.’ The result was that Boris’s evil plan was spoiled. If only he’d been a little more considerate with how he handled access.

What Can an Attacker Do With Read-only Access?

Why am I focusing on what is often dismissed as a lower-risk element that doesn’t warrant attention? Attackers are creative folk; it’s known that attackers will always seek to reconnoiter their environment. Often, read-only is enough for them to do that. [Here’s a real-world example.] Giving read-only rights to the cloud without suitable controls will enable an attacker to do exactly that.

To expand on the example, many organizations are happy to permit the managed policy ‘ReadOnlyAccess.’ The policy is a great example of what is often perceived as a harmless read-only role – aside from the policy granting the ability to read and copy the contents of any element of blob storage in the account. That means the read-only access can be used to read any data store. And that isn’t good.

“Attackers are creative folk; it’s known that attackers will always seek to reconnoiter their environment. Often, read-only is enough for them to do that. “

It’s an obvious example, and most organizations remove the capability to read all the data stores. But there are plenty more things you could do to map or identify targets. List roles and the users they are mapped to? YEP! Download container images from your hosted private registry? For sure!

Going deeper, without turning this into a rant against managed policies, that managed policy also includes a little subset of permissions for SSM, AWS’s System Manager service. The section that grants SSM:Describe* worries me because it grants entitlements to all Describe functions aligned to SSM. The entitlement SSM:DescribeParameters allows you to see the environment variables of a running EC2 instance retrieved from Parameter Store. There are many people out there who still use parameter store for storage of credentials.

Knowing that I could possibly return a secret under management and read all the data in an AWS account paints a clear picture to answer, ‘How far can you go with just read-only?’ The more I research, the more I realize that any access to cloud consoles comes with a relatively high element of risk.

How Do We Address the Risk and Secure Read-only Access?

The reality is that you should treat read-only access the same way you treat any other elevated access when accessing the cloud. At CyberArk, it’s why we talk about zero standing privileges (ZSP); read-only access should be something you request, even if the request is auto-approved. You must make sure adequate controls are in place.

There is a temptation to say that not applying the same controls to users with just read-only entitlements will save you time and money too. But that’s a mistake; you’ll have to manage two sets of controls and monitor the read-only accounts to ensure they don’t end up with higher-risk entitlements that would warrant extra controls.

Flexibility in access should not compromise security; instead, it should be a strategic approach to grant the right privileges to the right users at the right time. Doing so would put you one step ahead of Boris from Goldeneye; you don’t have to worry about any second-level programmers crashing your satellite to foil your evil plan.

Understanding and mitigating the risks associated with read-only access in the cloud is paramount. Organizations can frustrate potential attackers and safeguard their cloud environments by implementing robust controls and adopting a proactive approach.

To explore the concept of zero standing privileges further and learn how to fortify your cloud security, check out our blog, “PAM and Cloud Security: The Case for Zero Standing Privileges.”

Josh Kirkwood is a senior product marketing manager at CyberArk.