This article is directed at an audience with a basic understanding of AWS Organizations and Service Control Policies (SCPs).
While technically speaking, the documentation for AWS Organizations Service Control Policies is not lacking in subject matter, the clarity of explanation left something to be desired for me.
While working with Support and testing various approaches to my use case, I found frustration in what I thought was an intuitive understanding of the console’s visual representation of Service Control Policies inheritance. It was frustrating because my understanding was wrong.
Below I attempt to walk through a graphical explanation for how SCPs function and provide an approach for following AWS’s design in applying least privilege in an ever increasing way.
In the following diagrams think of the circles as representing service permissions (ec2:*, s3:*, etc.), each square is a direct attachment of an SCP, and the arrows represent the direction of effective inheritance of the policies.
As with all things IAM related in AWS, we start with an implicit deny. No account has the inherent ability to invoke any service without the attachment of an SCP granting such. All services and all permissions (*:*) are granted by the default attachment of the FullAWSAccess SCP to all Organizational Units and accounts at the time of their creation.
Because Deny permissions are evaluated first and all permissions are inherited, any Deny higher in the hierarchy prevents any similar permissions from being accessible — even if granted by another SCP — at a lower level. Above, the policy at the Parent OU level prevents the use of EC2 and S3 in all levels below it, regardless of the multiple direct applications of the FullAWSAccess policy.
Similarly, the attachment of an Allow-based whitelist will prevent the propagation of the permissions at lower levels.
While requiring the most management, an account-level Allow-based whitelist provides the most granularity for governance. Here the author is assuming there is already some level of automation around the account creation which would allow the application of the whitelist and the removal of the FullAWSAccess policy with little additional effort.
The value of this approach can be seen when there are services that may not be desired at a majority of the organization but may still be needed in specific use-cases. This allows for simple elevation to both satisfy the security and governance concerns, while also allowing the flexibility of exceptions for valid uses.
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html
