Lake Formation 권한: IAM만으로 부족한 데이터 레이크 통제
데이터를 읽을 수 있다는 뜻은 하나가 아니다
S3에서 데이터 레이크를 운영하면 접근 판단이 여러 계층에 걸쳐 있다. S3 object를 읽을 IAM 권한, catalog에서 테이블을 볼 권한, 특정 열·행만 볼 권한을 함께 설계해야 한다.
AWS Lake Formation은 S3 데이터와 Glue Data Catalog metadata에 대한 중앙 권한 모델을 제공한다. 리멤버가 공개한 S3 Tables 아키텍처에서도 Lake Formation이 분석 팀과 BI 도구의 접근 제어를 맡는 단계로 표시된다.
1. IAM과 Lake Formation의 책임을 나눈다
IAM은 athena:StartQueryExecution, s3tables:GetTableData처럼 AWS API를 호출할 수 있는지 판단한다. Lake Formation은 그 호출자가 특정 데이터베이스·테이블·컬럼·행을 볼 수 있는지를 데이터 관점에서 판단한다.
둘 중 하나만 허용했다고 접근이 성공하는 것이 아니다. 반대로 권한을 넓게 주어 문제를 우회하면 개인정보와 핵심 회사 데이터가 필요 이상으로 노출될 수 있다.
2. 테이블 권한보다 소유권이 먼저다
권한 설정은 데이터 소유자가 누구인지, 무엇을 위해 수집했는지, 언제 삭제해야 하는지가 정해져야 의미가 있다. 권한을 기술 팀만의 설정값으로 두면 한 번 허용한 후 안 거두는 문제가 생긴다.
권장되는 기본 모델은 다음과 같다.
- 생성자와 소유자를 구분한다.
- 개인정보·영업민감·일반 데이터를 태그로 분류한다.
- 개인이 아닌 역할·그룹에 접근을 부여한다.
- 영구 권한 대신 만료일과 재검토 일정을 둔다.
- 원본뿐 아니라 재처리·임시·추출 산출물에도 같은 정책을 적용한다.
3. 컬럼·행·셀 수준 제어가 필요한 시점
전체 테이블을 따로 복사해 마스킹하는 방식은 복사본 증가와 정책 drift를 만든다. Lake Formation은 열, 행, 셀 수준 필터를 지원한다.
- 연락처·이메일은 숨기고 업종·직무 컬럼만 제공
- 특정 고객·국가·사업부 행만 제공
- 조건에 따라 민감 셀을 NULL 또는 대체값으로 보임
세부 제어가 있어도 최종 쿼리 결과가 파일로 export되면 다시 보호해야 한다. 접근 정책의 경계는 원본 저장소가 아니라 데이터 생애주기 전체다.
4. 감사 로그는 ‘설정이 맞음’을 증명하지 않는다
CloudTrail로 누가 어떤 Lake Formation API를 호출했는지, 어느 role이 접근을 시도했는지 추적할 수 있다. 그러나 로그가 있다는 것은 현재 권한이 최소인지, 소유자가 승인했는지를 증명하지 않는다.
따라서 정기적으로 다음을 확인한다.
- 장기 미사용 권한
- 개인에 직접 부여된 권한
- 태그가 없거나 소유자가 없는 테이블
- 실패한 접근의 급증과 비정상적인 export
- 파이프라인 role과 사람 조회 role의 분리