This is a series of notes that I'm preparing in order to take the Solutions Architect Associate Exam.

In this specific article, I am going to write about IAM (The Identity & Access Management) section is the starting point in AWS.

Glossary

Identity: Represents a user or a role, also known as "Principal"

Role: Identities that can be temporarily applied to an app, service, user or group.

Policies: They define how the identities can interact with the resources in your AWS account.

Identity-Based Policies: They are applied to a "principal".

Resource-based policies: They are applied to a resource.

Federated Identities:

The identities can be federated, this means that they can be integrated with 3rd party services like Microsoft Active Directory, LDAP. Users without AWS account credentials can log in to the AWS console with a temporary access granted by this integration.

Root Identity:

This is the default identity that comes with every AWS Account, it has full rights overall services and resources.

This is a very good reason to protect it since if it gets compromised, your entire account is at risk.

Be careful about using this account to do regular administration tasks. Here is a list of steps that you should follow to protect your root account using the Identity and Access Management (IAM) tools that AWS provides.

Steps to secure your root account:

AWS Suggest that you have to heavily protect your Root Credentials, and provides a handful checklist to protect it.

To access it you should log into your console, and select IAM under Security, Identity & Compliance section

1. Activate MFA on your root account: Doing this enforces you to add a second device to validate your identity.
   After you enter your credentials when you log into your console, the system will require either a 6 digit code that has to be generated using any supported authenticator app, or that you plug in a MFA Device into your computer.
   List of supported MFA Devices here: https://aws.amazon.com/iam/features/mfa/
2. Create Individual IAM users: One of the principles that is mentioned in the Security Pillar of the Well Architected Framework written by AWS is the "Principle of least privilege": You should give IAM principals permissions to only the resources they need and no more.
   Summary: You shouldn't do all from your root account, create users with specific privileges, and ALSO create a user with Admin privileges for you.
3. Use Groups to Assign Permissions: This is a handful option when you have many users and need to set up levels of access.
   For example you can create a group for web developers that have access granted to some specific resources, and when you need to add / remove a permssion, instead of doing it directly in the Principal you do it in the group and it gets automatically applied to all the principals that are in that group.
   

4. Apply an IAM password policy: This is super helpful in order to avoid potential risks on the accounts, you can enforce users to use difficult passwords, or to renew their password after X days, etc.

5. Rotate your Access Keys: Amazon suggests to change your access keys regularly (at least once per year) and delete unused access keys to reduce your risk in case of accidental exposure.

Policies: How do they work?

A policy is a document that contains actions related to one or more AWS resources and the effect permitted by the action on the resource.

AWS provides hundreds of preset policies.

Sample policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

Golden Rule for policies:

The most restrictive policy is the one who precedes in case of policy conflicts.
i.e. If I have a policy that allows a principal to start EC2 instances but at the same time I have another one that restricts a group for starting EC2 instances and that principal is inside that group, the policy that will be applied is the one that restricts.

Accepted values for policies:

- Version: AWS suggest to use the latest one: 2012-10-17
- Statement: This is where the main info of the policy goes, multiple statements are allowed per policy, AWS suggest to create multiple policies in case the complexity of the permissions requires it.
- Sid: This is the statement identifier, optional
- Effect : Allow or Deny
- Principal: (Required only under some circumstances), if you create a resource based policy, you must indicate the account, user, role or federated user which you'd like to allow or deny access.
- Action: The list of actions that the policy allows or denies
- Resource: (Required only under some circumstances), if an IAM permissions policy is created, a list of resources must be specified, if no resource is specified and you create a resource based policy, then the permission policy applies to the resource to which is attached.
- Conditions: Specify the circumstances where the policy grants permissions. (This is optional)

Here's a list of Example IAM policies:

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_examples.html