GetFederationToken에 대한 권한

IAM 사용자가 GetFederationToken 작업을 호출하고 해당 사용자에 대한 임시 자격 증명을 반환합니다. 이 작업은 사용자를 연동합니다. 페더레이션 사용자에게 할당된 권한은 둘 중 한 곳에 정의되어 있습니다.

세션 정책은 임시 세션을 프로그래밍 방식으로 생성할 때 파라미터로 전달하는 고급 정책입니다. 연동 사용자 세션을 생성하고 세션 정책을 전달할 때 결과적으로 얻는 세션의 권한은 사용자의 자격 증명 기반 정책의 교차와 세션 정책입니다. 세션 정책을 사용하여 연동된 사용자의 자격 증명 기반 정책에서 허용되는 권한을 부여할 수는 없습니다.

대부분의 경우 GetFederationToken API 호출로 정책을 전달하지 않으면 그 결과 얻게 되는 임시 보안 자격 증명은 아무 권한이 없습니다. 하지만 리소스 기반 정책은 세션에 대한 추가 권한을 제공할 수 있습니다. 세션을 허용된 보안 주체로 지정하는 리소스 기반 정책을 사용하여 리소스에 액세스할 수 있습니다.

다음 그림은 GetFederationToken 호출에 의해 반환되는 임시 보안 자격 증명에 대한 권한을 정책들이 어떻게 상호 작용하여 결정하는지를 시각적으로 재현한 것입니다.

예: GetFederationToken을 사용한 권한 할당

서로 다른 종류의 정책으로 GetFederationToken API 작업을 사용할 수 있습니다. 여기 몇 가지 예가 있습니다.

IAM 사용자에게 연결된 정책은 다음과 같습니다.

이 예시에는 2개의 백엔드 웹 서비스에 의존하는 브라우저 기반 클라이언트 애플리케이션이 있습니다. 백엔드 서비스 중 하나는 자신만의 인증 서버로서 고유한 자격 증명 시스템을 사용해 클라이언트 애플리케이션을 인증합니다. 다른 백엔드 서비스는 AWS 서비스로, 클라이언트 애플리케이션의 기능 중 일부를 제공합니다. 이 클라이언트 애플리케이션은 서버에 의해 인증되고, 서버는 적절한 권한 정책을 생성하거나 가져옵니다. 서버는 이제 GetFederationToken API를 호출해 임시 보안 자격 증명을 얻은 다음, 그 자격 증명을 클라이언트 애플리케이션에 반환합니다. 이제 클라이언트 애플리케이션은 임시 보안 자격 증명을 사용해 AWS 서비스에 직접 요청할 수 있게 됩니다. 이 아키텍처는 클라이언트 애플리케이션이 장기 AWS 자격 증명을 포함하지 않고도 AWS 요청을 할 수 있도록 허용합니다.

인증 서버에서 이름이 token-app인 IAM 사용자의 장기 보안 자격 증명을 사용하여 GetFederationToken API를 호출합니다. 하지만 장기 IAM 사용자 자격 증명은 서버에 유지되고 클라이언트에 배포되지 않습니다. 다음 예시 정책은 token-app IAM 사용자에게 연결되어 페더레이션 사용자(클라이언트)에게 필요한 가장 폭넓은 권한 집합을 정의합니다. sts:GetFederationToken 권한은 인증 서비스가 페더레이션 사용자에 대한 임시 보안 자격 증명을 얻는 데 필요하다는 점에 유의하십시오.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:GetFederationToken",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "dynamodb:ListTables",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "sqs:ReceiveMessage",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "sns:ListSubscriptions",
      "Resource": "*"
    }
  ]
}

이전 정책은 IAM 사용자에게 여러 가지 권한을 부여합니다. 하지만 이 정책만으로는 페더레이션 사용자에게 권한을 부여하지 않습니다. IAM 사용자가 GetFederationToken을 호출하고 정책을 API 호출의 파라미터로 전달하지 않는다면, 그 결과로 얻은 페더레이션 사용자에게는 유효한 권한이 없습니다.

파라미터로 전달되는 세션 정책

