Share via


Power BI 구현 계획: 보고서 소비자 보안 계획

참고 항목

이 문서는 Power BI 구현 계획 시리즈의 일부를 구성합니다. 이 시리즈는 주로 Microsoft Fabric 내의 Power BI 워크로드에 중점을 둡니다. 시리즈에 대한 소개는 Power BI 구현 계획을 참조하세요.

이 보안 계획 문서에서는 읽기 전용 소비자를 위한 전략을 설명합니다. 보고서 및 앱에 대한 뷰어 권한과 데이터 보안을 적용하는 방법에 중점을 줍니다. 주로 다음을 대상으로 합니다.

  • Power BI 관리자: 조직의 Power BI를 감독할 책임이 있는 관리자입니다.
  • 우수성 센터, IT 및 BI 팀: Power BI를 감독할 책임도 있는 팀입니다. Power BI 관리자, 정보 보안 팀 및 기타 관련 팀과 공동 작업해야 하는 경우가 있을 수 있습니다.
  • 콘텐츠 작성자 및 소유자: 다른 사용자가 소비하는 콘텐츠를 만들고, 게시하고, 보호하고, 관리해야 하는 셀프 서비스 BI 작성자입니다.

일련의 문서는 Power BI 보안 백서의 콘텐츠를 확장하기 위한 것입니다. Power BI 보안 백서에서는 인증, 데이터 보존 및 네트워크 격리 등의 주요 기술 항목을 중점적으로 다루지만, 보안 및 프라이버시와 관련된 의사결정 사항과 고려 사항을 제시하는 것을 주된 목표로 합니다.

조직에서 많은 사용자가 소비자로 분류됩니다. 소비자는 다른 사용자가 만들고 게시한 콘텐츠를 봅니다. 소비자는 이 문서의 초점입니다. 콘텐츠 작성자 및 소유자에 초점을 맞춘 보안 계획은 콘텐츠 작성자 보안 계획 문서를 참조하세요.

이 문서에서 최대한 활용하려면 Power BI 컨텍스트에서 공유배포 라는 용어의 의미를 이해하는 것이 유용합니다.

공유는 한 사용자가 다른 사용자 또는 사용자 그룹에 특정 콘텐츠에 대한 액세스 권한을 부여하는 것입니다. Power BI 서비스의 공유 기능 범위는 한 항목으로 지정됩니다. 가장 일반적으로 공유는 서로를 알고 긴밀하게 협력하는 개인 간에 발생합니다.

배포 는 콘텐츠를 받는 사람이라고 하는 다른 사용자에게 전달되는 위치입니다. 여러 팀에서 더 많은 수의 사용자가 포함되는 경우가 많습니다. 받는 사람이 콘텐츠를 명시적으로 요청하지 않았을 수 있지만 해당 역할을 수행하는 데 필요한 것으로 인식됩니다. 배포된 콘텐츠를 사용하는 받는 사람은 콘텐츠의 원래 작성자를 알 수도 있고 모를 수도 있습니다. 따라서 개념적으로 배포는 공유보다 더 공식적입니다.

다른 사용자와 대화할 때 공유라는 용어를 일반적인 방식으로 사용하고 있는지 또는 문자 그대로 사용하는지 판정하세요. 공유라는 용어의 사용은 두 가지 방법으로 해석할 수 있습니다.

  • 공유라는 용어는 종종 동료와 콘텐츠를 공유하는 일반적 방법과 관련되어 사용됩니다. 이 문서에 설명된 읽기 전용 콘텐츠를 제공하기 위한 몇 가지 기술이 있습니다.
  • 공유 는 Power BI의 특정 기능이기도 합니다. 단일 항목에 대한 액세스 권한이 사용자 또는 그룹에 부여되는 기능입니다. 공유 링크 및 직접 액세스 공유는 이 문서에 설명되어 있습니다.

Important

Power BI 관리자 역할의 이름이 바뀌었습니다. 역할의 새 이름은 패브릭 관리자입니다.

읽기 전용 소비자를 위한 전략

Power BI 서비스 소비자는 다음 두 가지 모두에 대한 권한이 있는 경우 보고서 또는 대시보드를 볼 수 있습니다.

  • 시각화가 포함된 Power BI 항목(예: 보고서 또는 대시보드) 보기.
  • 기본 데이터(의미 체계 모델(이전에는 데이터 세트라고 함) 또는 기타 원본)를 읽습니다.

다양한 기술을 사용하여 소비자에게 읽기 전용 액세스를 제공할 수 있습니다. 셀프 서비스 콘텐츠 작성자가 사용하는 일반적인 기술은 다음과 같습니다.

Power BI 앱 및 Power BI 작업 영역 뷰어 역할 옵션에는 항목 집합에 대한 권한 관리가 포함됩니다. 두 개의 항목당 권한 기술에는 하나의 개별 항목에 대한 사용 권한 관리가 포함됩니다.

일반적으로 대부분의 소비자에게 Power BI 앱을 사용하는 것이 좋습니다. 경우에 따라 작업 영역 뷰어 역할도 적절할 수 있습니다. Power BI 앱과 작업 영역 뷰어 역할을 모두 사용하면 많은 항목에 대한 권한을 관리할 수 있으며 가능하면 언제든지 사용해야 합니다. 개별 항목에 대한 사용 권한 관리는 지루하고 시간이 오래 걸리며 오류가 발생하기 쉽습니다. 반대로 항목 집합을 관리하면 유지 관리가 줄어들고 정확도가 향상됩니다.

항목에 대한 보안 설정을 검토할 때 해당 권한이 다음 중 하나임을 확인할 수 있습니다.

  • 작업 영역 또는 앱에서 상속됨.
  • 항목에 직접 적용됨.

다음 스크린샷에서는 보고서에 대한 직접 액세스 권한이 표시됩니다. 이 인스턴스에서 작업 영역 관리 및 멤버 역할은 각각 그룹에 할당됩니다. 이러한 역할은 보고서 수준 액세스가 작업 영역에서 상속되기 때문에 보고서에 표시됩니다. 보고서에 직접 적용된 읽기 권한이 있는 사용자도 한 명 있습니다.

Power BI 서비스 보고서에 대한 직접 액세스 권한의 스크린샷.

읽기 전용 소비자에 대해 선택하는 전략은 다를 수 있습니다. 이러한 전략은 개별 솔루션, 솔루션을 관리하는 사용자의 기본 설정 또는 소비자의 요구를 기반으로 해야 합니다. 이 섹션의 나머지 부분에서는 사용 가능한 각 기술을 사용하는 방법을 고려해야 하는 경우에 대해 설명합니다.

검사 목록 - 읽기 전용 소비자에게 콘텐츠를 제공하는 방법에 대한 전략을 만들 때 주요 의사 결정 및 작업에는 다음이 포함됩니다.

  • 읽기 전용 소비자에 대한 기존 전략 평가: 콘텐츠가 현재 소비자에게 배포되고 공유되는 방식을 확인합니다. 개선의 여지가 있는지 확인합니다.
  • 읽기 전용 소비자에 대한 전략 결정: 앱 사용 권한, 작업 영역 역할 또는 항목별 권한을 사용하기 위한 기본 설정이 무엇인지 고려합니다. 이러한 기본 설정을 충족하기 위해 변경이 필요한 경우 개선 계획을 만듭니다.

Power BI 앱 사용 권한

Power BI 앱은 보고서, 대시보드 및 통합 문서 컬렉션을 소비자에게 제공합니다. 앱은 다음과 같은 이유로 소비자에게 최상의 사용자 환경을 제공합니다.

  • 앱의 탐색 창은 간단하고 직관적인 사용자 환경을 제공합니다. 작업 영역에서 직접 콘텐츠에 액세스하는 것보다 더 좋은 환경입니다.
  • 콘텐츠는 앱의 탐색 창에 있는 섹션(폴더와 같은)으로 논리적으로 구성할 수 있습니다.
  • 소비자는 대상 그룹을 위해 앱에 명시적으로 포함된 특정 항목에만 액세스할 수 있습니다.
  • 추가 정보, 설명서 또는 기타 콘텐츠에 대한 링크를 대상 그룹의 탐색 창에 추가할 수 있습니다.
  • 기본 제공 요청 액세스 워크플로가 있습니다.

