AWS IAM Permissions Guardrails

AWS IAM Permissions Guardrails https://aws-samples.github.io/aws-iam-permissions-guardrails/

View project on GitHub

AWS Billing

Identifier Guardrail Rationale Remediation References IAM Actions
IAM-BILLING-1 Check that the ability to modify or update AWS Billing options are only assumable to authorized principals. In all AWS environments, ensure that only billing and account administrators are able to update or modify AWS billing and account options. Unauthorized modifications could affect your billing payments, budgets, or account information such as email addresses and security contacts. For unauthorized principals, either remove the associated IAM Actions https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awsbilling.html

aws-portal:ModifyBilling
aws-portal:ModifyAccount
aws-portal:ModifyPaymentMethods

AWS Budgets

Identifier Guardrail Rationale Remediation References IAM Actions
IAM-BUDGETS-1 Check that the ability to modify or update AWS Budgets options are only assumable to authorized principals. In all AWS environments, ensure that only Budget administrators and authorized principals should be able to update or modify AWS Budgets options. Unauthorized modifications could affect your cost and usage budgets For unauthorized principals, either remove the associated IAM Actions https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html

budgets:ModifyBudget

Amazon CloudTrail

Identifier Guardrail Rationale Remediation References IAM Actions
IAM-CLOUDTRAIL-1 Check that Principals aren’t allowed to DeleteTrail or StopLogging As Cloudtrail is the source for auditing of activity within your AWS Account, it is important to verify that this functionality cannot be disabled by most entities within your Organization. This permission should be limited to breakglass roles (those who own the logging capability). It is also important to call out that Cloudtrail supports Resource Level Permissions for individual trails, so this can be scoped to Infosec/Logging Team owned Trails if the usecase exists for other independent teams to need access to manage their own trails Verify that DeleteTrail and StopLogging are explicitly denied to non-whitelisted Principals And That DeleteTrail and StopLogging permissions don’t exist in an Allow Statement for any non-whitelisted principal https://docs.aws.amazon.com/awscloudtrail/latest/userguide/security_iam_id-based-policy-examples.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscloudtrail.html

cloudtrail:DeleteTrail
cloudtrail:StopLogging
IAM-CLOUDTRAIL-2 Check that only authorized principals are able to UpdateTrail. Unauthorized principals could potentially turn off log file validation, turn off multi region trails, or turn off organizational trails. As Cloudtrail is the source for auditing of activity within your AWS Account, it is important to verify that this functionality is only for authorized principals within your Organization. Examples of authorized principals include break glass roles or those who own the logging capability, such as Security or the Logging Team. Verify that UpdateTrail is allowed only for authorized principals and denied for all else. https://docs.aws.amazon.com/awscloudtrail/latest/APIReference/API_UpdateTrail.html

cloudtrail:UpdateTrail
IAM-CLOUDTRAIL-4 Check that Principals aren’t allowed to PutEventSelectors or PutInsightSelectors. As Cloudtrail is the source for auditing of activity within your AWS Account, it is important to verify that the CloudTrail event selectors can’t be modified to disable the majority of CloudTrail events within your Organization. This permission should be limited to breakglass roles (those who own the logging capability). It is also important to call out that Cloudtrail supports Resource Level Permissions for individual trails, so this can be scoped to Infosec/Logging Team owned Trails if the usecase exists for other independent teams to need access to manage their own trails Verify that PutEventSelectors and PutInsightSelectors are explicitly denied to non-whitelisted Principals and that PutEventSelectors and PutInsightSelectors permissions don’t exist in an Allow Statement for any non-whitelisted principal https://docs.aws.amazon.com/awscloudtrail/latest/userguide/security_iam_id-based-policy-examples.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscloudtrail.html

cloudtrail:PutEventSelectors
cloudtrail:PutInsightSelectors
IAM-CLOUDTRAIL-5 Check that only authorized administrative Principals are allowed AWS CloudTrail modification permissions. As Cloudtrail is the source for auditing of activity within your AWS Account, it is important to verify that this functionality cannot be disabled or modified by most unathorized entities within your Organization. This permission should be limited to those who own the logging capability or break glass principals. It is also important to call out that Cloudtrail supports Resource Level Permissions for individual trails, so this CloudTrail permissions can be scoped to Infosec or Logging Team owned Trails if the usecase exists for other independent teams that need access to manage their own trails. Verify that CloudTrail modification permissions are explicitly denied to non-whitelisted Principals and that the CloudTrail modification permissions don’t exist in an Allow statement for any unauthorized principal. https://docs.aws.amazon.com/awscloudtrail/latest/userguide/security_iam_id-based-policy-examples.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awscloudtrail.html

cloudtrail:DeleteTrail
cloudtrail:PutEventSelectors
cloudtrail:PutInsightSelectors
cloudtrail:RemoveTags
cloudtrail:StopLogging
cloudtrail:UpdateTrail

AWS CodeCommit

