Let’s say you’re excited about using Service Control Policy to govern what goes on in your organization’s AWS accounts and improve compliance, but you don’t want to break the world when you roll it out. How do you do that?
Start by identifying a single account that serves an active, but low risk use case such as a sandbox or training account. Join this account to your organization and configure CloudTrail if you haven’t already.
Maintain Control of the Account
Let’s exert Enterprise level control upon a few Security-specific and critical functions. We can start by creating a policy that ensures you maintain control of the AWS account and that the CloudTrail is not tampered with.
Chris Farris published a policy that accomplishes this by denying specific cloudtrail, aws-portal, and organizations apis. AWS provides several similar examples. This policy could serve as the basis of an ‘Enterprise Security Controls’ policy. For now, attach it to only the test account. This policy can be attached to the test account with very little risk because it denies operations that are only needed by someone changing the account’s base configuration and audit configuration.
Learn and Iterate
With this basic policy in place on a test account, we can learn things like:
- whether it does or does not break anything
- the workflow of changing and managing service control policies
Once you’re comfortable, you can attach this policy to organizational units or even the organizational root.
As my friend Elliot at KindlyOps says, “Improving (governance) over time always beats trying to start perfect.” You now have one more piece to the Security and Governance pie implemented with automated Compliance AND you can improve on it next week.
#NoDrama
