Short version: Use Identity Center (SSO) for humans, IAM roles for workloads, and a handful of organization guardrails. Keep permission sets simple (ReadOnly, PowerUser-no-IAM, Admin), enforce MFA and sensible session lengths, and monitor root usage rather than trying to block it.
1) The shape that works
- Accounts: management, log-archive, security, and one per environment (dev/test/prod).
- Humans: sign in via Identity Center → assume roles into target accounts.
- Workloads: IAM roles with least privilege; no IAM users or long-lived keys.
2) Enable Identity Center and wire MFA
- In the management account, enable Identity Center and choose your identity source (built-in or external IdP).
- Require MFA for user sign-in (TOTP or hardware; avoid SMS).
- Set session duration (e.g., 1–4 hours) and CLI/AWS SDK session duration to match policy.
3) Create three permission sets
Attach these to groups (not individuals), then assign groups to accounts.
ReadOnly
- Attach AWS managed policy
ReadOnlyAccess. - Session 4h max. Use for auditors and developers outside their environment.
PowerUser (no IAM)
Start with AWS managed PowerUserAccess and add a deny statements for IAM/org changes.
{
"Version": "2012-10-17",
"Statement": [
{ "Effect": "Deny", "Action": ["iam:*","organizations:*","account:*","sso:*"], "Resource": "*" }
]
}Admin (break-glass)
- AdministratorAccess equivalent; keep membership small.
- Session 1h; MFA mandatory; log justification in the ticket.
4) Map groups to accounts
- Example: dev-engineers → Dev account: PowerUser; Test: ReadOnly.
- platform-admins → all accounts: Admin; membership reviewed monthly.
5) Guardrails (Organization-level)
Test these in a sandbox first. Keep them few and clear.
Deny CloudTrail tampering
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "DenyTrailStopDelete",
"Effect": "Deny",
"Action": [
"cloudtrail:StopLogging",
"cloudtrail:DeleteTrail",
"cloudtrail:UpdateTrail",
"cloudtrail:PutEventSelectors"
],
"Resource": "*"
}]
}Deny leaving the organization
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "DenyLeaveOrg",
"Effect": "Deny",
"Action": "organizations:LeaveOrganization",
"Resource": "*"
}]
}Discourage IAM users (prefer Identity Center)
Block creation of new IAM users and access keys. If you still need a service user somewhere, scope an exception by account or tag.
{
"Version": "2012-10-17",
"Statement": [{
"Sid": "NoIamUsers",
"Effect": "Deny",
"Action": [
"iam:CreateUser",
"iam:CreateAccessKey",
"iam:PutUserPolicy",
"iam:AttachUserPolicy"
],
"Resource": "*"
}]
}6) Monitoring and hygiene
- Alarm on root usage (CloudTrail → CloudWatch metric filter) rather than trying to block it.
- Log to a central S3 bucket in the log-archive account; enable log file validation.
- Rotate access: quarterly review of Identity Center group membership and permission sets.
7) Break-glass procedure (write it down)
- Who can assume Admin, for how long, and how justification is recorded.
- How to revoke access and what to check post-incident.
Security gaps in Linux and cloud systems risk downtime, data compromise, lost business — and compliance failures.
With 20+ years’ experience and active UK Security Check (SC) clearance, I harden Linux and cloud platforms for government, corporate, and academic sectors — ensuring secure, compliant, and resilient infrastructure.