Security best practices in IAM.. Summarized. 
Tags: aws, cloudskills, security
Published: 2021-07-20 18:22:26

**Lock away your AWSaccount root user access keys**
Do not use your AWSaccount root user access key to make programmatic requests to Amazon Web Services (AWS). The access key for your AWS account root user gives full access to all your resources for all services, including your billing information. You cannot reduce the permissions associated with this key and must protect it like you would your credit card numbers or other sensitive secret.
1. If you don't already have an access key for your AWS account root user, don't create one. Instead, use your account email address and password to sign in to the AWSManagement Console and create an IAM user for yourself that has administrative permissions. If you do need to create a new account, you can do so by signing into your existing account.
2. If you do have an access key for your AWS account root user, delete it. If you must keep it, rotate (change) the access key regularly. To delete or rotate your root user access keys, go to the My Security Credentials page in the AWSManagement Console.
3. Never share your AWSaccount root user password or access keys with anyone. The remaining sections of this document discuss various ways to avoid having to share your account's root user credentials with other users. They also explain how to avoid embedding them in an application.
4. Use a strong password to help protect account-level access to the AWSManagement Console. For information about managing your AWSaccount root user password, see Changing the AWS account root user password.
5. Enable AWS multi-factor authentication (MFA) on your AWSaccount root user account. For more information, see Using multi-factor authentication (MFA) in AWS.

**Create individual IAM users**
       Don't give your AWS account  credentials to anyone else. 
  Instead, create individual users for anyone who needs access to 
  your account. Create an IAM user for yourself as well, give that 
  user administrative permissions and use it for all your work. 
     You can create individual IAM users for people who access 
  your account. Each IAM user has a unique set of security 
  credentials, and you can grant different permissions to them. If 
  necessary, you can change or revoke an I AM user's permissions 
  anytime. It is possible to revoke the root user's password if 
  you don't want to give it to someone else. AWS recommends that 
  you create new users without permissions and require them to 
  change their password immediately. After they sign in for the 
  first time, you can add policies to the user.

**Use user groups to assign permissions to IAM users**
   You can create user groups that relate to job functions 
   (administrators, developers, accounting, etc.) Next, define the 
   relevant permissions for each user group. All the users in an 
   IAM zser group inherit the permissions of the user group they 
   belong to. That way, you can make changes for everyone in a 
   user group in just one place.
**Grant least privilege**
    When you create IAM policies, follow the standard security 
    advice of granting least privilege, or granting only the 
    permissions required to perform a task. This is more secure 
    than starting with too many permissions and then trying to 
    tighten them later. It's important to start with a minimum set 
    of permissions and grant additional permissions as necessary.
  **A.Understand access level groupings**
   You can use access level groupings to understand the level of 
   access that a policy grants. Policy actions are classified as 
   List, Read, Write, Permissions management, or Tagging. For 
   example, you can choose actions from the List and Read access 
   levels to grant read-only access to your users.
  **B.Validate your policies**
   IAM Access Analyzer provides over 100 policy checks to validate 
   your policies. It generates security warnings when a statement 
   in your policy allows access we consider overly permissive. You 
   can use the actionable recommendations that are provided 
   through the security warnings as you work toward granting least 
   privilege.
 **C.Generate a policy based on access activity**
  You can create a policy based on the access activity for an IAM 
  entity. IAM Access Analyzer reviews your CloudTrail logs and 
  generates a policy template that contains the permissions that 
  have been used by the entity in your specified time frame. You 
  can use the template to create a managed policy with fine- 
  grained permissions.
 **D.Use last accessed information**
   Last accessed information includes information about the 
  actions that were last accessed for some services, such as 
  Amazon EC2,IAM, Lambda, and Amazon S3. View this information on 
  the Access Advisor tab on the IAM console details page for an 
  IAM user, group, role, or policy. You can use this information 
  to identify unnecessary permissions so that you can refine your 
  IAM or Organizations policies to better adhere to the principle 
 of least privilege.
**E.Review account events in AWS CloudTrail**
   To further reduce permissions, you can view your account's 
   events in AWS CloudTrail Event history. CloudTrail event logs 
   include detailed event information that you can use to reduce 
   the policy's permissions. The logs include only the actions and 
   resources that your IAM entities need.

**Get started using permissions with AWS managed policies**
  AWS managed policies can give your employees the permissions 
  they need to get started. These policies are already available 
  in your account and are maintained and updated by AWS. To get 
  started quickly, you can use AWS managed policies to give your 
  employee access to the services they want or need.AWS managed 
  policies are designed to provide permissions for many common use 
  cases. Full access AWS managed policies define permissions for 
  service administrators by granting full access to a service. 
  Power-user policies such as AWSCodeCommitPowerUser and 
  AWSKeyManagementServicePowerUser provide multiple levels of 
  access to services without allowing permissions management 
  permissions. Partial-access policies like 
  AmazonMobileAnalyticsWriteOnlyAccess and AmazonEC2ReadOnlyAccess 
  provide specific levels of permission for users, user groups, 
  and roles.
