혼동된 대리자 문제

혼동된 대리자 문제는 작업을 수행할 권한이 없는 엔터티가 권한이 더 많은 엔터티에게 작업을 수행하도록 강요할 수 있는 보안 문제입니다. 이를 방지하기 위해 AWS은(는) 계정의 리소스에 타사(크로스 계정) 또는 기타 AWS 서비스(교차 서비스) 액세스를 제공할 경우 계정을 보호하는 데 도움이 되는 도구를 제공합니다.

이따금 AWS 리소스에 대한 액세스를 타사에 부여해야 할 때가 있습니다(액세스 위임). 예를 들어 Example Corp이라는 타사를 고용해 AWS 계정을 모니터링하고 비용을 최적화하기로 했다고 가정해봅시다. 일일 경비를 추적하기 위해 Example Corp은 AWS 리소스에 접근해야 합니다. Example Corp 역시 다른 고객을 위해 다른 많은 AWS 계정을 모니터링합니다. IAM 역할을 사용하여 AWS 계정과 Example Corp 계정 사이에 신뢰 관계를 설정할 수 있습니다. 이 시나리오의 한 가지 중요한 부분은 IAM 역할 신뢰 정책에서 역할 수임자를 지정하는 데 사용할 수 있는 옵션 정보인 외부 ID입니다. 외부 ID의 주된 기능은 혼동된 대리자 문제를 해결하고 방지하는 것입니다.

AWS에서는 교차 서비스 가장(cross-service impersonation)으로 인해 혼동된 대리자 문제가 발생할 수 있습니다. 교차 서비스 가장은 한 서비스(호출하는 서비스)가 다른 서비스(호출되는 서비스)를 직접적으로 호출할 때 발생할 수 있습니다. 호출하는 서비스는 다른 고객의 리소스에 대해 액세스 권한이 없는 방식으로 작동하게 권한을 사용하도록 조작될 수 있습니다.

크로스 계정 혼동된 대리자 예방

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

이 시나리오에서는 다음과 같이 가정합니다.

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

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

Example Corp 서비스 사용을 시작할 때 Example Corp에 AWS1:ExampleRole의 ARN을 제공합니다.
Example Corp은 그 ARN을 사용해 임시 보안 인증을 얻어 AWS 계정의 리소스에 액세스합니다. 이러한 방식으로 Example Corp을 대신 행위할 수 있는 "대리자"로 신뢰합니다.
또 다른 AWS 고객도 Example Corp의 서비스를 사용하기 시작하고, 이 고객 역시 Example Corp가 사용할 AWS1:ExampleRole의 ARN을 제공합니다. 아마도 그 다른 고객은 비밀이 아닌 AWS1:ExampleRole을 알거나 짐작했을 것입니다.
다른 고객이 Example Corp에게(자신의 것이라고 주장하는) 계정의 AWS 리소스에 액세스할 수 있는 권한을 요청하면, Example Corp는 AWS1:ExampleRole을 사용해 계정의 리소스에 액세스합니다.

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

Example Corp는 사용자가 역할의 신뢰 정책에 ExternalId 조건 확인을 포함하도록 요구하여 혼동된 대리자 문제를 해결합니다. Example Corp는 각 고객에 대해 고유 ExternalId 값을 생성하며 요청에 해당 값을 사용하여 역할을 수임합니다. ExternalId 값은 Example Corp의 고객 사이에서 고유해야 하며 고객이 아닌 Example Corp에 의해 제어되어야 합니다. 이것이 바로 Example Corp에서 외부 ID를 얻고 그것을 스스로 찾아내지 않는 이유입니다. 이로 인해 Example Corp이 혼동된 대리자가 되는 것을 예방하고 다른 계정의 AWS 리소스에 대한 액세스 권한을 부여하는 것을 방지합니다.

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

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


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

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

다음 다이어그램에서 이 방법을 보여줍니다.

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

외부 ID는 다른 고객이 Example Corp을 속여 자신도 모르게 리소스에 액세스하지 못하도록 방지합니다.

교차 서비스 혼동된 대리인 방지

서비스 권한을 특정 리소스로 제한하기 위해 리소스 기반 정책의 aws:SourceArn, aws:SourceAccount, aws:SourceOrgID, 또는 aws:SourceOrgPaths 전역 조건 컨텍스트 키를 사용하는 것이 좋습니다. aws:SourceArn을 사용하면 하나의 리소스만 교차 서비스 액세스 권한과 연결됩니다. aws:SourceAccount를 사용하면 해당 계정의 모든 리소스가 교차 서비스 사용 권한과 연결됩니다. aws:SourceOrgID를 사용하면 조직 내 모든 계정의 모든 리소스가 교차 서비스 사용 권한과 연결될 수 있습니다. aws:SourceOrgPaths를 사용하면 AWS Organizations 경로 내 계정의 모든 리소스가 교차 서비스 사용 권한과 연결됩니다. 경로 사용 및 이해에 대한 자세한 내용은 AWS Organizations 엔터티 경로 이해하기 섹션을 참조하세요.

혼동된 대리자 문제로부터 보호하는 가장 좋은 방법은 리소스 기반 정책에서 리소스의 전체 ARN이 포함된 aws:SourceArn 전역 조건 컨텍스트 키를 사용하는 것입니다. 리소스의 전체 ARN을 모를 경우 또는 여러 리소스를 지정하는 경우, ARN의 알 수 없는 부분에 대해 와일드카드(*)를 포함한 aws:SourceArn 전역 조건 컨텍스트 키를 사용합니다. 예: arn:aws:servicename:*:123456789012:*

