Org Management account - AWS Prescriptive Guidance
Service control policiesIAM Identity CenterIAM access advisorAWS Systems ManagerAWS Control TowerAWS ArtifactDistributed and centralized security service guardrails

Org Management account

Influence the future of the AWS Security Reference Architecture (AWS SRA) by taking a short survey.

The following diagram illustrates the AWS security services that are configured in the Org Management account.

Security services for Org Management account

The sections Using AWS Organizations for security and The management account, trusted access, and delegated administrators earlier in this guide discussed the purpose and security objectives of the Org Management account in depth. Follow the security best practices for your Org Management account. These include using an email address that is managed by your business, maintaining the correct administrative and security contact information (such as attaching a phone number to the account in the event AWS needs to contact the owner of the account), enabling multi-factor authentication (MFA) for the all users, and regularly reviewing who has access to the Org Management account. Services deployed in the Org Management account should be configured with appropriate roles, trust policies, and other permissions so that the administrators of those services (who must access them in the Org Management account) cannot also inappropriately access other services.

Service control policies

With AWS Organizations, you can centrally manage policies across multiple AWS accounts. For example, you can apply service control policies (SCPs) across multiple AWS accounts that are members of an organization. SCPs allow you to define which AWS service APIs can and cannot be run by AWS Identity and Access Management (IAM) entities (such as IAM users and roles) in your organization's member AWS accounts. SCPs are created and applied from the Org management account, which is the AWS account that you used when you created your organization. Read more about SCPs in the Using AWS Organizations for security section earlier in this reference. 

If you use AWS Control Tower to manage your AWS organization, it will deploy a set of SCPs as preventative guardrails (categorized as mandatory, strongly recommended, or elective). These guardrails help you govern your resources by enforcing organization-wide security controls. These SCPs automatically use an aws-control-tower tag that has a value of managed-by-control-tower. 

Design consideration

  • SCPs affect only member accounts in the AWS organization. Although they are applied from the Org Management account, they have no effect on users or roles in that account. To learn about how SCP evaluation logic works, and to see examples of recommended structures, see the AWS blog post How to Use Service Control Policies in AWS Organizations.

IAM Identity Center

AWS IAM Identity Center (successor to AWS Single Sign-On) is an identity federation service that helps you centrally manage SSO access to all your AWS accounts, principals, and cloud workloads. IAM Identity Center also helps you manage access and permissions to commonly used third-party software as a service (SaaS) applications. Identity providers integrate with IAM Identity Center by using SAML 2.0. Bulk and just-in-time provisioning can be done by using the System for Cross-Domain Identity Management (SCIM). IAM Identity Center can also integrate with on-premises or AWS-managed Microsoft Active Directory (AD) domains as an identity provider through the use of AWS Directory Service. IAM Identity Center includes a user portal where your end-users can find and access their assigned AWS accounts, roles, cloud applications, and custom applications in one place.

IAM Identity Center natively integrates with AWS Organizations and runs in the Org Management account by default. However, to exercise least privilege and tightly control access to the management account, IAM Identity Center administration can be delegated to a specific member account. In the AWS SRA, the Shared Services account is the delegated administrator account for IAM Identity Center. Before you enable delegated administration for IAM Identity Center, review these considerations. You will find more information about delegation in the Shared Services account section. Even after you enable delegation, IAM Identity Center still needs to run in the Org Management account to perform certain IAM Identity Center related tasks, which include managing permission sets that are provisioned in the Org Management account. 

Within the IAM Identity Center console, accounts are displayed by their encapsulating OU. This enables you to quickly discover your AWS accounts, apply common sets of permissions, and manage access from a central location. 

IAM Identity Center includes an identity store where specific user information must be stored. However, IAM Identity Center does not have to be the authoritative source for workforce information. In cases where your enterprise already has an authoritative source, IAM Identity Center supports the following types of identity providers (IdPs).

  • IAM Identity Center Identity store – Choose this option if the following two options are not available. Users are created, group assignments are made, and permissions are assigned in the identity store. Even if your authoritative source is external to IAM Identity Center, a copy of principal attributes will be stored with the identity store.

  • Microsoft Active Directory (AD) – Choose this option if you want to continue managing users in either your directory in AWS Directory Service for Microsoft Active Directory or your self-managed directory in Active Directory.

  • External identity provider – Choose this option if you prefer to manage users in an external third-party, SAML-based IdP.

