들어가며
사내 분석툴로 Redash를 사용중이며, Athena를 통해 데이터를 조회한다. 그러다 보니 bronze/silver/gold 전 레이어에 걸쳐 개인정보(PII)가 포함된 데이터에 대한 접근이 무제한으로 열려있는 상태였다.
ISMS 대응 과정에서 개인정보가 포함된 데이터의 접근 권한을 구조적으로 제어하는 것이 필요해졌다.
기존 방식에는 IAM 기반으로 gold 레이어만 조회하도록 제한했지만 한계가 있었다.
•
bronze/silver 데이터를 직접 join해야 하는 경우 빈번
•
PII 제거용 중복 테이블 약 30개 운영 (동기화 비용 발생)
•
IAM만으로는 컬럼 단위 제어 불가능
이 문제를 해결하기 위해 AWS의 Lake Formation을 도입했다.
Lake Formation 개념
S3 데이터는 기본적으로 IAM으로 접근 제어한다. 하지만 데이터레이크 규모가 커지면 IAM만으로는 다음 문제가 발생한다.
•
테이블·컬럼 단위 차단 불가
•
테이블 단위 정책 관리의 복잡도 증가
•
태그 기반 정책 적용 불가
Lake Formation(이하 LF)은 이 문제를 해결하기 위해 Glue Catalog(메타데이터) + S3 접근을 하나의 권한 모델로 통합한 서비스다.
동작 구조
1.
권한 검증 흐름
Lake Formation은 3개의 레이어로 동작한다.
레이어 | 검증 항목 |
IAM Policy | Athena API 호출 가능한지 |
Lake Formation | DB / 테이블 / 컬럼 접근 권한 |
S3 접근 | 실제 데이터 읽기/쓰기 가능 여부 |
Lake Formation을 도입하면서 가장 헷갈렸던 부분은 IAM / Lake Formation / S3가 각각 어떤 역할을 하고 어떻게 결합되는지였다.
실제 쿼리 실행시 위 레이어 순서로 검증이 이루어지며, 세 레이어는 AND 조건으로 하나라도 실패하면 쿼리는 실패한다
2.
Lake Formation 구성 요소
Lake Formation은 위 흐름 안에서 동작하기 위해 다음 세 가지 핵심 설정을 제공한다.
구성 요소 | 역할 |
Data Permissions | 테이블 / 컬럼 접근 권한 정의 |
Hybrid Access Mode | 어떤 Principal에 LF를 적용할지 결정 |
Data Lake Location | S3 접근을 LF 경유로 전환 |
그리고 이 세 요소는 각 레이어에 영향을 준다.
Data Permissions → Lake Formation 레이어
Hybrid Access Mode → IAM ↔ LF 경계
Data Lake Location → S3 레이어
HCL
복사
이제 위 세가지 구성 요소를 순서대로 살펴보자.
Data Permissions (카탈로그 권한)
Glue Catalog 단위(DB / Table / Column) 권한을 정의한다. 권한 부여 방식은 크게 두가지가 있다.
1.
명시적 Grant
특정 테이블 또는 컬럼을 지정해 권한을 직접 부여하는 방식이다.
•
특정 테이블에만 SELECT 허용
•
특정 Role에만 접근 허용
가장 직관적이지만 테이블 수가 많아질수록 관리 비용이 급격히 증가한다.
2.
Tag-Based Acces Control(TBAC)
리소스(DB / 테이블 / 컬럼)에 태그를 붙이고 태그 기준으로 권한을 부여하는 방식이다.
예를 들어 다음과 같은 태그를 정의할 수 있다.
태그: sensitivity
값: public | pii
구조:
Database (public)
└─ Table (상속)
└─ Column (기본 public → PII만 pii로 override)
HCL
복사
명시적 grant 방식은 다음과 같은 한계가 있다.
•
테이블이 늘어날수록 권한 설정이 기하급수적으로 증가
•
신규 테이블 생성 시 권한 누락 가능성 존재
•
컬럼 단위 제어 시 관리 복잡도 폭증
TBAC를 사용하면 권한을 리소스가 아니라 속성 기준으로 정의할 수 있다.
정책:
→ sensitivity = public 인 리소스만 조회 허용
Plain Text
복사
이 구조의 장점은 다음과 같다.
•
신규 테이블 추가 시 자동으로 권한 적용 (태그 상속)
•
PII 컬럼만 태그 override로 분리 가능
•
Role별 정책 재사용 가능 (태그 기반)
실제 적용 방식
•
Database에 sensitivity=public 기본 태그 부여
•
모든 테이블/컬럼은 기본적으로 public 상속
•
PII 컬럼만 sensitivity=pii로 override
•
Redash는 sensitivity=public만 조회 가능하도록 설정
Hybrid Access Mode
Lake Formation을 처음 도입할 때 가장 먼저 부딪혔던 문제는 권한을 설정해도 실제로 적용되지 않는다는 점이다.
IAMAllowedPrincipals
기본적으로 모든 Glue 리소스에는 IAMAllowedPrincipals가 설정되어 있다.
이 설정이 살아있는 한 IAM 권한이 있는 Principal은 Lake Formation 권한과 관계없이 접근을 허용한다.
실제 LF 권한을 적용하기 위해서는 두가지 방법이 있다.
방식 | 설명 | 특징 |
IAMAllowedPrincipals 제거 | LF 권한만으로 접근 제어 | 전면 전환, 위험 |
Hybrid Access Mode | 일부 Principal만 LF 적용 | 점진적 전환 가능 |
IAMAllowedPrincipals 권한을 회수하면 LF 권한을 강제 할 수 있지만, 누가 어디서 사용중인지 조사 없이 한번에 전환하기에 위험이 있기 때문에 LF에서는 Hybrid Access Mode 모드를 제공한다.
Hybrid Access Mode 개념
데이터베이스 단위로 LF 권한을 강제할지 IAM과 병행할지 선택할 수 있는 옵션이다.
동작 방식은 다음과 같다.
사용자가 테이블 접근 시
해당 Principal이 opt-in 되었는가?
├─ YES → IAMAllowedPrincipals 무시 → LF 권한 적용
└─ NO → IAMAllowedPrincipals 적용 → IAM 권한으로 접근
HCL
복사
Hybrid Mode를 통해 기존 IAM 기반 서비스들이 중단될 위험없이 특정 Role부터 점진적으로 LF로 전환할 수 있다.
S3 접근 구조와 Data Lake Location
Lake Formation 도입 시 가장 중요한 변화는 S3 접근 주체가 바뀐다는 점이다.
기존에는 사용자가 자신의 IAM Role로 S3에 직접 접근했지만 LF를 적용하면 사용자 대신 LF 서비스 Role이 S3에 접근하는 구조로 변경된다.
기존 구조:
Athena → 사용자 IAM Role → S3 접근
HCL
복사
•
S3 Bucket Policy의 Deny 정책을 그대로 적용받음
•
Athena 쿼리도 S3 접근에 의존하기 때문에 함께 차단될 수 있음
Lake Formation 적용 후:
Athena → Lake Formation → LakeFormationAccessRole → S3 접근
HCL
복사
•
Lake Formation이 S3 접근을 대신 수행 (proxy)
•
사용자 IAM Role과 S3 접근이 분리됨
Data Lake Location
S3 경로를 LF에 등록하면 해당 경로는 LF 관리 대상이 된다.
이 설정은 S3 접근 방식을 IAM 기반에서 LF 기반으로 전환하는 역할을 한다.
상태 | S3 접근 방식 |
미등록 | 사용자 IAM으로 직접 접근 |
등록 | LF를 통해 proxy 접근 |
Hybride Mode에 opt-in을 했더라도 바로 LF 권한으로 동작하지 않고, 해당 경로를 반드시 Data Lake Location으로 등록해야 한다.
이 구조를 적용하기 전에는 S3 Deny 설정 때문에 Athena에서 쿼리가 실패해 분석가나 엔지니어가 불편을 겪었다.
Data Lake Location과 Hybrid Access Mode를 적용하면 S3 직접 접근은 계속 차단된 상태로 Athena는 정상적으로 조회 할 수 있게 된다.
또한 Hybrid Access Mode를 통해 Principal(Role/유저) 단위로 LF 적용 여부를 선택할 수 있다.
•
Redash Role → LF 적용 (컬럼 단위 제어)
•
데이터팀 Role → LF 적용 (S3 직접 접근 없이 Athena 조회)
•
기타 서비스 → 기존 IAM 방식 유지
→ 동일 계정 내에서도 Role별로 접근 방식을 분리할 수 있다.
Data Location (쓰기 권한)
여기까지 설정하면 읽기(SELECT)는 정상 동작한다. 하지만 Athena CTAS나 INSERT는 여전히 실패 할 수 있다.
이때 필요한 개념이 Data Location 권한 (DATA_LOCATION_ACCESS)이다.
위 Data Lake Location 과 이름이 비슷해 헷갈릴 수 있는데, Data Location은 S3 경로에 대해 파일을 생성(write)할 수 있는지 제어하는 권한이다.
Athena CTAS는 내부적으로 쿼리를 실행해 결과를 S3에 저장한다. 이 과정에서 LF가 LakeFormationAccessRole을 사용해 S3에 write를 수행한다. 즉, 사용자 IAM이 아니라 LF 서비스 역할이 실제 파일 생성을 담당한다.
정리하자면
S3 접근 구조
[읽기]
IAM → LF → S3 read
[쓰기]
IAM → LF → S3 read + write
↑
Data Location 권한 필요
HCL
복사
전체 흐름 정리
지금까지 설명한 내용을 하나의 흐름으로 정리하면 Lake Formation 기반 데이터 접근은 아래 단계로 동작한다.
전체 구조
[1] IAM (API 레벨)
────────────────────────────────
사용자가 Athena 쿼리 실행 요청
→ athena:StartQueryExecution 허용 여부 확인
↓
[2] Hybrid Access Mode (경로 선택)
────────────────────────────────
해당 Principal이 opt-in 되었는가?
├─ YES → Lake Formation 경로로 진입
└─ NO → IAM 기반 접근 (LF 우회)
↓
[3] Lake Formation (카탈로그 권한)
────────────────────────────────
→ DB / 테이블 / 컬럼 접근 권한 확인
→ TBAC 정책 적용 (PII 컬럼 필터링)
↓
[4] Data Lake Location (S3 접근 방식)
────────────────────────────────
→ S3 접근을 LF proxy로 전환
→ LakeFormationDataAccessRole 사용
↓
[5] S3 접근 (실제 데이터)
────────────────────────────────
→ 데이터 read 수행
(쓰기인 경우)
↓
[6] Data Location 권한
────────────────────────────────
→ S3 write 가능 여부 추가 확인
HCL
복사
Redash가 PII 차단되는 흐름
Redash에서 Athena를 통해 다음과 같은 쿼리를 실행한다고 가정한다.
SELECT * FROM gold.users
SQL
복사
이 쿼리는 내부적으로 아래 흐름을 따라 실행된다.
1. Redash Role이 Athena 쿼리 실행 요청
→ IAM에서 athena:StartQueryExecution 허용 → 통과
2. Hybrid Access Mode 확인
→ Redash Role은 opt-in 상태
→ IAMAllowedPrincipals 무시
→ Lake Formation 권한 강제 적용
3. Lake Formation 권한 검증 (TBAC)
→ 정책: sensitivity = public 만 허용
→ users 테이블 컬럼:
- id (public)
- email (pii)
- phone (pii)
→ 결과: email, phone 컬럼 제외
4. Data Lake Location 적용
→ S3 접근은 사용자 IAM이 아니라
LakeFormationDataAccessRole을 통해 수행
→ S3 Deny 정책과 무관하게 LF 정책 기준으로 접근
5. S3에서 데이터 read
→ 최종 결과:
PII 컬럼이 제거된 상태로 데이터 반환
HCL
복사
성과
Lake Formation 도입을 통해 단순 권한 제어를 넘어서 데이터 접근 방식을 구조적으로 개선할 수 있었다.
•
PII 중복 테이블 제거
◦
기존에 PII 제거를 위해 운영하던 약 30개 이상의 중복 테이블 제거
◦
원본 동기화 비용 및 데이터 일관성 관리 부담 해소
•
컬럼 단위 접근 제어 구현
◦
약 160개 PII 컬럼을 TBAC 기반으로 관리
◦
Redash에서는 별도 처리 없이 자동으로 PII 차단
•
권한 관리의 코드화
◦
Terraform으로 권한과 태그를 관리하여 변경 이력 추적 가능
◦
수동 설정이 아닌 코드 기반 운영으로 전환
•
운영 비용 감소 및 확장성 확보
◦
신규 테이블/컬럼 추가 시 별도 권한 작업 없이 태그 기반 자동 적용
◦
Role이나 계정이 추가되어도 정책 재사용 가능
마치며
처음에는 단순히 컬럼 권한을 설정하는 작업인줄 알았는데 실제로는 IAM, Lake Formation, S3가 어떻게 결합되어 동작하는지 이해하는 과정이 더 컸다.
특히 다음 두 가지를 이해한 이후 전체 구조가 더 들어오게 되었다.
1.
Lake Formation이 S3 접근 주체를 바꾼다는 점
2.
읽기와 쓰기(Data Location 권한)가 분리되어 있다는 점
이 구조를 통해 S3는 직접 접근을 차단하면서 Athena 기반 분석은 유지하는 보안과 활용성을 동시에 만족하는 데이터 레이크를 구성할 수 있었다.