top of page

Microsoft Fabric Security Features

Microsoft Fabric, a critical component of Microsoft's cloud infrastructure, comes equipped with a robust set of security features designed to safeguard data, protect against threats, and ensure the integrity of services hosted within its framework. These security measures are integral in maintaining the trust and confidentiality of both customer data and Microsoft's proprietary systems.


In this discussion, we will explore the array of security features that Microsoft Fabric offers, highlighting how they contribute to a secure and resilient cloud computing environment.


Read: How to Enable Microsoft Fabric?


Table of Contents:
Microsoft Fabric Conditional Access Feature
How does Conditional Access Work?
Conditional Access Signals
Common Decisions
How to Create a Conditional Access Policy
Microsoft Fabric Resiliency Feature
Microsoft Fabric Lockbox Feature
Lockbox
Customer Lockbox
How to enable Customer Lockbox
Logs
How to make a Microsoft-initiated Customer Lockbox request?
Microsoft Fabric Service Tags Feature
Service Tags
How to use Service Tags
Enable a Public Endpoint in the SQL Managed Instance
Create a Network Security Group Rule
Enter the credentials in Microsoft Fabric
Conclusion

Feature 1: Microsoft Fabric Conditional Access Feature

Conditional Access policies are essentially if-then statements. For example, if a user wants to access an application or service like Microsoft 365, they must perform multifactor authentication to gain access. These policies are enforced after first-factor authentication is completed and are not intended to be an organization’s first line of defense for scenarios like denial-of-service (DoS) attacks.


How does Conditional Access work?

Conditional Access is a capability of Azure AD that enables you to enforce controls on the access to apps in your environment based on specific conditions from a central location.

Microsoft Fabric Security Feature - Conditional Access

The process involves three main components: Signals, Decisions, and Enforcement.

  1. Signals: Information used to make decisions. This could be details about the user, device, location, or app.

  2. Decisions: The responses defined by the organization based on the signals. This could involve allowing access, denying access, or challenging the user with Multi-Factor Authentication (MFA), device enrollment, or password change.

  3. Enforcement: Once decisions are made based on the signals, they are enforced as policies.

Policies are the combination of Signals, Decisions, and Enforcement. They define the rules for how users access applications based on the conditions specified.


Multiple Conditional Access policies may apply to an individual user at any time. If this happens, all policies that apply must be satisfied. For example, if one policy requires MFA and another requires a compliant device, you must complete MFA and use a compliant device.


The enforcement of all policies occurs in two phases:


Phase 1 - Collect session details: Gather session details like network location and device identity necessary for policy evaluation.


Phase 2 - Enforcement: Use the session details gathered in phase 1 to identify any requirements that haven’t been met. If there’s a policy configured to block access with the block grant control, enforcement will stop here and the user will be blocked. The user will be prompted to complete more grant control requirements that weren’t satisfied during phase 1 until policy is satisfied.


Once all grant controls have been satisfied, apply session controls (App Enforced, Microsoft Defender for Cloud Apps, and token Lifetime).


Conditional Access Signals

Conditional Access in Azure Active Directory (Azure AD) uses various signals to make access decisions. These signals include:

  1. User or Group Membership: Policies can be targeted to specific users and groups, giving administrators fine-grained control over access.

  2. IP Location Information: Organizations can create trusted IP address ranges that can be used when making policy decisions. Administrators can specify entire countries/regions IP ranges to block or allow traffic from.

  3. Device: Users with devices of specific platforms or marked with a specific state can be used when enforcing Conditional Access policies. Use filters for devices to target policies to specific devices like privileged access workstations.

  4. Application: Users attempting to access specific applications can trigger different Conditional Access policies.

  5. Real-time and Calculated Risk Detection: Signals integration with Microsoft Entra ID Protection allows Conditional Access policies to identify and remediate risky users and sign-in behavior.

  6. Microsoft Defender for Cloud Apps: Enables user application access and sessions to be monitored and controlled in real time. This integration increases visibility and control over access to and activities done within your cloud environment.

These signals are used in combination with the conditions set by the organization to enforce access controls and protect the organization’s assets.


Common Decisions

Common decisions that you can make based on these signals:


1. Blocking access: For organizations with a conservative cloud migration approach, the block all policy is an option that can be used. Misconfiguration of a block policy can lead to organizations being locked out. Policies like these can have unintended side effects. Proper testing and validation are vital before enabling. Administrators should utilize tools such as Conditional Access report-only mode and the What If tool in Conditional Access when making changes.


