Designing Policies for Least Privilege Access

This guide covers the core strategies for implementing the principle of least privilege (PoLP) within a multi-account AWS environment. It focuses on the intersection of Service Control Policies (SCPs), IAM Policies, and Permission Boundaries to create a robust security posture.

Learning Objectives

By the end of this guide, you should be able to:

• Explain the evaluation logic between SCPs, IAM policies, and Permission Boundaries.
• Design Service Control Policies (SCPs) to act as organizational guardrails.
• Differentiate between Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC).
• Implement Permission Boundaries to delegate IAM administration safely.

Key Terms & Glossary

• Least Privilege: The practice of limiting access rights for users to the bare minimum permissions they need to perform their work.
• Service Control Policy (SCP): A type of organization policy used to manage permissions in your organization, acting as a filter for what actions are possible.
• Permission Boundary: A managed policy used to set the maximum permissions that an identity-based policy can grant to an IAM entity.
• Principal: An entity in AWS that can perform actions and access resources (e.g., a User or Role).
• Implicit Deny: The default state where every request is denied unless an explicit Allow is present.
• Explicit Deny: A policy statement that specifically denies an action; it always overrides any Allow.

The "Big Idea"

In a modern DevOps environment, security cannot be managed manually at the user level. Instead, security is implemented as Defense in Depth. Think of it as a series of filters: SCPs define the "maximum possible" permissions for an account, Permission Boundaries define the "maximum allowed" for a specific role, and IAM Policies grant the "actual" permissions. Access is only granted where all these layers overlap.

Policy Evaluation & Logic Box

Hierarchical Outline

1. Organizational Guardrails (SCPs)
   • Whitelist Approach: Deny all, then explicitly allow specific services.
   • Blacklist Approach: Allow all, then explicitly deny sensitive actions (e.g., StopLogging).
2. Identity-Based Controls
   • RBAC: Access based on job function (e.g., "Developer" role).
   • ABAC: Access based on tags (e.g., "Access if Principal.Project == Resource.Project").
3. Delegation Controls
   • Permission Boundaries: Prevent "privilege escalation" when developers create their own roles.
4. Resource-Based Policies
   • Attached directly to resources (S3 buckets, KMS keys).
   • Can allow cross-account access.

Visual Anchors

Policy Evaluation Flow

Permission Intersection

Definition-Example Pairs

• Service Control Policy (SCP)
  • Definition: A policy that sets the maximum available permissions for all accounts in an OU.
  • Example: A policy that prevents any account in the "Production" OU from deleting S3 buckets, regardless of what the Admin user within that account tries to do.
• Attribute-Based Access Control (ABAC)
  • Definition: Defining permissions based on attributes (tags) rather than static roles.
  • Example: A developer can only start/stop EC2 instances where the tag Environment matches their own user tag Team.

Worked Examples

Example 1: Preventing Shadow IT with SCPs

Scenario: You want to ensure that developers in a specific OU only use us-east-1 and us-west-2 to control costs.

Solution (SCP):

Note: Global services like IAM must be excluded from the regional deny.

Example 2: Using Permission Boundaries

Scenario: You allow a Junior Admin to create IAM Roles for Lambda functions, but you want to ensure they cannot create a Role with AdministratorAccess.

Solution:

1. Create a "Boundary Policy" that only allows S3 and CloudWatch Logs.
2. In the Junior Admin's IAM policy, use a condition that requires the PermissionsBoundary parameter to be attached to any CreateRole call.

Checkpoint Questions

1. If an SCP allows s3:* but an IAM Policy has no statement regarding S3, is access granted? (Answer: No, it is an implicit deny).
2. Which policy type takes precedence: an IAM Explicit Deny or an SCP Explicit Allow? (Answer: IAM Explicit Deny; any Deny always wins).
3. Does an SCP affect the Management Account of an organization? (Answer: No, SCPs do not restrict the management account principal).

Muddy Points & Cross-Refs

• SCPs vs. IAM: A common confusion is thinking SCPs grant access. They do not. Even if an SCP says Allow *, the user still needs an IAM policy to do anything.
• Resource-Based Policies: These are unique because they can grant access even if an IAM Policy doesn't (as long as no Deny exists). However, they cannot bypass an SCP deny.
• Cross-Ref: For further reading on account automation, see "AWS Control Tower and Guardrails."

Comparison Tables