만약 aws:SourceArn 값에 Amazon S3 버킷 ARN과 같은 계정 ID가 포함되어 있지 않은 경우, 권한을 제한하려면 두 aws:SourceAccount 및 aws:SourceArn를 모두 사용해야 합니다.

혼동된 대리자 문제로부터 보호하려면 리소스 기반 정책에서 리소스의 조직 ID 또는 조직 경로와 함께 aws:SourceOrgID 또는 aws:SourceOrgPaths 전역 조건 컨텍스트 키를 사용하세요. aws:SourceOrgID 또는 aws:SourceOrgPaths 키가 포함된 정책에는 올바른 계정이 자동으로 포함되며 조직에서 계정을 추가, 제거 또는 이동할 때 정책을 수동으로 업데이트할 필요가 없습니다.

서비스에 연결되지 않은 역할 트러스트 정책의 경우, 트러스트 정책의 모든 서비스는 역할이 호출하는 서비스와 동일한 계정에 있는지 확인하는 iam:PassRole 작업을 수행했습니다. 따라서 트러스트 정책과 aws:SourceAccount, aws:SourceOrgID, 또는 aws:SourceOrgPaths 은(는) 함께 사용하지 않아도 됩니다. 트러스트 정책에서 aws:SourceArn을(를) 사용하면 Lambda 함수 ARN과 같이 역할을 대신 맡을 수 있는 리소스를 지정할 수 있습니다. 일부 AWS 서비스는 새로 만든 역할을 위한 트러스트 정책 aws:SourceAccount 및 aws:SourceArn을(를) 사용하지만 계정의 기존 역할에 대해서는 키를 사용하지 않아도 됩니다.

참고

KMS 키 부여 사용과 AWS Key Management Service을 통합하는 AWS 서비스은 aws:SourceArn, aws:SourceAccount, aws:SourceOrgID, 또는 aws:SourceOrgPaths 조건 키를 지원하지 않습니다. KMS 키 정책에서 이러한 조건 키를 사용하면 KMS 키 부여를 통해서 AWS 서비스가 키를 사용하는 경우 예상치 못한 동작이 발생할 수 있습니다.

AWS Security Token Service에 대한 교차 서비스 혼동된 대리자 예방

AWS 서비스는 역할을 사용하여 서비스가 사용자를 대신하여 다른 서비스의 리소스로 액세스할 수 있어야 합니다. 서비스가 사용자를 대신하여 작업을 수행하기 위해 수임한 역할을 서비스 역할이라고 합니다. 역할에는 두 가지 정책이 필요합니다. 즉, 역할을 수임할 수 있는 보안 주체를 지정하는 역할 신뢰 정책과 역할로 수행할 수 있는 작업을 지정하는 권한 정책이 필요합니다. 역할 신뢰 정책은 IAM의 유일한 리소스 기반 정책 유형입니다. 기타 AWS 서비스에는 Amazon S3 버킷 정책과 같은 리소스 기반 정책이 있습니다.

서비스가 사용자를 대신하여 역할을 맡을 경우 서비스 보안 주체는 역할 신뢰 정책의 sts:AssumeRole 작업을 수행하도록 허용되어야 합니다. 서비스가 sts:AssumeRole을(를) 호출할 때, AWS STS은(는) 서비스 보안 주체가 역할의 권한 정책에 허용되는 리소스에 액세스하는 데 사용하는 일련의 임시 보안 자격 증명을 반환합니다. 서비스가 계정에서 역할을 맡은 경우, 역할 신뢰 정책의 aws:SourceArn, aws:SourceAccount, aws:SourceOrgID, 또는 aws:SourceOrgPaths 전역 조건 컨텍스트 키를 포함하여 역할에 대한 액세스를 예상 리소스에 의해 생성된 요청으로만 제한할 수 있습니다.

예를 들어, AWS Systems Manager Incident Manager에서는 Incident Manager가 사용자를 대신하여 Systems Manager 자동화 문서를 실행할 수 있는 역할을 선택해야 합니다. 자동화 문서에는 CloudWatch 경보 또는 EventBridge 이벤트에 의해 시작된 인시던트에 대한 자동 응답 계획이 포함될 수 있습니다. 다음 역할 신뢰 정책 예에서는 aws:SourceArn 조건 키를 사용하여 인시던트 레코드의 ARN을 기반으로 서비스 역할에 대한 액세스를 제한할 수 있습니다. 응답 계획 리소스 myresponseplan에서 생성된 인시던트 레코드만이 이 역할을 사용할 수 있습니다.


{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Principal": {
      "Service": "ssm-incidents.amazonaws.com"
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "ArnLike": {
        "aws:SourceArn": "arn:aws:ssm-incidents:*:111122223333:incident-record/myresponseplan/*"
      }
    }
  }
}

참고

모든 서비스가 AWS STS 지원 aws:SourceArn, aws:SourceAccount, aws:SourceOrgID, 또는 aws:SourceOrgPaths 조건 키와 통합되는 것은 아닙니다. 지원되지 않는 통합과 함께 IAM 신뢰 정책에서 이러한 키를 사용하면 예상치 못한 동작이 발생할 수 있습니다.

javascript가 브라우저에서 비활성화되거나 사용이 불가합니다.

AWS 설명서를 사용하려면 Javascript가 활성화되어야 합니다. 지침을 보려면 브라우저의 도움말 페이지를 참조하십시오.

문서 규칙

역할

일반적인 시나리오