다음을 통해 공유

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

  • 아티클

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

Power BI로 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 값을 반환합니다.

    행 수준 보안을 정의하기 위한 역할 관리 창 기본 편집기의 스크린샷.

    참고 항목

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

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

    예제 DAX 식을 강조 표시하는 역할 관리 창의 스크린샷

    참고 항목

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

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

    기본 편집기로 전환할 것인지 확인하는 대화 상자의 스크린샷.

    참고 항목

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

  9. 저장을 선택합니다.

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

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

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

양방향으로 보안 필터를 적용하는 모델 관계 설정의 스크린샷.

모델에 대한 보안 관리

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

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

    탐색 메뉴의 추가 옵션 메뉴를 보여주는 스크린샷.

  2. 보안을 선택합니다.

    보안이 선택된 추가 옵션 메뉴를 보여주는 스크린샷.

보안은 사용자가 만든 역할에 멤버를 추가할 수 있는 역할 수준 보안 페이지로 이동합니다. 기여자(및 더 높은 작업 영역 역할)에는 보안이 표시되고 사용자를 역할에 할당할 수 있습니다.

멤버 작업

맴버 추가

Power BI 서비스에서 사용자의 이메일 주소나 이름 또는 보안 그룹을 입력하여 역할에 멤버를 추가할 수 있습니다. Power BI에서 만든 그룹은 추가할 수 없습니다. 조직 외부 멤버를 추가할 수 있습니다.

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

Microsoft 365 그룹은 지원되지 않으며 어떤 역할에도 추가할 수 없습니다.

멤버를 추가하는 방법을 보여 주는 스크린샷.

역할 이름 옆이나 멤버 옆에 있는 괄호에 있는 숫자로 역할에 속한 멤버의 수를 확인할 수도 있습니다.

역할의 멤버를 보여 주는 스크린샷.

멤버 제거

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

멤버를 제거하는 방법을 보여 주는 스크린샷.

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

역할을 테스트하여 사용자가 정의한 역할이 Power BI 서비스에서 제대로 작동하는지 확인할 수 있습니다.

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

역할로 테스트 옵션의 스크린샷.

이 의미 체계 모델이 있는 경우 Power BI Desktop에서 게시된 보고서로 리디렉션됩니다. 대시보드는 역할로 테스트 옵션을 사용하여 테스트할 수 없습니다.

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

특정 사용자에 대한 지금 보기 드롭다운 스크린샷.

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

테스트할 다른 보고서를 선택하는 보기의 스크린샷.

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

참고 항목

역할로 테스트 기능은 SSO(Single Sign-On)가 설정된 DirectQuery 모델에서는 작동하지 않습니다. 또한 Q&A 시각화, 빠른 인사이트 시각화 및 Copilot을(를) 포함한 역할로 테스트 기능에서 보고서의 모든 측면을 검증할 수 있는 것은 아닙니다.

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를 적용하려면 해당 사용자에게 뷰어 역할만 할당하면 됩니다. 작업 영역의 역할에 대해 자세히 알아보세요.

고려 사항 및 제한 사항

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

  • 이전에 Power BI 서비스에 역할 및 규칙을 정의한 경우 Power BI Desktop에서 이를 다시 생성해야 합니다.
  • Power BI Desktop으로 만들어진 의미 체계 모델에서만 RLS를 정의할 수 있습니다. Excel로 만든 의미 체계 모델에 대해 RLS를 사용하도록 설정하려면 먼저 파일을 Power BI Desktop(PBIX) 파일로 변환해야 합니다. 자세히 알아보기.
  • 서비스 사용자를 RLS 역할에 추가할 수 없습니다. 따라서 최종 유효 ID로 서비스 주체를 사용하는 앱에는 RLS가 적용되지 않습니다.
  • 가져오기 및 DirectQuery 연결만 지원됩니다. Analysis Services에 대한 라이브 연결은 온-프레미스 모델에서 처리됩니다.
  • 역할로 테스트/역할로 보기 기능은 SSO(Single Sign-On)가 설정된 DirectQuery 모델에서는 작동하지 않습니다.
  • 역할로 테스트/역할로 보기 기능은 의미 체계 모델 작업 영역의 보고서만 표시합니다.
  • 역할로 테스트/역할로 보기 기능은 페이지를 매긴 보고서에서 작동하지 않습니다.

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 커뮤니티에 질문하기의 제안은 무엇입니까? Power BI 개선을 위한 아이디어 제공