From Exposure to Lockdown: How AWS Neutralizes Compromised IAM Credentials through Managed Policies
AWS has implemented a managed policy, AWSCompromisedKeyQuarantine, to proactively address the risk of exposed IAM access keys. This policy automatically attaches to IAM users whose credentials have been exposed, either through public code repositories (like GitHub) or external notifications. The policy limits the permissions of the IAM user, preventing potential misuse of the compromised credentials. The policy has evolved over time, with multiple versions adding to its protective capabilities. GitHub’s secret scanning program plays a key role in identifying exposed credentials, alerting service providers, and ultimately, AWS, which then attaches the managed policy to mitigate the risk.
AWS has developed a robust system to combat the ongoing threat of exposed Identity and Access Management (IAM) access keys. The core of this system is the AWSCompromisedKeyQuarantine managed policy, designed to automatically respond to instances where an IAM user's credentials have been exposed. This proactive approach is crucial, given that long-term access keys are frequently exposed through publicly accessible code repositories like GitHub, or via external notifications.
AWSCompromisedKeyQuarantine works by limiting the permissions of an IAM user whose credentials have been compromised. Instead of requiring administrators to manually adjust permissions after a breach – a time-consuming and potentially reactive process – the policy is automatically attached to the IAM user, effectively preventing the attacker from utilizing the exposed key. The policy’s effectiveness is further enhanced by GitHub’s secret scanning program, which identifies exposed credentials in public repositories and alerts service providers, including AWS.
GitHub’s secret scanning program, established in 2018 and expanded to include AWS in 2020, scans public surfaces across GitHub, including repositories and public npm packages, for specific sequences to identify exposed credentials. This process generates pop-ups when a push attempt with the exposed credentials is detected, prompting the user to confirm the action.
AWS actively monitors for these exposed credentials and, upon detection, immediately attaches the AWSCompromisedKeyQuarantine managed policy. This action is typically accompanied by email notifications to the AWS account owner and the creation of a Support case within the AWS console. The timeline of events demonstrates a rapid response time – within 10 seconds of an access key exposure, AWS attaches the policy and generates a GitHub notification within a second.
Over time, the AWSCompromisedKeyQuarantine managed policy has evolved, with each version expanding its protective capabilities. The initial version focused on limiting 28 actions across five services, but subsequent versions have added to this list. The policy’s design is notable because it doesn’t require modifying existing permissions associated with the IAM user; instead, it directly restricts access, minimizing disruption to existing operations. To help prevent communication gaps between cloud engineering teams and security teams, AWS Systems Manager Explorer can be used to aggregate AWS Support cases, ensuring that security professionals are promptly notified of potential exposures. Security teams can proactively enable alerts based on the AttachUserPolicy event in CloudTrail logs, providing an additional layer of defense.