Identifier Guardrail Rationale Remediation References IAM Actions
IAM-CODECOMMIT-1 DeleteRepository action for CodeCommit is only allowed to whitelisted roles CodeCommit acts as the source of truth for the versioning of different projects used by the application and/or central IT teams. If privileges to delete repository are not clearly managed, it can lead to accidental deletion of repository leading to data loss Addingaws:ResourceTag/${TagKey}in the IAM policy’s condition to only allow whitelisted roles to delete the repository   codecommit:DeleteRepository

Amazon Elastic Compute Cloud (EC2)

Identifier Guardrail Rationale Remediation References IAM Actions
IAM-EC2-1 Check that the ability to terminate EC2 instances are appropriately scoped or are only assumable to authorized principals. In Production or Production-like environments,no one other than IaC tools should have access to delete resources. Even in development, unintentional termination of EC2 instances can delay project timelines or delivery. If ec2:TerminateInstances has a wildcard resource policy ( Resource *) that isn’t scoped with a condition statement such as ec2:ResourceTag, unauthorized EC2 instances might be inadvertently terminated. For unauthorized principals, either remove ec2:TerminateInstances or appropriately scope with Condition keys. Remove ec2:TerminateIntances for unauthorized principals.   ec2:TerminateInstances
IAM-EC2-2 Check EC2 instances can only run instances with approved Amazon Machine Images (AMIs). For security hardening, vulnerability management, and configuration management purposes, only approved AMIs should be used to launch instances in Production or Production-like environments. Scope ec2:RunInstances resources to approved AMI ids or Use Condition tag with ec2:ResourceTag https://aws.amazon.com/premiumsupport/knowledge-center/restrict-launch-tagged-ami/

https://aws.amazon.com/blogs/aws/amazon-ec2-resource-level-permissions-for-runinstances/

https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonec2.html#amazonec2-ec2ResourceTag_TagKey

ec2:RunInstances
IAM-EC2-3 Check that all network modification permissions are granted to authorized roles only, ideally the AWS Account provisioning role. For all environments it is important to maintain and manage authorized network permitters and boundaries. Unauthorized network modifications could expose the network or service to attacks or data exfiltration. These actions are commonly associated with account provisioning rather than daily or frequent usage. Scope the following network infrastructure actions only to the AWS Account provisioning role. https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Operations.html

ec2:AssociateDhcpOptions
ec2:AssociateRouteTable
ec2:AssociateSubnetCidrBlock
ec2:AssociateVpcCidrBlock
ec2:AttachInternetGateway
ec2:AttachVpnGateway
ec2:CreateCustomerGateway
ec2:CreateDhcpOptions
ec2:CreateInstanceExportTask
ec2:CreateInternetGateway
ec2:CreateRoute
ec2:CreateRouteTable
ec2:CreateSubnet
ec2:CreateVpc
ec2:CreateVpcEndpoint
ec2:CreateVpcEndpointServiceConfiguration
ec2:CreateVpcPeeringConnection
ec2:CreateVpnConnection
ec2:CreateVpnConnectionRoute
ec2:CreateVpnGateway
ec2:DeleteCustomerGateway
ec2:DeleteDhcpOptions
ec2:DeleteEgressOnlyInternetGateway
ec2:DeleteInternetGateway
ec2:DeleteNatGateway
ec2:DeleteNetworkAcl
ec2:DeleteNetworkAclEntry
ec2:DeleteRoute
ec2:DeleteRouteTable
ec2:DeleteSubnet
ec2:DeleteVpc
ec2:DeleteVpcEndpointServiceConfigurations
ec2:DeleteVpcEndpoints
ec2:DeleteVpcPeeringConnection
ec2:DeleteVpnConnection
ec2:DeleteVpnConnectionRoute
ec2:DeleteVpnGateway
ec2:DetachInternetGateway
ec2:DetachVpnGateway
ec2:DisableVgwRoutePropagation
ec2:DisassociateRouteTable
ec2:DisassociateSubnetCidrBlock
ec2:DisassociateVpcCidrBlock
ec2:EnableVgwRoutePropagation
ec2:ModifySubnetAttribute
ec2:ModifyVpcAttribute
ec2:ModifyVpcEndpoint
ec2:ModifyVpcEndpointServiceConfiguration
ec2:ModifyVpcEndpointServicePermissions
ec2:ModifyVpcPeeringConnectionOptionsconnection
ec2:ReplaceRoute
ec2:ReplaceRouteTableAssociation
IAM-EC2-4 Check that sensitive more frequently used EC2 actions are appropriately scoped to approprariate roles and resources. These EC2 actions might be more frequently needed, particularly in a development environment. However, these are sensitive EC2 permissions and should be appropriately scoped and for authorized roles only. Secure using IAM condition statements and tags. https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonec2.html#amazonec2-policy-keys https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_Operations.html

ec2:InstanceSecurityGroup
ec2:AttachVolume
ec2:CopyImage
ec2:CopyFpgaImage
ec2:CreateFpgaImage
ec2:CreateImage
ec2:DeleteFpgaImage
ec2:DeregisterImage
ec2:DisassociateAddress
ec2:DisassociateIamInstanceProfile
ec2:ModifyFpgaImageAttribute
ec2:ModifyImageAttribute
ec2:ReplaceIamInstanceProfileAssociation
IAM-EC2-5 Check that only authorized principals can manage security groups. A security group acts as a virtual firewall for your instance to control inbound and outbound traffic. Security groups act at the instance level, not the subnet level. Thus, security groups are one piece to providing network perimiter protection. For unauthorized principals, remove the permissions to invoke security group IAM actions. https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html

