Power BI를 사용하는 RLS(행 수준 보안)

RLS(행 수준 보안)는 특정 사용자의 데이터 액세스를 제한합니다. 필터는 행 수준에서 데이터를 제한하고 역할 내에서 필터를 정의합니다. Power BI 서비스에서 작업 영역에 대한 액세스 권한이 있는 사용자는 해당 작업 영역의 의미 체계 모델에 액세스할 수 있습니다. RLS는 보기 권한자 권한이 있는 사용자의 데이터 액세스만 제한합니다. 관리자, 구성원 또는 참가자에게는 적용되지 않습니다.

RLS를 구현하려면 다음 상위 수준 워크플로를 따릅니다.

1. DAX 필터 식을 사용하여 Power BI Desktop에서 역할 및 규칙 정의합니다.
2. 게시 의미 체계 모델과 보고서를 Power BI 서비스에 게시합니다.
3. 멤버를 Power BI 서비스 역할에 추가합니다.
4. 테스트 역할을 사용하여 데이터 필터링이 예상대로 작동하는지 확인하여 유효성을 검사합니다.

Power BI Desktop 또는 Power BI 서비스 가져온 의미 체계 모델에 대해 RLS를 구성할 수 있습니다. SQL Server와 같이 DirectQuery를 사용하는 의미 체계 모델에 RLS를 구성할 수도 있습니다. Analysis Services 또는 Azure Analysis Services 라이브 연결의 경우 Power BI가 아닌 모델에서 행 수준 보안을 구성합니다. 라이브 연결 의미 체계 모델에는 보안 옵션이 표시되지 않습니다.

Power BI Desktop의 역할 및 규칙 정의

Power BI Desktop 내에서 역할 및 규칙을 정의할 수 있습니다. 이 편집기를 사용하면 기본 드롭다운 인터페이스와 DAX 인터페이스 사용 간에 전환할 수 있습니다. Power BI에 게시할 때 역할 정의도 게시합니다.

보안 역할을 정의하려면 다음을 수행합니다.

1. Power BI Desktop 보고서에 데이터를 가져오거나 DirectQuery 연결을 구성합니다.

   참고

   Analysis Services 라이브 연결을 위해 Power BI Desktop 내에서 역할을 정의할 수 없습니다. Analysis Services 모델 내에서 이를 수행해야 합니다.

2. 모델링 탭에서 역할 관리를 선택합니다.

3. 역할 관리 창에서 새로 만들기를 선택하여 새로운 역할을 만드세요.

4. 역할에서 역할의 이름을 입력하고 Enter 키를 선택합니다.

   참고

   쉼표로 역할을 정의할 수 없습니다(예: London,ParisRole).

5. 테이블 선택 아래에서 행 수준 보안 필터를 적용할 테이블을 선택하세요.

6. 필터 데이터에서 기본 편집기를 사용하여 역할을 정의하세요. 만든 식은 true 또는 false 값을 반환합니다. DAX 필터는 각 행에 대해 TRUE/FALSE를 평가합니다. TRUE를 반환하는 행만 볼 수 있습니다. 다른 모든 항목은 완전히 제거됩니다.

   참고

   Power BI에서 지원되는 일부 행 수준 보안 필터는 기본 편집기를 사용하여 정의할 수 없습니다. 제한 사항에는 username() 또는 userprincipalname()과 같은 동적 규칙을 포함하여 DAX를 사용하여 정의할 수 있는 식만 포함됩니다. 이러한 필터를 사용하여 역할을 정의하려면 DAX 편집기를 사용하도록 전환합니다.

7. 필요에 따라 DAX 편집기로 전환을 선택하여 DAX 편집기를 사용하여 역할을 정의하도록 전환합니다. DAX 식은 true 또는 false 값을 반환합니다. 예: [Entity ID] = “Value” DAX 편집기는 수식에 대한 자동 완성 기능(인텔리센스)이 구비되어 있습니다. 식 상자 위의 확인 표시를 선택하여 식의 유효성을 검사하고 식 상자 위의 X 단추를 선택하여 변경 내용을 되돌릴 수 있습니다.

   참고

   이 식 내에서 username() 을 사용할 수 있습니다. username()은 Power BI Desktop 내에서 DOMAIN\username 형식을 가집니다. Power BI 서비스 및 Power BI Report Server 내에서 사용자의 UPN(사용자 계정 이름) 형식입니다. 또한, 이 식 상자에서는 보통 세미콜론 구분자를 사용하는 로캘(예: 프랑스, 독일)에서도 쉼표를 사용하여 DAX 함수 인수를 구분합니다.

