AWS Identity and Access Management
사용 설명서

AWS 리소스에 대한 액세스를 타사에 부여할 때 외부 ID를 사용하는 방법

이따금 AWS 리소스에 대한 액세스를 타사에 부여해야 할 때가 있습니다(액세스 위임). 이 시나리오의 한 가지 중요한 부분은 IAM 역할 신뢰 정책에서 역할 수임자를 지정하는 데 사용할 수 있는 옵션 정보인 외부 ID입니다.

중요

AWS는 외부 ID를 비밀로 취급하지 않습니다. AWS에서 액세스 키 페어 또는 암호와 같은 비밀 정보를 만든 후에는 다시 볼 수 없습니다. 역할의 외부 ID는 해당 역할을 볼 수 있는 권한을 가진 사람만 볼 수 있습니다.

예를 들어 Example Corp이라는 타사를 고용해 AWS 계정을 모니터링하고 비용을 최적화하기로 했다고 가정해봅시다. 일일 경비를 추적하기 위해 Example Corp은 AWS 리소스에 접근해야 합니다. Example Corp 역시 다른 고객을 위해 다른 많은 AWS 계정을 모니터링합니다.

IAM 사용자 및 AWS 계정의 장기 자격 증명에 대한 액세스 권한을 Example Corp에게 제공하지 마십시오. 대신 IAM 역할과 임시 보안 자격 증명을 사용합니다. IAM 역할은 장기 자격 증명(예: IAM 사용자의 액세스 키)을 공유하지 않고도 AWS 리소스에 액세스할 수 있도록 허용하는 메커니즘을 타사에게 제공합니다.

IAM 역할을 사용하여 AWS 계정과 Example Corp 계정 사이에 신뢰 받는 관계를 설정할 수 있습니다. 이 관계가 설정된 후 Example Corp 계정의 멤버는 AWS STS AssumeRole API를 호출하여 임시 보안 자격 증명을 얻을 수 있습니다. Example Corp 멤버는 자격 증명을 사용하여 계정의 AWS 리소스에 액세스할 수 있습니다.

참고

임시 보안 자격 증명을 얻기 위해 호출할 수 있는 AssumeRole 및 다른 AWS API 작업에 대한 자세한 내용은 다음(임시 보안 자격 증명 요청하기)을 참조하십시오.

이 시나리오에 대한 더 자세한 분석은 다음과 같습니다.

  1. Example Corp을 고용해 고유한 사용자 지정 식별자를 생성하도록 합니다. 고유한 사용자 지정 ID 및 AWS 계정 번호를 부여합니다. 이 정보는 다음 단계에서 IAM 역할을 생성하는 데 필요합니다.

    참고

    이 식별자가 Example Corp의 각 고객에게 고유한 것이라면 Example Corp는 ExternalId에 대해 그들이 원하는 어떤 문자열 값이라도 사용할 수 있습니다. 두 고객이 같은 값을 갖지 않는 한, 고객 계정 번호 또는 임의 문자열이 될 수 있습니다. 이는 '보안 유지'를 위한 것은 아닙니다. Example Corp은 각 고객에게 ExternalId 값을 제공해야 합니다. 가장 중요한 것은 그들의 고객이 아닌 Example Corp이 그것을 생성해야 한다는 것입니다.

  2. AWS에 로그인해 Example Corp에 리소스에 대한 액세스 권한을 부여하는 IAM 역할을 생성합니다. IAM 역할과 마찬가지로 해당 역할에도 권한 정책과 신뢰 정책이라는 2가지 정책이 있습니다. 그 역할의 신뢰 정책은 역할을 위임할 사용자를 지정합니다. 이 예시 시나리오에서 정책은 Example Corp의 AWS 계정 번호를 Principal로 지정합니다. 이렇게 하면 계정의 자격 증명이 그 역할을 수임하도록 허용합니다. 또한, Condition 요소를 신뢰 정책에 추가합니다. 이 Condition은 Example Corp의 고유 고객 ID와 일치하는지 확인하기 위해 ExternalId 컨텍스트 키를 테스트합니다. 예를 들면 다음과 같습니다.

    "Principal": {"AWS": "Example Corp's AWS Account ID"}, "Condition": {"StringEquals": {"sts:ExternalId": "Unique ID Assigned by Example Corp"}}
  3. 역할에 대한 권한 정책은 해당 역할이 누군가가 수행하도록 허용할 수 있는 작업을 지정합니다. 예를 들어 그 역할은 누군가에게 IAM 사용자나 그룹이 아닌 Amazon EC2 또는 Amazon RDS 리소스만을 관리할 수 있게 허용하도록 지정할 수 있습니다. 이 예시 시나리오에서는 권한 정책을 사용하여 Example Corp에게 계정의 리소스 전체에 대한 읽기 전용 액세스 권한을 부여합니다.

  4. 역할을 정의한 후에는 역할의 Amazon 리소스 이름(ARN)을 Example Corp에 제공합니다.

  5. Example Corp이 AWS 리소스에 액세스해야 할 때는 그 회사의 누군가가 AWSsts:AssumeRole API를 호출합니다. 이 호출에는 수임할 역할의 ARN과 사용자 지정 ID에 해당하는 ExternalId 파라미터가 포함되어 있습니다.

