Full Report
In the previous post in this series, we discussed how to do some basic cleaning of AWS access keys. In this post, we’ll show how to reduce the privileges in order to mitigate their risk.
Analysis Summary
# Best Practices: Reducing Risks Associated with AWS Access Keys via IAM Policy Tightening
## Overview
These practices focus on reducing the security risks associated with AWS access keys (and IAM principals in general) by implementing the principle of least privilege through rigorous refinement and restriction of IAM policies. This serves as an intermediate step before transitioning principals off access keys entirely.
## Key Recommendations
### Immediate Actions
1. **Identify High-Impact Keys:** Audit all existing IAM users/roles with access keys to pinpoint those with excessively broad permissions (e.g., those attached to `AdministrativeAccess` policy).
2. **Identify High-Risk Access Paths:** Flag keys that reside in sensitive accounts or grant access to critical/sensitive data stores.
3. **Restrict Privilege Escalation and Discovery:** Immediately review policies for actions in the `iam` or `sts` services and remove them if they grant potential privilege escalation capabilities.
4. **Remove Resource Listing Privileges:** If feasible, remove broad listing permissions (e.g., `s3:ListAllMyBuckets`) to obscure the resource landscape from a potential attacker, even if read/write access remains.
### Short-term Improvements (1-3 months)
1. **Apply Service-Level Least Privilege:** Use **IAM Access Advisor** data to downgrade broad service permissions (e.g., change a principal with `AdministratorAccess` to only have `s3:*` permissions if S3 access is the only known requirement).
2. **Generate Action-Level Policies:** Utilize the **Access Analyzer policy generator** to create granular policies based on observed CloudTrail activity, ensuring specific actions are allowed rather than broad service wildcards (`s3:*`).
3. **Implement Source IP Restrictions (Cautiously):** Apply conditional restrictions based on `aws:SourceIp` where the source IP is static and reliable to limit network exposure of key usage. **Prefer VPC endpoints over IP restrictions if possible.**
### Long-term Strategy (3+ months)
1. **Resource-Level Policy Definition:** Manually review CloudTrail logs or application source code to define policies scoped to individual, necessary resources (e.g., specific S3 bucket ARNs) instead of resource wildcards.
2. **Proxy Sensitive Access:** Re-architect workflows requiring high-privilege keys (e.g., access to a sensitive S3 bucket) by routing operations through an intermediary service (like an AWS Lambda function utilizing **S3 Object Lambdas**). This proxy can enforce rate-limiting, geo-IP checks, and data redaction/tokenization.
3. **Isolate Key-Dependent Functionality:** For use cases requiring long-lived access keys (e.g., generating multi-day S3 pre-signed URLs), isolate that specific functionality into a dedicated, narrowly-scoped microservice. Its primary application should only interact with this isolated microservice.
## Implementation Guidance
### For Small Organizations
- Focus initial efforts on identifying and removing `AdministrativeAccess` policies from any identity associated with an access key.
- Prioritize using the IAM Access Advisor to quickly move from service-level wildcards (`*`) to specific service permissions (e.g., `ec2:*` instead of `*`).
- Start tracking CloudTrail logs for processes using keys to gather initial data for policy generation.
### For Medium Organizations
- Systematically apply the Access Analyzer policy generator across key groups identified during the identification phase.
- Begin pilot projects to deploy proxy services (e.g., using Lambda) for one high-risk data access workflow as a test case for mitigation.
- Document all instances where IP restrictions are applied and begin planning for migration to VPC-based security controls.
### For Large Enterprises
- Implement automated scanning or governance tools to continuously monitor IAM policies for violations of least privilege, especially focusing on the presence of `sts:AssumeRole` or overly broad `iam:*` permissions attached to access keys.
- Develop standardized reference architectures for isolating functions that *must* use static credentials, ensuring these isolated services utilize the proxy pattern (rate limiting, data transformation).
- Integrate resource-level policy generation into the standard CI/CD deployment pipeline for new applications to enforce least privilege by default.
## Configuration Examples
| Restriction Type | Condition Key | Implementation Note |
| :--- | :--- | :--- |
| Source IP Denial | `aws:SourceIp` | Deny access if the request does not originate from specific trusted IPs (use with caution). |
| Resource Scoping | `Resource` ARN | Instead of `Resource: "arn:aws:s3:::*"` use `Resource: "arn:aws:s3:::critical-bucket/*"` |
## Compliance Alignment
- **NIST (SP 800-53):** AC-6 (Least Privilege), AC-2 (Account Management), IA-2 (Identification and Authentication)
- **ISO 27001/27002:** A.9.2.5 (Access Rights), A.14.2.1 (Secure Development Policy)
- **CIS Benchmarks (AWS):** Focuses on Identity and Access Management controls related to restricting permissions.
## Common Pitfalls to Avoid
1. **Over-reliance on Source IP:** Failing to recognize that users/applications running on dynamic IP addresses (like mobile clients or traditional egress NAT gateways) will break access when using `aws:SourceIp` restrictions.
2. **Ignoring Listing Privileges:** Assuming that attackers only need read/write. Removing the ability to list buckets or roles prevents the attacker from effectively mapping the boundaries of their compromised permissions.
3. **Assuming Access Analyzer is Perfect:** Forgetting that Access Analyzer suggestions are based on recorded activity and might miss infrequent but critical administrative calls, necessitating manual review for privilege escalation actions.
## Resources
- **AWS Documentation:**
- Automating analysis using IAM Access Advisor
- IAM Access Analyzer policy generator
- Example policies for denying access based on source IP
- Introducing Amazon S3 Object Lambdas (for proxying access)
- **AWS Documentation:** Guide on using pre-signed URLs (for understanding required scope if isolation is planned)
- **Series Reference:** Part 1: The easy wins (for prerequisite steps)