We all know that vulnerabilities are a concern in security, but IAM misconfigurations are actually the biggest culprit in cloud security incidents.<p>Why do we keep using "*" and then complain about it? Is IAM so challenging?
Most high level AWS API clients don't provide an easy way to map their operations into well thought low level IAM permissions.<p>So you might need many iterations of trial and error possibly involving different teams (dev, sec, ops, etc...) just to figure out the minimum pivileges needed for something.<p>As a concrete example, check the docs for boto3's upload_file method: <a href="https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/s3/client/upload_file.html" rel="nofollow">https://boto3.amazonaws.com/v1/documentation/api/latest/refe...</a><p>UploadFile is not a S3 API action, so there's no IAM policy for that. It's up to you to search in the docs and in the internet which S3 APIs upload_files uses under the hood and how to properly design a policy for those.<p>As a possible solution, here's how AWS CDK does things:<p>> a = SomeResource()<p>> b = OtherResource()<p>> a.grant_read(b)<p>Resources auto generate IAM policies from high level constructs, which leaves much less room for human error.
IMO, there is no simple answer, since many access control elements are involved and implementations vary between organizations.<p>From my experience I would say that there may be different factors:<p>- Every developer is an exception<p>- IAM is challenging to scale<p>- Lazy IT Teams?<p>- Visibility of access controls are poor<p>Some useful references:<p>- <a href="https://sysdig.com/blog/identity-access-management-difficult-cloud/" rel="nofollow">https://sysdig.com/blog/identity-access-management-difficult...</a><p>- <a href="https://www.effectiveiam.com/why-aws-iam-is-so-hard-to-use" rel="nofollow">https://www.effectiveiam.com/why-aws-iam-is-so-hard-to-use</a><p>- <a href="https://aws.amazon.com/blogs/security/iam-access-analyzer-makes-it-easier-to-implement-least-privilege-permissions-by-generating-iam-policies-based-on-access-activity/" rel="nofollow">https://aws.amazon.com/blogs/security/iam-access-analyzer-ma...</a>
Companies were struggling even in the non cloud world.<p>Add to that a cloud migration severely underestimated that involves refactoring of n legacy processes (and possible team reorganization), a "brilliant" idea of mapping AD roles and nonsensical forests into <insert propietary cloud IAM solution>, a new CISO coming in following the mantra of least privilege without taking the time to understand (and eventually help redesign) current operations, and urgent deadlines to meet/emergencies to manage/general unwillingness to change standard operating procedures for the new environments (trying to fit everything in the custom servicenow workflows that was designed years ago)... the result is either everyone gets its own tailored set of overpermissions, or broad wildcard roles that for some strange reason fit <insert compliance framework>.
Someone really needs to write some dead simple Cloudtrail analysis tools to advise on needed access. I know there’s a couple out there but they were kinda flaky when I tried them