Skip to main content

Many security considerations involving Azure revolve primarily around network security. Other important security aspects to be considered in the context of Microsoft Fabric are indicated below.

Security in general

In many client projects, there is a requirement for all network traffic to run through an internal company network. It is often forgotten that security has several manifestations. In addition to the network's security, identity is also a crucial parameter in the cloud. Another central question posed to security departments is how to deal with encryption (key management), which is also directly related to aspects of data security. Application security is an essential topic too.



The primary focus is often on network security, insofar as the organization has a large on-premises footprint and/or is subject to industry regulations. Though can be a sensible security approach, it does not make services secure by definition. This is where the current zero-trust security paradigm comes in: No connection is trusted – each invocation, regardless of where it comes from, is checked against central policies.

A need for considering several aspects in discussions about security is thus clear.

A consideration of various topics for a comprehensive security concept can also be applied in the case of Microsoft Fabric.

Fabric security pillars

Some enterprises have a requirement for all network traffic to run through an internal company network. Fulfillment of this requirement can have a major influence on the architecture of a solution and its deployment processes. This also necessitates more operational resources, especially in terms of time and expertise. However, security concepts should not be limited to network security. Other security aspects are also important, especially for Fabric:

 

Possible zero-trust measures for Fabric implementations

Identities and access

Conditional access policies can be used to protect identities and access. They are configured on Entra tenant, and make it possible to deny or approve access based on conditions. The following conditional access policy items can mean particularly high added value for security:

  1. Blocking access from certain countries
  2. Allowing access only from compliant devices
  3. Multi-factor authentication
  4. Blocking high sign-in risks (e.g. access via ToR browser or anonymous VPN)
  5. Blocking high user risks (e.g. credential leak, unusual user behavior exhibiting the same patterns as hacking)

BlogBlogBlogConditional access policies can be implemented for the entire Azure environment, or only for Fabric. Depending on policy, conditional access policies require an Entra license P1 or P2.

Governance and architecture

With respect to authorization, the architecture development process should include a consideration of how workspaces should be apportioned, and which roles need which permissions. The data security concept can be implemented with the use of Purview.  Microsoft Purview is a solution for managing and governing data in an organization. It combines data cataloging, data lineage, data classification and data protection functions to improve control and transparency over the data landscape. It is possible to use Fabric and Purview together, for example, in order to scan data in Fabric. A customer lockbox offers the possibility to restrict Microsoft's data collection for all cloud services. Enabling the feature requires a Microsoft support engineer to submit a just-in-time request to access the environment.

With respect to authorization, the architecture development process should include a careful consideration of how workspaces should be apportioned, and which roles need which permissions. If permissions are conceived at the level of Fabric components (workspaces, lakehouse, etc.), it can make sense here to specify whether certain user groups are only allowed to view certain data. This is closely linked to the topic of row-level security.

Power BI security

Row-level security (RLS) in Power BI is a function which can be used to restrict access to data at the row-level. RLS can thus be used to control which user groups are allowed to see certain data rows in reports or dashboards.

Object-level security determines which tables or columns may be read by users. These aspects should all be included as components in a detailed access concept.

Artifact security relates to reports, dashboards, data records and workspaces. The goal of artifact security is to control access to these elements and ensure that only authorized users have appropriate access.

 

 

Is Fabric security a central topic for your implementation? Are you interested in how a zero-trust strategy can be applied in the case of Fabric?
Talk to us and learn more about b.telligent's «Way to Fabric».

 

Contact us!