Power BI RLS 적용 전 검증: 외부 공유와 역할별 노출 범위 점검
AI Editter
영업 담당자에게 자기 지역 매출만 보여 주려고 RLS를 만들었다면, 작성자의 화면에서 필터가 잘 보이는지만 확인해서는 부족합니다. 실제 수신자의 작업 영역 역할, 사용자 매핑, 외부 게스트 식별값에 따라 결과가 달라질 수 있습니다.
특히 Power BI 작업 영역의 Admin·Member·Contributor는 Viewer와 다르게 취급됩니다. Microsoft 문서는 RLS가 작업 영역 Viewer에게 적용되며 편집 권한이 있는 세 역할에는 적용되지 않는다고 설명합니다. 공식 RLS 안내를 기준으로 사용자의 실제 권한부터 확인합니다.
필터를 만들기 전에 허용 범위를 표로 적는다
가상의 지역별 매출 모델을 생각해 보겠습니다. 사용자 이메일과 지역코드를 연결하는 사용자지역 표를 둡니다. 한 사용자가 두 지역을 맡으면 두 행을 기록합니다.
| 사용자 | 허용 지역 | 기대 결과 |
|---|---|---|
| seoul@example.com | SEO | 서울 거래만 |
| busan@example.com | BUS | 부산 거래만 |
| lead@example.com | SEO, BUS | 두 지역 거래 |
| unmapped@example.com | 없음 | 허용 거래 없음 |
| 외부 협력사 시험 계정 | 지정 지역만 | 다른 지역과 내부 전용 정보 제외 |
이 표는 예시입니다. 실제 매핑에는 로그인할 때 평가되는 식별값을 사용해야 합니다. 표시 이름이나 메일 별칭을 임의로 넣지 않습니다. 소문자 변환 등 정규화 규칙을 사용한다면 원본과 로그인 값 모두 같은 규칙을 적용합니다.
동적 RLS와 관계를 함께 검증한다
사용자 매핑 테이블에 다음과 같은 필터를 정의할 수 있습니다.
'사용자지역'[사용자] = USERPRINCIPALNAME()하지만 이 식 하나가 모든 매출표를 자동으로 제한하는 것은 아닙니다. 사용자지역에서 지역과 사실 테이블로 필터가 전달되는 관계를 설계해야 합니다. 다대다 사용자 매핑이나 양방향 보안 필터가 필요한 모델은 경로를 별도로 검토합니다.
권한 매핑이 없는 사용자를 전체 조회로 처리하는 예외 조건을 넣지 않습니다. 새 직원의 매핑이 누락되면 빈 결과로 드러나도록 한 뒤, 정당한 범위를 확인해 추가하는 편이 추적하기 쉽습니다.
비밀 열을 화면에서 숨기는 것과 데이터 접근을 제한하는 것도 구분해야 합니다. 시각화에서 열을 제거했다고 모델 자체의 열 접근까지 제한되는 것은 아닙니다. 열·테이블 수준 제어가 필요하면 OLS나 모델 분리 등 해당 요구에 맞는 설계를 검토합니다.
Desktop 시험 다음에 서비스 시험을 한다
① 시험할 역할 옆의 더 보기 메뉴를 엽니다. ② Test as role을 선택해 역할에서 보이는 데이터를 확인합니다. 관리자·편집자 권한과 외부 사용자는 이 화면의 결과만으로 판정하지 말고 실제 사용자 계정으로 시험합니다.
① Desktop의 모델링 → 역할 관리에서 규칙을 정의합니다. ② 역할 보기에서 역할과 사용자 조건을 바꾸어 결과를 확인합니다. ③ 서비스에 모델과 보고서를 게시한 뒤 의미 체계 모델의 보안 메뉴에서 역할 구성원을 등록합니다. ④ 역할 옆 더 보기 메뉴에서 Test as role을 실행합니다.
여기까지는 모의 시험입니다. 실제 수신 계정으로도 보고서를 열어야 합니다. DirectQuery와 SSO 등 일부 구성에서는 Test as role 기능의 적용에 제약이 있으므로, 모의 화면만으로 배포 판정을 내리지 않습니다.
시험용 데이터에는 지역별로 구별되는 거래번호를 넣으면 좋습니다. 서울용 SEO-TEST-01, 부산용 BUS-TEST-01처럼 실제 개인정보가 없는 표식을 사용하면 다른 지역 데이터가 섞였는지 찾기 쉽습니다.
화면 한 장보다 효과적인 계정별 시험표
| 시험 계정·조건 | 확인할 대상 | 통과 기준 |
|---|---|---|
| 서울 Viewer | 표·카드·드릴스루 | 서울만 표시 |
| 부산 Viewer | 같은 보고서 | 부산만 표시 |
| 매핑 없는 Viewer | 모든 페이지 | 전체 자료가 열리지 않음 |
| 두 역할에 동시 배정 | 지역 합집합 여부 | 사전에 정한 허용 범위와 일치 |
| 외부 게스트 | 로그인·식별값·공유 경로 | 해당 협력사 범위만 |
| 내보내기 권한 보유자 | 내보낸 데이터 | 보고서 밖에서도 허용 범위 유지 |
RLS 역할을 여러 개 부여하면 단순히 더 제한적인 역할 하나만 적용될 것이라고 가정하지 않습니다. 여러 역할의 허용 범위가 결합되는 결과를 실제 계정으로 확인하고, 관리자 편의를 위해 넓은 역할을 함께 넣지 않았는지 점검합니다.
허용된 내보내기·Excel 분석·연결 보고서도 시험 대상에 포함합니다. 보고서 한 페이지에서 보이지 않는다고 모든 접근 경로가 막혔다고 결론 내리지 않습니다.
외부 게스트는 이메일 문자열만 보고 판단하지 않는다
게스트 계정은 조직 내부 사용자와 식별 방식이 다를 수 있습니다. 테스트용 진단 페이지에서 USERPRINCIPALNAME()의 실제 반환값을 확인하고 매핑 표와 대조합니다. 진단 페이지는 검증 후 일반 배포 대상에서 제외합니다.
외부 사용자가 포함된 그룹을 역할에 등록했다면 그룹 소속 평가가 예상대로 작동하는지도 확인합니다. Microsoft가 문서화한 B2B 제약과 현재 테넌트 정책을 확인하고, 필요한 경우 사용자를 역할에 직접 등록해 검증합니다. 초대만 완료된 상태, 초대 수락 전후, 계정 교체 후를 같은 사용자 상태로 취급하지 않습니다.
퇴사·부서 이동 때 재시험할 항목
권한 회수는 사용자 매핑 한 행을 지우는 것으로 끝나지 않을 수 있습니다. 작업 영역 직접 권한, 앱 대상 그룹, 개별 공유, 역할 구성원 목록을 함께 확인합니다. 부서 이동자는 이전 지역 데이터가 사라지고 새 지역만 보이는지 실제 계정으로 재시험합니다.
배포 기록에는 모델 버전, 시험 계정의 역할, 허용 지역, 기대 건수, 실제 건수, 시험 시각을 남깁니다. “RLS 정상”이라는 한 줄보다 어떤 계정으로 어디까지 확인했는지가 있어야 변경 후에도 같은 검사를 반복할 수 있습니다.