Security Cloud Privacy Tech
Ten Years of Cloud Security

Ten Years of Cloud Security

7 minute read | Last updated 3-May-2021 | An icon depicting a retail tag with a heart for 'favourite' Cloud, AWS

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.

Index

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

A screenshot of the AWS IAM Management Console with the policies ending in 'FullAccess' displayed

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.

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

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…

More Content

Prev: What Do You Want To Learn?

Next: Top Recommendations for Working with IAM from Our AWS Heroes – Part 4: Available Permissions and User Identity

Back to top

Related Content