Example Corp의 AWS 계정을 사용하는 사람이 요청을 하는 경우와 역할 ARN 및 외부 ID가 올바른 경우에 요청이 성공합니다. 그 경우 요청은 역할이 허용하는 AWS 리소스에 액세스하기 위해 Example Corp이 사용할 수 있는 임시 보안 자격 증명을 제공합니다.

다시 말해서 역할 정책에 외부 ID가 포함된다면 그 역할을 수임하고자 하는 사용자는 누구든지 그 역할에서 보안 주체로 지정되어야 하고 정확한 외부 ID를 포함해야 합니다.

외부 ID를 사용해야 하는 이유는?

추상적인 용어로 말하자면 외부 ID는 그 역할을 위임하고 있는 사용자가 자신이 활동하고 있는 상황을 어설션할 수 있도록 허용합니다. 또한, 계정 소유자가 특정 상황에서만 역할이 위임되도록 허용할 수 있는 방법을 제공합니다. 외부 ID의 주된 기능은 "혼동된 대리자" 문제를 해결하고 방지하는 것입니다.

혼동된 대리자 문제

이전 예시에 이어서 Example Corp은 AWS 계정의 특정 리소스에 대한 액세스 권한이 필요합니다. 그러나 Example Corp에게는 다른 고객도 있으며 각 고객의 AWS 리소스에 액세스할 방법이 필요합니다. 고객들에게 결코 공유되어서는 안 될 비밀인 AWS 계정 액세스 키를 요구하는 대신 Example Corp은 각 사용자에게 역할 ARN을 요청합니다. 하지만 다른 Example Corp 고객은 사용자의 역할 ARN을 추측하거나 얻을 수 있습니다. 해당 고객은 역할 ARN을 사용해 Example Corp을 경유해 AWS 리소스에 대한 액세스 권한을 얻을 수 있습니다. 이러한 형태의 권한 상승은 혼동된 대리자 문제로 알려져 있습니다.

다음 다이어그램은 혼동된 대리자 문제를 보여줍니다.


             혼동된 대리자 문제에 대한 설명

이 다이어그램은 다음과 같이 가정합니다.

  • AWS1은 AWS 계정입니다.

  • AWS1:ExampleRole은 계정의 역할입니다. 이 역할의 신뢰 정책은 Example Corp의 AWS 계정의 역할을 위임할 수 있는 것으로 지정함으로써 Example Corp을 신뢰합니다.

