Full Report
Learn how to identify unused and unnecessary long-lived IAM User access keys.
Analysis Summary
# Best Practices: AWS Access Key Management and Remediation
## Overview
These practices address the security risks associated with long-lived, static AWS IAM access keys. The central recommendation is to eliminate access keys in favor of temporary credentials provided by IAM Roles, which automatically refresh and expire, significantly reducing the window of opportunity for attackers if credentials are leaked.
## Key Recommendations
### Immediate Actions
1. **Identify and Deactivate Unused Access Keys:** Generate an IAM Credentials Report to list all active/inactive keys. Identify and remove any keys that have not been used for a defined period (ideally much shorter than 90 days, though 90 days aligns with some baseline standards).
2. **Remove Root User Access Keys:** Immediately determine the purpose of any access keys associated with the AWS Root user account. If any exist, find immediate alternatives (e.g., use a dedicated administrative IAM user with MFA) and proceed to disable the root account access keys.
3. **Scan Code Repositories and Artifacts:** Utilize external tools (like Wiz, if available) or internal scripts to scan source code repositories, configuration files, application logs, and backup files for hardcoded secrets (access keys). Remove or securely replace any keys found.
### Short-term Improvements (1-3 months)
1. **Enforce IAM Roles for Compute Workloads:** For all existing compute resources (EC2, Lambda, Containers), identify any usage of static access keys. Replace these keys with appropriately scoped IAM Roles assigned directly to the resource (Instance Profiles for EC2).
2. **Transition Human Users to SSO:** Identify all human IAM users relying on password logins or access keys. Enroll these users into a federated Identity Provider (IdP) via Single Sign-On (SSO). This allows for centralized credential lifecycle management and immediate offboarding.
3. **Remove Orphaned IAM Users:** Use the Credentials Report to identify IAM users that do not possess any active access keys or passwords, and remove these unnecessary users from the environment.
### Long-term Strategy (3+ months)
1. **Enforce IAM Roles as Default:** Establish a policy that mandates the use of IAM Roles for all AWS services requiring programmatic access, effectively deprecating the creation and use of static access keys entirely.
2. **Implement Prevention Guardrails (SCPs):** Deploy a Service Control Policy (SCP) across organizational units to deny the creation of new IAM users and new associated access keys. *Note: This SCP should generally only be applied after all existing necessary keys have been migrated to roles, as it also prevents necessary key rotation.*
3. **Establish Contractor Access via Trust Relationships:** For third-party contractors, establish dedicated AWS accounts and utilize IAM Roles with trust policies to grant them access to necessary resources, rather than creating local IAM users in the primary account.
## Implementation Guidance
### For Small Organizations
- **Prioritize Credentials Report:** Focus immediately on generating the IAM Credentials Report and purging keys older than 90 days.
- **Manual SSO Migration:** If a formal IdP solution is not yet in place, begin moving human users to use IAM console passwords with strong MFA, while simultaneously planning the integration with an external IdP for better lifecycle management.
### For Medium Organizations
- **Automated Scanning:** Implement a cloud security posture management (CSPM) or secret scanning tool to regularly identify keys in ephemeral environments (like deployment artifacts or containers).
- **Phased Role Assignment:** Select one core application team to pilot the migration from access keys to IAM Roles for their compute resources, document the success, and use this blueprint for broader rollout.
### For Large Enterprises
- **Mandatory SCP Implementation:** Roll out the preventative SCP policy (denying IAM user/key creation) to non-production or highly controlled accounts first, then expand.
- **Centralized Offboarding Checks:** Ensure the HR/Identity systems integrate fully with the IdP, guaranteeing that disabling the user in the central system immediately revokes access across all integrated AWS accounts.
## Configuration Examples
### Denying Access Key Creation (SCP Policy Snippet Example)
To prevent *new* access key creation across an AWS Organization:
json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyCreateAccessKey",
"Effect": "Deny",
"Action": [
"iam:CreateAccessKey"
],
"Resource": "*"
}
]
}
*Note: As the article mentions, this SCP also blocks key rotation, so it requires careful coordination.*
## Compliance Alignment
- **CIS AWS Foundations Benchmark (V1.2.x / V2.0.x):** Focuses heavily on restricting root usage, enforcing MFA, and evaluating key usage periods (e.g., checking for keys unused in the last 90 days).
- **NIST SP 800-53 (IA/AC Controls):** Addresses the need for periodic review and revocation of credentials, and the use of least privilege and temporary credentials where possible.
- **ISO 27001/27002 (A.9 Access Control):** Emphasizes managing user access rights, including timely removal of access upon termination or change of role, which is facilitated by SSO integration.
## Common Pitfalls to Avoid
1. **Applying Blocking SCPs Prematurely:** Applying SCPs that deny key creation before all existing keys on compute instances are migrated to Roles will immediately break running applications. Migration must precede the general block.
2. **Ignoring Root Keys:** Treating the Root account as just another user; Root access keys are extremely dangerous because they often have unrestricted permissions and bypass many logging/control mechanisms.
3. **Focusing Only on Keys, Not Users:** Removing an access key might leave behind an IAM user. If that user has no credentials, they are harmless, but they represent unnecessary clutter and should be cleaned up.
4. **Using Long Inactivity Thresholds:** Using the 90-day benchmark without investigation is risky. If an account hasn't been active in 90 days, it’s a strong candidate for immediate removal or deactivation.
## Resources
- **AWS Documentation:** AWS IAM User Guide - Managing access keys
- **AWS Documentation:** AWS IAM User Guide - Requesting temporary credentials (for understanding Roles)
- **AWS Control Tower Recommendations:** Documentation regarding strongly recommended controls, including disabling root user actions.