Ten Years of Cloud Security

The AWS Cloud really started out as a service or two. Those of us using the first few services didn’t really think of it as a “cloud”. At that point it was just a series of services that were very good at solving very specific problems.

Amazon SQS was the first out the door in 2004. Amazon S3 and Amazon EC2 followed two years later. Over the next three years, AWS launched several more services—like Amazon DynamoDB, Amazon Elastic Block Store, and Amazon CloudWatch—that form the core of what we now know as the AWS Cloud.

These services were a great start but the idea of the “AWS Cloud” didn’t really come together for me until the launch of AWS Identity and Access Management or as we all know it, IAM.

Next Level Access Control

When IAM launched in 2011, it was the first time that these separate services really felt like one big offering. Now the AWS Cloud was stitched together with a common fabric and I could use whatever piece was the most appropriate for the problem at hand.

As a security professional, this really started to open up new possibilities. Now we had a consistent, common permissions system that was accessible via one API!

Remember that while ActiveDirectory was the dominant player at the time, most services used it only for authentication. Some were starting to take it deeper but it wasn’t a comprehensive solution outside of the Windows ecosystem.

That’s understandable given the wide variety of equipment in use in the typical data center. Hundreds of different vendors for software and hardware. We counted ourselves lucky if we had a directory as the single source of truth for authentication. Let alone access control.

Then along came AWS IAM.

Millions of Requests Per Second

Jeff Barr has a great overview of the feature timeline for AWS IAM in his post, “Happy 10th Birthday – AWS Identity and Access Management.” Near the end of his post, he shows us just how big AWS IAM has gotten. It currently processes “more than 400 million API calls per second worldwide.”

That’s 12 QUADRILLION requests per year.

That’s crazy.

It’s also the only number I’ve seen from AWS that makes Amazon S3’s 100 trillion objects stored number look small.

It’s also a strong data point showing how critical this service is to builders in the AWS Cloud.

Game Changer

If you’re not a security nerd like me, it’s hard to properly put the impact of IAM into context. It truly has changed how we can handle access to our systems.

Jeff’s post shows some of the highlights like IAM Roles, Attribute Based Access Control, and conditions. But this doesn’t really do justice to what the service has enabled.

The goal of cybersecurity is to ensure that your systems work as intended and only as intended.

When you’re dealing with an environment that is constantly changing like the AWS cloud, this is only possible if you can ensure that only the right systems and authorized people have access to your data at any point in time.

IAM does a great job of meeting this need.

Is it perfect? No.

Has it the set the standard for what we expect in this type of system? Yes.

Frustrations

Any system at this scale has to make trade offs and will inevitably have rough edges. While there are always placed for improvement. IAM has done a great job of avoiding major missteps.

…and yes, I know that in some cases you can submit policies in YAML and yet I still standby that statement. 🤣

By far my biggest gripe with the system is in the managed policies. These are policies that are created and maintained by AWS. The concept is an excellent one.

It’s a great way to reduce friction with these smartly maintained policies. Any builder can simply assign on theses policies to suit their need and be reasonably assured that they have a good starting place.

My problem? The series of policies that end in FullAccess

Just typing that frustrated me. Every time you create an access policy, you should be aiming for one that adheres to the principle of least privilege. The idea is simple. Only grant the permissions required to do the task at hand and nothing more.

I’m sure you can guess which permissions are granted with these FullAccess policies. If you said, “All of them.” You got it on one.

It’s the exact opposite of the principle of least privilege.

Now logically, I understand why these policies exist but I would love to change their name. I think all of them should be labelled FullAccessTemporaryForTroubleshootingOnly or FullAccessButJustLookInCloudTrailToSeeWhatYouActuallyNeed but neither of those is too catchy and probably won’t look good in the AWS IAM Management Console.

The Good, Great, and Amazing

On the positive side, we have all of the fantastic core IAM features that Jeff listed in his post and the series of blogs the AWS Heroes are posting this week.

04-May from Rowan Udell, “IAM 10th Anniversary: Top Recommendations for Working with IAM from Our AWS Heroes – Part 1”
05-May from Ben Bridts, “Top Recommendations for IAM from Our AWS Heroes – Part 2: The Visual Editor and Federation”
06-May from Iam Mckay, “Top Recommendations for Working with IAM from Our AWS Heroes – Part 3: Permissions Boundaries and Conditions”
07-May from me! “Top Recommendations for Working with IAM from Our AWS Heroes – Part 4: Available Permissions and User Identity”

But I’ll add to that list with some AWS IAM-adjacent features;

The AWS IAM Access Analyzer. This tool enabled automated policy validation and creation. It’s a time saver and extra assurance that you’ve got that policy tuned in just right.
AWS SSO allows you to use your existing directory of users (like ActiveDirectory, Okta, and others) and bridge them into the AWS IAM system. It’s critical for any enterprise.
Ben Kehoe’s excellent aws-sso-util tool to make using AWS SSO easier. It’s a life saver and we all owe Ben a big “thank you!” for creating it.
Netflix’s ConsoleMe project. This tool tackles some of the complexities of multi-account, multi-role management. With the power made available in IAM, things can get out of hand quickly, ConsoleMe helps you rein things in.

Getting Started

If you’ve seen IAM grow up, a quick link to the documentation is probably all of you need to get started with a new piece of the IAM puzzle. But if you’re just getting started or need a refresher, where do you start?

Remember that everything is “off” to start. AWS IAM is a “default deny” environment (except for the root account!) which means you need to specifically grant permission for anything to happen.

With that in the back of your head, I strongly recommend watching “Getting started with AWS identity services” by Becky Weiss from AWS re:Invent 2020.

This 30m talk walks you through the core principles behind AWS IAM and its adjacent services. After that, check out this fun series from Cloud Bart on the service.

As a bonus, if you’re an A Cloud Guru student, check out Kesha Williams’ course, “Introduction to Identity and Access Management (IAM).” It’s a great way to get hands-on and Kesha does a great job of breaking everything down into easy to understand blocks.

Eventually working up to the AWS IAM tutorials in the User Guide. Once you’ve completed those, check out Brigid Johnson’s excellent talk from AWS re:Invent 2020, “AWS Identity: Next-generation permissions management”

That should get your started on you AWS IAM journey.

What’s Next?

AWS IAM has come a very long way. It’s truly changed how we manage security in the cloud. More importantly, the launch of the service created what we now think of as the AWS Cloud.

IAM is the backbone of AWS and on its ten year anniversary, it’s already delivered a revolution in cloud security. The really exciting part? I know the team has only just gotten started…