ACM.370 Additionally, policy nightmare caused by inconsistent resources in API requests
Part of my series on Automation of cybersecurity measures. AWS Organizations. I AM. Deploy a static website. THE Coded.
Free content on Cybersecurity Jobs | Register at Broadcast list
In the last article I wrote and tested a policy that prevents a user with administrator permissions from modifying any MFA device other than their own – except we can’t exactly do that with virtual devices. As far as I know, we have done our best with the policy posted in the post. I’ll update if I find things change or discover anything new.
OK, next step. Although we have restricted MFA devices, there are many other types of credentials on AWS that a user can modify in addition to an MFA device for another user.
Please note that I’m looking forward to trying to sort out any inconsistencies in how AWS passes resources in requests and writing the associated policy correctly. I have therefore not tested all the actions of this policy in this article. If you are using it in a production environment, you need to verify that the user can perform all the actions they are supposed to perform and not any actions they are not supposed to perform.
Here are some sample policies, none of which completely address credential issues and some of which use logic that even the AWS documentation warns against. I’ll try to sort it out below.
AWS has an article on passwords here:
This article covers passwords, service-specific credentials, and signing certificates: