Databricks Unity Catalog 그룹 & 권한 구조

미리디 Databricks 워크스페이스의 Unity Catalog 카탈로그 구성과 Role 그룹·조직 그룹 분리 기반 권한 체계 현황

개요

미리디 Databricks 워크스페이스(miridih-workspace)의 카탈로그 구성과, Role 그룹(권한 정의) + 조직 그룹(사람 관리)으로 분리된 권한 체계의 현재 상태.

환경 개요

Workspace: miridih-workspace (1개)
카탈로그: 총 14개 (System 제외)

카테고리	카탈로그
Production	bronze, silver, gold, iron, master
Development	bronze_develop, silver_develop, gold_develop, silver_staging, master_develop
Shared / Temp	temp, miridih_training

(확인 필요) 원문은 카탈로그 총 개수를 14개라고 명시하지만, 위 표에 나열된 카탈로그는 12개뿐이다 — 원문 자체의 불일치다.

현재 상태 / 정의

설계 원칙

Role 그룹 + 조직 그룹 분리 — Role은 권한 정의, 조직은 사람만 관리
조직 그룹을 Role 그룹의 멤버로 할당 — IAM Role 방식
전 사용자 프로덕션 READ — 계획은 account users 직접 부여였으나, 실제 구현은 9개 도메인 그룹을 role.*.reader 에 nest 하는 방식이다
개인 grant 금지 — 반드시 그룹을 통해 권한 부여
PII_ACCESS_* 그룹은 현행 유지

Role 그룹

Entitlement Role (워크스페이스 기능 권한)

Role	Entitlements	용도
role.admin	관리자 권한	플랫폼 운영 (전부 포함)

workspace-access, databricks-sql-access는 workspace 할당 시 자동 부여된다.

카탈로그 Role — Reader (카탈로그 레벨 READ)

Role	대상 카탈로그	멤버 (실제 nested)
role.bronze.reader	bronze, iron, master	bizdev, cpdev, cx, design, dxdev, finance, marketing, pnc, product
role.silver.reader	silver (계획 대비 APPLY_TAG·REFRESH 추가)	(동일 9개)
role.gold.reader	gold	(동일 9개)

카탈로그 Role — Writer (카탈로그 레벨 WRITE — 스키마 전체)

Role	대상 카탈로그	멤버 (실제 nested)
role.silver.writer	silver, silver_develop, silver_staging	cpdev, dxdev, product.da, product.di.ae
role.gold.writer	gold, gold_develop + dev 전체	cpdev, dxdev, product.da, product.di.ae
role.master.writer (신설 · 계획 외)	master	dxdev, dxdev.platform.de

스키마/테이블 단위 세분화가 필요하면 조직 그룹에 직접 grant한다.

기타

Role	권한	멤버 (실제)
role.admin	ALL_PRIVILEGES + 클러스터 생성 + PAT	dxdev.platform.de

role.admin은 Entitlement + 카탈로그 ALL_PRIVILEGES를 모두 포함하는 단일 Role이다.

temp, miridih_training은 전 사용자 WRITE를 유지한다 (account users).

system 카탈로그 읽기는 role.* 에 없으며(계획 대비 변경), dxdev.platform·dxdev.security만 보유한다.

권한 레벨 정의

레벨	실제 권한
READ	BROWSE, SELECT, USE_CATALOG, USE_SCHEMA, EXECUTE, READ_VOLUME
WRITE	READ + MODIFY, CREATE_TABLE, CREATE_SCHEMA, CREATE_VOLUME, WRITE_VOLUME, REFRESH, APPLY_TAG
ALL	ALL_PRIVILEGES, EXTERNAL_USE_SCHEMA, MANAGE

조직 그룹 & Role 매핑

네이밍 규칙: 소문자 영어, 하이픈 없이 붙여쓰기. 계층 구분은 dot(.) 사용. 예: product.da, dxdev.platform.de

조직	실제 그룹명	Entitlement Role	카탈로그 Role	구 그룹
사업개발그룹	bizdev	-	reader (bronze/silver/gold)	BIZKR
마케팅그룹	marketing	-	reader	BIZGLOBAL
디자인그룹	design	-	reader	DESIGN
CX그룹	cx	-	reader	CX
피플&컬처그룹	pnc	-	reader	PEOPLE
재무회계그룹	finance	-	reader	-
프로덕트	product	-	reader (상위 그룹)	PD_GREEN·PD_MINT 흡수
└ DA파트	product.da	role.token	role.silver.writer · role.gold.writer	DATA_MA
└ AE파트	product.di.ae	role.token	role.silver.writer · role.gold.writer	DI_AE
DX개발그룹	dxdev	role.token	role.silver/gold/master.writer	DXDEV
└ 플랫폼팀	dxdev.platform	- (상위)	system 읽기	-
└ DE파트	dxdev.platform.de	-	role.admin · role.master.writer	DATA_DP
└ AE파트	dxdev.platform.ae	-	(상속)	DATA_DP_AE
└ 보안	dxdev.security	-	system 읽기 격리	SECURITY
└ AI/ML	dxdev.ai → dxdev.ai.ml4	-	(상속)	DI_DP
└ 백엔드	dxdev.backend.template	-	(상속)	-
CP개발그룹	cpdev	role.token	role.silver.writer · role.gold.writer	CPDEV
관리자	(없음)	role.admin	role.admin	ADMIN·DATA_DP

DevOps파트는 별도 dxdev.platform.devops 그룹 대신 dxdev.platform에 흡수되었다(계획 대비 변경).

그룹 계층 구조

조직 그룹 (사람만 관리)
├ bizdev / marketing / design / cx / pnc / finance ─→ role.*.reader
├ product ─→ role.*.reader
│  └ product.di
│     ├ product.da ────────→ role.silver/gold.writer + role.token
│     └ product.di.ae ─────→ role.silver/gold.writer + role.token
├ dxdev ───────────────────→ role.silver/gold/master.writer + role.token
│  ├ dxdev.platform ───────→ (system 읽기)
│  │   ├ dxdev.platform.de ─→ role.admin + role.master.writer
│  │   └ dxdev.platform.ae
│  ├ dxdev.security ───────→ (system 읽기 격리)
│  ├ dxdev.ai → dxdev.ai.ml4
│  └ dxdev.backend.template
└ cpdev ───────────────────→ role.silver/gold.writer + role.token

develop 카탈로그는 계획과 반대로 account users에 ALL 개방되어 있다(bronze_develop 제외). 관리자는 role.admin(= dxdev.platform.de)이다.

권한 흐름

사용자 → 조직 그룹 (product.da) → Role 그룹 (role.token + role.*.writer) → 실제 권한

사람 이동 → 조직 그룹 멤버만 변경
권한 변경 → Role 그룹만 수정
조직 그룹은 사람만 관리, 직접 권한 부여 없음

Nested Group 권한 상속

✅ 테스트 검증 완료 — 권한은 부모 그룹 → 멤버(자식) 방향으로만 상속된다.

Role 그룹 (role.catalog.writer) ← 권한 부여
  └ 조직 그룹 (product.da) ← 멤버로 추가
    └ 사용자 A ← role.catalog.writer의 권한을 상속받음

Role 그룹에 권한을 부여하면 → 멤버인 조직 그룹의 사용자가 상속받음
반대 방향(자식 → 부모)으로는 상속 안 됨
get_effective API로 검증 완료