How not to accidently create HUGE risks in IAM policies
Many people do not realize they created a huge backdoor into their IAM policies with this SMALL mistake
hello avatars, celt here to talk about a huge and common design flaw in IAM policies. Many people make this mistake and do not know there is a backdoor waiting to be opened in their infrastructure.
I recently found this design implemented by an InfoSec engineer at my firm. Half of the people on the call didnt even realize what i was saying, goes to show what your competition is. Needless to say i am going to market the crap out of this finding to my management and say i saved the company from a huge risk vector, and you should too.
AWS IAM Least Privilege
Least principle is pretty much a buzzword at this point, everyone says it but most people DO NOT practice it. There is almost always something a role doesnt need, and thats why least privilege is almost like an ideal goal that most people do not reach. I have lightly covered the topic here and here.
here is how AWS looks at least privilege:
Apply least-privilege permissions
When you set permissions with IAM policies, grant only the permissions required to perform a task. You do this by defining the actions that can be taken on specific resources under specific conditions, also known as least-privilege permissions. You might start with broad permissions while you explore the permissions that are required for your workload or use case. As your use case matures, you can work to reduce the permissions that you grant to work toward least privilege. For more information about using IAM to apply permissions, see Policies and permissions in IAM.
Overtime your policies should be come more granular and be narrowly tailored to the persona. There is a sweet spot between perfect least privilege and general roles for engineer, this depends on your risk tolerance and your organization.
How not to write IAM Policy
Let’s say you are writing a policy for Redshift for your database engineers to use. Obviously you dont want someone to accidently delete something, so delete permissions are off the table. Let’s say you also want to restrict the ability to also want to eliminate the ability to create cluster security groups s, these are common security controls. we dont want the engineers going beyond the guardrails we established. Some people will write this policy as:
{ “Action”: [ “redshift:*”
],
“Effect”: “Allow”,
“Resource” “*”
},
{
“Action”: [
“redshift:Delete*”,
“redshift:CreateClusterSecurityGroup”,
],
“Effect”: “Deny”,
“Resource” “*“
},
So this policy is saying you can do everything except the things we do not want you to do which is these 2 specific things. As this policy has an explicit deny on the restricted actions, there is no way around that. Explicit denies
What most people do not realize is that you are actually saying more than that.
What happens if AWS releases a new Redshift feature, and along with it a new Action? In the above policy logic your principal (who or what is doing the action) now has an explicit allow to execute this new action. This by principle is not least privilege, and you should not write policies like this.
The preferred software architecture is providing having explicit allows for the actions that are approved, and either an implicit or explicit deny, based on your risk tolerance.
Many people miss this, but not you avatar.
-celt