Forum Discussion
Need help with configuring DLP policies for Flow in O365
Hi Pooya Obbohat - so, your assumption is correct regarding the relationship between the two groups, that is "you can't create flows by combining connectors from the two groups (Business data only & No business data allowed)." But as for your objectives, let's walk through them:
1. Allow users to create Flows by combining Office 365 connectors (business data stays within the company)
RECOMMENDATION: Add the O365 connectors to the "Business data only" group. See attachment for how this might look.
With that in place, users can create Flows with connectors from the O365 group that can interact with one another, but they cannot create Flows that interact with those on the "no-Business data allowed" group.
2. Allow users to create Flows where info from the outside world is stored within the O365 environment (e.g. save Tweets with specific hashtag in Teams)
NOT POSSIBLE: The DLP engine is bi-directional, so when you add connectors in to a group, the data can go in both directions. To use your example, if you add Twitter to the "Business data only" group, you can achieve the requirement to save Tweets based on a specific hashtag to Teams, but you can also send data out to Twitter too, which from your requirements you don't wish to do. I have had discussions with the product group on the idea of uni-directional policies, but nothing has been committed to at this time.
3. Don't allow business data to leave the company (e.g. copy O365 Outlook meetings to Google calendar)
RECOMMENDATION: See point 1. above, but you probably know that based on what I shared above. Like us you would like all 3 scenarios to be possible, while protecting your data. The solution is not quite there yet.
Good day Clifford Kennedy! Perhaps you can help me on something related to this. My company has the desire to only use the connectors provided by Microsoft as well and keep the data contained in Office 365 precisely as you described. Can you point towards any documentation that clearly defines what is a Microsoft controlled containor and what isn't? When I look at a page like this one: https://docs.microsoft.com/en-us/connectors/approvals/ I can't get the assurance that my company needs to say yes that is a Microsoft owned app contained in Office 365 / Azure.
Thanks kindly!
Have opened a case with support to get a clear understanding of how everything works w.r.t. Flow administration. Here are some thoughts:
- DLP policies are stacked and Flows have to comply with all the DLP policies applied to the environments where they have been created. Also keep in mind that your policies will have an impact on PowerApps and Logic Apps.
- Connectors allow for multiple connections. Having all the O365 related connectors in the top group and the rest of the connectors in the bottom group doesn't prevent users from adding connections to other tenants when using the O365 related connectors. Users on a different tenant can also create connections to your tenant and bypass your company's DLP policies (this is by design, they have to comply with their own company's DLP policies). These two points can be addressed by making use of Active Directory tenant restrictions. More info via link. I'm still researching this as this would have an impact on other applications as well. Also keep in mind that the Yammer connector still allows users to establish connections to Yammer networks where Office 365 identities are not enforced.
- It is recommended to keep the bottom group as the default (no business data allowed). Keep in mind that the labels for the groups are just labels. Both groups are identical in the way they work. Let's assume that you have all O365 related connectors in the top group. When a new Office 365 related connector is released, it will end up in the bottom group, allowing users to combine that connector with connectors such as Dropbox, Twitter, Facebook etc. You have to add the new Office 365 related connector to an existing DLP policy or create a new one if you don't want users to combine it with other connectors. Making the top group default is not an option as most of the new connectors being added aren't related to Office 365. There is a Flow which gives you a notification when new connectors are made available. More about this via following link. You could address this by isolating each connector in the bottom group in its own DLP policy (creating around 170 policies). This would prevent users from combining any new connector with other connectors, but it will also prevent users from combining connectors in the bottom group which makes it rather restrictive.
- Custom connectors are treated as being part of the default group, but they don't show up there when configuring the DLP policy. This means that you can't create any specific policies to address custom connectors. This is rather restrictive as you don't have a way to allow users to combine them with the O365 connectors in the top group (if that group is not set as the default group). I'm assuming that even if you isolate each connector from the bottom group in its own DLP policy, users will be able to combine these individual connectors with multiple custom connectors in Flows.
- As a Flow admin, you don't have an overview of all the custom connectors. You only see the custom connectors that have been shared with you explicitly and you can only delete them if they made you an owner. Users can also make custom connectors available to the entire organisation. It will show up as a suggestion when they are creating a Flow.
- The point regarding bi-directional could be a reason to prevent users from combining O365 related with the other connectors. Allowing users to save Tweets in a SharePoint list means that they can also send out a Tweet with info from a SharePoint list. Think it's important to explain to users that they're not allowed to sync company data to other cloud services if you are not restricting this.
Will be creating a blog post about Flow soon. Will share a link here when it's online.