**Validate your policies**
  It is a best practice to validate the policies that you create. 
  You can perform policy validation when you create and edit JSON 
  policies. IAM identifies any JSON syntax errors, while IAM 
  Access Analyzer provides over 100 policy checks and actionable 
  recommendations to help you author secure and functional 
  policies. We recommend that you review and validate all of your 
  existing policies
**Use customer managed policies instead of inline policies**
  For custom policies, we recommend that you use managed policies 
  instead of inline policies. A key advantage of using these 
  policies is that you can view all of your managed policies in 
  one place in the console. You can also view this information 
  with a single AWS CLI or AWS API operation. Inline policies are 
  policies that exist only on an IAM identity (user, user group, 
  or role). Managed policies are separate IAM resources that you 
  can attach to multiple identities.
 **Use access levels to review IAM permissions**
  AWS categorizes each service action into one of five access 
  levels based on what each action does: List, Read, Write, 
  Permissions management, or Tagging. You can use these access 
  levels to determine which actions to include in your policies. 
  Make sure that your policies grant the least privilege that is 
  needed to perform only the necessary actions.
**Configure a strong password policy for your users**
  If you allow users to change their own passwords, create a 
  custom password policy that requires them to create strong 
  passwords and rotate their passwords periodically. You can 
  upgrade from the default password policy to define password 
  requirements, such as minimum length, minimum length and 
  whether it requires nonalphabetic characters. For more 
  information, see Setting an account password policy for IAM 
  users.
 **Enable MFA**
  For extra security, we recommend that you require multi-factor 
  authentication (MFA) for all users in your account. With MFA, 
  users have a device that generates a response to an 
  authentication challenge. Both the user's credentials and the 
  device-generated response are required to complete the sign-in 
  process. If a user's password or access keys are compromised, 
  your account resources are still secure because of the 
  additional authentication requirement.
      The response is generated in one of the following ways:
 1.Virtual and hardware MFA devices generate a code that you view 
   on the app or device and then enter on the sign-in screen.
 2.U2F security keys generate a response when you tap the device. 
   The user does not manually enter a code on the sign-in screen.

**Use roles for applications that run on Amazon EC2 instances**
  Amazon EC2 is a cloud computing platform that allows you to run 
  applications on an Amazon EC2 instance. When you launch an EC2 
  server, you can specify a role for the instance as a launch 
  parameter. Roles provide temporary credentials to the EC2 
  instances and these credentials are automatically rotated for 
  you. The role's permissions determine what the application is 
  allowed to do.
**Use roles to delegate permissions**
  Don't share security credentials between accounts to allow users 
  from another AWS account to access resources in your AWS 
  account. Instead, use IAM roles. You can define a role that 
  specifies what permissions the IAM users in the other account 
  are allowed. You can also designate which AWS accounts have the 
  IAM users that are allowed to assume the role.


**Do not share access keys**
  Do not embed access keys within unencrypted code or share these 
  security credentials between users in your AWS account. For 
  applications that need access to AWS, configure the program to 
  retrieve temporary security credentials using an IAM role. To 
  allow your users individual programmatic access, create a user 
  with personal access keys.
**Rotate credentials regularly**
  If a password or access key is compromised without your 
  knowledge, you limit how long the credentials can be used to 
  access your resources. Change your own passwords and access keys 
  regularly, and make sure that all IAM users in your account do 
  as well. You can apply a custom password policy to your account 
  to require all your IAM user to rotate their IAM passwords.
**Remove unnecessary credentials**
  You can find unused passwords or access keys using the console, 
  using the CLI or API, or by downloading the credentials report. 
  Passwords and access keys that have not been used recently might 
  be good candidates for removal. If you created an IAM user for 
  an application that does not use the console then the IAM 
  doesn't need a password.
**Use policy conditions for extra security**
  You can define the conditions under which your IAM policies 
  allow access to a resource. For example, you can write 
  conditions to specify a range of allowable IP addresses that a 
  request must come from. You can also set conditions that require 
  the use of SSL or MFA (multi-factor authentication).
**Monitor activity in your AWS account**
  Logging features are available in the following AWS services:
  1. Amazon CloudFront.
  2. AWS CloudTrail.
  3. Amazon CloudWatch.
  4. AWS Config.
  5. Amazon Simple Storage Service