Prerequisites

• Technically none, but this will work better if you complete our labs on creating public buckets.

The Lesson

It’s hard to express how many headlines directly result from someone making an S3 bucket public. We are talking epidemic levels. And like, oh say, a real-world pandemic, even when you think it’s over, it’s not really over.

When the first string of public buckets hit, the headlines would scream “AWS S3 was hacked!” This is the cloud equivalent of how every mobile vulnerability is “an iPhone hack” because… more sensational means more ad views, I guess. I was one of those security folks screaming into the void, “S3 wasn't hacked, people had to DELIBERATELY MAKE THEIR BUCKETS PUBLIC!”

And you know what? That was victim blaming. People weren’t making buckets public because they were stupid, but because it was too easy and more granular sharing was too complicated. There are so many ways to expose a bucket that AWS themselves must use automated reasoning (don’t call it AI, but it is) to figure out whether a bucket is public.

Amazon has improved AWS immensely since those big early breaches. Aside from taking steps like working to phase out ACLs, they started adding more alerts and features to reduce the chances we would make buckets public by mistake. Then they brought the sledgehammer to the rock fight, and released Block Public Access (BPA).

Block Public Access

I love BPA. The idea started with S3 and has since expanded to EBS snapshots and, as of like a week before I wrote this, VPCs. Block Public Access is a Security Invariant. These are high-level rules we can enforce across entire accounts, and sometimes entire organizations.

BPA for S3 is very simple in terms of implementation, but many of you are working in existing environments where it’s important to understand the process to implement BPA without breaking the hell out of things which actually require public access (like those CloudFormation templates I’m always sharing).

Here’s how it works:

• Block Public Access can be set for an entire account, or on a per-bucket basis.

• When you turn it on you can set it to instantly block all public access, or just enforce BPA for any new buckets.

• You can set it to only block access via ACLs, via bucket policies, or something called access point policies (which we haven’t covered yet).

• Or you can turn them all on.

What’s the difference? Well, we just worked through labs showing the difference between ACLs and bucket policies. If you follow my (and Amazon’s) advice, you’ll never use ACLs any more but… they are still used often. Setting BPA to disable them at the account level means that’s locked down hard. At least, assuming you don’t give anyone IAM permission to turn BPA off.

Bucket policies are more granular and you might want to allow them for sharing. But in my experience when you turn BPA on you probably want it on for everything.

Now, what’s that about pissing people off?

BPA is powerful. And for some percentage of security professionals, our instinct is to just lock it all down. The problem with that is S3 is used all the time to share things publicly for totally legitimate purposes. It can host images, templates (like for these labs), and even work like a web server. My product FireMon Cloud Defense is just a single-page application in an S3 bucket (with a related API gateway). We literally don’t have a web server for this big SaaS platform. If I turned on BPA at work it would… be bad. Very very bad.

Here’s my recommended process:

• In an existing environment use Access Analyzer and/or your Cloud Security Posture Management (CSPM) tool to identify any existing public buckets. Then hunt down whoever owns them (which can be very hard) and find out whether they should exist, and whether they comply with corporate policy.

• Write an SCP which prevents disabling BPA, and apply it to every OU except Exceptions and Workloads > Prod. Although depending on how you do things you might need to leave it off in some other OUs, like the one you use for M&A/onboarding. This doesn’t turn on BPA, but ensures that if it is on, nobody can turn it off.

• Use your account factory (which we haven’t gotten to yet) to enable BPA by default on all new accounts.

  • I don’t yet recommend using Resource Control Policies (RCPs) exclusively and ignoring BPA.

• Your Prod OU is a bit different, because you might need public access for some of those buckets. What about Dev, you ask? Non-prod? I get very nervous when those allow public access. For Prod I recommend making decisions on BPA at the per-account and per-bucket levels. I’ll show how that works on this lab.

• For existing accounts which probably shouldn’t have public buckets, you can turn BPA on with the setting to only apply to new buckets or objects. This won’t protect anything that’s already public, but prevents new things from being public.

When I go into a large environment with a lot of existing stuff, it is a complicated process, and I generally use automation to sweep through and fix things as best I can. But for us, today, I want you to focus on how it works and the difference between account-level, bucket-level, block everything, and block new.

Key Lesson Points

• Block Public Access (BPA) is a security invariant which prevents buckets and objects from being public, and can instantly block any existing access.

• It’s powerful, but AWS built enough flexibility into BPA that we can implement it without totally breaking everything.

• I hope you think a year of CloudSLAW is as big a deal as I do. I can’t believe I’m about to get a week off!

The Lab

For this lab we’ll go into TestAccount1 and enable Block Public Access in different modes, so you can see what they look like.

Video Walkthrough

Step-by-Step

Go to your Sign-In Portal > TestAccount1 > AdministratorAccess > S3 and then click Block Public Access settings for this account so we can review the account-level settings. Remember BPA is per-account; there isn’t an Organization-level master setting. We use RCPs when we want something to apply organization-wide.

We won’t change these, but this is where you go to lock down an entire account. For example I turn this on for all my dev accounts, which should never share anything public. Then I back that up with an SCP which blocks turning off BPA except for the security team. And… I typically set this even if I also have RCPs to block sharing, since BPA assures there aren’t any loopholes — I can mess up an RCP policy.

Now go back to Buckets > Your bucket with “bp” in the title — any bucket works, I just like to be consistent:

Then go to Permissions > Block public access (bucket settings) > Edit:

Now click either Block all public access, or pick the two boxes like I did in this screenshot for Any ACL or bucket policy. Why did I do it this way? Just to show you options… both have the same effect. Then Save changes:

Then type Confirm and click Confirm:

Now pick your other bucket, then Permissions > Block public access > Edit. This time pick the options for New buckets and objects only:

And go through the confirm dialog again.

Why this option? Imagine you have a production account, and want to host your website in S3, but prevent anything else from being public. You could set up the site and then turn on the new-only options like this; your existing bucket would be public (hosting your website), but no new buckets could be. Kinda cool.

It’s also good if you have messes to clean up. You can stop the bleeding with BPA, and then crawl through the mess to clean up older ones one by one.

Let’s see how this affects our Access Analyzer findings!

We’ll start by turning on BPA for the entire SecurityAudit account, then review Access Analyzer. Close the tab:

From your Sign-in portal (the tab should still be open, like mine) go to SecurityAudit > ReadOnly > S3 > Block public access settings for this account > Edit > Block all public access:

Shields are up, Captain!

Let’s check the sensors. IAM > Access analyzer > External access:

Notice anything? If you recall, last week we had 2 buckets listed here, since our first bucket had public ACLs and our second had a public bucket policy.

Why do you still have a public bucket? Think about what we did: we took our “bp” (bucket policy) bucket and said “block all public access.”

Then we took our other bucket (with the public ACL) and said, “block any new public access.” We didn’t shut down existing access, just new access. And that’s what Access Analyzer shows us! The bucket is still public, but new objects would not be.

I love it when a lab series comes together!

Bonus step

Go back into TestAccount1 and tag the bucket with classification: sensitive. Then come back to Access Analyzer and see if anything changes.

Lab Key Points

Look, you’ve completed 50+ labs at this point, probably over the course of an entire year. While we still have an endless amount of material in front of us, I just want you to sit back and appreciate how far you’ve come, and how dedicated you have been.

This has been a wild ride for me and I’m going to enjoy a week off, but CloudSLAW is far from over! I’m really looking forward to getting into some more advanced concepts and deeper fundamentals.

Thank you. Sincerely.

-Rich