AWS IAM BEST PRACTICES FOR SECURITY AND COMPLIANCE | Cloudelligent

What is IAM?

AWS Identity and Access Management (IAM) is a web service that helps you securely control access to AWS resources. You use IAM to control who is authenticated (signed in) and authorized (has permissions) to use resources.

Security of Services

Amazon security of it services and resources is paramount, security is at the forefront of services. It focuses on providing a fine tuned robust approach in access control for it AWS customers. AWS Identity and access managament (IAM)  enables you to manage services and resources securely, using IAM you can create and manage AWS users, groups and use permission to allow and deny access to AWS resources.

To help you make the most of AWS IAM feature we have put together 10 AWS IAM best practices every organisation should follow

1. Lock Away Your AWS Account Root User Access Keys

You use an access key (an access key ID and secret access key) to make programmatic requests to AWS. However, do not use your AWS account root user access key. The access key for your AWS account root user gives full access to all your resources for all AWS services, including your billing information. The root user is the only principal that can authenticate the account for a new user. You cannot reduce the permissions associated with your AWS account root user access key. Therefore, protect your root user access key like you would your credit card numbers or any other sensitive secret.

locks

2. Enable MFA and Rotate Access Keys

As a security best practice, we recommend that you regularly rotate (change) IAM user access keys. If your administrator granted you the necessary permissions, you can rotate your own access keys. 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.

Find out more about setting up MFA and Rotating Access Keys.

3. Do Not Share Access Keys

Access keys provide programmatic access to AWS. 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 an IAM user with personal access keys.

dont share

4. Use AWS managed policies to assign permissions

Amazon have provided pre-defined policies for many services, these are managed by Amazon and are not allowed to be edited. The policies are designed for the end-user to make it easier to grant access to resources within the cloud. A single AWS managed policy for job functions, you can grant the permissions necessary for network or database administrators, for example.

5. Monitor Activity in Your AWS Account

Monitoring services and activities in the cloud are a vital part of any organisation, to understand what is security risks, potential resource outages and many other vulnerabilities. Monitoring is paramount, AWS activity is constantly monitored with AWS Cloudtrail, and here at CLOUDELLIGENT we strongly recommend organisation monitor alongside AWS or other cloud services to understand a unified view of all cloud activities.

6. Remove Unnecessary Credentials

Auditing is always good practice, checking users have left, checking credentials that are not active anymore. You can generate and download a credential report that lists all users in your account and the status of their various credentials, including passwords, access keys and MFA devices. You can provide the report to an external auditor, or grant permissions to an auditor so that he or she can download the report directly.

7. Configure a Strong Password Policy for Your Users

Users tend to go for easy to remember password, this can be a potential security risks. Hackers can exploit these vulnerabilities. AWS has made securing password effortless by using, password expiration and password-generation-tools. Along with this you could keep password length long, and use special characters, uppercases, and also non-alphabet characters.

8. Grant Least Privilege

‘Less is better than more’ remember adding more salt to food would ruin it, better approach is to add less, you can always add more… this approach applies to best practices, when giving access to resources for your users. It can be faster to create IAM user without a granular approach or not measuring outcomes, but if credentials are compromised and users have access to many services this can cause significant loss for the organisation. One quick way of checking what services are being used with AWS is the Access Advisor, this can help Identify unused IAM roles and remove them confidently with the last used timestamp.

9. Use Managed Policies Instead of Inline Policies

Key advantage of not using an inline policy is transparency and reusability, you can view all your managed policies in one place. You can view them on console, and a single AWS CLI or AWS API operation. Inline are attached only IAM identity, user, group, or role. You can convert an inline policy to a managed policy from the console.

10. Use Roles for Applications That Run on Amazon EC2 Instances

Applications that run on an Amazon EC2 instance need credentials in order to access other AWS services. To provide credentials to the application in a secure way, use IAM roles. A role is an entity that has its own set of permissions, but that isn’t a user or group. Roles also don’t have their own permanent set of credentials the way IAM users do. In the case of Amazon EC2, IAM dynamically provides temporary credentials to the EC2 instance, and these credentials are automatically rotated for you.

When you launch an EC2 instance, you can specify a role for the instance as a launch parameter. Applications that run on the EC2 instance can use the role’s credentials when they access AWS resources. The role’s permissions determine what the application is allowed to do