Richard Feynman said, “The first principle is that you must not fool yourself and you are the easiest person to fool.” This rings true in cloud security. We’re all doing the best we can (I am learning new things literally every day) but the reality of how data is protected in the cloud is poorly understood.

I’ve seen two notable things watching cloud teams work. First, most companies don’t really understand AWS and how it works. There are smart folks with the best of intentions who aren’t given the time or budget to fully grasp this new world they’ve been thrown into. So people lean on tools – good tools that provide great insights if you understand the context. Because the cloud itself is poorly understood, the findings from tools are not well understood. I’ve literally been told, “Just make the Prowler warning go away.”

Second, I’ve noticed that solutions must have a minimum size and complexity. A simple solution with a straightforward architecture is met with skepticism: something must be missing, surely it can’t be that simple. Complexity implies thoroughness, thoroughness implies correctness. We don’t want to verify the details; we just want to have enough detail that it feels right. I don’t think this is unique to security or cloud; it’s human psychology, made worse by a lack of understanding and time.

We want to ensure our data is not available to anyone it shouldn’t be. So, we design network architectures to guarantee that a single byte never travels over the public internet. That’s commendable. What we lose in that discussion is the fundamental nature of Amazon Web Services: they’re publicly accessible web services. The control plane of every service is publicly accessible, anyone in the world can make a request to control your resources. The data plane of many of these services is public-first with no way to turn that off, especially for the older or more fundamental AWS services like S3, SNS, SQS, DynamoDB, and KMS. If someone knows the name of your S3 bucket, they can use the S3 API to request that data, there is no way to disable that feature. So, what’s really protecting your data from all the wrong people in the world accessing it?

It’s a JSON file. Just kidding! It’s multiple JSON files and sometimes there are checkboxes. Really, that’s all it is. Take a deep breath, let it sink in. It’s going to be okay.

That first JSON file is called a Resource Policy. IAM policies in AWS relate to either principals — the identity making a request — or resources — the things the request is being made on. Resource policies are attached directly to a single resource like a DynamoDB table, an S3 bucket, or a KMS key. These policies can make a resource available to principals outside your organization, other AWS accounts, or in some cases the public.s

As of my testing in November 2024, you can:

• Make an S3 bucket available to the public or another account by changing the bucket policy. You may need to adjust the Bucket and/or Account Block Public Access settings.
• Share a DynamoDB table with any other account by updating the table policy, you do have to specify the account.
• Make a KMS key available to anyone with an AWS account simply by setting Principal: ”*” in the key policy. No checkboxes required.

In the AWS Shared Responsibility Model, these fall squarely on the “your problem” side of the line, there are valid reasons for these options. Plus, you’re a grown-up with adult money — you can do what you want.

This isn’t a criticism of AWS. These technologies, their ubiquity, and their flexibility have made it possible for us to move data faster and more securely than ever before. This is a big improvement over how we used to do things.

The other JSON files can be a new feature AWS just announced, Resource Control Policies (RCPs). RCPs were just launched this month. They are a new type of organization policy, similar to Service Control Policies (SCPs) but for resources. These allow you to create rules that apply to all resources in your organization. In initial testing they appear very effective, also difficult to use correctly and there is still a lot to learn about how to use them. These are a way you could block some of the actions I just did, assuming you are using them, and using them correctly.

”But I Use VPC Endpoints!”

VPC endpoints only protect the data going in and out of your VPCs. The public APIs are all still available anywhere.

”Yes! But I Have Service Control Policies!”

SCPs only apply to the principals in your organization. They don’t have any effect on principals from other accounts or anonymous principals even if they are making requests for resources in your organization.

”So What Can I Really Count On?”

The one thing protecting your data (and your credit card bill) is understanding Identity and Access Management (IAM). AWS IAM is battle-tested and operates at an unfathomable scale. It’s also massively complex, poorly documented, and most significantly of all, not well understood by most people using it.

You probably won’t have much success submitting a Visio diagram with a two boxes that says “really good resource policy” and “well deployed RCP” to your enterprise security team. But between me and you, the rest of the diagram doesn’t matter without it. If you are in charge of a cloud security or enablement team, please invest the time – and the money – to ensure your team understands IAM well. Also, make sure you read any service specific IAM documentation when editing a resource policy. Every service works a little differently.

Resources

There are tons of resources out there to help you learn and understand IAM. I recommend this series on IAM policy evaluation by Matt Luttrell at AWS. I’m also trying to do my part (psst, try editing one of the policies) to help with documentation and hopefully will have more soon. Whatever the source, please take the time to understand IAM and how it works. It’s the thing standing between you and a terrible, horrible, no good, very bad day.