Properly setting permissions on IAM users, groups and roles greatly enhances your security posture. Below are some points to consider to improve security with IAM.

  • While creating policies, start with granting least priveleges. Use policy conditions to further restrict access. Following snippet shows a policy to allow deletion of RDS, only with MFA and from company IP address. This policy may be attached to select group of users. All other users may have explicit ‘deny’ policy attached.
An explicit 'deny' policy, attached to all users/groups:

{
"Statement": [
{
"Effect": "Deny",
"Action": [
"rds:DeleteDBClusterSnapshot",
"rds:DeleteDBSnapshot",
"rds:DeleteDBCluster",
"rds:DeleteDBInstance"
],
"Resource": "*"
}
]}
---------------------------------------------------------
Policy to allow deletion, attached to select users/groups:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds:DeleteDBClusterSnapshot",
"rds:DeleteDBSnapshot",
"rds:DeleteDBCluster",
"rds:DeleteDBInstance"
],
"Resource": "*",
"Condition": {
"BoolIfExists": {
"aws:MultiFactorAuthPresent": "true"
},
"IpAddress": {
"aws:SourceIp": [
"<COMPANY_IP>"
] }
}
}
]}
  • Use IAM Access Analyzer to check access activity. Take action based on the Analyzer findings, such as deleting or modify based on activity reported in the Analyzer.
  • Use ‘Access advisor’ tab of the IAM user/group/role to know about ‘last accessed information’ of an attached policy. Delete the one which are not used.
  • Using permission boundaries set maximum permissions an entity (user or role) should have. As roles can be from external accounts as well, it is even more important to set permission boundaries on roles.
  • Double check any values for the Action or Resource element that include *. Where possible, grant Allow access to the individual actions and resources that users need.
  • If you have more than one AWS account, use AWS Organizations along with service control policies (SCP) to efficiently manage policies across accounts. SCP are enforced on IAM users and roles of AWS accounts within the Organization only. Also, they don’t affect permissions granted to other AWS accounts (not part of the Organization) as well.

Best practices

  • Don’t use root user to create various AWS services and resources. Create an IAM user for this purpose. Don’t create access-key for root user.
  • Enforce to rotate users console password every 3 months.
  • Use MFA for root and all IAM users.
  • AWS console password be complex with minimum length 10
  • Enable CloudTrail to log API calls.