Use a Deny policy to revoke active user permissions
You might need to revoke an IAM Identity Center user’s access to AWS accounts while the user is actively using a permission set. You can remove their ability to use their active IAM role sessions by implementing a Deny policy for an unspecified user in advance, then when needed, you can update the Deny policy to specify the user whose access you want to block. This topic explains how to create a Deny policy and considerations for how to deploy the policy.
Prepare to revoke an active IAM role session created by a permission set
You can prevent the user from taking actions with an IAM role they're actively using by applying a deny all policy for a specific user through the use of a Service Control Policy You can also prevent a user from using any permission set until you change their password, which removes a bad actor actively misusing stolen credentials. If you need to deny access broadly and prevent a user from re-entering a permission set or accessing other permission sets, you might also remove all user access, stop the active AWS access portal session, and disable the user sign-in. See Revoke active IAM role sessions created by permission sets to learn how to use the Deny policy in conjunction with additional actions for broader access revocation.
Deny policy
You can use a Deny policy with a condition that matches to the user’s
UserID
from the IAM Identity Center identity store to prevent further
actions by an IAM role that the user is actively using. Using this
policy avoids impact to other users who might be using the same
permission set when you deploy the Deny policy. This policy uses the
placeholder user ID,
, for Add user ID
here
"identitystore:userId"
that you’ll update with the user ID for which you want to revoke
access.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "*" ], "Resource": "*", "Condition": { "StringEquals": { "identitystore:userId": "
Add user ID here
" } } } ] }
Although you could use another condition key such as
“aws:userId”
, “identitystore:userId”
is
certain because it's a globally unique value that's associated with one
person. Using “aws:userId”
in the condition can be affected
by how user attributes are synchronized from your source of identities
and can change if the user’s username or email address changes.
From the IAM Identity Center console, you can find a user’s
identitystore:userId
by navigating to
Users, searching for the user by name,
expanding the General information section and
copying the User ID. It's also convenient to stop a user’s AWS access portal
session and disable their sign-in access in the same section while
searching for the User ID. You can automate the process to create a Deny
policy by obtaining the user’s User ID through querying the identity
store APIs.
Deploying the deny policy
You can use a placeholder user ID that isn't valid, such as
, to
deploy the Deny policy in advance using a Service Control Policy (SCP)
that you attach to the AWS accounts users might have access to. This
is the recommended approach for its ease and speed of impact. When you
revoke a user’s access with the Deny policy, you'll edit the policy to
replace the placeholder user ID with the user ID of the person whose
access you want to revoke. This prevents the user from taking any
actions with any permission set in every account that you attach the
SCP. It blocks the user’s actions even if they use their active
AWS access portal session to navigate to different accounts and assume
different roles. With the user’s access fully blocked by the SCP, you
can then disable their ability to sign in, revoke their assignments, and
stop their AWS access portal session if needed. Add user ID here
As an alternative to using SCPs, you can also include the Deny policy in the inline policy of permission sets and in customer managed policies that are used by the permission sets the user can access.
If you must revoke access for more than one person, you can use a list of values in the condition block, such as:
"Condition": { "StringEquals": { "identitystore:userId": ["
user1 userId
", "user2 userId
"...] } }
Important
Regardless of the method(s) you use, you must take any other corrective actions and keep the user’s user ID in the policy for at least 12 hours. After that time, any roles the user has assumed expire and you can then remove their user ID from the Deny policy.