참고 항목

이 문서의 앱에 대한 모든 참조는 Power BI 앱을 참조합니다. Power Apps와는 다른 개념입니다. Power BI 모바일 애플리케이션과도 다른 개념입니다. 이 섹션에서는 템플릿 앱이 아닌 조직 앱에 초점을 맞춥니다.

작업 영역 콘텐츠를 일부 또는 전부 배포하는 공식적인 방법으로 각 작업 영역에 대해 하나의 앱을 만들 수 있습니다. 앱은 조직 내에서 콘텐츠를 광범위하게 배포하는 좋은 방법이며, 특히 사용자가 잘 모르거나 긴밀하게 협업하지 않는 사용자에게 배포할 수 있습니다.

광범위한 콘텐츠 배포를 위해 Power BI 앱을 사용하는 방법에 대한 자세한 내용은 엔터프라이즈 BI 사용 시나리오를 참조하세요. 콘텐츠를 배포해야 하는 콘텐츠 작성자는 첫 번째 선택으로 앱을 만드는 것이 좋습니다.

작업 영역 역할과 별도로 앱 권한을 관리합니다. 사용 권한 분리에는 두 가지 이점이 있습니다. 다음을 권장합니다.

  • 콘텐츠 작성자에 대한 작업 영역 액세스 권한 부여. 여기에는 의미 체계 모델 작성자, 보고서 작성자 및 테스터와 같이 콘텐츠에 대해 적극적으로 공동 작업하는 사용자가 포함됩니다.
  • 소비자에게 앱 사용 권한 부여. 작업 영역 권한과 달리 앱 권한은 항상 읽기 전용(또는 없음)입니다.

작업 영역 액세스 권한이 있는 모든 사용자는 앱을 자동으로 볼 수 있습니다(Power BI 앱이 작업 영역에 대해 게시된 경우). 이 동작으로 인해 작업 영역 역할을 각 앱 대상 그룹이 상속하는 것으로 개념적으로 생각할 수 있습니다. 작업 영역 액세스 권한이 있는 일부 사용자는 할당된 작업 영역 역할에 따라 Power BI 앱을 업데이트할 수도 있습니다.

작업 영역 액세스에 대한 자세한 내용은 콘텐츠 작성자 보안 계획 문서를 참조하세요.

다음과 같은 경우 앱을 사용하여 읽기 전용 소비자에게 콘텐츠를 배포하는 것이 가장 좋습니다.

  • 사용자가 기본 작업 영역 내의 모든 항목이 아니라 해당 대상 그룹에 표시되는 특정 항목만 보게 하려고 합니다.
  • 작업 영역과 별도로 앱에 대한 읽기 전용 권한을 관리하려고 합니다.
  • 읽기 전용 사용자에 대해 항목별 권한보다 더 간단한 권한 관리를 원합니다.
  • 소비자에 대해 행 수준 보안이 적용되는지 확인하려고 합니다(기본 의미 체계 모델에 대한 읽기 전용 권한이 있는 경우).
  • 앱이 다시 게시될 때까지 소비자가 새 보고서와 변경된 보고서를 볼 수 없도록 해야 합니다.

앱이 다시 게시될 때까지 보고서 및 대시보드에 대한 변경 내용이 앱 사용자에게 표시되지 않는 것은 사실이지만 주의해야 하는 두 가지 고려 사항이 있습니다.

  • 즉각적인 의미 체계 모델 변경: 의미 체계 모델 변경은 항상 즉시 적용됩니다. 예를 들어 작업 영역의 의미 체계 모델에 호환성이 손상되는 변경 내용이 도입되면 실수로 보고서가 불안정해질 수 있습니다(앱에 다시 게시되지 않았더라도). 이 위험을 완화하는 방법에는 두 가지가 있습니다. 첫째, Power BI Desktop 모든 개발 작업을 수행합니다(작업 영역과 별개). 둘째, 개발 및 테스트에 별도의 작업 영역을 사용하여 프로덕션 앱을 격리합니다. (필요에 따라 배포 파이프라인을 사용하여 개발에서 테스트 및 프로덕션까지 작업 영역 콘텐츠 배포에 대한 더 높은 수준의 제어를 달성할 수 있습니다.)
  • 콘텐츠와 권한을 함께 게시: 앱을 게시하면 해당 사용 권한이 콘텐츠와 동시에 게시됩니다. 예를 들어 아직 완료, 완전히 테스트 또는 승인되지 않은 작업 영역에서 보고서 변경 내용이 있을 수 있습니다. 따라서 권한을 업데이트하기 위해 앱을 다시 게시할 수 없습니다. 이러한 위험을 완화하려면 보안 그룹에 앱 권한을 할당하고 앱 권한을 부여할 때 보안 그룹 멤버 자격(개별 사용자 대신)을 사용합니다. 단지 권한 변경을 적용하기 위해 앱을 다시 게시하지 마십시오.

앱 대상 그룹

Power BI 서비스 각 작업 영역에는 Power BI 앱이 하나만 있을 수 있습니다. 그러나 앱 내에서 하나 이상의 대상 그룹을 만들 수 있습니다. 다음 시나리오를 살펴 보십시오.

  • 전역 영업 조직 전체에서 많은 사용자에게 배포되는 5개의 판매 보고서가 있습니다.
  • 영업 담당자를 위해 앱에서 한 명의 대상 그룹이 정의됩니다. 이 대상 그룹은 5개의 보고서 중 3개를 볼 수 있습니다.
  • 다른 대상 그룹이 영업 리더십 팀을 위해 앱에서 정의됩니다. 이 대상 그룹은 영업 담당자가 사용할 수 없는 두 보고서를 포함하여 5개의 보고서를 모두 볼 수 있습니다.

콘텐츠와 대상 그룹을 서로 연결하는 이 기능에는 다음과 같은 이점이 있습니다.

  • 특정 보고서는 여러 대상 그룹이 볼 수 있습니다. 따라서 여러 대상 그룹을 만들면 여러 작업 영역에서 콘텐츠를 복제할 필요가 없습니다.
  • 특정 보고서는 하나의 대상 그룹에서만 볼 수 있습니다. 따라서 해당 대상 그룹의 콘텐츠는 다른 관련 콘텐츠와 동일한 작업 영역에 상주할 수 있습니다.

다음 스크린샷은 영업 리더십영업 담당자라는 두 명의 대상 그룹이 있는 앱을 보여 줍니다. 대상 그룹 액세스 관리 창은 Sales Leadership-North AmericaSales Leadership-Europe 등 두 보안 그룹에 대한 액세스를 영업 리더십 대상 그룹에 제공합니다. 영업 리더십 대상 그룹 스크린샷에 표시된 총 마진 분석 보고서는 영업 담당자 대상 그룹에서 사용할 수 없습니다.

Power BI 서비스 앱 대상 그룹 설정 스크린샷.

참고 항목

대상 그룹 집단이라는 용어가 사용되는 경우도 있습니다. 보안 그룹 사용에 대한 직접적인 참조는 아닙니다. 여기에는 Power BI 앱 내에서 콘텐츠 컬렉션을 볼 대상 그룹의 멤버가 포함됩니다. 개별 사용자를 대상 그룹에 할당할 수 있지만 실제로는 언제든지 보안 그룹, Microsoft 365 그룹 또는 메일 그룹을 할당하는 것이 가장 좋습니다. 자세한 내용은 테넌트 수준 보안 계획 문서에서 그룹을 사용하는 전략을 참조하세요.

앱에 대한 권한을 관리하는 경우 직접 액세스 페이지에서 각 대상 그룹의 구성원을 볼 수 있습니다. 모든 대상 그룹 아래에 나열된 작업 영역 역할이 있는 사용자를 볼 수도 있습니다. 직접 액세스 페이지에서는 앱 권한을 업데이트할 수 없습니다. 대신 앱을 다시 게시해야 합니다. 그러나 앱에 대한 열린 액세스 요청이 있는 경우 보류 중인 페이지에서 앱 권한을 업데이트할 수 있습니다.

