Reviewing account by account does not scale
With five accounts, checking by hand that they all comply with the standard is tedious but possible. With fifty, across three clouds, it is impossible. And every new account created is another one to review.
The account structure we saw earlier has a property that solves this: policies are inherited.
Top down
A policy applied to the organisation holds for every account. One applied to the workloads unit holds for every account in that unit. And so on downwards. For example:
- At the organisation: permitted regions only; activity logging switched on and protected.
- In the workloads: mandatory encryption; owner and environment tags.
- In production: no public storage; no local users.
- In the sandboxes: a monthly spend limit and automatic deletion of anything unused for weeks.
A new account inherits every rule for its place in the hierarchy from the first minute.
Prevent and detect
There are two kinds of policy, and you need both:
Preventive. They block the action: you cannot create a resource in a region that is not permitted, the request is rejected. They are the safest, but they should be used for very clear rules, because they block.
Detective. They allow the action, but detect and report it: a resource with no tags shows up in the compliance report with its owner. They are better for rules with nuances or in a transition period.
The usual approach is to start a rule as detective, measure how much it is breached, fix what exists and, once breaches are almost zero, turn it into a preventive one.
Alongside the rules in the code
These policies act in the cloud, on everything that exists. Rules as code act earlier, on each change's plan. The two layers complement each other: the first catches what slips past the second, including whatever somebody does by hand in the console.
With all of this running, one question remains that almost nobody asks: how do you know whether governance is working?
How we apply it: Multicloud Governance.