User exclusions: Conditional Access policies are powerful tools, we recommend excluding the following accounts from your policies:

  • Emergency access or break-glass accounts to prevent tenant-wide account lockout.

  • Service accounts and service principals, such as the Azure AD Connect Sync Account.

These policies are put into Report-only mode to start so administrators can determine the impact they’ll have on existing users. When administrators are comfortable that the policies apply as they intend, they can switch them to On.


2. Granting access: If the conditions specified in the policy are met, you can choose to grant access. This means that the user will be able to access the application or service they are trying to reach.


Administrators can choose to enforce one or more controls when granting access. These controls include:

  • Require multifactor authentication (Azure AD Multifactor Authentication)

  • Require authentication strength

  • Require device to be marked as compliant (Microsoft Intune)

  • Require hybrid Azure AD joined device

  • Require approved client app

  • Require app protection policy

  • Require password change

When administrators choose to combine these options, they can use the following methods:

  • Require all the selected controls (control and control)

  • Require one of the selected controls (control or control)

By default, Conditional Access requires all selected controls


How to Create a Conditional Access Policy

Here we will guide you on how you can create policies that react to sign-in events and require additional actions before a user is granted access.


Conditional Access is the recommended way to enable and use Azure AD Multi-Factor Authentication. This is because Conditional Access allows you to target specific users, groups, and apps with MFA requirements. This means that you can require MFA for high-risk access scenarios, such as signing in from outside of your corporate network or accessing sensitive data.


Multi-Factor Authentication (MFA) is a security measure that requires users to provide two or more pieces of evidence to verify their identity. This can be a password, a code from their phone, or a fingerprint.


Consider the image below that illustrates how conditional access will work to secure the sign-in process.

Microsoft Fabric Security Feature - sign-in process

In the above diagram:

  1. The user attempts to sign in to an Azure application or service.

  2. Azure AD evaluates the user's sign-in request against the Conditional Access policies that are assigned to the user and the application or service.

  3. If the user meets all of the conditions of a Conditional Access policy, Azure AD grants access to the application or service.

  4. If the user does not meet all of the conditions of a Conditional Access policy, Azure AD may require the user to take additional actions before granting access, such as providing MFA.

  5. If the user is unable to meet the requirements of the Conditional Access policy, Azure AD denies access to the application or service.

This will protect the organization from unauthorized access to your cloud resources, while also providing the right levels of access to the users who need it.


Steps to create a Conditional Access Policy to secure sign-ins to the Azure Portal

Here is an example of a basic Conditional Access policy to requires MFA for all sign-ins to the Azure portal:


STEP 1: Log in to the Azure Portal, account with global administrator permissions.

To create a Conditional Access policy, you must have an account with global administrator permission in Azure Active Directory (Azure AD). This is because Conditional Access policies can be applied to all users and resources in your Azure AD tenant.


STEP 2: Now, search and select "Azure Active Directory". From the left side panel, select "Security".


STEP 3: Now, select Conditional Access => + New Policy => Create new policy.

Microsoft Fabric Security Feature - conditional access 1

STEP 4: Enter the name for the policy. For example, MFA Pilot.


STEP 5: Under the "Assignments" section, select the current value for user or workload identities.

Microsoft Fabric Security Feature - conditional access 2


STEP 6: Now, you have to select "User and groups" under "What does this policy apply to?"


STEP 7: Under Include, choose "users and groups", and then select Users and groups.

Microsoft Fabric Security Feature - conditional access 3

STEP 8: Browse for and select your Azure AD group, such as MFA-Test-Group, then choose Select.


Microsoft Fabric Security Feature - conditional access 4

STEP 9: Under Access controls, select Grant then select Grant access.

Microsoft Fabric Security Feature - conditional access 5


STEP 10: Select Require multifactor authentication and click "Select".

Microsoft Fabric Security Feature - conditional access 6


STEP 11: Now, you have to enable the policy. Under "Enable policy", select "ON".

Microsoft Fabric Security Feature - conditional 6

STEP 12: Click Create to save the conditional access policy.


Features 2: Microsoft Fabric Resiliency Feature

Resiliency in Microsoft Fabric is about ensuring the reliability and availability of services, even in the face of infrastructure failures or disasters. Here are some key aspects of resiliency in Microsoft Fabric:


Availability Zone Support: Azure availability zones are at least three physically separate groups of data centers within each Azure region. Each zone is equipped with independent power, cooling, and networking infrastructure. In case of a local zone failure, regional services, capacity, and high availability are supported by the remaining two zones.


