AWS에 대한 API 액세스를 위해 SAML 기반 페더레이션 사용 SAML 2.0 기반 페더레이션 구성 개요 AWS 리소스에 대한 SAML 페더레이션 액세스를 허용하는 역할 개요 SAML 기반 페더레이션에서 사용자를 고유하게 식별

SAML 2.0 연동

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

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

조직의 사용자 또는 애플리케이션이 AWS API 작업을 호출할 수 있도록 허용하는 페더레이션 액세스. 조직에서 생성되는 SAML 어설션(인증 응답의 일부)을 사용해 임시 보안 자격 증명을 얻습니다. 이 시나리오는 임시 보안 자격 증명 요청 및 OIDC 페더레이션에 기술된 것과 같이 IAM이 지원하는 다른 페더레이션 시나리오와 유사합니다. 그러나 조직의 SAML 2.0 기반 IdP가 인증 수행 및 권한 부여 확인을 위한 세부 사항을 런타임에 대부분 처리합니다. 이 주제에서는 이러한 시나리오에 대해 설명합니다.
조직에서 AWS Management Console로 이루어지는 웹 기반 SSO(Single Sign-On). 사용자가 SAML 2.0 호환 IdP에서 호스팅하는 조직의 포털에 로그인하고 AWS로 이동하는 옵션을 선택하면 추가 로그인 정보를 제공하지 않고도 콘솔에 리디렉션될 수 있습니다. 타사 SAML IdP를 사용하여 콘솔에 SSO 액세스하거나 사용자 지정 IdP를 만들어 외부 사용자의 콘솔 액세스를 허용할 수 있습니다. 사용자 지정 IdP를 구축하는 방법에 대한 자세한 정보는 사용자 지정 자격 증명 브로커가 AWS 콘솔에 액세스할 수 있도록 하기를 참조하세요.

주제

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

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

조직 내 사용자가 클라이언트 앱을 사용해 조직의 IdP로부터 인증을 요청합니다.
IdP가 조직의 자격 증명 스토어를 이용하여 사용자를 인증합니다.
IdP가 사용자에 대한 정보로 SAML 어설션을 만들어 클라이언트 앱으로 보냅니다.
클라이언트 앱이 AWS STSAssumeRoleWithSAML API를 호출하면서 SAML 공급자의 ARN, 수임할 역할의 ARN, IdP로부터 받은 SAML 어설션을 전달합니다.
클라이언트 앱에 대한 API 응답에는 임시 보안 자격 증명이 포함되어 있습니다.
클라이언트 앱이 임시 보안 자격 증명을 사용하여 Amazon S3 API 작업을 호출합니다.

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

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

참고

페더레이션 복원력을 개선하려면 여러 SAML 로그인 엔드포인트를 지원하도록 IdP 및 AWS 페더레이션을 구성하는 것이 좋습니다. 자세한 내용은 AWS 보안 블로그 문서 How to use regional SAML endpoints for failover(장애 조치에 리전 SAML 엔드포인트를 사용하는 방법)를 참조하세요.

조직의 IdP와 AWS가 서로 신뢰하도록 구성하는 방법

AWS를 조직의 IdP에 서비스 제공업체(SP)로 등록합니다. https://region-code.signin.aws.amazon.com/static/saml-metadata.xml 의 SAML 메타데이터 문서를 사용합니다.

가능한 region-code 값 목록은 AWS 로그인 엔드포인트의 리전(Region) 열을 참조하세요.

필요에 따라 https://signin.aws.amazon.com/static/saml-metadata.xml 에서 SAML 메타데이터 문서를 사용할 수 있습니다.
조직의 IdP를 사용하여 AWS에서 IdP를 IAM 자격 증명 공급자로 기술하는 동등한 메타데이터 XML 파일을 생성합니다. 그 파일에는 발급자 이름, 생성 일자, 만료 일자 및 AWS가 조직에서 오는 인증 응답의 유효성을 검증하는 데 사용할 수 있는 키가 포함되어 있어야 합니다.
IAM 콘솔에서 SAML 자격 증명 공급자 엔터티를 생성합니다. 이 과정의 일부로 단계 2에서 조직의 IdP가 생성한 SAML 메타데이터 문서를 업로드합니다. 자세한 내용은 IAM에서 SAML ID 공급자 생성 단원을 참조하십시오.
IAM에서 하나 이상의 IAM 역할을 생성합니다. 역할의 신뢰 정책에서 SAML 공급자를 보안 주체로 설정함으로써 조직과 AWS 사이에 신뢰 관계를 설정합니다. 역할의 권한 정책은 조직의 사용자가 AWS에서 하도록 허용된 것을 설정합니다. 자세한 내용은 서드 파티 자격 증명 공급자의 역할 만들기(연동) 단원을 참조하십시오.