ec2:AuthorizeSecurityGroupEgress
ec2:AuthorizeSecurityGroupIngress
ec2:ApplySecurityGroupsToClientVpnTargetNetwork
ec2:CreateSecurityGroup
ec2:DeleteSecurityGroup
ec2:RevokeSecurityGroupEgress
ec2:RevokeSecurityGroupIngress
ec2:UpdateSecurityGroupRuleDescriptionsEgress
ec2:UpdateSecurityGroupRuleDescriptionsIngress
IAM-EC2-6 Check that only authorized principals can manage EC2.       ec2:AcceptReservedInstancesExchangeQuote
ec2:AcceptTransitGatewayPeeringAttachment
ec2:AcceptTransitGatewayVpcAttachment
ec2:AcceptVpcEndpointConnections
ec2:AcceptVpcPeeringConnection
ec2:AdvertiseByoipCidr
ec2:AllocateAddress
ec2:AllocateHosts
ec2:ApplySecurityGroupsToClientVpnTargetNetwork
ec2:AssignIpv6Addresses
ec2:AssignPrivateIpAddresses
ec2:AssociateAddress
ec2:AssociateClientVpnTargetNetwork
ec2:AssociateDhcpOptions
ec2:AssociateIamInstanceProfile
ec2:AssociateRouteTable
ec2:AssociateSubnetCidrBlock
ec2:AssociateTransitGatewayMulticastDomain
ec2:AssociateTransitGatewayRouteTable
ec2:AssociateVpcCidrBlock
ec2:AttachClassicLinkVpc
ec2:AttachInternetGateway
ec2:AttachNetworkInterface
ec2:AttachVolume
ec2:AttachVpnGateway
ec2:AuthorizeClientVpnIngress
ec2:AuthorizeSecurityGroupEgress
ec2:AuthorizeSecurityGroupIngress
ec2:BundleInstance
ec2:CancelBundleTask
ec2:CancelCapacityReservation
ec2:CancelConversionTask
ec2:CancelExportTask
ec2:CancelImportTask
ec2:CancelReservedInstancesListing
ec2:CancelSpotFleetRequests
ec2:CancelSpotInstanceRequests
ec2:ConfirmProductInstance
ec2:CopyFpgaImage
ec2:CopyImage
ec2:CopySnapshot
ec2:CreateCapacityReservation
ec2:CreateClientVpnEndpoint
ec2:CreateClientVpnRoute
ec2:CreateCustomerGateway
ec2:CreateDefaultSubnet
ec2:CreateDefaultVpc
ec2:CreateDhcpOptions
ec2:CreateEgressOnlyInternetGateway
ec2:CreateFleet
ec2:CreateFlowLogs
ec2:CreateFpgaImage
ec2:CreateImage
ec2:CreateInstanceExportTask
ec2:CreateInternetGateway
ec2:CreateKeyPair
ec2:CreateLaunchTemplate
ec2:CreateLaunchTemplateVersion
ec2:CreateLocalGatewayRoute
ec2:CreateLocalGatewayRouteTableVpcAssociation
ec2:CreateNatGateway
ec2:CreateNetworkAcl
ec2:CreateNetworkAclEntry
ec2:CreateNetworkInterface
ec2:CreateNetworkInterfacePermission
ec2:CreatePlacementGroup
ec2:CreateReservedInstancesListing
ec2:CreateRoute
ec2:CreateRouteTable
ec2:CreateSecurityGroup
ec2:CreateSnapshot
ec2:CreateSnapshots
ec2:CreateSpotDatafeedSubscription
ec2:CreateSubnet
ec2:CreateTags
ec2:CreateTrafficMirrorFilter
ec2:CreateTrafficMirrorFilterRule
ec2:CreateTrafficMirrorSession
ec2:CreateTrafficMirrorTarget
ec2:CreateTransitGateway
ec2:CreateTransitGatewayMulticastDomain
ec2:CreateTransitGatewayPeeringAttachment
ec2:CreateTransitGatewayRoute
ec2:CreateTransitGatewayRouteTable
ec2:CreateTransitGatewayVpcAttachment
ec2:CreateVolume
ec2:CreateVpc
ec2:CreateVpcEndpoint
ec2:CreateVpcEndpointConnectionNotification
ec2:CreateVpcEndpointServiceConfiguration
ec2:CreateVpcPeeringConnection
ec2:CreateVpnConnection
ec2:CreateVpnConnectionRoute
ec2:CreateVpnGateway
ec2:DeleteClientVpnEndpoint
ec2:DeleteClientVpnRoute
ec2:DeleteCustomerGateway
ec2:DeleteDhcpOptions
ec2:DeleteEgressOnlyInternetGateway
ec2:DeleteFleets
ec2:DeleteFlowLogs
ec2:DeleteFpgaImage
ec2:DeleteInternetGateway
ec2:DeleteKeyPair
ec2:DeleteLaunchTemplate
ec2:DeleteLaunchTemplateVersions
ec2:DeleteLocalGatewayRoute
ec2:DeleteLocalGatewayRouteTableVpcAssociation
ec2:DeleteNatGateway
ec2:DeleteNetworkAcl
ec2:DeleteNetworkAclEntry
ec2:DeleteNetworkInterface
ec2:DeleteNetworkInterfacePermission
ec2:DeletePlacementGroup
ec2:DeleteRoute
ec2:DeleteRouteTable
ec2:DeleteSecurityGroup
ec2:DeleteSnapshot
ec2:DeleteSpotDatafeedSubscription
ec2:DeleteSubnet
ec2:DeleteTags
ec2:DeleteTrafficMirrorFilter
ec2:DeleteTrafficMirrorFilterRule
ec2:DeleteTrafficMirrorSession
ec2:DeleteTrafficMirrorTarget
ec2:DeleteTransitGateway
ec2:DeleteTransitGatewayMulticastDomain
ec2:DeleteTransitGatewayPeeringAttachment
ec2:DeleteTransitGatewayRoute
ec2:DeleteTransitGatewayRouteTable
ec2:DeleteTransitGatewayVpcAttachment
ec2:DeleteVolume
ec2:DeleteVpc
ec2:DeleteVpcEndpointConnectionNotifications
ec2:DeleteVpcEndpointServiceConfigurations
ec2:DeleteVpcEndpoints
ec2:DeleteVpcPeeringConnection
ec2:DeleteVpnConnection
ec2:DeleteVpnConnectionRoute
ec2:DeleteVpnGateway
ec2:DeprovisionByoipCidr
ec2:DeregisterImage
ec2:DeregisterTransitGatewayMulticastGroupMembers
ec2:DeregisterTransitGatewayMulticastGroupSources
ec2:DetachClassicLinkVpc
ec2:DetachInternetGateway
ec2:DetachNetworkInterface
ec2:DetachVolume
ec2:DetachVpnGateway
ec2:DisableEbsEncryptionByDefault
ec2:DisableFastSnapshotRestores
ec2:DisableTransitGatewayRouteTablePropagation
ec2:DisableVgwRoutePropagation
ec2:DisableVpcClassicLink
ec2:DisableVpcClassicLinkDnsSupport
ec2:DisassociateAddress
ec2:DisassociateClientVpnTargetNetwork
ec2:DisassociateIamInstanceProfile
ec2:DisassociateRouteTable
ec2:DisassociateSubnetCidrBlock
ec2:DisassociateTransitGatewayMulticastDomain
ec2:DisassociateTransitGatewayRouteTable
ec2:DisassociateVpcCidrBlock
ec2:EnableEbsEncryptionByDefault
ec2:EnableFastSnapshotRestores
ec2:EnableTransitGatewayRouteTablePropagation
ec2:EnableVgwRoutePropagation
ec2:EnableVolumeIO
ec2:EnableVpcClassicLink
ec2:EnableVpcClassicLinkDnsSupport
ec2:ExportImage
ec2:ExportTransitGatewayRoutes
ec2:ImportClientVpnClientCertificateRevocationList
ec2:ImportImage
ec2:ImportInstance
ec2:ImportKeyPair
ec2:ImportSnapshot
ec2:ImportVolume
ec2:ModifyCapacityReservation
ec2:ModifyClientVpnEndpoint
ec2:ModifyDefaultCreditSpecification
ec2:ModifyEbsDefaultKmsKeyId
ec2:ModifyFleet
ec2:ModifyFpgaImageAttribute
ec2:ModifyHosts
ec2:ModifyIdFormat
ec2:ModifyIdentityIdFormat
ec2:ModifyImageAttribute
ec2:ModifyInstanceAttribute
ec2:ModifyInstanceCapacityReservationAttributes
ec2:ModifyInstanceCreditSpecification
ec2:ModifyInstanceEventStartTime
ec2:ModifyInstanceMetadataOptions
ec2:ModifyInstancePlacement
ec2:ModifyLaunchTemplate
ec2:ModifyNetworkInterfaceAttribute
ec2:ModifyReservedInstances
ec2:ModifySnapshotAttribute
ec2:ModifySpotFleetRequest
ec2:ModifySubnetAttribute
ec2:ModifyTrafficMirrorFilterNetworkServices
ec2:ModifyTrafficMirrorFilterRule
ec2:ModifyTrafficMirrorSession
ec2:ModifyTransitGatewayVpcAttachment
ec2:ModifyVolume
ec2:ModifyVolumeAttribute
ec2:ModifyVpcAttribute
ec2:ModifyVpcEndpoint
ec2:ModifyVpcEndpointConnectionNotification
ec2:ModifyVpcEndpointServiceConfiguration
ec2:ModifyVpcEndpointServicePermissions
ec2:ModifyVpcPeeringConnectionOptions
ec2:ModifyVpcTenancy
ec2:ModifyVpnConnection
ec2:ModifyVpnTunnelCertificate
ec2:ModifyVpnTunnelOptions
ec2:MonitorInstances
ec2:MoveAddressToVpc
ec2:ProvisionByoipCidr
ec2:PurchaseHostReservation
ec2:PurchaseReservedInstancesOffering
ec2:PurchaseScheduledInstances
ec2:RebootInstances
ec2:RegisterImage
ec2:RegisterTransitGatewayMulticastGroupMembers
ec2:RegisterTransitGatewayMulticastGroupSources
ec2:RejectTransitGatewayPeeringAttachment
ec2:RejectTransitGatewayVpcAttachment
ec2:RejectVpcEndpointConnections
ec2:RejectVpcPeeringConnection
ec2:ReleaseAddress
ec2:ReleaseHosts
ec2:ReplaceIamInstanceProfileAssociation
ec2:ReplaceNetworkAclAssociation
ec2:ReplaceNetworkAclEntry
ec2:ReplaceRoute
ec2:ReplaceRouteTableAssociation
ec2:ReplaceTransitGatewayRoute
ec2:ReportInstanceStatus
ec2:RequestSpotFleet
ec2:RequestSpotInstances
ec2:ResetEbsDefaultKmsKeyId
ec2:ResetFpgaImageAttribute
ec2:ResetImageAttribute
ec2:ResetInstanceAttribute
ec2:ResetNetworkInterfaceAttribute
ec2:ResetSnapshotAttribute
ec2:RestoreAddressToClassic
ec2:RevokeClientVpnIngress
ec2:RevokeSecurityGroupEgress
ec2:RevokeSecurityGroupIngress
ec2:RunInstances
ec2:RunScheduledInstances
ec2:SendDiagnosticInterrupt
ec2:StartInstances
ec2:StartVpcEndpointServicePrivateDnsVerification
ec2:StopInstances
ec2:TerminateClientVpnConnections
ec2:TerminateInstances
ec2:UnassignIpv6Addresses
ec2:UnassignPrivateIpAddresses
ec2:UnmonitorInstances
ec2:UpdateSecurityGroupRuleDescriptionsEgress
ec2:UpdateSecurityGroupRuleDescriptionsIngress
ec2:WithdrawByoipCidr

