It was a second-latte-kind-of-day for health claims processor, Jane. Unknowingly, as she was waiting for the barista to work his magic, Nosy Pete looked over at her laptop screen five feet away and saw that his second cousin’s brother-in-law’s nephew’s ex-girlfriend’s health record was displayed on a Power BI dashboard. Suddenly, he had some juicy news for the gossip train.
Of course, personal health information (PHI) getting into the wrong hands has much greater danger than simply gossip fuel. This is a very real issue. In this bring-your-own-device world, PHI and all kinds of other sensitive data can easily get into the wrong hands. (See our security solutions)
“How can we restrict Power BI data to only our network?”
Recently, a health provider approached us on how to handle this situation. Their issue was, “How can we restrict the data in our Power BI service environment to only our trusted network?” The caveat being they didn’t want to block everyone from using Power BI externally. A group of associates in this client’s executive level would still to need access to this data on external networks. The customer asked us to identify a way to restrict Power BI service usage to their trusted network except for the group of executive level associates.
This is a common request in today’s data-driven world. Fortunately, we have developed a solution (that I outline below) to meet this issue through Microsoft’s Conditional Access.
(Though this solution talks about healthcare, it can be applied to other scenarios where you need to control access to sensitive data.)
Conditional Access
Conditional Access (CA) allows the creation of very configurable policies that allow you to reduce the risk of data getting into the wrong hands. These policies define what conditions (assignments) you want to watch for and what to do about it (access controls).
(image from Microsoft)
CA Policies Address:
- Who: Identifies which users or groups can access resources (required)
- Where: Geo-fencing or IP address range restrictions (required)
- What: Device-based—only approved devices, or application-based conditional access
- When: Time or risk-based restrictions
Conditional Access (CA) is available in AADP premium subscriptions, both P1 and P2. Only AADP P1 is required for defining conditional access policies. P2 adds just-in-time-identity management (aka – Privileged Identity Management [PIM]) and access reviews. (You would only need to purchase P2 subscriptions for the Administrators who need PIM or access reviews performed.)
Proof-of-Concept Test
To test CA for this customer, I set up a trial subscription of AADP P2 (P1 was not available for a trial) in my own Azure tenant. I created a few test users and an “Execs” group containing one of the users. After creating the users, I defined a Trusted Location with the IP address range I currently receive from Comcast and called it “Paul’s Home”.
Then I created a CA policy called, “Restrict Power BI from External Locations”.
Conditional Access Assignments
Specifying Users or Groups
The first required assignment in a CA policy is to specify users or groups. I specified that all users would be included in the policy (selected “All users” on the “Include” tab in the “Users and groups” blade). Then I indicated that the Execs group is the exception to this rule (selected “Users and groups” on the “Exclude” tab of the “Users and groups” blade and added the “Execs” group). You should also consider whether there is a group of Administrators that should also be excluded from this policy. But the question should be asked, “Should Administrators even need to access Power BI outside of a trusted network?”
Specifying Cloud Applications
The second required assignment in a CA policy is to specify which cloud applications are impacted.
For this situation, the client wants to prevent Power BI from being used externally. Additionally, I added Azure Analysis Services as another practical use case in this scenario.
You could select “All cloud apps” or just the ones you want to lock down. You will see all apps connected with your Azure tenant. So, since we’re locking down Power BI in this example, I selected the “Power BI Service” app.
Using the Exclude tab, you could have selected specific apps to exclude from this policy and have “All cloud apps” on the include – essentially a white list of what’s allowed to be executed externally.
From that point, the next policy Assignment to figure out is the Conditions for the assignment. In other words, “What would trigger this policy to be enforced?”
5 Condition Categories
There are five categories of conditions which are all optional for setting up a CA policy. If you don’t specify any specific conditions, your policy will always affect the users and cloud apps you specified in the previous Assignments. The five categories are Sign-in Risk, Device Platforms, Client Apps, Device State, and Location.
1. Sign-in Risk is only available with the P2 subscription. Sign-in risk is pretty impressive as it utilizes Microsoft’s expansive Intelligent Security Graph to determine the risk-level of sign-in’s. More information on this topic can be found here.
2. Device Platforms allow you to narrow down to Android, iOS, Windows Phone (what’s that?), Windows, or MacOS. Or you can select, “All platforms (including unsupported)” which would be advisable since Linux isn’t one of the specific supported platforms.
3. Client Apps is a misleading term as it leads you to think of Power BI, Dropbox, or Office 365 apps on a person’s mobile device. However, “Client apps” refers more to the kind of application that is the source of the communication (i.e. – a browser, mobile app, or a desktop client). Be careful of relying on the “Browser” condition as this can be spoofed.
4. The Device State allows you to restrict all devices except those marked as compliant or devices that have joined your Entra ID.
5. The Location Condition is the only thing I needed specifically for this customer’s concern. I was able to specify that All locations would be included in this policy but allowed the exception for All trusted locations. I would also have been able to select specific-named locations defined in my AD, if needed.
Access Controls
Once you’ve defined the Assignments for the policy, then you move on to define the Access Controls. The Access Controls say what to do if the conditions defined are met. You can either block, grant access completely, or you can define specific session controls. Session controls depend on the level of control a cloud application provides. For example, you could use session control to say, “When user X logs in remotely, only allow them to have read-access to data.”
For my purposes, I simply wanted to block individuals from using Power BI from external networks. So, under the Grant access control, I selected “Block access”. Here is where you could say, “Grant access, but only if they provide Multi-factor Authentication.”
The final step in creating the CA policy was to turn it on; simply selecting “On” under “Enable policy” did the job.
A Welcomed Unwelcome Message
Finally, the last step was to test out my CA configuration.
First, I logged into Power BI with a credential that was not a member of the executives group and with an executive’s credential. Both of those credentials successfully logged in.
I then disconnected my laptop’s internet connection from Comcast and turned on my phone’s hotspot; a Verizon IP address range was assigned.
Next, I opened an incognito window in my Google Chrome browser. I tried logging in with “Jimmy Smith” who was a part of the executive’s group. The “Jimmy Smith” credential was still able to log in to Power BI. I logged Jimmy out and tried to log in as “Paulie Fuller” who was not part of the executives group.
I received the following message displayed below, “You cannot access this right now”, along with details about how to deal with the block. Normally this message would be quite unwelcome. However, it was quite a welcome sight for me as it proved out exactly what our health provider customer wanted to see: “You logged in just fine, but you can’t do that where you are right now.”
Through this test case, I was able to sucessfully prove out how you can restrict access to the Power BI service, or any of the Microsoft Cloud apps, to a trusted network. If you have any questions on how we can do this for you, let us know. We’d be happy to help.
