Identity is the new perimeter

Why identity is the perimeter

In an old office network, the firewall was the wall around the castle. If you were inside the building, you were mostly trusted. In the cloud, every action, from starting a server to reading a file, is an API call over the internet. A perimeter is the boundary that decides who gets in. In the cloud that boundary is the identity making the call: a user, a role or a key. If an attacker steals a valid access key, no firewall stops them.

Lock down the root user

• Turn on MFA (multi-factor authentication: a second proof such as a phone app, passkey or hardware key) for the root user of every account.
• Delete any root access keys and never create new ones.
• Store the root password in a company password manager, not in someone's head or inbox.
• In an AWS Organization you can also manage root access centrally and remove root passwords from member accounts, so the root user cannot sign in at all unless an admin allows a specific task.

MFA everywhere and SSO for people

Every human who can sign in to the console should use MFA. SSO (single sign-on) means people sign in once through the company identity provider, such as Microsoft Entra ID, Okta or Google Workspace, and get access to the AWS accounts they need. On AWS this is IAM Identity Center. When someone leaves the company, HR disables one account and all cloud access stops at once. Without SSO, you must remember to delete IAM users in every account, and people get missed.

Roles and short-lived credentials

A long-lived access key (it starts with AKIA) works until someone deletes it. If it leaks in a GitHub repository, attackers find it within minutes. A role gives temporary credentials (they start with ASIA) that expire on their own, usually within an hour. Use roles for EC2 instance profiles, Lambda functions, ECS tasks, and for CI/CD pipelines through OIDC federation (for example GitHub Actions assuming a role without any stored key).

Least privilege and permission boundaries

Least privilege means each identity gets only the actions and resources it needs, nothing more. Start small and add permissions when a real need appears. IAM Access Analyzer helps: it shows resources shared outside your account, flags unused roles and permissions, and can generate a policy from the actions a role actually used in CloudTrail. A permissions boundary is a managed policy that sets the maximum permissions a user or role can ever have. It is useful when you let developers create their own roles: they can create roles, but never with more power than the boundary allows.

AWS Organizations and Service Control Policies

AWS Organizations groups many accounts under one management account, with organisational units (OUs) such as Security, Production and Development. A Service Control Policy (SCP) sets the maximum permissions for every identity in the accounts it is attached to, including the account root user. SCPs never grant anything; they only limit. They do not affect the management account itself, so keep workloads out of it. The example below keeps everything in the two Indian regions, Mumbai (ap-south-1) and Hyderabad (ap-south-2).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideIndianRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "organizations:*",
        "sts:*",
        "route53:*",
        "cloudfront:*",
        "waf:*",
        "support:*",
        "budgets:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["ap-south-1", "ap-south-2"]
        },
        "ArnNotLike": {
          "aws:PrincipalARN": "arn:aws:iam::*:role/BreakGlassAdmin"
        }
      }
    }
  ]
}

Why the NotAction list? Some services are global: IAM, Organizations, Route 53, CloudFront and others send their API calls to us-east-1 even when your work is in Mumbai. If you deny them, nobody can create a role or a DNS record. The AWS documentation has a longer, maintained list of exceptions; copy from there and test the SCP on a sandbox OU before attaching it to production.

Break-glass accounts and access reviews

A break-glass account (or role) is an emergency identity used only when normal sign-in fails, for example when SSO is down. Protect it with a hardware MFA key kept in a safe, alert on every use, and test it twice a year. An access review is a regular check, usually every quarter, where managers confirm who still needs which access. The IAM credential report lists every user with MFA status, password and key ages.

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 --decode > report.csv
aws accessanalyzer list-analyzers