8. 기본 편집기로 전환을 선택하여 기본 편집기로 다시 전환할 수 있습니다. 편집기 인터페이스 중 하나에서 수행된 모든 변경 사항은 가능한 경우 인터페이스를 전환할 때도 지속됩니다. 기본 편집기에서 정의할 수 없는 DAX 편집기를 사용하여 역할을 정의할 때 기본 편집기로 전환하려고 하면 편집기를 전환하면 일부 정보가 손실될 수 있다는 경고 메시지가 표시됩니다. 이 정보를 유지하려면 취소를 선택하고 DAX 편집기에서만 이 역할을 계속 편집합니다.

   참고

   이 식 상자에서는 보통 세미콜론 구분자를 사용하는 로캘(예: 프랑스, 독일)에서도 쉼표를 사용하여 DAX 함수 인수를 구분합니다.

9. 저장을 선택합니다.

Power BI Desktop 내에서는 사용자를 역할에 할당할 수 없습니다. Power BI 서비스에서 할당합니다. username() 또는 userprincipalname() DAX 함수를 사용하고 적절한 관계를 구성하여 Power BI Desktop 내에서 동적 보안을 사용하도록 설정할 수 있습니다.

일반적인 DAX 필터 패턴

다음 예제에서는 RLS 역할을 정의할 때 사용할 수 있는 일반적인 DAX 필터 식을 보여 줍니다.

• 정적 RLS - 데이터를 고정 값으로 제한합니다.

  [Region] = "West"
  

• UPN ΣÇö를 사용하는 동적 RLS는 로그인한 사용자의 이메일 주소에 따라 데이터를 제한합니다.

  [UserEmail] = USERPRINCIPALNAME()
  

• USERNAME ΣÇö를 사용하는 동적 RLS는 사용자의 도메인 및 사용자 이름에 따라 데이터를 제한합니다.

  [UserDomain] = USERNAME()
  

• CUSTOMDATA를 사용한 동적 RLS — 임베딩 애플리케이션에서 전달된 사용자 지정 문자열을 기반으로 데이터를 제한합니다.

  [AppRole] = CUSTOMDATA()
  

  참고

  CUSTOMDATA() 애플리케이션이 Power BI REST API를 통해 사용자 지정 유효 ID 문자열을 전달하는 포함된 시나리오에서 주로 사용됩니다.

동적 RLS는 단일 역할 정의가 데이터 모델의 사용자 매핑 테이블에 따라 각 사용자에 대해 데이터를 다르게 필터링할 수 있기 때문에 가장 일반적인 방법입니다.

예: 지역별 판매 데이터 필터링

열이 Region, Product, Amount인 Sales 테이블이 있다고 가정해 보겠습니다. "서부" 역할에 할당된 사용자를 제한하여 지역이 "서부"인 행만 표시되도록 하려고 합니다.

"West" 역할에 대한 DAX 필터 필드에 다음 식을 입력합니다.

[Region] = "West"

필터링 전(모든 데이터):

필터링 후("서부" 역할 사용자에 대한 보기):

DAX 식은 테이블의 각 행을 평가하는 행 필터 역할을 합니다. Region 열의 값이 "West"인 행만 해당 역할이 할당된 사용자에게 표시됩니다.

기본적으로 행 수준 보안 필터링은 관계가 단방향으로 설정되었는지 양방향으로 설정되었는지 여부에 관계없이 단방향 필터를 사용합니다. 관계를 선택하고 보안 필터 양방향으로 적용 확인란을 선택하여 행 수준 보안으로 양방향 교차 필터링을 수동으로 활성화할 수 있습니다. 테이블이 여러 양방향 관계에 참여하는 경우 이러한 관계 중 하나에 대해서만 이 옵션을 선택할 수 있습니다. 행 수준 보안이 사용자 이름 또는 로그인 ID에 기반하는 서버 수준의 동적 행 수준 보안도 구현한 경우에는 이 옵션을 선택하세요.

자세한 내용은 Power BI에서 DirectQuery를 사용하여 양방향 교차 필터링 및 테이블 형식 BI 의미 체계 모델 보안 기술 문서를 참조하세요.

