Power BI 대시보드 공유와 데이터 보안 가이드

Power BI를 사용하다 보면 누구와 어떻게 보고서를 공유할지, 그리고 민감한 데이터를 어떻게 보호할지 고민하게 됩니다. 특히 RLS(Row Level Security)와 OLS(Object Level Security)는 데이터 보안의 핵심 기능으로, 사용자별로 접근 가능한 데이터를 정밀하게 제어할 수 있습니다. 이번 글에서는 Power BI의 공유 방법부터 보안 설정까지 실무에서 바로 활용할 수 있는 내용을 정리했습니다.

---

대시보드 공유의 기본 개념

공유 방법의 종류

Power BI는 다양한 공유 방식을 제공하며, 상황에 따라 적절한 방법을 선택할 수 있습니다.

직접 공유(Direct Sharing)
보고서나 대시보드 상단의 '공유' 버튼을 통해 특정 사용자에게 직접 공유할 수 있습니다. 공유 시 세 가지 옵션 중 선택할 수 있습니다.

• 조직의 사용자: 링크가 있는 조직 내 모든 사용자가 볼 수 있습니다(외부 게스트 제외)
• 특정 사용자: 이메일 주소를 입력해 직접 공유하며, Microsoft Entra B2B 게스트도 포함 가능합니다
• 기존 액세스 권한이 있는 사용자: 이미 권한이 있는 사람에게 링크를 전달할 때 사용합니다

공유 시 '다시 공유' 권한과 '빌드' 권한을 부여할 수 있으며, 링크를 복사하거나 이메일, Outlook, Teams를 통해 직접 전송할 수 있습니다.

작업 영역(Workspace) 기반 공유
작업 영역은 팀 단위로 콘텐츠를 공동 작업하는 공간입니다. 작업 영역에는 네 가지 역할이 있으며, 각각 다른 권한을 가집니다.

• 관리자(Admin): 작업 영역의 모든 설정과 권한을 관리할 수 있습니다
• 멤버(Member): 콘텐츠를 만들고 편집하며, 다른 멤버를 추가할 수 있습니다
• 기여자(Contributor): 콘텐츠를 만들고 편집할 수 있지만, 작업 영역 설정이나 멤버 관리는 불가능합니다
• 뷰어(Viewer): 읽기 전용 권한으로, 보고서와 대시보드를 조회만 할 수 있습니다

뷰어 역할은 RLS를 적용하기에 적합한 역할입니다. 관리자, 멤버, 기여자 역할에는 RLS가 적용되지 않으므로 주의해야 합니다.

앱(App) 배포
앱은 완성된 대시보드와 보고서를 패키징하여 대규모 그룹이나 전체 조직에 배포하는 방식입니다. 앱을 통해 일관된 읽기 전용 환경을 제공할 수 있으며, 대상 그룹(Audience)별로 다른 콘텐츠와 권한을 설정할 수 있습니다. 앱은 작업 영역에서 개발한 콘텐츠를 정리하여 게시하며, 자동 설치 기능을 통해 최종 사용자의 Power BI에 직접 표시되도록 할 수 있습니다.

Microsoft Teams 통합
Teams 채널이나 채팅에서 직접 보고서를 공유하고 실시간으로 인사이트를 논의할 수 있습니다. 팀 협업 환경에서 바로 데이터를 확인할 수 있어 의사결정 속도가 빨라집니다.

라이선스와 공유 제약

Power BI의 공유는 라이선스에 따라 제한됩니다.

• 콘텐츠가 Premium 용량에 있지 않으면 공유하는 사람과 받는 사람 모두 Power BI Pro 또는 PPU 라이선스가 필요합니다
• Premium 또는 Fabric 용량의 콘텐츠는 무료 라이선스 사용자도 뷰어로 접근할 수 있습니다
• 외부 사용자에게 공유할 때는 Microsoft Entra B2B 게스트 초대가 권장됩니다

반응형

---

RLS(Row Level Security) 완벽 가이드

RLS란 무엇인가

RLS는 행 수준 보안으로, 특정 사용자가 볼 수 있는 데이터 행을 필터링하는 기능입니다. 예를 들어 영업 관리자는 자신의 지역 데이터만 보고, 임원은 전체 데이터를 볼 수 있도록 설정할 수 있습니다. RLS는 데이터 자체를 필터링하므로, 사용자는 권한이 없는 데이터의 존재조차 알 수 없습니다.

RLS 역할 생성 방법

RLS는 Power BI Desktop의 모델링 탭에서 설정합니다.

기본 역할 생성

