# Step 2c. Configure your shared accounts, logging, and encryption
In this section of the setup process, the panel shows the default selections for the names of your shared AWS Control Tower accounts. These accounts are an essential part of your landing zone. **Do not move or delete these shared accounts**. You can choose customized names for the **audit** and **log archive** accounts during setup. Alternatively, you have a one-time option to specify existing AWS accounts as your shared accounts.
You must provide unique email addresses for your log archive and audit accounts, and you can verify the email address that you previously provided for your management account. Choose the **Edit** button to change the editable default values.
**About the shared accounts**
+ **The management account** – The AWS Control Tower management account is part of the Root level. The management account allows for AWS Control Tower billing. The account also has administrator permissions for your landing zone. You cannot create separate accounts for billing and for administrator permissions in AWS Control Tower.
The email address shown for the management account is not editable during this phase of setup. It is shown as a confirmation, so you can check that you're editing the correct management account, in case you have multiple accounts.
+ **The two shared accounts** – You can choose customized names for these two accounts, or bring your own accounts, and you must supply a unique email address for each account, either new or existing. If you choose to have AWS Control Tower create new shared accounts for you, the email addresses must not already have associated AWS accounts.
**To configure the shared accounts, fill in the requested information.**
1. At the console, enter a name for the account initially called the **log archive** account. Many customers decide to keep the default name for this account.
1. Provide a unique email address for this account.
1. Enter a name for the account initially called the **audit** account. Many customers choose to call it the **Security** account.
1. Provide a unique email address for this account.
# Optionally configure log retention
During this phase of setup, you can customize the log retention policy for Amazon S3 buckets that store your AWS CloudTrail logs in AWS Control Tower, in increments of days or years, up to a maximum of 15 years. If you choose not to customize your log retention, the default settings are one year for standard account logging and 10 years for access logging. This feature also is available when you update or reset your landing zone.
# Optionally self-manage AWS account access
You can select whether AWS Control Tower sets up AWS account access with AWS Identity and Access Management (IAM), or whether to self-manage AWS account access—either with AWS IAM Identity Center users, roles, and permissions that you can set up and customize on your own, or with another method *such as an external IdP, either for direct account federation or federation to multiple accounts by means of IAM Identity Center*. You can change this selection later.
By default, AWS Control Tower sets up AWS IAM Identity Center for your landing zone, in alignment with best-practices guidance defined in [Organizing your AWS environment using multiple accounts](https://docs.aws.amazon.com//whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html). Most customers choose the default. Alternative access methods are required sometimes, for regulatory compliance in specific industries or countries, or in AWS Regions where AWS IAM Identity Center is not available.
Selection of identity providers at the account level is not supported. This option applies only for the landing zone as a whole.
For more information, see [IAM Identity Center guidance](sso-guidance.md).
# Optionally configure AWS CloudTrail trails
As a best practice, we recommend that you set up logging. If you wish to allow AWS Control Tower to set up an organization-level CloudTrail trail and manage it for you, choose **Opt in**. If you wish to manage logging with your own CloudTrail trails or a third-party logging tool, choose **Opt out**. Confirm your selection when requested to do so in the console. You can change your selection, and opt into, or opt out of, organization-level trails when you update your landing zone.
You can set up and manage your own CloudTrail trails at any time, including organization-level and account-level trails. If you set up duplicate CloudTrail trails, you may incur duplicate costs when CloudTrail events are logged.
# Optionally configure AWS KMS keys
If you wish to encrypt and decrypt your resources with an AWS KMS encryption key, select the checkbox. If you have existing keys, you'll be able to select them from identifiers displayed in a dropdown menu. You can generate a new key by choosing **Create a key**. You can add or change a KMS key any time you update your landing zone.
When you select **Set up landing zone**, AWS Control Tower performs a pre-check to validate your KMS key. The key must meet these requirements:
+ Enabled
+ Symmetric
+ Not a multi-Region key
+ Has correct permissions added to the policy
+ Key is in the management account
You may see an error banner if the key does not meet these requirements. In that case, choose another key or generate a key. Be sure to edit the key's permissions policy, as described in the next section.
## Update the KMS key policy
Before you can update a KMS key policy, you must create a KMS key. For more information, see [Creating a key policy](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-overview.html) in the *AWS Key Management Service Developer Guide*.
To use a KMS key with AWS Control Tower, you must update the default KMS key policy by adding the minimum required permissions for AWS Config and AWS CloudTrail. As a best practice, we recommend that you include the minimum required permissions in any policy. When updating a KMS key policy, you can add permissions as a group in a single JSON statement or line by line.
The procedure describes how to update the default KMS key policy in the AWS KMS console by adding policy statements that allow AWS Config and CloudTrail to use AWS KMS for encryption. The policy statements require that you include the following information:
+ **`YOUR-MANAGEMENT-ACCOUNT-ID`** – the ID of the management account in which AWS Control Tower will be set up.
+ **`YOUR-HOME-REGION`** – the home Region that you will select when setting up AWS Control Tower.
+ **`YOUR-KMS-KEY-ID`** – the KMS key ID that will be used with the policy.
**To update the KMS key policy**
1. Open the AWS KMS console at [https://console.aws.amazon.com//kms](https://console.aws.amazon.com//kms)
1. From the navigation pane, choose **Customer managed keys**.
1. In the table, select the key that you want to edit.
1. In the **Key policy** tab, make sure that you can view the key policy. If you can't view the key policy, choose **Switch to policy view**.
1. Choose **Edit**, and update the default KMS key policy by adding the following policy statements for AWS Config and CloudTrail.
**AWS Config policy statement**
```
{
"Sid": "Allow Config to use KMS for encryption",
"Effect": "Allow",
"Principal": {
"Service": "config.amazonaws.com"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "arn:aws:kms:YOUR-HOME-REGION:YOUR-MANAGEMENT-ACCOUNT-ID:key/YOUR-KMS-KEY-ID"
}
```
**CloudTrail policy statement**
```
{
"Sid": "Allow CloudTrail to use KMS for encryption",
"Effect": "Allow",
"Principal": {
"Service": "cloudtrail.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey*",
"kms:Decrypt"
],
"Resource": "arn:aws:kms:YOUR-HOME-REGION:YOUR-MANAGEMENT-ACCOUNT-ID:key/YOUR-KMS-KEY-ID",
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:aws:cloudtrail:YOUR-HOME-REGION:YOUR-MANAGEMENT-ACCOUNT-ID:trail/aws-controltower-BaselineCloudTrail"
},
"StringLike": {
"kms:EncryptionContext:aws:cloudtrail:arn": "arn:aws:cloudtrail:*:YOUR-MANAGEMENT-ACCOUNT-ID:trail/*"
}
}
}
```
1. Choose **Save changes**.
** Example KMS key policy **
The following example policy shows what your KMS key policy might look like after you add the policy statements that grant AWS Config and CloudTrail the minimum required permissions. The example policy doesn't include your default KMS key policy.
```
{
"Version": "2012-10-17",
"Id": "CustomKMSPolicy",
"Statement": [
{
... YOUR-EXISTING-POLICIES ...
},
{
"Sid": "Allow Config to use KMS for encryption",
"Effect": "Allow",
"Principal": {
"Service": "config.amazonaws.com"
},
"Action": [
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "arn:PARTITION:kms:YOUR-HOME-REGION:YOUR-MANAGEMENT-ACCOUNT-ID:key/YOUR-KMS-KEY-ID"
},
{
"Sid": "Allow CloudTrail to use KMS for encryption",
"Effect": "Allow",
"Principal": {
"Service": "cloudtrail.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey*",
"kms:Decrypt"
],
"Resource": "arn:PARTITION:kms:YOUR-HOME-REGION:YOUR-MANAGEMENT-ACCOUNT-ID:key/YOUR-KMS-KEY-ID",
"Condition": {
"StringEquals": {
"aws:SourceArn": "arn:PARTITION:cloudtrail:YOUR-HOME-REGION:YOUR-MANAGEMENT-ACCOUNT-ID:trail/aws-controltower-BaselineCloudTrail"
},
"StringLike": {
"kms:EncryptionContext:aws:cloudtrail:arn": "arn:PARTITION:cloudtrail:*:YOUR-MANAGEMENT-ACCOUNT-ID:trail/*"
}
}
}
]
}
```
To view other example policies, see the following pages:
+ [Granting encrypt permissions](https://docs.aws.amazon.com//awscloudtrail/latest/userguide/create-kms-key-policy-for-cloudtrail.html#create-kms-key-policy-for-cloudtrail-encrypt) in the *AWS CloudTrail User Guide*.
+ [Required Permissions for the KMS Key When Using Service-Linked RolesS3 Bucket Delivery)](https://docs.aws.amazon.com//config/latest/developerguide/s3-kms-key-policy.html#required-permissions-s3-kms-key-using-servicelinkedrole) in the *AWS Config Developer Guide*.
**Protect against attackers**
By adding certain conditions to your policies, you can help prevent a specific type of attack, known as a *confused deputy* attack, which occurs if an entity coerces a more-privileged entity to perform an action, such as with cross-service impersonation. For general information about policy conditions, also see [Specifying conditions in a policy](access-control-overview.md#specifying-conditions).
The AWS Key Management Service (AWS KMS) allows you to create multi-Region KMS keys and asymmetric keys; however, AWS Control Tower does not support multi-Region keys or asymmetric keys. AWS Control Tower performs a pre-check of your existing keys. You may see an error message if you select a multi-Region key or an asymmetric key. In that case, generate another key for use with AWS Control Tower resources.
For more information about AWS KMS, see [ the AWS KMS Developer Guide.](https://docs.aws.amazon.com//kms/latest/developerguide/overview.html)
Note that customer data in AWS Control Tower is encrypted at rest, by default, using SSE-S3.
# Optionally configure auto-enrollment for accounts
When you enable this feature during setup, or later, accounts that are moved between two registered OUs, or moved into your AWS Control Tower environment for the first time, no longer show a state of inheritance drift. The accounts automatically inherit the baselines and controls that are enabled on the new OU. Controls and baselines from the previous OU are removed.
To opt in for auto-enrollment at any time after setup, navigate to the landing zone **Settings** page and choose **Update** landing zone, or call the AWS Control Tower `UpdateLandingZone` API.
You can move an account between OUs by means of the AWS Organizations API, or by means of the AWS Control Tower console. If you move an account outside an OU that's registered, AWS Control Tower removes all deployed baselines and controls, automatically. It essentially unenrolls the account from AWS Control Tower.
**Note**
If you choose to enable the auto-enroll capability after initial setup of the landing zone, AWS Control Tower does not retroactively resolve the inheritance drift that was caused by moving accounts between OUs before the auto-enroll capability was enabled. The automatic drift resolution goes into effect for accounts that are moved after you enable this setting.
# Optionally configure and create customized member accounts
When you follow the **Create account** workflow to add your member accounts, you can optionally specify a previously-defined *blueprint* to use for provisioning customized member accounts from the AWS Control Tower console. You can customize accounts later if you do not have a blueprint available. See [Customize accounts with Account Factory Customization (AFC)](af-customization-page.md).