I am pleased to announce my second course for Linux Academy/Cloud Assessments, 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, the student will be working with the root account and with an Admin account throughout the rest of the course. Normally, we like to provide as many 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! We have designed a course which will still enable the student 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 Orion Papers. Every lesson will have a diagram with key points and instruction as well as the AWS Management Console or CLI in a split-screen format.

The course comes with a scenario that the student can follow along with and work through using their own AWS account. The scenario is that a fictitious company, 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 the student with great experience configuring IAM for any size company.

The course will start with just a root account and no IAM configuration. The student will learn how to manage the root account, create administrator users and groups, and ultimately follow best practices and lock away the root account from everyday use.

The student can then follow along and configure Users and Groups for IAM Secure Corp and place those users into Groups based on department/job function. As a company grows, it can be very helpful to allow users to manage their own accounts, such as access key rotation and MFA configuration, and the student will be instructed on these techniques.

The brains of the whole operation are IAM Policies, and the course provides two entire sections on working with Policies. The first section focuses on Identity-Based Policies and attaching those Policies to the Users and Groups created in previous lessons. The second section focuses on Resource Based Policies and granting access to resources such as S3 Buckets. The Policies sections will be wrapped up with the student gaining hands-on experience using the new IAM Policy Visual Editor.

The course concludes with a thorough investigation and implementation of IAM Roles to delegate access to Users, Groups, and Services (EC2), using such techniques as 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 the student will learn how to resolve such problems, and more importantly, learn to avoid them using best practices. Finally, the student will be exposed to best practices when implementing IAM and troubleshooting IAM when problems arise.

In the spirit of fun, I’d like to present a fictitious story that involves IAM and security issues associated with 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/Cloud Assessments 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/Cloud Assessments hoodie. And don’t be Freddy!

Take the Identity and Access Management Deep Dive!

 

AWS Labs

3 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.

Leave a Reply

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

Get actionable training and tech advice

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