Amazon Elastic Container Registry (ECR)

Identifier Guardrail Rationale Remediation References IAM Actions
IAM-ECR-2 Check that only authorized principals are able to pull images from ECR. An authorization token is used to manage authorization to ECR. Only authorized principals should have the ability to retrieve the authorization token, in order to protect any images in ECR. For the action ecr:GetAuthorizationToken either: Explicitly grant to a list of authorized principals OR Consider usingaws:PrincipalOrgPathswhen multiple AWS Accounts need access. https://docs.aws.amazon.com/AmazonECR/latest/userguide/ecr_managed_policies.html#AmazonEC2ContainerRegistryReadOnly

https://docs.aws.amazon.com/AmazonECR/latest/APIReference/API_GetAuthorizationToken.html

ecr:GetAuthorizationToken

Amazon Elastic Kubernetes Service

Identifier Guardrail Rationale Remediation References IAM Actions
IAM-EKS-1 Check that the management of your EKS clusters is for authorized principals only. It is important that access control to the management of your EKS clusters is only performed by your authorized principals. Protect against unauthorized modifications or changes to your EKS clusters by limiting access to only your administrative principals.     eks:CreateCluster
eks:CreateFargateProfile
eks:CreateNodegroup
eks:DeleteCluster
eks:DeleteFargateProfile
eks:DeleteNodegroup
eks:TagResource
eks:UntagResource
eks:UpdateClusterConfig
eks:UpdateClusterVersion
eks:UpdateNodegroupConfig
eks:UpdateNodegroupVersion

