혼란스러운 대리인(confused deputy) 문제

혼란스러운 대리인(confused deputy) 문제

혼란스러운 대리인 문제는 작업을 수행할 권한이 없는 개체가 더 권한이 많은 개체를 강제로 그 작업을 수행하게 만드는 보안 문제입니다. 이를 방지하기 위해 AWS는 써드파티(교차 계정이라고 함) 또는 다른 AWS 서비스(교차 서비스라고 함)에 계정의 리소스에 대한 접근을 제공할 때 계정을 보호하는 데 도움이 되는 도구를 제공합니다.

출처: 문서

본문

때로는 AWS 리소스에 대한 접근을 써드파티에 부여해야 할 수도 있어요(접근 위임). 예를 들어 소비를 최적화하고 AWS 계정을 모니터링하기 위해 Example Corp라는 써드파티 회사를 고용하기로 했다고 가정해 보겠습니다. 일일 지출을 추적하려면 Example Corp가 AWS 리소스에 접근해야 해요. Example Corp는 다른 고객을 위해 다른 많은 AWS 계정도 모니터링합니다. IAM 역할을 사용해 AWS 계정과 Example Corp 계정 사이에 신뢰 관계를 설정할 수 있어요. 이 시나리오의 중요한 측면 중 하나는 *외부 ID(external ID)*입니다. 외부 ID는 IAM 역할 신뢰 정책에서 역할을 수임할 수 있는 사람을 지정하는 데 사용할 수 있는 선택적 식별자입니다. 외부 ID의 주요 기능은 혼란스러운 대리인 문제를 해결하고 방지하는 것입니다.

일부 AWS 서비스(호출 서비스)는 AWS 서비스 주체를 사용해 다른 AWS 서비스(피호출 서비스)의 AWS 리소스에 접근합니다. 이러한 서비스 상호작용 중 일부에서는 호출 서비스가 다른 AWS 계정에 있는 피호출 서비스의 리소스와 통신하도록 구성할 수 있어요. 그 예로 AWS CloudTrail이 다른 AWS 계정에 있는 중앙 Amazon S3 버킷에 기록하도록 구성하는 것입니다. 호출 서비스인 CloudTrail은 cloudtrail.amazonaws.com에 대한 허용 문을 추가해 S3 버킷 정책을 사용해 S3 버킷에 대한 접근 권한을 부여받습니다.

호출 서비스의 AWS 서비스 주체가 피호출 서비스의 리소스에 접근할 때, 피호출 서비스의 리소스 정책은 호출 서비스를 구성한 행위자가 아니라 AWS 서비스 주체만 인가합니다. 예를 들어 조건 없이 CloudTrail 서비스 주체를 신뢰하는 S3 버킷은 신뢰하는 관리자가 구성한 AWS 계정의 CloudTrail 로그와, S3 버킷 이름을 알고 있는 AWS 계정의 허가되지 않은 행위자의 CloudTrail 로그를 모두 받을 수 있어요.

혼란스러운 대리인 문제는 행위자가 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를 당신을 대신해 행동할 수 있는 "대리인(deputy)"으로 신뢰하는 것입니다.
  3. 다른 AWS 고객도 Example Corp의 서비스를 사용하기 시작하고, 이 고객도 Example Corp가 사용할 AWS1:ExampleRole의 ARN을 제공합니다. 아마 그 고객은 AWS1:ExampleRole을 알거나 추측했을 것입니다. 이는 비밀이 아니기 때문입니다.
  4. 다른 고객이 Example Corp에 (자기 계정이라고 주장하는) 계정의 AWS 리소스에 접근해 달라고 요청하면, Example Corp는 AWS1:ExampleRole을 사용해 당신의 계정의 리소스에 접근합니다.

이것이 다른 고객이 당신의 리소스에 허가되지 않은 접근을 얻을 수 있는 방법입니다. 이 다른 고객이 Example Corp를 속여 당신의 리소스에 대해 무의식적으로 행동하게 만들 수 있었기 때문에, Example Corp는 이제 "혼란스러운 대리인"이 됩니다.

Example Corp는 역할의 신뢰 정책에 ExternalId 조건 확인을 포함하도록 요구해 혼란스러운 대리인 문제를 해결할 수 있어요. Example Corp는 각 고객에 대해 고유한 ExternalId 값을 생성하고 그 값을 역할 수임 요청에 사용합니다. ExternalId 값은 Example Corp의 고객들 사이에서 고유해야 하며, 고객이 아니라 Example Corp가 통제해야 해요. 그래서 이 값을 Example Corp에서 받는 것이지 스스로 만들지 않는 것입니다. 이렇게 하면 Example Corp가 혼란스러운 대리인이 되어 다른 계정의 AWS 리소스에 접근을 부여하는 것을 방지합니다.

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

Example Corp는 외부 ID 값 12345를 당신에게 제공합니다. 그러면 역할의 신뢰 정책에 sts:ExternalId 값이 12345여야 한다고 요구하는 Condition 요소를 추가해야 합니다. 다음과 같습니다:

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

이 정책의 Condition 요소는 AssumeRole API 호출에 외부 ID 값 12345가 포함된 경우에만 Example Corp가 역할을 수임하도록 허용합니다. Example Corp는 고객을 대신해 역할을 수임할 때마다 항상 그 고객의 외부 ID 값을 AssumeRole 호출에 포함하도록 합니다. 다른 고객이 Example Corp에 당신의 ARN을 제공하더라도, Example Corp가 AWS에 대한 요청에 포함하는 외부 ID를 통제할 수는 없습니다. 이는 허가되지 않은 고객이 당신의 리소스에 접근하는 것을 방지하는 데 도움이 됩니다.

더 알아보기 (Learn more)