앱 대상 그룹을 사용하는 기본 사용 사례는 다양한 사용자 집합에 대한 특정 권한을 정의하는 것입니다. 그러나 대상 그룹을 사용할 때 약간의 창의력을 발휘할 수 있습니다. 사용자는 여러 대상 그룹의 구성원일 수 있으며 각 대상 그룹은 앱의 뷰어에게 보조 메뉴 집합으로 표시됩니다. 예를 들어 앱을 사용하는 방법, 연락할 사람, 피드백을 제공하는 방법 및 도움말을 얻는 방법에 대한 정보가 포함된 여기서 시작이라는 대상 그룹을 만들 수 있습니다. 또는 데이터 사전을 포함하는 KPI 정의 라는 대상 그룹을 만들 수 있습니다. 이러한 유형의 정보를 제공하면 새 사용자에게 도움이 되며 솔루션 채택 노력을 개선할 수 있습니다.

사용 권한 옵션

앱을 만들거나 다시 게시할 때 각 대상 그룹에는 대상 그룹 액세스 관리 창이 있습니다. 해당 창에서 다음 권한을 사용할 수 있습니다.

  • 다음 대상에 액세스 권한 부여: 개별 사용자 및 그룹에 대한 액세스 권한을 각 대상 그룹에 부여할 수 있습니다. 전체 조직에 앱 게시 테넌트 설정을 통해 사용하도록 설정하면 전체 조직에 앱을 게시할 수 있으며 앱이 자동으로 설치되지 않습니다. 가능하면 사용자를 추가하거나 제거하려면 앱을 다시 게시해야 하므로 그룹을 대상 그룹에 할당하는 것이 좋습니다. 작업 영역 액세스 권한이 있는 모든 사용자에게는 작업 영역 역할에 따라 앱을 보거나 업데이트할 수 있는 권한이 자동으로 부여됩니다.
  • 의미 체계 모델 권한: 두 가지 형식의 의미 체계 모델 권한이 앱을 게시하는 동안 부여될 수 있습니다.
    • 의미 체계 재공유: 사용하도록 설정하면 앱 사용자에게 다른 사용자와 기본 의미 체계 모델에 대한 재공유 권한이 부여됩니다. 기본 의미 체계 모델을 누구와도 쉽게 다시 공유할 수 있는 경우 이 옵션을 사용하도록 설정하는 것이 좋습니다. 앱 대상 그룹에 다시 공유 권한을 부여하기 전에 의미 체계 모델 소유자로부터 승인을 받는 것이 좋습니다.
    • 의미 체계 모델 빌드: 사용하도록 설정하면 앱 사용자에게 의미 체계 모델에 대한 빌드 권한이 부여됩니다. 빌드 권한을 사용하면 사용자가 새 보고서를 만들고 보고서에서 기본 데이터를 내보내는 등의 작업을 수행할 수 있습니다. 앱 대상 그룹에 빌드 권한을 부여하기 전에 의미 체계 모델 소유자로부터 승인을 받는 것이 좋습니다.

앱을 게시하는 동안 의미 체계 모델 다시 공유 또는 빌드 권한을 추가하는 기능은 편리합니다. 그러나 앱 권한 및 의미 체계 모델 권한을 별도로 관리하는 것이 좋습니다. 그 이유는 다음과 같습니다.

  • 공유 의미 체계 모델은 별도의 작업 영역에 있을 수 있습니다. 의미 체계 모델이 앱과 별도의 작업 영역에 게시되는 경우 해당 권한을 직접 관리해야 합니다. 앱을 게시하는 동안 읽기, 빌드 또는 다시 공유 권한을 추가하는 기능은 앱과 동일한 작업 영역에 있는 의미 체계 모델에 대해서만 작동합니다. 이러한 이유로 의미 체계 모델 권한을 독립적으로 관리하는 습관을 들이는 것이 좋습니다.
  • 의미 체계 모델 권한은 별도로 관리됩니다. 앱에 대한 권한을 제거하거나 변경하는 경우 해당 작업은 앱에만 영향을 줍니다. 이전에 할당된 의미 체계 모델 권한은 자동으로 제거되지 않습니다. 이러한 방식으로 앱 권한 및 의미 체계 모델 권한은 분리된 것으로 간주할 수 있습니다. 의미 체계 모델 권한이 변경되거나 제거되어야 하는 경우 앱과 별도로 의미 체계 모델을 직접 관리해야 합니다.
  • 의미 체계 모델 권한을 제어해야 함: 앱을 통해 의미 체계 모델 권한을 부여하면 의미 체계 모델 소유자의 제어 권한이 제거됩니다. 다시 공유 권한을 부여하면 의미 체계 모델을 다시 공유하도록 선택한 사용자가 적절한 판단을 해야 합니다. 내부 거버넌스 또는 보안 지침은 다시 공유가 허용되는 경우 관리하기가 더 어려워질 수 있습니다.
  • 소비자와 크리에이터의 목표는 서로 다릅니다. 일반적으로 조직에는 작성자보다 콘텐츠 소비자가 더 많습니다. 최소 권한 원칙에 따라 소비자는 기본 의미 체계 모델에 대한 읽기 권한만 필요합니다. 새 보고서를 만들려는 경우가 아니면 빌드 권한이 필요하지 않습니다.

별도의 데이터 작업 영역 및 보고 작업 영역을 사용하는 시기에 대한 자세한 내용은 작업 영역 수준 계획 문서를 참조하세요.

앱 사전 설치 권한

Power BI 앱을 게시한 후 사용자는 일반적으로 Power BI 앱을 열 수 있도록 설치해야 합니다. 사용자는 Power BI 서비스 앱 페이지에서 또는 다른 사용자로부터 받은 링크를 사용하여 앱을 설치할 수 있습니다. 앱의 하나 이상의 대상 그룹에 포함되면 앱을 찾고 설치할 수 있습니다.

앱을 설치하는 다른 방법은 앱 소비자에게 푸시 하는 것입니다. 그러면 앱이 사전 설치되어 Power BI 서비스 앱 페이지에 자동으로 표시됩니다. 이 방법은 앱을 찾고 설치할 필요가 없으므로 소비자에게 편리합니다. 그러나 사전 설치된 앱은 관련이 없는 앱이 너무 많아지게 해서 사용자를 성가시게 할 수 있습니다.

최종 사용자에게 앱 푸시 테넌트 설정은 앱을 자동으로 설치할 수 있는 사용자를 제어합니다. 사용자에게 편리하기 때문에 이 기능을 사용하는 것이 좋습니다. 그러나 과도하게 사용되지 않도록 콘텐츠 작성자에게 사용 시기를 교육하는 것이 좋습니다.

앱을 게시할 때 앱을 자동으로 설치하는 옵션을 선택하면 대상 그룹을 전체 조직으로 설정할 수 없습니다( 최종 사용자에게 앱 푸시 테넌트 설정에서 사용하도록 설정된 경우).

검사 목록 - 콘텐츠 뷰어용 앱을 사용하기 위한 전략을 만들 때 주요 의사 결정 및 작업에는 다음이 포함됩니다.

  • 앱 사용 전략 결정: 앱을 사용하는 방법에 대한 기본 설정을 정의합니다. 읽기 전용 소비자에 대한 전반적인 전략과 일치하는지 확인합니다.
  • 전체 조직에 앱을 게시할 수 있는 사용자 결정: 전체 조직에 게시할 수 있는 보고서 작성자를 결정합니다. 이 결정에 맞게 전체 조직에 앱 게시 테넌트 설정을 설정합니다.
  • 최종 사용자에게 앱을 푸시할 수 있는 사용자 결정: 앱을 사전 설치할 수 있는 Power BI 보고서 작성자를 결정합니다. 최종 사용자에게 앱 푸시 테넌트 설정을 설정하여 이 결정에 맞춥니다.
  • 콘텐츠 작성자를 위한 지침 생성 및 게시: 콘텐츠 작성자를 위한 설명서 및 교육을 제공합니다. 앱을 가장 효과적으로 사용하는 방법에 대한 요구 사항 및 기본 설정을 포함합니다.
  • 앱 액세스 요청을 처리하는 방법 결정: 연락처를 할당하고 앱 액세스 요청을 적시에 처리하는 프로세스가 있는지 확인합니다.