Fault Tolerance: To prepare for availability zone failure, customers should over-provision the capacity of service to ensure that the solution can tolerate ⅓ loss of capacity and continue to function without degraded performance during zone-wide outages.


Business Continuity and Disaster Recovery (BCDR): Microsoft Fabric ensures that your data is recoverable in cases of infrastructure failures or disasters.


Zone-Redundant and Zonal Services: Azure availability zone-enabled services can be either zone redundant, with automatic replication across zones, or zonal, with instances pinned to a specific zone. You can also combine these approaches.


Workload Management: The system is fault-tolerant and if a node becomes unhealthy, operations executing on the node are redistributed to healthy nodes for completion.


Feature 3: Microsoft Fabric Lockbox Feature

The Lockbox is a security feature provided by Microsoft to give you more control over how their engineers access your data when they need to troubleshoot issues with Microsoft Fabric services. This feature helps ensure the security and privacy of your data during such support requests.


Customer Lockbox is a Microsoft service that allows customers to control and audit access to their data by Microsoft engineers. Customer Lockbox is an important tool for protecting customer data. It allows customers to control who has access to their data and for how long. It also provides customers with auditing information so that they can track who has accessed their data and for what purpose.


Here are some of the benefits of using Customer Lockbox:

  • It gives customers control over who has access to their data.

  • It provides auditing information so that customers can track who has accessed their data and for what purpose.

  • It helps to protect customer data from unauthorized access.

  • It helps to comply with data privacy regulations.


Difference between Customer Lockbox and Lockbox

Here is a table that summarizes the key differences between Customer Lockbox and Lockbox:

Feature

Customer Lockbox

Lockbox

Initiated by

Customer

Microsoft Engineer

Requires customer approval?

Yes

No

Purpose

To give customers control over who has access to their data and for how long


How to Enable Customer Lockbox?

To enable "Customer Lockbox" for Microsoft Fabric, you need to follow these steps:


STEP 1: Open the Azure portal


STEP 2: Navigate to the section or option labeled "Customer Lockbox for Microsoft Azure." This is where you can configure the Lockbox feature.


STEP 3: Inside the Customer Lockbox settings, there should be an "Administration" tab or section. Within this section, you can find an option to enable Customer Lockbox. Click on it to enable the feature.

Enable customer lockbox in microsoft fabric

Once you've enabled Customer Lockbox, it starts working to ensure that Microsoft engineers can access your data only when necessary and with your permission. This helps maintain a high level of security and transparency in managing your data.


Logs

Logs in Microsoft Fabric Customer Lockbox are records of all access requests and approvals. This includes the following information:

  • The date and time of the request

  • The name of the Microsoft engineer requesting access

  • The resources that the Microsoft engineer is requesting access to

  • The justification for the request

  • The decision of the customer approver (approve or deny)

  • The date and time of the approval (if applicable)

Customers can view their Customer Lockbox logs in the Azure portal. To do this, they must go to the Customer Lockbox page and then click on the Logs tab.


Customer Lockbox logs are retained for one year. After one year, the logs are automatically deleted.


There are two types of logs in Microsoft Fabric Lockbox:

  1. Activity Logs

  2. Audit Logs

Activity Logs: These logs are available through the Azure Monitor activity log. They provide a record of various actions related to Customer Lockbox, such as

  • Deny Lockbox Request

  • Create Lockbox Request

  • Approve Lockbox Request

  • Lockbox Request Expiry

Audit Logs: You can access audit logs from the Microsoft Purview compliance portal. These logs offer a more comprehensive view of the activities related to Customer Lockbox. You can view these audit logs in the admin portal, which allows for a deeper analysis and review of security-related events.


How to make a Microsoft-initiated Customer Lockbox request?

When a Microsoft engineer needs direct access to customer data to troubleshoot an issue, they must submit a Customer Lockbox request. This request is reviewed by Microsoft approvers and the customer. If the customer approves the request, the Microsoft engineer is granted access to the customer's data for a limited period of time.


