데이터의 권한 관리를 단순화하는 AWS Lake Formation 사용하기

AWS에서 데이터 레이크를 구축하기 위해서는 3가지 서비스가 필요합니다.

  • 데이터를 저장하는 S3
  • 테이블에 대한 메타 데이터를 저장하는 Glue Data Catalog
  • 데이터를 쿼리할 수 있는 Athena

이렇게 3가지 서비스를 이용하여 데이터 레이크를 구축하고 나면, 그 다음에 고민해야 하는 문제는 바로 사용자별 권한 관리입니다. 사용자에 따라서 접근 가능한 데이터와 그렇지 않은 데이터를 구분하고 테이블에서 데이터 삭제를 방지하는 등의 여러 조건을 반영하려면 굉장히 번거롭습니다.

IAM으로 권한 관리가 불가능한 이유

데이터 레이크에서 IAM을 이용하여 권한 관리를 한다면 개별 사용자에 따른 수없이 많은 정책을 생성해야 할 수 있습니다. 그래서 사용자가 조금만 늘어나도 관리하기란 결코 쉬운 일이 아닙니다. 왜 그런지 OpsNow에서 사용중인 IAM 기반 권한 관리 예제를 살펴보겠습니다.

저희가 앞선 글에서 Athena에서 데이터를 조회하기 위해서 IAM 정책의 예시를 올려둔 적이 있습니다. 최종적으로 Athena에서 쿼리가 가능하려면 4개의 권한이 필요하다고 하였는데, 데이터 레이크에서 데이터에 대한 권한을 관리하기 위해서는 아래와 같이 2개의 권한을 이용해야 합니다.

  • 데이터가 저장된 S3에 대한 권한
  • 메타 데이터가 저장된 Glue Data Catalog에 대한 권한

그러면 각각에 대한 IAM 정책을 정의하면서 다른 리소스에는 접근하지 못하도록 Resource 정보를 명시하게 될 것입니다. 리소스가 적으면 문제가 없지만, 100개의 리소스에 대해서 개별 권한을 정의하는 경우를 상상해보시기 바랍니다.

100개의 데이터 저장 경로에 대한 S3 권한

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListBucketMultipartUploads", "s3:ListBucket", "s3:GetBucketLocation" ], "Resource": [ "arn:aws:s3:::<bucket01>", ... "arn:aws:s3:::<bucket10>" ] }, { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ], "Resource": [ "arn:aws:s3:::<bucket01>/<path01>", ... "arn:aws:s3:::<bucket10>/<path10>" ] } ] }
Code language: JSON / JSON with Comments (json)

100개의 테이블 메타 데이터에 대한 Glue Data Catalog 권한

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "glue:GetDatabase", "glue:GetDatabases", "glue:GetPartitions", "glue:GetTable", "glue:GetTables", "glue:SearchTables" ], "Resource": [ "arn:aws:glue:ap-northeast-2:<account>:database/<database>", "arn:aws:glue:ap-northeast-2:<account>:table/<database>/<table001>", ... "arn:aws:glue:ap-northeast-2:<account>:table/<database>/<table002>", "arn:aws:glue:ap-northeast-2:<account>:catalog" ] } ] }
Code language: JSON / JSON with Comments (json)

상상이 가시나요? IAM 정책이 도대체 얼마나 거대해질 것인지 감도 오지 않습니다. 게다가 이러한 작업을 각 사용자별로 반복해야 한다고 하면 관리가 왜 불가능한지 이해가 가실 겁니다. 그리고 이렇게 한다고 하더라도 각 테이블에 대한 쿼리 제한, 컬럼 제한과 같은 세분화된 접근 제어도 어렵습니다.

Lake Formation의 역할

그렇다면, Lake Formation이 위와 같은 IAM 정책을 이용한 권한 관리에 비해서 어떤 장점을 가지고 있을까요? 바로 데이터와 테이블에 대한 세분화된 권한 관리를 별도로 제공함으로써 IAM을 단순화하고 보다 간편하게 접근 제어를 제공한다는 것입니다.

Lake Formation을 이용하여 권한을 관리하려면 위와 같은 IAM 정책에서 Resource 부분을 모든 리소스 * 로 대체하고 Lake Formation을 통해서 권한을 받을 수 있도록 lakeformation:GetDataAccess 액션을 추가하면 됩니다. S3에 대한 접근 권한의 제어도 Lake Formation에서 진행하기 때문에 해당 권한은 명시할 필요도 없습니다.

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "lakeformation:GetDataAccess", "glue:GetDatabase", "glue:GetDatabases", "glue:GetPartitions", "glue:GetTable", "glue:GetTables", "glue:SearchTables" ], "Resource": "*" } ] }
Code language: JSON / JSON with Comments (json)

데이터 접근 권한은 취득했으므로 이제 Athena 권한만 추가하면 데이터를 조회할 수 있게 됩니다. 테스트용 계정을 생성하고 권한을 부여하겠습니다.

