SAML 2.0 연동

AWS는 많은 자격 증명 공급자(IdP)가 사용하는 개방형 표준인 SAML 2.0(Security Assertion Markup Language 2.0)이라는 아이덴티티 페더레이션을 지원합니다. 이 기능은 페더레이션 Single Sign-On(SSO)을 활성화하므로 조직의 모든 구성원에 대해 IAM 사용자를 생성하지 않아도 사용자가 AWS Management Console에 로그인하거나 AWS API 작업을 호출할 수 있습니다. SAML을 사용함으로써 AWS로 연동을 구성하는 과정을 단순화할 수 있는데, 이는 사용자 지정 자격 증명 프록시 코드를 작성하는 대신 IdP의 서비스를 사용할 수 있기 때문입니다.

IAM 페더레이션은 다음과 같은 사용 사례를 지원합니다.

AWS에 대한 API 액세스를 위해 SAML 기반 페더레이션 사용

직원들에게 자신의 컴퓨터에서 백업 폴더로 데이터를 복사하는 방법을 제공하려 한다고 가정해 봅시다. 사용자가 컴퓨터에서 실행하는 애플리케이션을 구축합니다. 이 애플리케이션은 백엔드에서 Amazon S3 버킷에 있는 객체를 읽고 씁니다. 사용자는 AWS에 직접 액세스할 수 없습니다. 그 대신 다음 프로세스를 사용합니다.

SAML 2.0 기반 페더레이션 구성 개요

앞의 시나리오와 다이어그램을 통해 설명한 대로 SAML 2.0 기반 페더레이션을 사용하기 전에, 서로를 신뢰하도록 조직의 IdP와 AWS 계정을 구성해야 합니다. 이 신뢰를 구성하는 일반적인 프로세스는 다음 단계에서 설명합니다. 조직 내에는 Microsoft Active Directory 연동 서비스(AD FS, Windows Server의 일부), Shibboleth 또는 기타 호환 가능한 SAML 2.0 공급자와 같이 SAML 2.0을 지원하는 IdP가 반드시 있어야 합니다.

AWS 리소스에 대한 SAML 페더레이션 액세스를 허용하는 역할 개요

IAM에서 생성하는 역할에서는 조직의 페더레이션 사용자가 AWS에서 무엇을 할 수 있는지를 정의합니다. 역할에 대한 신뢰 정책을 생성할 때 앞서 생성한 SAML 공급자를 Principal로 지정합니다. Condition으로 신뢰 정책을 추가로 자세히 살펴봄으로써 특정 SAML 속성과 일치하는 사용자만 그 역할에 액세스하도록 허용할 수 있습니다. 예를 들어 다음 샘플 정책에 설명되어 있듯이 SAML 소속이 staff(https://openidp.feide.no에 의해 어설션되듯이)인 사용자만이 그 역할에 액세스할 수 있도록 지정할 수 있습니다.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Federated": "arn:aws:iam::account-id:saml-provider/ExampleOrgSSOProvider"},
    "Action": "sts:AssumeRoleWithSAML",
    "Condition": {
      "StringEquals": {
        "saml:aud": "https://signin.aws.amazon.com/saml",
        "saml:iss": "https://openidp.feide.no"
      },
      "ForAllValues:StringLike": {"saml:edupersonaffiliation": ["staff"]}
    }
  }]
}

정책에서 확인할 수 있는 SAML 키에 대한 자세한 정보는 SAML 기반 AWS STS 연동에 사용할 수 있는 키 섹션을 참조하세요.

https://region-code.signin.aws.amazon.com/static/saml-metadata.xml에서 saml:aud 속성에 대한 리전 엔드포인트를 포함할 수 있습니다. 가능한 region-code 값 목록은 AWS 로그인 엔드포인트의 리전(Region) 열을 참조하세요.

해당 역할의 권한 정책에 대해서는, 역할에 사용하는 방식으로 권한을 지정합니다. 예를 들어 조직의 사용자가 Amazon Elastic Compute Cloud 인스턴스를 관리할 수 있는 경우 AmazonEC2FullAccess 관리형 정책에서처럼 권한 정책에서 Amazon EC2 작업을 명시적으로 허용해야 합니다.

SAML 기반 페더레이션에서 사용자를 고유하게 식별

IAM에서 액세스 정책을 생성할 때 사용자의 자격 증명을 기반으로 권한을 지정할 수 있으면 종종 쓸모가 있습니다. 예를 들어 SAML을 사용하여 페더레이션된 사용자의 경우 애플리케이션에서 Amazon S3에 정보를 다음과 같은 구조를 사용하여 저장할 수 있습니다.

amzn-s3-demo-bucket/app1/user1
amzn-s3-demo-bucket/app1/user2
amzn-s3-demo-bucket/app1/user3

버킷(amzn-s3-demo-bucket)과 폴더(app1)는 정적 값이므로 Amazon S3 콘솔 또는 AWS CLI를 통해 생성할 수 있습니다. 그러나 사용자 고유 폴더(user1, user2, user3 등)는 사용자가 연동 프로세스를 통해 최초로 로그인할 때까지 사용자를 식별하는 값이 알려지지 않기 때문에 코드를 사용해 런타임에 생성되어야 합니다.

사용자 고유의 세부 정보를 리소스 이름의 일부로 참조하는 정책을 작성하려면, 정책 조건에서 사용될 수 있는 SAML 키에서 사용자 자격 증명이 사용 가능해야 합니다. 다음 키는 IAM 정책에서 사용할 SAML 2.0 기반 페더레이션에 사용할 수 있습니다. 다음 키에서 반환되는 값을 사용하여 Amazon S3 폴더와 같은 리소스의 고유한 사용자 식별자를 생성할 수 있습니다.

다음 예에서는 앞의 키를 사용하여 Amazon S3의 사용자별 폴더에 대한 권한을 부여하는 권한 정책을 보여줍니다. 해당 정책에서는 saml:namequalifier 및 saml:sub를 모두 포함하는 접두사를 사용하여 Amazon S3 객체를 식별한다고 가정합니다. Condition 요소에는 saml:sub_type이 persistent로 설정되어 있는지 확인하는 테스트가 포함되어 있다는 것에 유의하세요. transient로 설정되어 있다면 사용자에 대한 saml:sub 값은 각 세션마다 다를 수 있고 값의 조합은 사용자 고유 폴더를 식별하는 데 사용되어서는 안 됩니다.

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "s3:GetObject",
      "s3:PutObject",
      "s3:DeleteObject"
    ],
    "Resource": [
      "arn:aws:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}",
      "arn:aws:s3:::amzn-s3-demo-bucket-org-data/backup/${saml:namequalifier}/${saml:sub}/*"
    ],
    "Condition": {"StringEquals": {"saml:sub_type": "persistent"}}
  }
}

IdP의 어설션을 정책 키에 매핑하는 것에 대한 자세한 정보는 인증 응답에 대한 SAML 어설션 구성 섹션을 참조하세요.