Power BI 모델 데이터에 대한 액세스 제한
데이터 모델 개발자는 하나 이상의 역할을 만들어 RLS를 설정합니다. 역할은 모델에서 고유한 이름을 가지며 일반적으로 하나 이상의 규칙을 포함합니다. 규칙은 DAX(데이터 분석 식) 필터 식을 사용하여 모델 테이블에 필터를 적용합니다.
참고
기본적으로 데이터 모델에는 역할이 없습니다. 역할이 없는 데이터 모델은 사용자(데이터 모델을 쿼리할 수 있는 권한이 있는 사용자)가 모든 모델 데이터에 액세스할 수 있음을 의미합니다.
팁
규칙이 없는 역할을 정의할 수 있습니다. 이 경우 역할은 모든 모델 테이블의 모든 행에 대한 액세스를 제공합니다. 이 역할 설정은 모든 데이터를 볼 수 있는 관리 사용자에게 적합합니다.
Power BI Desktop에서 역할을 만들고, 유효성을 검사하고, 관리할 수 있습니다. Azure Analysis Services 또는 SQL Server Analysis Services 모델의 경우 SSDT(SQL Server Data Tools)를 사용하여 역할을 만들고, 유효성을 검사하고, 관리할 수 있습니다.
SSMS(SQL Server Management Studio)를 사용하거나 테이블 형식 편집기와 같은 타사 도구를 사용하여 역할을 만들고 관리할 수도 있습니다.
RLS가 데이터에 대한 액세스를 제한하는 방법을 더 잘 이해하려면 다음 애니메이션 이미지를 시청하세요.
별모양 스키마 디자인 원칙 적용
차원 및 팩트 테이블로 구성된 모델을 생성하려면 별모양 스키마 디자인 원칙을 적용하는 것이 좋습니다. 일반적으로는 차원 테이블을 필터링하는 규칙을 적용하도록 Power BI 설정하여, 모델 관계에서 이러한 필터를 팩트 테이블에 효율적으로 전파할 수 있게 합니다.
다음 이미지는 Adventure Works 판매 분석 데이터 모델의 모델 다이어그램입니다. Sales라는 단일 팩트 테이블로 구성된 별모양 스키마 디자인을 보여줍니다. 다른 테이블은 날짜, 판매 지역, 고객, 재판매인, 주문, 제품 및 영업 사원별 판매 측정값 분석을 지원하는 차원 테이블입니다. 모든 테이블을 연결하는 모델 관계에 주목하세요. 이러한 관계는 필터를 직접 또는 간접적으로 Sales 테이블에 전파합니다.
이 모델 디자인은 이 단원에 제시된 예제를 지원합니다.
규칙 정의
규칙 식은 행 컨텍스트 내에서 평가됩니다. 행 컨텍스트는 이 행의 열 값을 사용하여 각 행에 대해 식이 평가됨을 의미합니다. 식이 TRUE를 반환하면 사용자는 행을 "볼" 수 있습니다.
팁
행 컨텍스트에 대해 자세히 알아보려면 Power BI Desktop 모델에 계산된 테이블 및 열 추가 모듈을 살펴보세요. 이 모듈에서는 모델 계산을 추가하는 방법에 대해 설명하지만 행 컨텍스트를 소개하고 설명하는 단위를 포함합니다.
정적 또는 동적 규칙을 정의할 수 있습니다.
정적 규칙
정적 규칙은 상수를 참조하는 DAX 식을 사용합니다.
Midwest 판매에 대한 데이터 액세스를 제한하는 Region 테이블에 적용되는 다음 규칙을 고려합니다.
'Region'[Region] = "Midwest"
다음 단계에서는 Power BI가 규칙을 적용하는 방법을 설명합니다. 해당 항목은 다음을 수행합니다.
Region 테이블을 필터링하여 하나의 행이 표시됩니다(Midwest의 경우).
모델 관계를 사용하여 Region 테이블 필터를 State 테이블에 전파하면 14개의 행이 표시됩니다(Midwest 지역은 14개 주로 구성됨).
모델 관계를 사용하여 State 테이블 필터를 Sales 테이블에 전파하면 수천 개의 행(Midwest 지역에 속한 주에 대한 판매 팩트)이 표시됩니다.
만들 수 있는 가장 간단한 정적 규칙은 모든 테이블 행에 대한 액세스를 제한합니다. Sales Details 테이블(모델 다이어그램에 표시되지 않음)에 적용된 다음 규칙을 고려합니다.
FALSE()
이 규칙은 사용자가 테이블 데이터에 액세스할 수 없도록 합니다. 영업 사원이 집계된 판매 결과(Sales 테이블)를 볼 수 있지만 주문 수준 세부 정보는 볼 수 없는 경우에 유용할 수 있습니다.
정적 규칙을 정의하는 것은 간단하고 효과적입니다. 미국 내 6개 지역만 있는 Adventure Works에서처럼 몇 개만 만들어야 할 때 사용하는 것이 좋습니다. 그러나 단점도 알고 있어야 합니다. 정적 규칙을 설정하려면 만들고 설정하는 데 상당한 노력이 수반될 수 있습니다. 또한 새 지역이 온보딩될 때 데이터 세트를 업데이트하고 다시 게시해야 합니다.
설정할 규칙이 많고 나중에 새 규칙이 추가될 것으로 예상되는 경우에는 대신 동적 규칙을 생성하는 것이 좋습니다.
동적 규칙
동적 규칙은 상수가 아닌 환경 값을 반환하는 특정 DAX 함수를 사용합니다. 환경 값은 세 가지 특정 DAX 함수에서 반환됩니다.
USERNAME 또는 USERPRINCIPALNAME – Power BI 인증된 사용자를 텍스트 값으로 반환합니다.
CUSTOMDATA - 연결 문자열에 CustomData 속성을 반환합니다. 연결 문자열을 사용하여 데이터 세트에 연결하는 Power BI 보고 도구는 이 속성(예: Microsoft Excel)을 설정할 수 있습니다.
참고
USERNAME 함수는 Power BI Desktop에서 사용될 때 DOMAIN\username 형식으로 사용자를 반환합니다. 그러나 Power BI 서비스에서 사용하면 사용자의 UPN(사용자 계정 이름) 형식(예: username@adventureworks.com)이 반환됩니다. 또는 항상 UPN(사용자 계정 이름) 형식으로 사용자를 반환하는 USERPRINCIPALNAME 함수를 사용할 수 있습니다.
이제 (숨겨진) AppUser 테이블이 포함된 수정된 모델 디자인을 고려합니다. AppUser 테이블의 각 행은 사용자 이름 및 지역을 설명합니다. Region 테이블에 대한 모델 관계는 AppUser 테이블의 필터를 전파합니다.
AppUser 테이블에 적용된 다음 규칙은 인증된 사용자의 지역에 대한 데이터 액세스를 제한합니다.
'AppUser'[UserName] = USERPRINCIPALNAME()
동적 규칙 정의는 모델 테이블에 사용자 이름 값이 저장되는 경우 간단하고 효과적입니다. 이를 통해 데이터 기반 RLS 디자인을 적용할 수 있습니다. 예를 들어 영업 사원이 AppUser 테이블에 추가되거나 테이블에서 제거될 때(또는 다른 지역에 할당될 때)는 이 디자인 방식이 효과가 있습니다.
역할 유효성 검사
역할을 만들 때는 반드시 역할을 테스트하여 올바른 필터를 적용하는지 확인해야 합니다. Power BI Desktop에서 만든 데이터 모델의 경우 다른 역할이 적용되고 다른 사용자 이름 값이 전달될 때 보고서를 볼 수 있는 View as 함수가 있습니다.
역할 매핑 설정
사용자가 Power BI 콘텐츠에 액세스하기 전에 역할 매핑을 설정해야 합니다. 역할 매핑에는 Microsoft Entra 보안 개체를 역할에 할당하는 작업이 포함됩니다. 보안 개체는 사용자 계정 또는 보안 그룹일 수 있습니다.
팁
가능하면 역할을 보안 그룹에 매핑하는 것이 좋습니다. 그러면 매핑 수가 줄어들고 그룹 멤버 자격 관리를 네트워크 관리자에게 위임할 수 있습니다.
Power BI Desktop 개발 모델의 경우 역할 매핑은 일반적으로 Power BI 서비스 수행됩니다. Azure Analysis Services 또는 SQL Server Analysis Services 모델의 경우 역할 매핑은 일반적으로 SSMS에서 수행됩니다.
RLS 설정에 대한 자세한 내용은 다음을 참조하세요.
DirectQuery 원본의 SSO(Single Sign-On) 사용
데이터 모델에 DirectQuery 테이블이 있고 관련 데이터 원본이 SSO를 지원하는 경우, 데이터 원본은 데이터 권한을 적용할 수 있습니다. 이 방식을 이용해 데이터베이스는 RLS를 적용하고 데이터 세트 및 보고서는 Power BI 데이터 원본 보안을 준수합니다.
Adventure Works에 Power BI와 동일한 테넌트에 상주하는 판매 작업에 대한 Azure SQL Database가 있다고 가정해 보세요. 이 데이터베이스는 다양한 데이터베이스 테이블에 있는 행에 대한 액세스를 제어하기 위해 RLS를 적용합니다. 역할 없이 이 데이터베이스에 연결하는 DirectQuery 모델을 만들어 Power BI 서비스에 게시할 수 있습니다. Power BI 서비스에서 데이터 원본 자격 증명을 설정할 때는 SSO를 사용하도록 설정하게 됩니다. 보고서 소비자가 Power BI 보고서를 열면 Power BI에서는 ID를 데이터 원본에 전달합니다. 데이터 원본은 보고서 소비자의 ID를 기준으로 RLS를 적용합니다.
Azure SQL Database RLS에 관한 자세한 내용은 행 수준 보안을 참조하세요.
참고
SSO 인증으로 데이터 원본의 DirectQuery 테이블을 참조하는 계산된 테이블 및 계산된 열은 Power BI 서비스에서 지원되지 않습니다.
SSO를 지원하는 데이터 원본에 관한 자세한 내용은 DirectQuery 원본의 SSO(Single Sign-On)를 참조하세요.