AWS Identity and Access Management (IAM)

Identifier	Guardrail	Rationale	Remediation	References	IAM Actions	Policy
IAM-IAM-1	Check that the management of AWS IAM Users, secret access keys, and multi-factor authentication is for authorized principals only.	While AWS IAM Users are typically not recommended today, in favor of federated principals, IAM Users might be needed for break glass procedures or operational availability when an identity provider is unavailable and federation is not possible. However, in general these actions are sensitive should be scoped appropriately.	Secure by restricting to Security Operations only and authorized roles.	https://docs.aws.amazon.com/IAM/latest/APIReference/API_Operations.html	iam:AddUserToGroup iam:AttachGroupPolicy iam:CreateLoginProfile iam:CreateUser iam:CreateVirtualMFADeviceiam iam:DeleteAccessKey iam:DeleteGroup iam:DeleteGroupPolicy iam:DeleteLoginProfile iam:DeleteUser iam:DeleteUserPolicy iam:DeleteVirtualMFADevice iam:DetachGroupPolicy iam:DetachUserPolicy iam:EnableMFADevice iam:PutGroupPolicy iam:PutUserPolicy iam:RemoveUserFromGroup iam:ResyncMFADevice iam:UpdateAccessKey iam:UpdateGroup iam:UpdateLoginProfile iam:UpdateUser	nan
IAM-IAM-10	Check iam:PassRole permission is appropriately scoped for approved roles for passing and scope the trust policy for the intended target AWS Services.	PassRole provides ability for user to handoff and associate a role to a particular service. This can be potentially harmful, such as in a scenario where the user passes a privileged role to EC2 instances he/she has access to Passrole should be appropriately scoped with the Resources element of the IAM Policy statement for passing only approved roles. Specify the trust policy for the targeted AWS Service.	Update Resources element of the iam:PassRole to specify the approved roles to be passed and scope appropriately to the specific AWS Services. Update the trust policy to scope the target AWS Service for the service role.	https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html		IAM
IAM-IAM-11	Check that the management of AWS IAM Users, AWS IAM Roles, AWS IAM Groups, secret access keys, and multi-factor authentication is for authorized principals only.	It is important that access control to the management of your AWS principals and AWS permissions is only performed by your authorized principals. Protect against unauthorized identity by limiting access to only your administrative principals.	Verify that IAM administrative and modification permissions are explicitly denied to non-whitelisted principals and that the IAM modification permissions don’t exist in an Allow statement for any unauthorized principals.	https://docs.aws.amazon.com/IAM/latest/APIReference/API_Operations.html	iam:AddClientIDToOpenIDConnectProvider iam:AddRoleToInstanceProfile iam:AddUserToGroup iam:AttachGroupPolicy iam:AttachRolePolicy iam:AttachUserPolicy iam:ChangePassword iam:CreateAccessKey iam:CreateAccountAlias iam:CreateGroup iam:CreateInstanceProfile iam:CreateLoginProfile iam:CreateOpenIDConnectProvider iam:CreatePolicy iam:CreatePolicyVersion iam:CreateRole iam:CreateSAMLProvider iam:CreateServiceLinkedRole iam:CreateServiceSpecificCredential iam:CreateUser iam:CreateVirtualMFADevice iam:DeactivateMFADevice iam:DeleteAccessKey iam:DeleteAccountAlias iam:DeleteAccountPasswordPolicy iam:DeleteGroup iam:DeleteGroupPolicy iam:DeleteInstanceProfile iam:DeleteLoginProfile iam:DeleteOpenIDConnectProvider iam:DeletePolicy iam:DeletePolicyVersion iam:DeleteRole iam:DeleteRolePermissionsBoundary iam:DeleteRolePolicy iam:DeleteSAMLProvider iam:DeleteServerCertificate iam:DeleteServiceLinkedRole iam:DeleteServiceSpecificCredential iam:DeleteSigningCertificate iam:DeleteSSHPublicKey iam:DeleteUser iam:DeleteUserPermissionsBoundary iam:DeleteUserPolicy iam:DeleteVirtualMFADevice iam:DetachGroupPolicy iam:DetachRolePolicy iam:DetachUserPolicy iam:EnableMFADevice iam:PutGroupPolicy iam:PutRolePermissionsBoundary iam:PutRolePolicy iam:PutUserPermissionsBoundary iam:PutUserPolicy iam:RemoveClientIDFromOpenIDConnectProvider iam:RemoveRoleFromInstanceProfile iam:RemoveUserFromGroup iam:ResetServiceSpecificCredential iam:ResyncMFADevice iam:SetDefaultPolicyVersion iam:SetSecurityTokenServicePreferences iam:TagRole iam:TagUser iam:UntagRole iam:UntagUser iam:UpdateAccessKey iam:UpdateAccountPasswordPolicy iam:UpdateAssumeRolePolicy iam:UpdateGroup iam:UpdateLoginProfile iam:UpdateOpenIDConnectProviderThumbprint iam:UpdateRole iam:UpdateRoleDescription iam:UpdateSAMLProvider iam:UpdateServerCertificate iam:UpdateServiceSpecificCredential iam:UpdateSigningCertificate iam:UpdateSSHPublicKey iam:UpdateUser iam:UploadServerCertificate iam:UploadSigningCertificate iam:UploadSSHPublicKey	nan
IAM-IAM-2	Check that the management of IAM Roles and Policies for authorized principals only, ideally build automation roles only.	The creation, update, and deletion of roles and policies and SAML provides needs to occur on approved changes to the IAM environment. However, these changes should be gated and restricted to authorized roles only, such as build automation, to prevent against any unintended principal granting themselves unauthorized permissions. The following permissions should be scoped appropriately.	Secure to only allow build automation.	https://docs.aws.amazon.com/IAM/latest/APIReference/API_Operations.html	iam:AttachRolePolicy iam:AttachUserPolicy iam:CreateAccountAlias iam:UpdateAssumeRolePolicy iam:CreateSAMLProvider iam:CreateServiceLinkedRole iam:DeleteAccountAlias iam:DeleteAccountPasswordPolicy iam:DeletePolicy iam:DeletePolicyVersion iam:DeleteRole iam:DeleteRolePermissionsBoundary iam:DeleteRolePolicy iam:DeleteSAMLProvider iam:DeleteServiceLinkedRole iam:DeleteUserPermissionsBoundary iam:DetachRolePolicy iam:PutRolePermissionsBoundary iam:PutRolePolicy iam:PutUserPermissionsBoundary iam:UpdateAccountPasswordPolicy iam:UpdateAssumeRolePolicy iam:UpdateRole iam:UpdateRoleDescription iam:UpdateSAMLProvider	nan
IAM-IAM-3	Be careful when placing IAM IP restrictions to restrict API access to specific IP addresses, such as customer’s on-premise network range.	There are many AWS Services where the IP address of the originating user is not passed when the AWS service makes call on the user’s behalf, such as AWS CloudFormation.	Alternatively, consider attaching the condition ’aws:SourceIp’to assumeRole* such as AssumeRoleWithSAML orAssumeRole.	https://aws.amazon.com/premiumsupport/knowledge-center/iam-restrict-calls-ip-addresses/		nan
IAM-IAM-4	IAM Policy Documents utilized as a Permissions Boundary are protected from modification from unauthorized entities	When utilizing a delegated admin model of IAM to allow developers to create their own roles - a permissions boundary is utilized to prevent privilege escalation. It is important to ensure that the Delegated Admins do not have access to modify the Policy Document used as their Permissions Boundary - this creates a risk of privilege escalation.	Prevent the following IAM Actions: “iam:CreatePolicyVersion”, “iam:DeletePolicy”, “iam:DeletePolicyVersion”, “iam:SetDefaultPolicyVersion” on the ARN of the policy document that is utilized as the permissions boundary. This can be achieved as an outright deny at the SCP, or at the Permissions Boundary level. Utilizing IAM Paths (eg - a seperate path for Delegated Admins vs Protected IAM entities) to achieve the same outcome - as long as developers cannot edit their own Permissions Boundary, or alter the current policy version.	https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html#access_policies_boundaries-delegate	iam:CreatePolicyVersion iam:DeletePolicy iam:DeletePolicyVersion iam:SetDefaultPolicyVersion	nan
IAM-IAM-5	Require roles created by Delegated IAM Admins (e.g. developers) to have appropriate Permissions Boundary attached.	Allowing delegated IAM admins to create roles with permissions boundaries attached provides teams the flexibility to create roles with restrictions but without waiting for an IAM admin to do it for them. In lower environments when developer roles are created, they usually have more privileges to play with services. In order to contain the potential privilege escalation, the role must have a permission boundary.	Attach permission boundary with the developer roles (dependent on naming conventions of the developer role)			IAM
IAM-IAM-6	Check iam:PassRole permission is appropriately scoped for approved roles for passing and scope the trust policy for the intended target AWS Services.	PassRole provides ability for user to handoff and associate a role to a particular service. This can be potentially harmful, such as in a scenario where the user passes a privileged role to EC2 instances he/she has access to Passrole should be appropriately scoped with the Resources element of the IAM Policy statement for passing only approved roles. Specify the trust policy for the targeted AWS Service.	Update Resources element of the iam:PassRole to specify the approved roles to be passed and scope appropriately to the specific AWS Services. Update the trust policy to scope the target AWS Service for the service role.	https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html		IAM
IAM-IAM-7	iam:GetAccountAuthorizationDetails is limited to only whitelisted roles	Since this action provides all information (IAM principals and their relationship with each other) about your IAM constrcuts in an account it can be used for recon for unintended actions	Removal of the action from the policy	https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetAccountAuthorizationDetails.html	iam:GetAccountAuthorizationDetails	nan
IAM-IAM-8	iam:CreateUser is not allowed in roles/users who do not have business justification to have it	In enterprise environment, the need for having permissions to create IAM users is negligible. The only use case would be for power user who creates on-demand users in case of an incident or emergency. Thus, general use roles should not be having this permission.	Removal of the action from the role unless it is whitelisted		iam:CreateUser	nan
IAM-IAM-9	Adding Managed Policy for denying high risk APIs	From the attacker perspective, walking through the first three steps of an attack (Reconnaissance, Scanning, and Access & Escalation), an attacker could leverage specific API calls in order to do damage to an AWS account. These particular APIs are what are commonly used in known attacks.	Add a policy that specifically denies the APIs contained within the Reference section, and adding the policy to IAM Users and Roles that are used as service users/roles.		s3:ListBucket s3:ListAllMyBuckets lambda:ListFunctions kms:ListKeys kms:ListAliases cloudtrail:DescribeTrails cloudtrail:ListTrails iam:Generate iam:Get iam:List* organizations:DescribeAccount organizations:DescribeOrganization organizations:DescribeOrganizationalUnit organizations:ListAccounts organizations:ListAWSServiceAccessForOrganization organizations:DescribePolicy organizations:ListChildren organizations:ListParents organizations:ListPoliciesForTarget organizations:ListRoots organizations:ListPolicies organizations:ListTargetsForPolicy ec2:TerminateInstances ec2:ModifyInstanceMetadataOptions	nan