기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 에 대한 긴급 액세스 설정 AWS Management Console IAM Identity Center는 고가용성 AWS 인프라를 기반으로 구축되었으며 가용 영역 아키텍처를 사용하여 단일 장애 지점을 제거합니다. 드물지만 IAM Identity Center 또는 AWS 리전 중단이 발생할 경우 추가 보호 계층을 위해에 대한 임시 액세스를 제공하는 데 사용할 수 있는 구성을 설정하는 것이 좋습니다 AWS Management Console. AWS 를 사용하면 다음을 수행할 수 있습니다. + [타사 IdP를 IAM Identity Center에 연결합니다](https://docs.aws.amazon.com/singlesignon/latest/userguide/manage-your-identity-source-idp.html). + SAML 2.0 기반 페더레이션을 사용하여 타사 IdP를 개별 AWS 계정 에 연결합니다. [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html) IAM Identity Center를 사용하면 이러한 기능을 사용하여 다음 섹션에 설명된 비상 액세스 구성을 생성할 수 있습니다. 이 구성을 사용하면 IAM Identity Center를 AWS 계정 액세스 메커니즘으로 사용할 수 있습니다. IAM Identity Center가 중단되면 비상 운영 사용자는 계정에 액세스하는 데 사용하는 것과 동일한 자격 증명을 사용하여 직접 페더레이션을 AWS Management Console 통해에 로그인할 수 있습니다. 이 구성은 IAM Identity Center를 사용할 수 없지만 IAM 데이터 영역과 외부 ID 제공업체(idP)를 사용할 수 있는 경우에 작동합니다. 외부 IdP에 의존하지 않으려면 [AWS 브레이크 글래스 액세스를](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/ag.sad.5-implement-break-glass-procedures.html) 설정하는 것이 좋습니다. **중요** 필요한 IAM 역할을 생성하기 위한 액세스 권한도 중단되면 구성을 생성할 수 없으므로 중단이 발생하기 전에 이 구성을 배포하는 것이 좋습니다. 또한, IAM Identity Center가 중단될 경우 팀에서 어떤 조치를 취해야 하는지 파악할 수 있도록 이 구성을 주기적으로 테스트합니다. **Topics** + [비상 액세스 구성 요약](emergency-access-implementation.md) + [중요 운영 역할을 설계하는 방법](emergency-access-implementation-design.md) + [액세스 모델을 계획하는 방법](emergency-access-planning.md) + [비상 역할, 계정 및 그룹 매핑을 설계하는 방법](emergency-access-mapping-design.md) + [비상 액세스 구성을 만드는 방법](emergency-access-role-idp-group-creation-mapping-plan.md) + [비상 상황 대비 작업](emergency-access-prepare-configuration.md) + [비상 장애 조치 프로세스](emergency-access-failover-steps.md) + [정상 작동 상태로 복귀합니다.](emergency-access-return-to-normal-operations.md) + [Okta에서 직접 IAM 페더레이션 애플리케이션을 한 번만 설정하면 됩니다.](emergency-access-one-time-setup-direct-IAM-federation-application-in-idp.md) + [를 사용하여 직접 IAM 페더레이션 애플리케이션의 일회성 설정 ADFS](emergency-access-one-time-setup-direct-IAM-federation-application-in-adfs.md) # 비상 액세스 구성 요약 긴급 액세스를 구성하려면 다음 작업을 완료해야 합니다. 1. [AWS Organizations에서 조직의 비상 운영 계정을 계정을 만듭니다](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_create.html). 이 계정은 비상 운영 계정이 됩니다. 1. [SAML 2.0 기반 페더레이션](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html)을 사용하여 IdP를 IdP를 비상 운영 계정에 연결합니다. 1. 비상 운영 계정에서 [제3자 ID 제공업체 페더레이션에 필요한 역할을 생성합니다](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp.html). 또한 필요한 권한을 사용하여 각 워크로드 계정에서 비상 운영 역할을 생성합니다. 1. [비상 운영 계정에서 생성한 IAM 역할의 워크로드 계정에 대한 액세스 권한을 위임합니다](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html). 비상 운영 계정에 대한 액세스를 승인하려면 구성원 없이 IdP에 비상 운영 그룹을 생성합니다. 1. IdP에 [AWS Management Console에 대한 SSAML 2.0 페더레이션 액세스를 활성화](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)하는 규칙을 생성하여 IdP의 비상 운영 그룹이 비상 운영 역할을 사용하도록 설정합니다. 정상 운영 중에는 IdP의 비상 운영 그룹에 구성원이 없으므로 아무도 비상 운영 계정에 액세스할 수 없습니다. IAM Identity Center가 중단되는 경우 IdP를 사용하여 신뢰할 수 있는 사용자를 IdP의 비상 운영 그룹에 추가합니다. 그런 다음 이러한 사용자는 IdP에 로그인하고, 로 이동하고 AWS Management Console, 비상 운영 계정에서 비상 운영 역할을 수임할 수 있습니다. 여기에서 해당 사용자는 비상 운영을 수행해야 하는 워크로드 계정에서 비상 액세스 역할로 [역할을 전환](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)할 수 있습니다. # 중요 운영 역할을 설계하는 방법 이 설계에서는 사용자가 중요한 운영 역할을 수임할 수 있도록 IAM을 통해 페더레이션 AWS 계정 하는 단일를 구성합니다. 중요 운영 역할에는 사용자가 워크로드 계정에서 해당 역할을 맡을 수 있도록 하는 신뢰 정책이 있습니다. 워크로드 계정의 역할은 사용자가 필수 작업을 수행하는 데 필요한 권한을 제공합니다. 다음 다이어그램은 디자인 개요를 보여줍니다. ![\[IAM Identity Center: 비상 계정 내 필수 작업을 위한 신뢰 정책, 비상 역할을 생성합니다.\]](http://docs.aws.amazon.com/ko_kr/singlesignon/latest/userguide/images/emergency-access-design.png) # 액세스 모델을 계획하는 방법 비상 액세스를 구성하기 전에 액세스 모델 작동 방식에 대한 계획을 세웁니다. 다음 프로세스를 사용하여 이 계획을 생성합니다. 1. IAM Identity Center 중단 시 AWS 계정 긴급 운영자 액세스가 필요한을 식별합니다. 예를 들어 프로덕션 계정은 필수적이지만 개발 및 테스트 계정은 그렇지 않을 수 있습니다. 1. 해당 계정 모음에서 계정에 필요한 중요 역할을 파악합니다. 이러한 계정에서 각 역할이 수행할 수 있는 작업을 일관성 있게 정의합니다. 이렇게 하면 교차 계정 역할을 생성하는 비상 액세스 계정에서의 작업이 간소화됩니다. 이러한 계정에서는 읽기 전용(RO)과 운영(Ops) 이렇게 두 가지 역할로 시작하는 것이 좋습니다. 필요한 경우 더 많은 역할을 생성하고 이러한 역할을 설정에서 더 많은 비상 액세스 사용자 그룹에 매핑할 수 있습니다. 1. IdP에서 비상 액세스 그룹을 식별하고 생성합니다. 그룹 구성원은 비상 액세스 역할에 대한 액세스 권한을 위임하는 사용자입니다. 1. 비상 액세스 계정에서 이러한 그룹이 맡을 수 있는 역할을 정의합니다. 이렇게 하려면 그룹이 액세스할 수 있는 역할을 표시하는 클레임을 생성하는 규칙을 IdP에서 정의합니다. 그러면 이러한 그룹이 비상 액세스 계정에서 읽기 전용 또는 운영 역할을 맡을 수 있습니다. 이러한 역할을 통해 워크로드 계정에서 해당 역할을 맡을 수 있습니다. # 비상 역할, 계정 및 그룹 매핑을 설계하는 방법 다음 다이어그램은 비상 액세스 그룹을 비상 액세스 계정의 역할에 매핑하는 방법입니다. 이 다이어그램에는 비상 액세스 계정 역할이 워크로드 계정의 해당 역할에 액세스할 수 있도록 하는 계정 간 역할 신뢰 관계도 나와 있습니다. 비상 계획 설계 시 이러한 매핑을 출발점으로 삼는 것이 좋습니다. ![\[IAM Identity Center 워크플로: 비상 액세스 그룹을 비상 계정 내 역할에 매핑합니다.\]](http://docs.aws.amazon.com/ko_kr/singlesignon/latest/userguide/images/emergency-access-mapping.png) # 비상 액세스 구성을 만드는 방법 다음 매핑 표를 사용하여 비상 액세스 구성을 만듭니다. 이 표에는 워크로드 계정에서 읽기 전용(RO) 및 운영(Ops) 이렇게 두 가지 역할과 해당 신뢰 정책 및 권한 정책이 명시된 계획이 나와 있습니다. 신뢰 정책을 사용하면 비상 액세스 계정 역할이 개별 워크로드 계정 역할에 액세스할 수 있습니다. 개별 워크로드 계정 역할에는 해당 역할이 계정에서 수행할 수 있는 작업에 대한 권한 정책도 포함되어 있습니다. 권한 정책은 [AWS 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) 또는 [고객 관리형 정책](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)일 수 있습니다. **** | Account | 역할 생성 | 신뢰 정책 | 권한 정책 | | --- | --- | --- | --- | | 계정 1 | EmergencyAccess\$1RO | EmergencyAccess\$1Role1\$1RO | arn:aws:iam::aws:policy/ReadOnlyAccess | | 계정 1 | EmergencyAccess\$1Ops | EmergencyAccess\$1Role1\$1Ops | arn:aws:iam::aws:policy/job-function/SystemAdministrator | | 계정 2 | EmergencyAccess\$1RO | EmergencyAccess\$1Role2\$1RO | arn:aws:iam::aws:policy/ReadOnlyAccess | | 계정 2 | EmergencyAccess\$1Ops | EmergencyAccess\$1Role2\$1Ops | arn:aws:iam::aws:policy/job-function/SystemAdministrator | | 비상 액세스 계정 | EmergencyAccess\$1Role1\$1RO EmergencyAccess\$1Role1\$1Ops EmergencyAccess\$1Role2\$1RO EmergencyAccess\$1Role2\$1Ops | IdP | 계정의 역할 리소스에 대한 AssumeRole | 이 매핑 계획에서 비상 액세스 계정에는 읽기 전용 역할 2개와 운영 역할 2개가 포함되어 있습니다. 이러한 역할은 IdP를 신뢰하여 어설션에 역할의 이름을 전달함으로써 선택한 그룹이 역할에 액세스할 수 있도록 인증하고 권한을 부여합니다. 워크로드 계정 1과 계정 2에는 해당하는 읽기 전용 및 운영 역할이 있습니다. 워크로드 계정 1의 경우 `EmergencyAccess_RO` 역할은 비상 액세스 계정에 있는 `EmergencyAccess_Role1_RO` 역할을 신뢰합니다. 이 표에는 워크로드 계정 읽기 전용 및 운영 역할과 해당 비상 액세스 역할 간 유사한 신뢰 패턴이 나와 있습니다. # 비상 상황 대비 작업 비상 액세스 구성을 준비하려면 비상 상황이 발생하기 전에 다음 작업을 수행하는 것이 좋습니다. 1. IdP에서 직접 IAM 페더레이션 애플리케이션을 설정합니다. Okta 또는 기타 외부 IdPs ID 소스로 사용하는 경우 섹션을 참조하세요[Okta에서 직접 IAM 페더레이션 애플리케이션을 한 번만 설정하면 됩니다.](emergency-access-one-time-setup-direct-IAM-federation-application-in-idp.md). Active Directory를 ID 소스로 사용하는 경우 섹션을 참조하세요[를 사용하여 직접 IAM 페더레이션 애플리케이션의 일회성 설정 ADFS](emergency-access-one-time-setup-direct-IAM-federation-application-in-adfs.md). 1. 이벤트 중에 액세스할 수 있는 비상 액세스 계정에서 IdP 연결을 만듭니다. 1. 위의 매핑 표에 설명된 대로 비상 액세스 계정에 비상 액세스 역할을 만듭니다. 1. 각 워크로드 계정에서 신뢰 및 권한 정책을 사용하여 임시 운영 역할을 만듭니다. 1. IdP에서 임시 운영 그룹을 생성합니다. 그룹 이름은 임시 운영 역할의 이름에 따라 달라집니다. 1. 직접 IAM 페더레이션을 테스트합니다. 1. 정기적인 사용을 방지하기 위해 IdP에서 IdP 페더레이션 애플리케이션을 비활성화합니다. # 비상 장애 조치 프로세스 IAM Identity Center 인스턴스를 사용할 수 없고 AWS Management Console에 대한 긴급 액세스를 제공해야 한다고 판단되면 다음 장애 조치 프로세스를 권장합니다. 1. IdP 관리자는 IdP에서 직접 IAM 페더레이션 애플리케이션을 활성화합니다. 1. 사용자는 이메일 요청, Slack 채널 또는 기타 통신 형식과 같은 기존 메커니즘을 통해 임시 운영 그룹에 대한 액세스를 요청합니다. 1. 비상 액세스 그룹에 추가한 사용자는 IdP에 로그인하고, 비상 액세스 계정을 선택하고, 사용자는 비상 액세스 계정에서 사용할 역할을 선택합니다. 이러한 역할 중에서 비상 계정 역할과 계정 간 신뢰를 갖는 해당 워크로드 계정의 역할을 맡을 수 있습니다. # 정상 작동 상태로 복귀합니다. [AWS 상태 대시보드](https://health.aws.amazon.com/health/status)를 확인하여 IAM Identity Center 서비스의 상태가 복원되는 시기를 확인합니다. 정상 작동으로 돌아가려면 다음 단계를 수행합니다. 1. IAM Identity Center 서비스의 상태 아이콘이 서비스가 정상이라고 표시되면 IAM Identity Center에 로그인합니다. 1. IAM Identity Center에 성공적으로 로그인할 수 있으면 비상 액세스 사용자에게 IAM Identity Center를 사용할 수 있다고 전달합니다. 이러한 사용자에게 로그아웃하고 AWS 액세스 포털을 사용하여 IAM Identity Center에 다시 로그인하도록 지시합니다. 1. 모든 비상 액세스 사용자가 로그아웃한 후 IdP에서 IdP 페더레이션 애플리케이션을 비활성화합니다. 근무 시간 이후에 이 작업을 수행하는 것이 좋습니다. 1. IdP의 비상 액세스 그룹에서 모든 사용자를 제거합니다. 비상 액세스 역할 인프라는 백업 액세스 계획으로 유지되지만 이제 비활성화됩니다. # Okta에서 직접 IAM 페더레이션 애플리케이션을 한 번만 설정하면 됩니다. 1. 관리 권한을 가진 사용자인 Okta 계정에 로그인합니다. 1. Okta 관리 콘솔의 **애플리케이션**에서 **애플리케이션**을 선택합니다. 1. **앱 카탈로그 찾아보기**를 선택합니다. **AWS 계정 페더레이션**을 검색하여 선택합니다. **통합 추가**를 선택합니다. 1. 계정 연동을 위해 SAML 2.0을 구성하는 방법의 단계에 따라를 AWS 사용하여 직접 IAM 연동을 설정합니다. [AWS](https://saml-doc.okta.com/SAML_Docs/How-to-Configure-SAML-2.0-for-Amazon-Web-Service.html) 리전 장애 시나리오를 처리하려면 로그인 엔드포인트를 구성할 때 페더레이션 복원력을 개선하기 위해에서 운영하는 모든 리전에 대해 리전이 아닌 엔드포인트와 여러 리전 엔드포인트를 모두 활성화하는 것이 좋습니다. 이 긴급 액세스를 위해 ACS URL을 구성할 때는 IAM Identity Center가 배포된 리전과 다른 리전의 리전 엔드포인트를 사용하는 것이 좋습니다. 리전 [엔드포인트](https://docs.aws.amazon.com/general/latest/gr/signin-service.html) 목록은 *AWS 일반 참조*의 로그인 엔드포인트를 참조하세요. 1. **로그인 옵션** 탭에서 SAML 2.0을 선택하고 **그룹 필터** 및 **역할 값 패턴** 설정을 입력합니다. 사용자 디렉터리의 그룹 이름은 구성한 필터에 따라 달라집니다. ![\[두 가지 옵션: 그룹 필터의 accountid 및 역할 또는 역할 값 패턴.\]](http://docs.aws.amazon.com/ko_kr/singlesignon/latest/userguide/images/emergency-access-group-filter-role-value-pattern.png) 위 그림에서 `role` 변수는 비상 액세스 계정의 비상 운영 역할에 대한 변수입니다. 예를 들어에서 `EmergencyAccess_Role1_RO` 역할(매핑 테이블에 설명된 대로)을 생성하고 그룹 필터 설정이 위 그림과 같이 구성된 AWS 계정 `123456789012`경우 그룹 이름은 여야 합니다`aws#EmergencyAccess_Role1_RO#123456789012`. 1. 디렉터리(예: Active Directory의 디렉터리)에서 비상 액세스 그룹을 만들고 디렉터리 이름(예: `aws#EmergencyAccess_Role1_RO#123456789012`)을 지정합니다. 기존 프로비저닝 메커니즘을 사용하여 사용자를 이 그룹에 할당합니다. 1. 비상 액세스 계정에서 장애 발생 시 비상 액세스 역할을 맡는 데 필요한 권한을 제공하는 [사용자 지정 신뢰 정책을 구성합니다](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-custom.html). 다음은 `EmergencyAccess_Role1_RO` 역할에 연결된 사용자 지정 **신뢰 정책**에 대한 예제 설명입니다. 설명을 보려면 [비상 역할, 계정 및 그룹 매핑을 설계하는 방법](emergency-access-mapping-design.md) 아래의 다이어그램에서 긴급 계정을 참조하세요. 샘플 SAML 공급자 ARN을 긴급 액세스 계정에서 생성한 올바른 공급자 ARN으로 바꿉니다. 예제의 리전 엔드포인트를 선택한 리전으로 바꿉니다. ------ #### [ 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. 다음은 `EmergencyAccess_Role1_RO` 역할에 연결된 사용자 지정 **권한 정책**에 대한 예제 설명입니다. 설명을 보려면 [비상 역할, 계정 및 그룹 매핑을 설계하는 방법](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. 워크로드 계정에서 사용자 지정 신뢰 정책을 구성합니다. 다음은 `EmergencyAccess_RO` 역할에 연결된 사용자 지정 **신뢰 정책**에 대한 예제 설명입니다. 이 예에서 계정 `123456789012`는 비상 액세스 계정입니다. 설명을 보려면 [비상 역할, 계정 및 그룹 매핑을 설계하는 방법](emergency-access-mapping-design.md) 아래의 다이어그램에서 워크로드 계정을 참조하세요. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect":"Allow", "Principal":{ "AWS":"arn:aws:iam::123456789012:root" }, "Action":"sts:AssumeRole" } ] } ``` ------ **참고** 대부분의 IdP에서는 필요할 때까지 애플리케이션 통합을 비활성화할 수 있습니다. 비상 액세스가 필요할 때까지 IdP에서 직접 IAM 페더레이션 애플리케이션을 비활성화 상태로 유지하는 것이 좋습니다. # 를 사용하여 직접 IAM 페더레이션 애플리케이션의 일회성 설정 ADFS 이 가이드에서는 IAM Identity Center를 사용할 수 없을 AWS 계정 때에 대한 긴급 액세스를 활성화ADFS하기 위해를 사용하여 직접 IAM 페더레이션을 구성하는 일회성 설정 프로세스에 대해 설명합니다. ## 사전 조건 AWS 관리형 Microsoft ADADFS로를 구성하려는 경우 먼저 [다중 리전 복제를 구성](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/ms_ad_configure_multi_region_replication.html)하고 복원력을 위해 기본 리전이 아닌 추가 리전에서 다음 단계를 계속하는 것이 좋습니다. ## Active Directory 그룹 이름 지정 규칙 계획 그룹 이름과 AWS IAM 역할 간의 자동 일치를 활성화하는 특정 이름 지정 패턴을 사용하여 AD 그룹을 생성합니다. **그룹 이름 지정 형식**: `AWS--` 설명을 보려면 [비상 역할, 계정 및 그룹 매핑을 설계하는 방법](emergency-access-mapping-design.md) 아래의 다이어그램에서 긴급 계정을 참조하세요. 사용자가이 그룹에 할당되면 계정의 `EmergencyAccess_Role1_RO` 역할에 대한 액세스 권한이 부여됩니다`123456789012`. 사용자가 여러 그룹과 연결된 경우 별로 사용 가능한 역할 목록이 표시되고 수임할 역할을 선택할 AWS 계정 수 있습니다. ## AWS 구성 전체 설정에는 긴급 액세스 계정 및 워크로드 계정의 구성이 포함됩니다. 전체 설정에 대한 그림은 단원을 참조하십시오[비상 역할, 계정 및 그룹 매핑을 설계하는 방법](emergency-access-mapping-design.md). 1. [SAML 자격 증명 공급자 생성](#emergency-access-adfs-create-saml-provider) 1. [긴급 액세스 역할 생성](#emergency-access-adfs-create-roles) 1. [워크로드 계정 역할 구성](#emergency-access-adfs-configure-workload-accounts) ### SAML 자격 증명 공급자 생성 긴급 액세스 계정에서 IAM에서 SAML 자격 증명 공급자 생성의 단계에 따라 [IAM에서 SAML 자격 증명 공급자를 생성합니다](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_saml.html). ADFS 서버에서 필요한 메타데이터를 다운로드합니다. `https:///FederationMetadata/2007-06/FederationMetadata.xml` ### 긴급 액세스 역할 생성 SAML 2.0 연동을 신뢰할 수 있는 엔터티 유형으로 사용하여 긴급 계정에서 긴급 [액세스 역할을 생성합니다](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-idp_saml.html). 이전 단계에서 생성한 SAML 2.0 공급자를 선택합니다. **고려 사항:** + **운영 중인 모든 리전 포함 **- 활성 워크로드가 있는 모든 리전을 선택하여 리전 중단 시 페더레이션을 계속 사용할 수 있도록 합니다. + **단일 리전에서 운영하는 경우에도 하나 이상의 추가 리전 엔드포인트를 구성합니다**. 예를 들어 에서만 운영하는 경우 `us-east-1`를 보조 엔드포인트`us-west-2`로 추가합니다. IdP를 `us-west-2` SAML 로그인 엔드포인트로 장애 조치하고의 워크로드 없이도 `us-east-1` 리소스에 계속 액세스할 수 있습니다`us-west-2`. + **비리전 엔드포인트와 리전 엔드포인트 모두 활성화 -** 비리전 엔드포인트(`https://signin.aws.amazon.com/saml`)는 가용성이 높지만 단일에서 호스팅되는 AWS 리전`us-east-1`반면 리전 엔드포인트(`https://.signin.aws.amazon.com/saml`)는 단일 글로벌 엔드포인트에 대한 종속성을 줄여 복원력을 개선합니다. **신뢰 정책 구성** 여러 로그인 리전 엔드포인트가 있는 신뢰 정책의 예는 섹션을 참조[Okta에서 직접 IAM 페더레이션 애플리케이션을 한 번만 설정하면 됩니다.](emergency-access-one-time-setup-direct-IAM-federation-application-in-idp.md)하세요. 샘플 리전 엔드포인트 및 SAML 공급자 ARNs 사용자의 것으로 바꿉니다. **권한 정책 구성** 긴급 액세스 역할에 연결하는 권한 정책의 [Okta에서 직접 IAM 페더레이션 애플리케이션을 한 번만 설정하면 됩니다.](emergency-access-one-time-setup-direct-IAM-federation-application-in-idp.md) 예는 섹션을 참조하세요. ### 워크로드 계정 역할 구성 워크로드 계정 역할의 경우 긴급 액세스 계정의 긴급 액세스 역할이 해당 역할을 수임하도록 허용하는 사용자 지정 신뢰 정책을 구성합니다. 계정이 긴급 액세스 계정인 신뢰 정책의 [Okta에서 직접 IAM 페더레이션 애플리케이션을 한 번만 설정하면 됩니다.](emergency-access-one-time-setup-direct-IAM-federation-application-in-idp.md) 예는 섹션을 참조`123456789012`하세요. ## Active Directory 구성 다음 단계에서는 긴급 액세스를 위해 Active Directory 및 ADFS를 구성하는 방법을 설명합니다. 1. [그룹 생성](#emergency-access-adfs-create-groups) 1. [신뢰 당사자 생성](#emergency-access-adfs-create-relying-party) 1. [클레임 규칙 생성](#emergency-access-adfs-create-claim-rules) ### 그룹 생성 앞에서 설명한 이름 지정 규칙(예: )에 따라 Active Directory에서 비상 그룹을 생성합니다`AWS-123456789012-EmergencyAccess_Role1_RO`. 기존 프로비저닝 메커니즘을 통해 이러한 그룹에 사용자를 할당합니다. ### 신뢰 당사자 생성 ADFS 페더레이션에는 신뢰 당사자 구성이 필요합니다. 신뢰 당사자는 자격 증명 공급자ADFS로에 인증을 아웃소싱하는 AWS Security Token Service (AWS STS)입니다. 1. ADFS 관리 콘솔에서 작업 메뉴를 사용하고 **신뢰 당사자 신뢰 추가를** 선택합니다. 신뢰 당사자를 추가할 때 **클레임 인식을** 선택합니다. 1. 페더레이션 메타데이터의 경우 IAM 콘솔의 자격 증명 공급자 메타데이터 정보에서 메타데이터 URL을 입력합니다. 예제: `https://signin.aws.amazon.com/static/saml/SAMLSPXXXXXX/saml-metadata.xml` 1. 신뢰 당사자(예: **AWS 계정 액세스**)의 표시 이름을 설정한 **후 다음을** 선택합니다. 1. 에 액세스할 사용자를 선택합니다 AWS. 특정 그룹을 선택하고 MFA와 같은 요구 사항을 정의할 수 있습니다. 1. 완료 페이지에서 **닫기**를 선택하여 신뢰 당사자 추가 신뢰 마법사를 완료합니다. AWS 가 이제 신뢰 당사자로 구성됩니다. ### 클레임 규칙 생성 ADFS는 클레임 규칙 언어를 사용하여 클레임 공급자와 신뢰 당사자 간에 클레임을 발행하고 변환합니다. NameId, RoleSessionName, AD 그룹 가져오기 및 AWS 액세스를 위한 역할이라는 네 가지 클레임 규칙을 생성해야 합니다. 신뢰 당사자를 마우스 오른쪽 버튼으로 클릭한 다음 **클레임 발급 정책 편집**을 선택합니다. **규칙 추가**를 선택하여 규칙을 추가합니다. **1. NameId** 1. **수신 클레임 변환을** 선택한 **후 다음을** 선택합니다. 1. 다음 설정을 사용합니다. + 클레임 규칙 이름: `NameId` + 수신 클레임 유형: `Windows Account Name` + 발신 클레임 유형: `Name ID` + 발신 이름 ID 형식: `Persistent Identifier` + 모든 클레임 값 전달: 확인됨 1. **확인**을 선택합니다. **2. RoleSessionName** 1. **규칙 추가(Add Rule)**를 선택합니다. 1. 클레임 규칙 템플릿 목록에서 **클레임으로 LDAP 속성 전송을** 선택합니다. 1. 다음 설정을 사용합니다. + 클레임 규칙 이름: `RoleSessionName` + 속성 저장소: `Active Directory` + LDAP 속성: `E-Mail-Addresses` + 발신 클레임 유형: `https://aws.amazon.com/SAML/Attributes/RoleSessionName` 1. **확인**을 선택합니다. **3. AD 그룹 가져오기** 1. **규칙 추가(Add Rule)**를 선택합니다. 1. 클레임 규칙 템플릿 목록에서 **사용자 지정 규칙을 사용하여 클레임 전송을** 선택한 **후 다음을** 선택합니다. 1. 클레임 규칙 이름에 `Get AD Groups`를 입력한 다음 사용자 지정 규칙에 다음을 입력합니다. ``` 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); ``` 이 사용자 지정 규칙은 인증된 사용자가 속한 모든 그룹을 검색하여 라는 임시 클레임에 배치하는 클레임 규칙 언어의 스크립트를 사용합니다`http://temp/variable`. **참고** 예상치 못한 결과를 방지하기 위해 후행 공백이 없는지 확인합니다. **4. 역할 속성** 1. **규칙 추가(Add Rule)**를 선택합니다. 1. 클레임 규칙 템플릿 목록에서 **사용자 지정 규칙을 사용하여 클레임 전송을** 선택한 **후 다음을** 선택합니다. 1. 클레임 규칙 이름에 `Roles`를 입력한 다음 사용자 지정 규칙에 다음을 입력합니다. ``` 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/")); ``` 이 사용자 지정 규칙은 정규식을 사용하여 양식의 각 그룹 멤버십을가 AWS 예상하는 IAM 역할 ARN 및 IAM 페더레이션 공급자 ARN 양식`AWS--`으로 변환합니다. **참고** 위의 예제 규칙 언어에서는 자격 증명 공급자 설정에서 SAML AWS 자격 증명 공급자에 지정된 논리적 이름을 `ADFS` 나타냅니다. ID 제공업체의 IAM 콘솔에서 선택한 논리적 이름을 기반으로 이를 변경합니다. ## 구성 테스트 에서 인증하여 솔루션이 작동하는지 테스트합니다`https:///adfs/ls/IdpInitiatedSignOn.aspx`. 사이트의 드롭다운 목록에서 생성한 신뢰 당사자 이름을 선택합니다. ## 에서 기본 SAML 어설션 엔드포인트 업데이트 ADFS **중요** 에서 신뢰 당사자 신뢰를 구성할 때 SAML 어설션 엔드포인트ADFS는 기본적으로 글로벌 엔드포인트`https://signin.aws.amazon.com/`가 아니며에 있습니다`us-east-1`. 기본 엔드포인트를 IAM Identity Center가 복원력을 위해 구성된 리전 엔드포인트와 다른 리전 엔드포인트로 수정하는 것이 좋습니다. 예를 들어 IAM Identity Center가에 배포되어 `us-east-1` 있고 에서도 작업하는 경우 기본 SAML 어설션 소비자 엔드포인트를 로 `us-west-2`변경합니다`https://us-west-2.signin.aws.amazon.com/saml`. 1. 신뢰 당사자 신뢰에서 **속성을** 선택하고 **모니터링** 탭으로 이동합니다. **신뢰 당사자 자동 업데이트 확인란의 선택을 취소합니다**. 1. **엔드포인트** 탭으로 이동하여 원하는 로그인 엔드포인트를 선택하고 **편집**을 선택합니다. 1. 신뢰할 **수 있는 URL을 기본값으로 설정** 확인란을 선택합니다. 설정을 적용하려면 **확인** 및 **적용을** 선택합니다. **참고** 대부분의 IdP에서는 필요할 때까지 애플리케이션 통합을 비활성화할 수 있습니다. 비상 액세스가 필요할 때까지 IdP에서 직접 IAM 페더레이션 애플리케이션을 비활성화 상태로 유지하는 것이 좋습니다.