자신이 소유한 다른 AWS 계정의 IAM 사용자에 대한 액세스 권한 제공 - AWS Identity and Access Management

자신이 소유한 다른 AWS 계정의 IAM 사용자에 대한 액세스 권한 제공

IAM 사용자에게 AWS 계정 내에서 역할을 전환하거나 소유하고 있는 다른 AWS 계정에 정의된 역할로 전환할 수 있는 권한을 부여할 수 있습니다.

참고

소유하지 않은 또는 제어하지 않는 계정에 대한 액세스 권한을 부여하고자 하는 경우, 이 주제 뒷부분의 타사가 소유한 AWS 계정에 대한 액세스 제공 단원을 참조하십시오.

조직에 중요한 Amazon EC2 인스턴스가 있다고 가정해 봅시다. 사용자에게 인스턴스를 종료할 수 있는 권한을 직접 부여하지 않고, 이러한 권한이 있는 역할을 만들 수 있습니다. 그런 다음 관리자는 인스턴스를 종료해야 하는 경우 해당 역할로 전환할 수 있습니다. 그러면 이러한 인스턴스에 다음과 같은 보호 계층이 추가됩니다.

  • 사용자에게 역할을 수임할 권한을 명시적으로 부여해야 합니다.

  • 사용자는 AWS Management 콘솔을 사용하여 해당 역할로 능동적으로 전환하거나 AWS CLI 또는 AWS API를 사용하여 역할을 수임해야 합니다.

  • 역할에 멀티 팩터 인증(MFA) 보호를 추가하여 MFA 디바이스로 로그인하는 사용자만 역할을 수임할 수 있도록 합니다. 역할을 수임한 사용자가 MFA(멀티 팩터 인증)를 사용하여 처음에 인증을 받도록 역할을 구성하는 방법을 알아보려면 MFA 보호 API 액세스 구성 단원을 참조하십시오.

이 방법을 사용하여 최소 권한 원칙을 적용하는 것이 좋습니다. 다시 말해, 특정 작업이 필요한 경우에만 승격된 권한을 사용하도록 제한하는 것입니다. 역할을 사용하여 중요한 환경을 실수로 변경하는 일을 방지할 수 있습니다. 특히 필요할 때만 역할이 사용되는지 확인하기 위해 중요한 환경을 감사와 결합하는 경우에 그렇습니다.

이러한 목적을 위해 역할을 만들려면 해당 역할의 신뢰 정책 Principal 요소에서 액세스가 필요한 사용자의 ID로 계정을 지정합니다. 그런 다음 이러한 다른 계정의 특정 사용자에게 해당 역할로 전환할 수 있는 권한을 부여할 수 있습니다. 해당 신뢰 영역(신뢰할 수 있는 조직 또는 계정) 외의 계정 내 보안 주체가 역할을 수임하는 권한이 있는지 자세히 알고 싶다면, IAM Access Analyzer란 무엇일까요? 단원을 참조하십시오.

한 계정의 사용자는 동일한 또는 다른 계정의 역할로 전환할 수 있습니다. 사용자는 역할을 사용하는 동안 해당 작업만을 수행하고 해당 역할에서 허용한 리소스만 액세스할 수 있지만, 이들의 원래 사용자 권한은 일시 중지된 상태입니다. 사용자가 역할을 끝내면 원래 사용자 권한이 회복됩니다.

분리된 개발 및 프로덕션 계정을 사용한 예제 시나리오