작업 영역 뷰어 역할

작업 영역 계획 문서에 설명된 대로 작업 영역의 주요 목적은 협업입니다. 의미 체계 모델 작성자, 보고서 작성자 및 테스터와 같은 작업 영역 협력자는 기여자, 멤버 또는 관리자의 세 가지 역할 중 하나에 할당되어야 합니다. 이러한 역할콘텐츠 작성자 보안 계획 문서에 설명되어 있습니다.

소비자에게 작업 영역 뷰어 역할을 할당할 수 있습니다. 소비자가 작업 영역에서 직접 콘텐츠에 액세스할 수 있도록 허용하면 긴밀하게 협력하는 소규모 팀과 비공식 팀에 적합할 수 있습니다.

소비자가 작업 영역 콘텐츠에 직접 액세스할 수 있도록 허용하는 것은 다음과 같은 경우에 적합합니다.

  • 별도의 권한이 있는 앱의 형식은 필요하지 않습니다.
  • 뷰어는 작업 영역 내에 저장된 모든 항목을 볼 수 있습니다.
  • 항목별 권한보다 더 간단한 사용 권한 관리를 원합니다.
  • 작업 영역 사용자는 앱을 볼 수도 있습니다(작업 영역에 대한 앱이 게시된 경우).
  • 앱에 게시되기 전에 콘텐츠를 검토하기 위한 것입니다.

다음은 작업 영역 뷰어를 지원하기 위한 몇 가지 제안 사항입니다.

  • 보고서 소비자가 항목을 쉽게 배치하여 보안에 잘 맞도록 각 작업 영역에서 콘텐츠를 구성합니다. 주체 영역 또는 프로젝트별 작업 영역 조직은 일반적으로 잘 작동합니다.
  • 진행 중인 항목에 시청자가 액세스할 수 없도록 개발 및 테스트 콘텐츠를 프로덕션 콘텐츠와 분리합니다.
  • 처리할 액세스 요청이 많을 것으로 예상되는 경우 앱(또는 적절한 경우 항목별 권한)을 사용합니다. 작업 영역에 대한 액세스 요청 워크플로가 없습니다.

검사 목록 - 콘텐츠 뷰어용 작업 영역을 사용하기 위한 전략을 만들 때 주요 의사 결정 및 작업에는 다음이 포함됩니다.

  • 작업 영역 뷰어 역할을 사용하기 위한 전략 결정: 소비자를 위해 작업 영역을 사용하는 방법에 대한 기본 설정을 정의합니다. 읽기 전용 소비자에 대한 전반적인 전략과 일치하는지 확인합니다.
  • 콘텐츠 작성자를 위한 지침 생성 및 게시: 콘텐츠 작성자를 위한 설명서 및 교육을 제공합니다. 작업 영역 권한을 가장 효과적으로 사용하는 방법에 대한 요구 사항 및 기본 설정을 포함합니다.

항목별 권한

개별 항목 공유는 단일 항목에 대한 권한을 부여합니다. 경험이 적은 콘텐츠 작성자는 공유 명령이 Power BI 서비스 눈에 띄게 표시되기 때문에 일반적으로 이 기술을 기본 공유 기술로 사용합니다. 따라서 작업 영역 역할 대신 앱 사용 권한을 사용하는 경우를 포함하여 콘텐츠 제작자에게 다양한 공유 옵션을 교육하는 것이 중요합니다.

항목별 권한은 다음과 같은 경우에 적합합니다.

  • 한 항목(보고서 또는 대시보드)에 대한 읽기 전용 액세스를 제공하려는 경우.
  • 소비자가 작업 영역에 게시된 모든 콘텐츠를 보지 않기를 바라는 경우.
  • 소비자가 앱 대상 그룹에 게시된 모든 콘텐츠를 보지 않기를 바라는 경우.

공유는 단일 항목에 읽기 권한을 부여하므로 항목별 사용 권한을 아끼지 않고 사용합니다. 어떤 면에서 항목별 권한은 작업 영역 역할 또는 앱 권한의 재정의라고 생각할 수 있습니다.

가능한 경우 앱 권한을 사용할 것을 권장합니다. 다음으로 작업 영역 역할을 사용하여 직접 작업 영역 액세스를 사용하도록 설정하는 것이 좋습니다. 마지막으로 위의 조건을 충족하는 경우 항목별 권한을 사용합니다. 앱 권한 및 작업 영역 역할은 모두 개별 항목이 아닌 콘텐츠 컬렉션에 대한 보안을 지정합니다. 이는 더 나은 보안 사례입니다.

항목별 권한을 사용하여 많은 항목을 공유하는 것은 특히 그룹 대신 개별 사용자에게 공유할 때 지루하고 오류가 발생하기 쉽습니다. 개별 사용자 계정을 사용하여 동료에게 40개의 보고서를 공유한 시나리오를 생각해 보겠습니다. 한 동료가 다른 부서로 이전하는 경우 40개 보고서 모두에 대한 편집 권한이 포함된 액세스 권한을 취소해야 합니다.

Important

개인 작업 영역에서 콘텐츠를 공유하는 작업은 자주 수행되지 않아야 합니다. 개인 작업 영역은 중요하지 않거나 비공식적이거나 임시적인 콘텐츠에 가장 적합합니다. 콘텐츠 작성자가 개인 작업 영역에서 중요하거나 중요한 콘텐츠를 자주 공유하는 경우 해당 콘텐츠를 표준 작업 영역으로 이동하려면 적절한 조치를 취해야 합니다. 자세한 내용은 개인 BI 사용 시나리오를 참조하세요.

개별 항목을 공유하는 경우 몇 가지 사용 권한 옵션이 있습니다.

  • 재공유 권한: 사용하도록 설정하면 사용자는 기본 의미 체계 모델을 포함하여 다른 사용자와 항목을 공유할 수 있습니다. 항목을 누구와도 쉽게 공유할 수 있는 경우 이 권한을 부여하는 것이 좋습니다. 항목을 관리하는 사람 또는 팀에서 컨트롤을 제거합니다. 따라서 재공유 권한을 부여받은 사용자의 좋은 판단에 의존합니다. 내부 거버넌스 또는 보안 지침은 다시 공유가 허용되는 경우 관리하기가 더 어려워질 수 있습니다.
  • 빌드 권한: 사용하도록 설정하면 기본 의미 체계 모델에 대한 빌드 권한이 사용자에게 부여됩니다. 빌드 권한을 사용하면 사용자가 의미 체계 모델을 기반으로 하는 새 콘텐츠를 만들 수 있습니다. 또한 보고서 등에서 기본 데이터를 내보낼 수 있습니다. 빌드 권한 부여에 대한 고려 사항은 콘텐츠 작성자 보안 계획 문서에 설명되어 있습니다.

