KSI-IAM-ELPEnsuring Least Privilege

Assert mfa_active=true for every password_enabled=true principal, and (now - access_key_N_last_rotated) <= 90d for every active key. generate-credential-report is async; poll get-credential-report until State=COMPLETE (report is regenerated at most every 4 hours). mfa_active is TRUE for a virtual TOTP device as well as a FIDO key, and the CSV covers IAM users and the root user only — a human confirms from the identity provider's own report that console authentication is phishing-resistant (the IA-02 (01)/(02) guidance) and that federated Identity Center or external-IdP sign-ins are covered elsewhere. The 90-day threshold is CIS Benchmark 1.14's, not FedRAMP's. Filed under IA-02 and IA-05 base: key age tests IA-05 (g), not AC-02 (01)'s automated account management or IA-05 (01)'s password rules.

The API fully enumerates entitlements (telemetry), but deciding whether a given permission set is 'least privilege' requires human judgement against a documented access baseline. Reviewers should diff this snapshot against the last approved baseline and justify deltas.

Use list-findings-v2 (list-findings is external-access only and does not return unused-access findings). Requires an existing ACCOUNT_UNUSED_ACCESS analyzer; create one with create-analyzer --type ACCOUNT_UNUSED_ACCESS --configuration '{"unusedAccess":{"unusedAccessAge":90}}'. Target zero ACTIVE unused-permission findings for privileged roles. An empty findings list is meaningful only if an analyzer exists, is ACTIVE, and its unusedAccessAge equals the review period the SSP declares; entities younger than the tracking period, and principals or accounts excluded by tag, never appear as findings. UnusedPermission findings are computed for roles, so IAM users' unused permissions are outside this output, and AC-06 (07)(a)'s periodic review is a human record — which is why this is partial.

Scope caveat: this rule evaluates only customer-managed policies, not inline or AWS-managed policies. Combine with iam-account-authorization-details review to cover inline policies and admin AWS-managed policy attachments (e.g. AdministratorAccess). A human closes that gap by reading iam-account-authorization-details, which is why this is partial; and nothing in the output records the explicit authorizations AC-06 (01) asks for or partitions privileged from non-privileged users as AC-06 (10) does, so neither enhancement is claimed.

The commands split cleanly across the control family, and the gap in the middle is the one to be honest about. AC-17(1) — automated monitoring and control of remote access — is what session history and connection logs deliver, with two documented blind spots. Session Manager does not log sessions that connect through port forwarding or SSH, because SSH encrypts the session data inside the TLS connection and Session Manager is only the tunnel; an operator who port-forwards leaves a session record with no command content behind it. And describe-sessions reaches back 30 days only, so anything longer is an S3 or CloudWatch Logs query against the destinations named in the preferences document, not an SSM call. Client VPN retention is shorter still — terminated connections drop out of the API after 60 minutes, which makes the log group named in ConnectionLogOptions the only durable record, and Username is populated only for Active Directory authentication, so certificate-authenticated users are identified by CommonName or not at all. AC-17(2) is the strongest link in GovCloud, where the endpoints are FIPS 140-3 modules by construction; the Session Manager equivalent is kmsKeyId in the preferences document, and it is empty unless you set it, so an empty kmsKeyId is a finding rather than a default. AC-17(3) — routing remote access through managed network access control points — is the one nothing here proves. Session Manager and a Client VPN endpoint are managed access points, and ec2-instance-no-public-ip is the closest negative check, but that rule applies only to IPv4 and only to AWS::EC2::Instance: an IPv6-reachable instance, a load balancer fronting SSH, or a third-party jump host is invisible to it. Read the result as 'no EC2 instance carries a public IPv4 address', which is a useful sentence and not the control. AC-17 itself — the documented usage restrictions, configuration requirements and per-type authorization — is a record you write, and this telemetry only shows whether the estate matches it. One warning to carry into the evidence package: Session Manager logs the commands entered and their output, so a credential typed into a session lands in the log group you are about to hand an assessor.

This enumerates the authentication paths and closes the credentials that belong to nobody. What it cannot do is the word IA-02 turns on: unique. No API reports that an IAM user is one named human rather than a login three engineers share, or that a federated subject maps one-to-one onto a person on the roster — that binding lives in the personnel record and the joiner/mover/leaver process, and a reviewer establishes it by joining this output against the account inventory (see the AC-02 account-authorization-details recipe), not by reading this output alone. Rated partial for that reason: the authentication half is decided here outright, the identification half is not. Providers counts SAML and OIDC providers together, so the two list calls are what tell you which is which. An account with Users at 0 and one Identity Center instance is the strong shape — no standing workforce credentials at all — and an account with both is the one worth explaining. Substitute nothing here: every command runs as written. The two AWS Config rules are periodic and evaluate global IAM resource types, so deploy them in exactly one Region; adding them in several does not add coverage and does add duplicate evaluations.

