For IT & Telecom Solutions Call (310) 955-1600
  • Contact Us

Key Concepts of AWS Identity & Access Management (IAM)

Security is paramount to the success of any business. No matter where your sensitive and vital information is stored, you need to know that it’s safe and secure at all times. This concept is no different in the cloud, with exception of how security is managed and monitored. If you currently use (or plan to use) Amazon Web Services (AWS), one of the first and most important things you should understand is how to effectively use AWS Identity and Access Management (IAM).

Not sure how to use IAM yet? No sweat. The experts at Shamrock Consulting Group can walk you through the entire process of securing access to your AWS account with IAM.



But even with Shamrock’s help, it’s important to educate yourself on the key concepts of IAM prior to setting up your first user. So let’s get to it!

1. Basic Terms Explained

Basic Terms, Explained

AWS uses several terms that may not mean much to those who have never used it, so here’s a quick guide to get you started:

Principal: The source of a request (e.g. logging into an account, editing user permissions or deleting a database). The principal can be either a person or a program.

Entity: A user or role (i.e. an identity) that the principal uses to identify (or authenticate) themselves with the IAM system.

Resource: Anything stored in IAM including users, roles, groups and policy objects. Resources can be added to IAM, edited and deleted.

Identity: A resource used to identify and/or group other resources. Examples are: users, roles and groups. Users are normally used for individual people or programs. Groups are used to group users together. Roles are often used for cross-account requests (e.g. where a developer needs to regularly move between two AWS accounts).

Request: An action or operation that an entity applies to a resource. Actions refer to requests via the AWS Management Console. Operations refer to either user or programmatic requests that have come via the AWS CLI or API.

All good with the terms above? Perfect!

Next, let’s look at the authentication process in more detail.

Entities and Authentication

First and foremost, in order to do anything within your AWS account, you have to sign in via an authentication process.

Authentication is the process whereby you (the principal) prove that you are allowed to access your AWS account. The very first time you access AWS, you will use your email address and password to access AIM as a root user. Once authenticated, you’ll have full unrestricted access and permission to perform actions or operations on all AWS resources.

Important note: Once you establish yourself as the root user, you should never access your AWS account as a root user again. Don’t do it! This will safeguard your AWS account in the event that your credentials are stolen, which could then be used to give free reign of your entire AWS account to whoever has the credentials.

Instead, set yourself up as the first user account and assign yourself administrator permissions. As an administrator, you’ll be able to add additional users, which can be people or even applications connecting via an API.

Every user on your AWS account will need their own credentials. Actual people will log in with a user name and password, whereas programs will use an access key and a secret key. Extra security measures (e.g. multi-factor authentication) can also be set up for each user.

Authentication vs. Authorization – This is an important distinction:

  • Authentication is the process of proving who you are
  • Authorization is the process of checking whether you have permission to do what you want to do

Permissions and Authorization

Every new user an administrator creates will need to be given certain permissions by the admin. These permissions will determine which actions or operations each user can carry out, and on which resources. You can use default ‘AWS managed’ permissions or you can customize your own granular ‘customer managed’ ones where you can give different users different permissions for different resources.

In either case, the permissions are stored on JSON documents as user policies. “Users” can include programs running on Amazon EC2 instances, so you as the admin can give them permission to access storage, databases and so on.

Resource-based permissions are the most popular way of controlling requests from cross-account roles.

When an entity makes a request, AIM uses the information provided to create a ‘request context.’ The information it uses includes the entity and any user policies; the target resources and any resource policies; the action or operation to be carried out; environmental data (IP address, SSL-enabled status, time of day, etc.) and resource data (database names, tags, etc.).

Important note: IAM’s Policy Evaluation Logic denies all requests by default, so successful actions/operations have to be explicitly allowed by the admin within the user and resource policies.

If a policy denies a specific action or access to a resource, this is termed an ‘explicit deny’ and the whole request is then denied. If none of the policies allow a specific action or access to a resource, this is termed an ‘implicit deny’ and the whole request is once again denied.


2. Actions and Operations

So, what types of actions and operations can be used on a resource? Let’s find out.

Taking a user resource for example, there are around 40 different actions/operations possible on that user including retrieving information (GetUser); creating (CreateUser), changing (UpdateUser) and deleting (DeleteUser).

As explained in the previous section, each intended action or operation needs to be explicitly allowed by the admin within the relevant user or resource policy, otherwise the request will be denied by default.

Each policy needs to define the resource that can be accessed, the level of access allowed (a ‘wildcard’ asterisk symbol is used to give full access) and any request conditions that may apply.

Existing user or resource policy summaries and the JSON documents themselves can be viewed via the AWS Management Console on the user page. The information is nested, with the resources grouped into an action summary, the actions grouped in a service summary and the services grouped in the policy summary.

There is also a policies page which provides an overview of all existing policies within the account. Other types of policies that IAM uses are permission boundaries, organizations SCPs, ACLs and session policies.

Once you’ve familiarized yourself with the different policies, you will be able to troubleshoot any problems you may encounter with permissions.

3. Federating Users into AWS

IAM also manages so-called federated identities. These are users or programs which have already been authenticated either by the account holder’s corporate network or, for web-accessed services, via an internet-based authentication system.

Federated identities first authenticate with the corporate network (using SAML 2.0 or a broker app) or with an internet service. This then sends a request for single sign-on access (SSO) with AWS.

An example of a corporate system which uses federated identities is Microsoft Active Directory. When a user logs into Active Directory, temporary access to AWS can be granted using AWS Directory Services.

Another example uses OpenID Connect (OIDC), enabling online service users to log on using their Google, Facebook or Amazon accounts. AWS recommends Amazon Cognito for managing online IAM.

Worried about Security? You Should Be. Shamrock can Help.

While there is certainly some work to be done in order to organize permissions and ensure your AWS services are secure, the key concepts outlined above should offer a solid jumping off point.

To stay in line with best practices (and to reduce your overall workload), we strongly recommend that you organize your users into groups and set permissions at group level. We also recommend only giving users the absolute minimum access they need to do their job. You can always offer additional access if need be.

The most important thing to understand with regards to managing IAM within AWS is that you’re not alone. Shamrock Consulting Group is a proud member of the Amazon Partner Network and we have an entire team of AWS certified cloud practitioners dedicated to helping customers with everything related to AWS, including a special focus on security.

Ready to get set up with IAM? Shamrock will walk you through the entire process to ensure you migrate to AWS in a secure, controlled manner with all entities and roles set up correctly. Get your free consultation today and hit the ground running with AWS!

Ben Ferguson

Ben Ferguson

Ben Ferguson is the Vice President and Senior Network Architect for Shamrock Consulting Group, an industry leader in digital transformation solutions. Since his departure from Biochemical research in 2004, Ben has built core competencies around cloud direct connects and cloud cost reduction, enterprise wide area network architecture, high density data center deployments, cybersecurity and Voice over IP telephony. Ben has designed hundreds of complex networks for some of the largest companies in the world and he’s helped Shamrock become a top partner of the 3 largest public cloud platforms for AWS, Azure and GCP consulting. When he takes the occasional break from designing networks, he enjoys surfing, golf, working out, trying new restaurants and spending time with his wife, Linsey, his son, Weston and his dog, Hamilton.

Learn About Our Best Price Guarantee