보고서 및 대시보드에 대한 항목별 권한은 콘텐츠가 몇몇 사용자와 공유되는 비공식적 시나리오에 적합할 수 있습니다. 특히 팀 외부의 많은 사용자 또는 사용자에게 콘텐츠를 공유하는 경우 앱 및 작업 영역을 사용하여 권한을 관리하는 방법을 사용자에게 교육하는 것이 좋습니다. 다음 사항을 강조하는 것이 중요합니다.

  • 각 보고서 및 대시보드에 대한 사용 권한을 개별적으로 검토해야 하므로 어떤 콘텐츠가 어떤 사용자와 공유되었는지 확인하기가 더 어려워집니다.
  • 대부분의 경우 사용자 환경에서 기본적으로 이 옵션을 사용하도록 설정하기 때문에 재공유 권한이 설정됩니다. 따라서 콘텐츠가 의도한 것보다 더 광범위한 사용자 집합에 공유될 위험이 있습니다. 이런 일은 공유 시 받는 사람이 이 보고서를 공유하도록 허용 옵션을 선택 취소하여 방지할 수 있습니다. 이러한 방식으로 과잉 공유를 최소화하는 것은 사용자 학습 문제입니다. 공유 권한을 설정하는 콘텐츠 작성자는 매번 이 선택을 고려해야 합니다.
  • 보고서 및 대시보드의 모든 변경 내용은 다른 사용자가 즉시 볼 수 있으므로 콘텐츠 수정이 진행 중인 작업일 때 사용자를 혼동할 수 있습니다. 이러한 문제는 앱에서 콘텐츠를 배포하거나 별도의 작업 영역을 사용하여 개발, 테스트 및 프로덕션 콘텐츠를 분리함으로써 완화할 수 있습니다. 자세한 내용은 셀프 서비스 콘텐츠 게시 사용 시나리오를 참조하세요.
  • 사용자가 개인 작업 영역의 콘텐츠를 공유하고 조직을 떠날 때 IT는 일반적으로 사용자 계정을 사용하지 않도록 설정합니다. 이 경우 공유 콘텐츠의 모든 수신자는 콘텐츠에 대한 액세스 권한을 즉시 잃게 됩니다.

공유 링크, 직접 액세스 공유 및 공유 보기 등 세 가지 특정 유형의 공유가 있습니다.

개별 항목을 공유하면 기본 환경이 공유 링크가 생성됩니다. 공유 링크에는 세 가지 유형이 있습니다.

  • 조직 내 사용자: Power BI 테넌트 설정에서 사용하도록 설정된 경우 이러한 유형의 공유 링크는 조직 내의 모든 사용자에게 읽기 전용 액세스를 제공하는 간단한 방법입니다. 그러나 공유 링크는 외부 사용자에게는 작동하지 않습니다. 이 옵션은 조직 전체에서 누구나 콘텐츠를 볼 수 있고 링크를 자유롭게 공유할 수 있는 경우에 가장 적합합니다. 공유 가능한 링크가 조직 내 모든 사용자에게 액세스 권한을 부여하도록 허용 테넌트 설정을 사용하지 않도록 설정하지 않는 한 이 유형의 공유가 기본값입니다.
  • 기존 액세스 권한이 있는 사용자: 이 옵션은 새 공유 링크를 만들지 않습니다. 대신 URL을 검색하여 이미 액세스 권한이 있는 사람에게 보낼 수 있습니다.
  • 특정 사용자: 이 옵션은 특정 사용자 또는 그룹에 대한 공유 링크를 생성합니다. 특정 액세스를 제공하므로 대부분의 경우 이 옵션을 사용하는 것이 좋습니다. 일반적으로 외부 사용자와 함께 작업하는 경우 Microsoft Entra ID(이전의 Azure Active Directory)에 이미 있는 게스트 사용자에 대해 이 유형의 링크를 사용할 수 있습니다. 게스트 사용자를 만들기 위한 계획된 초대 프로세스에 대한 자세한 내용은 테넌트 수준 보안 계획 문서를 참조하세요.

Important

공유 가능한 링크가 조직 내 모든 사용자에게 액세스 권한을 부여하도록 허용 테넌트 설정을 그룹 구성원으로 제한하는 것이 좋습니다. Power BI Share와 같은 그룹 이름을 전체 조직에 만든 다음 조직 전체 공유의 의미를 이해하는 소수의 사용자를 추가할 수 있습니다. 기존 조직 전체 링크가 우려되는 경우 관리자 API를 사용하여 전체 조직과 공유된 모든 항목을 찾을 수 있습니다.

공유 링크는 항목에 읽기 권한을 추가합니다. 재공유 권한은 기본적으로 선택되어 있습니다. 공유 링크가 만들어지는 동시에 기본 의미 체계 모델에 빌드 권한을 추가할 수도 있습니다.

보고서 소비자가 보고서를 만들거나, 데이터를 내보내거나, 기본 의미 체계 모델에서 복합 모델을 만들어야 할 수도 있는 콘텐츠 작성자이기도 한 경우에만 빌드 권한 옵션을 사용하도록 콘텐츠 작성자를 가르치는 것이 좋습니다.

공유 링크는 직접 액세스 공유보다 유지 관리가 더 쉬울 수 있습니다. 특히 대량 변경을 수행해야 하는 경우 더욱 편리합니다. 개별 사용자에게 공유 권한이 부여되는 경우 이는 그룹(일반적으로 셀프 서비스 사용자가 권한 관리를 담당할 때 발생)보다 훨씬 더 큰 이점입니다. 다음 비교를 고려합니다.

  • 공유 링크: 20명의 개별 사용자에게 공유 링크를 사용하여 액세스 권한이 부여됩니다. 링크가 한 번의 변경으로 20명의 사용자에게 모두 영향을 줍니다.
  • 직접 액세스: 20명의 개인에게 항목에 대한 직접 액세스 권한이 부여됩니다. 변경하려면 20개의 사용자 권한을 모두 수정해야 합니다.

항목별 직접 액세스 권한

직접 액세스를 사용하여 항목별 권한을 얻을 수도 있습니다. 직접 액세스에는 단일 항목에 대한 사용 권한 설정이 포함됩니다. 작업 영역 역할에서 파생된 상속된 사용 권한을 확인할 수도 있습니다.

사용자에게 직접 액세스 권한을 부여하면 항목에 대한 읽기 권한이 부여됩니다. 기본 의미 체계 모델에 대한 빌드 권한과 마찬가지로 재공유 권한은 기본적으로 선택됩니다. 보고서 소비자가 보고서를 만들거나, 데이터를 내보내거나, 기본 의미 체계 모델에서 복합 모델을 만들어야 할 수도 있는 콘텐츠 작성자이기도 한 경우에만 빌드 권한 옵션을 사용하도록 콘텐츠 작성자를 가르치는 것이 좋습니다.

사용자 환경을 사용하면 다시 공유 및 빌드 권한을 매우 간단하게 부여할 수 있지만 공유를 수행하는 사용자는 항상 해당 권한이 필요한지 확인해야 합니다.

공유 보기

공유 보기를 사용하여 보고서의 필터링된 관점을 다른 사용자와 공유합니다. 공유 링크를 사용하거나 직접 액세스하여 공유 보기를 게시할 수 있습니다.

공유 보기는 임시 개념입니다. 180일이 지나면 자동으로 만료됩니다. 이러한 이유로 공유 보기는 비공식 및 임시 공유 시나리오에 가장 적합합니다. 사용자가 이 제한 사항을 알고 있는지 확인하세요.

검사 목록 - 항목별 권한을 사용하기 위한 전략을 만들 때 주요 의사 결정 및 작업에는 다음이 포함됩니다.

  • 공유 기능을 사용하기 위한 전략 결정: 항목별 사용 권한을 사용하는 방법에 대한 기본 설정을 정의합니다. 읽기 전용 소비자에 대한 전반적인 전략과 일치하는지 확인합니다.
  • 전체 조직에 링크를 게시할 수 있는 사용자 결정: 전체 조직에 링크를 게시할 수 있는 보고서 작성자를 결정합니다. 공유 가능한 링크가 조직 내 모든 사용자에게 액세스 권한을 부여하도록 허용 테넌트 설정을 이 결정에 맞게 설정합니다.
  • 콘텐츠 작성자를 위한 지침을 만들고 게시: 항목별 사용 권한을 가장 효과적으로 사용하는 방법에 대한 요구 사항 및 기본 설정을 포함하는 콘텐츠 작성자를 위한 설명서 및 교육을 제공합니다. 항목별 권한의 장점과 단점을 명확히 확인합니다. 공유 링크를 사용하는 시기 및 직접 액세스 공유를 사용하는 시기에 대한 지침을 포함합니다.

기타 소비자 쿼리 기술

