AWS Security Hub · IAM
IAM.27: Identities should not have AWSCloudShellFullAccess attached
Written and reviewed by Emnode · Last reviewed
What does AWS Security Hub IAM.27 check?
IAM.27 fails when any IAM user, group, or role has the AWS-managed AWSCloudShellFullAccess policy attached. The control flags the blanket grant, not CloudShell usage itself.
Why does IAM.27 matter?
AWSCloudShellFullAccess hands an identity a privileged Linux shell inside your account with sudo, persistent storage, outbound internet, and file upload/download. That combination turns whatever the identity can read into a one-step data-exfiltration path, with no instance to launch and no obvious trail. Detaching the blanket policy removes the easiest exfiltration route while preserving scoped CloudShell access for those who need it.
How do I fix IAM.27?
- Find every user, group, and role carrying AWSCloudShellFullAccess.
- Detach it from each identity type with the matching detach call (user, group, or role).
- Replace it with a scoped policy that allows CloudShell but blocks the file-transfer actions for identities that genuinely need the shell.
- Add an SCP denying the blanket policy so it can't be reattached.
Remediation script · bash
# Generate a least-privilege policy from real usage, then promote it to default.
aws accessanalyzer start-policy-generation \
--policy-generation-details principalArn=arn:aws:iam::123456789012:role/DataPipelineWorker
aws iam create-policy-version \
--policy-arn arn:aws:iam::123456789012:policy/DataPipelineWorkerPolicy \
--policy-document file://generated-policy.json --set-as-default
# Move a user's direct policy to a group: attach + add BEFORE detach, so there is no gap.
aws iam attach-group-policy --group-name developers \
--policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
aws iam add-user-to-group --group-name developers --user-name nina
aws iam detach-user-policy --user-name nina \
--policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
# Detach a broad CloudShell grant, then scope down anyone with a genuine need.
aws iam detach-group-policy --group-name developers \
--policy-arn arn:aws:iam::aws:policy/AWSCloudShellFullAccessFull walkthrough (console steps, edge cases and verification) in the lesson Enforce IAM least privilege.
Is IAM.27 a false positive?
AWS itself lists IAM.27 among the controls you might reasonably disable, because plenty of teams genuinely rely on CloudShell's file transfer for day-to-day operations (pulling logs down or pushing a config up is the whole point for them), and stripping that access would break a sanctioned workflow. If a defined group of operators needs the full policy and you've accepted the exfiltration risk, that's a documented exception, not a misconfiguration to chase. The cleaner answer is still to swap the blanket AWSCloudShellFullAccess for a scoped policy that allows CloudShell but denies the file-transfer actions, so most identities pass on merit; where someone truly needs the full grant, suppress the finding for that specific principal rather than disabling the control account-wide, so a fresh attachment elsewhere still surfaces.
More IAM controls
- IAM.1 A policy grants full "*" administrative privileges
- IAM.2 Policies attached directly to users do not scale or audit cleanly
- IAM.3 Long-lived access keys have not been rotated
- IAM.4 The root user still has long-lived access keys
- IAM.5 Console users without MFA are one phish from compromise
- IAM.6 The root user is not protected by hardware MFA
- IAM.7 The IAM password policy is too weak
- IAM.8 Unused IAM keys and passwords are waiting to be leaked
- IAM.9 The root user can sign in without MFA
- IAM.10 IAM user password policies should be strong (PCI DSS)
- IAM.19 MFA should be enabled for all IAM users
- IAM.21 Wildcard permissions grant far more access than intended