양방향 교차 필터링

기본적으로 행 수준 보안 필터링은 관계가 단방향으로 설정되었는지 양방향으로 설정되었는지 여부에 관계없이 단방향 필터를 사용합니다.

관계를 선택하고 보안 필터 양방향으로 적용 확인란을 선택하여 행 수준 보안으로 양방향 교차 필터링을 수동으로 활성화할 수 있습니다. 행 수준 보안이 사용자 이름 또는 로그인 ID에 기반하는 서버 수준의 동적 행 수준 보안도 구현한 경우에는 이 옵션을 선택하세요. 테이블이 여러 양방향 관계에 참여하는 경우 해당 관계 중 하나에 대해서만 이 옵션을 선택할 수 있습니다.

자세한 내용은 Power BI에서 DirectQuery를 사용하여 양방향 교차 필터링 및 테이블 형식 BI 의미 체계 모델 보안 기술 문서를 참조하세요.

모델에 대한 보안 관리

의미 체계 모델의 보안을 관리하려면 Fabric에서 의미 체계 모델을 저장한 작업 영역을 열고 다음 단계를 수행합니다.

1. Fabric에서 의미 체계 모델에 대한 추가 옵션 메뉴를 선택합니다. 의미 체계 모델 이름에 커서를 대면 이 메뉴가 나타납니다.

   

2. 보안을 선택합니다.

   

보안은 사용자가 만든 역할에 멤버를 추가할 수 있는 역할 수준 보안 페이지로 이동합니다. 기여자 이상의 작업 영역 역할이 있는 사용자는 보안 옵션을 보고 사용자를 역할에 할당할 수 있습니다. 시나리오에 따라 의미 체계 모델 소유권 또는 빌드 권한도 필요할 수 있습니다.

역할 멤버 자격 관리

맴버 추가

Power BI 서비스에서 사용자의 이메일 주소나 이름 또는 보안 그룹을 입력하여 역할에 멤버를 추가할 수 있습니다. Power BI에서 만든 그룹은 추가할 수 없습니다. 조직 외부 멤버를 추가할 수 있습니다. RLS가 외부 B2B 게스트 사용자와 작동하는 방식에 대한 지침은 외부(B2B 게스트) 사용자에 대한 고려 사항을 참조하세요.

다음 그룹을 사용하여 행 수준 보안을 설정할 수 있습니다.

• 배포 그룹
• 메일 사용이 가능한 그룹
• Microsoft Entra 보안 그룹 보안 그룹에 외부 B2B 게스트 사용자가 포함된 경우 알려진 제한 사항은 외부(B2B 게스트) 사용자에 대한 승인을 참조하세요.

역할 이름 옆 또는 멤버 옆에 있는 괄호 안의 숫자로 역할의 일부인 멤버 수를 확인할 수 있습니다.

멤버 제거

해당 이름 옆에 있는 X를 선택하여 멤버를 제거할 수 있습니다.

Power BI 서비스 내에서 역할 유효성 검사

Power BI 서비스에서 정의한 역할이 올바르게 작동하는지 확인하려면 그 역할을 테스트하십시오.

1. 역할 옆에 있는 추가 옵션(...)을 선택합니다.
2. 테스트 역할로를 선택합니다.

보고서가 로드되면 다음을 확인합니다.

• 보고서에는 역할에 정의된 필터 식과 일치하는 데이터 행만 표시됩니다.
• 시각적 개체, 테이블 및 차트는 전체 데이터 세트가 아닌 필터링된 데이터를 반영합니다.
• 동적 RLS를 사용하는 경우 데이터는 지금 보기 헤더에 표시된 ID에 해당합니다.

페이지 머리글에는 적용되는 역할이 표시됩니다. 현재 역할 보기를 선택하여 다른 역할, 역할의 조합 또는 특정 사용자를 테스트할 수 있습니다. 여기서는 테스트 중인 개인 또는 역할과 관련된 중요한 권한 세부 정보를 볼 수 있습니다. 사용 권한이 RLS와 상호 작용하는 방법에 대한 자세한 내용은 RLS 사용자 환경을 참조하세요.

페이지 머리글에서 보기를 선택하여 의미 체계 모델에 연결된 다른 보고서를 테스트합니다. 의미 체계 모델과 동일한 작업 영역에 있는 보고서만 테스트할 수 있습니다.

일반 보기로 돌아가려면 행 수준 보안으로 돌아가기를 선택합니다.