You can rely on an existing IdP that is already in place within your enterprise. This makes it easier to manage access across multiple applications and services, because you are creating, managing, and revoking access from a single location. For example, if someone leaves your team, you can revoke their access to all applications and services (including AWS accounts) from one location. This reduces the need for multiple credentials and provides you with an opportunity to integrate with your human resources (HR) processes.

Design consideration

  • Use an external IdP if that option is available to your enterprise. If your IdP supports System for Cross-Domain Identity Management (SCIM), take advantage of the SCIM capability in IAM Identity Center to automate user, group, and permission provisioning (synchronization). This allows AWS access to stay in sync with your corporate workflow for new hires, employees who are moving to another team, and employees who are leaving the company. At any given time, you can have only one directory or one SAML 2.0 identity provider connected to IAM Identity Center. However, you can switch to another identity provider.

IAM access advisor

IAM access advisor provides traceability data in the form of service last accessed information for your AWS accounts and OUs. Use this detective control to contribute to a least privilege strategy. For IAM entities, you can view two types of last accessed information: allowed AWS service information and allowed action information. The information includes the date and time when the attempt was made. 

IAM access within the Org Management account lets you view service last accessed data for the Org Management account, OU, member account, or IAM policy in your AWS organization. This information is available in the IAM console within the management account and can also be obtained programmatically by using IAM access advisor APIs in AWS Command Line Interface (AWS CLI) or a programmatic client. The information indicates which principals in an organization or account last attempted to access the service and when. Last accessed information provides insight for actual service usage (see example scenarios), so you can reduce IAM permissions to only those services that are actually used.

AWS Systems Manager

Quick Setup and Explorer, which are capabilities of AWS Systems Manager, both support AWS Organizations and operate from the Org Management account. 

Quick Setup is an automation feature of Systems Manager. It enables the Org Management account to easily define configurations for Systems Manager to engage on your behalf across accounts in your AWS organization. You can enable Quick Setup across your entire AWS organization or choose specific OUs. Quick Setup can schedule AWS Systems Manager Agent (SSM Agent) to run biweekly updates on your EC2 instances and can set up a daily scan of those instances to identify missing patches. 

Explorer is a customizable operations dashboard that reports information about your AWS resources. Explorer displays an aggregated view of operations data for your AWS accounts and across AWS Regions. This includes data about your EC2 instances and patch compliance details. After you complete Integrated Setup (which also includes Systems Manager OpsCenter) within AWS Organizations, you can aggregate data in Explorer by OU or for an entire AWS organization. Systems Manager aggregates the data into the AWS Org Management account before displaying it in Explorer.

The Workloads OU section later in this guide discusses the use of the Systems Manager Agent (SSM Agent) on the EC2 instances in the Application account.

AWS Control Tower

AWS Control Tower provides a straightforward way to set up and govern a secure, multi-account AWS environment, which is called a landing zone. AWS Control Tower creates your landing zone by using AWS Organizations, and provides ongoing account management and governance as well as implementation best practices. You can use AWS Control Tower to provision new accounts in a few steps while ensuring that the accounts conform to your organizational policies. You can even add existing accounts to a new AWS Control Tower environment. 

AWS Control Tower has a broad and flexible set of features. A key feature is its ability to orchestrate the capabilities of several other AWS services, including AWS Organizations, AWS Service Catalog, and IAM Identity Center, to build a landing zone. For examples, by default AWS Control Tower uses AWS CloudFormation to establish a baseline, AWS Organizations service control policies (SCPs) to prevent configuration changes, and AWS Config rules to continuously detect non-conformance. AWS Control Tower employs blueprints that help you quickly align your multi-account AWS environment with AWS Well Architected security foundation design principles. Among governance features, AWS Control Tower offers guardrails that prevent deployment of resources that don't conform to selected policies. 