소비자가 Power BI와 상호 작용하는 가장 일반적인 방법은 앱, 작업 영역 및 항목별 권한(이 문서에서 설명한 내용)입니다.

소비자가 Power BI 데이터를 쿼리하는 데 사용할 수 있는 다른 기술이 있습니다. 다음 각 쿼리 기술에는 의미 체계 모델 또는 데이터 마트 빌드 권한이 필요합니다.

  • Excel에서 분석: Excel을 사용하려는 소비자는 Excel에서 분석을 사용하여 Power BI 의미 체계 모델을 쿼리할 수 있습니다. 이 기능은 데이터가 중복되지 않으므로 Excel로 데이터를 내보내는 좋은 대안입니다. 사용자는 의미 체계 모델에 대한 라이브 연결을 사용하여 피벗 테이블, 차트 및 슬라이서를 만들 수 있습니다. 그런 다음 소비자가 통합 문서를 열고 상호 작용할 수 있도록 Power BI 서비스 작업 영역에 통합 문서를 게시할 수 있습니다.
  • XMLA 엔드포인트: 소비자는 XMLA 엔드포인트에 연결하여 의미 체계 모델을 쿼리할 수 있습니다. XMLA 규격인 애플리케이션은 프리미엄 작업 영역에 저장된 의미 체계 모델에 연결, 쿼리 및 사용할 수 있습니다. 이 기능은 소비자가 Power BI 의미 체계 모델을 Microsoft 에코시스템 외부의 데이터 시각화 도구에 대한 데이터 원본으로 사용하려는 경우에 유용합니다.
  • 데이터 마트 편집기: 소비자는 데이터 마트 편집기를 사용하여 Power BI 데이터 마트를 쿼리할 수 있습니다. 코드 없는 쿼리를 만들기 위한 웹 기반 시각적 쿼리 편집기입니다. 소비자가 SQL 쿼리를 작성하는 것을 선호하는 경우 웹 기반 SQL 편집기도 있습니다. 두 편집기 모두 기본 제공 의미 체계 모델이 아닌 Power BI 데이터 마트의 기반이 되는 관리되는 Azure SQL Database를 쿼리합니다.
  • SQL 엔드포인트: 소비자는 SQL 엔드포인트를 사용하여 Power BI 데이터 마트를 쿼리할 수 있습니다. Azure Data Studio 또는 SSMS(SQL Server Management Studio)와 같은 도구를 사용하여 SQL 쿼리를 실행할 수 있습니다. SQL 엔드포인트는 기본 제공 의미 체계 모델이 아닌 Power BI 데이터 마트의 기반이 되는 관리되는 Azure SQL Database로 쿼리를 전달합니다.

작업 영역 액세스에 대한 자세한 내용은 콘텐츠 작성자 보안 계획 문서를 참조하세요.

검사 목록 - 소비자가 사용할 쿼리 기술을 계획할 때 주요 의사 결정 및 작업에는 다음이 포함됩니다.

  • Excel에서 분석을 사용하는 방법에 대한 사용자 지침 제작: Excel에서 기존 의미 체계 모델을 다시 사용하는 가장 좋은 방법에 대한 설명서 및 교육을 소비자에게 제공합니다.
  • XMLA 엔드포인트 사용 방법에 대한 사용자 지침 제작: XMLA 엔드포인트에서 기존 의미 체계 모델을 다시 사용하는 가장 좋은 방법에 대한 설명서 및 교육을 소비자에게 제공합니다.
  • 데이터 마트 쿼리에 대한 사용자 지침 제작: Power BI 데이터 마트를 쿼리하는 데 사용할 수 있는 기술에 대한 소비자를 위한 설명서 및 교육을 제공합니다.

소비자에 대한 액세스 워크플로 요청

콘텐츠를 공유할 때 한 사용자가 링크(URL)를 다른 사용자에게 전달하는 것이 일반적입니다. 받는 사람이 콘텐츠를 보려고 시도하고 액세스 권한이 없다는 것을 알게 되면 액세스 요청 단추를 선택할 수 있습니다. 이 작업은 액세스 요청 워크플로를 시작합니다. 그런 다음 사용자에게 액세스를 원하는 이유를 설명하는 메시지를 제공하라는 메시지가 표시됩니다.

다음에 대한 액세스 요청 워크플로가 있습니다.

  • Power BI 앱에 액세스합니다.
  • 보고서 또는 대시보드와 같은 항목에 액세스합니다.
  • 의미 체계 모델에 대한 액세스. 의미 체계 모델을 검색할 수 있는 경우 액세스 요청 워크플로에 대한 자세한 내용은 콘텐츠 작성자 보안 계획 문서를 참조하세요.

앱 액세스 요청

앱에 대해 제출된 보류 중인 액세스 요청을 알아보는 방법에는 두 가지가 있습니다.

  • 이메일: 앱의 연락처가 이메일 알림을 받습니다. 기본적으로 이 연락처는 앱 게시자입니다. 중요한 앱에 대한 더 나은 지원을 제공하려면 액세스 요청에 신속하게 응답할 수 있는 그룹으로 연락처를 설정하는 것이 좋습니다.
  • 권한 관리 메뉴: 작업 영역 관리자와 구성원은 액세스 요청을 보거나 승인하거나 거부할 수 있습니다. 권한 관리 페이지는 앱 페이지에서 사용할 수 있으며 각 앱에 대해 열 수 있습니다. 이 기능은 기여자가 이 작업 영역의 앱을 업데이트하도록 허용 설정을 사용하도록 설정된 경우에도 작업 영역 기여자가 사용할 수 있습니다.

앱에 대한 보류 중인 액세스 요청은 사용자가 제공한 메시지를 표시합니다. 보류 중인 각 요청은 승인되거나 거부될 수 있습니다. 요청을 승인하도록 선택할 때 앱 대상 그룹을 선택해야 합니다.

다음 스크린샷은 사용자의 보류 중인 액세스 요청을 보여줍니다. 이를 승인하려면 두 앱 대상 그룹 중 하나인 영업 담당자 또는 영업 리더십 중 하나를 선택해야 합니다.

Power BI 서비스 Power BI 앱에 대한 보류 중인 요청의 스크린샷.

앱을 게시하면 콘텐츠와 사용 권한이 동시에 게시됩니다. 앞에서 설명한 대로 콘텐츠 변경 없이 앱 권한만 게시할 수 없습니다. 그러나 한 가지 예외가 있습니다. 보류 중인 액세스 요청(예: 이전 스크린샷에 표시된 요청)을 승인하면 작업 영역에 최신 콘텐츠를 게시하지 않고 권한 변경이 발생합니다.

작업 영역 액세스 요청

작업 영역 액세스 권한은 관리 역할 또는 멤버 역할에 속한 사용자가 부여합니다.

작업 영역을 보려는 사용자는 작업 영역 역할의 멤버가 아닌 경우 액세스 거부 메시지를 받습니다. 작업 영역에 대한 기본 제공 요청 액세스 워크플로가 없으므로 긴밀하게 협력하는 소규모 팀과 비공식 팀에 가장 적합합니다. 이것이 Power BI 앱이 더 큰 팀과 광범위한 콘텐츠 배포 시나리오에 더 적합한 이유 중 하나입니다.

항목별 액세스 요청

보고서 같은 개별 항목에 대해 제출된 보류 중인 액세스 요청을 알아보는 방법에는 두 가지가 있습니다.

  • 이메일: 항목의 연락처가 이메일 알림을 받습니다. 중요한 보고서에 대한 더 나은 지원을 제공하려면 액세스 요청에 신속하게 응답할 수 있는 그룹으로 연락처를 설정하는 것이 좋습니다.
  • 권한 관리 메뉴: 작업 영역 관리자와 멤버는 각 항목에 대한 권한 관리 페이지에 액세스할 수 있습니다. 요청이 보류 중인 액세스를 보거나 승인하거나 거부할 수 있습니다.

그룹을 사용하여 액세스 요청 관리