Amazon GuardDuty

Identifier Guardrail Rationale Remediation References IAM Actions
IAM-GUARDDUTY-1 Ensure GuardDuty master account does not have permission to StopMonitoringMembers action The master account should not have permissions to deregister a centralized member account unless it is done by a security admin Makes the accounts go “invisible” which can lead to malicious activities which cannot be viewed at org master level Remove principal ARNs if they don’t meet the whitelisted role name and/or statement body   guardduty:StopMonitoringMembers

AWS Identity and Access Management (IAM)

Identifier Guardrail Rationale Remediation References IAM Actions
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
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
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
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
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
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
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

AWS Key Management Service (KMS)

Identifier Guardrail Rationale Remediation References IAM Actions
IAM-KMS-2 Check that either only authorized principals or no principals can delete imported key material. This is a potentially destructive action. Deletes key material that you previously imported. This operation makes the specified customer master key (CMK) unusable until the key material is reimported. All encrypted data is unreadable and unable to be decrypted until the customer reimports the exact same key material. A decision should be made if any break-glass roles should have this capability. These authorized roles should be whitelisted and all other rules should trigger a violation. Permission kms:DeleteImportedKeyMaterial should only be for authorized principals. Ensure any attached policies are for authorized use cases only and have sufficient preventive controls and monitoring alerts. Enforce with preventive controls (e.g., service control policies). Detect on any AWS API calls to delete imported key material. https://docs.aws.amazon.com/kms/latest/developerguide/importing-keys-delete-key-material.html

