IAM Best Practices & Least Privilege

The Auditor's Report

Three weeks into her engagement, Priya sends Dana a short audit report from her own AWS account, signed in through the cross-account role Trailbase set up for her. It contains two findings, and neither one has caused an incident. Yet.

Finding one: a policy named TempS3Fix, attached to the Developers group, grants s3:* on every resource in the account. Someone created it during a late-night debugging session back in the shared-root days, promised to tighten it later, and forgot. Finding two: an active access key belonging to the user jordan-contractor, unused for 241 days. Jordan built the trail-map importer last year, finished the project, and left. His key still opens the account from anywhere on the internet.

Dana reads the report twice, then opens a new document titled Trailbase Security Charter. Every rule in it is a scar with a name attached: root lockdown from the Theo incident, policy discipline from Priya's finding one, credential hygiene from finding two. This lesson walks through that charter, because the SAA-C03 exam is essentially asking you to write the same document for a fictional company in every security question.

The organizing idea behind the whole charter is least privilege: every identity should hold exactly the permissions its job requires, and nothing more. You met the principle in lesson 1. This lesson is about practicing it, because least privilege is a continuous process of granting, measuring, and trimming access rather than a checkbox you tick once.

The charter organizes its rules in layers, from the root account at the top down to individual resources. Keep this map in view as we work through each rule:

Rule One: Treat Least Privilege as a Process

Why does TempS3Fix matter if nothing bad ever happened through it? Because permissions define your blast radius: the total damage one compromised credential can do. With s3:* on every bucket, a single phished developer password could read every hiker photo, delete every backup, and rewrite every static asset Trailbase serves. Least privilege shrinks that radius until a stolen credential is an annoyance instead of a catastrophe.

There are quieter benefits too. Narrow permissions make audits readable, because Priya can look at a policy and know what a person can actually do. They satisfy compliance frameworks such as SOC 2, HIPAA, and PCI-DSS, which all demand demonstrable access control. And they create accountability, because every grant has an owner and a reason.

The direction of travel is the part people get wrong. Trailbase used to start from everything and promise to subtract later, which is how TempS3Fix survived for a year. The charter reverses the arrow: start from nothing, and make every addition answer to a real requirement. Remember from lesson 1 that a new IAM user begins with zero permissions anyway; the charter simply insists on keeping that spirit as access grows.

Rule Two: Prefer Credentials That Expire

Jordan's stale access key is the second scar. An access key is a long-term credential: it works forever until a human remembers to rotate or delete it, and humans forget. For 241 days, anyone who found that key in an old laptop backup or a leaked config file could have acted as Jordan. The fix for this class of problem is structural. Use credentials that destroy themselves.

Temporary credentials are short-lived keys issued by AWS STS, the Security Token Service that powers every role assumption you saw in lesson 1. They expire automatically after a configurable window of 15 minutes to 12 hours, AWS rotates them without anyone lifting a finger, and there is nothing durable to embed in code. The Trailbase EC2 fleet already lives this way: the app servers upload hiker photos to trailbase-photos through an instance role, and no server has ever held a permanent key.

Dana deletes Jordan's key the same afternoon, and the charter gains a rule: long-term credentials exist only where nothing temporary can work, and each one carries an expiry review date.

Rule Three: Let Evidence Write Your Policies

Here is the awkward question Priya's report raises: how does Mara shrink TempS3Fix without breaking the data pipeline that depends on it? Fear of breakage is the reason broad policies survive. Nobody knows exactly which actions are in use, so nobody dares remove any.

IAM Access Analyzer removes the guesswork. It reads the account's CloudTrail history (CloudTrail is the AWS service that records every API call made in the account) and reports which actions an identity actually performed, then generates a policy containing exactly those actions. Mara stops estimating what the pipeline needs and starts measuring it.

Step 1: The Broad Starting Point

This is what TempS3Fix looks like today. Broad grants like this are acceptable only as a short-lived scaffold while you gather usage data, and even then only in non-production accounts:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:*"
      ],
      "Resource": "*"
    }
  ]
}

Step 2: Analyze and Reduce

