An Overview of AWS Organizations
By: Chris Hare
Tags: AWS, Cloud, Governanve, Cloud Governance, Technology

For example, let’s assume you want to deny a specific service to your organization for some reason. For our example, let’s deny access to DynamoDB.

Enter a name and description for the policy, and then navigate through the service list on the left to find ‘DynamoDB’. After selecting DynamoDB, a list of actions is displayed. If you want to deny specific actions, select those, but for our example, we are going to deny all actions in DynamoDB, effectively removing an account’s ability to access the service.

Before we can submit the policy, we have to select the resources to apply the policy too. In this case, we want to apply this policy to DynamoDB.

We have to select DynamoDB as the service, select all of the resources, and because we are opting to deny DynamoDB completely, leave the ‘*’ in the ARN field.

Once we have defined everything in our SCP, the resulting JSON looks like

{

"Version": "2012-10-17",

"Statement": [

{

"Sid": "Statement1",

"Effect": "Deny",

"Action": [

"dynamodb:*"

],

"Resource": [

"*"

]

}

]

}

This has the effect of denying all actions associated with DynamoDB.

As mentioned previously, we should not apply this policy against the master or root account until we are sure it provides the desired result. Once we have validated the result, we can apply the SCP to the appropriate OUs or accounts.

Testing the new Policy

Before we apply this policy to all of our accounts, AWS recommends verifying you get the desired result before implementing it everywhere.

First, let’s validate the other account can access the resource we are going to block, in this case, DynamoDB. We do this by logging into the master account, and using the switch role feature to switch to the target account.

If you have never switched roles before, click on the “Switch Role” item, which displays this page:

You have to enter the target account ID, and the target role, which is the “OrganizationAccountAccessRole”, which was created in the target account when the organization was defined and the target account was linked to the master account.

Because I have already accessed the other account using the Switch Role function, it appears in the Role History above the Switch Role item. After you switch roles, the view in the target account matches where you were in the console in the original account. For example, because I was in AWS Organizations when I switched roles, I am in the same view after switching roles.

Let’s go create a table in DynamoDB.

With our table created, we can see the table details.

Now, let’s go back to the Master account and apply the DenyDynamoDB policy.

Before we can apply the Service Control Policy, we have to enable this feature on the root or master account.

Click on “Enable” next to Service Control Policies to enable SCPs on the root account. This shows Service Control Policies are enabled, and we can add our policy to our target account by selecting the target account in the view, and then clicking on Service Control Policies on the right side of the page.

After clicking on “Attach”, the SCP is attached to the account, and when we access the alternate account, we should not be able to access DynamoDB now.

After switching roles, and accessing DynamoDB, we are presented with the DynamoDB Getting Started page. Click on the arrow at the top left of the page.

When we click on the Tables item on the left of the page, we get an access denied message because the Service Control Policy is in place. All DynamoDB actions are denied at this point, making usage of the service for this account impossible.

If this is the desired action for all of the accounts in the organization, then applying the policy to the root account will apply the policy to every account in the organization.

SCP Interactions

The principal thing to remember with Service Control Policies is to attach them to an Organizational Unit and not to account. By attaching the SCP to the OU, the SCP is propagated to every OU in the hierarchy.

The second key point is that SCPs define the maximum permissions for the service. Even if an IAM Role or user has more extensive permissions, they will not be granted to the user or role because of the SCP.

Settings

The Settings view allows you to view the details for the organization, including the master account information and the trusted services configuration. Trusted services can access information about the accounts, OUs, polices for the organization.

AWS recommends adding the desired trusted services to the account using the console so other tasks that must be performed to enable the access are also performed.

Deleting An Account

At some point, it may be time to remove an account from the organization. To do this, go to the AWS Organizations dashboard view, and select the account. At that point, you can remove the account.

This is best done from the account leaving the organization, as it may be necessary for additional information such as contacts and billing information to be provided.

AWS Organizations Pricing

There is no cost to using AWS Organizations itself, but any resources created in the accounts associated with the organization may incur charges as defined in the pricing structures for those services.

Automation

If you are considering the use of AWS Organizations, it is advisable to develop either parameterized CloudFormation templates or a custom application using the SDK to add/remove accounts in the organization.

The advantage to this becomes clear as you add Service Control Policies to control and limit the maximum permissions for various AWS Services, or as illustrated in this article, prevent the use of a service altogether. This way you can ensure when accounts are created, the process is consistent, they can be assigned to an OU, and the appropriate SCPs are applied immediately.

AWS Control Tower