1. 모델링 탭에서 역할 관리를 클릭합니다
2. 만들기를 클릭하여 새 역할을 추가합니다
3. 역할 이름을 입력합니다(예: "서울지역")
4. 필터를 적용할 테이블을 선택합니다
5. 필터 데이터 섹션에서 DAX 필터 식을 입력합니다

정적 RLS 예시
정적 RLS는 고정된 값으로 데이터를 필터링합니다.

[Region] = "Seoul"

이 식은 Region 컬럼이 "Seoul"인 데이터만 보여줍니다. 서울지역 영업팀에게 이 역할을 할당하면, 서울 데이터만 접근할 수 있습니다.

동적 RLS 예시
동적 RLS는 사용자 정보를 기반으로 자동으로 필터링합니다.

[UserEmail] = USERPRINCIPALNAME()

이 식은 현재 로그인한 사용자의 이메일과 데이터의 UserEmail 컬럼을 비교하여, 일치하는 데이터만 보여줍니다. 이 방식은 사용자별로 역할을 일일이 만들 필요가 없어 관리가 훨씬 간편합니다.

또 다른 동적 RLS 예시는 다음과 같습니다.

[ID] = USERNAME()

이 식은 Power BI Report Server 환경에서 사용자 이름을 기준으로 필터링합니다. 사용자의 ID와 데이터의 ID 컬럼이 일치하는 행만 표시됩니다.

RLS 역할 테스트

역할을 만든 후에는 반드시 테스트해야 합니다.

1. 모델링 탭에서 보기 형식을 클릭합니다
2. 테스트할 역할을 선택합니다
3. 동적 규칙의 경우 다른 사용자 옵션을 체크하고 테스트 값을 입력합니다
4. 확인을 클릭하면 해당 역할로 보고서가 필터링됩니다
5. 시각화가 예상대로 필터링되는지 확인합니다

테스트를 마치려면 다시 보기 형식을 클릭하여 역할 보기를 중지합니다.

Power BI 서비스에서 역할 할당

보고서를 Power BI 서비스에 게시한 후, 실제 사용자에게 역할을 할당해야 합니다.

1. Power BI 서비스에서 작업 영역으로 이동합니다
2. 데이터셋(의미 체계 모델)의 추가 옵션(...) 메뉴를 클릭합니다
3. 보안을 선택합니다
4. 생성한 역할을 선택하고 멤버 섹션에 사용자 이메일 또는 보안 그룹을 추가합니다
5. 저장을 클릭합니다

보안 그룹을 활용하면 개별 사용자를 일일이 추가하지 않아도 되므로 대규모 조직에서 관리가 용이합니다.

RLS 사용 예시

지역별 영업 데이터 필터링
전국 영업 데이터를 가진 보고서에서 각 지역 관리자는 자기 지역 데이터만 볼 수 있도록 설정할 수 있습니다. 지역 테이블에 다음과 같은 역할을 생성합니다.

[Region] = "부산"

부산지역 역할에 부산 영업팀을 할당하면, 부산 데이터만 표시됩니다. 서울, 대구, 광주 등 다른 지역도 동일한 방식으로 역할을 만들어 관리합니다.

부서별 인사 데이터 제한
인사 데이터에서 각 부서장은 자기 부서원의 정보만 볼 수 있도록 설정할 수 있습니다.

[Department] = "IT"

IT부서장에게 이 역할을 할당하면 IT부서 직원 데이터만 접근 가능합니다.

계층적 권한 구조
임원은 전체 데이터를 보고, 중간 관리자는 팀 데이터만, 팀원은 본인 데이터만 보는 계층적 구조도 구현할 수 있습니다. 이를 위해 사용자 권한 테이블을 만들고 관계를 설정한 후, 다음과 같은 DAX를 사용합니다.

PATHCONTAINS(Users[ManagerHierarchy], USERPRINCIPALNAME())

이 식은 조직의 보고 체계를 반영하여 상위 관리자는 하위 팀원의 데이터까지 볼 수 있도록 합니다.

RLS 주의사항

• RLS는 뷰어 역할에만 적용됩니다. 작업 영역의 관리자, 멤버, 기여자에게는 적용되지 않습니다
• RLS는 행만 필터링하며, 열이나 측정값은 제한하지 못합니다. 열을 숨기려면 OLS를 사용해야 합니다
• DirectQuery 모드에서 RLS를 사용하면 복잡한 DAX 함수가 제한될 수 있으며, 원천 데이터베이스에 쿼리 부하가 발생할 수 있습니다
• 양방향 관계에서 RLS를 적용하려면 관계 속성에서 보안 필터 양방향으로 적용 옵션을 활성화해야 합니다

