Overview
If we compare Cognos, we are talking about
permission for Cognos Framework package, folders, reports, and Row-level
security. While Cognos is centralized, content owned and managed by IT
department, Power BI could be decentralized, content owned and managed by the
business unit. There are 7 different cases we can apply it.
Each of these settings helps you to secure your data
in different ways. There are plenty of web-Resources for these topics. So we'll
add links to these Resources instead of rewriting or copying the content from
there. I hope that this document is helpful to understand the available
security features in Power BI. We will apply for projects case by case.
Use case 1: Database Level Security
We dedicate this security solution to resolving data
source security issues for the production database, especially when allowing
Power BI developers to access the production database.
Use case 2: Privacy levels in Power Query.
When you load data from a relational database, Query folding can
happen. This means that Power Query transformations can be translated into SQL
code and passed to the database. Now
imagine that you get data from two sources. Database contains sensitive data —
for example, personal data about employees or customers. Imagine that you want
to filter data in the files without sensitive data based on data from the database
with sensitive data.
Privacy Levels helps you to manage such scenarios.
For example, when you set the correct privacy Levels on your sources, you can
disable Query folding, and no sensitive data is shared between different
sources.
These References below can help explain this concept
in detail
Microsoft documentation about
Privacy levels
Short explanation about Privacy
Levels by alphabold
Throughout descriptions from Chris
Webb
The overall suggested setting is listed below:
- Public, for data from the Internet
- Organizational, for internal data sources
- Private, for data with Sensitive data
Use case 3: Row-Level-Security (RLS) in Power BI
models
Row-Level-Security (RLS) controls who has access to
which data in the data model. This feature of Power BI is well documented and
understood in the community. It is the same idea as Cognos Row-Level security,
but it could be more flexible to leverage DAX functionality.
These References below can help explain this concept
in detail.
- Dynamic Row Level Security in
Power BI (by PragmaticWorks)
- What Do You Need to Implement
Dynamic Row-Level Security in Power BI? (by RADACAD)
- Dynamic Row Level Security
with Organizational Hierarchy Power BI
Use case 4: Object-Level Security
Explore
how you can hide columns and tables to Power BI users by using the Object Level
Security (OLS) feature released in February 2021.
By
hiding objects, you also hide derived calculations like measures, calculated
columns, and calculated tables. The hidden objects have different effects on
Excel and Power BI reports, though.
These References below can help explain this concept
in detail.
·
Introducing
Power BI Object-level Security
·
Analysis
Services tabular model object-level security | Microsoft Docs
Use case 5: DAX Driven Interface security.
We have implemented this security in Cognos
Framework Manager in Merlin. The overall concept at a high level was documented
with Using
Cognos framework manager parameter maps for data-level security for unbalanced
ragged hierarchy.
As Power BI may use this security differently, we
can't simply mimic the implementation of Cognos. Even though it is a very tough
problem, we can resolve this issue case by case as we can use the most powerful
DAX functionality. Based on our experience with Cognos, we probably use
Row-Level security together with DAX codes to hide and show measures. We will
look into it once we need to resolve it with the Power BI project.
Use case 6: Workspace Security
Each Workspace has four roles:
- Admin:
An Admin can do anything in a Workspace
- Member:
Each Member can add any content and change most settings in a Workspace. A
Member can add other Users with the Member Role and add Contributors and
Viewers.
- Contributor:
Members of this role can add Reports and Datasets to a Workspace with the
Contributor role. But they're not allowed to change a Power BI App, as
long an Admin doesn't delegate this permission to the user.
- Viewer:
Viewer exists when you have a Premium Capacity. Viewers can access any
content, even without a Pro License. But they cannot change anything.
Each user with access to a Workspace can share
Artifacts with other not Workspace members. Possible permissions include
Building permission on a data set and sharing reports.
Power BI Apps are somewhat outside of a Workspace
and aren't controlled by Workspace security. However, you can configure access
to your Power App, which goes beyond the users with access to your Workspace.
Use case 7: Sensitivity Labels.
Sensitivity Label is a feature controlled by Azure
and Microsoft 365 admins. An Admin can enable Data Protection and create
Sensitivity labels in your organization to control enforced encryption and to
limit capabilities to distribute information inside and outside your tenant.
You can add a Sensitivity label on a Power BI report
as soon as the admin configures labels and policies.
For example, Sensitivity labels can restrict the
distribution capability in Power BI reports.
One of the great features of Sensitivity labels is
that when you mark Power BI Report with a label, the same label is applied to
an Office file created with the Export function in Power BI.
Go to the Microsoft documentation about Sensitivity labels in Power BI to
learn more about it.
No comments:
Post a Comment