This is a topic for a future article, but it needs to be mentioned in this context.

Designed to assist organizations to create, manage and control a multi-account AWS environment, Control Tower helps by applying the best practices established by AWS through their experience in supporting organizations as they migrate to the cloud. According to the product webpage AWS Control Tower “can provision new AWS accounts in a few clicks, while you have peace of mind knowing your accounts conform to your company-wide policies”. I will dive into AWS Control Tower in a future article.

Best Practices

Here are some things to consider when getting ready to move beyond your one account and start setting up AWS Organizations.

How to organize accounts

You must give serious consideration to how you will get organized. There are several options: — Organize by functional domain. Just like we organize people and process your function, we could do the same for accounts.

— Organize by development phase. You may want an account for developers, along with corresponding VPCs for development and testing, along with a separate account for production. This eliminates the separation of duties issues by ensuring users with access to the development account can not access the production account. — Organize based on data classification. This is another situation where you may need to create OUs for your most sensitive information, regardless of which part of the organization.

What works in one situation, may not work for another. I would suggest creating OUs based upon business function. For example, finance apps and users are in the finance OU, and each OU has several accounts, one for each of the development phases, and one for production. This has the benefit of keeping the applications and data for that business unit together.

For example, general ledger and related functions would be used by finance users, and typically no one else in the company. Those same functions are likely implemented in software and need to communicate with each other, by keeping them in the same OU and different accounts for development and production, you can limit who has access to this important resource.

Other SCPs to consider

Aside from denying specific services such as our DynamoDB example earlier in the article, you may also want to consider Service Control Policies extricating what actions can be taken for the security and IAM services. The important thing to remember is you will have to decide what is allowed and not allowed within your specific organization and it’s specific rules and legal obligations.

For example, you may want to prevent users from disabling services like CloudTrail and CloudWatch, prevent configuration changes on services, prevent VPCs from getting internet access, etc. AWS has defined several scenarios and provided sample Service Control Policies to implement them. These are worth examining and applying to your organization if they make sense.

Additional Best Practices

Some additional best practices to consider when setting up AWS Organizations: — It is strongly recommended you do not create any resources (with one exception) in the Master account. This makes it easier to make high-quality control decisions, and make it easier to understand the charges on your AWS invoice. — The one exception is CloudTrail. You should set up CloudTrail in the Master Account so you can track all AWS usage across the member accounts.

— Every account/OU should be set up to have the least privilege possible, even if you are going to further reduce the privileges using IAM. For example, users who are in the development OU should not have access to the production VPCs and OU. Even then, you may want to limit who can create, modify and delete resources.

— Assign Service Control Policies to the OU rather than the accounts. This allows for a better mapping between the organizational structure and the level of access needed within AWS. — After creating a new Service Control Policy, validate operation in one account before implementing it across all of the OUs. This makes it easier to rollback should the result be something other than anticipated. — Automate the creation of accounts. Create a CloudFormation template so every new account is created and configured for the organization. This template can create the account, assign to an OU, attach Service Control Policies, create VPcs, IAM roles, etc. Just as we implement resources using infrastructure as code (e.g. CloudFormation), so should we consider the creation of an account and OU as a similar process.

Conclusion

AWS Organizations can be invaluable to enterprises who need multiple accounts to segregate work, and apply either unique SCPs to an account, or more specific IAM roles for specific use cases. It also provides consolidated billing through the master account, so volume discounts can be achieved which might otherwise not be attainable at the individual account level.

Additionally, using multiple accounts also allows for the separation of development, test and production environments aside from VPC separation, as more granular control can be achieved at the account level through IAM roles than at the VPC level.

Enabling additional trusted services, and simplifying logins to the organization through the AWS Single Sign-On (SSO) service is also possible.

In conclusion, using AWS Organizations is a must for anyone needing more than a single account or VPC and is a best practice for managing the services and resources in your AWS environment.

References

AWS Control Tower

AWS Organizations

AWS Organizations Tutorials

Enabling All Features in your AWS Organization

Example Service Control Policies

IAM JSON Policy Elements: Condition

Managing the Accounts in your AWS Organization

Service Control Policies

Strategies for using Service Control Policies

About the Author

Chris is a highly-skilled Information Technology AWS Cloud, Training and Security Professional bringing cloud, security, training and process engineering leadership to simplify and deliver high-quality products. He is the co-author of more than seven books and author of more than 70 articles and book chapters in technical, management and information security publications. His extensive technology, information security, and training experience makes him a key resource who can help companies through technical challenges.

Copyright

This article is Copyright © 2019, Chris Hare.