AWS Organizations allows the management of accounts under a new entity. This entity is built into a hierarchy, and the policies and organizational units can be built within each other for management. I couldn’t help but think of Microsoft’s Active Directory when looking at it the first time, but that goes for anything with organizational units (OU) and hierarchy. Each particular OU can have policy applied to it, and the user/group will inherit the policy of the OU in which they reside. This also means that each user/group can only be in one OU at a time, but can have multiple policies applied to it since the OUs can be nested. The groups can be created by region, user, group or other elements.
With both AWS IAM and AWS Organizations, there can be a little overlap, but you can think of Organizations as a way of containing the rights of users. The IAM policies can still be created and even pushed through Organizations, but it’s the guardrail to determine least privilege. If users go against these policies, it’s possible to contain or restrict them with blacklist or whitelist policies. This helps to keep the permissions and security of users to what’s deemed necessary by hierarchical policy enforcement. AWS Organizations is the framework that IAM policies can use to tighten security. Read the rest of my article at the link below:
This is a Security Bloggers Network syndicated blog post authored by Matthew Pascucci. Read the original post at: Frontline Sentinel