행 수준 보안 설정

완료됨

데이터 모델 개발자는 하나 이상의 역할 을 만들어 RLS를 설정합니다. 역할은 모델에서 고유한 이름을 가지며 일반적으로 하나 이상의 규칙 을 포함합니다. 규칙은 DAX(데이터 분석 식) 필터 식을 사용하여 모델 테이블에 필터를 적용합니다.

참고

기본적으로 데이터 모델에는 역할이 없습니다. 역할이 없는 데이터 모델은 사용자(데이터 모델을 쿼리할 수 있는 권한이 있는 사용자)가 모든 모델 데이터에 액세스할 수 있음을 의미합니다.

규칙이 없는 역할을 정의할 수 있습니다. 이 경우 역할은 모든 모델 테이블의 모든 행에 대한 액세스를 제공합니다. 이 역할 설정은 모든 데이터를 볼 수 있는 관리 사용자에게 적합합니다.

Microsoft Power BI Desktop 개발 모델의 경우 Power BI Desktop에서 역할을 만들고, 유효성을 검사하고, 관리할 수 있습니다. Microsoft Azure Analysis Services 또는 SQL Server Analysis Services 모델의 경우 SSDT(SQL Server Data Tools)를 사용하여 역할을 만들고, 유효성을 검사하고, 관리할 수 있습니다.

또한 SQL Server Management Studio를 사용하거나 테이블 형식 편집기와 같은 외부 도구를 사용하여 역할을 만들고 관리할 수 있습니다.

별모양 스키마 디자인 원칙 적용

효과적인 RLS 솔루션을 달성하기 위한 첫 번째 단계는 잘 설계된 모델을 개발하는 것입니다. 차원 및 팩트 테이블로 구성된 모델을 생성하려면 별모양 스키마 디자인 원칙을 적용하는 것이 좋습니다. 일반적으로 Power BI 차원 테이블을 필터링하는 규칙을 적용하고 모델 관계를 통해 이러한 필터를 팩트 테이블에 효율적으로 전파합니다.

다음 이미지는 Tailspin Toys 판매 분석 데이터 모델의 모델 다이어그램입니다. Sales 라는 단일 팩트 테이블이 포함된 별모양 스키마 디자인을 보여줍니다. 나머지 4개 테이블은 날짜, 주, 지역 및 제품별 판매 측정값 분석을 지원하는 차원 테이블입니다. 모델 관계는 모든 테이블을 연결합니다. 이러한 관계는 필터를 직접 또는 간접적으로 Sales 테이블에 전파합니다.

테이블 및 관계가 포함된 Power BI Desktop 모델 다이어그램의 스크린샷

이 모델 디자인은 이 모듈에 제시된 예제를 지원합니다.

규칙 정의

규칙 식은 행 컨텍스트 내에서 평가됩니다. 행 컨텍스트는 이 행의 열 값을 사용하여 각 행에 대해 식이 평가됨을 의미합니다. 식이 TRUE를 반환하면 사용자는 행을 "볼" 수 있습니다.

행 컨텍스트에 대해 자세히 알아보려면 Power BI Desktop 모델에 계산된 테이블 및 열 추가 모듈을 참조하세요. 이 모듈에서는 모델 계산을 추가하는 프로세스에 대해 설명하지만 행 컨텍스트를 소개하고 설명하는 단원이 포함됩니다.

정적 또는 동적 규칙을 정의할 수 있습니다.

정적 규칙

정적 규칙은 상수를 참조하는 DAX 식을 사용합니다.

New England 판매에 대한 데이터 액세스를 제한하는 Region 테이블에 적용되는 다음 규칙을 고려합니다.

'Region'[Region] = "New England"

다음 단계에서는 Power BI가 규칙을 적용하는 프로세스에 대해 설명합니다.

  1. Region 테이블을 필터링합니다. 그러면 하나의 행(New England)이 표시됩니다.

  2. 모델 관계를 사용하여 Region 테이블 필터를 State 테이블에 전파합니다. 그러면 6개의 행이 표시됩니다(New England 지역에는 6개 주가 포함됨).

  3. 모델 관계를 사용하여 State 테이블 필터를 Sales 테이블에 전파합니다. 그러면 수천 개의 행(New England 지역에 속한 주에 대한 판매 팩트)이 표시됩니다.

만들 수 있는 가장 간단한 정적 규칙은 모든 테이블 행에 대한 액세스를 제한합니다. Sales Details 테이블(모델 다이어그램에 표시되지 않음)에 적용된 다음 규칙을 고려합니다.

FALSE()

이 규칙은 사용자가 테이블 데이터에 액세스할 수 없도록 합니다. 이 규칙은 영업 사원이 집계된 판매 결과(Sales 테이블)를 볼 수 있지만 주문 수준 세부 정보는 볼 수 없는 경우에 유용할 수 있습니다.

