AWS 기술 블로그
Amazon Redshift와 Keycloak을 활용한 사설망 내 중앙 집중화된 사용자 인증 및 권한 관리 – Amazon Redshift와 Keycloak를 활용한 스키마와 사용자 권한 관리
안내
이 글은 총 5개의 이어지는 글로 구성된 Amazon Redshift와 Keycloak을 활용한 사설망 내 중앙 집중화된 사용자 인증 및 권한 관리 시리즈의 첫번째 글에 해당됩니다. 사설망에서 ID Federation을 통하여 Amazon Redshift를 연결, 사용하고 상세 수준 권한관리를 하시려는 독자분들께서는 시리즈의 첫번째 글 부터 순서대로 읽으시며 실습을 겸하시면 필요한 구성을 성공적으로 진행하실 수 있습니다.
- 글 1 : 솔루션 개요 및 환경 준비
- 글 2 : 사설망 내 Amazon Redshift 클러스터 생성 및 PrivateLink 구성
- 글 3 : ID 페더레이션 구성
- 글 4 : Amazon Redshift JDBC 드라이버 구성 및 ID 페더레이션 실행
- 글 5 : Amazon Redshift와 Keycloak를 활용한 스키마와 사용자 권한 관리
** 앞 글에서 이어집니다.
Amazon Redshift와 Keycloak를 활용한 스키마와 사용자 권한 관리
AWS IAM 역할을 활용한 Amazon Redshift의 스키마 관리
Amazon Redshift는 기본적으로 데이터베이스 오브젝트와 사용자를 생성하고 권한 제어를 할 수 있는 기능들을 제공하고 있습니다. 하지만 앞에서 설명하였듯이 Keycloak과 같은 IAM 솔루션을 보유하고 있는 고객사의 경우에는 사용자 계정 관리를 일원화하여 여러가지 다양한 서비스에 대한 접근 관리를 효율적으로 하길 원합니다. 특히 데이터 관점에서는 Amazon Redshift 외부에 있는 Amazon S3에 존재하는 데이터를 접근하기 위해서는 AWS Lake Formation과 같은 다른 AWS 서비스와의 연계가 필요합니다. 이를 위해서는 특정 서비스에 종속적이지 않은 사용자 또는 역할이 필요하게 되고, AWS IAM을 통한 인증과 권한이 중요한 역할을 수행하게 됩니다.
이 섹션에서는 AWS IAM 역할을 가진 사용자가 Amazon Redshift에 접속한 이후에, Amazon Redshift 내의 데이터를 관리하는 방안과 Amazon Redshift 외부에 있는 데이터를 관리하는 방안에 대해서 순차적으로 알아보도록 하겠습니다.
- 사전 준비: 앞의 섹션에서 생성한 AWS IAM 역할을 가진 페더레이션 사용자가 Amazon Redshift에서 스키마 관리를 할 수 있도록 Amazon Redshift 내에 사용자와 DB 역할을 생성하고 필요한 권한을 부여합니다. Amazon Redshift에서 테이블을 액세스 할 수 있도록 데이터를 Amazon S3에 준비합니다.
- Amazon Redshift 내부의 데이터 관리: 관리자 DB 역할을 가진 스키마 관리자(redshift.admin@mycompany.local)가 Amazon Redshift에 접속한 후에 내부 스키마를 생성하고 사용자 DB 역할을 일반 사용자(redshift.user@mycompany.local)가 데이터를 조회하는 방법을 알아봅니다.
- Amazon Redshift 외부의 데이터 관리: 관리자 DB 역할을 가진 스키마 관리자(redshift.admin@mycompany.local)가 Amazon Redshift에 접속한 후에 외부 스키마를 생성하고 사용자 DB 역할을 일반 사용자(redshift.user@mycompany.local)가 데이터를 조회하는 방법을 알아봅니다. 외부 스키마를 접근하는 권한 측면에서 Session과 Role 옵션의 차이점에 대해 알아봅니다.
사전 준비
Amazon Redshift에서 스키마와 사용자를 관리하는 가장 기본적인 방법은 RBAC를 사용하는 것입니다. RBAC는 사용자와 스키마 사이에 DB 역할을 두어서 데이터베이스의 권한 관리를 보다 효율적으로 수행할 수 있게 해줍니다. 상세한 내용에 대해서는 RBAC를 사용하여 Amazon Redshift에서 데이터베이스 권한 관리 간편화를 참조하세요.
Amazon Redshift 클러스터에 아래와 같이 2개의 DB 역할을 생성합니다.
- schema_admin: 스키마 관리자를 위한 DB 역할
- schema_user: 스키마 사용자를 위한 DB 역할
그림 8: Amazon Redshift와 Keycloak를 활용한 스키마와 사용자 권한 관리 사전 준비 단계
1.Amazon Redshift 클러스터 관리자로 접속을 합니다.
2. Amazon Redshift 스키마 관리자와 스키마 사용자를 위한 역할을 생성하고, 권한을 부여합니다.
3. Amazon Redshift에서는 AWS IAM 역할로 접속하는 사용자에게 자동으로 IAMR:이라는 접두어가 붙여서 사용자를 자동으로 생성되지만, 미리 사용자를 IAMR: 접두어를 붙여서 아래와 같이 강제로 미리 생성할 수도 있습니다.
4. AWS IAM 역할로 접속한 사용자에게 2단계에서 만든 DB 역할을 부여합니다.
5. 스키마 생성 및 데이터 조회를 위한 데이터(Nation.csv)를 다운로드한 후에 Amazon S3에 업로드를 합니다. (해당 데이터는 AWS에서 제공하는 Redshift Immersion Day에서 사용하는 TPC-H 데이터 셋 중 일부입니다.)
- Amazon S3에 버킷을 생성한 후에 파일의 S3 URI 정보를 확인합니다. (다음 스텝에서 필요합니다.)
Amazon Redshift 내부의 데이터를 관리하는 방안
Amazon Redshift는 내부 데이터에 대한 접근 관리를 위해 Amazon Redshift에 생성되어 있는 DB 역할과 사용자를 사용합니다. 즉 ID 페더레이션으로 Amazon Redshift에 접속하더라도, 접속을 한 후에는 다른 DB 사용자들과 동일하게 동작하게 됩니다.
외부 스키마를 관리할 때는 상황이 다릅니다. 이 경우 페더레이션 사용자에게 할당된 AWS IAM 역할이 중요한 기능을 수행합니다.
아래와 같이 스키마 관리자(redshift.admin@mycompany.local)로 Amazon Redshift에 접속한 후에 테이블을 생성하고 스키마 사용자(redshift.user@mycompany.local)에게 스키마 사용 권한을 부여한 후에 데이터가 정상적으로 조회되는지를 확인합니다.
COPY 명령을 사용하여 Amazon S3에 저장된 데이터 로드
1.스키마 관리자 계정(redshift.admin@mycompany.local)으로 Amazon Redshift에 싱글 사인온으로 접속합니다.
2. 클러스터 생성 시에 기본으로 자동 생성되는 dev 데이터베이스와 public 스키마에 테이블을 생성하고 Amazon S3에 업로드했던 데이터를 적재합니다.
데이터 적재를 위해 COPY 명령어가 동작하려면 Amazon Redshift가 사용자를 대신하여 AWS 서비스에 액세스할 수 있도록 권한 부여가 되어 있어야 합니다. Amazon Redshift 클러스터 생성 시에 필요한 역할을 생성하여 연계시킨 후에 default로 지정을 하면 IAM_ROLE 옵션에 전체 ARN 이름을 입력하지 않고 간단하게 사용할 수 있습니다.
만약 향상된 VPC 라우팅 기능이 켜져 있는 경우, 기본적으로 Amazon Redshift와 다른 리전의 Amazon S3 버킷은 통신할 수 없습니다. 다른 리전의 Amazon S3와 연결성을 확보하려면 다음을 참조하세요.
3. DB 역할(schema_user)에 테이블에 대한 조회 권한을 부여합니다.
4. 데이터 사용자(IAMR:redshift.user@mycompany.local)로 접속을 합니다.
5. 테이블이 정상적으로 조회되는지 확인합니다.
Amazon Redshift 외부의 데이터를 관리하는 방안
Amazon Redshift는 Amazon S3와 같이 데이터 레이크에 있는 데이터를 접근할 수 있도록 Amazon Redshift Spectrum 기능을 지원하고 있습니다. 사용자 측면에서는 Amazon Redshift를 사용하는 것이기 때문에 동일한 인터페이스를 제공하지만, 내부적으로는 다른 AWS 서비스를 접근하는 과정이 필요합니다. 이를 구현하기 위해서는 외부 스키마를 생성하는 과정에서 타 서비스와 연계를 위한 정보를 제공하여야 합니다. 특히 서비스와 서비스를 넘나드는 과정에서 통합 권한 관리를 위해서는 AWS IAM 권한이 필요하게 됩니다.
고려가 되어야 할 부분은 Amazon Redshift는 외부 스키마에 대한 액세스에 대한 권한 부여를 할때 스키마 레벨에서의 제어만 지원합니다. 테이블 레벨의 상세 제어 기능을 위해서 AWS Lake Formation, AWS Glue Catalog와 Amazon S3 등과 같은 서비스의 기능을 사용해야 합니다. AWS Lake Formation을 활용한 기본 데이터 액세스 및 권한 제어에 대해서는 Lake Formation 권한 참조와 AWS Lake Formation 보안 정책을 사용하여 Amazon Redshift Spectrum 사용하기를 참조하면 됩니다.
그리고 외부 스키마를 생성하는 과정에서 어느 AWS IAM 역할을 사용할지를 지정함으로써 사용자 별로 권한 제어를 더 세밀하게 수행할 수 있습니다. 여기서는 외부 스키마 생성시의 2가지 IAM ROLE 옵션(ROLE 또는 SESSION)에 따른 구성 방법과 권한 제어에 대해서 알아봅니다.
ROLE방식
ROLE 방식은 외부 스키마 생성 시 클러스터에 연결된 AWS IAM 역할을 활용하는 방법입니다. 이 방식에서는 페더레이션 관리자(redshift.admin@mycompany.local)나 일반 사용자(redshift.user@mycompany.local)가 개별적인 AWS IAM 권한 정책을 가지고 있더라도, 외부 데이터에 접근할 때는 스키마에 지정된 AWS IAM 역할을 통해 접근하게 됩니다. Role 방식은 클러스터에 이미 연결된 AWS IAM 역할을 사용하기 때문에 관리 측면에서는 단순해지기는 하지만 모든 사용자들이 동일한 권한을 가지게 되어 사용자 레벨의 상세 제어는 지원하지 않습니다.
그림 10: Amazon Redshift 클러스터에 연결된 AWS IAM 역할을 활용한 스키마 관리
1. 외부 스키마를 생성할 때 사용할 AWS IAM 역할을 클러스터에 연결합니다.
Amazon Redshift 서버리스 네임스페이스와 연결된 AWS IAM 역할
그리고 Amazon Redshift Spectrum을 사용하는데 필요한 권한을 부여합니다. 최소한의 권한을 부여하기 위한 정책은 다음을 참조하세요.
2. 스키마 관리자(redshift.admin@mycompany.local)로 접속을 합니다.
3. ROLE 옵션을 사용하여 외부 스키마를 생성합니다.
AWS Glue Catalog에 해당 데이터베이스가 존재하지 않으면 redshift_spectrum_role 데이터베이스가 자동으로 생성된 것을 확인할 수 있습니다.
Amazon S3 버킷에 업로드한 Nation.csv로 외부 테이블을 생성합니다.
정상적으로 외부 테이블이 생성이 되면 관련 메타 데이터 정보가 Glue Catalog에 자동으로 갱신되어 있는 것을 확인할 수 있습니다.
SQL 클라이언트에서 정상적으로 조회되는지 확인합니다.
4. Amazon Redshift는 외부 스키마에 대해서 테이블 단위의 제어 기능을 제공하지 않고, 스키마에 대한 사용 권한만 부여할 수 있습니다(테이블 레벨의 상세 제어를 하려면 AWS Lake Formation 기능을 사용해야 합니다). 외부 스키마 spectrum_role에 대한 USAGE 권한을 scheman_user DB 역할에 부여합니다.
5. 스키마 사용자(redshift.user@mycompany.local)로 SQL 클라이언트에 접속합니다.
6. 외부 테이블이 정상적으로 조회되는지 확인합니다.
사용자에게 AWS IAM 권한 정책을 할당하지 않아도 Amazon Redshift에 연결된 AWS IAM 역할을 공유해서 데이터를 조회할 수 있습니다.
SESSION 방식
SESSION 방식은 외부 스키마를 생성할 때 옵션으로 SESSION을 지정하는 방식입니다. 이 옵션을 지정하면 스키마 관리자나 스키마 사용자가 개별적으로 AWS IAM 권한 정책을 보유하여야 합니다. 이 방식을 사용하게 되면, 사용자별로 서로 다른 AWS IAM 권한을 부여할 수 있기 때문에 데이터에 대한 세밀한 접근 제어가 가능합니다.
그림 11: 페더레이션 사용자에게 부여된 AWS IAM 역할을 활용한 스키마 관리
1. 스키마 관리자(redshift.admin@mycompany.local)와 스키마 사용자(redshift.user@mycompany.local)의 AWS IAM 역할에 Amazon Redshift Spectrum을 사용하는데 필요한 IAM 권한을 부여합니다. 최소한의 권한을 부여하기 위한 정책은 을 참조하세요.
2. 스키마 관리자(redshift.admin@mycompany.local)로 접속을 합니다.
3. SESSION 옵션을 사용하여 외부 스키마를 생성합니다.
AWS Glue Catalog에 해당 데이터베이스가 존재하지 않으면 redshift_spectrum_session 데이터베이스가 자동으로 생성된 것을 확인할 수 있습니다.
Role 방식에 사용했던 데이터(Nation.csv)를 사용하여 외부 테이블을 생성합니다.
정상적으로 외부 테이블이 생성이 되면 관련 메타 데이터 정보가 Glue Catalog에 자동으로 갱신되어 있는 것을 확인할 수 있습니다.
SQL 클라이언트에서 정상적으로 조회되는지 확인합니다.
4. 외부 스키마 spectrum_session에 대한 USAGE 권한을 DB 역할 schema_user에 부여합니다.
5. 스키마 사용자(redshift.user@mycompany.local)로 SQL 클라이언트에 접속합니다.
6. 외부 테이블이 정상적으로 조회되는지 확인합니다.
위와 같이 페더레이션 사용자에게 Lake Foramation 권한이 불충분하다는 메시지가 출력되면 Lake Formation 에서 사용자(redshift.user@mycompany.local)의 AWS IAM 역할(Redshift-User-Role)에 대상 테이블에 대한 권한을 아래와 같이 할당합니다. 상세한 AWS Lake Foramtion 권한 설정은 Lake Formation 권한 관리를 참고하세요.
스키마 사용자(redshift.user@mycomapny.local)에게 부여된 IAM 역할 Redshift-User-Role 에 nation 테이블에 대한 Select 권한을 부여합니다.
다시 스키마 사용자가 nation 테이블을 조회해서 Select 권한이 부여되었는지 확인합니다.
Amazon Redshift에 연결된 AWS IAM 역할을 사용해서 Redshift Spectrum 작업을 하는 경우 스키마 관리자와 스키마 사용자 모두 클러스터에 연결된 AWS IAM 역할을 사용하기 때문에 Lake Formation 권한 오류가 발생하지 않았습니다. 하지만 페더레이션 사용자 각각에 부여된 AWS IAM 역할을 사용해서 Amazon Redshift Spectrum 작업을 하는 경우 개별 사용자에게 할당된 IAM 권한 정책에 외부 테이블에 대한 권한을 할당해야 합니다.
마치며
이번 블로그에서는 높은 보안성이 요구되는 금융사를 포함하여 인터넷 접근이 제한된 AWS 환경에서 Keycloak과 같은 외부 자격 증명 공급자를 활용해 Amazon Redshift에 안전하게 접속하고, 내부 권한 관리를 효과적으로 수행하는 방법에 대해 살펴보았습니다. 구체적으로는 Amazon Redshift의 프로비저닝 클러스터와 서버리스 클러스터 간의 인증 API 차이, Keycloak 속성과의 연동 설정, 그리고 다양한 인증 방식을 통한 접근에서 Amazon Redshift 내부 데이터 및 S3에 저장된 외부 테이블 권한 관리 방안을 다루었습니다. 이를 통해 외부 네트워크와 격리된 환경에서도 Amazon Redshift 기반으로 안전한 데이터 관리 구조를 구축하는 데 필요한 주요 개념과 구현 단계를 제시했습니다.
이와 같은 아키텍처는 외부 환경과의 연결이 제한된 상황에서도 보안성과 유연성을 모두 갖춘 강력한 솔루션을 제공합니다. 특히, Keycloak과 Amazon IAM을 통한 역할 기반 접근 제어를 통해 데이터에 대한 세밀한 권한 관리를 가능하게 함으로써, 기업 내 데이터 거버넌스를 강화하고 사용자 인증 및 권한 관리에 대한 일관된 접근법을 제공합니다.
이 블로그의 내용은 단일 Amazon Redshift 클러스터 환경뿐 아니라, 성능과 비용 최적화를 위해 다수의 Amazon Redshift 클러스터 간 데이터를 공유하는 아키텍처에도 유용하게 적용될 수 있습니다. 다만, 이러한 솔루션을 성공적으로 운영하기 위해서는 다중 클러스터 간 데이터 공유 시 발생할 수 있는 권한 관리 문제와 같은 추가적인 주제에 대한 고민이 필요합니다. 클러스터 간 데이터 공유 시, 각기 다른 클러스터에 존재하는 사용자와 데이터 접근 정책을 일관되게 유지하는 것은 기술적으로 복잡할 수 있으며, 클러스터 및 계정 간 권한 세분화와 효율적 관리를 위한 추가 연구도 요구됩니다.
본 블로그의 내용을 바탕으로, 여러분의 기업 환경에서도 더욱 안전하고 효율적인 접근 관리 솔루션을 설계하시길 바랍니다. 사설망 내에서 외부 자격 증명 공급자와 Amazon Redshift를 연동한 통합적 활용이 제공할 수 있는 보안 향상 효과를 고려하여, 각 조직의 특성에 맞는 최적의 아키텍처를 구축해 보시기를 바랍니다.