사용자가 Power BI 항목(예: 보고서 또는 의미 체계 모델) 또는 Power BI 앱에 대한 액세스 요청 양식을 제출하면 개별 사용자에 대한 요청이 제출됩니다. 그러나 많은 대규모 조직에서 내부 보안 정책을 준수하기 위해 그룹을 사용해야 합니다.

실용적인 경우 항상 콘텐츠를 보호하기 위해 개인이 아닌 그룹을 사용하는 것이 좋습니다. 그룹 계획에 대한 자세한 내용은 테넌트 수준 보안 계획 문서를 참조하세요.

개별 사용자 대신 그룹에 대한 액세스를 제공하려는 경우 액세스 요청을 처리하는 콘텐츠 소유자 또는 관리자는 여러 단계로 요청을 완료해야 합니다.

  1. Power BI에서 보류 중인 요청을 거부합니다(개별 사용자와 연결되어 있기 때문).
  2. 현재 프로세스에 따라 요청자를 올바른 그룹에 추가합니다.
  3. 요청자에게 이제 액세스 권한이 있음을 알립니다.

콘텐츠 작성자의 빌드 액세스 요청에 응답하는 방법에 대한 자세한 내용은 작성자에 대한 액세스 요청 워크플로를 참조하세요. 또한 액세스 요청에 양식을 사용하는 방법에 대한 권장 사항도 포함되어 있습니다.

검사 목록 - 액세스 요청 워크플로를 계획할 때 주요 결정과 조치에는 다음이 포함됩니다.

  • 앱 액세스 요청을 처리하는 방법 결정: 앱 액세스 요청을 적시에 처리하는 프로세스가 있는지 확인합니다. 프로세스를 지원하기 위해 앱 연락처가 할당되었는지 확인합니다.
  • 항목별 요청을 처리하는 방법 결정: 액세스 요청을 적시에 처리하는 프로세스가 있는지 확인합니다. 프로세스를 지원하기 위해 각 항목에 연락처가 할당되었는지 확인합니다.
  • 콘텐츠 작성자를 위한 설명서 및 교육에 포함: 콘텐츠 작성자가 액세스 요청을 적시에 처리하는 방법을 이해해야 합니다. 개별 사용자 대신 그룹을 사용해야 하는 경우 요청을 처리하는 방법을 인식하도록 합니다.
  • 설명서 및 학습에 포함: 콘텐츠 작성자를 위한 액세스 요청을 효과적으로 관리하는 방법에 대한 지침을 포함합니다. 또한 액세스 요청 메시지에 포함할 정보에 대한 소비자에 대한 지침을 포함합니다.

소비자 ID에 따라 데이터 보안 적용

데이터 보안을 적용하여 더 적은 수의 의미 체계 모델 및 보고서를 만들 계획을 세울 수 있습니다. 목표는 콘텐츠를 보는 사용자의 ID에 따라 데이터 보안을 적용하는 것입니다.

예를 들어 각 영업 사원이 해당 지역의 판매 결과만 볼 수 있다는 것을 알고 모든 영업 사원(소비자)과 단일 판매 보고서를 공유할 수 있습니다. 이 방법을 사용하면 해당 판매 지역의 영업 사원과 공유해야 하는 지역별로 별도의 보고서를 만드는 복잡성을 피할 수 있습니다.

일부 조직에는 보증된(인증 또는 승격된) 의미 체계 모델 또는 데이터 마트에 대한 특정 요구 사항이 있습니다. 널리 사용되는 데이터의 경우 데이터 보안을 사용해야 할 수도 있습니다.

여러 가지 방법으로 데이터 보안을 수행할 수 있습니다.

  • Power BI 의미 체계 모델: Power BI 데이터 작성자는 RLS(행 수준 보안)OLS(개체 수준 보안)를 적용할 수 있습니다. RLS는 데이터 모델 행을 필터링하는 역할 및 규칙을 정의하는 반면 OLS는 특정 테이블 또는 열에 대한 액세스를 제한합니다. 이러한 정의된 RLS 및 OLS 규칙은 슬라이서 및 필터 선택과 같은 의미 체계 모델 외부에 저장된 참조에는 적용되지 않습니다. RLS 및 OLS 기술 모두 이 섹션의 뒷부분에서 자세히 설명합니다.
  • Analysis Services: 라이브 연결 의미 체계 모델은 AAS(Azure Analysis Services) 또는 SQL Server Analysis Services(SSAS)에서 호스트되는 원격 데이터 모델에 연결할 수 있습니다. 원격 모델은 소비자 ID에 따라 RLS 또는 OLS를 적용할 수 있습니다.
  • 데이터 원본: Azure SQL Database와 같은 일부 데이터 원본은 RLS를 적용할 수 있습니다. 이 경우 Power BI 모델은 다시 정의하지 않고 기존 보안을 활용할 수 있습니다. 이 방법은 원본에 정의된 RLS가 복잡할 때 상당한 이점이 될 수 있습니다. DirectQuery 모델을 개발 및 게시하고 Power BI 서비스 의미 체계 모델의 데이터 원본 자격 증명을 설정하여 SSO(Single Sign-On)를 사용하도록 설정할 수 있습니다. 보고서 소비자가 보고서를 열면 Power BI는 해당 ID를 데이터 원본에 전달합니다. 데이터 원본은 보고서 소비자의 ID를 기준으로 RLS를 적용합니다. Azure SQL 데이터베이스 RLS에 대한 자세한 내용은 이 문서를 참조하세요.

참고 항목

Azure SQL Database와 같은 원본 시스템은 보기와 같은 기술을 사용하여 사용자가 볼 수 있는 범위를 좁힐 수도 있습니다. 이는 유효한 기술이지만 이 섹션의 초점과는 관련이 없습니다.

행 수준 보안

RLS(행 수준 보안)를 사용하면 데이터 모델러가 데이터 하위 집합에 대한 액세스를 제한할 수 있습니다. 일반적으로 일부 보고서 소비자가 다른 판매 지역의 판매 결과와 같은 특정 데이터를 볼 수 없도록 하는 데 사용됩니다.

다른 소비자 그룹을 지원하기 위해 여러 데이터 모델을 만드는 사람을 발견한 경우 RLS가 요구 사항을 충족하는지 확인합니다. 일반적으로 여러 데이터 모델이 아닌 하나의 데이터 모델을 만들고, 테스트하고, 유지 관리하는 것이 좋습니다.

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

RLS를 설정하기 위한 두 가지 단계인 규칙 및 역할 매핑이 있습니다.

RLS 규칙

의미 체계 모델의 경우 데이터 모델러는 하나 이상의 역할을 만들어 Power BI Desktop RLS를 설정할 수 있습니다. 역할은 모델에서 고유한 이름을 가지며 일반적으로 하나 이상의 규칙을 포함합니다. 규칙은 DAX(데이터 분석 식) 필터 식을 사용하여 모델 테이블에 필터를 적용합니다. 기본적으로 모델에는 역할이 없습니다.

Important

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

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

  • 정적 규칙:[Region] = "Midwest" 같은 상수를 참조하는 DAX 식을 사용합니다.
  • 동적 규칙: 상수가 아닌 환경 값을 반환하는 특정 DAX 함수를 사용합니다. 환경 값은 다음 3개의 특정 DAX 함수로부터 반환됩니다. USERNAME, USERPRINCIPALNAMECUSTOMDATA. 동적 규칙 정의는 모델 테이블에 사용자 이름 값이 저장되는 경우 간단하고 효과적입니다. 이를 통해 데이터 기반 RLS 디자인을 적용할 수 있습니다.

RLS 역할 매핑

모델을 Power BI 서비스 게시한 후에는 사용자가 관련 보고서에 액세스하기 전에 역할 매핑을 설정해야 합니다. 역할 매핑에는 Microsoft Entra 보안 개체를 역할에 할당하는 작업이 포함됩니다. 보안 개체는 사용자 계정 또는 보안 그룹일 수 있습니다.

가능하면 역할을 보안 그룹에 매핑하는 것이 좋습니다. 이렇게 하면 매핑이 줄어들고 그룹 소유자가 그룹 멤버 자격 관리를 처리할 수 있습니다.

