Identity Access Management

IAM Principle

• The main principle is least access , if access required give them that access by assigning a role , once work is completed remove that role after certain amount of time

Identity & Acess Management

1. This is a global Service

2. The main purpose of IAM is to manage the access and security of the configured root account and services used

Introduction to IAM

1. Generally, we first create a root user account.

2. We should enable MFA for a root account to for further security

3. The main purpose of IAM is to control access to users

4. Then inside we create multiple users and assign them to different groups.

5. After assigning them to different groups we assign them different policies.

6. If a user is a member of a particular group then all the policies assigned to a user will be applicable to that user

7. Users can be a part of more than one group

8. Policies are JSON documents that have the various authorization allocated to that particular account

9. Rules for making groups

   • We can only have users inside of groups.

   • We cannot have groups inside of users.

   • We can have different users belonging to different groups.

   • Group inheritance

     • If a user is part of the group 'A' and the group has been allocated some policies then the user will also inherit that policy

     • If a user is part of two groups 'A' and group 'B' and both have policies attached to them then user will inherit policies of both 'A' & 'B'

Policy Structure

{
    "Version": "2012-10-17", // indicates the version of the policy
    "id":// id of the policy which is optional
    "Statement": [
        {    "Statemenid":1,//optional represents the statement id 
            "Effect": "Allow", // this represents the permissions
            "Principal": // on which account the policy is applied to
            "Action": [
                "s3:GetObject", // list of actions on which policy denies or allows
                "s3:PutObject",
                "s3:ListBucket",
                "s3:DeleteObject"
            ],
            "Resource": [
                "arn:aws:s3:::my-bucket/*", // resource of the service               of which the permission is to be applied
                "arn:aws:s3:::my-bucket" 
            ]
        }
    ]
}

IAM Password Policy

AWS IAM password policies are used to enforce strong password requirements for user accounts in an AWS environment. Here are some of the password policy settings that can be configured:

• Minimum password length: This is the minimum number of characters required for a password.

• Require at least one uppercase letter: This setting requires that the password contain at least one uppercase letter.

• Require at least one lowercase letter: This setting requires that the password contain at least one lowercase letter.

• Require at least one number: This setting requires that the password contain at least one numeric digit.

• Require at least one non-alphanumeric character: This setting requires that the password contain at least one non-alphanumeric character (such as !, @, #, etc.).

• Password expiration: This setting specifies the number of days after which a password must be changed.

• Password reuse prevention: This setting specifies the number of previous passwords that cannot be reused.

• Account lockout: This setting specifies the number of failed login attempts after which an account will be locked.

To configure the IAM password policy, an administrator can log in to the AWS Management Console, navigate to the IAM service, and then click on "Account settings" in the left-hand menu. From there, they can set the desired password policy settings. It's generally recommended to enforce strong password policies to help ensure the security of AWS user accounts.

IAM MFA Policy

1. AWS IAM MFA (Multi-Factor Authentication) is a security feature that adds an extra layer of protection to user accounts by requiring users to provide two or more forms of authentication to access their AWS resources. MFA is a method of authentication that requires something the user knows (such as a password) and something the user has (such as a security token or a mobile device). This significantly reduces the risk of unauthorized access to AWS resources, even if a user's password is compromised.

2. To use MFA with IAM, an administrator can enable MFA for individual IAM users, and then require those users to provide an authentication code generated by a hardware or virtual MFA device in addition to their password when they log in to the AWS Management Console or access AWS resources using the AWS API or CLI. The MFA device can be a hardware device, such as a YubiKey or Google Authenticator, or a virtual device, such as the AWS Virtual MFA app.

3. To enable MFA for an IAM user, an administrator can log in to the AWS Management Console, navigate to the IAM service, select the user, and then click on the "Security credentials" tab. From there, they can enable MFA and associate the MFA device with the user's account. The next time the user logs in, they will be prompted to provide the authentication code generated by their MFA device in addition to their password.

How to access AWS

1. Using a website which is called the AWS Management Console

2. Using AWS CLI, for this we need to create access keys

3. AWS SDK, using multiple programming languages like JavaScript again we need Access to Keys

4. One more way is to use AWS CloudShell

Access Keys

1. AWS access keys are a set of credentials that allow access to AWS resources through the AWS API or command line tools. Access keys consist of an access key ID and a secret access key, and are used to authenticate AWS requests made by applications and services running on behalf of an AWS user.

2. To create an access key for an AWS user, an administrator can log in to the AWS Management Console, navigate to the IAM service, select the user, and then click on the "Security credentials" tab. From there, they can generate an access key, which will be displayed in the console along with the secret access key. The access key can then be used by applications or services to access AWS resources on behalf of the user.

3. It's important to protect access keys, as they provide full access to the AWS resources associated with the user's account. Access keys should be stored securely and not shared with others, and should be rotated periodically to help ensure the security of AWS resources. If an access key is compromised, it should be immediately revoked and a new access key generated.

IAM Roles

1. AWS IAM roles are a way to delegate permissions to AWS resources without the need to share long-term access keys. An IAM role is similar to an IAM user, in that it is an AWS identity with permissions to access AWS resources. However, instead of being associated with a specific user, a role is intended to be assumed by one or more entities, such as an EC2 instance, a Lambda function, or an external user authenticated with an identity provider.

2. When an entity assumes an IAM role, it receives temporary security credentials that it can use to access the AWS resources defined in the role's policy. This helps to ensure the security of the AWS resources, as the temporary credentials can be revoked automatically when the role is no longer needed, or when the permissions associated with the role are changed.

3. To create an IAM role, an administrator can log in to the AWS Management Console, navigate to the IAM service, and then click on "Roles" in the left-hand menu. From there, they can create a new role and define the role's policy, specifying which AWS resources the role is allowed to access. Once the role has been created, it can be assumed by the entity that needs access to the AWS resources.

4. The temporary credentials have a limited lifespan, typically ranging from a few minutes to a few hours. Once the duration expires, the temporary permissions are automatically revoked.

IAM Shared Security Model

1. The AWS IAM (Identity and Access Management) shared security model is a framework for understanding the shared responsibility for securing AWS resources between AWS and its customers. The model defines the security responsibilities of both AWS and its customers, and helps ensure that AWS resources are secured in a collaborative manner.

2. Under the IAM shared security model, AWS is responsible for the security of the underlying cloud infrastructure, including the physical security of the data centers, the network infrastructure, and the virtualization layer. AWS is also responsible for the security of some AWS-managed services, such as Amazon RDS, Amazon S3, and Amazon DynamoDB. AWS implements various security controls to ensure that its infrastructure is secure, and regularly audits its security controls to ensure compliance with security standards and best practices.

3. Customers are responsible for securing their own applications and data that are deployed on AWS. This includes securing the operating system and applications, configuring network security groups and access control lists (ACLs), and managing user access to AWS resources through IAM. Customers are also responsible for ensuring compliance with applicable regulatory and compliance requirements, and for monitoring and logging their AWS environments to detect security incidents.

4. Overall, the IAM shared security model emphasizes the importance of collaboration between AWS and its customers to ensure the security of AWS resources. Customers are encouraged to follow AWS security best practices and to use the security features provided by AWS, such as IAM roles, security groups, and encryption, to protect their applications and data.