Lake Formation을 활용한 세부 권한 설정 및 데이터 공유(2)
지난 Lake Formation을 활용한 세부 권한 설정 및 데이터 공유(1) 시리즈에 이은 두번째 시리즈입니다. Lake Formation으로 어떻게 다른 AWS 계정에 데이터 공유를 할 수 있는지 알아볼까요?
4. 교차 계정 데이터 공유
AWS는 철저한 환경 격리 및 세분화된 보안 관리 등을 위해 조직 또는 환경 별로 별도 계정을 생성할 것을 권장합니다. 해당 이유가 아니라도 사내 조직 별 빌링 분리 또는 데이터 격리 등과 같은 이유로 계정을 분리해서 사용하는 사례가 많을 것 같습니다.
Lake Formation을 활용하면 조직 간 계정 별로 데이터가 분리되어 있을 때, 데이터를 조직 간 손쉽게 공유할 수 있습니다. 기존에는 데이터를 계정 간 공유하려면 데이터를 새 계정에 복제하거나 S3 policy설정을 통한 접근 제어가 필요했는데, Lake Formation을 활용하면 이러한 부분들이 쉬워집니다. 여기서 데이터 공유란, 데이터 자체를 공유하는 것은 아니고 Glue 데이터 카탈로그를 공유하는 것입니다. 공유받은 데이터 카탈로그를 Resource link라는 오브젝트 생성을 통해 다양한 AWS 데이터 관련 서비스와의 연동도 가능합니다.
데이터 카탈로그를 타 계정에 공유할 때에도 3번에서 알아본 두 가지 방법 -Named Resource 및 태그 기반 액세스 제어 방법을 사용해 권한을 부여할 수 있습니다. 본 가이드에서는 태그 기반 액세스 제어 방법으로 타 계정에 데이터 카탈로그를 공유해보겠습니다.
Permissions — Data lake permissions 페이지 내 Grant 버튼을 클릭해서 권한 부여 페이지로 이동합니다.
권한을 받을 대상으로 External accounts를 선택 후 B 계정 아이디를 입력합니다. 입력 후 엔터를 두번 치면 해당 계정이 principal로 입력됩니다. 조금 전 생성한 태그 기반으로 특정 열에 대해서만 데이터 접근 권한을 주기 위해 data:analytics 태그를 선택합니다.
Named resource 방법으로 데이터 카탈로그 권한을 부여하고 싶다면, 전 단계에서 알아본 방법을 그대로 적용하시면 됩니다.
DB와 Table에 대해서는 describe만 가능하도록 권한을 부여합니다.
여기에서 RAM(Resource Access Manager)에 대한 이해도가 조금 필요한데요, RAM은 AWS 계정 간 리소스 공유를 도와주는 서비스입니다. Lake Formation 또한 RAM을 활용해서 Glue catalog를 공유합니다. 리소스를 갖고 있는 계정 A가 리소스 공유를 받고자 하는 계정 B에게 리소스 공유에 대한 invitation을 보냅니다. 그 후 계정 B에서 invitation을 수락하면 해당 계정에서도 그 리소스를 사용할 수 있게 됩니다.
Organization으로 묶인 계정 간 데이터 공유 시에는 RAM에서 공유 수락을 받을 필요가 없습니다.
B계정 내 Resource Access Manager 페이지로 이동합니다. Shared with me -Resource shares에서 보면 invitations이 왔다고 알람이 뜬 것을 확인할 수 있습니다.
각 항목을 클릭해 세부 페이지에서 리소스 공유를 수락합니다.
리소스 공유를 수락하면 리소스 status가 Active된 것을 확인할 수 있습니다.
B 계정 내 Lake Formation 또는 Glue 페이지 table 탭에서 공유 받은 데이터 카탈로그를 확인할 수 있습니다.
데이터를 공유 받은 것으로 끝이 아니라 분석 및 가공을 할 수 있어야겠죠. 공유 받은 데이터 카탈로그를 데이터 분석 서비스와 연동하려면 Resource link 생성이 필요합니다. Resource link를 통해서 데이터 카탈로그를 DB 또는 테이블과 연결할 수 있습니다.
계속해서 B 계정 내에서 Resource link를 생성해 보도록 하겠습니다. 해당 Resource link를 담을 DB가 필요하기 때문에 Data catalog - Databases에서 DB를 생성합니다. 해당 DB는 IAM이 아닌 Lake Formation으로 권한 관리를 할 것이기 때문에 페이지 마지막 IAM 관련 내용을 체크 해제합니다.
그 다음 Data catalog - Tables로 이동하여 공유 된 table에 대한 Resource link 생성을 해보겠습니다.
방금 생성한 DB를 선택하여 resource link를 생성합니다.
테이블 목록을 확인해보면 새로운 테이블이 생긴 것을 확인할 수 있습니다. 해당 테이블은 공유받은 데이터 카탈로그와 실제 데이터가 이어진 링크라고 생각하면 됩니다.
Athena에서 확인해보면 Resource link로 생성된 테이블이 조회가 되고 데이터 또한 접근되는 것을 확인할 수 있습니다.
5. 에러 관련
Lake Formation 관련 테스트를 진행하면서 몇 가지 에러들을 맞닥 뜨렸는데, 여러 검색과 시도 끝에 아래와 같은 해결 방법을 찾았습니다.
1.Consumer 계정 내 Athena에서 ‘Permission denied on S3 path’와 같은 에러가 뜰 때
→ Producer 계정의 Lake Formation에 Data lake location이 등록 되어 있지 않아서입니다. Data lake location 등록을 통해 Lake Formation이 해당 S3 내 데이터에 대한 제어가 가능할 수 있도록 설정해야 합니다.
2.Data lake location 등록 이후 Glue crawler 실행 시, ‘LakeFormation Permission denied’라는 에러가 뜰 때
→ Data lake location으로 등록되어 있으면 별도의 permission이 필요합니다. Permissions — Data locations 탭에서 Grant를 선택 후 Glue crawler를 실행시킬 role에게 location에 대한 permission을 추가해야 합니다.
3.모든 권한 제어를 제대로 했으나 Athena 실행 시 에러 메시지도 없이 데이터가 조회되지 않을 때
→ Glue crawler 실행 시 선택된 S3 Path가 특정 파일을 가키고 있다면 데이터가 조회되지 않으니 S3 Path를 특정 버킷으로 수정이 필요합니다.
Lake Formation의 몇 가지 기능들에 대해서 알아보았는데요, 기존에 익숙하던 IAM과 별도로 추가 권한을 제어하는 것이 처음엔 조금은 복잡하게 느껴졌던 것 같습니다.
하지만 태그 기반 또는 필터를 활용해서 세부적으로 데이터에 대한 권한을 관리하고 부여할 수 있다는 것이 큰 메리트로 느껴졌습니다. 데이터 거버넌스와 보안 더욱 대두되고 있는 만큼, Lake Formation이 앞으로 더 많은 곳에서 활용될 수 있을 것으로 기대가 됩니다! 🙌
