I have been rather vocal about the inadequate admin controls within the Power platform for a while now. While I can appreciate the flexibility a solution such as Power Automate adds and its usefulness across a myriad of scenarios, the simple fact remains that it can be abused to perform actions that might be otherwise unavailable to the end user. Even worse, it can be used by bad actors to exfiltrate data or in ransomware scenarios. Which is why it is important to have proper admin controls that can limit certain functionalities.
The DLP controls for the Power platform have been around for years now, yet they do nothing to address scenarios such as the one detailed in the Practical 365 article. In fact, Microsoft’s own IT organization acknowledged the issue, and the lack of control on Power platform’s side forced them to work with the Exchange PGI to come up with a workaround to address this specific scenario. Obviously, this is not an approach every other organization using the Power platform can take, neither it makes sense to address such issues outside of the Power platform itself. A more robust solution is needed, and with the general availability of the Advanced DLP granular connector controls feature, Microsoft just deliver such!
What are advanced granular controls?
While the “traditional” DLP controls within the Power platform do help address certain scenarios, they lack specificity. Advanced granular controls go a step further, allowing you to configure restrictions on a per-connector basis, and limit the set of actions you can perform via a given connector. In addition, they also allow you to configure endpoint restrictions, for example block connectivity to a certain IP address. Endpoint restrictions are currently in Preview, whereas connector action controls are officially released and supported.
Before covering how the features mentioned above actually work, it’s worth making a comparison with the Graph API. Most Microsoft 365 admins and IT Pros out there are slowly getting accustomed to relying on various Graph API endpoints to perform their daily tasks, and as such we can argue that the Graph, or the Microsoft Graph SDK for PowerShell are now a must-use tools. Yet, the permissions model employed by the Graph leaves a lot to be desired in terms of granularity. While most endpoints do support both read-only and read-write permissions, those are still quite broad in scope. For example, a Files.ReadWrite.All permission allows you unrestricted access to all files, and you cannot limit file deletion operations. And depending on the type of permission granted, they can span the entire directory, not just the files a given user has access to. Thus, the Graph team can take a hint or two from the approach taken by the Power platform folks.
With that said, let’s see how the Power platform DLP connector action controls are configured and enforced.
Configuring connector action controls
To restrict the actions exposed for a given connector, you will need to edit an existing DLP policy or create a new one. Start by navigating to the Power Platform admin center, Policies > Data policies or directly via the https://admin.powerplatform.microsoft.com/dlp URL. Press the New Policy button (or select and existing one and press the Edit button) > Enter a Policy name as needed and navigate to the Prebuilt connectors page of the wizard. Here, you will find all the available connectors, grouped in one of the three default groups. For our purposes, it doesn’t matter in which group the connector is, so let’s stick to the default Non-business group. Browse the list of connectors or use the Search box on the top right to find the connector you want to configure restrictions for, then select it and hit the Configure connector > Connector actions button on top. Alternatively, you can select the same action from the three-dot menu next to the connector name.
For example, let’s select the OneDrive connector, the one used for personal OneDrive integration. The list of actions exposed for said connector can be seen on the screenshot below, where we have chosen to toggle off three of them: Create share link, Create share link by path and Delete file. You can hit the info tooltip to get more info about each action.
At the bottom of the screen, you can specify how to handle any newly added actions, ones that might be made available after an update to the underlying connector. You can choose to either Allow new connector actions (default option) or Block new connector actions. Confirm your selection by pressing the Save button.
Next, configure restrictions on any additional connectors as you see fit, or proceed to the next wizard page by pressing the Next button. If you haven’t added any Custom connectors yet, you can skip the next page. Under the Scope page, select which environments the DLP policy will apply to, the default being Add all environments. Lastly, check your configuration on the Review and create policy page and if everything looks in order, hit the Create policy button to complete the process.
Verifying action restrictions
OK, now that we have configured at least one DLP policy with a connector action restrictions, let’s see what the effects are. When a user tries to configure a new Flow with the OneDrive connector selected, the system will not prevent him from selecting the Delete file operation. However, upon trying to save the new flow, an error will be flagged, as shown on the screenshot below:
This experience matches the behavior of other DLP-related restrictions, although personally I’d prefer an approach that hides any unavailable actions from the UI. In any case, the configured restrictions are being enforced, which is a good thing.
What’s not so good is the fact that not every connector supports action controls. Even first-party (native) Microsoft connectors do not universally support the restrictions, and even when the same APIs is effectively in use. For example, while the OneDrive (consumer) connector supports the granular action controls, its sibling OneDrive for Business one does not. Same goes for Exchange Online – the corresponding Office 365 Outlook connector does not support action controls, whereas the Outlook.com connector does. And what’s even more interesting is that related connectors, such as Outlook tasks do support the restrictions.
Another annoyance is the lack of visibility into which specific connectors within a DLP policy might have restrictions configured. The only way to get this information via the UI is by clicking each individual connector and checking the corresponding Connector actions pane. At the very least, a new column should be added to the connectors list view, designating whether connector actions are supported, and/or configured. Luckily, you can use PowerShell (and the underlying API) to generate a report, as follows.
You can start by getting a list of all the DLP policies configured within the tenant, via the Get-AdminDlpPolicy cmdlet. Once you have the policy name (represented in GUID form), you can query the connector configuration via the Get-PowerAppDlpPolicyConnectorConfigurations cmdlet. The output will contain a list of action rules per connector, as shown below:
If needed, you can use the New-PowerAppDlpPolicyConnectorConfigurations and/or the New-PowerAppDlpPolicyConnectorConfigurations cmdlets to make changes, but I’d generally suggest sticking to the UI on that.
Connector endpoint restrictions
Apart from the functionality to restrict which actions can be leveraged by a given connector, Microsoft also introduced a (preview) functionality to restrict endpoint connectivity. Also known as endpoint filtering, the functionality allows you to restric connectivity to specific connectors, such as the HTTP webhook one or the SQL Server one. To obtain a list of all connectors that currently support endpoint restrictions, use a filter on the value of the Endpoint configurable column in the UI.
The restrictions themselves can be configured under the same place, by selecting a given connector, then selecting Configure Connector > Connector endpoints (preview). The endpoint format might vary depending on the selected connector, but generally speaking you can use the FQDN,port or IP,port notation. Refer to the official documentation for a list of supported formats per connector type. For example, in the case of the standard SMTP connector, you can do something like this:
As with the connector action restrictions, discovering the current configuration can be cumbersome, even though the number of connectors supporting endpoint restrictions currently is quite small. You can still use PowerShell to list the restrictions, as they are represented as just another property of the Get-PowerAppDlpPolicyConnectorConfigurations cmdlet output:
It has taken Microsoft a long time, but we are finally seeing some meaningful admin controls being added to the Power platform. While the current implementation leaves something to be desired in terms of connector coverage and management experience, it’s undoubtedly a step in the right direction, and a major one at that. With the granular connector action restrictions control, admins can now enforce restrictions on “sensitive” operations such as file deletions, whereas the connector endpoint restriction controls allow limiting connectivity to only approved instances of say an SMTP gateway or an SQL server. So, if you haven’t yet played with the “advanced granular controls” feature, I’d strongly recommend you give it a go. And I’d encourage the Graph API team to take a look into the granularity offered by this feature and come up with something comparable!