Which of the following are AWS recommended best practices in relation to IAM select two?

Amazon takes the security of its services and resources very seriously. One of the areas that Amazon has focused on is providing a robust access control service to its Amazon Web Services (AWS) customers. AWS’s identity and access management (IAM) service allows customers to manage users, groups, roles, and permissions. But it’s entirely up to AWS customers to properly configure IAM to meet their security and compliance requirements. To help you make the most of Amazon’s built-in controls, we’ve compiled the top 13 AWS IAM best practices every organization should follow.

1) Restrict use of the AWS root account

When you register an account with AWS, the initial user account created is known as the root account. This account has complete access to every AWS resource (including billing information), making it the most privileged user account. Since root account credential permissions can’t be restricted, it is recommended that access to the root account be restricted to tasks that can only be completed using the root account (like creating the first admin account). For all other tasks, create an IAM user that has administrative privileges, and use that account to manage your AWS environment on a day-to-day basis.

2) Rotate root account access keys and enable multifactor authentication (MFA)

Regardless of how seldom the AWS root account is used, it is highly recommended that the account access keys are rotated on a regular basis using the security credentials page, and MFA is enabled to use the root account.

3) Never share AWS account credentials

Instead of sharing AWS accounts, create individual IAM users for employees that need to access AWS resources. This will allow you to assign a unique set of permissions to different users based on their job requirements.

4) If possible, use AWS managed policies to assign permissions

Amazon provides a pre-defined set of policies that are completely managed by AWS and customers aren’t allowed to edit the permissions. These policies are designed to serve common use cases while making it easier to enforce access policies than creating policies yourself from scratch.

5) Assign permissions at IAM group/role level rather than individual IAM user level

AWS allows policies to be defined at the IAM user/group/role level when a new user/group/role is created (known as inline policies). AWS customers can also apply customer-managed policies (which could be derived from cloning AWS managed policies) to a set of IAM users, groups, or roles. As a best practice, avoid assigning customer-managed policies to individual IAM users or defining inline policies when creating an IAM user. Instead, assign policies to a group of IAM users or write inline policies when creating an IAM group. This streamlines the process of making changes to multiple user permissions and decreases the risk of accidentally giving individual users an unnecessarily high set of permissions.

6) Never grant privileges beyond the minimum required for a user or group to fulfill their job requirements

One of the more common mistakes made when provisioning AWS users is granting them privileges that go beyond what’s minimally required. While it may be faster to create IAM users without scrutinizing the assigned privileges, unfettered access to AWS significantly increases the potential damage in the event of lost or stolen user credentials.

Verizon’s Data Breach Investigations Report 2017 further underscores the threat from compromised accounts. The report finds that an alarming 81% of data breaches were caused by stolen or insecure passwords in 2016. It’s therefore important for IT security to ensure that AWS administrators perform adequate research in order to define the right set of permissions.

Tip: if you’re not sure whether users/groups/roles have minimal required privileges, use the Access Advisor tab (found in the IAM console details page) to analyze a user/group/role, which will tell you which services are actually being used by them. This can help determine which services should be blocked.

7) Set a regular cadence to review IAM permissions

As a security best practice, it’s important to regularly review your organization’s AWS IAM policies to ensure they’re granting least privileges. Each policy comes with a policy summary, which is a good place to start when auditing IAM policies. AWS provides four levels of access for each of its services: list, read, write, and permissions management.

The write and permissions management access levels should be granted with caution. Write permits users to create, delete, or modify resources. Permissions management allows a user to grant or restrict resource permissions for entire organization and its AWS users. For this reason, permissions management should be granted to as few IAM users as possible.

8) Enforce a strong password policy for all AWS users

When left to their own devices, most users will select an easy to guess password despite its security risks. According to McAfee (formerly Skyhigh Networks), the top 20 most common passwords account for 10% of all passwords, with gems like “123456” and “password” accounting for over 5% of all passwords. This means that a hacker can infiltrate one out of twenty user accounts without any brute-force attacks if he just uses the two aforementioned passwords. It’s possible, however, to create highly secure and easy to remember passwords and taking the following steps can help ensure IAM credentials are protected:

1. Define a minimum password length of at least 14 characters
2. Require non-alphabet characters, at least one uppercase alphabet, and a symbol
3. Set up a password expiration policy and disallow password reuse
4. Discourage privileged users from using dictionary words in their passwords

9) Enable multi-factor authentication (MFA) for all IAM users

Organizations should assume that at least some of their cloud service user credentials have already been compromised. Since employees have a tendency to re-use passwords across services, enabling MFA should be a requirement not just for AWS but any cloud service that is being used at an organization.

Configuring AWS with a single sign-on provider such as Okta, Ping Identity, or Azure Active Directory can ease the friction introduced by enabling MFA by standardizing authentication factors across all applications employees use.

10) Use IAM roles for custom applications running on AWS EC2

Any app that requires access to another AWS service in order to function will need its own credentials. As a security best practice, use IAM roles to provide credentials to the application. Roles can have their own set of permissions without any users/groups needing to be attached to them.

When a user first launches an EC2 instance, they can determine the role for that instance, and any application that is deployed on that EC2 instance can then use the role’s credentials to access other AWS resources. The credentials will be dynamic and AWS will rotate them automatically for additional security.

11) Remove unused, stale, or unnecessary IAM users/credentials

To minimize the risk of IAM user credentials being stolen, all unnecessary IAM users should have their access terminated. Employees who no longer work at an organizations or those who have moved on to a different department that don’t need AWS access should not have access to AWS. Organizations should audit their IAM user activity to see which users haven’t logged into AWS for at least 90 days, and revoke their permissions as well.

12) Organizations working with highly sensitive or regulated information (e.g. healthcare, finance, federal government) should use policy conditions as an added security measure

Policy conditions are boolean operators that determine whether a match exists between a policy and a request. There are a near limitless number of conditions that can be used for IAM policies. Policy conditions are especially useful when working with partners and third-party vendors who need access to your organization’s AWS resources. Below are some of the recommended conditions that should be employed:

1. Use date/time conditions to limit access to resources such that IAM users are only able to access a resource during weekdays for the duration of their workday/shift.
2. Set up conditions that whitelists IP addresses that are allowed to access AWS resources to ensure only trusted IP addresses are able to gain access to an AWS resource.
3. For contract employees/partners, set up date conditions that block access to AWS resources after the termination date of the contract.

Only use policy conditions that meet your organization’s security and compliance requirements without hindering employee productivity.

13) Monitor user activity in all cloud services (including IAM user activity) to identify anomalous activity indicative of threats arising from a compromised account, or malicious/negligent internal employee

Amazon supports AWS activity monitoring with AWS CloudTrail. However, organizations should monitor AWS activity alongside all other cloud services to attain a unified view of all cloud activity. This will help to accurately separate a true threat from a false positive alert and also provide insight into cross-cloud threats that would go undetected by only looking at each cloud service in isolation.

A cloud access security broker (CASB) provides cross-cloud visibility into user activity to support comprehensive activity monitoring and threat protection.

Which of the following are AWS recommended best practices in relation to IAM choose two?

Which of the following are recommended best practices in relation to IAM?

Which of the following are AWS IAM best practices?

What does AWS recommend as best security practices for IAM?