# IAM 역할 관련 일반 시나리오
대부분의 AWS 기능과 마찬가지로 역할 사용에는 일반적으로 두 가지 방법이 있습니다. 즉, IAM 콘솔에서 대화식으로 사용하는 것 또는 AWS CLI, Tools for Windows PowerShell이나 API에서 프로그래밍 방식으로 사용하는 것입니다.
+ IAM 콘솔을 사용하는 계정의 IAM 사용자가 역할을 *전환하여* 콘솔에서 해당 역할의 권한을 임시로 사용할 수 있습니다. 사용자는 자신의 원래 권한을 포기하고 역할에 할당된 권한을 수임합니다. 사용자가 역할을 끝내면 원래 권한이 복원됩니다.
+ AWS에서 제공하는 애플리케이션 또는 서비스(예: Amazon EC2)가 AWS에 프로그래밍 방식으로 요청할 때 사용할 역할의 임시 보안 자격 증명을 요청하여 역할을 *수임*할 수 있습니다. 역할을 이렇게 사용하면 리소스에 액세스해야 하는 각 엔터티를 위한 장기 보안 자격 증명을 공유하거나 유지(예: IAM 사용자 생성)할 필요가 없습니다.
**참고**
이 안내서는 *역할로 전환합니다*와 *역할을 수임합니다*라는 표현을 서로 대치할 수 있는 동일한 의미로 사용합니다.
역할을 사용하는 가장 간단한 방법은 IAM 사용자에게 자신이나 다른 사용자의 AWS 계정에서 생성하는 역할로 전환할 권한을 부여하는 것입니다. IAM 사용자는 IAM 콘솔을 통해 역할을 쉽게 전환하여 일반적으로 부여받지 않은 권한을 사용한 다음 역할을 끝내 해당 권한을 포기할 수 있습니다. 이를 통해 중요한 리소스에 *잘못* 액세스하거나 이를 수정하는 일을 방지할 수 있습니다.
애플리케이션 및 서비스 또는 연동된 외부 사용자에게 액세스 권한을 부여하는 등 역할을 한층 복잡한 방식으로 사용하기 위해 `AssumeRole` API를 호출할 수 있습니다. 이 API 호출은 애플리케이션이 이후의 API 호출에 사용할 수 있는 일련의 임시 자격 증명 세트를 반환합니다. 임시 자격 증명을 사용하여 시도하는 작업에는 연결된 역할에서 부여한 권한만 있습니다. 애플리케이션에서는 콘솔에서 사용자가 하듯이 역할을 "끝낼" 필요가 없습니다. 단지 애플리케이션에서 임시 자격 증명 사용을 중지하고 원래 자격 증명으로 호출을 재개합니다.
페더레이션 사용자는 IdP(자격 증명 공급자)에서 제공하는 자격 증명을 사용하여 로그인합니다. 그 다음 AWS에서 신뢰받는 IdP에 임시 자격 증명을 제공하여 이후의 AWS 리소스 요청에 포함할 수 있도록 사용자에게 전달합니다. 그러한 자격 증명은 할당된 역할에 부여된 권한을 제공합니다.
이 섹션에서는 다음 시나리오의 개요를 제공합니다.
+ [소유한 AWS 계정의 IAM 사용자에게 소유한 다른 계정의 리소스에 액세스할 수 있는 권한 제공](id_roles_common-scenarios_aws-accounts.md)
+ [AWS 워크로드 이외 워크로드에 대한 액세스 권한 제공](id_roles_common-scenarios_non-aws.md)
+ [타사가 소유한 AWS 계정에 속한 IAM 사용자에 액세스 권한 제공](id_roles_common-scenarios_third-party.md)
+ [AWS가 제공하는 서비스를 위해 AWS 리소스에 대한 액세스 권한을 제공하는 경우](id_roles_common-scenarios_services.md)
+ [외부에서 인증된 사용자에게 액세스 권한 제공(아이덴티티 페더레이션)](id_roles_common-scenarios_federated-users.md)
# 소유한 다른 AWS 계정의 IAM 사용자에 대한 액세스
IAM 사용자에게 AWS 계정 내의 역할 또는 소유하고 있는 다른 AWS 계정에 정의된 역할로 전환할 수 있는 권한을 부여할 수 있습니다.
**참고**
소유하지 않은 또는 제어하지 않는 계정에 대한 액세스 권한을 부여하고자 하는 경우, 이 주제 뒷부분의 [타사가 소유한 AWS 계정에 액세스](id_roles_common-scenarios_third-party.md) 섹션을 참조하세요.
조직에 중요한 Amazon EC2 인스턴스가 있다고 가정해 봅시다. 사용자에게 인스턴스를 종료할 수 있는 권한을 직접 부여하지 않고, 이러한 권한이 있는 역할을 만들 수 있습니다. 그런 다음 관리자는 인스턴스를 종료해야 하는 경우 해당 역할로 전환할 수 있습니다. 그러면 이러한 인스턴스에 다음과 같은 보호 계층이 추가됩니다.
+ 사용자에게 역할을 수임할 권한을 명시적으로 부여해야 합니다.
+ 사용자는 AWS Management Console을 사용하여 해당 역할로 능동적으로 전환하거나 AWS CLI 또는 AWS API를 사용하여 역할을 수임해야 합니다.
+ 역할에 멀티 팩터 인증(MFA) 보호를 추가하여 MFA 디바이스로 로그인하는 사용자만 역할을 수임할 수 있도록 합니다. 역할을 수임한 사용자가 MFA(멀티 팩터 인증)를 사용하여 처음에 인증을 받도록 역할을 구성하는 방법을 알아보려면 [MFA를 통한 보안 API 액세스](id_credentials_mfa_configure-api-require.md) 섹션을 참조하세요.
이 방법을 사용하여 *최소 권한 원칙*을 적용하는 것이 좋습니다. 다시 말해, 특정 작업이 필요한 경우에만 승격된 권한을 사용하도록 제한하는 것입니다. 역할을 사용하여 중요한 환경을 실수로 변경하는 일을 방지할 수 있습니다. 특히 필요할 때만 역할이 사용되는지 확인하기 위해 중요한 환경을 [감사](cloudtrail-integration.md)와 결합하는 경우에 그렇습니다.
이러한 목적을 위해 역할을 만들려면 해당 역할의 신뢰 정책 `Principal` 요소에서 액세스가 필요한 사용자의 ID로 계정을 지정합니다. 그러면 그러한 다른 계정의 특정 사용자에게 해당 역할로 전환할 수 있는 권한을 부여할 수 있습니다. 해당 신뢰 영역(신뢰할 수 있는 조직 또는 계정) 외의 계정 내 보안 주체가 역할을 수임하는 권한이 있는지 자세히 알고 싶다면, [IAM Access Analyzer란 무엇인가요?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)를 참조하세요.
한 계정의 사용자는 동일한 또는 다른 계정의 역할로 전환할 수 있습니다. 사용자는 역할을 사용하는 동안 해당 작업만을 수행하고 해당 역할에서 허용한 리소스만 액세스할 수 있지만, 이들의 원래 사용자 권한은 일시 중지된 상태입니다. 사용자가 역할을 끝내면 원래 사용자 권한이 회복됩니다.
## 분리된 개발 및 프로덕션 계정을 사용한 예제 시나리오
프로덕션 환경에서 개발 환경을 격리하기 위해 조직이 여러 개의 AWS 계정을 갖고 있다고 가정합시다. 개발 계정의 사용자는 프로덕션 계정의 리소스에 액세스해야 하는 경우가 있습니다. 예를 들어, 개발 환경에서 프로덕션 환경으로 업데이트를 승격하려는 경우 크로스 계정 액세스 권한이 필요할 수 있습니다. 두 계정을 모두 사용하는 사용자를 위해 별도의 자격 증명(및 암호)을 생성했다 해도 여러 계정에 대한 자격 증명을 관리할 경우 자격 증명 관리가 어려워집니다. 다음 그림을 보면 모든 사용자가 개발 계정에서 관리됩니다. 그러나 일부 개발자에게는 프로덕션 계정에 대한 제한된 액세스 권한이 필요합니다. 개발 계정에는 Testers와 Developers라는 두 개의 그룹이 있으며 각 그룹에는 고유의 정책이 있습니다.
![\[역할을 사용하여 다른 계정의 사용자에게 권한 위임\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/roles-usingroletodelegate.png)
1. 프로덕션 계정에서 관리자는 IAM을 사용하여 해당 계정에 `UpdateApp` 역할을 생성합니다. 관리자는 그 역할에서 개발 계정을 `Principal`로 지정하는 신뢰 정책을 정의합니다. 이는 개발 계정의 권한이 있는 사용자는 `UpdateApp` 역할을 사용할 수 있다는 것을 뜻합니다. 또한 관리자는 이 역할의 사용자가 `productionapp`이라는 Amazon S3 버킷에 대한 읽기 및 쓰기 권한을 보유하도록 지정하는 역할의 권한 정책을 정의합니다.
그런 다음 관리자는 적절한 정보를 이 역할을 수임해야 하는 대상과 공유합니다. 그러한 정보로는 계정 번호와 역할 이름(AWS 콘솔 사용자들에 대한) 또는 Amazon 리소스 이름(ARN)(AWS CLI 또는 AWS API 액세스용)이 있습니다. 역할 ARN은 `arn:aws:iam::123456789012:role/UpdateApp`과 같은 형태를 띱니다. 여기에서 역할의 이름은 `UpdateApp`이고, 역할이 생성된 계정 번호는 123456789012입니다.
**참고**
관리자는 역할을 수임하는 사용자가 먼저 멀티 팩터 인증(MFA)을 사용하여 인증을 받도록 역할을 구성할 수도 있습니다. 자세한 내용은 [MFA를 통한 보안 API 액세스](id_credentials_mfa_configure-api-require.md) 섹션을 참조하세요.
1. 개발 계정에서 관리자는 Developer 그룹의 구성원에게 이 역할로 전환할 수 있는 권한을 부여합니다. 이를 수행하려면 Developers 그룹에 `UpdateApp` 역할에 대한 AWS Security Token Service(AWS STS) `AssumeRole` API를 호출할 권한을 부여하면 됩니다. 이제 개발 계정의 Developers 그룹에 속한 모든 IAM 사용자는 프로덕션 계정의 `UpdateApp` 역할로 전환할 수 있습니다. Developer 그룹에 속하지 않은 다른 사용자는 이 역할로 전환할 수 있는 권한이 없으므로 프로덕션 계정의 S3 버킷에 액세스할 수 없습니다.
1. 사용자가 이 역할로의 전환을 요청:
+ AWS 콘솔: 탐색 표시줄에서 계정 이름을 선택하고 **Switch Role(역할 전환)**을 선택합니다. 계정 ID(또는 별칭) 및 역할 이름을 지정합니다. 아니면 사용자는 관리자가 이메일로 보낸 링크를 클릭해도 됩니다. 링크를 누르면 세부 정보가 이미 채워져 있는 **역할 전환** 페이지로 이동합니다.
+ AWS API/AWS CLI: 개발 계정의 Developers 그룹에 속한 사용자는 `AssumeRole` 함수를 호출하여 `UpdateApp` 역할에 대한 자격 증명을 가져옵니다. `UpdateApp` 역할의 ARN을 이 호출의 일부로 지정합니다. Testers 그룹의 사용자가 동일한 요청을 하는 경우에는 요청이 실패하는데, 이는 Testers가 `AssumeRole` 역할 ARN을 위해 `UpdateApp`을 호출할 권한이 없기 때문입니다.
1. AWS STS는 임시 자격 증명을 반환합니다.
+ AWS 콘솔: AWS STS에서 그 요청이 신뢰할 수 있는 대상(개발 계정)에서 온 것인지 확인하기 위해 그 요청에 대해 역할의 신뢰 정책을 확인합니다. 확인 후 AWS STS에서 AWS 콘솔로 [임시 보안 자격 증명](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html)을 반환합니다.
+ API/CLI: AWS STS에서 신뢰할 수 있는 대상(Development 계정)이 요청을 보낸 것인지 확인하기 위해 역할의 신뢰 정책에 대한 요청을 확인합니다. 확인 후 AWS STS에서 해당 애플리케이션으로 [임시 보안 자격 증명](https://docs.aws.amazon.com/STS/latest/UsingSTS/Welcome.html)을 반환합니다.
1. 임시 자격 증명은 AWS 리소스에 대한 액세스를 허용합니다.
+ AWS 콘솔: AWS 콘솔은 이후의 모든 콘솔 작업에서 사용자를 대신하여 임시 자격 증명을 사용합니다. 이 경우에 그 작업이란 `productionapp` 버킷에 대한 읽기 및 쓰기입니다. 이 콘솔은 프로덕션 계정의 다른 리소스에는 액세스할 수 없습니다. 사용자가 역할을 끝내면 사용자의 권한은 이 역할로 전환하기 전에 보유한 원래의 권한으로 돌아갑니다.
+ API/CLI: 이 애플리케이션에서는 임시 보안 자격 증명을 사용하여 `productionapp` 버킷을 업데이트합니다. 이 애플리케이션은 임시 보안 자격 증명을 통해 `productionapp` 버킷에 대한 읽기 및 쓰기만 할 수 있으며 프로덕션 계정의 다른 리소스에는 액세스할 수 없습니다. 애플리케이션은 역할을 종료하지 않아도 되지만 대신에 임시 자격 증명 사용을 중지하고 이후의 API 호출에서 다시 원래의 자격 증명을 사용합니다.
## 추가 리소스
자세한 내용은 다음을 참조하세요.
+ [튜토리얼: IAM 역할을 사용한 AWS 계정 간 액세스 권한 위임](tutorial_cross-account-with-roles.md)
# 비AWS 워크로드 액세스
[IAM 역할](id_roles.md)은 [권한](access_policies.md)이 할당된 AWS Identity and Access Management(IAM)의 객체입니다. IAM 자격 증명 또는 AWS 외부의 자격 증명을 사용하여 [역할을 맡은](id_roles_manage-assume.md) 경우 해당 역할 세션을 위한 임시 보안 자격 증명이 제공됩니다. AWS 리소스에 액세스해야 하는 데이터 센터 또는 AWS 외부의 기타 인프라에서 실행 중인 워크로드가 있을 수 있습니다. 장기 액세스 키를 생성, 배포 및 관리하는 대신 AWS Identity and Access Management Roles Anywhere(IAM Roles Anywhere)를 사용하여 AWS 이외 워크로드를 인증할 수 있습니다. IAM Roles Anywhere는 인증 기관(CA)의 X.509 인증서를 사용하여 자격 증명을 인증하고 IAM 역할에서 제공하는 임시 보안 인증을 사용하여 AWS 서비스에 대한 액세스 권한을 안전하게 제공합니다.
**IAM Roles Anywhere 사용**
1. [AWS Private Certificate Authority](https://docs.aws.amazon.com/privateca/latest/userguide/PcaWelcome.html) 사용을 통해 CA를 설정하거나 자체 PKI 인프라의 CA를 사용합니다.
1. CA를 설정한 후 IAM Roles Anywhere에서 **트러스트 앵커라는 객체를 생성합니다. 이 앵커는 IAM Roles Anywhere와 CA 간에 인증을 위한 트러스트를 구축합니다.
1. 그런 다음 기존 IAM 역할을 구성하거나 IAM Roles Anywhere 서비스를 신뢰하는 새 역할을 생성할 수 있습니다.
1. 트러스트 앵커를 사용하여 비AWS 워크로드를 IAM Roles Anywhere에서 인증합니다. AWS에서는 IAM 역할에 비 AWS 워크로드 이미 자격 증명을 부여하고, 이를 통해 AWS 리소스에 액세스할 수 있습니다.
## 추가 리소스
다음 리소스는 비AWS 워크로드에 대한 액세스 제공에 대해 알아보는 데 도움이 될 수 있습니다.
+ IAM Roles Anywhere 구성에 대한 자세한 내용은 *IAM Roles Anywhere 사용 설명서*의 [AWS Identity and Access Management Roles Anywhere란 무엇입니까?](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/introduction.html)를 참조하세요.
+ IAM Roles Anywhere에서 퍼블릭 키 인프라(PKI)를 설정하는 방법을 알아보려면 **AWS 보안 블로그에서 [IAM Roles Anywhere with an external certificate authority](https://aws.amazon.com/blogs/)의 내용을 참조하세요.
# 타사가 소유한 AWS 계정에 액세스
타사가 조직의 AWS 리소스에 액세스해야 하는 경우 역할을 사용하여 해당 사용자에게 그에 대한 액세스 권한을 위임할 수 있습니다. 예를 들어, 타사가 AWS 리소스를 관리하는 서비스를 제공할 경우 IAM 역할을 사용하면 AWS 보안 자격 증명을 공유하지 않고 해당 타사에 AWS 리소스에 액세스할 수 있는 권한을 부여할 수 있습니다. 대신 타사는 귀하의 AWS 계정에 만든 역할로 가장하여 귀하의 AWS 리소스에 액세스할 수 있습니다. 해당 신뢰 영역(신뢰할 수 있는 조직 또는 계정) 외의 계정 내 보안 주체가 역할을 수임하는 권한이 있는지 자세히 알고 싶다면 [IAM Access Analyzer란 무엇인가요?](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html)를 참조하세요.
해당 사용자가 수임할 수 있는 역할을 생성하려면 타사가 다음 정보를 제공해야 합니다.
+ **타사의 AWS 계정 ID**. 역할에 대한 신뢰 정책을 정의할 때 AWS 계정 ID를 보안 주체로 지정합니다.
+ **역할을 고유하게 연결하는 데 사용하는 외부 ID**. 외부 ID는 여러분과 타사만이 알고 있는 임의의 식별자일 수 있습니다. 예를 들어, 여러분과 타사가 사용하는 인보이스 ID를 사용할 수 있지만 타사의 이름이나 전화번호와 같이 추측 가능한 것은 사용하지 마세요. 역할에 대한 신뢰 정책을 정의할 때 이 ID를 지정해야 합니다. 타사가 역할을 수임할 때 이 ID를 제공해야 합니다.
+ **AWS 리소스를 사용하기 위해 타사에 필요한 권한**. 역할의 권한 정책을 정의할 때 이러한 권한을 지정해야 합니다. 이 정책은 타사에서 수행할 수 있는 작업과 액세스할 수 있는 리소스를 정의합니다.
역할을 정의한 후에는 역할의 Amazon 리소스 이름(ARN)을 타사에 제공해야 합니다. 타사가 역할을 수임하려면 해당 역할의 ARN이 필요합니다.
**중요**
타사에 AWS 리소스에 대한 액세스 권한을 부여하는 경우 타사는 여러분이 정책에서 지정하는 모든 리소스에 액세스할 수 있습니다. 타사의 리소스 사용에 대해서는 여러분에게 과금됩니다. 타사의 리소스 사용을 적절하게 제한해야 합니다.
## 타사 액세스를 위한 외부 ID
외부 ID는 그 역할을 위임하고 있는 사용자가 자신이 활동하고 있는 상황을 어설션할 수 있도록 허용합니다. 또한, 계정 소유자가 특정 상황에서만 역할이 위임되도록 허용할 수 있는 방법을 제공합니다. 외부 ID의 주된 기능은 [혼동된 대리자 문제](confused-deputy.md)를 해결하고 방지하는 것입니다.
**중요**
AWS는 외부 ID를 비밀로 취급하지 않습니다. AWS에서 액세스 키 페어 또는 암호와 같은 비밀 정보를 만든 후에는 다시 볼 수 없습니다. 역할의 외부 ID는 해당 역할을 볼 수 있는 권한을 가진 사람만 볼 수 있습니다.
## 언제 외부 ID를 사용해야 하나요?
다음 상황에서 외부 ID를 사용합니다.
+ AWS 계정 소유자가 자신의 계정뿐 아니라 다른 AWS 계정에도 액세스하는 타사를 위한 역할을 구성했습니다. 이 경우 타사에 역할을 위임할 때 포함하는 외부 ID를 요청해야 합니다. 그런 다음 역할의 신뢰 정책에서 외부 ID를 확인합니다. 이렇게 하여 외부 사용자를 대신해서 수행하는 경우에만 역할을 맡을 수 있도록 해야 합니다.
+ 이전 시나리오의 Example Corp와 같은 다른 고객을 대신하여 역할을 위임할 수 있습니다. 각 고객에게 고유한 외부 ID를 할당하고 외부 ID를 역할의 신뢰 정책에 추가하도록 지시해야 합니다. 그런 다음 역할 위임 요청에 정확한 외부 ID를 항상 포함하도록 해야 합니다.
각 고객에 대한 고유한 식별자를 이미 갖고 있겠지만, 이 고유 ID는 외부 ID로 사용하기에 충분합니다. 외부 ID는 단지 이러한 목적을 위해 명시적으로 생성하거나 별도로 추적할 필요가 있는 특별한 값은 아닙니다.
외부 ID는 항상 `AssumeRole` API 호출에 지정해야 합니다. 이 밖에도 고객이 역할 ARN을 부여할 때 정확한 외부 ID가 있든 없든 그 역할을 위임할 수 있는지 확인하세요. 정확한 외부 ID 없이 역할을 위임할 수 있는 경우 시스템에 고객의 역할 ARN을 저장하지 마세요. 고객이 정확한 외부 ID를 요구하도록 역할 신뢰 정책을 업데이트할 때까지 기다립니다. 이러한 방식으로 고객이 올바른 일을 할 수 있도록 돕고, 이는 양자 모두 혼동된 대리자 문제에서 보호받는 데 도움이 됩니다.
## 외부 ID를 사용하는 예제 시나리오
예를 들어 Example Corp이라는 타사를 고용해 AWS 계정을 모니터링하고 비용을 최적화하기로 했다고 가정해봅시다. 일일 경비를 추적하기 위해 Example Corp은 AWS 리소스에 접근해야 합니다. Example Corp 역시 다른 고객을 위해 다른 많은 AWS 계정을 모니터링합니다.
AWS 계정의 IAM 사용자 및 해당 장기 자격 증명에 대한 액세스 권한을 Example Corp에게 제공하지 마세요. 대신 IAM 역할과 임시 보안 자격 증명을 사용합니다. IAM 역할은 장기 보안 인증(IAM 사용자 액세스 키 등)을 공유하지 않고도 AWS 리소스에 액세스할 수 있도록 허용하는 메커니즘을 타사에 제공합니다.
IAM 역할을 사용하여 AWS 계정과 Example Corp 계정 사이에 신뢰 관계를 설정할 수 있습니다. 이 관계가 설정된 후 Example Corp 계정의 멤버는 AWS Security Token Service [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API를 호출하여 임시 보안 자격 증명을 얻을 수 있습니다. Example Corp 멤버는 자격 증명을 사용하여 계정의 AWS 리소스에 액세스할 수 있습니다.
**참고**
임시 보안 자격 증명을 얻기 위해 호출할 수 있는 AssumeRole 및 다른 AWS API 작업에 대한 자세한 내용은 다음([AWS STS 자격 증명 비교](id_credentials_sts-comparison.md))을 참조하세요.
이 시나리오에 대한 더 자세한 분석은 다음과 같습니다.
1. Example Corp을 고용해 고유한 사용자 지정 식별자를 생성하도록 합니다. 이 고유 고객 ID와 AWS 계정 번호를 제공합니다. 이 정보는 다음 단계에서 IAM 역할을 생성하는 데 필요합니다.
**참고**
이 식별자가 Example Corp의 각 고객에게 고유한 것이라면 Example Corp는 ExternalId에 대해 그들이 원하는 어떤 문자열 값이라도 사용할 수 있습니다. 두 고객이 같은 값을 갖지 않는 한, 고객 계정 번호 또는 임의 문자열이 될 수 있습니다. 이는 '보안 유지'를 위한 것은 아닙니다. Example Corp은 각 고객에게 ExternalId 값을 제공해야 합니다. 가장 중요한 것은 각 외부 ID가 고유하도록, 고객이 ***아닌*** Example Corp이 이 값을 생성해야 한다는 것입니다.
1. AWS에 로그인해 Example Corp에 리소스에 대한 액세스 권한을 부여하는 IAM 역할을 생성합니다. IAM 역할과 마찬가지로 해당 역할에도 권한 정책과 신뢰 정책이라는 두 가지 정책이 있습니다. 그 역할의 신뢰 정책은 역할을 위임할 사용자를 지정합니다. 이 예시 시나리오에서 정책은 Example Corp의 AWS 계정 번호를 `Principal`로 지정합니다. 이렇게 하면 계정의 자격 증명이 그 역할을 수임하도록 허용합니다. 또한, `[Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Condition)` 요소를 신뢰 정책에 추가합니다. 이 `Condition`은 Example Corp의 고유 고객 ID와 일치하는지 확인하기 위해 `ExternalId` 컨텍스트 키를 테스트합니다.
```
"Principal": {"AWS": "Example Corp's AWS 계정 ID"},
"Condition": {"StringEquals": {"sts:ExternalId": "Unique ID Assigned by Example Corp"}}
```
1. 역할에 대한 권한 정책은 해당 역할이 누군가가 수행하도록 허용할 수 있는 작업을 지정합니다. 예를 들어 그 역할은 누군가에게 IAM 사용자나 그룹이 아닌 Amazon EC2 또는 Amazon RDS 리소스만을 관리할 수 있게 허용하도록 지정할 수 있습니다. 이 예시 시나리오에서는 권한 정책을 사용하여 Example Corp에게 계정의 리소스 전체에 대한 읽기 전용 액세스 권한을 부여합니다.
1. 역할을 정의한 후에는 역할의 Amazon 리소스 이름(ARN)을 Example Corp에 제공합니다.
1. Example Corp가 AWS 리소스에 액세스해야 할 때는 그 회사의 누군가가 AWS `sts:AssumeRole` API를 호출합니다. 이 호출에는 수임할 역할의 ARN과 사용자 지정 ID에 해당하는 ExternalId 파라미터가 포함되어 있습니다.
Example Corp의 AWS 계정을 사용하는 사람이 요청하는 경우와 역할 ARN 및 외부 ID가 올바른 경우에 요청이 성공합니다. 그 경우 요청은 역할이 허용하는 AWS 리소스에 액세스하기 위해 Example Corp이 사용할 수 있는 임시 보안 자격 증명을 제공합니다.
다시 말해서 역할 정책에 외부 ID가 포함된다면 그 역할을 수임하고자 하는 사용자는 누구든지 그 역할에서 보안 주체로 지정되어야 하고 정확한 외부 ID를 포함해야 합니다.
## 외부 ID의 요점
+ 서로 다른 AWS 계정을 가진 여러 고객을 지원하는 다중 테넌트 환경에서는 AWS 계정당 하나의 외부 ID를 사용하는 것이 좋습니다. 이 ID는 타사에서 생성한 임의의 문자열이어야 합니다.
+ 역할을 수임할 때 타사에서 외부 ID를 제공하도록 요구하려면 해당 역할의 신뢰 정책을 선택한 외부 ID로 업데이트합니다.
+ 역할을 수임할 때 외부 ID를 제공하려면 AWS CLI 또는 AWS API를 사용하여 해당 역할을 수임합니다. 자세한 내용은 STS [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html) API 작업 또는 STS [assume-role](https://docs.aws.amazon.com/cli/latest/reference/sts/assume-role.html) CLI 작업을 참조하세요.
+ `ExternalId` 값은 최소 2자, 최대 1,224자여야 합니다. 이 값은 공백 없이 영숫자여야 합니다. 이 값은 더하기(\$1), 등호(=), 쉼표(,) 마침표(.), 기호(@), 콜론(:), 슬래시(/) 및 하이픈(-)과 같은 기호도 포함할 수 있습니다.
## 추가 리소스
다음 리소스는 타사 소유의 AWS 계정에 대한 액세스 제공에 대해 알아보는 데 도움이 될 수 있습니다.
+ 다른 사용자가 AWS 계정에서 작업을 수행하도록 허용하는 방법을 알아보려면 [사용자 지정 트러스트 정책을 사용하여 역할 생성](id_roles_create_for-custom.md)의 내용을 참조하세요.
+ 역할로 전환할 수 있는 권한을 부여하는 방법을 알아보려면 [사용자에게 역할을 전환할 권한 부여](id_roles_use_permissions-to-switch.md)의 내용을 참조하세요.
+ 신뢰할 수 있는 사용자를 생성하고 임시 보안 자격 증명을 제공하는 방법을 알아보려면 [임시 보안 자격 증명에 대한 권한](id_credentials_temp_control-access.md)의 내용을 참조하세요.
# AWS 서비스 액세스
많은 AWS 서비스에서는 역할을 사용하여 해당 서비스가 액세스할 수 있는 대상을 제어해야 합니다. 서비스가 사용자를 대신하여 작업을 수행하기 위해 수임한 역할을 [서비스 역할](id_roles.md#iam-term-service-role)이라고 합니다. 역할이 서비스에 대해 특수한 목적을 수행하는 경우 [서비스 연결 역할](id_roles.md#iam-term-service-linked-role)로 분류될 수 있습니다. 서비스에서 역할을 사용하는지 여부와 서비스에서 사용할 역할을 할당하는 방법을 알아보려면 서비스별 [AWS 문서](https://docs.aws.amazon.com/)를 참조하세요.
역할을 생성해 AWS가 제공하는 서비스에 액세스 권한을 위임하는 것에 대한 자세한 내용은 [AWS 서비스에 대한 권한을 위임할 역할 생성](id_roles_create_for-service.md) 섹션을 참조하세요.
# 외부에서 인증된 사용자에 대한 액세스(ID 페더레이션)
사용자는 이미 회사 디렉터리 등 AWS 외부에 자격 증명을 보유할 수 있습니다. 그러한 사용자가 AWS 리소스를 사용해야 하는 경우(또는 해당 리소스에 액세스하는 애플리케이션을 사용해야 하는 경우), 해당 사용자에게도 AWS 보안 자격 증명이 필요합니다. 자격 증명이 내 조직 또는 서드 파티 자격 증명 공급자(IdP)에서 페더레이션되는 사용자의 권한을 IAM 역할을 사용하여 지정할 수 있습니다.
**참고**
보안 모범 사례로서, IAM 사용자를 생성하지 말고, 그 대신 아이덴티티 페더레이션을 사용하여 [IAM Identity Center](https://docs.aws.amazon.com//singlesignon/latest/userguide/what-is.html)에서 사용자 액세스를 관리하는 것이 좋습니다. IAM 사용자가 필요한 특정 상황에 대한 자세한 내용은 [IAM 사용자(역할이 아님)를 생성해야 하는 경우](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_which-to-choose)를 참조하세요.
## Amazon Cognito를 사용하여 모바일 또는 웹 기반 앱 사용자 페더레이션
AWS 리소스에 액세스하는 모바일 또는 웹 기반 앱을 생성하는 경우, 이 앱에는 AWS에 프로그래밍 방식으로 요청하기 위해 보안 자격 증명이 필요합니다. 대부분의 모바일 애플리케이션 시나리오의 경우 [Amazon Cognito](https://aws.amazon.com/cognito/) 사용을 권장합니다. 이 서비스와 함께 [AWS Mobile SDK for iOS](https://aws.amazon.com/sdkforios/) 및 [AWS Mobile SDK for Android and Fire OS](https://aws.amazon.com/sdkforandroid/)를 사용하면 사용자의 고유 자격 증명을 생성하고 사용자를 인증하여 AWS 리소스에 안전하게 액세스하도록 할 수 있습니다. Amazon Cognito는 다음 섹션에 나열된 자격 증명 공급자를 지원할 뿐만 아니라 [개발자 인증 자격 증명](https://aws.amazon.com/blogs/mobile/amazon-cognito-announcing-developer-authenticated-identities)과 인증되지 않은(게스트) 액세스까지 지원합니다. 또한, Amazon Cognito는 사용자가 디바이스 간에 이동할 때 데이터가 보존되도록 사용자 데이터를 동기화하기 위한 API 작업도 제공합니다. 자세한 내용은 [모바일 앱용 Amazon Cognito](id_federation_common_scenarios.md#id_roles_providers_oidc_cognito) 섹션을 참조하세요.
## 퍼블릭 자격 증명 서비스 공급자 또는 OpenID Connect를 사용하여 사용자 페더레이션
가능하면 항상 모바일 및 웹 기반 애플리케이션 시나리오에 Amazon Cognito를 사용합니다. Amazon Cognito는 퍼블릭 자격 증명 공급자 서비스를 통해 대부분의 백그라운드 작업을 수행합니다. 동일한 타사 서비스를 사용하며 익명 로그인을 지원하기도 합니다. 그러나 고급 시나리오의 경우에는 Login with Amazon, Facebook, Google, 또는 OpenID Connect(OIDC)와 호환되는 모든 IdP로 직접 작업할 수 있습니다. 이들 서비스 중 한 가지를 이용한 OIDC 페더레이션에 대한 자세한 내용은 [OIDC 페더레이션](id_roles_providers_oidc.md) 항목을 참조하세요.
## SAML 2.0으로 사용자 연동하기
조직에서 SAML 2.0(Security Assertion Markup Language 2.0)을 지원하는 자격 증명 공급자 소프트웨어 패키지를 이미 사용하는 경우 IdP(자격 증명 공급자)인 조직과 서비스 공급자인 AWS 간에 신뢰를 형성할 수 있습니다. 그러면 SAML을 사용하여 사용자에게 AWS Management Console에 대한 연동 SSO(Single-Sing On) 또는 AWS API 작업을 호출하기 위한 페더레이션 액세스를 제공할 수 있습니다. 예를 들어 회사가 Microsoft Active Directory와 Active Directory Federation Services를 이용한다면, SAML 2.0을 사용해 연동할 수 있습니다. SAML 2.0를 이용한 사용자 연동에 대한 세부 정보는 [SAML 2.0 연동](id_roles_providers_saml.md)을 참조하세요.
## 사용자 지정 자격 증명 브로커 애플리케이션 생성에 의한 사용자 연동
자격 증명 스토어가 SAML 2.0과 호환되지 않는다면, 사용자 지정 자격 증명 브로커 애플리케이션을 구축해 비슷한 기능을 수행할 수 있습니다. 브로커 애플리케이션이 사용자를 인증하고, AWS에게 사용자를 위한 임시 자격 증명을 요청한 다음, 이를 사용자에게 제공해 AWS 리소스에 액세스하도록 합니다.
예를 들어 Example Corp.에 회사의 AWS 리소스에 액세스하는 내부 애플리케이션을 실행해야 하는 직원들이 많다고 합시다. 직원들은 이미 회사 자격 증명 및 인증 시스템에 자격 증명이 있어서 Example Corp는 각 직원의 IAM 사용자를 별도로 생성하길 원하지 않습니다.
Bob은 Example Corp의 개발자입니다. Example Corp 내부 애플리케이션에서 회사의 AWS 리소스에 액세스하도록 하기 위해 Bob은 사용자 지정 자격 증명 브로커 애플리케이션을 개발합니다. 그 애플리케이션은 직원들이 기존 Example Corp. 자격 증명 및 인증 시스템에 로그인된 상태인지 확인하는데, 그 시스템은 LDAP, Active Directory, 또는 다른 시스템을 사용할 수 있습니다. 그 다음에 자격 증명 브로커 애플리케이션은 직원들에 대한 임시 보안 자격 증명을 획득합니다. 이 시나리오는 이전 시나리오(사용자 지정 인증 시스템을 사용하는 모바일 앱)과 유사합니다. 단지 AWS 리소스에 액세스해야 하는 애플리케이션이 모두 회사 네트워크 내에서 실행되고 회사에 기존 인증 시스템이 있다는 점만 다릅니다.
임시 보안 자격 증명을 얻기 위해 자격 증명 브로커 애플리케이션은 밥(Bob)이 사용자들에 대한 정책을 어떻게 관리하고자 하는지, 그리고 임시 자격 증명이 언제 만료되는지에 따라 `AssumeRole` 또는 `GetFederationToken`을 호출해 임시 보안 자격 증명을 획득합니다. (이러한 API 작업 간의 차이점을 보려면 [IAM의 임시 보안 자격 증명](id_credentials_temp.md) 및 [임시 보안 자격 증명에 대한 권한](id_credentials_temp_control-access.md)를 참조하세요.) 호출은 AWS 액세스 키 ID, 보안 액세스 키, 세션 토큰으로 구성된 임시 보안 자격 증명을 반환합니다. 자격 증명 브로커 애플리케이션은 이 임시 보안 자격 증명을 내부 회사 애플리케이션에서도 사용할 수 있게 해줍니다. 그 앱은 그 임시 자격 증명을 사용해 AWS를 직접 호출할 수 있습니다. 그 앱은 자격 증명이 만료될 때까지 캐싱한 다음, 새로운 일련의 임시 자격 증명을 요청합니다. 다음은 이 시나리오를 설명한 그림입니다.
![\[사용자 지정 자격 증명 브로커 애플리케이션을 사용하는 샘플 워크플로우\]](http://docs.aws.amazon.com/ko_kr/IAM/latest/UserGuide/images/enterprise-authentication-with-identity-broker-application.diagram.png)
이 시나리오에는 다음과 같은 속성이 있습니다.
+ 자격 증명 브로커 애플리케이션은 IAM의 보안 토큰 서비스(STS) API에 액세스하여 임시 보안 자격 증명을 생성할 수 있는 권한이 있습니다.
+ 신원 증명 브로커 애플리케이션을 통해 기존 인증 시스템 내에서 직원이 인증되었는지 확인할 수 있습니다.
+ 사용자는 AWS 관리 콘솔에 대한 액세스 권한을 제공하는 임시 URL(Single Sign-On이라고 함)을 가져올 수 있습니다.
임시 보안 자격 증명 생성에 대한 자세한 내용은 [AWS STS 자격 증명 비교](id_credentials_sts-comparison.md)를 참조하세요 . AWS 관리 콘솔에 대한 액세스 권한을 얻는 SAML 페더레이션 보안 주체에 대한 자세한 내용은 [SAML 2.0 페더레이션 위탁자의 AWS Management Console 액세스 활성화](id_roles_providers_enable-console-saml.md) 섹션을 참조하세요.