IA-11 asks for re-authentication under organization-defined circumstances. Only one of those circumstances — elapsed time — is in any of these outputs, and even that arrives as a ceiling rather than as an event: MaxSessionDuration caps what a caller may request, it does not report that a session ended or that a human presented an authenticator again. The other circumstances FedRAMP expects an organization to name — a change of role, a change of authenticator, before executing a privileged function, after a defined idle period — have no field here at all. Deciding whether the configured ceilings match the documented circumstances is the human judgement, which is why this is partial and not full. Two scope gaps worth writing into the assessment rather than discovering later. A console session reached through an external identity provider ends on that provider's session policy, and no AWS API reports it: the IdP's own configuration is the artifact. And aws:MultiFactorAuthAge is absent from the request context for federated identities and for requests signed with long-term access keys, so a policy that expires an MFA session governs exactly the principals using temporary MFA-backed credentials and silently governs nobody else — pair it with BoolIfExists on aws:MultiFactorAuthPresent so the not-present case denies rather than passes. A role left at the 3600-second default is not evidence of a decision; a role at 43200 is a decision someone should have written down. Read the distribution, not the extremes. Substitute the instance and permission-set ARNs, which the two list calls supply.

AC-20 is a two-limb control and only one limb is in this output. The limb that is here: which external entities can reach organization-controlled information. Access Analyzer answers that by logic-based reasoning over resource-based policies, and every access by a principal INSIDE the zone of trust is trusted by definition, so a finding is exactly an access that crosses the boundary the organization declared. The limb that is not here: whether each of those crossings is covered by terms and conditions consistent with the trust relationship. That is an agreement — a contract, an interconnection security agreement, an authorization to connect — and no call returns it. Attach the agreement register and reconcile it finding by finding; the reconciliation, not the finding list, is the AC-20 artifact. The inventory also has a direction. Access Analyzer sees resources you share OUT. It does not see an external system your people use to process organization information — a SaaS tool reached from a workstation leaves no resource policy in your account and produces no finding. That half of AC-20 has to come from your own third-party register, and inventing a join between the two would make the coverage claim wider than the evidence. Three scope facts worth pinning down before the count is quoted. External-access analysis is REGIONAL: an analyzer evaluates only resources in the Region where it is enabled, so one analyzer per Region in use, or the inventory is silently partial. Fifteen resource types are analyzed for external access — S3 buckets and directory buckets, IAM roles, KMS keys, Lambda functions and layers, SQS queues, Secrets Manager secrets, SNS topics, EBS volume snapshots, RDS DB and DB cluster snapshots, ECR repositories, EFS file systems, DynamoDB streams and tables — and a resource type outside that list is not covered by the analyzer at all. And findings refresh within about 30 minutes of a policy change but can lag up to 24 hours when a change notification is missed, so a finding list is a recent state, not a live one.