username() 또는 userprincipalname() DAX 함수 사용

데이터 세트 내에서 DAX 함수 username() 또는 userprincipalname()을 사용할 수 있습니다. Power BI Desktop의 식 내에서 사용할 수 있습니다. 모델을 게시하면 Power BI 서비스 내에서 사용됩니다.

Power BI Desktop 내에서 username ()은 사용자를 DOMAIN\User 형식으로 반환하며, userprincipalname()은 사용자를 user@contoso.com 형식으로 반환합니다.

Power BI 서비스 내에서 username() 및 userprincipalname()은 모두 사용자의 UPN(사용자 계정 이름)을 반환합니다. 형태는 전자 메일 주소와 유사합니다.

Power BI에서 작업 영역과 함께 RLS 사용

Power BI 서비스의 작업 영역에 Power BI Desktop 보고서를 게시할 경우 작업 영역에서 뷰어 역할이 할당된 멤버에게 RLS 역할이 적용됩니다. 뷰어에게 의미 체계 모델에 대한 빌드 권한이 부여되더라도 RLS는 계속 적용됩니다. 예를 들어, 빌드 권한이 있는 뷰어가 Excel에서 분석을 사용하는 경우 데이터 보기는 RLS에 의해 제한됩니다. 관리자, 멤버 또는 기여자가 할당된 작업 영역 멤버에는 의미 체계 모델에 대한 편집 권한이 있으므로 RLS가 적용되지 않습니다. 작업 영역에 있는 사용자에게 RLS를 적용하려면 해당 사용자에게 뷰어 역할만 할당하면 됩니다. 작업 영역의 역할에 대해 자세히 알아보세요.

외부(B2B 게스트) 사용자에 대한 고려 사항

Microsoft Entra B2B를 통해 외부 사용자와 Power BI 콘텐츠를 공유하는 경우 RLS에 대한 다음 고려 사항에 유의하세요.

외부 멤버가 있는 Entra 보안 그룹

외부 B2B 게스트 사용자를 포함하는 Microsoft Entra 보안 그룹은 RLS 역할 멤버 자격에 사용할 때 예상대로 작동하지 않을 수 있습니다. 일부 구성에서는 특히 외부 사용자에게 멤버 유형 계정이 아닌 게스트 유형 계정이 있는 경우 RLS 필터를 적용할 때 게스트의 그룹 멤버 자격이 Power BI 서비스 의해 올바르게 평가되지 않습니다.

권장 해결 방법: Entra 보안 그룹을 통해 RLS 역할에 외부 사용자를 추가하는 대신 전자 메일 주소로 역할에 직접 추가합니다. 전자 메일 주소는 사용자의 B2B 계정으로 확인됩니다. 이렇게 하면 RLS 필터가 적용될 때 ID가 올바르게 일치합니다. 자세한 내용은 역할 멤버 자격 관리를 참조하세요.

외부 사용자가 많은 조직의 경우 그룹 기반 역할 멤버 자격 대신 동적 RLS USERPRINCIPALNAME() 를 사용하는 것이 좋습니다. 이 방법은 각 사용자의 ID를 개별적으로 평가하고 그룹 멤버 자격 확인 문제를 완전히 방지합니다.

외부 사용자와 콘텐츠를 공유하는 방법에 대한 자세한 내용은 Microsoft Entra B2B 사용하여 외부 게스트 사용자에게 Power BI 콘텐츠 배포를 참조하세요.

해결 방법을 적용한 후에도 문제가 지속되면 추가 진단 단계는 문제 해결: 외부 게스트에게 데이터가 표시되지 않음을 참조하세요.

B2B 방문자를 위한 UPN 해상도

외부 B2B 게스트 사용자가 Power BI 보고서에 액세스하는 경우 USERPRINCIPALNAME() DAX 함수는 일반적으로 전자 메일과 유사한 식별자(예: user@partner.com)를 반환합니다. 일부 구성에서는 게스트 UPN #EXT# 을 형식(예: user_partner.com#EXT#@yourtenant.onmicrosoft.com)으로 반환할 수 있습니다.

이러한 구분은 동적 RLS에 중요합니다. 사용자 매핑 테이블에 저장된 식별자 형식이 USERPRINCIPALNAME()가 반환하는 형식과 다르면 필터 표현식이 일치하지 않아, 게스트 사용자에게 데이터가 없거나 잘못된 데이터가 표시될 수 있습니다.

