기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 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 페더레이션 애플리케이션을 비활성화 상태로 유지하는 것이 좋습니다.