AWS for Industries
Best Practices for AWS Organizations Service Control Policies in a Multi-Account Environment
AWS financial services industry (FSI) customers often seek guidance on how to set up their AWS environment and accounts for best results. AWS has created a unified set of recommendations, called the multi-account strategy, to help customers like you make the best use of your AWS resources. In this blog, we provide a representative organization unit (OU) structure for an FSI customer, and also best practice guidance and starter service control policies (SCPs) to consider in a multi-account AWS environment to establish governance and control. Using this approach, you can see how the best practices for SCPs are applied in the context of the representative OU structure.
Core concepts of AWS Organizations and starter service control policies
Let us first start by understanding the core concepts of AWS Organizations and SCPs. AWS Organizations is a management service that enables you to consolidate multiple AWS accounts into an organization that you create and centrally manage. AWS Organizations includes account management and consolidated billing capabilities that enable you to better meet the budgetary, security, and compliance needs of your business. You can create accounts in your organization and also invite existing accounts to join the organization.
One of the features from AWS Organizations is SCPs, which helps you specify the maximum permissions for member accounts in the organization. Using SCPs, you can restrict which AWS services, resources, and individual API actions the users and roles in each member account can access. You can also define conditions for when to restrict access to AWS services, resources, and API actions. If you have not used SCPs before, we recommend you review the blog, “How to use service control policies to set permission guardrails across accounts in your AWS Organization.”
Organizational Unit Structure
In a previous blog post, we have examined the recommended architecture of AWS best practices for building your organization. It discussed the need for a multi-account environment, best practices for setting up a multi-account environment including the OU structure and the well-architected multi-account strategy. The OU structure discussed in this post is built with these best practices as foundations and further expands it for an FSI customer.
Figure 1 provides a representative OU structure for an FSI banking customer. The management account is the AWS account you use to create your organization. From the management account, you can manage the lifecycle of accounts in your organization and it also acts as a payer account for the entire organization. From this account, you can also attach policies to entities such as administrative roots, organizational units (OUs), or accounts within your organization.
The organization root is the top level parent node in the hierarchy of the organization. The root contains all the OUs and accounts within the organization.
Figure 1: Representative OU structure for an FSI banking customer
The following sections explain the hierarchy of an OU structure for the FSI customer and some of the SCPs that can be considered for OUs in the hierarchy. This is general guidance and by no means an exhaustive list of SCPs. You can start with this guidance and extend the SCPs to cover controls and governance needed for your organization. Also please note, the SDLC OUs would mimic the structure of the production OUs and for simplicity it is not shown in the diagram.
Before we dive into the OU structure here are few things to note about SCPs:
- SCPs are invisible to all the roles in the child account, including the root user
- SCPs are applied to all roles in the child account, including root user
- SCPs can be attached to the organization root, specific OU or to a specific account. Because you can attach policies to multiple levels in the organization, accounts can inherit multiple policies. As shown in Figure 2, the effective permission for the child OU or account is the intersection of the SCP attached to or inherited from parent and the SCP permissions attached to the child OU or account.
Figure 2: Effective permission for a child OU or account
- As a general best practice, when applying SCPs, the less granular policies are applied higher in the hierarchy and the SCPs become more restrictive as you go to lower level OUs and accounts. As an example, a higher-level policy can permit the use of Amazon Elastic Compute Cloud (Amazon EC2) and a less granular policy applied at lower level can then restrict the instance types that can be used.
- The effective permission for the user (including administrative user) in the child account is the intersection between the SCP and IAM permissions. This is illustrated in Figure 3.
Figure 3: Effective permissions for a user in a child account
Corporate OU
The corporate OU is defined as level 1 OU and is depicted as 1A in Figure 1. It is a direct child of the root and can be considered as an optional OU. Having this OU directly under the root gives an advantage of attaching SCPs in one place. If this is a criteria for your organization, then this is something to review. All SCPs applied to this high-level OU will flow down to all the nested OUs and the member accounts. Note, there are no accounts attached directly to the corporate OU.
Some of the SCPs that can be considered on corporate OU are listed below. Applying these to the corporate OU will give the FSI customer the ability to implement security controls at the highest level to meet the governance requirements. The SCPs are:
- Deny account from leaving organization: When the account leaves an organization, it is no longer bounded by the controls established within that organization. This SCP can be used to prevent someone from moving an account to a different organization that has a set of different controls that are not as restrictive and there is risk of someone making undesired changes.
- SCP: Reference example
- Deny access to specific regions (reduce surface area): AWS has 26 regions, however FSI customer typically operate their workloads within two to four approved regions as required by the government or corporate policies. This SCP gives you the ability to limit the regions where the AWS resources can be deployed, thus reducing the surface area of exposure.
- SCP: Reference example
- Block service access for root user: With a multi-account implementation there are a number of root user accounts, with one root user per account. You should have strong protection for access keys of the root user of an account, Multi-Factor Authentication (MFA) enabled and stored in a company’s secure key vault. Preventing service access for the root user in member accounts eliminates the concern of managing a high number of root user accounts.
- SCP: Reference example
- Prevent users from modifying Amazon S3 block public access at the account level (data protection): FSI customers want to ensure that Amazon Simple Storage Service (Amazon S3) buckets are not changed to public. The account level setting of S3 block public access helps accomplish this. However there is still risk of someone changing this account level setting. This SCP prevents users from modifying the S3 block public access account level settings. In addition to the preventive measures, additional detecting and alerting measures should be implemented if a bucket were to become public.
- SCP: Reference example
- Prevent users from disabling security tools like Amazon GuardDuty, AWS Config, AWS CloudTrail: This SCP prevents anyone from disabling the AWS security tools that are enabled as per best practices in various accounts. The SCP can allow only users in certain roles to be able to make these changes.
- SCP: Reference examples for preventing disabling GuardDuty, Config, CloudTrail
- Prevent escalation of privileges: Privilege escalation refers to the ability of a bad actor to use stealthy permissions to elevate permission levels and compromise security. To prevent privilege escalation, you should use SCPs to prevent users in your accounts from using administrative IAM actions, except from approved roles. With this policy, administrative IAM actions can be restricted to delegated IAM admins. You can use permission boundaries to safely delegate permissions management to trusted employees or a CI/CD pipeline.
- SCP: Deny administrative IAM actions if user not part of approved roles
Workloads OU
The workloads OU is under the corporate OU (a level 2 OU) and is depicted as 2B in Figure 1. The workloads OU would have an approved list of AWS services (allow-list) that are pre-approved to use. The approval of a service can depend on many factors such as approving services based on the type of workloads, like web applications, storage, analytics, etc., that the customer has currently deployed on AWS. For example, if a customer does not have any IoT workloads, it makes sense to block IoT services from the workloads OU. FSI customers can approve services based on compliance programs like SOC or PCI DSS that they need to adhere to. To help customers navigate a complex regulatory landscape for their workloads, AWS has a dedicated team of financial services professionals and resources.
Here is the example SCP for the workloads OU.
- Allow only approved services (reduce surface area): This SCP gives the ability to lock down the workload environment to only approved services. The sample SCP shows how to only allow a subset of services.
- Note this is a sample of allow-listed services. You should modify this list to include the specific allowed services for your organization.
The workloads OU consists of both production and SDLC OUs. Within an FSI organization, the controls that are needed for public-facing workloads can be very different from the internal-facing workloads. To provide greater control within the workloads OU, there are two production OUs defined at level 3: production public facing OU (3A in Figure 1) and production internal facing OU (3B in Figure 1).
Production public facing OU
Data protection is a key consideration for FSI customer production accounts. One consideration for the production OUs can be to mandate classification of data as different data types have need for different controls. Other data protection considerations can be to mandate a MFA for any resource deletion to protect the production workloads. These can be accomplished by using the following SCPs:
- Mandate a tag for S3 data classification (data protection): Attaching a SCP that mandates a tag for S3 data classification assists you with tracking where the various types of data reside.
- SCP: Reference example
- Require MFA for resource deletion (data protection): This SCP will protect accidental deletion of any resources in production and can help protect production data.
- SCP: Reference example
In addition, customers may want to ensure their S3 objects in S3 buckets are encrypted, especially for the production OUs.
- Ensure S3 objects are encrypted when uploaded to buckets (data protection):This sample SCP prevents users from uploading unencrypted objects to S3 buckets.
- SCP: Reference example
Following is another optional SCP you may also want to consider related to VPC (Virtual Private Cloud) peering for your production OUs.
- Deny VPC peering: A VPC peering connection enables you to route traffic between two VPCs and instances and either VPC can communicate with each other as if they are within the same network. FSI customers would like to block this capability as this can lead to data exfiltration outside the organization if a VPC in the organization is peered with another external VPC.The following SCP helps block the VPC peering connection except for some approved roles.
The public-facing workloads can be further classified as those containing confidential data and public data; there are level 4 sub OUs defined as public facing confidential OU (4A in Figure 1) and public facing public OU (4B in Figure 1)
- The workloads with confidential data can have data like SSNs, cardholder information and other PII. Some examples of public confidential workloads are apps for retail banking, online investments, etc. that are available for users to access over the internet with the right authentication and authorization.
- The workloads with public data are those freely accessible to the public. Marketing apps and investor relations portals fall in this category.
The categorization of the public facing OU into sub OUs gives option to set additional controls on these OUs based on the sensitivity of the workloads.
Production internal-facing OU
The production internal-facing OU would contain the internal-facing workloads. The SCPs 8, 9, 10, and 11 defined in the previous section are applicable here as well. In addition, you may also want to implement the SCP to block creation of Internet Gateway for these accounts to reduce the surface area of exposure.
- Deny creating an Internet Gateway (reduce surface area): Attaching an SCP that prevents someone from creating an Internet Gateway (IGW) will help ensure that internal data is kept private.
- SCP: Reference example
The internal-facing workloads can be further classified as those containing internal data, confidential data or restricted data and it is recommended to have separate OUs for these workloads. There are level 4 sub OUs defined as internal-facing internal OU (4C in Figure 1), internal facing confidential OU (4D in Figure 1) and internal facing restricted OU (4E in Figure 1).
- The workloads with internal data are internal portals, operations sites, and other internal only applications which need to be strictly accessible to internal company personnel.
- The workloads with confidential data are the ones that would require specific authorization or clearance. Types of confidential data can include SSNs, cardholder data, etc. Some examples of these internal confidential apps are those that serve the legal or HR teams.
- The workloads with restricted data would include those that if compromised or accessed without authorization could cause massive legal fines or cause damage to the company. Some examples of these internal restricted data apps are portals/apps used by teams like corporate strategy, mergers and acquisition teams, or research teams that have proprietary data.
The categorization of the internal facing OU into sub OUs gives option to set additional controls on these OUs based on the sensitivity of the workloads.
Security OU
Security OU has shared accounts that cater to security personnel. The OU is mainly for security tooling, so similar to SCP7, you can have an SCP with a subset of only needed services for this OU.
Known restrictions when working with SCPs
Here are some restrictions to keep in mind when working with SCPs:
- Maximum size of a policy document for SCPs is 5120 bytes (not characters)
- You can have only five levels deep of OUs under a root
- Service control policy
- Every entity must have at least one SCP attached at all times. You can’t remove the last SCP from an entity.
- Maximum SCPs attached to root is five
- Maximum SCPs attached per OU is five
- Maximum SCPs attached per account is five
- Note: These numbers apply to only those policies that are directly attached to an OU or an account. Policies that affect an OU or account by inheritance do not count against these limits.
Conclusion
In this blog, we’ve provided representative starter organization unit (OU) structure for an FSI customer, and also best practice guidance for service control policies (SCPs) to consider in a multi-account AWS environment. SCPs are a great tool for FSI customers to implement control and governance across your organization, created using AWS Organizations. By planning a multi-account OU structure based on our best practice guidance and using the recommended SCPs at each level, you can help ensure that you are meeting corporate and regulatory requirements. It also allows you to build custom environments within your organization to protect data, apply varying security controls, and meet the needs of both customers and internal users. Get started today and contact us if you would like to discuss establishing governance and control in your environment using SCPs.