It’s critical to understand how IAM works and what can be achieved via the service, but it’s even more important to know how to implement its features.  Without IAM, there would be no way of maintaining security or control of who or what could access your resources and what they could do with them, both internally and externally.  IAM provides the components to maintain this management of access, but it is only as strong and secure as you configure it.  

The responsibility of implementing secure, robust, and tight security within your AWS account using IAM is yours, you are the owner of the AWS account.  You must define how secure your access control procedures must be, how much you want to restrict users from accessing certain resources, how complex a password policy must be, and if users should be using Multi-factor authentication.  All of this is and much more is down to you to architect and implement, and much of it will likely depend on your own security standards and policies within your Information Security Management System (ISMS).

In this lecture, I want to talk about some of the different features and components that AWS IAM uses to centrally manage and control security permissions for any identity requiring access to your AWS Account and its resources.  

From with the AWS Management Console, the IAM service can be found under the ‘Security, Identity & Compliance’ category, and when accessed it will take you to the IAM Dashboard.  

The initial dashboard of the IAM Console will display the following information.

This is a URL link that you can send to users who you will need to gain access to your AWS Management Console.  This sign-in link can be customized by clicking on the ‘customize’ button to make it easier to remember and read.  If you have multiple AWS accounts, this customization would help to distinguish between your accounts

IAM Resources. This section provides a summary overview of your IAM resources using a simple count of the number of users, user groups, roles, customer-managed policies, and identity providers you have configured within IAM. 

Best Practices. This is populated with a list of IAM security best practices that AWS recommends you implement with links on how to implement them.  I strongly recommend you try to adopt these best practices at your earliest opportunity.  Maintaining tight security is paramount with working within a cloud environment.

In addition to this dashboard, you will also see 2 categories on the left menu, Access Management and Access Reports each listing a number of components underneath. I want to start by reviewing each of these components under Access Management to give you an insight into what each are used for, starting with Users.

User objects are created to represent an identity, this could be a real person within your organization who requires access to operate and maintain your AWS environment, or it could be an identity that is used by an application to interact with your AWS resources programmatically.   Users are simply objects representing an identity which are used in the authentication process to your AWS account.  Being unique values, every user has an Amazon Resource Name, an ARN which it can be referenced by.  An example of a user’s ARN could be as shown.

When configuring your Users you can set them up for Multi-Factor Authentication. Configuring MFA allows for an additional level of verification to be applied, the user will have to enter a random 6 digit number from a linked MFA device after their usual password.  MFA should be used for the AWS Account owner and any other users who have elevated privileges.  

IAM USer Groups are objects much like user objects, however, they are not used in any authentication process, instead, they are used to authorize members of the group access to AWS resources.

So, the IAM USer Groups contain IAM Users, and these groups have IAM policies associated that will either allow or explicitly deny access to AWS resources.  These policies are either pre-existing AWS Managed policies, customer-managed policies that are created by you, the customer, or in-line policies which are embedded explicitly to the group itself.

IAM Roles allow Users, other AWS services, and applications to adopt a set of temporary IAM permissions to access AWS resources.  Roles essentially operate the same as User objects do in that it’s an identity with associated permissions to allow it access to different resources.  The difference being however is that roles don’t define a single person, they are designed to be assumed by any identity or service that needs to temporarily acquire a set of permissions.  Additionally, roles don’t have passwords associated with their identities, instead, like I just mentioned, roles are assumed as long as you have the correct permissions to assume it.

Policies used within IAM are written as JSON documents and these define what can and can’t be accessed.  These policies can be attached to Users, User Groups, or Roles.  

When working with policies, you can use Managed policies or In-line policies.  Managed policies are viewed as a library of usable policies and come in 2 different flavors which can be applied to multiple Users, User Groups, and Roles:

1. AWS Managed Policies: These are a list of predefined policies granting varied access to different AWS services
2. Customer Managed Policies: These are policies created and written by you as the customer

Unlike Managed policies, Inline policies are not stored in a library, instead, they have to be written and explicitly embedded within a User, User Group, or Role, as a result, the same policy can’t easily be applied to another identity like Managed policies can.

If you are looking to provide federated access to your AWS resources, then you must add an identity provider. 

Federated Access allows credentials external to AWS to be used as a means of authentication to your AWS resources.  For example, you could establish a trust between your Active Directory Federation server on premises and your AWS account.  Or, you could establish a trust between your AWS account and Google account.  Either way, in these instances your ADFS server or Google account could be configured as Identity Providers allowing those authenticated by Active Directory or Google to access your resources in your AWS account.  This prevents you from having to create individual IAM user accounts.

Under Account Settings, you can enforce a password policy, and it’s always best practice to do so.  The Password policy should be used to enforce the minimum security requirements that need to be met for any password standards that your organization might have to adhere to.  The password policy applies to all IAM users within your account, and as you can see here, you can be very specific by enabling/disabling and configuring different controls.

The STS service is used to allow you to request temporary, limited-privilege credentials for both IAM users and federated users.  The STS endpoints provide a list of Regions that are either activated or deactivated for STS.  By default, all Regions are activated, however, it is recommended you deactivate the regions you do not intend to use.  

By default STS uses the global endpoint of  https://sts.amazonaws.com, however, when using regional endpoints it can help to reduce latency.

So that has given a quick overview of the component covered by Access Management, I now want to look at the features that come under the category of Access Reports, starting with Access Analyzer

Access Analyzer. This is used to generate findings when a policy on a resource within your zone of trust allows access from outside your zone of trust.  So this could be from a number of different sources, such as an IAM role allowing cross-account access, or a Bucket that allows a different account to upload objects into the bucket, basically any resource that allows external access to your resources will be flagged and highlighted to ensure you are aware of the access.  This is a great tool to help reduce security risks and threats as you or your team may have unintentionally allowed access to a resource you shouldn’t have.  Any issues are recorded by Access Analyzer as a finding allowing you to review the access 

The credential report is a great tool that allows you to generate and download a *.csv file containing a list of all of your IAM users and their credentials.  This provides a quick and easy way to review your accounts and the last time they were used, in addition to identifying when a user's password was last changed and if they have Multi-Factor Authentication enabled.

If using AWS Organizations, it allows you to Select an organizational unit (OU) or account to view its service activity over the previous 365 days.  By drilling down into the accounts in this section you can see which users have had activity, in addition to which AWS services they have accessed over a given time frame.  

Service Control Policies. This links in with the previous component, ‘Organization Activity’, and lists any Service Control Policies that are applicable to the account and the number of identities affected.  Service Control Policies, or SCPs, are different from identity-based policies which grant permissions to users, user groups, and roles as SCPs do not actually grant permission themselves. Instead, SCPs are used with AWS Organizations to implement and set a boundary of permissions for AWS accounts. 

For example, let's say a user within an AWS account had full access to S3, RDS, and EC2 via an identity-based policy in IAM. If the SCP associated with that AWS account denied access to the S3 service, then that user would only be able to access RDS and EC2, despite having full access to S3. The SCP would prevent that service from being used within the AWS account and so have the overriding precedence and determine the maximum level of permissions allowed.