Here are the steps involved in a Microsoft-initiated Customer Lockbox request for the Microsoft Fabric service:

  1. A Microsoft engineer submits a Customer Lockbox request for the Microsoft Fabric service.

  2. The request is reviewed by Microsoft approvers, who may require additional information from the engineer.

  3. The Azure AD Global Administrator receives a pending access request notification email from Microsoft.

  4. The Azure AD Global Administrator clicks on the link in the email to view the Customer Lockbox request in the Azure portal.

  5. The Azure AD Global Administrator reviews the request and enters a justification for their decision.

  6. The Azure AD Global Administrator clicks on the Approve button to grant access to the Microsoft engineer for a default period of eight hours.

  7. The Azure AD Global Administrator clicks on the Deny button to reject the request.


Feature 4: Microsoft Fabric Service Tags Feature

The service tag in Microsoft Fabric allows you to define groups of IP addresses that represent Azure services. This can be useful for simplifying network security rules and improving performance.


For example, you can create a service tag for the Power BI service. This service tag would include all of the IP addresses that are used by the Power BI service. You could then use this service tag in a network security rule to allow traffic from the Power BI service to your Azure SQL Database instance.


The service tag feature is important because it can help you to:

  • Improve security: By using service tags in your network security rules, you can reduce the risk of accidentally blocking legitimate traffic.

  • Simplify network administration: Service tags can help you to simplify your network security rules and make them easier to manage.

  • Improve performance: By using service tags, you can avoid the need to manually update your network security rules every time the IP addresses of an Azure service change.


Steps to Enable Service Tags in Microsoft Fabric:

Here are the steps to enable the service tag feature in Microsoft Fabric:


STEP 1: Enable a Public Endpoint in the SQL Managed Instance

Follow the below steps to enable the public endpoint:


STEP 1: Go to the Azure Portal and navigate to SQL Managed Instance.


STEP 2: In the left panel, select "Networking".


STEP 3: Here, enable the "Public endpoint(data)" and then set the "Minimum TLS version" to 1.2.


Enable Public endpoint in SQL Managed Instance

STEP 4: Click "Save" to save the settings.


STEP 2: Create a Network Security Group Rule

This step is about setting up a rule that controls who can access a particular service in your Azure cloud environment. Specifically, it's about allowing inbound traffic (data coming into your Azure resources) for a service called Power BI. This service allows you to visualize and analyze data.


Here you need to create a rule in your Azure Network Security Group (NSG) to allow inbound traffic from the Power BI service to your SQL Managed Instance (SQL MI). You can do this using the command-line interface (CLI) or PowerShell.


Think of NSG as a virtual firewall that guards your resources in the cloud. This rule tells the firewall to allow incoming data from Power BI.


Create a rule using the Command-line-interface (CLI)

The CLI script example provided below shows how to create an NSG rule with the following properties:

  • Name: allow_inbound_PowerBI

  • Priority: 400

  • Source address prefixes: PowerBI service tag

  • Destination address prefixes: * (all)

  • Destination port ranges: 3342 (the public endpoint port defined in step 1)

  • Direction: Inbound

  • Access: Allow

  • Protocol: tcp

  • Description: Allow PowerBI Access to SQL MI for Direct Query or Data Refresh.

Here is the step-by-step guide to creating a security group rule:


STEP 1: Log in to Azure: Log into your Azure Account.


STEP 2: Select your subscription: If you have multiple forts (subscriptions), you need to tell Azure which one you're working with.


STEP 3: Create a rule for your subscription: You're going to create a new rule for your subscription. This rule will say, "Allow Power BI to enter."


STEP 4: Specify some details for the rule:

  • Resource Group (RG): Name of the area where your subscription is located.

  • Network Security Group (NSG): List of rules that control who can enter your fortress.

  • Rule Name: Give your rule a name, like "allow_inbound_PowerBI."

  • Priority: This is like telling Azure how important this rule is compared to other rules. Lower numbers mean higher importance.

  • Service Tag: Specify that you want to allow Power BI.

  • Port: Specific entrance gate (door) that Power BI will use.

  • Direction: Specify that Power BI can enter your fortress from outside.

  • Access Type: Allow Power BI to enter.

  • Protocol: Specify the way Power BI communicates with your fortress (like speaking a certain language).

  • Description: Give a brief explanation of what this rule does.

STEP 5: Create the rule: With all these details, you tell Azure to create the rule that allows Power BI to enter your fortress.

#login to azure
az login

#set subscription that contains SQL MI instance
$subname = "mysubscriptionname"
az account set --subscription $subname

#set NSG rule for inbound PowerBI traffic

#update $RG to your resource group name
$rg = 'myresourcegroup'

#update $nsg to your Network Security Group name
$nsg = 'nsgresourcename'

# Name the NSG rule
$rule = 'allow_inbound_PowerBI'

