워크스페이스 역할, 항목 권한, SQL 권한 — 세 층이 어떻게 겹치나

원문: Secure Your Fabric Data Warehouse 게시일: 2026-03-13 · 저자: WilliamDAssafMSFT (Microsoft)

“이 사람이 왜 이 테이블을 볼 수 있지?” 팀에 사람이 늘어나면 꼭 한 번은 나오는 질문이에요. Fabric의 Warehouse 접근 권한은 한 곳에서 관리되지 않고, 워크스페이스 역할·항목 권한·SQL 권한이라는 세 층이 겹쳐서 결정돼요. 이 세 층의 관계를 알아두면 권한 문제를 훨씬 빠르게 추적할 수 있어요.

세 층이 함께 작동한다

원문은 이렇게 정리해요. Fabric 권한과 세밀한 SQL 권한이 함께 작동해서 Warehouse 접근과, 연결한 뒤의 사용자 권한을 결정해요.

Warehouse에 연결하려면 최소한 그 Warehouse에 대한 Fabric Read 권한이 있어야 해요.
Fabric 항목 권한은 SQL 안에서 별도로 권한을 주지 않고도 사용자에게 SQL 권한을 부여할 수 있게 해줘요.
Fabric 워크스페이스 역할은 워크스페이스 안의 모든 Warehouse에 대한 Fabric 권한을 한 번에 제공해요.
세밀한 사용자 권한은 T-SQL로 추가로 관리할 수 있어요.
Admin·Member·Contributor 역할을 가진 사용자는 서비스 주체¹(service principal)를 이용해 Fabric REST API로 Warehouse를 관리할 수도 있어요.

층 1 — 워크스페이스 역할

워크스페이스 역할은 워크스페이스 안에서 협업하는 팀을 위한 것으로, 역할 배정에 따라 그 워크스페이스의 모든 항목에 적용되는 동작이 정해져요. Warehouse 기준으로 각 역할이 실제로 주는 권한은 이렇게 나뉘어요.

Admin·Member·Contributor: 워크스페이스 안 모든 Warehouse와 SQL analytics endpoint에 대해 CONTROL 권한을 줘요. 완전한 읽기·쓰기 권한은 물론, 세밀한 사용자 SQL 권한까지 직접 관리할 수 있어요. (Admin은 여기에 더해 워크스페이스 범위의 세션을 보고 DMV²로 연결·요청을 모니터링할 수 있어요.)
Viewer: 워크스페이스 안 모든 Warehouse와 SQL analytics endpoint에 대해 CONNECT와 ReadData 권한만 줘요. T-SQL로 테이블·뷰의 데이터를 읽을 수 있는 수준이에요.

즉 Admin·Member·Contributor 세 역할은 Warehouse 관점에서는 사실상 동일한 수준(CONTROL)의 권한을 줘요. 차이는 워크스페이스 관리 기능 쪽에 있지, Warehouse 데이터 접근 수준 자체에 있지 않아요.

층 2 — 항목 권한

항목 권한은 워크스페이스 역할과 달리 개별 Warehouse 하나에만 직접 부여할 수 있어요. 원문은 최소 권한 원칙에 따라 이렇게 권장해요.

읽기 전용 접근만 필요한 사용자라면 Viewer 역할을 주고, T-SQL로 특정 객체에 대한 읽기 권한을 추가로 부여하세요.
지금 해당 솔루션을 실제로 함께 개발하는 팀원만 Admin·Member·Contributor에 배정하세요. 이 세 역할은 워크스페이스 안 모든 항목에 접근 권한을 주기 때문이에요.
더 높은 권한이 필요한 사용자는 Admin·Member·Contributor 중 필요한 작업에 맞는 역할에 배정하세요.
개별 Warehouse나 특정 SQL 객체에만 접근이 필요한 그 외 사용자는 Fabric 항목 권한을 주고, SQL을 통해 해당 객체에 대한 접근을 부여하세요.
사용자 한 명씩 추가하는 대신 Microsoft Entra ID 그룹 단위로 권한을 관리할 수도 있어요.

