Amazon Web Services 한국 블로그

새로운 기능 – AWS Single Sign-On을 사용한 속성 기반 액세스 제어

이제 AWS Single Sign-On을 사용하여 로그인할 때 AWS 세션에서 사용자 속성을 전달할 수 있습니다. AWS Single Sign-On과 ABAC의 계정 액세스 관리를 중앙에서 처리할 수 있고 AWS SSO, Active Directory 또는 외부 ID 공급자를 ID 소스로 사용할 수 있는 유연성도 제공합니다. AWS에서 ABAC 정책이 제공하는 장점에 대한 자세한 내용은 이 주제에 대한 이전 블로그 게시물을 참조하세요.

개요
한편으로 시스템 관리자는 AWS Single Sign-On ID 리포지토리 또는 관리형 Active Directory에서 사용자 속성을 구성합니다. 시스템 관리자는 외부 ID 공급자(예: Okta, OneLogin PingIdentity)를 구성하고 직원이 AWS에 연동할 때 AWS 세션에서 기존 사용자 속성을 전달할 수 있습니다. 이러한 속성을 AWS 세션 태그라고 합니다. 다른 한편으로 클라우드 관리자는 직원이 일치하는 리소스 태그를 가진 클라우드 소스에만 액세스할 수 있도록 세부적인 권한 정책을 생성합니다.

기능적 역할 대신 일치하는 속성에 기반한 정책을 생성하면 AWS 환경에서 생성하고 관리해야 하는 권한과 역할 개수를 줄이는 데 도움이 됩니다. 예를 들어 레드팀의 개발자 Bob과 블루팀의 개발자 Alice가 AWS에 로그인하고 같은 AWS Identity and Access Management(IAM) 역할을 맡으면 각 팀에 태그된 프로젝트 리소스에 대한 개별적 권한을 받습니다. ID 시스템은 Bob과 Alice가 AWS에 로그인할 때 AWS 세션에서 팀 이름 속성을 보냅니다. 역할의 권한은 일치하는 팀 이름 태그가 있는 프로젝트 리소스에 액세스 권한을 부여합니다. 이제 Bob이 블루팀으로 이동하고 시스템 관리자가 ID 공급자 디렉터리에서 그의 팀 이름을 업데이트하면, IAM에서 권한을 업데이트하지 않고도 블루팀의 프로젝트 리소스에 자동 액세스합니다.

AWS SSO를 구성하여 사용자 속성을 매핑하는 방법
AWS SSO를 구성하기 전에 두 가지 중요한 내용을 강조하려고 합니다. 먼저, ABAC는 AWS SSO에 구성된 ID 소스(AWS SSO 자체, 관리형 Active Directory, 외부 ID공급자)의 속성을 사용합니다. 다음으로, AWS SSO에 액세스 제어를 위한 속성을 전달하는 방법은 두 가지가 있습니다. 접두사 https://thinkwithwp.com/SAML/Attributes/AccessControl를 사용해서 SAML 어설션에 직접 속성을 전달하거나 AWS SSO ID 스토어에 있는 속성을 사용할 수 있습니다. 이러한 속성은 AWS SSO 관리자가 AWS SSO에 생성된 사용자에 대해 구성하거나, Active Directory에서 동기화하거나, 자동 프로비저닝(SCIM)을 사용하여 외부 ID 공급자에서 동기화합니다.

이 데모에서는 외부 ID 공급자와 SCIM을 사용합니다.

다음의 3단계에 따라 AWS SSO를 사용하여 AWS에서 ABAC를 활성화할 수 있습니다.

1단계: 외부 ID 공급자에서 연결된 사용자 ID와 속성으로 ID 소스를 구성합니다. 오늘부터 AWS SSO는 Azure AD, Okta, OneLogin 및 PingIdentity에서 SCIM을 통해 ID 동기화를 지원합니다. 최신 목록은 이 페이지를 확인하세요. 구체적인 내용은 각 ID 공급자에 따라 달라집니다.