---

OLS(Object Level Security) 활용하기

OLS란 무엇인가

OLS는 개체 수준 보안으로, 특정 테이블이나 컬럼 자체를 특정 역할에서 숨기는 기능입니다. RLS가 데이터 행을 필터링한다면, OLS는 데이터 구조(테이블, 컬럼) 자체를 숨깁니다. 예를 들어 급여 정보를 담은 "Salary" 컬럼을 일반 사용자에게는 완전히 숨기고, HR 관리자만 볼 수 있도록 설정할 수 있습니다.

OLS 설정 방법

OLS는 현재 Power BI Desktop에서 기본적으로 지원되지 않으므로, Tabular Editor와 같은 외부 도구를 사용해야 합니다.

Tabular Editor를 사용한 OLS 구성

1. Power BI Desktop에서 역할을 먼저 생성합니다
2. 외부 도구 탭에서 Tabular Editor를 실행합니다
3. Tabular Editor에서 역할을 확장하고 설정할 역할을 선택합니다
4. 테이블 권한을 확장합니다
5. 숨기려는 테이블이나 컬럼의 권한을 없음(None)으로 설정합니다
   • 없음: 해당 역할에서 테이블이나 컬럼이 완전히 숨겨집니다
   • 읽기(Read): 해당 역할에서 접근 가능합니다
6. 변경 사항을 저장합니다
7. Power BI Desktop으로 돌아와 서비스에 게시합니다
8. Power BI 서비스에서 보안 설정에 들어가 역할에 사용자를 할당합니다

TMDL 스크립트를 사용한 OLS 구성
최근에는 Power BI Desktop에서 TMDL(Tabular Model Definition Language) 스크립트를 사용하여 OLS를 구성할 수도 있습니다. 이 방법은 외부 도구 없이 코드 기반으로 보안을 설정할 수 있습니다.

OLS 사용 예시

민감한 재무 정보 보호
재무 보고서에서 "NetProfit"과 "CostOfGoods" 컬럼은 경영진만 볼 수 있도록 설정할 수 있습니다. 일반 사용자 역할에서는 이 컬럼들을 OLS로 숨기고, 경영진 역할에서는 읽기 권한을 부여합니다.

개인정보 보호
고객 테이블에서 "주민등록번호", "계좌번호" 같은 민감한 개인정보는 OLS를 통해 데이터 분석팀에게는 숨기고, 규정 준수팀에게만 노출시킬 수 있습니다.

부서별 테이블 접근 제어
마케팅 부서는 "MarketingCampaign" 테이블만 보고, 재무 부서는 "FinancialStatement" 테이블만 볼 수 있도록 OLS를 설정할 수 있습니다. 각 부서별 역할을 생성하고 해당하지 않는 테이블을 숨깁니다.

RLS와 OLS 조합 전략

RLS와 OLS를 함께 사용하면 더욱 강력한 보안 체계를 구축할 수 있습니다.

시나리오: 지역별 영업 대시보드

• RLS: 각 영업 관리자는 자기 지역의 영업 데이터만 볼 수 있도록 행 필터링
• OLS: 일반 영업 사원에게는 "원가" 컬럼을 숨기고, 관리자만 볼 수 있도록 설정

시나리오: HR 대시보드

• RLS: 각 부서장은 자기 부서원의 데이터만 볼 수 있도록 필터링
• OLS: 일반 부서장에게는 "급여" 테이블을 숨기고, HR 임원만 접근 가능하도록 설정

동적 OLS와 RLS 조합
Azure AD 그룹을 활용하여 동적으로 RLS와 OLS를 할당할 수 있습니다. Azure AD에서 사용자 그룹을 관리하고, Power BI 역할에 그룹을 할당하면 사용자 추가/제거 시 자동으로 권한이 반영됩니다.

---

보안 모범 사례

역할 설계 전략

최소 권한 원칙
사용자에게 업무에 필요한 최소한의 데이터만 접근하도록 설정합니다. 처음부터 제한적으로 권한을 부여하고, 필요에 따라 점진적으로 확대하는 것이 안전합니다.

역할 계층 구조
조직의 보고 체계를 반영한 역할 계층을 설계합니다. 임원 → 부서장 → 팀장 → 팀원 순으로 데이터 접근 범위가 좁아지도록 설정하면 관리가 용이합니다.

보안 그룹 활용
개별 사용자가 아닌 Azure AD 보안 그룹에 역할을 할당합니다. 조직 변경 시 Power BI가 아닌 AD에서만 그룹 멤버십을 관리하면 되므로 운영 부담이 줄어듭니다.

