Org guardrails and human access

The earlier pages cover what one principal may do. This page covers the walls around the whole company. It asks how humans log in, how accounts are split, and how org-level policies limit what any admin can do, even an admin who makes a mistake.

The big idea

A single account with every team inside makes least privilege almost impossible. One bad policy or one leaked key can reach everything. The fix has two parts: split the accounts by environment and blast radius, then put ceilings above them that nobody inside can lift.

Humans: SSO, short sessions, break-glass

Humans should not hold long-lived IAM user keys. Instead:

• Log in through SSO (IAM Identity Center on AWS, Cloud Identity federation on GCP) with the company identity provider.
• Use short sessions, from 1 to 8 hours, with MFA for console and sensitive CLI roles.
• Use permission sets for jobs, such as Developer, OnCall or BillingViewer, not one shared admin.
• Prefer just-in-time access. Request a role for two hours instead of holding admin all the time.
• Keep a few break-glass accounts. These are heavily audited, MFA-bound and monitored with real-time alerts. They are used only when SSO is down.

Walking through the guardrails

Here is what an account admin can do without and with org guardrails:

Without org guardrails:
  Account admin attaches AdministratorAccess
    -> creates a public bucket
    -> disables logging

With SCPs:
  Even AdministratorAccess cannot:
    - disable CloudTrail
    - create resources outside approved regions
    - turn off the public access block without a break-glass tag

The admin's own policy is irrelevant here. The SCP is a ceiling above the account, so the actions are blocked whatever the account's policies say. Put logging and security tooling in a dedicated account that application teams cannot change.

Splitting accounts

A typical split uses separate accounts for prod, staging, shared-services and security, all under one organization. Each boundary limits the damage a mistake can cause. The security account holds the logs, so an attacker in prod cannot erase them.

Common mistakes

• Permanent admin groups "for convenience." Standing privilege is what gets misused.
• Assuming an SCP grants access. It never does. An allow must still exist in the account.
• One account for everything. Blast radius equals the whole company.
• Untested break-glass. The path you never run is the path that fails.

Check yourself

1. An admin with AdministratorAccess tries to disable CloudTrail. Why does it fail? An SCP caps what member accounts may do, so the block holds whatever the account's own policies say.
2. Why prefer a two-hour role over standing admin? A short role ends by itself, so less privilege sits around to be misused.

Key takeaways

• Log in through SSO with short sessions and MFA. Avoid long-lived user keys.
• Use just-in-time access instead of standing admin groups.
• SCPs and organization policies are ceilings set above all accounts.
• Split accounts by environment, and keep logging in a separate account.

Further learning

For the zero-trust side of human access, read the BeyondCorp overview linked from the IAM topic page. For the long-lived secrets that remain, see secrets management and encryption.