# Set up emergency access to the AWS Management Console IAM Identity Center is built from highly available AWS infrastructure and uses an Availability Zone architecture to eliminate single points of failure. For an extra layer of protection in the unlikely event of an IAM Identity Center or AWS Region disruption, we recommend that you set up a configuration that you can use to provide temporary access to the AWS Management Console. AWS enables you to: + [Connect your third-party IdP to IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html). + Connect your third-party IdP to individual AWS accounts by using [SAML 2.0-based federation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html). If you use IAM Identity Center, you can use these capabilities to create the emergency access configuration described in the following sections. This configuration enables you to use IAM Identity Center as the mechanism for AWS account access. If IAM Identity Center is disrupted, your emergency operations users can sign in to the AWS Management Console through direct federation, by using the same credentials that they use to access their accounts. This configuration works when IAM Identity Center is unavailable, but the IAM data plane and your external identity provider (IdP) are available . If you prefer to not depend on the external IdP, consider setting up [AWS break-glass access](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/ag.sad.5-implement-break-glass-procedures.html) **Important** We recommend that you deploy this configuration before a disruption occurs because you cannot create the configuration if your access to create the required IAM roles is also disrupted. Also, test this configuration periodically to ensure that your team understands what to do if IAM Identity Center is disrupted. **Topics** + [Summary of emergency access configuration](emergency-access-implementation.md) + [How to design your critical operations roles](emergency-access-implementation-design.md) + [How to plan your access model](emergency-access-planning.md) + [How to design emergency role, account, and group mapping](emergency-access-mapping-design.md) + [How to create your emergency access configuration](emergency-access-role-idp-group-creation-mapping-plan.md) + [Emergency preparation tasks](emergency-access-prepare-configuration.md) + [Emergency failover process](emergency-access-failover-steps.md) + [Return to normal operations](emergency-access-return-to-normal-operations.md) + [One-time setup of a direct IAM federation application in Okta](emergency-access-one-time-setup-direct-IAM-federation-application-in-idp.md) + [One-time setup of a direct IAM federation application with ADFS](emergency-access-one-time-setup-direct-IAM-federation-application-in-adfs.md) # Summary of emergency access configuration To configure emergency access, you must complete the following tasks: 1. [Create an emergency operations account in your organization in AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_create.html). This account will become your emergency operations account. 1. Connect your IdP to the emergency operations account by using [SAML 2.0-based federation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html). 1. In the emergency operations account, [create a role for third-party identity provider federation](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html). Also, create an emergency operations role in each of your workload accounts, with your required permissions. 1. [Delegate access to your workload accounts for the IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) that you created in the emergency operations account. To authorize access to your emergency operations account , create an emergency operations group in your IdP, with no members. 1. Enable the emergency operations group in your IdP to use the emergency operations role by creating a rule in your IdP that [enables SAML 2.0 federated access to the AWS Management Console](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html). During normal operations, no one has access to the emergency operations account because the emergency operations group in your IdP has no members. In the event of an IAM Identity Center disruption, use your IdP to add trusted users to the emergency operations group in your IdP. These users can then sign in to your IdP, navigate to the AWS Management Console, and assume the emergency operations role in the emergency operations account. From there, these users can [switch roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) to the emergency access role in your workload accounts where they need to perform operations work. # How to design your critical operations roles With this design, you configure a single AWS account in which you federate through IAM, so that users can assume critical operations roles. The critical operations roles have a trust policy that enables users to assume a corresponding role in your workload accounts. The roles in the workload accounts provide the permissions that users require to perform essential work. The following diagram provides a design overview. ![\[IAM Identity Center: create trust policy, emergency role for essential work in emergency account.\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/emergency-access-design.png) # How to plan your access model Before you configure emergency access, create a plan for how the access model will work. Use the following process to create this plan. 1. Identify the AWS accounts where emergency operator access is essential during a disruption to IAM Identity Center. For example, your production accounts are probably essential, but your development and test accounts might not be. 1. For that collection of accounts, identify the specific critical roles that you need in your accounts. Across these accounts, be consistent in defining what the roles can do. This simplifies work in your emergency access account where you create cross-account roles. We recommend that you start with two distinct roles in these accounts: Read Only (RO) and Operations (Ops). If required, you can create more roles and map these roles to a more distinct group of emergency access users in your setup. 1. Identify and create emergency access groups in your IdP. The group members are the users to whom you are delegating access to emergency access roles. 1. Define which roles these groups can assume in the emergency access account. To do this, define rules in your IdP that generate claims that list which roles the group can access. These groups can then assume your Read Only or Operations roles in emergency access account. From those roles, they can assume corresponding roles in your workload accounts. # How to design emergency role, account, and group mapping The following diagram shows how to map your emergency access groups to roles in your emergency access account. The diagram also shows the cross-account role trust relationships that enable emergency access account roles to access corresponding roles in your workload accounts. We recommend that your emergency plan design use these mappings as a starting point. ![\[IAM Identity Center workflow: map emergency access groups to roles in emergency account.\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/emergency-access-mapping.png) # How to create your emergency access configuration Use the following mapping table to create your emergency access configuration. This table reflects a plan that includes two roles in the workload accounts: Read Only (RO) and Operations (Ops) , with corresponding trust policies and permissions policies. The trust policies enable the emergency access account roles to access the individual workload account roles. The individual workload account roles also have permissions policies for what the role can do in the account. The permissions policies can be [AWS managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) or [customer managed policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies). **** | Account | Roles to create | Trust policy | Permissions policy | | --- | --- | --- | --- | | Account 1 | EmergencyAccess\$1RO | EmergencyAccess\$1Role1\$1RO | arn:aws:iam::aws:policy/ReadOnlyAccess | | Account 1 | EmergencyAccess\$1Ops | EmergencyAccess\$1Role1\$1Ops | arn:aws:iam::aws:policy/job-function/SystemAdministrator | | Account 2 | EmergencyAccess\$1RO | EmergencyAccess\$1Role2\$1RO | arn:aws:iam::aws:policy/ReadOnlyAccess | | Account 2 | EmergencyAccess\$1Ops | EmergencyAccess\$1Role2\$1Ops | arn:aws:iam::aws:policy/job-function/SystemAdministrator | | Emergency access account | EmergencyAccess\$1Role1\$1RO EmergencyAccess\$1Role1\$1Ops EmergencyAccess\$1Role2\$1RO EmergencyAccess\$1Role2\$1Ops | IdP | AssumeRole for role resource in account | In this mapping plan, the emergency access account contains two read-only roles and two operations roles. These roles trust your IdP to authenticate and authorize your selected groups to access the roles by passing the names of the roles in assertions. There are corresponding read-only and operations roles in workload Account 1 and Account 2. For workload Account 1, the `EmergencyAccess_RO` role trusts the `EmergencyAccess_Role1_RO` role that resides in the emergency access account. The table specifies similar trust patterns between the workload account read-only and operations roles and the corresponding emergency access roles. # Emergency preparation tasks To prepare your emergency access configuration, we recommend that you perform the following tasks before an emergency occurs. 1. Set up a direct IAM federation application in your IdP. If you are using Okta or other external IdPs as your identity source, see [One-time setup of a direct IAM federation application in Okta](emergency-access-one-time-setup-direct-IAM-federation-application-in-idp.md). If you are using Active Directory as your identity source, see [One-time setup of a direct IAM federation application with ADFS](emergency-access-one-time-setup-direct-IAM-federation-application-in-adfs.md). 1. Create an IdP connection in the emergency access account that can be accessed during the event. 1. Create emergency access roles in the emergency access accounts as described in the mapping table above. 1. Create temporary operations roles with trust and permission policies in each of the workload accounts. 1. Create temporary operations groups in your IdP. The group names will depend on the names of the temporary operations roles. 1. Test direct IAM federation. 1. Disable the IdP federation application in your IdP to prevent regular usage. # Emergency failover process When an IAM Identity Center instance isn't available and you determine that you must provide emergency access to the AWS Management Console, we recommend the following failover process. 1. The IdP administrator enables the direct IAM federation application in your IdP. 1. Users request access to the temporary operations group through your existing mechanism, such as an email request, Slack channel, or other form of communication. 1. Users that you add to your emergency access groups sign in to the IdP, select the emergency access account, and, users choose a role to use in the emergency access account. From these roles, they can assume roles in corresponding workload accounts that have cross-account trust with the emergency account role. # Return to normal operations Check the [AWS Health Dashboard](https://health.aws.amazon.com/health/status) to confirm when the health of the IAM Identity Center service is restored. To return to normal operations, perform the following steps. 1. After the status icon for the IAM Identity Center service indicates that the service is healthy, sign in to IAM Identity Center. 1. If you can sign in to IAM Identity Center successfully, communicate to emergency access users that IAM Identity Center is available. Instruct these users to sign out and use the AWS access portal to sign back in to IAM Identity Center. 1. After all emergency access users sign out, in the IdP, disable the IdP federation application. We recommend that you perform this task after working hours. 1. Remove all users from the emergency access group in the IdP. Your emergency access role infrastructure remains in place as a backup access plan, but it is now disabled. # One-time setup of a direct IAM federation application in Okta 1. Sign in to your Okta account as a user with administrative permissions. 1. In the Okta Admin Console, under **Applications**, choose **Applications.** 1. Choose **Browse App Catalog**. Search for and choose **AWS Account Federation**. Then choose **Add integration**. 1. Set up direct IAM federation with AWS by following the steps in [ How to Configure SAML 2.0 for AWS Account Federation](https://saml-doc.okta.com/SAML_Docs/How-to-Configure-SAML-2.0-for-Amazon-Web-Service.html). To handle regional failure scenarios, when you configure the sign-in endpoint, we recommend that you enable both the non-regional endpoint and multiple regional endpoints for all Regions you operate in to improve federation resiliency. When configuring the ACS URL for this emergency access, we recommend that you use the regional endpoint of a different Region than the one that your IAM Identity Center is deployed in. Refer to [Sign-in endpoints](https://docs.aws.amazon.com/general/latest/gr/signin-service.html) in the *AWS General Reference* for the list of regional endpoints. 1. On the **Sign-On Options** tab, select SAML 2.0 and enter **Group Filter** and **Role Value Pattern** settings. The name of the group for the user directory depends on the filter that you configure. ![\[Two options: accountid and role in group filter or role value pattern.\]](http://docs.aws.amazon.com/singlesignon/latest/userguide/images/emergency-access-group-filter-role-value-pattern.png) In the figure above, the `role` variable is for the emergency operations role in your emergency access account. For example, if you create the `EmergencyAccess_Role1_RO` role (as described in the mapping table) in AWS account `123456789012`, and if your group filter setting is configured as shown in the figure above, your group name should be `aws#EmergencyAccess_Role1_RO#123456789012`. 1. In your directory (for example, your directory in Active Directory), create the emergency access group and specify a name for the directory (for example, `aws#EmergencyAccess_Role1_RO#123456789012`). Assign your users to this group by using your existing provisioning mechanism. 1. In the emergency access account, [configure a custom trust policy](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html) that provides the permissions required for the emergency access role to be assumed during a disruption. Following is an example statement for a custom **trust policy** that is attached to the `EmergencyAccess_Role1_RO` role. For an illustration, see the emergency account in the diagram under [How to design emergency role, account, and group mapping ](emergency-access-mapping-design.md). Replace the sample SAML provider ARN with the correct one you have created in the emergency access account. Replace the regional endpoints in the example with those regions of your choice. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect":"Allow", "Principal":{ "Federated":"arn:aws:iam::123456789012:saml-provider/[SAML PROVIDER NAME]" }, "Action":[ "sts:AssumeRoleWithSAML", "sts:TagSession" ], "Condition":{ "StringEquals":{ "SAML:aud": [ "https://signin.aws.amazon.com/saml", "https://us-west-2.signin.aws.amazon.com/saml", "https://us-west-1.signin.aws.amazon.com/saml", "https://us-east-2.signin.aws.amazon.com/saml" ] } } }, { "Effect":"Allow", "Principal":{ "Federated":"arn:aws:iam::123456789012:saml-provider/Okta" }, "Action":"sts:SetSourceIdentity" } ] } ``` ------ 1. The following is an example statement for a **permissions policy** that is attached to the `EmergencyAccess_Role1_RO` role. For an illustration, see the emergency account in the diagram under [How to design emergency role, account, and group mapping ](emergency-access-mapping-design.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": [ "arn:aws:iam::111122223333:role/EmergencyAccess_RO", "arn:aws:iam::444455556666:role/EmergencyAccess_RO" ] } ] } ``` ------ 1. On the workload accounts, configure a custom trust policy. Following is an example statement for a **trust policy** that is attached to the `EmergencyAccess_RO` role. In this example, account `123456789012` is the emergency access account. For an illustration, see workload account in the diagram under [How to design emergency role, account, and group mapping ](emergency-access-mapping-design.md). ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Principal":{ "AWS":"arn:aws:iam::123456789012:root" }, "Action":"sts:AssumeRole" } ] } ``` ------ **Note** Most IdPs enable you to keep an application integration deactivated until required. We recommend that you keep the direct IAM federation application deactivated in your IdP until required for emergency access. # One-time setup of a direct IAM federation application with ADFS This guide describes the one-time setup process for configuring direct IAM federation with ADFS to enable emergency access to AWS accounts when IAM Identity Center is unavailable. ## Prerequisites If you plan to configure ADFS with AWS Managed Microsoft AD, we recommend that you first [configure Multi-Region replication](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_configure_multi_region_replication.html) and continue with the following steps in the additional Region and not in the primary Region for resiliency. ## Plan your Active Directory group naming convention Create AD groups using a specific naming pattern that enables automated matching between group names and AWS IAM roles. **Group naming format**: `AWS--` For an illustration, see the emergency account in the diagram under [How to design emergency role, account, and group mapping ](emergency-access-mapping-design.md). When a user is assigned to this group, they are granted access to the `EmergencyAccess_Role1_RO` role in account `123456789012`. If a user is associated with multiple groups, they see a list of available roles by AWS account and can choose which role to assume. ## AWS configuration The complete setup includes configurations in an emergency access account and the workload accounts. For an illustration of the overall setup, see [How to design emergency role, account, and group mapping ](emergency-access-mapping-design.md). 1. [Create a SAML identity provider](#emergency-access-adfs-create-saml-provider) 1. [Create emergency access roles](#emergency-access-adfs-create-roles) 1. [Configure workload account roles](#emergency-access-adfs-configure-workload-accounts) ### Create a SAML identity provider In the emergency access account, create a SAML identity provider in IAM by following the steps in [Create a SAML identity provider in IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html). Download the required metadata from your ADFS server: `https:///FederationMetadata/2007-06/FederationMetadata.xml` ### Create emergency access roles [Create emergency access roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_saml.html) in the emergency account using SAML 2.0 Federation as the trusted entity type. Select the SAML 2.0 provider you created in the previous step. **Considerations:** + **Include all Regions where you operate** — select every Region in which you have active workloads to ensure federation remains available during a Regional disruption. + **Configure at least one additional Regional endpoint, even if you operate in a single Region** — for example, if you operate only in `us-east-1`, add `us-west-2` as a secondary endpoint. You can fail over your IdP to the `us-west-2` SAML sign-in endpoint and still access your `us-east-1` resources, even without any workloads in `us-west-2`. + **Enable both the non-regional endpoint and regional endpoints** — Although the non-regional endpoint (`https://signin.aws.amazon.com/saml`) is highly available, it is hosted in a single AWS Region, `us-east-1`, while regional endpoints (`https://.signin.aws.amazon.com/saml`) improve resiliency by reducing dependency on a single global endpoint. **Configure trust policy** Refer to [One-time setup of a direct IAM federation application in Okta](emergency-access-one-time-setup-direct-IAM-federation-application-in-idp.md) for an example trust policy with multiple sign-in regional endpoints. Replace the sample regional endpoints and SAML provider ARNs with yours. **Configure permissions policies** Refer to [One-time setup of a direct IAM federation application in Okta](emergency-access-one-time-setup-direct-IAM-federation-application-in-idp.md) for an example permissions policy that you attach to the emergency access roles. ### Configure workload account roles For the workload account roles, configure a custom trust policy that allows the emergency access roles in the emergency access account to assume them. Refer to [One-time setup of a direct IAM federation application in Okta](emergency-access-one-time-setup-direct-IAM-federation-application-in-idp.md) for an example trust policy, where account `123456789012` is the emergency access account. ## Active Directory configuration The following steps describe how to configure Active Directory and ADFS for emergency access. 1. [Create groups](#emergency-access-adfs-create-groups) 1. [Create a relying party](#emergency-access-adfs-create-relying-party) 1. [Create claim rules](#emergency-access-adfs-create-claim-rules) ### Create groups Create emergency groups in Active Directory according to the naming convention described earlier (for example, `AWS-123456789012-EmergencyAccess_Role1_RO`). Assign users to these groups through your existing provisioning mechanisms. ### Create a relying party ADFS federation requires a relying party configuration. The relying party is AWS Security Token Service (AWS STS), which outsources authentication to ADFS as the identity provider. 1. In the ADFS Management console, use the Action menu and select **Add Relying Party Trust**. Select **Claims aware** when adding a relying party. 1. For federation metadata, enter the Metadata URL from the identity provider metadata info on the IAM console. For example: `https://signin.aws.amazon.com/static/saml/SAMLSPXXXXXX/saml-metadata.xml` 1. Set the display name for the relying party (for example, **AWS Account Access**) and then choose **Next**. 1. Select who you want to enable to access AWS. You can select specific groups and define requirements like MFA. 1. Choose **Close** on the Finish page to complete the Add Relying Party Trust Wizard. AWS is now configured as a relying party. ### Create claim rules ADFS uses Claims Rule Language to issue and transform claims between claims providers and relying parties. You need to create four claim rules: NameId, RoleSessionName, Get AD Groups, and Roles for AWS Access. Right-click on the relying party and then choose **Edit Claim Issuance Policy**. Choose **Add Rule** to add rules. **1. NameId** 1. Select **Transform an Incoming Claim** and then choose **Next**. 1. Use the following settings: + Claim rule name: `NameId` + Incoming claim type: `Windows Account Name` + Outgoing claim type: `Name ID` + Outgoing name ID format: `Persistent Identifier` + Pass through all claim values: checked 1. Choose **OK**. **2. RoleSessionName** 1. Choose **Add Rule**. 1. In the Claim rule template list, select **Send LDAP Attributes as Claims**. 1. Use the following settings: + Claim rule name: `RoleSessionName` + Attribute store: `Active Directory` + LDAP Attribute: `E-Mail-Addresses` + Outgoing Claim type: `https://aws.amazon.com/SAML/Attributes/RoleSessionName` 1. Choose **OK**. **3. Get AD Groups** 1. Choose **Add Rule**. 1. In the Claim rule template list, select **Send Claims Using a Custom Rule** and then choose **Next**. 1. For Claim Rule Name, enter `Get AD Groups`, and then in Custom rule, enter the following: ``` c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => add(store = "Active Directory", types = ("http://temp/variable"), query = ";tokenGroups;{0}", param = c.Value); ``` This custom rule uses a script in the claim rule language that retrieves all the groups the authenticated user is a member of and places them into a temporary claim named `http://temp/variable`. **Note** Ensure there's no trailing whitespace to avoid unexpected results. **4. Role Attributes** 1. Choose **Add Rule**. 1. In the Claim rule template list, select **Send Claims Using a Custom Rule** and then choose **Next**. 1. For Claim Rule Name, enter `Roles`, and then in Custom rule, enter the following: ``` c:[Type == "http://temp/variable", Value =~ "(?i)^AWS-([\d]{12})"] => issue(Type = "https://aws.amazon.com/SAML/Attributes/Role", Value = RegExReplace(c.Value, "AWS-([\d]{12})-", "arn:aws:iam::$1:saml-provider/,arn:aws:iam::$1:role/")); ``` This custom rule uses regular expressions to transform each of the group memberships of the form `AWS--` into the IAM role ARN and IAM federation provider ARN form that AWS expects. **Note** In the example rule language above, `ADFS` represents the logical name given to the SAML identity provider in the AWS identity provider setup. Change this based on the logical name you chose in the IAM console for your identity provider. ## Test the configuration Test that the solution works by authenticating at `https:///adfs/ls/IdpInitiatedSignOn.aspx`. Select the name of the relying party you created from the dropdown list of the sites. ## Update default SAML assertion endpoint in ADFS **Important** When configuring relying party trust in ADFS, the SAML Assertion endpoint defaults to `https://signin.aws.amazon.com/` which is not a global endpoint and is located in `us-east-1`. We recommend that you modify the default endpoint to a regional endpoint different from where your IAM Identity Center is configured for resiliency. For example, if your IAM Identity Center is deployed in `us-east-1` and you also operate in `us-west-2`, change the default SAML Assertion consumer endpoint to `https://us-west-2.signin.aws.amazon.com/saml`. 1. Choose **Properties** on the relying party trust and go to the **Monitoring** tab. Clear the checkbox **Automatically Update relying party**. 1. Go to the **Endpoints** tab, select your preferred sign-in endpoint, and choose **Edit**. 1. Select the checkbox **Set the trusted URL as default**. Choose **OK** and **Apply** for the setting to take effect. **Note** Most IdPs enable you to keep an application integration deactivated until required. We recommend that you keep the direct IAM federation application deactivated in your IdP until required for emergency access.