kms:DeleteImportedKeyMaterial
IAM-KMS-3 Check that either only authorized principals or no principals can delete CMKs. Deleting a CMK is a destructive and potentially dangerous operation. When a CMK is deleted, all data that was encrypted under the CMK is unrecoverable. Even in development this can be disruptive as there might be unnecessary downtime. The preventive control is to avoid ununauthorized capability of deleting CMKs. Relying on the 7 day waiting period and notificatons require appropriate detective controls. Permission kms:ScheduleKeyDeletion should only be for authorized principals. Ensure any attached policies are for authorized use cases only and have sufficient preventive controls and monitoring alerts. Enforce with preventive controls (e.g., service control policies). Detect on any AWS API calls to delete CMKs https://docs.aws.amazon.com/kms/latest/APIReference/API_ScheduleKeyDeletion.html

kms:ScheduleKeyDeletion
IAM-KMS-4 Check that either only authorized principals or no principals can disable CMKs. If you disable a CMK, it cannot be used to encrypt or decrypt data until you re-enable it. This has immediate effectiveness. This could potentially incur downtime in a production environment. Even in development this can be disruptive as there might be unnecessary downtime. Permission kms:DisableKey should only be for authorized principals. Ensure any attached policies are for authorized use cases only and have sufficient preventive controls and monitoring alerts. Enforce with preventive controls (e.g., service control policies). Detect on any AWS API calls to disable CMKs. https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html

kms:DisableKey
IAM-KMS-5 Check that either only authorized principals or no principals can place a new KMS key policy. Users with the PutKeyPolicy permission for a CMK can completely replace the key policy for a CMK with a different key policy of their choice. Permission kms:PutKeyPolicy should only be for authorized principals. Ensure any attached policies are for authorized use cases only and have sufficient preventive controls and monitoring alerts. Enforce with preventive controls (e.g., service control policies). Detect on any AWS API calls to put key policy. https://d0.awsstatic.com/whitepapers/aws-kms-best-practices.pdf

kms:PutKeyPolicy
IAM-KMS-7 Check that either only authorized principals or no principals can disable key rotation. Disabling key rotation will prevent the CMK from automatic annual rotation. Permission kms:DisableKeyRotation should only be for authorized principals. Ensure any attached policies are for authorized use cases only and have sufficient preventive controls and monitoring alerts. Enforce with preventive controls (e.g., service control policies). Detect on any AWS API calls to disable CMKs. https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html

kms:DisableKeyRotation
IAM-KMS-9 Check that only authorized administrative Principals are allowed AWS KMS administrative permissions. AWS Key Management Service (KMS) makes it easy for you to create and manage cryptographic keys and control their use across a wide range of AWS services and in your applications. It is important that access control to the management of your keys is only performed by authorized administrative key management administrators. Verify that KMS administrative and modification permissions are explicitly denied to non-whitelisted Principals and that the KMS modification permissions don’t exist in an Allow statement for any unauthorized principal. https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html

kms:CancelKeyDeletion
kms:ConnectCustomKeyStore
kms:CreateAlias
kms:CreateCustomKeyStore
kms:CreateGrant
kms:CreateKey
kms:DeleteAlias
kms:DeleteCustomKeyStore
kms:DeleteImportedKeyMaterial
kms:DisableKey
kms:DisableKeyRotation
kms:DisconnectCustomKeyStore
kms:ImportKeyMaterial
kms:PutKeyPolicy
kms:RetireGrant
kms:RevokeGrant
kms:ScheduleKeyDeletion
kms:TagResource
kms:UntagResource
kms:UpdateAlias
kms:UpdateCustomKeyStore
kms:UpdateKeyDescription

AWS Lambda

Identifier Guardrail Rationale Remediation References IAM Actions
IAM-LAMBDA-2 Check that the management of your Lambdas is for authorized principals only. It is important that access control to the management of your Lambdas is only performed by your authorized principals. Protect against unauthorized modifications or changes to your Lambdas by limiting access to only your administrative principals.     lambda:AddLayerVersionPermission
lambda:AddPermission
lambda:CreateAlias
lambda:CreateEventSourceMapping
lambda:CreateFunction
lambda:DeleteAlias
lambda:DeleteEventSourceMapping
lambda:DeleteFunction
lambda:DeleteFunctionConcurrency
lambda:DeleteFunctionEventInvokeConfig
lambda:DeleteLayerVersion
lambda:DeleteProvisionedConcurrencyConfig
lambda:DisableReplication
lambda:EnableReplication
lambda:InvokeAsync
lambda:InvokeFunction
lambda:PublishLayerVersion
lambda:PublishVersion
lambda:PutFunctionConcurrency
lambda:PutFunctionEventInvokeConfig
lambda:PutProvisionedConcurrencyConfig
lambda:RemoveLayerVersionPermission
lambda:RemovePermission
lambda:TagResource
lambda:UntagResource
lambda:UpdateAlias
lambda:UpdateEventSourceMapping
lambda:UpdateFunctionCode
lambda:UpdateFunctionConfiguration
lambda:UpdateFunctionEventInvokeConfig