Microsoft Entra의 보안 계정 정보를 콘텐츠 작성자가 사용할 수 있도록 하는 것이 좋습니다. 한 가지 옵션은 Microsoft Entra ID와 동기화된 상태로 유지되는 데이터를 사용하여 데이터 흐름을 만드는 것입니다. 이렇게 하면 콘텐츠 작성자가 데이터 흐름 데이터를 통합하여 데이터 기반 의미 체계 모델을 생성할 수 있습니다.

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

RLS 사용자 환경

일부 조직에서는 표준 Power BI 권한 외에도 의도적으로 RLS를 보조 보안 계층으로 사용하도록 선택합니다. 보고서 링크를 전체 조직과 공유하는 시나리오를 고려합니다. 보고서를 보는 모든 사용자는 보고서에서 데이터를 볼 수 있도록 RLS 역할에 매핑되어야 합니다. RLS 역할에 매핑되지 않은 경우 데이터가 표시되지 않습니다.

RLS가 있으면 소비자의 기본 환경이 변경됩니다.

  • 의미 체계 모델에 대해 RLS가 정의되지 않은 경우: 의미 체계 모델에 대해 최소 읽기 권한이 있는 작성자와 소비자는 의미 체계 모델의 모든 데이터를 볼 수 있습니다.
  • 의미 체계 모델에 RLS가 정의된 경우: 의미 체계 모델에 대해 오직 읽기 권한만 있는 작성자와 소비자는 허용된 데이터만 볼 수 있습니다(RLS 역할 매핑에 따라).

참고 항목

일부 조직에서는 특히 중요한 데이터가 관련된 경우 RLS를 추가 보안 계층으로 적용합니다. 이러한 이유로 인증된 의미 체계 모델에 대해 RLS가 필요할 수 있습니다. 해당 요구 사항은 의미 체계 모델을 인증하기 전에 내부 검토 및 승인 프로세스를 통해 수행할 수 있습니다.

사용자가 작업 영역 또는 앱에서 보고서를 보는 경우 RLS는 의미 체계 모델 권한에 따라 적용되거나 적용되지 않을 수 있습니다. 이러한 이유로 콘텐츠 소비자와 작성자는 RLS를 적용해야 하는 경우에 기본 의미 체계 모델에 대한 읽기 권한을 보유해야 합니다.

다음은 RLS가 적용되는지 여부를 결정하는 권한 규칙입니다.

  • 사용자에게 의미 체계에 대한 읽기 권한이 있습니다. RLS가 사용자에게 적용됩니다.
  • 사용자에게 의미 체계 모델 읽기 및 빌드 권한이 있는 경우: 사용자에 대해 RLS가 적용됩니다.
  • 사용자에게 의미 체계 모델 쓰기 권한이 있는 경우: RLS가 사용자에게 적용되지 않으므로 의미 체계 모델의 모든 데이터를 볼 수 있습니다. 쓰기 권한은 의미 체계 모델을 편집하는 기능을 제공합니다. 두 가지 방법 중 하나로 권한 부여될 수 있습니다.

RLS가 콘텐츠 작성자에 대해 작동하도록 별도의 작업 영역을 사용하는 방법에 대한 자세한 내용은 관리형 셀프 서비스 BI 사용 시나리오를 참조하세요.

RLS에 대한 자세한 내용은 Power BI 모델 데이터에 대한 액세스 제한을 참조하세요.

데이터 마트에 대한 RLS

Power BI 데이터 마트는 RLS를 적용할 수도 있습니다. 그러나 구현은 다릅니다.

주요 차이점은 데이터 마트에 대한 RLS가 Power BI Desktop에서가 아니라 Power BI 서비스에서 설정된다는 것입니다.

또 다른 차이점은 데이터 마트가 데이터 마트와 연결된 관리형 Azure SQL Database 및 의미 체계 모델과 양쪽에 RLS를 적용한다는 것입니다. 두 계층에서 RLS를 적용하면 일관성과 유연성이 제공됩니다. 의미 체계 모델에 연결하든 관리형 Azure SQL Database에 연결하든 관계없이, 사용자가 데이터를 쿼리하는 방법에 관계없이 동일한 RLS 필터가 적용됩니다.

자세한 내용은 데이터 마트에 대한 RLS를 참조하세요.

개체 수준 보안

OLS(개체 수준 보안)를 통해 데이터 모델러는 특정 테이블 및 열과 관련 메타데이터에 대한 액세스를 제한할 수 있습니다. 일반적으로 OLS를 사용하여 직원 급여와 같은 중요한 열이 특정 사용자에게 표시되지 않도록 합니다. 측정값에 대한 액세스를 제한할 수는 없지만 제한된 열을 참조하는 측정값 자체는 제한됩니다.

직원 테이블의 예를 생각해 보세요. 여기에는 직원 이름 및 전화 번호와 급여를 저장하는 열이 포함되어 있습니다. OLS를 사용하여 고위 인사 담당자와 같은 특정 사용자만 급여 값을 볼 수 있도록 할 수 있습니다. 급여 값을 볼 수 없는 사용자의 경우 해당 열이 없는 것처럼 표시됩니다.

Power BI 보고서 시각적 개체에 급여가 포함된 경우 해당 필드에 액세스할 수 없는 사용자에게 오류 메시지가 표시되므로 주의해야 합니다. 이 메시지는 개체가 존재하지 않는다는 사실을 알립니다. 사용자에게는 보고서가 손상된 것처럼 보입니다.

참고 항목

데이터 모델에서 큐브 뷰를 정의할 수도 있습니다. 큐브 뷰는 보고서 작성자에게 특정 포커스를 제공하는 데 도움이 되는, 모델 개체의 표시 가능한 하위 집합을 정의합니다. 큐브 뷰는 모델 개체에 대한 액세스를 제한하기 위한 것이 아닙니다. 사용자는 표시되지 않는 테이블 또는 열도 열을 쿼리할 수 있습니다. 따라서 큐브 뷰를 보안 기능이 아닌 사용자 편의성으로 고려합니다.

현재 POWER BI DESKTOP OLS를 설정할 인터페이스가 없습니다. 모델을 만들고, 유지 관리하고, 관리하기 위한 타사 도구인 테이블 형식 편집기를 사용할 수 있습니다. 자세한 내용은 고급 데이터 모델 관리 사용 시나리오를 참조하세요.

OLS에 대한 자세한 내용은 Power BI 모델 개체에 대한 액세스 제한을 참조하세요.

검사 목록 - RLS 및 OLS를 계획할 때 주요 의사 결정 및 작업에는 다음이 포함됩니다.

  • RLS 사용 전략 결정: 행 수준 보안을 사용하려는 사용 사례 및 목적을 고려합니다.
  • OLS 사용 전략 결정: 개체 수준 보안을 사용하려는 사용 사례 및 목적을 고려합니다.
  • 인증된 콘텐츠에 대한 요구 사항 고려: 의미 체계 모델을 인증하는 데 필요한 프로세스가 있는 경우 RLS 또는 OLS 사용에 대한 특정 요구 사항을 포함할지 여부를 결정합니다.
  • 사용자 지침 제작 및 게시: RLS 및 OLS 사용에 대한 요구 사항 및 기본 설정을 포함하는 사용자를 위한 설명서를 만듭니다. 중앙 집중식 위치에 있는 경우 사용자 매핑 정보를 가져오는 방법을 설명합니다.
  • 교육 자료 업데이트: 사용자 교육 자료에 RLS 및 OLS에 대한 요구 사항 및 기본 설정에 대한 주요 정보를 포함합니다. 사용자가 데이터 보안 기술을 사용하는 것이 적절한 시기를 이해할 수 있는 예제를 제공합니다.

이 시리즈의 다음 문서에서는 의미 체계 모델, 데이터 흐름, 데이터 마트, 보고서 또는 대시보드 만들기를 담당하는 콘텐츠 작성자를 위한 보안 계획에 대해 알아봅니다.