Enabling Service Control Policies in AWS Organizations
Left unchecked, the spread of uncategorized AWS accounts in a company can turn into a policy nightmare. Here's how to establish some oversight using service control policies.
Use of Amazon Web Service (AWS) within a company often grows organically. It may start out with a department or two using AWS for their own purposes.
Eventually, however, there will likely be pressure to put some controls into place to ensure that AWS is being used in a way that is consistent with the company's own internal policies.
As I explained in last week's installment, in these types of situations, it is possible to link multiple AWS accounts to a primary account using the new AWS Organizations feature. Although linking AWS accounts can allow for oversight and consolidated billing, it is also possible to establish a degree of governance through the use of service control policies.
AWS does not enable service control policies by default. To enable these policies, log in to the AWS console, and then click on the AWS Organizations link, located within the list of AWS Services. Assuming that you have already created an AWS Organization and added one or more accounts to it, you should now see a list of the accounts that exist within the Organization. This screen contains a series of tabs that run along the top of the window. Click on the Organize Accounts tab.
At this point, you should see a message telling you that you need to enable a policy type in this root before you can apply policies of that type. Just beneath this message is a list of policy types. By default, the only policy type that is listed is a service control policy. You can enable service control policies by clicking on the Enable link, just to the right of the policy type, as shown in Figure 1.
It takes about a minute or so for AWS to enable service control policies. Once the policies are enabled, the console view will change slightly. If you look at Figure 2, for example, you can see that the Policies section now contains a Service Control Policies link. You will also notice that there is now a link that you can use to disable service control policies.
When you click on the Service Control Policies link, you are taken to a screen that shows you the policies that apply to the various accounts. For example, Figure 3 shows that my account (which is the only account that I have) has inherited the FullAWSAccess policy from the root level. This policy allows full access to AWS.
You might also notice that the list of Policies Attached/Available does not list any other policies. The reason for this is that we have not created any additional policies.
If you look at the top of the screen, you will see that there is a tab labeled Policies. Clicking on this tab brings up a list of the currently existing policies. This screen also contains a button that you can use to create a new policy, as shown in Figure 4.
There are two different methods of creating a policy. One option is to copy an existing policy and then customize the copy to meet your needs. The other option is to use the Policy Generator to create a policy from scratch.
The Policy Generator is relatively easy to use. You will need to begin the process by entering a name and an optional description for the policy. From there, you have to specify the overall effect of the policy. The overall effect can be set to either Allow or Deny. Next, you simply add a list of services to the policy. If, for example, you set the overall effect to Deny, then any services that you add to the list will be blocked to any account that is subject to the policy.
For example, the sample policy that is shown in Figure 5 above is configured to deny access to the Amazon API Gateway. You can create more comprehensive policies by adding additional statements to the policy.
Brien Posey is a seven time Microsoft MVP with over two decades of IT experience. As a freelance writer, Posey has written many thousands of articles and written or contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. When He isn't busy writing, Brien Posey enjoys exotic travel, scuba diving, and racing his Cigarette boat. You can visit his personal Web site at: www.brienposey.com.