Amazon Simple Storage Service (S3)

Identifier Guardrail Rationale Remediation References IAM Actions
IAM-S3-2 Check that the ability to get sensitive or classified information in S3 Objects is for authorized principals only. Access to sensitive data must only be access to authorized principals. Unauthorized principals that are able to get S3 Objects would be able to read sensitive data and violate security policy. Options include Complete removal of unauthorized principals from s3:GetObject. Scoping using condition keys to contain principal access to authorized S3 objects only. Encrypt at rest the S3 objects using a customer managed AWS CMKs to provide defense in depth. If the key policy prevents the unauthorized principal fro decrypting the data, then the unauthorized principal will not be able to decrypt the data, even if there were able to download the S3 object. https://aws.amazon.com/blogs/security/how-to-use-bucket-policies-and-apply-defense-in-depth-to-help-secure-your-amazon-s3-data/

https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazons3.html#amazons3-GetObject

s3:GetObject
IAM-S3-4 Check that the management of your S3 buckets and objects is for authorized principals only. It is important that access control to the management of your S3 buckets and principals is only performed by your authorized principals. Protect against unauthorized modifications or changes to your sensitive data in your S3 buckets by limiting access to only your administrative principals.   https://aws.amazon.com/blogs/security/how-to-use-bucket-policies-and-apply-defense-in-depth-to-help-secure-your-amazon-s3-data/

https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazons3.html#amazons3-GetObject

s3:AbortMultipartUpload
s3:BypassGovernanceRetention
s3:CreateAccessPoint
s3:CreateBucket
s3:CreateJob
s3:DeleteAccessPoint
s3:DeleteAccessPointPolicy
s3:DeleteBucket
s3:DeleteBucketPolicy
s3:DeleteBucketWebsite
s3:DeleteObject
s3:DeleteObjectTagging
s3:DeleteObjectVersion
s3:DeleteObjectVersionTagging
s3:ObjectOwnerOverrideToBucketOwner
s3:PutAccelerateConfiguration
s3:PutAccessPointPolicy
s3:PutAccountPublicAccessBlock
s3:PutAnalyticsConfiguration
s3:PutBucketAcl
s3:PutBucketCORS
s3:PutBucketLogging
s3:PutBucketNotification
s3:PutBucketObjectLockConfiguration
s3:PutBucketPolicy
s3:PutBucketPublicAccessBlock
s3:PutBucketRequestPayment
s3:PutBucketTagging
s3:PutBucketVersioning
s3:PutBucketWebsite
s3:PutEncryptionConfiguration
s3:PutInventoryConfiguration
s3:PutLifecycleConfiguration
s3:PutMetricsConfiguration
s3:PutObject
s3:PutObjectAcl
s3:PutObjectLegalHold
s3:PutObjectRetention
s3:PutObjectTagging
s3:PutObjectVersionAcl
s3:PutObjectVersionTagging
s3:PutReplicationConfiguration
s3:ReplicateDelete
s3:ReplicateObject
s3:ReplicateTags
s3:RestoreObject
s3:UpdateJobPriority
s3:UpdateJobStatus

Amazon Simple Storage Service (S3) Access Points

Identifier Guardrail Rationale Remediation References IAM Actions
IAM-S3-AP-1 Check that the VPC mentioned in the S3-AccessEndpoint is valid VPC The Access Point cannot be edited once it has been created. If it has been created incorrectly, the only method is to delete the access point and create a new access point. Check the VPC value provided in the API call payload for creating access point is a valid VPC in the account specified. https://docs.aws.amazon.com/AmazonS3/latest/dev/creating-access-points.html

s3:CreateAccessPoint
IAM-S3-AP-2 Block Public access to buckets and objects through access points The block public access setting of the Access point should not be open to public unless really justified by customer requirements. Check PublicAccessBlockConfiguration setting of access point is set to not allow public access.   s3:CreateAccessPoint
IAM-S3-AP-3 Allow s3:GetObject and s3:PutObject on the S3 Access Points owned by the account. If a user has IAM policies or bucket policies which allow authorized users to interact with the bucket’s objects through access point, the s3:DataAccessPointAccount condition should be added to ensure only access points owned by the buckets are allowed to perform s3:GetObject and s3:PutObjects Add s3:DataAccessPointAccount condition to the bucket policy to deny all GetObject and PutObject actions to S3 Access point’s owner account https://docs.aws.amazon.com/AmazonS3/latest/dev/creating-access-points.html#access-points-policies

s3:DataAccessPointAccount
IAM-S3-AP-4 Limit access to the S3 bucket only through a specific S3 Access Point for the bucket Buckets which have specific access points enabled and do not have access pattern outside of access points. These buckets should have bucket policies which allow GetObject and PubObject only through the approved S3 Access Endpoints Add s3:DataAccessPointAccount condition to the bucket policy to deny all GetObject and PutObject actions to S3 Access point’s owner account https://docs.aws.amazon.com/AmazonS3/latest/dev/creating-access-points.html#access-points-policies