IA-04 is four verbs — receive authorization for an identifier, select it, assign it to the intended party, and prevent its reuse for a defined period. AWS proves the third completely, gives real but bounded evidence for the fourth, and returns nothing at all for the first two. Assignment is the easy half and it is genuinely complete: every identifier in the account is enumerable with the date it was assigned and the AWS-generated unique id behind it. Selection and authorization are records about a decision, not about a resource, and no call returns them. Reuse is where this control is usually mis-evidenced, and AWS's own documentation is unusually direct about why. Within an account a friendly name for a user, group, role or policy must be unique — but only while it exists. AWS documents the exact failure IA-04's reuse clause exists to prevent: an employee named John leaves, the IAM user John is deleted, a new employee named John arrives, a new IAM user John is created, and a policy written against the friendly name grants the new John access to what the old John left behind. Nothing in AWS prevents that. There is no cooling-off period, no reserved-name list, no setting. What AWS guarantees instead is narrower and worth reading precisely: the unique id is never reused, so the old John's AIDA... and the new John's AIDA... differ, and a resource-based policy or an aws:userId condition written against the unique id cannot be inherited by a successor. The identifier that is protected from reuse is the one nobody uses in policy by default. So the honest evidence for the reuse limb is a comparison, not a field: DeleteUser events dated against the CreateDate of a live identifier bearing the same name — UserDetailList[].CreateDate is collected here and is the right side of that comparison, which is why no CreateUser lookup is listed. Note what to read on the left side: Username on a lookup-events entry is the REQUESTER, the administrator who ran the deletion, so the deleted identifier has to come out of the CloudTrailEvent JSON at requestParameters.userName. Reading Username as the deleted name is the easy mistake and it produces a comparison against the wrong string entirely. Three limits on the comparison, all hard. lookup-events reads management events for the last 90 DAYS only, so any reuse period your SSP states beyond 90 days cannot be evidenced from this call at all — a CloudTrail Lake event data store or an S3 trail with a longer retention is what closes that, and it is a different collection. The call is also Region-bound in a way that has nothing to do with GovCloud: IAM is a global service, its events are recorded in one Region, and lookup-events shows them in the Region where they occurred — so the same command run anywhere else returns an empty Events[] while succeeding, which is indistinguishable from a window in which nobody was deleted. And the comparison itself is a join between two commands' outputs, which the assertion grammar cannot express: it compares a field to a constant, never one response to another. Both of those are why the reuse limb is written into the notes as a manual reconciliation rather than dressed up as a clause below. The IAM users this recipe enumerates are also, on a well-run estate, the smallest part of the answer. Workforce identifiers should be issued in an external identity provider and reach AWS through IAM Identity Center, where the identifier's authority is the ExternalIds pair naming the issuer — which is what the third call reads. An account with an empty UserDetailList and a populated identity store is in better shape than the reverse, and an assertion that ranges over IAM users will say almost nothing about it. Read the two together or read neither. The identity-store calls are collected as EVIDENCE and deliberately carry no assertion. An earlier draft asserted that an Identity Center instance exists and that every identity-store user carries ExternalIds; both were withdrawn, because they fail an account that federates through an IAM SAML provider instead — which is a different architecture, not an IA-04 defect — and because the second is vacuous anyway on an instance with zero users, so the first does not guard it. An assertion that encodes an architectural preference as a control failure is worse than a paragraph saying which architecture this evidence reads best. Emptiness traps to state rather than assert. list-instances returns a list whose documented minimum length is zero and whose maximum is ten, so an account with no instance returns an empty Instances[] rather than an error, and reading only the first entry misses up to nine. A DeleteUser lookup over a window in which nobody was deleted returns an empty Events[], indistinguishable from a window in which the trail was not recording. And GroupDetail carries no Tags, so the authorization-tag clause below cannot be extended to group identifiers at all; device and service identifiers are outside every call here. Roles and groups are collected alongside users because their names are identifiers the control covers, and because the same reuse behaviour applies: RoleId and GroupId are never reused, while RoleName and GroupName are free the moment the resource is deleted.

PS-04 is a list of things that happen when someone leaves: disable system access within a defined period, revoke the authenticators, conduct an exit interview, retrieve organizational property, retain access to the information the person worked on, and notify named personnel within a period. AWS holds evidence for the first two and nothing whatever for the other four. And it holds those two only as state and history, never as subject. The credential report says every credential in the account and what shape it is in; CloudTrail says which revocation happened, when, and by which administrator. Five lookups rather than two, because lookup-events takes one lookup attribute per call and revocation is not one API: an estate that follows this recipe's own advice and DISABLES rather than deletes never emits DeleteUser at all, so a collection that watched only for deletions would return an empty Events[] on a correctly executed separation. UpdateAccessKey is in the list for the same reason — setting a key Inactive is a revocation that deletes nothing. What no call knows is that a PERSON was terminated. There is no roster in AWS, no employment status, no separation date — so the join between 'this human left on the 4th' and 'this identity was revoked on the 6th' is made by a human against an HR record, and the period the control defines is checked on that join and not here. This recipe produces the AWS-side column. It is partial for that reason and no assertion below pretends otherwise. That is also why there is exactly one assertion. Any clause of the form 'no user has an active credential' is false on every working account and would be answering about the whole population when the control is about a named few; a clause over 'users your tagging marks as separated' would invent a third tagging convention to answer a question the HR record already answers better. So the single assertion is about the EVIDENCE rather than the estate: that the report describes a recent moment. A credential report is a snapshot with a timestamp, and a stale one is a true statement about a past that has already been superseded. Read the four-hour rule as a collection constraint, not a detail. AWS stores one credential report per account and regenerates it at most once every four hours; a generate call inside that window returns the report you already had. So generate-then-get does not guarantee freshness, GeneratedTime is what does, and a collector that runs the two calls back to back and assumes the second reflects the first is reporting on a state up to four hours old. The report's coverage is narrower than its name suggests, and the gap is exactly where a separation goes wrong. AWS documents it as covering passwords, the first two access keys per user, MFA devices and X.509 signing certificates. A third access key is not in it. Service-specific credentials are not in it. A separated user whose remaining access is a CodeCommit password or a long-term service credential appears in this report as fully revoked. additional_credentials_info is the only signal that anything else exists, and closing that gap needs ListAccessKeys and ListServiceSpecificCredentials per user, which this recipe does not collect and an assessment should. On a well-run estate the IAM half is the small half. Workforce identities live in the identity store and a separation there is UserStatus DISABLED rather than a deletion, which is why the third call is collected: an account whose credential report lists no IAM user for a departed employee, while the identity store still lists them as ENABLED, has not revoked anything — and the credential report, which sees only IAM, cannot show it. Disabling rather than deleting is also the better practice for this control, because it preserves the identifier — see the IA-04 recipe on why a freed name is a hazard. One KSI was deliberately not claimed. KSI-IAM-SUS asks that privileged accounts be disabled or secured IN RESPONSE TO SUSPICIOUS ACTIVITY, and a routine separation is not suspicious activity; the output is identical in both cases and cannot tell an assessor which one it is looking at. KSI-IAM-JIT was dropped for a quieter reason. Its statement asks for a least-privileged, role and attribute-based, and JUST-IN-TIME authorization model, persistently reviewed. Nothing in five commands over STANDING credentials evaluates a just-in-time or attribute-based model; only the 'persistently reviewed' tail is touched, and that tail is already what KSI-IAM-ELP carries here. KSI-IAM-ELP is earned outright: an identity that outlives its holder is precisely a failure of the rule that each user can access only what they need.

