Infrastructure OU – Shared Services 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 Shared Services account.
The Shared Services account is part of the Infrastructure OU, and its purpose is to support the services that multiple applications and teams use to deliver their outcomes. For example, directory services (Active Directory), messaging services, and metadata services are in this category. The AWS SRA highlights the shared services that support security controls. Although the Network accounts are also part of the Infrastructure OU, they are removed from the Shared Services account to support the separation of duties. The teams that will manage these services don't need permissions or access to the Network accounts.
AWS Systems Manager
AWS Systems Manager
Systems Manager helps you work to maintain security and compliance by scanning your managed instances and reporting (or taking corrective action) on any policy violations it detects. By pairing Systems Manager with appropriate deployment in individual member AWS accounts (for example, the Application account), you can coordinate instance inventory data collection and centralize automation such as patching and security updates.
AWS Managed Microsoft AD
AWS Directory Service
AWS Managed Microsoft AD helps you extend your existing Active Directory to AWS and use your existing on-premises user credentials to access cloud resources. You can also administer your on-premises users, groups, applications, and systems without the complexity of running and maintaining an on-premises, highly available Active Directory. You can join your existing computers, laptops, and printers to an AWS Managed Microsoft AD domain.
AWS Managed Microsoft AD is built on Microsoft Active Directory and doesn't require you to synchronize or replicate data from your existing Active Directory to the cloud. You can use familiar Active Directory administration tools and features, such as Group Policy Objects (GPOs), domain trusts, fine-grained password policies, group Managed Service Accounts (gMSAs), schema extensions, and Kerberos-based single sign-on. You can also delegate administrative tasks and authorize access using Active Directory security groups.
Multi-Region replication enables you to deploy and use a single AWS Managed Microsoft AD directory across multiple AWS Regions. This makes it easier and more cost-effective for you to deploy and manage your Microsoft Windows and Linux workloads globally. When you use the automated multi-Region replication capability, you get higher resiliency while your applications use a local directory for optimal performance.
AWS Managed Microsoft AD supports Lightweight Directory Access Protocol (LDAP) over SSL/TLS, also known as LDAPS, in both client and server roles. When acting as a server, AWS Managed Microsoft AD supports LDAPS over ports 636 (SSL) and 389 (TLS). You enable server-side LDAPS communications by installing a certificate on your AWS Managed Microsoft AD domain controllers from an AWS-based Active Directory Certificate Services (AD CS) certificate authority (CA). When acting as a client, AWS Managed Microsoft AD supports LDAPS over ports 636 (SSL). You can enable client-side LDAPS communications by registering CA certificates from your server certificate issuers into AWS, and then enable LDAPS on your directory.
In the AWS SRA, AWS Directory Service is used within the Shared Services account to provide domain services for Microsoft-aware workloads across multiple AWS member accounts.
Design consideration
-
You can grant your on-premises Active Directory users access to sign in to the AWS Management Console and AWS Command Line Interface (AWS CLI) with their existing Active Directory credentials by using IAM Identity Center and selecting AWS Managed Microsoft AD as the identity source. This enables your users to assume one of their assigned roles at sign-in, and to access and take action on the resources according to the permissions defined for the role. An alternative option is to use AWS Managed Microsoft AD to enable your users to assume an AWS Identity and Access Management
(IAM) role.
IAM Identity Center
The AWS SRA uses the delegated administrator feature supported by IAM Identity Center to delegate most of the administration of IAM Identity Center to the Shared Services account. This helps restrict the number of users who require access to the Org Management account. IAM Identity Center still needs to be enabled in the Org Management account to perform certain tasks, including the management of permission sets that are provisioned within the Org Management account.
The primary reason for using the Shared Services account as the delegated administrator for IAM Identity Center is the Active Directory location. If you plan to use Active Directory as your IAM Identity Center identity source, you will need to locate the directory in the member account that you have designated as your IAM Identity Center delegated administrator account. In the AWS SRA, the Shared Services account hosts AWS Managed Microsoft AD, so that account is made the delegated administrator for IAM Identity Center.
IAM Identity Center supports the registration of a single member account as a delegated administrator at one time. You can register a member account only when you sign in with credentials from the management account. To enable delegation, you have to consider the prerequisites listed in the IAM Identity Center documentation. The delegated administrator account can perform most IAM Identity Center management tasks, but with some restrictions, which are listed in the IAM Identity Center documentation. Access to the IAM Identity Center delegated administrator account should be tightly controlled.
Design considerations
-
If you decide to change the IAM Identity Center identity source from any other source to Active Directory, or change it from Active Directory to any other source, the directory must reside in (be owned by) the IAM Identity Center delegated administrator member account, if one exists; otherwise, it must be in the management account.
-
You can host your AWS Managed Microsoft AD within a dedicated VPC in a different account and then use AWS Resource Access Manager (AWS RAM) to share subnets from this other account to the delegated administrator account. That way, the AWS Managed Microsoft AD instance is controlled in the delegated administrator account, but from the network perspective it acts as if it is deployed in the VPC of another account. This is helpful when you have multiple AWS Managed Microsoft AD instances and you want to deploy them locally to where your workload is running but manage them centrally through one account.
-
If you have a dedicated identity team that performs regular identity and access management activities or have strict security requirements to separate identity management functions from other shared services functions, you can host a dedicated AWS account for identity management. In this scenario, you designate this account as your delegated administrator for IAM Identity Center, and it also hosts your AWS Managed Microsoft AD directory. You can achieve the same level of logical isolation between your identity management workloads and other shared services workloads by using fine-grained IAM permissions within a single shared service account.
-
IAM Identity Center currently doesn't provide multi-Region support. (To enable IAM Identity Center in a different Region, you must first delete your current IAM Identity Center configuration.) Furthermore, it doesn’t support the use of different identity sources for different set of accounts or let you delegate permissions management to different parts of your organization (that is, multiple delegated administrators) or to different groups of administrators. If you require any of these features, you can use IAM federation to manage your user identities within an identity provider (IdP) outside of AWS and give these external user identities permission to use AWS resources in your account. IAM supports IdPs that are compatible with OpenID Connect (OIDC)
or SAML 2.0. As a best practice, use SAML 2.0 federation with third-party identity providers such as Active Directory Federation Service (AD FS), Okta, Azure Active Directory (Azure AD), or Ping Identity to provide single sign-on capability for users to log into the AWS Management Console or to call AWS API operations. For more information about IAM federation and identity providers, see About SAML 2.0-based federation in the IAM documentation and the AWS Identity Federation workshops .
