AWS Policies
AWS uses different types of policies to define and enforce security, access, and governance controls. Understanding these policies helps organizations maintain least privilege access, compliance, and multi-account security.
This guide explores all AWS Policy Types, their use cases, structure, applications, key characteristics, best practices, and common mistakes, using SecureCart as a case study.
AWS Policy Types Overview
AWS provides several policy types to control access and enforce security policies. These include
Policy Type
Purpose
What It Applies To
Use Case Example
IAM Policies (Identity-Based Policies)
Defines what actions IAM identities (users, roles, groups) can perform.
IAM Users, IAM Groups, IAM Roles
SecureCart’s developers need access to the S3 bucket containing logs but should not have the ability to delete any files.
Resource Policies
Controls access at the AWS resource level (e.g., S3, KMS, SNS).
AWS Resources (S3, KMS, SNS, Lambda, API Gateway)
SecureCart ensures that customer order data stored in S3 is only accessible by internal applications and not exposed publicly.
Permission Boundaries
Defines the maximum permissions an IAM identity can have.
IAM Users, IAM Roles
SecureCart enforces a permission boundary to ensure that developers cannot grant themselves admin-level permissions, even if they attempt to create a new role.
Service Control Policies (SCPs)
Restricts permissions across all AWS accounts in an Organization.
AWS Organizations Accounts, Organizational Units (OUs)
SecureCart prevents unauthorized modifications in production accounts by enforcing an SCP that blocks the deletion of security logs across all accounts.
Session Policies
Temporary policies applied during AWS STS AssumeRole sessions.
AWS Temporary Sessions (via STS)
SecureCart provides short-term access to third-party auditors to review security configurations without granting persistent permissions.
Access Control Lists (ACLs)
Controls network-based and object-level access.
S3 Objects, VPC Network Resources
SecureCart allows partner organizations to access specific product images stored in an S3 bucket without using IAM roles.
IAM Policies (Identity-Based Policies)
IAM Policies control who can perform specific actions on AWS services. These policies are assigned to IAM users, groups, and roles to provide the necessary permissions for accessing AWS resources while ensuring security through granular permissions.
Key Characteristics
Defines permissions for users, groups, and roles.
Uses JSON-based policy documents.
Can be managed (AWS provided) or custom (customer-created).
Use Case 1: SecureCart Developer Access
SecureCart developers require read-only access to application logs stored in an S3 bucket. To prevent unauthorized modifications or deletions, an IAM policy is attached to their IAM role, allowing only s3:GetObject and s3:ListBucket actions.
Use Case 2: SecureCart Database Administrator Permissions
Database administrators in SecureCart require full access to Amazon RDS for database management but should not have permissions to modify IAM roles. An IAM policy is used to enforce this restriction.
Best Practices
Follow the principle of least privilege.
Regularly audit and update policies.
Use AWS Managed Policies for common use cases.
Common Mistakes:
Granting
*permissions without restrictions.Not using IAM roles for temporary access.
Resource Policies
Resource Policies define who has access to a particular AWS resource and under what conditions. These policies are attached directly to AWS services like S3, KMS, and Lambda, enabling fine-grained access control.
Key Characteristics:
Attached directly to AWS resources.
Controls who can access a resource and under what conditions.
Supports cross-account access.
Key Elements
Effect →
AlloworDeny.Action → Specifies AWS API operations (e.g.,
s3:ListBucket).Resource → Defines which AWS resources the policy applies to.
Condition (Optional) → Adds conditions to the policy (e.g., allow access only from specific IPs).
Use Case 1: SecureCart S3 Public Restriction
To prevent data leakage, SecureCart enforces a resource policy on S3 buckets storing customer data. This policy ensures that only internal applications can access the data while denying all public access.
Use Case 2: Lambda Function Restricted S3 Access
SecureCart’s serverless functions running on AWS Lambda need access to specific S3 buckets. A resource policy is applied to ensure that only the Lambda execution role can access these objects, preventing unintended access from other services or accounts.
Best Practices:
Use IAM roles where possible instead of broad resource policies.
Enable S3 Block Public Access.
Common Mistakes:
Accidentally allowing public access.
Not restricting cross-account access properly.
Permission Boundaries
Permission Boundaries define the maximum permissions an IAM identity can be granted. They do not grant permissions themselves but restrict what an IAM user or role can receive through policies.
Key Characteristics:
Limits the maximum permissions an IAM identity can have.
Does not grant permissions, only restricts them.
Helps enforce company-wide security policies.
Use Case 1: Restricting Admin Privileges for Developers
SecureCart enforces a permission boundary ensuring that developers cannot create new IAM users or roles to elevate their own permissions, even if they have broad permissions.
Use Case 2: Limiting Junior Engineer IAM Permissions
To prevent misconfigurations, SecureCart ensures that junior engineers cannot create IAM users with higher privileges than their own assigned role, limiting their scope within the environment.
Best Practices:
Use permission boundaries to enforce security policies.
Combine them with IAM policies for stricter access control.
Common Mistakes:
Assuming permission boundaries grant access.
Not applying them consistently across roles.
Service Control Policies (SCPs)
Service Control Policies (SCPs) are used in AWS Organizations to manage permissions across multiple AWS accounts. SCPs do not grant permissions but define what actions are allowed or denied for IAM users and roles within an organization.
Key Characteristics:
Used to enforce security and compliance controls.
Does grant permissions but instead restrict actions that IAM Roles, IAM Users, and AWS Root Users can perform.
Applies at the AWS Organizations level, meaning they affect all IAM identities (users, roles, and groups) in an account.
Can be applied to AWS Accounts, Organizational Units (OUs), or the Root Organization.
Do not override IAM permissions, but they act as guardrails to prevent unauthorized actions.
Example 1: Blocking IAM User Creation in Production
SecureCart applies an SCP to all production accounts that blocks IAM User creation, ensuring that only IAM Roles are used for authentication.
Example 2: Restricting AWS Regions for Deployment
SecureCart applies an SCP to prevent developers from launching resources in unapproved AWS regions, ensuring compliance with internal policies.
Example 3 Deny Root User Access to All Accounts
Prevent security risks by ensuring the Root User cannot perform any action. Even if the Root User tries to create IAM Users or change policies, they are blocked
Example 4: Prevent Developers from Modifying IAM Policies
Developers should not modify IAM Roles or Policies, even if they have broad permissions. Developers cannot change IAM permissions, even if an IAM Role grants them access.
Example 5: Require All AWS Accounts to Enable Security Services
Ensure that AWS Security Hub, GuardDuty, and AWS Config remain enabled for compliance. No one can disable security monitoring in SecureCart AWS accounts.
Best Practices:
Apply SCPs at the Organizational Unit (OU) level.
Use SCPs for governance, not for granular access control.
Common Mistakes:
Creating overly restrictive SCPs that block required services.
Not structuring SCPs correctly.
Session Policies
Session Policies provide temporary permissions for IAM users or roles when using AWS STS (e.g., AssumeRole). These policies help enforce least privilege and time-bound access.
Key Characteristics
Applied dynamically when a session is created.
Does not persist beyond the session duration.
Used for fine-grained access control during temporary access.
Use Case 1: SecureCart Vendor Temporary Access
SecureCart allows third-party auditors to temporarily review compliance logs without granting long-term permissions. A session policy is applied to their AWS STS credentials to restrict access duration and scope.
Use Case 2: Temporary Elevated Permissions for Deployments
SecureCart developers require temporary elevated access to manage critical application deployments. A session policy is enforced to grant access for a limited time, reducing security risks.
Best Practices:
Use AWS STS for temporary access.
Apply least privilege to session policies.
Common Mistakes:
Assigning broad permissions to session policies.
Not defining session duration limits appropriately.
Access Control Lists (ACLs)
ACLs manage network-based and object-level permissions, primarily used for S3 objects and VPC traffic control. They provide a basic way to allow or deny access at the resource level.
Key Characteristics:
Controls inbound and outbound traffic at the subnet level.
Defines permissions for individual S3 objects.
Does not support granular IAM role-based access.
Use Case 1: SecureCart External Partner Access
SecureCart enables limited access for external partners to certain product images stored in an S3 bucket. Instead of creating IAM Roles, SecureCart uses S3 ACLs to grant read access to specific AWS accounts.
Use Case 2: SecureCart Network ACL Restrictions
To secure its VPC, SecureCart enforces strict network ACLs allowing only specific IP ranges to access application subnets, reducing the risk of unauthorized access.
Best Practices
Use IAM and Resource Policies instead of ACLs when possible.
Keep ACL rules simple and specific.
Common Mistakes
Overcomplicating ACL rules leading to unintended access.
Using ACLs instead of more scalable IAM Policies.
AWS uses different types of policies to define and enforce security, access, and governance controls. Understanding these policies helps organizations maintain least privilege access, compliance, and multi-account security.
This guide explores all AWS Policy Types, their use cases, structure, and best practices, using SecureCart as a case study.
Key AWS Policy Types
AWS provides several policy types to control access and enforce security policies. These include:
Policy Type
Purpose
What It Applies To
Use Case Example
IAM Policies (Identity-Based Policies)
Defines what actions IAM identities (users, roles, groups) can perform.
IAM Users, IAM Groups, IAM Roles
SecureCart’s developers need access to the S3 bucket containing logs but should not have the ability to delete any files. SecureCart’s database administrators should have full access to RDS but no ability to manage IAM roles.
Resource Policies
Controls access at the AWS resource level (e.g., S3, KMS, SNS).
AWS Resources (S3, KMS, SNS, Lambda, API Gateway)
SecureCart ensures that customer order data stored in S3 is only accessible by internal applications and not exposed publicly. SecureCart’s Lambda functions require access to specific S3 buckets while restricting access from external accounts.
Permission Boundaries
Defines the maximum permissions an IAM identity can have.
IAM Users, IAM Roles
SecureCart enforces a permission boundary to ensure that developers cannot grant themselves admin-level permissions, even if they attempt to create a new role. SecureCart ensures that junior engineers cannot create IAM users with higher privileges than their own assigned role.
Service Control Policies (SCPs)
Restricts permissions across all AWS accounts in an Organization.
AWS Organizations Accounts, Organizational Units (OUs)
SecureCart prevents unauthorized modifications in production accounts by enforcing an SCP that blocks the deletion of security logs across all accounts. SecureCart applies an SCP to prevent unapproved regions from being used in development and production environments.
Session Policies
Temporary policies applied during AWS STS AssumeRole sessions.
AWS Temporary Sessions (via STS)
SecureCart provides short-term access to third-party auditors to review security configurations without granting persistent permissions. SecureCart developers need temporary elevated access to specific services during deployments, with automatic expiration.
Access Control Lists (ACLs)
Controls network-based and object-level access.
S3 Objects, VPC Network Resources
SecureCart allows partner organizations to access specific product images stored in an S3 bucket without using IAM roles. SecureCart enforces strict network ACLs to allow only specific IP ranges to access VPC subnets.
Policy Type
Purpose
Where It Is Applied
Example
IAM Policies (Identity-Based Policies)
Grants permissions to IAM users, groups, or roles.
Attached to IAM Users, Groups, or Roles.
SecureCart's EC2 instance role allows access to S3.
Resource Policies
Controls who can access a specific AWS resource.
Attached directly to an AWS resource (e.g., S3 bucket, Lambda function, KMS key).
SecureCart allows only specific accounts to access an S3 bucket.
Permission Boundaries
Defines the maximum permissions an IAM User or Role can have.
Applied to IAM Roles and IAM Users.
SecureCart developers can only create resources within a defined boundary.
Service Control Policies (SCPs)
Restricts permissions across multiple AWS accounts in an Organization.
Applied at the AWS Organizations level.
SecureCart prevents root users from disabling CloudTrail.
Session Policies
Temporary policies applied during an AWS session.
Used in STS AssumeRole calls.
SecureCart applies fine-grained permissions to temporary session tokens.
Access Control Lists (ACLs)
Grants permissions at the object level in S3 or networking resources.
Applied at the S3 bucket object level and VPC networking (NACLs).
SecureCart allows a specific AWS account to access certain objects in an S3 bucket.
IAM and Resource Policies are the core of access control in AWS. They define who can access AWS resources, what actions they can perform, and under what conditions.
Managing IAM Policies and Resource Policies ensures
Least Privilege Access – Users and applications only get the permissions they need.
Security Compliance – Prevents unauthorized access to sensitive AWS resources.
Multi-Account Security – Controls access across AWS Organizations and accounts.
Granular Access Control – IAM Policies define permissions at the identity level, while Resource Policies secure specific resources.
Key Elements Explained:
Effect →
AlloworDeny.Action → Specifies AWS API operations (e.g.,
s3:ListBucket).Resource → Defines which AWS resources the policy applies to.
Condition (Optional) → Adds conditions to the policy (e.g., allow access only from specific IPs).
Best Practices for IAM Policies
Use IAM Roles instead of IAM Users for permissions.
Follow least privilege by granting only necessary permissions.
Use AWS Managed Policies when possible.
Enable IAM Access Analyzer to detect overly permissive policies.
Section 5: Common IAM Policy Mistakes & Fixes
Common Mistake
Best Practice
❌ Using * in Action & Resource
✅ Follow least privilege principle by specifying only necessary actions/resources.
❌ Assigning policies to IAM Users directly
✅ Use IAM Roles instead for better security.
❌ Not enforcing encryption in resource policies
✅ Enforce KMS encryption on S3, DynamoDB, and EBS volumes.
❌ Using overly permissive wildcard (*) in SCPs
✅ Define specific restrictions in SCPs instead of broad denies.
📌 Hands-On Lab: Implement IAM & Resource Policies for SecureCart
🎯 Goal: ✅ Create an IAM Role with an IAM Policy to allow access to S3. ✅ Attach a Resource Policy to an S3 bucket to restrict access. ✅ Use SCPs to enforce security controls across AWS Organizations.
📌 Summary
Concept
AWS Service
Best Practice
Identity-Based Policies
AWS IAM Policies
Assign policies to IAM Roles instead of IAM Users.
Resource-Based Policies
S3, KMS, Lambda Policies
Restrict access directly at the resource level.
Permission Boundaries
IAM Permission Boundaries
Control max permissions for IAM Users/Roles.
SCPs
AWS Organizations
Restrict actions across all accounts.
✅ Following these best practices ensures that SecureCart applications remain secure and compliant.
SecureCart Use Case: Managing IAM Policies and Resource Policies
Business Context
SecureCart is an e-commerce platform that processes customer orders, manages inventory, and handles sensitive payment information. To protect its infrastructure, SecureCart must implement strict identity and access controls using IAM Policies and Resource Policies while ensuring compliance with security best practices.
📌 Security Challenges for SecureCart
🔹 Protect customer data and prevent unauthorized access to AWS resources. 🔹 Ensure developers and services have only the required permissions (least privilege). 🔹 Prevent accidental exposure of AWS resources (e.g., public S3 buckets, excessive IAM permissions). 🔹 Restrict access to production environments while allowing flexibility in development and testing. 🔹 Ensure compliance with internal security policies and industry regulations.
📌 How SecureCart Uses IAM Policies & Resource Policies
Requirement
Solution
SecureCart Implementation
Limit developer access to specific resources
IAM Policies (Identity-Based)
Developers have an IAM Role with restricted S3 access (no delete permissions).
Prevent unauthorized API calls to AWS services
IAM Role Policies
Lambda functions are assigned an IAM Role with least privilege instead of using static credentials.
Secure access to production vs. dev environments
IAM Policies + Permission Boundaries
SecureCart applies IAM Policies restricting access to production accounts.
Prevent S3 buckets from being publicly accessible
S3 Bucket Resource Policy
A Resource Policy denies all public access unless explicitly granted.
Ensure only SecureCart’s AWS accounts access sensitive data
S3 and KMS Resource Policies
SecureCart’s S3 and KMS keys only allow access from whitelisted accounts.
Restrict what AWS services teams can use
Service Control Policies (SCPs)
SCPs prevent non-compliant actions, such as launching unapproved instance types.
📌 IAM Policy Use Case: Least Privilege for Developers
SecureCart wants to ensure that developers can access logs but cannot delete them.
✅ IAM Role Policy for Developers (Allows Read-Only Access to Logs, No Deletion)
📌 Impact: Developers can view and retrieve logs, but they cannot delete logs, preventing accidental loss of critical data.
📌 Resource Policy Use Case: Restricting S3 Bucket Access
SecureCart stores customer invoices in an S3 bucket and needs to prevent unauthorized external access.
✅ S3 Bucket Policy to Block Public Access & Require IAM Authentication
📌 Impact: ✅ Blocks all unauthenticated users from accessing the bucket. ✅ Forces the use of HTTPS for secure data transmission.
📌 SCP Use Case: Preventing IAM User Creation in Production
SecureCart wants to enforce a rule that prevents IAM Users from being created in the production environment.
✅ SCP Applied at AWS Organization Level (Denies IAM User Creation in Production Accounts)
📌 Impact: ✅ Prevents SecureCart’s AWS accounts from allowing IAM Users, enforcing best practices of using IAM Roles instead.
📌 Key Takeaways for SecureCart
🔹 IAM Policies control what actions users and roles can perform. 🔹 Resource Policies restrict who can access specific AWS resources. 🔹 SCPs enforce security policies across SecureCart’s AWS Organizations. 🔹 SecureCart applies least privilege principles to minimize security risks
Last updated