페더레이션 사용자에게 적절한 권한이 할당되도록 하는 가장 일반적인 방법은 GetFederationToken API 호출의 세션 정책을 전달하는 것입니다. 앞의 예시를 확장해 IAM 사용자 token-app의 자격 증명을 사용하여 GetFederationToken 호출이 이루어진다고 가정합니다. 그런 다음 세션 정책이 API 호출의 파라미터로 전달된다고 가정합니다. 결과적으로 페더레이션 사용자는 이름이 productionapp인 Amazon S3 버킷의 콘텐츠를 나열할 권한을 갖습니다. 사용자는 productionapp 버킷의 항목들에 대한 GetObject, PutObject, Amazon S3 및 DeleteObject 작업을 수행할 수 없습니다.

페더레이션 사용자에게 이 권한이 할당되는 것은 권한이 IAM 사용자 정책과 전달한 세션 정책의 교차 지점이기 때문입니다.

페더레이션 사용자는 Amazon SNS, Amazon SQS, Amazon DynamoDB 또는 S3 버킷(productionapp 제외)에서 작업을 수행할 수 없습니다. 이러한 작업은 관련 권한이 GetFederationToken 호출과 연결된 IAM 사용자에게 부여되었더라도 거부됩니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::productionapp"]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": ["arn:aws:s3:::productionapp/*"]
    }
  ]
}

리소스 기반 정책

일부 AWS 리소스는 리소스 기반 정책을 지원하고, 이 정책은 페더레이션 사용자에게 직접 권한을 부여하는 또 다른 메커니즘을 제공합니다. 일부 AWS 서비스만이 리소스 기반 정책을 지원합니다. 예를 들어, Amazon S3에는 버킷이 있고, Amazon SNS에는 주제가 있고, Amazon SQS에는 정책을 연결할 수 있는 대기열이 있습니다. 리소스 기반 정책을 지원하는 모든 서비스 목록은 AWS IAM으로 작업하는 서비스 및 표의 "리소스 기반 정책" 열을 참조하세요. 리소스 기반 정책을 사용하여 페더레이션 사용자에게 직접 권할을 할당할 수 있습니다. 리소스 기반 정책의 Principal 요소에서 페더레이션 사용자의 Amazon 리소스 이름(ARN)을 지정하면 됩니다. 다음 예에서는 이를 설명하고 이름이 productionapp인 S3 버킷을 사용하여 앞의 예시를 확장합니다.

다음 리소스 기반 정책은 버킷에 연결되어 있습니다. 이 버킷 정책은 Carol이라는 페더레이션 사용자가 버킷에 액세스할 수 있도록 허용합니다. 다음 리소스 기반 정책이 적용되고 앞서 기술된 예시 정책이 token-app IAM 사용자에 연결되어 있으면, Carol이라는 페더레이션 사용자는 productionapp라는 버킷에 대해 s3:GetObject, s3:PutObject 및 s3:DeleteObject 작업을 수행할 수 있는 권한이 있습니다. 이는 GetFederationToken API 호출의 파라미터로 전달되는 세션 정책이 없을 때에도 해당됩니다. 왜냐하면 이 경우에 Carol이라는 페더레이션 사용자는 다음 리소스 기반 정책에 의해 명시적으로 권한을 부여받았기 때문입니다.

그 권한이 IAM 사용자 및 페더레이션 사용자 둘 다에게 명시적으로 부여될 때만 페더레이션 사용자는 권한을 부여받는다는 것을 명심하세요. 다음 예제처럼 정책의 Principal 요소에서 페더레이션 사용자의 이름을 명시적으로 지정하는 리소스 기반 정책을 통해서도 계정 내에서 권한을 부여할 수 있습니다.

{
  "Version": "2012-10-17",
  "Statement": {
    "Principal": {"AWS": "arn:aws:sts::account-id:federated-user/Carol"},
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:PutObject",
      "s3:DeleteObject"
    ],
    "Resource": ["arn:aws:s3:::productionapp/*"]
  }
}

정책이 평가되는 방식에 대한 자세한 내용을 알아보려면 정책 평가 로직을 참조하세요.