참고
역할 신뢰 정책에 사용되는 SAML IDP는 해당 역할이 속한 계정과 동일한 계정에 있어야 합니다.
조직의 IdP에서 조직의 사용자 또는 그룹을 IAM 역할로 매핑하는 어설션을 정의합니다. 조직의 다양한 사용자 및 그룹은 서로 다른 IAM 역할에 매핑될 수 있다는 점에 유의하세요. 매핑 수행을 위한 정확한 절차는 사용하고 있는 IdP에 따라 다릅니다. 사용자의 경우 Amazon S3 폴더에 대한 앞의 시나리오에서 모든 사용자가 Amazon S3 권한을 제공하는 동일한 역할에 매핑될 수 있습니다. 자세한 내용은 인증 응답에 대한 SAML 어설션 구성 단원을 참조하십시오.

IdP가 AWS 콘솔에 대한 SSO를 지원하는 경우, 콘솔 세션의 최대 지속 기간을 구성할 수 있습니다. 자세한 내용은 SAML 2.0 페더레이션 사용자가 AWS Management Console에 액세스할 수 있게 하기 단원을 참조하십시오.

참고
AWS의 SAML 2.0 페더레이션 구현에서는 IAM 자격 증명 공급자와 AWS 간의 암호화된 SAML 어설션을 지원하지 않습니다. 하지만 고객의 시스템과 AWS 간의 트래픽은 암호화된(TLS) 채널을 통해 전송됩니다.
생성 중인 애플리케이션에서 AWS Security Token Service AssumeRoleWithSAML API를 호출해 그것을 단계 3 단계에서 생성한 SAML 공급자의 ARN, 단계 4 단계에서 생성한 수임할 역할의 ARN 및 IdP에서 얻는 현재 사용자에 대한 SAML 어설션으로 전달합니다. AWS는 역할 수임 요청이 SAML 공급자에서 참조된 IdP로부터 오는지 확인합니다.

자세한 내용은 AWS Security Token Service API 참조의 AssumeRoleWithSAML을 참조하세요.
요청이 성공하면 API는 일련의 임시 보안 자격 증명을 반환하고 애플리케이션은 이를 사용해 AWS에 서명된 요청을 보냅니다. 애플리케이션은 현재 사용자에 대한 정보를 갖고 있어서 이전 시나리오에 설명된 대로 Amazon S3의 사용자별 폴더에 액세스할 수 있습니다.

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 IDP는 해당 역할이 속한 계정과 동일한 계정에 있어야 합니다.

정책에서 확인할 수 있는 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에 정보를 다음과 같은 구조를 사용하여 저장할 수 있습니다.


myBucket/app1/user1
myBucket/app1/user2
myBucket/app1/user3

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

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

saml:namequalifier. Issuer 응답 값(saml:iss)과 AWS 계정 ID 및 IAM에서 SAML 공급자의 표시 이름(ARN의 마지막 부분)을 포함하는 문자열의 연결을 기반으로 하는 해시 값 계정 ID와 SAML 공급자 표시 이름의 연결을 IAM 정책에서 saml:doc 키로 사용할 수 있습니다. 계정 ID와 공급자 이름을 "/123456789012/provider_name"처럼 '/'로 구분해야 합니다. 자세한 정보는 saml:doc의 SAML 기반 AWS STS 연동에 사용할 수 있는 키 키를 참조하세요.

NameQualifier와 Subject의 조합은 페더레이션 사용자를 고유한 이름으로 식별하는 데 사용할 수 있습니다. 다음 유사 코드는 이 값이 계산되는 방식을 보여줍니다. 이 유사 코드에서 +는 연결을 나타내고, SHA1는 SHA-1을 사용해 메시지 다이제스트를 생성하는 기능을 나타내며, Base64는 해시 출력의 Base-64 인코딩 버전을 생성하는 기능을 나타냅니다.

Base64 ( SHA1 ( "https://example.com/saml" + "123456789012" + "/MySAMLIdP" ) )

SAML 기반 연동에 사용 가능한 정책 키에 대한 자세한 정보는 다음(SAML 기반 AWS STS 연동에 사용할 수 있는 키)을 참조하세요.
saml:sub (문자열). 이것은 클레임의 주체로서 여기에는 조직 내 사용자 개개인을 식별할 수 있는 고유 값이 포함됩니다(예: _cbb88bf52c2510eabe00c1642d4643f41430fe25e3).
saml:sub_type (문자열). 이 키는 persistent, transient, 또는 SAML 어설션에서 사용되는 Format 및 Subject 요소의 전체 NameID URI일 수 있습니다. persistent라는 값은 saml:sub의 값이 모든 세션에 걸쳐 사용자에게 동일하다는 것을 나타냅니다. 값이 transient인 경우 각 세션마다 사용자의 saml:sub 값이 다릅니다. NameID 요소의 Format 속성에 대한 자세한 내용은 인증 응답에 대한 SAML 어설션 구성 섹션을 참조하세요.

다음 예에서는 앞의 키를 사용하여 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:::exampleorgBucket/backup/${saml:namequalifier}/${saml:sub}",
      "arn:aws:s3:::exampleorgBucket/backup/${saml:namequalifier}/${saml:sub}/*"
    ],
    "Condition": {"StringEquals": {"saml:sub_type": "persistent"}}
  }
}

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

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

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

문서 규칙

OIDC 페더레이션 관련 추가 리소스

SAML ID 공급자 생성