2단계: AWS SSO 콘솔 또는 API에서 새로운 액세스 제어 속성 글로벌 속성을 사용하여 액세스 제어를 위한 SCIM 속성을 구성할 수 있습니다. 이 화면에서는 1단계에서 구성한 ID 소스에서 액세스 제어를 위한 속성을 선택합니다.

액세스 제어를 위한 속성

3단계: 2단계에서 구성한 속성을 사용하여 권한 세트와 리소스 기반 정책을 통해 ABAC 규칙을 작성합니다. 자세한 내용은 잠시 후에 설명하겠습니다.

직원이 SSO를 사용하여 AWS 계정에 연동하면 일치하는 속성을 기반으로 AWS 리소스에 액세스합니다.

속성은 세션 태그로 전달됩니다. 이러한 정보는 쉼표로 구분된 key:value 쌍으로 전달됩니다. 모든 속성의 전체 문자 수는 460자 이내여야 합니다.

정책은 어떤 형식인가요?
액세스 제어 규칙을 생성할 때 aws:PrincipalTag 조건 키를 사용하여 권한 세트에서 사용자 속성을 사용할 수 있습니다. 예를 들어 각 부서 이름으로 조직 내의 모든 리소스를 태그하고 개발자에게 자신의 부서 리소스에만 액세스 권한을 제공하는 단일 권한 세트를 사용할 수 있습니다. 개발자가 AWS 계정에 연동할 때마다 AWS SSO는 ID 공급자에서 받은 값으로 부서 세션 태그를 생성합니다. 보안 정책을 적용해서 각 부서의 리소스에 대한 액세스 권한만 부여합니다. 팀에서 개발자와 리소스를 프로젝트에 추가할 때는 올바른 부서 이름으로만 리소스를 태그해야 합니다. 따라서 조직이 새로운 리소스와 개발자를 부서에 추가하면 개발자는 권한 업데이트 없이 각 부서에 속한 리소스만 관리할 수 있습니다.

ABAC SSO 권한 세트 정책은 다음과 같습니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [ "ec2:DescribeInstances"],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": ["ec2:StartInstances","ec2:StopInstances"],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "ec2:ResourceTag/Department": "${aws:PrincipalTag/Department}"
                }
            }
        }
    ]
}

이 정책에서는 누구에게나 DescribeInstances를 허용하지만, EC2 인스턴스 ec2:ResourceTag/Department 태그 값과 일치하는 aws:PrincipalTag/Department 태그 값을 가진 사용자만 인스턴스를 정지하거나 시작할 권한이 있습니다.

AWS 계정의 권한 세트에 이 정책을 연결하세요. AWS Single Sign-On 콘솔 왼쪽에서 [AWS 계정]을 클릭하고 [권한 세트] 탭을 선택합니다. 그런 다음, 권한 세트 생성을 클릭합니다. 다음 화면에서 고객 권한 세트 생성을 선택합니다.

사용자 지정 권한 세트 생성

이름과 설명을 입력합니다. [사용자 지정 권한 정책 생성]이 선택 되었는지 확인합니다. 그런 다음, 이전의 정책을 복사/붙여넣기해서 부서 이름 태그 값이 사용자의 부서 이름 태그 값과 같은 EC2 인스턴스를 시작 및 정지합니다.

권한 세트에 대한 사용자 지정 정책 생성

다음 화면에서 몇 개의 태그를 입력하고 나서 구성을 검토하고 [생성]을 검토합니다. 자, 이제 다 되었습니다.

AWS Security Token Service로 구성한 기존 연동이 있다면 외부 ID 공급자가 AWS SSO를 새로운 애플리케이션 구성으로 간주한다는 것을 기억하세요. 즉, 직접 IAM 연동에서 AWS SSO로 옮기면 외부 ID 공급자 구성을 업데이트해 AWS SSO와 연결하고 이 구성의 세션 태그로 속성을 도입해야 합니다.

정식 출시
AWS Single Sign-On으로 사용자 속성을 구성하는 데 추가 요금은 없습니다. 지금 AWS SSO가 제공되는 모든 AWS 리전에서 사용을 시작할 수 있습니다.

— seb