I am pleased to announce my second course for Linux Academy, the Identity and Access Management Deep Dive. You really can’t have a properly functioning AWS environment without properly configuring IAM. Improper configuration can lead to your users not having the access they need, or worse yet, having too much access.

Presenting a course on IAM has its challenges. At the start of the course, work with the root account and then with an Admin account throughout the rest of the course. Normally, we like to provide as many hands-on labs for the student as possible, but handing out root account access is certainly a major security risk, and it prohibited us from using our Lab environment for this course. But have no fear! This course is designed to enable you to work in the AWS IAM environment and gain that very important hands-on experience. The course uses the split screen format made famous by Thomas Haslett’s AWS CSA-A Orion Papers. Every lesson has a diagram with key points and instruction as well as the AWS Management Console or CLI in a split-screen format.

Real World Scenario

AWS Identity and Access Management Deep Dive is based off of a fictitious scenario that you can follow along with and work through using your own AWS account. IAM Secure Corporation has hired you as a Lead Architect and your job is to configure AWS IAM for the company as they prepare for a migration of their IT Services to an AWS Cloud environment. Over 90% of the lessons are task-oriented and will provide you with great hands-on experience configuring IAM for any size company.

The course concludes with a thorough investigation and implementation of IAM Roles to delegate access to Users, Groups, and Services (EC2), using techniques like Cross-Account Access and Web Identity Federation. A little intrigue will be brought to the course with the introduction of the Confused Deputy Security breach, and you’ll learn how to resolve such problems, but more importantly, learn how to avoid them using best practices. Finally, be exposed to best practices when implementing IAM and troubleshooting IAM when problems arise.

In the spirit of fun, here’s a fictitious story that involves IAM and security issues associated with an improperly configured IAM. The first user to list the correct number of security concerns in the comments section of this blog will receive a Linux Academy hoodie.

The Fixer

Terrence Drayton was a Fixer (picture George Clooney in the movie ‘Michael Clayton’). If the price was right, he fixed things. Anything. He just had a knack. He was in his office with his head of IT, Ivy League and AWS whiz kid, Seth Fogell (picture Jonah Hill in ‘Moneyball’). They were on a conference call with one of Terrence’s college classmates, Freddy Newman. Freddy was always the life of the party, but Terrence never imagined he’d have his own tech company. Freddy had called frantically screaming that his AWS environment had been hacked. Freddy understood that Terrence was very expensive, but he trusted Terrence to save a sinking ship.

Seth began a rapid-fire interview:

 

Seth: How many users in your account?

Freddy: 50.

 

Seth: Can I get an Admin Account?

Freddy: I’ll send you the root account. We use that as Admin.

 

Seth: What is the password policy for your users?

Freddy: We don’t have one.

 

Seth: Are you using MFA for your root account?

Freddy: No, but we have access keys for the root account.

 

Seth: Are you using Access Keys for you users?

Freddy: Yes.

 

Seth: How many users have access keys?

Freddy: All 50 of them

 

Seth: How many users are making programmatic calls to AWS?

Freddy: Just our Dev team, 7 users total.

 

Seth: Are you rotating your access keys?

Freddy: Yes.

 

Seth: Do you give access to your account to any 3rd Parties?

Freddy: Yes.

 

Seth: Are you using Access Keys or IAM Roles for this 3rd Party access?

Freddy: IAM Roles.

 

Seth: Are you providing the 3rd Party with an External ID along with the Role?

Freddy: No.

 

Seth nodded to Terrence to indicate that he had what he needed.

 

Terrence chimed in, “OK Freddy; we have what we need. Give us two hours. And Freddy, I trust this check will not bounce?”.

 

Freddy: “C’mon Terry, you know me.”

Terrence: “Yeah, I know you, Freddy, that’s why I asked. We’ll talk again in two hours”.

————————————————

Be the first to identify the correct number of security concerns in this story in the comments section and win a Linux Academy hoodie. And don’t be Freddy!

Take the Identity and Access Management Deep Dive!

 

AWS Labs

4 responses to “Introducing the Identity and Access Management (IAM) Deep Dive”

  1. Shadab Khan says:

    Security flaw 1 : It is a bad practice to use a root account as an admin account for an AWS account.
    Security flaw 2 : It is a bad practice to not set up a password policy for users in an AWS account. One should setup IAM user policies as soon as an organisational account has been created with AWS.
    Security flaw 3 : Setting up a MFA to the root account adds another layer of security to it. An MFA is only available to the root account holder who can generate a new MFA code using either Key FOB / Google Authenticator. Not having an MFA in this case hasn’t helped the business as it was easy for the hacker to get through their AWS account with just one layer of security which is, the root account password.
    Security flaw 4 : Why do all 50 users require access keys ? Access keys are required to make programmatic calls to AWS resource APIs and as there are only 7 developers, giving access keys to 50 users makes no sense.
    Not exactly sure about this one, but how I feel external login should be provided to third party in form of Windows SSO / trusted Web identity i.e. Google/Facebook etc which would enable the third party to authenticate themselves before logging into the organisation’s AWS account. Also creating external IDs will not require the AWS account admin to unnecessary setup AWS users using IAM every time a new person joins the 3rd party group requiring an access to the company’s AWS account.

    • Craig Arcuri says:

      Thanks, Shadab for your interest and the great, detailed reply. Not quite there on the answers. Keep trying. Hope you enjoy the course.

  2. Terrance says:

    I’ll send you the root account. We use that as Admin. No password policy for your users. Not using MFA for your root account. 7 users total making programmatic calls to AWS.

  3. Jay Hill says:

    Seems like there’s 6 security concerns.

    Giving a 3rd party security guy they’re hiring the root user account access.
    Not having a password policy
    No MFA for anyone
    Utilizing root access keys
    All 50 users having access keys, but only 7 people actually making programmatic calls to AWS
    Using IAM roles but not external Id’s to know who’s doing what specifically

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Get actionable training and tech advice

We'll email you our latest articles up to once per week.