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.
Table of Contents
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 Implementation
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:
Blocking access from certain countries
Allowing access only from compliant devices
Multi-factor authentication
Blocking high sign-in risks (e.g. access via ToR browser or anonymous VPN)
Blocking high user risks (e.g. credential leak, unusual user behavior exhibiting the same patterns as hacking)
Conditional 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».
Do you want to replace the IoT core with a multi-cloud solution and utilise the benefits of other IoT services from Azure or Amazon Web Services? Then get in touch with us and we will support you in the implementation with our expertise and the b.telligent partner network.
Many users of Google's IoT Core are currently looking for a successor to this service which will expire in August 2023. This blog post shows how Stackable's data platform can be used to create a highly scalable open-source alternative to Google's IoT Core.
How can I integrate data sources that are secured via private endpoints into Fabric? How do I deal with Azure Data Lakes behind a firewall? This blog post shows the possibilities which Fabric Nativ offers
Lack of resources or technical challenges are often hurdles to establish the value and viability of IoT use cases, and present them later to project sponsors. Even for simple IoT use cases, sometimes weeks instead of days may be needed to produce tangible results. In this blog, we’ll present our IoT kick-starter platform that makes it possible to technically assess simple IoT use cases within a few days.