다음은 무슨 일이 일어나는지에 대한 것입니다.

  1. Example Corp 서비스 사용을 시작할 때 Example Corp에 AWS1:ExampleRole의 ARN을 제공합니다.

  2. Example Corp은 그 ARN을 사용해 임시 보안 자격 증명을 얻어 AWS 계정의 리소스에 액세스합니다. 이러한 방식으로 Example Corp을 대신 행위할 수 있는 "대리자"로 신뢰합니다.

  3. 또 다른 AWS 고객도 Example Corp의 서비스를 사용하기 시작하고, 이 고객 역시 Example Corp이 사용할 AWS1:ExampleRole의 ARN을 제공합니다. 아마도 그 다른 고객은 비밀이 아닌 AWS1:ExampleRole을 알거나 짐작했을 것입니다.

  4. 다른 고객이 Example Corp에게 (자신의 것이라고 주장하는) 계정의 AWS 리소스에 액세스할 수 있는 권한을 요청하면, Example Corp은 AWS1:ExampleRole을 사용해 계정의 리소스에 액세스합니다.

이것이 바로 다른 고객이 리소스에 무단으로 액세스하는 과정입니다. 이 고객은 Example Corp이 자신도 모르게 리소스에 대한 작업을 하도록 속일 수 있었기 때문에 Example Corp은 이제 "혼동된 대리자"가 되었습니다.

외부 ID는 어떻게 혼동된 대리자 문제를 방지할까요?

역할의 신뢰 정책에 ExternalId 조건 확인을 포함시킴으로써 혼동된 대리자 문제를 해결합니다. "대리자" 회사는 각 고객에 대한 고유 외부 ID 값을 AWS 자격 증명에 대한 요청에 삽입합니다. 외부 ID는 고객 ID 값으로서 Example Corp의 고객 사이에서 고유한 것이어야 하며 Example Corp 고객의 통제를 벗어나 있어야 합니다. 이것이 바로 Example Corp에서 외부 ID를 얻고 그것을 스스로 찾아내지 않는 이유입니다. 이는 다른 고객으로 가장하는 데 성공한 고객을 방지하는 데 도움이 됩니다. Example Corp은 항상 고객의 할당된 외부 ID를 삽입하므로 자신의 것을 제외한 어떤 외부 ID가 포함된 Example Corp의 요청도 결코 눈에 띄어서는 안 됩니다.

이 시나리오에서 Example Corp의 고유 식별자가 "12345"이고, 다른 고객에 대해서는 그 식별자가 "67890"이라고 가정합시다. 이러한 식별자는 이 시나리오를 위해 단순화된 것입니다. 일반적으로 이러한 식별자는 GUID입니다. 이 식별자가 Example Corp의 고객 사이에서 고유한 것이라고 가정할 때, 외부 ID를 위해 사용하기에 합리적인 값들입니다.

Example Corp은 "12345"라는 외부 ID 값을 부여합니다. 그런 다음 Condition 값이 12345가 되어야 한다고 요구하는 역할의 신뢰 정책에 sts:ExternalId 요소를 다음과 같이 추가해야 합니다.

{ "Version": "2012-10-17", "Statement": { "Effect": "Allow", "Action": "sts:AssumeRole", "Principal": {"AWS": "Example Corp's AWS Account ID"}, "Condition": {"StringEquals": {"sts:ExternalId": "12345"}} } }