After two weeks of CloudTrail data, Access Analyzer shows the pipeline uses exactly three S3 actions against one bucket. The refined policy names them, pins the ARNs (remember from lesson 1 that the bucket and the objects inside it are separate resources), and locks the whole thing to one region:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowSpecificS3Actions",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my-app-bucket",
        "arn:aws:s3:::my-app-bucket/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "us-east-1"
        }
      }
    }
  ]
}

Step 3: Add Conditions for Extra Security

A condition narrows the circumstances under which a statement applies at all, and conditions cost nothing to add. The charter treats them as free insurance:

Conditions stack. The statement below applies only when the caller has MFA, uses TLS, and comes from the office network, all at once:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "SecureS3Access",
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::sensitive-data/*",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true",
          "aws:SecureTransport": "true"
        },
        "IpAddress": {
          "aws:SourceIp": "10.0.0.0/8"
        }
      }
    }
  ]
}

The Rest of the Charter

Humans Sign In Through Federation

Trailbase is hiring, and Dana has no appetite for creating and offboarding an IAM user per person forever. Federation means letting a trusted external identity provider vouch for who someone is, so AWS never stores their password at all. IAM Identity Center (formerly AWS SSO) is the AWS service that manages this for a workforce.

Workloads Wear Roles

The EC2 photo-upload fleet set the pattern, and the charter extends it to every workload. Compute inside AWS gets a role attached directly; workloads outside AWS federate in instead of carrying exported keys.

MFA Guards the Privileged Paths

The first thing Dana ever did after the Theo incident was lock a hardware MFA device onto root. Multi-factor authentication requires a second proof of identity beyond the password, so a stolen credential alone opens nothing. The charter scales the requirement to the sensitivity of the identity:

You can enforce MFA in policy itself. This pattern allows everything only when MFA is present, while leaving a small unauthenticated path so users can see and manage their own MFA devices:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowAllActionsWithMFA",
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    },
    {
      "Sid": "AllowBasicActionsWithoutMFA",
      "Effect": "Allow",
      "Action": [
        "iam:GetAccountPasswordPolicy",
        "iam:ListMFADevices"
      ],
      "Resource": "*"
    }
  ]
}

Access Is Reviewed on a Calendar

Jordan's key survived 241 days because review was nobody's job. Permissions drift is silent: people change teams, projects end, and grants outlive their reasons. The charter makes review a scheduled event instead of a hope.

Boundaries Make Delegation Safe

Theo, older and wiser, now builds Lambda functions and needs to create IAM roles for them. Handing an intern iam:CreateRole sounds like the setup for a sequel, because anyone who can create roles can, in principle, create an admin role and assume it. That move is called privilege escalation: using the permissions you have to grant yourself permissions you were never given.

A permissions boundary closes the loophole. It is a managed policy attached to a user or role that sets the ceiling on what their identity-based policies can ever grant. The effective permissions are the intersection of the identity policy AND the boundary, and the boundary itself grants nothing on its own. Theo can create any role he likes for his functions, but with a boundary applied, none of those roles can touch IAM or Organizations.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowedServices",
      "Effect": "Allow",
      "Action": [
        "s3:*",
        "dynamodb:*",
        "lambda:*",
        "logs:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenyIAMChanges",
      "Effect": "Deny",
      "Action": [
        "iam:*",
        "organizations:*"
      ],
      "Resource": "*"
    }
  ]
}

How the Exam Asks About This

Every one of these charter rules maps onto a recurring SAA-C03 scenario shape. The question describes some company in Trailbase's old situation, and the right answer is the charter rule that fixes it:

Common Pitfalls

Quick Reference

aws:SourceIp              - Restrict by IP address/range
aws:MultiFactorAuthPresent - Require MFA
aws:SecureTransport       - Require HTTPS
aws:RequestedRegion       - Limit to specific regions
aws:PrincipalTag/*        - Attribute-based access control
aws:CurrentTime           - Time-based restrictions
aws:TokenIssueTime        - Credential age checks

Related Services

Further Reading

• Security Best Practices in IAM
• Grant Least Privilege Access - Well-Architected Framework
• Techniques for Writing Least Privilege IAM Policies
• IAM Access Analyzer User Guide