Forum Discussion

frithjof_v's avatar
frithjof_v
Community Champion
2 years ago
Solved

Privacy levels

Hi,   I have some questions regarding Data Privacy levels.   If I understand correctly, the data privacy levels work like this:   Technically it is up to me (i.e. the semantic model author), as...
  • AmiraBedh's avatar
    2 years ago

    Is there any technical restriction on setting the privacy level for any data source?

     Technically, you can set the privacy level of any data source to Private, Organizational, or Public, regardless of the nature or ownership of the data. This flexibility means that even illogical settings can be applied, such as defining a top-secret company server as Public or an open web source as Private. So you need to choose the appropriate level, considering the sensitivity and potential business risks.

     What are the implications (or risks) of setting a Data Privacy level?

    In my opinion, the primary implication of setting privacy levels in Power BI is related to data leakage through query folding.  Let me explain it one by one :
    - Public Data Sources: Data can be used as input in query folding to other Public, Organizational, or Private data sources.
    - Organizational Data Sources: Data can be used as input in query folding to other Organizational or Private data sources.
    - Private Data Sources: Data cannot be used as input in query folding to any other data sources.

    The main risk here is for data leakage when data from less sensitive sources (Public or Organizational) is used in queries involving more sensitive data (Private).

     

    Are there any other risks affected by data Privacy levels, besides the risk of data leakage through query folding?

    The primary concern remains indeed data leakage through query folding. The documentation mentions preventing undesirable data transfers, which essentially translates to controlling how data from different sources interacts within queries. Other security measures like workspace access, sharing permissions, Row-Level Security (RLS), and Object-Level Security (OLS) manage visibility and access control outside the context of query folding.

     

    What does "visibility" mean in practical terms regarding data privacy levels?

    The term "visibility" in the context of data privacy levels might be misleading. It seems to refer to the control over data leakage during query folding rather than direct user access. Data visibility to users is managed through workspace access, sharing settings, RLS, and OLS. Thus, the term "visibility" in the documentation should ideally be interpreted as the potential exposure of data during query processing rather than user access control.

     

    Why does the documentation mention that data protection occurs "also" when a query uses query folding?

    I totally agree that the documentation use of "also" might indeed be misleading. Query folding is the primary mechanism through which data privacy levels protect against data leakage. The phrase "also occur when a query uses query folding" should be clarified to indicate that query folding is the primary, if not the only, context in which privacy levels play a protective role. This section of the documentation could benefit from clearer wording to avoid confusion.

  • frithjof_v's avatar
    2 years ago

    I also think in the case of an external data source (i.e. source which doesn't contain your organization's data and you don't want to leak your organizational data to it) then you should NOT set Organizational or Private level for that data source, because if you set an external source as Organizational or Private, you might leak data from your other (actual) Organizational data sources into the external source which has been wrongfully labelled as Private or Organizational.

     

    So external sources should probably always be selected as Public, if that made sense?

     

     

    I think we need to remember two things:

     

    - using a too "relaxed" setting can lead to unwanted data exposure.

    If a source which should be labelled as Private, gets wrongfully labelled as Organizational, it can cause unwanted data exposure of that sensitive data into other organizational data systems.

    If a source which should be labelled as Private or Organizational, gets wrongfully labelled as Public, it can also cause unwanted exposure of that sensitive or internal data to external systems.

     

    - using a too "strict" setting can also lead to unwanted data exposure.

    If an (external) source which should be labelled as Public, gets wrongfully labelled as Organizational or Private, then data from other sources which are rightfully labelled as Organizational can be leaked to that external system. Because when we label a data source as Organizational or Private, we say that it's okay to send data to this data source from our other Organizational and Public sources (through query folding).

     

    If a source which should be labelled as Organizational, gets wrongfully labelled as Private, I don't think this introduces any added risk of data leakage. But it can lead to bad performance in Power Query.

     

     

    Another aspect of it: before doing some kind of mix of data from different sources in Power Query (i.e. merging data, using data from one source to filter another source, etc.), remember to check the privacy level setting of each data source.