층 3 — T-SQL 세밀 권한

워크스페이스 역할과 항목 권한은 Warehouse 전체에 대해 뭉뚱그린(coarse) 권한을 쉽게 주는 수단이에요. 하지만 “이 열은 가리고 싶다”, “이 행만 보여주고 싶다”처럼 더 세밀한 통제가 필요할 때는 표준 T-SQL 구문으로 직접 권한을 관리해요. Fabric Warehouse는 애플리케이션 코드를 바꾸지 않고도 이런 세밀한 보호를 적용할 수 있는 몇 가지 기능을 지원해요.

개체 수준 보안(object-level security): 사용자 권한이나 역할에 따라 테이블, 뷰, 프로시저 같은 특정 데이터베이스 개체에 대한 접근을 통제해요.
행 수준 보안(row-level security): 익숙한 WHERE 절 필터 조건을 이용해서, 테이블의 특정 행을 사용자별로 다르게 보여주거나 감춰요.
열 수준 보안(column-level security): 테이블의 특정 열에 대한 접근을 제한해서, 권한이 없는 사용자에게는 해당 열을 숨겨요.
동적 데이터 마스킹(dynamic data masking): 이메일 주소 같은 민감한 값을 쿼리 결과에서 마스킹 처리해요. 데이터베이스에 저장된 값 자체는 바뀌지 않고, 마스킹 규칙이 쿼리 결과에만 적용돼서 기존 애플리케이션 코드를 그대로 쓸 수 있어요.

그래서 “왜 이 사람이 이 테이블을 볼 수 있지”를 추적하려면

권한 문제를 진단할 때는 이 순서로 확인하면 원인을 좁혀갈 수 있어요.

이 사용자가 워크스페이스 역할(Admin/Member/Contributor/Viewer)로 배정돼 있는지, 있다면 그 역할이 워크스페이스의 모든 Warehouse에 어떤 수준(CONTROL 또는 CONNECT+ReadData)을 주는지 확인해요.
워크스페이스 역할이 없거나 부족하다면, 이 특정 Warehouse에 개별 항목 권한이 부여돼 있는지 확인해요.
그 위에 T-SQL GRANT나 행·열 수준 보안, 동적 데이터 마스킹 같은 세밀한 규칙이 추가로 걸려 있는지 확인해요. 이 계층은 앞의 두 계층으로 준 접근을 더 좁히는 역할을 해요.

추가로, Microsoft Purview와 PowerShell을 통해 사용자 감사 로그를 확인하면 실제로 누가 어떤 작업을 했는지도 추적할 수 있어요.

정리

Fabric Warehouse 권한은 워크스페이스 역할(전체 워크스페이스 단위의 뭉뚱그린 권한), 항목 권한(개별 Warehouse 단위의 뭉뚱그린 권한), T-SQL 세밀 권한(개체·행·열 단위의 정교한 통제)이라는 세 층으로 겹쳐서 결정돼요. Admin·Member·Contributor는 Warehouse 데이터 접근 수준 자체는 동일(CONTROL)하고, Viewer는 읽기(CONNECT+ReadData)만 준다는 점, 그리고 최소 권한이 필요한 사용자는 워크스페이스 역할 대신 항목 권한 + T-SQL 권한 조합으로 가는 게 원문이 권장하는 방식이에요.

어휘 주석

서비스 주체(service principal): 사람 대신 애플리케이션이나 스크립트가 Azure·Fabric 리소스에 인증할 때 쓰는 자동화용 계정이에요.
DMV(Dynamic Management View): 서버나 데이터베이스의 현재 상태(실행 중인 쿼리, 연결 세션 등)를 조회할 수 있는 T-SQL 시스템 뷰예요.