이 정책의 조건 요소는 AssumeRole API 호출에 "12345"라는 외부 ID 값이 포함될 때만 Example Corp이 역할을 수임하도록 허용합니다. Example Corp은 고객을 대신해 역할을 위임할 때마다 항상 AssumeRole 호출에 해당 고객의 외부 ID 값을 포함하도록 보장합니다. 다른 고객이 Example Corp에게 ARN을 공급한다 하더라도 Example Corp이 AWS에 대한 요청 시 포함하는 외부 ID를 제어할 수 없습니다. 이는 다음 다이어그램에 나와 있듯이 권한을 부여받지 않은 고객이 리소스에 액세스하지 못하도록 방지하는 데 도움이 됩니다.


            혼동된 대리자 문제를 완화하는 방법
  1. 전과 같이 Example Corp 서비스 사용을 시작할 때 Example Corp에 AWS1:ExampleRole의 ARN을 제공합니다.

  2. Example Corp이 그 ARN을 사용해 AWS1:ExampleRole 역할을 위임하는 경우 Example Corp은 AssumeRole API 호출에 외부 ID("12345")를 포함시킵니다. 외부 ID는 역할의 신뢰 정책과 일치하므로 AssumeRole API 호출은 성공하고 Example Corp은 임시 보안 자격 증명을 획득해 AWS 계정의 리소스에 액세스합니다.

  3. 또 다른 AWS 고객도 Example Corp의 서비스를 사용하기 시작하고, 전과 같이 이 고객 역시 Example Corp이 사용할 AWS1:ExampleRole의 ARN을 제공합니다.

  4. 그러나 이번에는 Example Corp이 AWS1:ExampleRole이라는 역할을 위임하려 할 때 다른 고객과 연결된 외부 ID("67890")를 제공하므로 해당 고객은 이를 바꿀 방법이 없습니다. Example Corp이 이렇게 하는 이유는 역할을 사용하겠다는 요청이 다른 고객에게서 왔으므로, "67890"은 Example Corp이 작용하고 있는 상황을 나타내기 때문입니다. AWS1:ExampleRole의 신뢰 정책에 자신의 외부 ID("12345")가 있는 조건을 추가했기 때문에 AssumeRole API 호출은 실패하고 다른 고객이 계정 리소스에 무단으로 액세스하는 것을 막을 수 있습니다(다이어그램의 빨간색 "X" 참조).

외부 ID는 다른 고객이 Example Corp을 속여 자신도 모르게 리소스에 액세스하지 못하도록 방지함으로써 혼동된 대리자 문제를 완화합니다.

언제 외부 ID를 사용해야 하나요?

다음 상황에서 외부 ID를 사용합니다.

  • AWS 계정 소유자이고 다른 AWS 계정에도 액세스하는 타사를 위한 역할을 구성했습니다. 이 경우 타사에 역할을 위임할 때 포함하는 외부 ID를 요청해야 합니다. 그런 다음 역할의 신뢰 정책에서 외부 ID를 확인합니다. 이렇게 하여 외부 사용자를 대신해서 수행하는 경우에만 역할을 맡을 수 있도록 해야 합니다.

  • 이전 시나리오의 Example Corp와 같은 다른 고객을 대신하여 역할을 위임할 수 있습니다. 각 고객에게 고유한 외부 ID를 할당하고 외부 ID를 역할의 신뢰 정책에 추가하도록 지시해야 합니다. 그런 다음 역할 위임 요청에 정확한 외부 ID를 항상 포함하도록 해야 합니다.

    각 고객에 대한 고유한 식별자를 이미 갖고 있겠지만, 이 고유 ID는 외부 ID로 사용하기에 충분합니다. 외부 ID는 단지 이러한 목적을 위해 명시적으로 생성하거나 별도로 추적할 필요가 있는 특별한 값은 아닙니다.

    외부 ID는 항상 AssumeRole API 호출에 지정해야 합니다. 이 밖에도 고객이 역할 ARN을 부여할 때 정확한 외부 ID가 있든 없든 그 역할을 위임할 수 있는지 확인하십시오. 정확한 외부 ID 없이 역할을 위임할 수 있는 경우 시스템에 고객의 역할 ARN을 저장하지 마십시오. 고객이 정확한 외부 ID를 요구하도록 역할 신뢰 정책을 업데이트할 때까지 기다립니다. 이러한 방식으로 고객이 올바른 일을 할 수 있도록 돕고, 이는 양자 모두 혼동된 대리자 문제에서 보호받는 데 도움이 됩니다.