PS-05 is about a person moving inside the organization: the access that fitted the old role is reviewed, what is no longer needed is removed, and the transfer is completed within a period the provider defines. AWS holds two-thirds of that and cannot hold the rest. What it holds is the CHANGE and the STATE. CloudTrail records the six APIs a reassignment actually travels through — two for group membership, two for attached user policies, two for Identity Center account assignments — each with a timestamp and the administrator who made it. Identity Center holds the assignments as they stand today. What no call knows is that a person MOVED. There is no roster in AWS, no job title, no transfer date, so the join between 'this human changed teams on the 4th' and 'this principal lost the finance permission set on the 9th' is made by a human against an HR record, and the period the control defines is checked on that join. This recipe produces the AWS-side column and the rating says so. The third call set is the one that earns its place. A separation is visible as an absence; a transfer is visible as a RESIDUE — the old permission that nobody removed because nothing failed when it stayed. Service-last-accessed is the signal that names it per principal: for a principal it lists every service the identity could reach under its permissions policies, with the last time it authenticated, and an entry with no LastAuthenticated is a permission granted and never exercised. Run against the transferred principal it turns 'review the access that no longer fits' from an interview into a list. It is not the only route to that question — `iam-access-analyzer-unused-access` answers it estate-wide from findings — but it is the one that answers it about a NAMED identity, which is the unit a transfer is measured in. Read its four documented limits before quoting it. It reports for at least the last 400 days, and less in a Region that began supporting the feature within the last year — so a young Region reports a shorter history than the reviewer assumes. Recent activity usually appears within four hours, so a report pulled immediately after a transfer describes the state before it. It records ATTEMPTS and not successes: a denied call still marks a service as accessed, and AWS names CloudTrail as the authoritative source for whether a call succeeded. And it applies permissions-policy logic ONLY — resource-based policies, ACLs, Organizations policies, permissions boundaries and STS assume-role trust are all excluded, so an identity that reaches a bucket purely through a bucket policy is invisible to it. That last one bounds the whole claim: 'no unused permissions' from this report is a statement about identity policies, not about reach. list-account-assignments takes an account id AND a permission set ARN, and returns the assignees of that one pair. There is no call that returns an account's assignments whole, which is why list-permission-sets runs first and the collection is a loop. A single unlooped call would be a slice of one permission set presented as an account's access, and an assertion over it would be green on an estate where every other permission set is wrong. The authentication indicators are untouched here — nothing collected reads a factor. KSI-IAM-ELP is earned outright: a permission that fits a role the holder has left is exactly the failure of 'each user can access only what they need'. KSI-IAM-JIT is deliberately NOT claimed, on this overlay's own precedent: the PS-04 recipe dropped it because nothing evaluated over STANDING credentials examines a just-in-time or attribute-based model, and only the 'persistently reviewed' tail is touched — a tail KSI-IAM-ELP already carries. Everything collected here is standing too: standing credentials, standing group membership, standing account assignments. The just-in-time half is the Identity Center elevation recipe's to answer, and claiming it here would have had two sibling recipes taking opposite positions on one indicator over one class of telemetry.