B2B 게스트에 대한 USERNAME() 동작

DAX 함수는 USERNAME() 사용자의 domain\username 식별자를 반환합니다. B2B 게스트 사용자의 경우 이 함수는 일반적으로 도메인\사용자 이름 형식이 아닌 구성(예 user@partner.com: )에 따라 USERPRINCIPALNAME()과 유사한 UPN과 유사한 식별자를 반환합니다. USERNAME()와 USERPRINCIPALNAME()가 B2B 게스트를 위해 동일한 값을 반환하는 경우가 많기 때문에, 대부분의 구현에서는 USERPRINCIPALNAME()를 일관성을 위해 사용합니다.

[UserEmail] = USERPRINCIPALNAME()

내부 및 외부 사용자 모두를 위해 UserEmail와 같은 전자 메일 주소가 user@partner.com 열에 포함된 위치입니다.

문제 해결: 외부 게스트에 데이터가 표시되지 않음

B2B 게스트 사용자가 빈 보고서를 보거나 "데이터 없음" 메시지를 수신하는 경우 다음 단계를 수행합니다.

1. 반환된 UPN 형식 확인 - USERPRINCIPALNAME()을 사용하여 테스트 측정값을 만들고, 이를 카드 시각화로 표시합니다. 게스트 사용자가 보고서를 보고 반환된 실제 값을 확인하도록 합니다.
2. 사용자 매핑 테이블 확인 - 매핑 테이블에 해당 게스트의 반환 내용과 정확히 일치하는 값이 있는 행이 포함되어 있는지 USERPRINCIPALNAME() 확인합니다.
3. 대/소문자 구분 확인 - DAX 문자열 비교는 기본적으로 대/소문자를 구분하지 않지만 데이터 원본에 대/소문자 구분 값이 도입되지 않았는지 확인합니다.
4. 테넌트 간 액세스 설정 보기 - 조직에서 cross-tenant 액세스 정책을 사용하는 경우 Power BI 표시되는 UPN 형식에 영향을 줄 수 있습니다.
5. 실제 게스트 사용자로 테스트 - 역할로서의 테스트 기능은 사용자 고유의 ID를 사용합니다. 항상 실제 외부 게스트 계정으로 유효성을 검사합니다.
6. 역할 할당 확인 - 게스트 사용자에게 예상보다 많은 데이터가 표시되는 경우 RLS 역할에 할당되었는지 확인합니다. RLS 역할이 적용되지만 일치하는 역할이 적용되지 않으므로 일반적으로 RLS 역할에 할당되지 않은 사용자에게는 데이터가 표시되지 않습니다(빈 결과). DAX 필터는 각 행에 대해 TRUE/FALSE를 평가합니다. TRUE를 반환하는 행만 표시됩니다. 다른 모든 항목은 완전히 제거됩니다.

외부 사용자와 Power BI 콘텐츠를 공유하는 방법에 대한 자세한 내용은 Microsoft Entra B2B를 사용하여 외부 게스트 사용자에게 Power BI 콘텐츠를 배포하는 방법에 대한 정보를 확인하세요.

고려 사항 및 제한 사항

여기에서 클라우드 모델의 행 수준 보안에 대한 현재 제한 사항을 확인할 수 있습니다.

