How Service Control Policies help to secure AWS accounts
Service Control Policies (SCPs) bring outside control over the account greatly enhancing security. But you need to opt in early
Motivation
The recommended architecture is to have resources only in member accounts (those created via Organizations) and not in the master (the one you've just opened). Apart from the easier separation of resources, this setup also allows the use of Service Control Policies (SCPs for short) to limit what each account can do.
Along with identity-based and resource-based policies, SCPs are policy types that can limit permissions. But they control the account as a whole, instead of an identity or a resource. SCPs allow security controls not achievable with the other policy types.
But SCPs do not affect the master account.
So the first thing you should do right after opening an AWS account and logging in the first time is to go to Organizations, enable it, click on the link in the
email, then create a new member account. You need to input a new email address, but you can use the + alias if your email provider
supports it as Gmail does. And finally, use the role to get into the
newly created account and create a new user with Administrator privileges.
Why it is essential to do right after opening an account
The problem with postponing creating and using a member account is that it is unlikely you'll do it later. When you have resources like elastic IPs along with multiple users and policies, migrating them is likely to break something.
But starting out with a member account is trivial. It takes ~5 minutes and you can practically forget about this setup until you need it.
Other options
If you find yourself in the common situation when you started using the master account you still have a few options. First, you can register a new account and invite the old one as a member. The downside is that you need to use a different email address that might not be the official company address. But this is also a viable way.
The other option is to create a new member account and then move the resources over there. You might want to start gradually, but a migration means URLs and IPs will change.
Benefits of a member account
Using only member accounts for resources is a way more secure approach than using the master account. These accounts can be limited in a way that is outside their control.
For the master account, you can apply 2 types of policies: identity-, and resource-based ones. The former applies to users, roles, and groups, and control what they can do. The latter is attached to a resource like an S3 bucket and controls who can access it. But there is no policy type that restricts what the account as a whole can do. What if you want to make sure no S3 buckets can be created? None of the available policy types can guarantee that.
SCPs open the way for this kind of control. And since they are imposed on the member from the organization, there is no way around them. Not even the root account can do something denied by an SCP.
But the master account can not be limited by SCPs. You can attach them but they won't be effective.
What can be controlled
SCPs bring solutions to a whole set of policy problems that the other controls can not address. Let's see a few examples, but I'm sure these are just the tip of the iceberg.
Restrict regions
AWS allows all regions to be used, and there are quite a few of them now. But it is unusual to use more than one, especially for development.
But from a security perspective, having them usable offers a great way to hide malicious resources. Disabling regions you don't use is a best practice then.
Just keep in mind that global services are served from the us-east-1 region, so you might need to enable those.
Prevent deleting security-related resources
No matter how many bells a malicious action rings if an intruder can disable security-related services. If you have a CloudWatch Events Rule that sends an email when CloudTrail is disabled, an attacker can delete that first. You can define strict permissions that safeguard these services but you can't forbid all kinds of tinkering with them.
But with SCPs you can deny deleting or altering any resource. If you have an appropriate policy enforced on the account, even the root user is unable to delete the Events Rule. This guarantees security no matter how policies and roles evolve over time inside the account.
SCPs make it possible for an account to have no control over some of its resources.
Disable or limit services
Some services can be really expensive or downright disastrous if left available. Ordering a large reserved instance severely affects your bottom line. Or locking a Glacier Vault with a malicious vault lock and start pumping data into it is a particularly vicious act.
With SCPs you can disable these services altogether in a future-proof way.
You can also whitelist available instance types. Even if your account becomes a bitcoin mining machine it won't be a particularly effective one with only t3 instances in its disposal.
Conclusion
Take that 5 minutes to set up Organizations when you create your account. Even if you don't need the additional security controls this setup brings, they will be available for you. But if you don't do it it will be progressively harder the more resources you add to the master account.
