Fabric Security & User Account Impersonation

Introduction

I’ve been experimenting with Fabric for more than a year now. It’s an excellent extension of Power BI, and I’m excited to see where it goes. More competition in this space is always a plus!

When I explore new data and AI products, after creating a few pipelines and getting a feel for the product, I turn to security and DevOps/DataOps features. One issue I found led me to file a report with Microsoft’s Security Response Center and resulted in a security fix as well as changes to the documentation to highlight the risks of developing in a shared workspace.

Summary

For those short on time, here is a proposed model for developing with Fabric

Key notes:

• Ensure all developers have their own individual workspaces for development; this prevents user impersonation.
• Ensure developers don’t deploy directly into shared environments; this prevents outages if a Developer’s account is disabled or password policies change.
• When deploying into shared environments, use a shared user account until such time as service accounts are supported.
• Use source control to manage code contributions.
• Ensure there is a review process for code before it is deployed into shared workspaces.
• Optionally split your data sources into other workspaces and lock them down to save costs - notebooks, pipelines and other resources that allow execution of code are the most risky vectors for user impersonation.

The issue

While testing Fabric’s automation capabilities, I found that in some situations certain Fabric resources enable the execution of code under another user’s identity. This could be used to impersonate another user and access resources they have access to. This could be a security risk if a user has more permissions than another user such as a HR user that could have access to sensitive employee data. There are also auditing implications as malicious actions will look like they have been applied by the impersonated user.

This expands into external resources outside of Fabric that Fabric can natively communicate with, like Key Vault and Azure Storage, all without needing the user to know credentials or pass MFA prompts. This could be used to exfiltrate data or perform other malicious actions on behalf of the impersonated user.

So it is clear there is an issue when sharing an environment where developers (or any other users with permissions) can cause to be executed by others that hasn’t been reviewed as part of a proper DevOps lifecycle. This post contains a proposal for a secure development model that can be used to mitigate this issue and the potential other security issues that may arise when developing in a shared Fabric workspace. This model is based on the current state of Fabric and may change as new features are added.

Reporting a security issue to Microsoft

I discovered this issue in late May 2024 and reported it to MSRC in June, together with steps to reproduce it. After some discussion, they accepted my submission, updated the documentation to emphasize the risks of a shared workspace, and introduced UX changes. While I’ve worked with the MSRC team before on other vulnerabilities, I’m still impressed each time with the speed and professionalism compared to other vendors - they’re always a pleasure to work with, and their bounty program is pretty good too!

With a confirmed risk in using shared workspaces, this then posed the question - since developing in the same workspace can have security implications, how can you still collaborate? While manually handling workspaces would make it hard to keep code in sync, Fabric supports source control to help out here. By assigning each developer their own workspace, you reduce the chance of malicious code being able to be run to impersonate another user and can still leverage modern source control features to review, audit and safely deploy code to your production environments.

Proposal for secure Fabric development

In order to securely develop in Fabric, I believe user isolation is important to implement. I’ve outlined a proposal for architecting workspaces in Fabric. I’d suggest double checking documentation and to test a deployment in a sandbox to ensure that this method will work for you. I’d plan to revise this further when more features come out that will further simplify or secure this process.

The approach below may not work for all teams, so set up a sandbox and ensure it meets your requirements around cost, security, and the known limitations when using source control.

Setup and Configuration

• First assume we have three workspaces; we’ll call them “Development”, “Test” and “Production” and attach a Fabric capacity to them. For our production workspace we’ll ensure that our capacity is separate so that development workloads do not impact production workloads.
• We’ve got two users (1 and 2) and a deployment lead (User 3).
• We’re also going to use Development Pipelines to deploy our resources between environments.

The issues with this flow

• Because our developers share a single workspace, we face potential security and auditing issues. These risks worsen if User 1 has more permissions than User 2.
• User 1 can easily set up resources that User 2 could leverage under User 1’s identity, including accessing external resources like Key Vault, Azure Management and Storage Accounts
• Another issue with this approach is that resources are owned by the user that deploys the resources; this may cause issues if those accounts are disabled (e.g: Leaving the company or being locked out due to password failures).
  • For the example above, User 1 and 2 will own whatever resources they deploy in the Development environment, User 1 will own the resources in Test, and User 3 will own the resources in production.
• We must let both users contribute code safely, without providing them access to each other’s development environments. This approach also ensures a more robust deployment pipeline.

Resolving security issues in Development by ensuring users only have permissions to deploy resources in their own workspace

• When User 1 and User 2 branch off into their own workspaces - we ensure that they do not have the ability to change or execute each other’s code in each other’s respective workspace, but they can still contribute by using the Source Control functionality to check in code to “main”.
• This can be done either by having a single workspace per developer with Admin permissions on that workspace to configure how they see fit and switching branches, or by enabling for developers the ability to create workspaces on a per-branch-per-user basis if short lived workspaces are preferred.
• As an added bonus, using source control also provides code review and disaster recovery functionality as we can easily roll back and ensure all code going to production is reviewed as part of a standard pull request process.

Keep things secure past development

• Once code is checked into main, the release manager can log into a special user account used for automatically running workloads to grab the latest code from main and deploy it to the test account. It is important to know that any users with contribution rights to this workspace will have “effective” permissions to this special user account, so design your permissions accordingly.
  • Note that service accounts are not supported at this time - they have to be interactive, but this is scheduled for a future release.
  • I’ve seen 2FA causing availability issues as tokens expire, so this may be something you have to consider turning off if you run into token expiration errors (e.g: AADSTS50076).
• Once everything looks well in Test, we can use Fabric’s deployment pipelines to deploy to Production, or have a branch-per environment and just pull the latest changes into each environment when you are happy with the changes.

All together now

• We’ve successfully managed to deploy code in what I would consider to a more secure way!

Looking forward

While there are limitations to this method, especially as some tools don’t support source control and Microsoft could stand to invest a bit more in shared experiences - I’m optimistic for the future. It’s good to see too that Fabric is adopting open data standards that push back against those “viral” data tools that end up locking multiple departments into a single vendor.

In future I’d love to see Microsoft supporting an option to have a managed workspace service account that works in a way where all Fabric resources are run under that context for any scheduled workloads. This would remove the need for creating specific service accounts for deployment and make it harder for attackers to impersonate interactive users.