You can get started implementing AWS SRA guidance with AWS Control Tower. For example, AWS Control Tower establishes an AWS organization with the recommended multi-account architecture. It provides blueprints to provide identity management, provide federated access to accounts, centralize logging, establish cross-account security audits, define a workflow for provisioning new accounts, and implement account baselines with network configurations. 

In the AWS SRA, AWS Control Tower is within the Org Management account because AWS Control Tower uses this account to set up an AWS organization automatically and designates that account as the management account. This account is used for billing across your AWS organization. It's also used for Account Factory provisioning of accounts, to manage OUs, and to manage guardrails. If you are launching AWS Control Tower in an existing AWS organization, you can use the existing management account. AWS Control Tower will use that account as the designated management account.

Design consideration

  • If you want to do additional baselining of controls and configurations across your accounts, you can use Customizations for AWS Control Tower (CfCT). With CfCT, you can customize your AWS Control Tower landing zone by using an AWS CloudFormation template and service control policies (SCPs). You can deploy the custom template and policies to individual accounts and OUs within your organization. CfCT integrates with AWS Control Tower lifecycle events to ensure that resource deployments stay in sync with your landing zone. 

AWS Artifact

AWS Artifact provides on-demand access to AWS security and compliance reports and select online agreements. Reports available in AWS Artifact include System and Organization Controls (SOC) reports, Payment Card Industry (PCI) reports, and certifications from accreditation bodies across geographies and compliance verticals that validate the implementation and operating effectiveness of AWS security controls. AWS Artifact helps you perform your due diligence of AWS with enhanced transparency into our security control environment. It also lets you continuously monitor the security and compliance of AWS with immediate access to new reports. 

AWS Artifact Agreements enable you to review, accept, and track the status of AWS agreements such as the Business Associate Addendum (BAA) for an individual account and for the accounts that are part of your organization in AWS Organizations. 

You can provide the AWS audit artifacts to your auditors or regulators as evidence of AWS security controls. You can also use the responsibility guidance provided by some of the AWS audit artifacts to design your cloud architecture. This guidance helps determine the additional security controls you can put in place to support the specific use cases of your system. 

AWS Artifacts is hosted in the Org Management account to provide a central location where you can review, accept, and manage agreements with AWS. This is because agreements that are accepted at the management account flow down to the member accounts. 

Design consideration

  • Users within the Org Management account should be restricted to use only the Agreements feature of AWS Artifact and nothing else. To implement segregation of duties, AWS Artifact is also hosted in the Security Tooling account where you can delegate permissions to your compliance stakeholders and external auditors to access audit artifacts. You can implement this separation by defining fine-grained IAM permission policies. For examples, see Example IAM policies in the AWS documentation.

Distributed and centralized security service guardrails

In the AWS SRA, AWS Security Hub, Amazon GuardDuty, AWS Config, IAM Access Analyzer, AWS CloudTrail organization trails, and often Amazon Macie are deployed with appropriate delegated administration or aggregation to the Security Tooling account. This enables a consistent set of guardrails across accounts and also provides centralized monitoring, management, and governance across your AWS organization. You will find this group of services in every type of account represented in the AWS SRA. These should be part of the AWS services that must be provisioned as part of your account onboarding and baselining process. The GitHub code repository provides a sample implementation of AWS security-focused services across your accounts, including the AWS Org Management account. 

In addition to these services, AWS SRA includes two security-focused services, Amazon Detective and AWS Audit Manager, which support the integration and delegated administrator functionality in AWS Organizations. However, those are not included as part of the recommended services for account baselining. We have seen that these services are best used in the following scenarios:

  • You have a dedicated team or group of resources that perform those digital forensics and IT audit functions. Amazon Detective is best utilized by security analyst teams, and AWS Audit Manager is helpful to your internal audit or compliance teams.

  • You want to focus on a core set of tools such as GuardDuty and Security Hub at the start of your project, and then build on these by using services that provide additional capabilities.