성능 최적화

RLS 필터 최적화
복잡한 DAX 필터는 쿼리 성능을 저하시킬 수 있습니다. 성능 분석기를 사용하여 RLS 필터의 영향을 측정하고, 가능하면 단순한 필터 식을 사용합니다. 특히 DirectQuery 모드에서는 원천 데이터베이스에 전송될 SQL로 변환되므로, 복잡한 DAX는 성능 문제를 일으킬 수 있습니다.

인덱스 활용
DirectQuery 모드에서 RLS를 사용할 때는 원천 데이터베이스의 필터 컬럼에 인덱스를 생성하여 쿼리 속도를 높입니다.

Import 모드 권장
대부분의 경우 Import 모드가 DirectQuery보다 RLS 성능이 우수합니다. 실시간 데이터가 필수가 아니라면 Import 모드를 고려합니다.

테스트 및 검증

역할별 철저한 테스트
모든 역할을 테스트하여 의도한 대로 데이터가 필터링되는지 확인합니다. Power BI Desktop의 "보기 형식" 기능을 활용하면 각 역할의 관점에서 보고서를 미리 볼 수 있습니다.

다양한 시나리오 검증

• 단일 역할 사용자
• 여러 역할을 동시에 가진 사용자
• 역할이 없는 사용자
• 외부 게스트 사용자

각 시나리오에서 데이터 접근이 올바르게 제한되는지 확인해야 합니다.

감사 로그 모니터링
Power BI의 감사 로그를 활용하여 누가 언제 어떤 데이터에 접근했는지 추적합니다. 이상 접근 패턴을 조기에 발견할 수 있습니다.

추가 보안 레이어

민감도 레이블
Microsoft Purview의 민감도 레이블을 Power BI와 통합하여 데이터 분류와 보호를 자동화할 수 있습니다. "기밀", "사내용", "공개" 등의 레이블을 지정하면 데이터 다운로드, 인쇄, 공유 시 자동으로 보호 정책이 적용됩니다.

BYOK(Bring Your Own Key)
Premium 용량에서는 자체 암호화 키를 사용하여 미사용 데이터를 암호화할 수 있습니다. 서비스 운영자 오류가 발생해도 고객 데이터가 노출되지 않습니다.

필터 창 숨김
보고서 설정에서 필터 창을 숨기면 사용자가 페이지 필터나 시각적 개체 필터를 통해 의도하지 않은 데이터를 노출하는 것을 방지할 수 있습니다.

데이터셋 다운로드 방지
작업 영역 설정에서 데이터셋 다운로드를 차단하면 사용자가 .pbix 파일을 다운로드하여 로컬에서 보안 우회를 시도하는 것을 막을 수 있습니다.

---

문제 해결 팁

RLS가 적용되지 않는 경우

• 작업 영역에서 관리자, 멤버, 기여자 역할을 가진 사용자에게는 RLS가 적용되지 않습니다. 뷰어 역할로 변경하거나 앱을 통해 배포합니다
• DirectQuery 환경에서 통합 인증을 사용하면 RLS가 무시될 수 있습니다
• 역할 할당을 확인합니다. Power BI 서비스의 보안 설정에서 사용자가 올바른 역할에 포함되어 있는지 점검합니다

공유 시 권한 오류

• 대시보드나 보고서를 공유할 때 기본 데이터셋에 대한 다시 공유 권한이 필요합니다. 데이터셋 소유자에게 권한을 요청합니다
• 동적 메일 그룹과는 대시보드를 공유할 수 없습니다. 보안 그룹이나 Microsoft 365 그룹을 사용합니다

OLS 설정 후 보고서 오류

• OLS로 숨긴 테이블이나 컬럼이 보고서 시각화에서 사용되고 있으면 해당 역할의 사용자에게 오류가 표시될 수 있습니다. 필드 매개변수를 활용하여 역할별로 다른 시각화를 제공하는 방법을 고려합니다
• OLS는 작업 영역 뷰어에게만 적용됩니다. 관리자, 멤버, 기여자는 OLS가 무시됩니다

---

Power BI의 공유와 보안 기능을 제대로 활용하면 조직 내 데이터 거버넌스를 강화하면서도 효율적인 협업이 가능합니다. RLS와 OLS는 단순해 보이지만, 조직의 권한 구조와 데이터 민감도에 맞게 설계하려면 신중한 계획이 필요합니다. 처음에는 간단한 역할부터 시작하여 점진적으로 확장하고, 정기적으로 권한을 검토하여 불필요한 접근을 제거하는 것이 중요합니다.