LakeFormationAccess가 바로 위에 적어놓은 IAM 정책입니다.

테스트 계정으로 Athena에 접속해서 쿼리를 수행해봅니다.

Lake Formation에서 권한을 부여받은 데이터베이스 혹은 테이블만 표시됩니다.

정상적으로 데이터를 쿼리해오는 것을 확인할 수 있습니다. 이렇게 Lake Formation을 이용해서 세밀한 접근 제어를 수행함과 동시에 보다 간편하게 여러 사용자에 대한 데이터 권한을 관리할 수 있게 되었습니다.

Lake Formation 이용하기

IAM 권한 관리에서 Lake Formation으로 넘어가기 위해서는 사전 준비가 필요합니다. 기본적으로 Lake Formation은 별도의 서비스이므로 IAM 권한 관리 대신에 Lake Formation을 이용하기 위한 셋팅을 진행해야 합니다.

최초 설정

먼저 Lake Formation에 최초로 접근하면 관리자 설정을 하게 됩니다.

데이터 권한 관리를 위한 관리자를 지정해야 합니다.

관리자 지정 이후에 Lake Formation의 Settings에서 다음 설정을 확인합니다.

앞으로 생성될 데이터베이스와 테이블에 대한 권한 관리를 IAM으로 할 것인지 아닌지 결정합니다.

체크 해제를 하면 신규 데이터베이스와 테이블은 Lake Formation을 통해서만 권한이 관리됩니다. 체크를 하면 IAM을 이용해서만 권한이 관리됩니다. 둘 다 병행할 수는 없으며, 체크 해제 시점 전과 후에 대한 권한 관리 방식이 달라질 수 있기 때문에 이를 감안하셔야 합니다.

권한 마이그레이션

Lake Formation으로 통합하려면 위 설정을 해제하고 기존 데이터베이스와 테이블에 대해서도 Lake Formation을 이용할 수 있도록 개별 변경하는 절차가 필요합니다. 각각의 데이터베이스를 찾아서 편집하여 IAM 권한 관리를 제거하면 이후에는 Lake Formation을 이용하게 됩니다.

기존에 IAM으로 관리되는 데이터베이스. 편집을 통해 IAM 권한 관리를 해제하면 됩니다.

이렇게 데이터베이스의 권한 관리를 Lake Formation으로 위임하게 되면 기존에 IAM으로 부여된 모든 권한은 소용이 없어집니다. 그래서 위 작업을 진행하기에 앞서서 먼저 기존 부여된 IAM 권한에 걸맞는 권한을 Lake Formation에서 설정한 다음에 작업 진행하면 됩니다.

S3 위치 등록

Lake Formation은 S3 데이터에 대해서 권한을 관리하지만 실제로 사용자에게 별도의 S3 권한을 요구하지 않습니다. 이렇게 하기 위해서는 데이터가 저장된 S3를 Data Lake Locations로 등록해두어야 합니다.

Data Lake에 포함될 S3를 연결합니다.

이렇게 등록된 S3에 대해서도 Lake Formation에서 권한을 제어해주기 때문에 별도의 권한을 필요로 하지 않는 것입니다.

권한 등록

이제 데이터베이스에 사용자 또는 역할별로 권한을 제공할 수 있습니다.

데이터베이스 및 테이블 권한 추가

물론, S3 접근 권한도 제공해야만 데이터를 읽을 수 있습니다.

S3 권한 추가

여기까지 권한 추가가 완료되어야만 Athena 권한을 받아서 쿼리할 때, 정상적으로 동작하게 됩니다.

마치며…

AWS Lake Formation은 데이터 레이크에서의 권한을 세밀하고 편리하게 제어하기 위해서 제공되는 서비스입니다. 초기 구축은 물론 IAM만 이용하는 경우보다 매우 복잡한 편입니다. 하지만, 동작 방식에 대해서 한 번 이해를 하고 나면 IAM을 이용하는 것보다 얼마나 큰 장점들이 있는지 쉽게 알 수 있습니다.

데이터 레이크의 사용자가 늘어날 수록 그들에 대한 어마어마한 숫자의 데이터 접근 규칙을 IAM 정책으로 관리하는 것은 관리 부하를 기하급수적으로 증가시킵니다. 이제, Lake Formation을 이용하여 관리자 1명이 거의 모든 것을 처리할 수 있게끔 할 수 있습니다.

OpsNow에서도 IAM을 이용한 권한 관리를 Lake Formation으로 옮기려고 하는 이유는 겨우 10명도 안되는 인원에 대한 IAM 권한 관리조차도 버겁기 때문입니다. 여러분도 Lake Formation의 장점을 잘 살려서 이용해보시면 큰 도움이 될 것입니다. 비용도 무료입니다!

Leave a Reply

Your email address will not be published. Required fields are marked *