정적 규칙을 정의하는 것은 간단하고 효과적입니다. 6개 지역만 있는 Tailspin Toys의 경우와 같이 규칙을 몇 개만 만들어야 할 때 정적 규칙을 사용하는 것이 좋습니다. 그러나 몇 가지 단점을 알고 있어야 합니다. 정적 규칙을 설정하려면 만들고 설정하는 데 상당한 노력이 수반될 수 있습니다. 또한 새 지역을 도입할 때 데이터 세트를 업데이트하고 다시 게시해야 합니다.

설정할 규칙이 여러 개이고 나중에 새 규칙이 추가될 것으로 예상되는 경우 동적 규칙을 대신 사용하는 것이 좋습니다.

동적 규칙

동적 규칙은 상수가 아닌 환경 값을 반환하는 특정 DAX 함수를 사용합니다. 환경 값은 다음 특정 DAX 함수에서 반환됩니다.

  • USERNAME 또는 USERPRINCIPALNAME - 조직용 시나리오를 사용하는 경우 이러한 함수는 인증된 사용자를 설명하는 텍스트 값을 반환합니다. 고객용 시나리오를 사용하는 경우 앱이 전달하는 텍스트 값을 반환합니다.

  • CUSTOMDATA - 조직용 시나리오를 사용하는 경우 연결 문자열에 전달된 CustomData 속성을 반환합니다. 고객용 시나리오를 사용하는 경우 앱이 전달하는 텍스트 값을 반환합니다.

참고

USERNAME 함수는 Power BI Desktop에서 사용될 때 DOMAIN\username 형식으로 사용자를 반환합니다. 그러나 Power BI 서비스에서 사용되면 사용자의 UPN(사용자 계정 이름) 형식(예: username@tailspintoys.com)을 반환합니다. 또는 항상 UPN 형식으로 사용자를 반환하는 USERPRINCIPALNAME 함수를 사용할 수 있습니다.

이제 (숨겨진) AppUser 테이블이 포함된 수정된 모델 디자인을 고려합니다. AppUser 테이블의 각 행은 사용자 이름 및 지역을 설명합니다. Region 테이블에 대한 모델 관계는 AppUser 테이블의 필터를 전파합니다.

이제 AppUser 테이블이 포함된 수정된 모델 다이어그램의 스크린샷. 이 테이블에는 Region과 UserName이라는 두 개의 열이 있습니다.

AppUser 테이블에 적용된 다음 규칙은 인증된 사용자의 지역에 대한 데이터 액세스를 제한합니다.

'AppUser'[UserName] = USERPRINCIPALNAME()

동적 규칙 정의는 모델 테이블에 사용자 이름 값이 저장되는 경우 간단하고 효과적입니다. 동적 규칙을 사용하여 데이터 기반 RLS 디자인을 적용할 수 있습니다. 예를 들어, 영업 사원이 AppUser 테이블에 추가되거나 제거될 때(또는 다른 지역에 할당될 때) 이 디자인 방식은 효과가 있습니다.

중요

고객용 시나리오를 사용하는 경우 USERNAME 및 USERPRINCIPALNAME 함수는 실제 사용자 이름을 반환할 필요가 없습니다. 대신 앱에서 모델을 필터링하는 텍스트 값을 전달할 수 있습니다.

역할 유효성 검사

역할을 만들 때 역할을 테스트하여 올바른 필터를 적용하는지 확인해야 합니다. Power BI Desktop에서 만든 데이터 모델의 경우 View as 함수를 사용하여 다른 역할이 적용되고 다른 사용자 이름 값이 전달될 때 보고서를 볼 수 있습니다.

Power BI Desktop 모델링 리본의 스크린샷. View as 명령이 강조 표시되어 있습니다.

역할 매핑 설정

역할 매핑은 포함 시나리오에 따라 다르게 수행됩니다.

조직용 시나리오를 사용하는 경우 사용자가 Power BI 콘텐츠에 액세스하기 전에 역할 매핑을 설정해야 합니다. 역할 매핑에는 Microsoft Azure AD(Azure Active Directory) 보안 개체를 역할에 할당하는 작업이 포함됩니다. 보안 개체는 사용자 계정 또는 보안 그룹일 수 있습니다.

가능하면 역할을 보안 그룹에 매핑하는 것이 좋습니다. 그러면 매핑 수가 줄어들고 그룹 멤버 자격 관리를 네트워크 관리자에게 위임할 수 있습니다.

Power BI Desktop 개발 모델의 경우 역할 매핑은 일반적으로 Power BI 서비스 수행됩니다. Azure Analysis Services 또는 SQL Server Analysis Services 모델의 경우 역할 매핑은 일반적으로 SSMS(SQL Server Management Studio)에서 수행됩니다.

고객용 시나리오를 사용하는 경우 역할 매핑은 런타임에 앱에서 수행됩니다. 앱 논리는 하나 이상의 유효 ID 를 설정하여 RLS를 적용합니다. 유효 ID 설정은 이 모듈의 뒷부분에서 설명합니다.

RLS 설정에 대한 자세한 내용은 다음 문서를 참조하세요.