프로덕션 환경에서 개발 환경을 격리하기 위해 조직이 여러 개의 AWS 계정을 갖고 있다고 가정합시다. 개발 계정의 사용자는 프로덕션 계정의 리소스에 액세스해야 하는 경우가 있습니다. 예를 들어, 개발 환경에서 프로덕션 환경으로 업데이트를 승격하려는 경우 교차 계정 액세스 권한이 필요할 수 있습니다. 두 계정을 모두 사용하는 사용자를 위해 별도의 자격 증명(및 암호)을 생성했다 해도 여러 계정에 대한 자격 증명을 관리할 경우 자격 증명 관리가 어려워집니다. 다음 그림을 보면 모든 사용자가 개발 계정에서 관리됩니다. 그러나 일부 개발자에게는 프로덕션 계정에 대한 제한된 액세스 권한이 필요합니다. 개발 계정에는 Testers와 Developers라는 두 개의 그룹이 있으며 각 그룹에는 고유의 정책이 있습니다.


        역할을 사용하여 다른 계정의 사용자에게 권한 위임
  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 액세스 구성 단원을 참조하십시오.

  2. 개발 계정에서 관리자는 Developer 그룹의 구성원에게 이 역할로 전환할 수 있는 권한을 부여합니다. 이를 수행하려면 Developers 그룹에 UpdateApp 역할에 대한 AWS Security Token Service(AWS STS) AssumeRole API를 호출할 권한을 부여하면 됩니다. 이제 개발 계정의 Developers 그룹에 속한 모든 IAM 사용자는 프로덕션 계정의 UpdateApp 역할로 전환할 수 있습니다. Developer 그룹에 속하지 않은 다른 사용자는 이 역할로 전환할 수 있는 권한이 없으므로 프로덕션 계정의 S3 버킷에 액세스할 수 없습니다.

  3. 사용자가 이 역할로의 전환을 요청:

    • AWS 콘솔: 탐색 표시줄에서 계정 이름을 선택하고 Switch Role(역할 전환)을 선택합니다. 계정 ID(또는 별칭) 및 역할 이름을 지정합니다. 아니면 사용자는 관리자가 이메일로 보낸 링크를 클릭해도 됩니다. 링크를 누르면 세부 정보가 이미 채워져 있는 Switch Role(역할 전환) 페이지로 이동합니다.

    • AWS API/AWS CLI: 개발 계정의 Developers 그룹에 속한 사용자는 AssumeRole 함수를 호출하여 UpdateApp 역할에 대한 자격 증명을 가져옵니다. UpdateApp 역할의 ARN을 이 호출의 일부로 지정합니다. Testers 그룹의 사용자가 동일한 요청을 하는 경우에는 요청이 실패하는데, 이는 Testers가 AssumeRole 역할 ARN을 위해 UpdateApp을 호출할 권한이 없기 때문입니다.

  4. AWS STS는 임시 자격 증명을 반환합니다.

    • AWS 콘솔: AWS STS에서 그 요청이 신뢰할 수 있는 대상(개발 계정)에서 온 것인지 확인하기 위해 그 요청에 대해 역할의 신뢰 정책을 확인합니다. 확인 후 AWS STS에서 AWS 콘솔로 임시 보안 자격 증명을 반환합니다.

    • API/CLI: AWS STS에서 신뢰할 수 있는 대상(Development 계정)이 요청을 보낸 것인지 확인하기 위해 역할의 신뢰 정책에 대한 요청을 확인합니다. 확인 후 AWS STS에서 해당 애플리케이션으로 임시 보안 자격 증명을 반환합니다.

  5. 임시 자격 증명은 AWS 리소스에 대한 액세스를 허용합니다.

    • AWS 콘솔: AWS 콘솔은 이후의 모든 콘솔 작업에서 사용자를 대신하여 임시 자격 증명을 사용합니다. 이 경우에 그 작업이란 productionapp 버킷에 대한 읽기 및 쓰기입니다. 이 콘솔은 프로덕션 계정의 다른 리소스에는 액세스할 수 없습니다. 사용자가 역할을 끝내면 사용자의 권한은 이 역할로 전환하기 전에 보유한 원래의 권한으로 돌아갑니다.

    • API/CLI: 이 애플리케이션에서는 임시 보안 자격 증명을 사용하여 productionapp 버킷을 업데이트합니다. 이 애플리케이션은 임시 보안 자격 증명을 통해 productionapp 버킷에 대한 읽기 및 쓰기만 할 수 있으며 프로덕션 계정의 다른 리소스에는 액세스할 수 없습니다. 애플리케이션은 역할을 종료하지 않아도 되지만 대신에 임시 자격 증명 사용을 중지하고 이후의 API 호출에서 다시 원래의 자격 증명을 사용합니다.