Least privilege

Least privilege is an authorization design principle: an identity should be able to perform its intended work without receiving unrelated capabilities. Effective access is constrained by actions, resources, conditions, and time. For example, an application that reads invoices should receive permission to read objects under the required storage prefix, not permission to delete objects, modify bucket policies, or access every bucket. Authentication establishes who is requesting access; authorization determines whether that identity may perform a particular operation.

Start with documented access requirements and separate responsibilities into distinct roles. Scope permissions to supported resource identifiers and use conditions where they meaningfully restrict access, such as approved organization membership, resource tags, or a required network endpoint. Some API actions do not support resource-level permissions and therefore require a wildcard resource. In those cases, restrict the action set and use supported conditions rather than assuming that every wildcard is avoidable. Test both required operations and operations that must be denied.

Cloud permissions must be evaluated across all applicable policy types, not just the policy attached to a user or role. In AWS, identity policies, resource policies, role trust policies, permissions boundaries, session policies, and organization policies can influence the result. Explicit denies in applicable policies override allows. Permissions boundaries and session policies limit permissions rather than independently granting them. However, resource-based grants can behave differently depending on whether they target a user, role, or role session, so policy evaluation is not always a simple intersection of every policy. Investigating unintended access requires examining the actual principal, request context, and grant path.

Prefer temporary credentials over embedded long-lived access keys. AWS STS issues credentials for an assumed role, with permissions constrained by the role and any applicable session policy. A short session lifetime reduces the exposure window but does not make an overprivileged role safe. Amazon S3 presigned URLs delegate a particular signed request, such as downloading a specific object, and should use an appropriately limited signer and expiration. They are bearer capabilities: anyone possessing a valid URL can use it. A URL signed with temporary credentials cannot remain valid beyond those credentials, and applicable policy changes can also prevent access.

Compute workloads should obtain credentials through dedicated workload identities. An EC2 instance profile supplies a role to an instance; a Lambda execution role authorizes function code; a service role allows an AWS service to act on a customer's behalf. These mechanisms are not interchangeable, and each needs an appropriately restricted trust policy and permissions policy. For example, deployment permissions should be separate from runtime permissions. Restrict iam:PassRole to approved roles and intended services so that a developer cannot attach a more powerful role to a workload and indirectly escalate privileges.

Administrative access needs both identity and network controls. AWS Systems Manager Session Manager can provide role-controlled access without opening inbound SSH or RDP ports, but requires suitable instance permissions and connectivity to the service. Limit who can start sessions, which managed nodes they can target, and which session documents they can use. Configure logging where supported; SSH and port-forwarding sessions do not provide the same command visibility as standard shell sessions. EC2 Instance Connect provides temporary SSH-key delivery, but does not eliminate the need to restrict SSH reachability, operating-system users, and host-level privileges.

Apply least privilege to network paths as well as API calls. Permit only the necessary source, destination, protocol, and port combinations, and review unnecessary ingress and egress. VPC Network Access Analyzer can identify network paths that violate defined access requirements. AWS Verified Access can enforce identity- and device-context policies for supported applications without broadly exposing the surrounding network. Evaluate network exposure alongside Amazon Inspector workload findings, while recognizing that reachability, vulnerability assessment, and application authorization answer different questions.

At the network edge, restrict direct origin access and validate requests at the appropriate layer. CloudFront origin access control can authorize access to a private S3 origin; configured headers and origin checks can support other origin-protection designs. AWS WAF rules help filter malicious requests, including patterns associated with OWASP Top 10 threats, but are not a substitute for application authorization. S3 CORS controls browser cross-origin behavior and does not grant object permissions or protect an otherwise public bucket. AWS IoT policies should limit devices to required operations and topic resources. Shield Advanced provides DDoS protections and response capabilities, not identity authorization.

Use organization-level controls to prevent local administrators from exceeding centrally defined limits. AWS Organizations service control policies constrain supported permissions for principals in member accounts, while resource control policies constrain access to supported resources. Neither policy type independently grants access. Understand their coverage and exceptions rather than treating them as universal controls. AI services opt-out policies address the use of content for AI service improvement, and declarative policies govern supported service configurations; these are distinct from IAM permission grants.

Prepare incident access before an incident occurs. Provision and test narrowly scoped response roles for evidence collection, containment, and recovery, separating disruptive actions from routine investigation. Avoid permanent administrator access merely to make response easier. Time-bounded elevation, protected approval paths, and audited break-glass procedures preserve response speed while limiting blast radius. Protect root access with appropriate MFA and tightly controlled recovery processes. Where centralized root access is enabled for AWS member accounts, remove unnecessary member-account root credentials and use supported, task-scoped privileged root sessions instead of retaining standing root access.

Least privilege is an iterative process, not a one-time policy-writing exercise. IAM Access Analyzer can identify external access, analyze supported internal access, detect unused access, validate policies, and generate policy suggestions from supported activity. An external-access finding describes a policy-enabled access path, not proof that someone used it. Review findings against intended sharing and remediate unnecessary grants. Activity-derived policies are useful starting points, but observation windows may miss rare maintenance and recovery operations. Combine analysis, access logs, owner review, and regression tests. The trade-off is additional policy maintenance and occasional access failures; manage this through reusable role patterns and controlled escalation rather than broad permanent permissions.