s3:DataAccessPointAccount
IAM-S3-AP-5 Limit access to the S3 bucket only to traffic originated from VPC and coming through S3 Access Points Buckets which have S3 access points enabled should have bucket policy which limits access to them only through traffic originating from Amazon VPCs. This additional control prevents misconfiguration of bucket access pattern. Add s3:AccessPointNetworkOrigin condition with VPC value to the bucket policy to deny all GetObject and PutObject actions to S3 Access point’s owner account https://docs.aws.amazon.com/AmazonS3/latest/dev/creating-access-points.html#access-points-policies

s3:AccessPointNetworkOrigin
IAM-S3-AP-6 Limit access to S3 bucket objects by restricting principals which have a common tag as the object Buckets which have S3 access points enabled should have S3 access point policy enabled which allows IAM principals to make call to the objects which are tagged with a particular value Add s3:ExistingObjectTag condition in the S3 Access Endpoint policy which has allows certain principals with the similar tags to get access to the objects https://docs.aws.amazon.com/AmazonS3/latest/dev/creating-access-points.html#access-points-policies

s3:GetObject

AWS Secrets Manager

Identifier Guardrail Rationale Remediation References IAM Actions
IAM-SECRETSMANAGER-1 Check that DeleteSecret is appropriately scoped and for authorized principals. Deleting a secret makes the secret immediately inaccessible and could impact applications that depend on the secret. Check that Only authorized principals can invoke DeleteSecret Scope using secretsmanager:SecretId secretsmanager:AllowRotationLambdaArn or with a tag secretsmanager:ResourceTag/Optionally prevent disabling of the recovery window using theconditionssecretsmanager:ForceDeleteWithoutRecovery and secretsmanager:RecoveryWindowInDays https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage_delete-restore-secret.html

https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_DeleteSecret.html#SecretsManager-DeleteSecret-request-ForceDeleteWithoutRecovery

https://docs.aws.amazon.com/secretsmanager/latest/userguide/reference_iam-permissions.html#iam-contextkeys

secretsmanager:DeleteSecret
IAM-SECRETSMANAGER-2 Check that only authorized principals are able to retrieve a secret value. Sensitive or confidential information (e.g., credentials) would be expected to be stored in AWS Secrets Manager. Ensuring only authorized access reduces the risk of unauthorized access. Check that only authorized principals can invoke GetSecretValue. Specify the Secret Resource Arn. Also, scope using the Condition key secretsmanager:SecretId or secretsmanager:ResourceTag/ https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_GetSecretValue.html

https://docs.aws.amazon.com/secretsmanager/latest/userguide/reference_iam-permissions.html#iam-contextkeys

secretsmanager:GetSecretValue
IAM-SECRETSMANAGER-3 Check for separation of duties between managing a secret and reading or writing to a secret. An administrator is required to manage creating secret via CreateSecret. Though populating the secret value including both reading GetSecretValue and writing the secret PutSecretValue should be performed by a separate principal, ideally only automation should be generating a (random) secret value and rotating the secret. Separating out the management from actually viewing the secret data reduces the risk of unauthorized access. Check that the administration CreateSecret principal is separate from the secret value principal GetSecretValue and PutSecretValue.   secretsmanager:CreateSecret

Amazon Systems Manager (SSM)

Identifier Guardrail Rationale Remediation References IAM Actions
IAM-SSM-1 Check that usage of ssm:SendCommand is scoped via the usage of Resource Level Permissions or via the usage of conditions such as ssm:ResourceTag (no usage of * except for breakglass/admin roles) ssm:RunCommand allows command execution on a machine that is managed by SSM (SSM Agent Installed and Instance Profile configured with proper permissions). If a wildcard resource is specified - this grants unrestricted access to command execution on all SSM Managed EC2 Instances across the account. While some usecases may legitimately require this access (Breakglass/Admin Accounts, IR, etc), the majority of roles should be scoped to have this access only to EC2 Instances required for function. Usage of Resource Level Permissions - Specifiying the ARN of the instances needed in the statement of the policy arn:Partition:ec2:{Region}:Account:instance/{InstanceId} Or Usage of a tag condition - ec2:ResourceTag to scope usage of the command to only instances containing the appropriate tag https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html

https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awssystemsmanager.html#awssystemsmanager-managed-instance

https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html

ssm:SendCommand
IAM-SSM-2 ssm:StartSession action with Resource * that doesnt have a condition statement such as ssm:ResourceTag StartSession permission allows a principal to start an SSH session with the instance target. Unrestricted access to this can lead to logging into resources which may or may not be owned by the intended principal. Session manager should allow login into properly tagged resources only. If there are the instances being spun up either deliberately or accidentally with the appropriate tags it should not be accessible via SSH using Systems Manager Usage of tag condition such as ssm:ResourceTag OR Removal of the ssm:StartSession action from the IAM policy https://docs.aws.amazon.com/systems-manager/latest/userguide/auth-and-access-control-permissions-reference.html

ssm:StartSession