Amazon Security Token Service (STS)

Identifier	Guardrail	Rationale	Remediation	References	Policy	IAM Actions
IAM-STS-1	Check that the sts external ID is specified in the trust policy when allowing cross-account Assume Role for third parties.	The external ID allows the user that is assuming the role to assert the circumstances in which they are operating. It also provides a way for the account owner to permit the role to be assumed only under specific circumstances. The primary function of the external ID is to address and prevent the “confused deputy” problem. The external ID addresses the confused deputy problem by preventing any other customer from tricking the third party into unwittingly accessing your resources.	Add the condition sts:ExternalId.	https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-sourcearn https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-using-identity-based-policies.html	Trust Policy
IAM-STS-2	Check that usage of Principal “*” is not allowed without the usage of proper condition keys	A principal setting of “*” allows any authenticated AWS Identity to assume that role, provided they know the ARN. Broadly assumable roles should be considered an anti-pattern in most cases. If a use case arises that it is unavoidable (when you need to provide external access to multiple identities to resources that don’t support resource policies), the Assume Role Policy should be properly scoped with conditions to limit access	Add the condition aws:PrincipalOrgId, or aws:PrincipalArn with an account number, or aws:SourceAccount	https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html	Trust Policy
IAM-STS-3	Check that Principals allowed to sts:AssumeRole are known accounts owned by the Organization, or are pre-approved (some vendors require a cross-account role)	As cross account roles are another avenue of access into an AWS Account, it is important the appropriate guardrails are in place. When developers are able to create roles, they can control the contents of the Assume Role Policy Document, meaning they can create a cross account role for any account they know the account number to. It is important to understand what cross account roles exist within your organization, and who is allowed access to assume those roles.	Compare allowed principals to a whitelist of pre-approved accounts within the Org or whitelisted by the customer InfoSec Team (Third party Vendor accounts that require access)	https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html	Trust Policy
IAM-STS-4	Check if federated principals should only have programmatic access or also have access to the AWS Management Console.	When you create an IAM role that establishes a trust relationship between IAM and your organization’s identity provider, the role defines what users authenticated by your organization’s IdP are allowed to do in AWS. There are two options. ChooseAllow programmatic access onlyto create a role that can be assumed programmatically from the AWS API or AWS CLI. ChooseAllow programmatic and AWS Management Console accessto create a role that can be assumed programmatically and from the console. For the action sts:AssumeRoleWithSAML, you can add the saml:aud attribute to allow the role to be assumed for both programmatic and sign-in to the AWS Management Console.	Use the saml:aud attribute to make sure that the IAM role is assumable programmatically and for sign-in to the AWS Management Console.	https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_enable-console-saml.html https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_saml.html#idp_saml_Create	Trust Policy
IAM-STS-5	Check IAM role trust policies only allow sts:AssumeRole from specific IP addresses	Customers want to restrict IAM user AWS API calls from specific IP addresses to ensure access is only allowed from the corporate network. You can use theaws:SourceIpglobal condition key in the condition element of an IAM policy to restrict API calls from specific IP addresses. However, this denies access to AWS services, such as AWS CloudFormation, that make calls on your behalf.	Use a condition with “NotIpAddress” and “aws:SourceIp” in the IAM role trust policy for the “sts:AssumeRole” action.	https://aws.amazon.com/premiumsupport/knowledge-center/iam-restrict-calls-ip-addresses/	Trust Policy
IAM-STS-6	sts:TagSession is not allowed for users who can assumeRole*	If users can tag sessions with their own key values, they can possibly ovverride the tag of their role’s tag. thus breaking the boundary of the IAM construct. thus this permission should not be allowed if we have dynamic tag-based access control in the role’s policy	Removests:TagSessionfrom the policy	https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html#id_session-tags_permissions-required	IAM policy