• 이전에 Power BI 서비스에 역할 및 규칙을 정의한 경우 Power BI Desktop에서 이를 다시 생성해야 합니다.
• Power BI Desktop으로 만들어진 의미 체계 모델에서만 RLS를 정의할 수 있습니다. Excel로 만든 의미 체계 모델에 대해 RLS를 사용하도록 설정하려면 먼저 파일을 Power BI Desktop(PBIX) 파일로 변환해야 합니다. 자세히 알아보기.
• 서비스 주체를 RLS 역할에 추가할 수 없습니다. 따라서 최종 유효 ID로 서비스 주체를 사용하는 앱에는 RLS가 적용되지 않습니다.
• 가져오기 및 DirectQuery 연결만 지원됩니다. Analysis Services에 대한 라이브 연결은 온-프레미스 모델에서 처리됩니다.
• RLS를 사용하도록 설정하면 DAX 쿼리 및 측정값에서 USERELATIONSHIP() 함수를 사용하면 예기치 않은 오류가 발생할 수 있습니다. 이 문제를 해결하려면 USERELATIONSHIP()을 방지하고 모델 수준 관계 또는 기타 DAX 패턴을 대신 사용하도록 DAX 식을 다시 디자인합니다.
• 역할로 테스트/역할로 보기 기능은 SSO(Single Sign-On)가 설정된 DirectQuery 모델에서는 작동하지 않습니다.
• 역할로 테스트 및 보기 기능은 의미 모델 작업 공간의 보고서들만 표시합니다.
• 역할로 테스트/역할로 보기 기능은 페이지가 매겨진 보고서에서는 작동하지 않습니다.
• 토큰 기반 ID는 Microsoft Entra 인증을 허용하도록 구성된 Azure SQL Database에 연결된 용량의 DirectQuery 모델에 대해서만 작동합니다. 자세한 내용은 토큰 기반 ID를 사용하여 보고서 포함을 참조하세요.
• 'IdentityBlob' 매개 변수는 Azure SQL 대한 OAuth 2.0 액세스 토큰이며 Azure SQL DirectQuery 연결이 있는 데이터 세트에 대해서만 지원됩니다. 메커니즘 자체는 Azure SQL에만 해당합니다. Blob은 https://database.windows.net/.default 범위로 지정된 Microsoft Entra 액세스 토큰is입니다. App-owns-data 포함에는 다른 데이터 원본에 해당하는 토큰 전달 메커니즘이 없습니다. 자세한 내용은 GenerateToken에 대한 REST API 참조를 참조하세요.

동적 RLS에 대한 고려 사항 및 제한 사항

USERPRINCIPALNAME(), USERNAME(), CUSTOMDATA()와 같은 DAX 함수를 사용하여 동적 행 수준 보안(RLS)을 사용할 때는 다음 고려 사항에 유의하세요.

B2B 테넌트 간 시나리오

B2B 시나리오에서 USERPRINCIPALNAME() Power BI 서비스에서 확인된 ID를 반환하며, 이 ID는 테넌트 구성에 따라 다를 수 있습니다. 다음 중 하나로 표시할 수 있습니다.

