It seems like every week there's a news story about an "exposed S3 bucket." I want to ensure our IAM policies are as tight as possible. Beyond just making buckets "private," what are the subtle IAM errors or misconfigurations I should look for? Are there automated tools within AWS that can audit my permissions to ensure I'm following the Principle of Least Privilege?
3 answers
The most common mistake is using "Wildcards" in IAM policies, like s3:* on all resources. This gives way more power than necessary. You should always specify the exact Action and the exact Resource ARN. Another subtle issue is "Confused Deputy" vulnerabilities where a third-party service is given a role without an External ID. To audit this, use AWS IAM Access Analyzer; it uses formal logic to identify any resources that are accessible from outside your account. Also, enable "S3 Block Public Access" at the account level. This acts as a master kill-switch that prevents any bucket from accidentally being made public, regardless of individual bucket policies.
Are you using "Inline Policies" for your users, or are you managing permissions through IAM Groups and Managed Policies for better visibility and auditing?
Enable S3 Versioning and Multi-Factor Authentication (MFA) Delete. This prevents a compromised admin account from permanently deleting your critical data.
MFA Delete is such an underrated feature. It’s the ultimate safety net against malicious insiders or stolen high-level credentials.
Thomas, we actually moved away from individual users entirely and now use IAM Roles with AWS IAM Identity Center (formerly SSO). This allows us to map permissions to our corporate directory groups. When an employee leaves the company, their AWS access is revoked automatically. This "Identity-centric" approach is much cleaner than managing long-lived Access Keys, which are often the source of leaked credentials. It makes our annual security audit much faster because we can prove exactly who has access to what based on their job role.