#set the priority - this must be higher priority (lower number) than the deny_all_inbound rule
$priority = 400

#specifiy the service tag to use
$servicetag = 'PowerBI'

#specify the public endpoint port defined in step 1
$port = 3342

#set the rule to inbound direction
$direction = 'Inbound'

#set the access type to "Allow"
$access = 'Allow'

#Set the protocol as TCP
$protocol = 'tcp'

#Provide a description for the rule
$desc = 'Allow PowerBI Access to SQL MI for Direct Query or Data Refresh.'

#create the NSG rule
az network nsg rule create -g $rg \
--nsg-name $nsg -n $rule --priority $priority \
--source-address-prefixes $servicetag --destination-address-prefixes '*' \
--destination-port-ranges $port --direction $direction --access $access \
--protocol $protocol --description $desc

Create a rule using PowerShell

Another way to create a Network Security Group Rule is using PowerShell Script.

#login to azure
Login-AzAccount

#get your subscription ID
Get-AzSubscription

#####Script to create Network Security Group Rule
###

#enter your subscription ID
Set-AzContext -SubscriptionId "yoursubscriptionID"

#Provide the resource group for your Network Security Group
$RGname="yourRG"

#Enter the port for the SQL Managed Instance Public Endpoint
$port=3342

#name the NSG rule
$rulename="allow_inbound_PowerBI"

#provide the name of the Network Security Group to add the rule to
$nsgname="yourNSG"

#set direction to inbound to allow PowerBI to access SQL MI
$direction ="Inbound"

#set the priority of the rule. Priority must be higher (ie. lower number) than the deny_all_inbound (4096)
$priority=400

#set the service tags for the source to \u201cPowerBI\u201d
$serviceTag = "PowerBI"

# Get the NSG resource
$nsg = Get-AzNetworkSecurityGroup -Name $nsgname -ResourceGroupName $RGname

# Add the inbound security rule.
$nsg | Add-AzNetworkSecurityRuleConfig -Name $rulename -Description "Allow app port" -Access Allow `
    -Protocol * -Direction $direction -Priority $priority -SourceAddressPrefix $serviceTag -SourcePortRange * `
    -DestinationAddressPrefix * -DestinationPortRange $port
    
# Update the NSG.
$nsg | Set-AzNetworkSecurityGroup

In the above code:


STEP 1: Log in to Azure: Log into your Azure account.


STEP 2: Get your subscription ID: You need to specify which part of Azure (subscription) you're working with.


STEP 3: Set the context: You tell Azure which subscription you want to work with by providing its unique ID.


STEP 4: Specify some details:

  • $RGname: This is like telling Azure the name of the area where your resource is located. Think of it as the neighborhood your house is in.

  • $port: This is like specifying the specific entrance (port) where Power BI will enter your resource.

  • $rulename: You give a name to the rule you're creating, so you can identify it later.

  • $nsgname: This is the name of the Network Security Group you want to add the rule to. Imagine it as a list of rules for your resource's security.

  • $direction: You specify that you want to allow Power BI to come into your resource (inbound).

  • $priority: This is like saying how important this rule is compared to other rules. Smaller numbers mean higher importance.

  • $serviceTag: You specify that you're allowing access to Power BI.

STEP 5: Get the NSG resource: You tell Azure to find the Network Security Group (NSG) you want to add the rule to. Think of this as finding the specific rulebook for your resource's security.


STEP 6: Add the inbound security rule: You're creating the rule that allows Power BI to enter your resource.


STEP 7: Update the NSG: After creating the rule, you need to update the rulebook (NSG) to include this new rule. It's like adding a new page to the rulebook.


STEP 3: Enter the Credentials in Microsoft Fabric

To enter the credentials in Microsoft Fabric, follow these steps:

  1. Go to the Azure portal.

  2. Click SQL Managed Instances.

  3. Click the name of your SQL MI.

  4. Click Networking.

  5. Under Microsoft Fabric, click Connect.

  6. Enter the credentials for your Azure Active Directory account.

  7. Click Connect.

Once you have entered the credentials, Power BI will be able to access your SQL MI through the Microsoft Fabric.


Conclusion

Microsoft Fabric's security features, including Conditional Access, Resiliency, Lockbox, and Service Tags, work together to fortify data protection, ensure service continuity, enhance access control, and simplify network security management in the cloud. These features collectively create a robust and secure environment for Azure users, supporting trust, privacy, and compliance requirements.

0 comments
bottom of page