• 외부 사용자의 전자 메일 주소(user@partner.com) 또는
• 테넌트 확인 값(예: user_partner.com#EXT#@tenant.onmicrosoft.com

정확한 형식은 보장되지 않으며 사용자 환경에서 유효성을 검사해야 합니다.

사용자 매핑 테이블이 게스트 사용자에 대해 반환되는 USERPRINCIPALNAME() 것과 다른 형식으로 식별자를 저장하는 경우 RLS 필터 식이 일치하지 않으며 게스트에 데이터나 잘못된 데이터가 표시되지 않습니다. 항상 사용자 환경에서 외부 사용자에게 USERPRINCIPALNAME()에서 반환되는 정확한 값을 확인하세요.

동적 RLS를 사용하여 역할 제한으로 테스트

Power BI 서비스 Test as role 기능은 동적 RLS 식을 평가할 때 고유한 ID를 사용합니다. 즉 USERPRINCIPALNAME() , 시뮬레이션하려는 사용자의 UPN 이 아닌 UPN을 반환합니다. 테스트를 역할로 사용하여 특정 B2B 게스트 사용자 또는 서비스 주체가 어떤 것을 볼 수 있는지 확인할 수 없습니다.

Test as role은 역할 멤버십을 시뮬레이션하지만, 특히 B2B 게스트 또는 임베디드 시나리오의 경우 다른 사용자의 인증 컨텍스트를 완전히 재현하지는 않습니다.

외부 사용자에 대한 동적 RLS의 유효성을 검사하려면 실제 게스트 사용자로 로그인하고 보고서를 직접 봅니다. 이는 예상 값을 반환하고 RLS 필터가 USERPRINCIPALNAME() 해당 사용자에 대해 올바르게 일치하는지 확인하는 유일한 방법입니다.

서비스 주체를 사용하는 포함된 시나리오

보고서가 서비스 주체로 인증하는 포함된 애플리케이션을 통해 액세스될 경우, USERPRINCIPALNAME() 및 USERNAME()는 최종 사용자의 ID가 아니라 서비스 주체의 애플리케이션 ID 또는 빈 문자열을 반환합니다.

이러한 함수는 최종 사용자 ID를 반환하지 않으므로 서비스 주체 포함 시나리오에서 사용자별 필터링에 사용할 수 없습니다. 즉, 이러한 함수를 기반으로 하는 동적 RLS 필터는 포함된 시나리오에서 사용자당 데이터를 필터링하지 않습니다.

포함된 시나리오에서 사용자별 RLS를 적용하려면 Power BI REST API의 효율 ID 기능을 사용합니다. 임베드 토큰을 생성할 때 적절한 사용자 이름과 역할이 포함된 EffectiveIdentity 개체를 전달합니다. RLS 규칙에서 CUSTOMDATA()를 사용하는 경우 사용자 지정 데이터 문자열을 EffectiveIdentity.CustomData를 통해 전달하세요.

자세한 내용은 ISV에 대한 포함된 시나리오에 대한 RLS를 참조하세요.

Power BI 보고서가 RLS가 구성된 행을 참조하는 경우 삭제되었거나 존재하지 않는 필드와 동일한 메시지가 표시됩니다. 사용자에게는 보고서가 손상된 것처럼 보입니다.

자주 묻는 질문(FAQ)

질문: 이전에 Power BI 서비스의 데이터 세트에 대해 역할 및 규칙을 만든 경우 어떻게 됩니까? 아무 작업도 수행하지 않아도 계속 작동합니까?
답변: 아니요. 비주얼이 제대로 렌더링되지 않습니다. Power BI Desktop 내 역할 및 규칙을 다시 만든 다음, Power BI 서비스에 게시해야 합니다.

질문: Analysis Services 데이터 소스에 대해 이러한 역할을 만들 수 있습니까?
답변: 예. 데이터를 Power BI Desktop으로 가져온 경우입니다. 라이브 연결을 사용하는 경우 Power BI 서비스 내에서 RLS를 구성할 수 없습니다. Analysis Services 모델 온-프레미스 내에서 RLS를 정의합니다.

질문: RLS를 사용하여 내 사용자가 액세스할 수 있는 열이나 측정값을 제한할 수 있나요?
답변: 아니요, 사용자가 특정 데이터 행에 대한 액세스 권한이 있는 경우 해당 행의 모든 데이터 열을 볼 수 있습니다. 열 및 열 메타데이터에 대한 액세스를 제한하려면 개체 수준 보안을 사용하는 것이 좋습니다.

질문: RLS를 사용하면 자세한 데이터를 숨기고 시각적 개체에서 요약된 데이터에 대한 액세스 권한을 부여할 수 있나요?
답변: 아니요. 데이터 개별 행의 보안을 유지할 수 있지만 사용자는 요약된 데이터 또는 세부 정보를 확인할 수 있습니다.

질문: 내 데이터 원본에 이미 보안 역할이 정의되어 있습니다(예: SQL Server 역할 또는 SAP BW 역할). 이러한 역할과 RLS 사이에는 어떤 관계가 있나요?
답변: 데이터를 가져오는지 아니면 DirectQuery를 사용하는지에 따라 달라집니다. Power BI 데이터 세트로 데이터를 가져오는 경우에는 데이터 원본의 보안 역할이 사용되지 않습니다. 이 경우 RLS를 정의하여 Power BI에서 연결하는 사용자를 위한 보안 규칙을 적용해야 합니다. DirectQuery를 사용하는 경우에는 데이터 원본의 보안 역할이 사용됩니다. 사용자가 보고서를 열면 Power BI가 기본 데이터 원본으로 쿼리를 전송하고, 해당 데이터 원본은 사용자의 자격 증명에 따라 데이터에 보안 규칙을 적용합니다.

질문: 사용자가 둘 이상의 역할에 속할 수 있습니까?
답변: 사용자는 여러 역할에 속할 수 있으며 역할은 가산적입니다. 예를 들어 사용자가 "영업" 및 "마케팅" 역할에 모두 속하는 경우 이러한 두 역할에 대한 데이터를 볼 수 있습니다.

관련 콘텐츠

• Power BI Desktop에 대해 RLS(행 수준 보안)를 사용하여 데이터 액세스 제한
• Power BI 구현 계획: 보고서 사용자 보안 계획
• 내장 시나리오용 RLS (ISV 대상)
• Microsoft Entra B2B를 사용하여 외부 게스트 사용자에게 Power BI 콘텐츠를 배포합니다

궁금한 점이 더 있나요? Power BI 커뮤니티에 질문해 보세요 제안이 있으신가요? Power BI 개선을 위한 아이디어 제공