I have a client with over 5000 users that all use OneDrive for their corporate data. This corporate data is governed by company policy.
With the addition of Flow for OneDrive, how can I lock down data loss from users creating easy Flows?
Reviewing the DLP policy recommendations here: https://docs.microsoft.com/en-us/flow/prevent-data-loss
leaves a LOT to be desired.
It was easy for me to spin up a demo tenant and set up a Flow to copy all my OneDrive for Business (corporate tenant) to my OneDrive for Business (demo tenant). Obviously none of the corporate security/legal/dlp/retention/etc policies apply on this second tenant. The flow can be created from either tenant (another issue).
Now this client wants to shut down OneDrive for their corporate data. As great as the vision of Flow is, without the ability to turn it off for a tenant while the product matures is a significant security and legal risk to corporations that take this very seriously.
Is there anyway to prevent this from happening and save this client? Separating services into categories in the flow admin portal does not provide nearly sufficient control.
Thanks for your advice.
Have you seen these two docs on DLP:
From the docs we know that we could create DLP policy to define which consumer services data may be shared with. You could create a DLP policy if you are a tenant and environment admin.
Thank you for taking the time to respond Mabel!
Unfortunately I'm not convinced that these controls give nearly sufficient control to be deemed as "Data Loss Policies". I would love to talk to the team that implemented this to understand how they managed to convince the MS legal team that this meets the requirements to be classified as such.
What if you are the IT administrator, and you decide that you want to lock down access to a users email and onedrive account? You would probably implement MFA for 2 factor authentication.
Lets say that a users accidentally clicks on a link and their password is comprimised without them knowing. Implementing MFA prevents the users information getting into the wrong hands. Unfortunately, MFA is NOT implemented in flow. This hackor could set up a O365 tenant with Flow (Plan 2) and use the comprimised users credentials to copy emails to another email ("same service" as far as flow is concerned as it allows multiple tenants) or onedrive content to another onedrive or attachments to onedrive.... there are literally thousands of options.
My questions are:
1. How, as an IT Admin do I determine that a users account has been comprimised/beings used as a connection in ANY flow be it by my tenant or another tenant?
2. How can I lock down a users Email/OneDrive to prevent flow from accessing ANY corportate data. I don't care about "services", I just don't want access unless it is between MY tenant's email and MY tenant's onedrive.
My testing has shown this:
0. SETUP: Tenant A [Source]; Tenant B [Target].
--- Play the role of the bad guy and I control Tenant A and have login for user at Tenant B.
1. Log into Tenant A (with Flow 2)
2. Create a connection to TenantB.ComprimisedO365Login
3. Create a flow to copy data and emails to TenantA
4. Result: I get a complete copy of Comprimised Users emails/OneDrive
--- Play the rold of the good guy to catch the bad guy
5. Log into Tenant B playing the Role of "IT Admin"
6. Try to see the data loss from the above scenario --- no indications
7. Change Flow DLP policies -- flows from steps 3 continue to run as I only used single connection sources in my flow
8. Ran all the security/reports/Azure AD lockdowns/etc... still information is copied to bad guy and there is no indication that data loss is occurring
I hope that I'm doing something wrong and that there is a simple way to prevent and detect data loss from Flow.
Check out the new Process Advisor community forum board!
Check out new user group experience and if you are a leader please create your group
On-demand access to all the great content presented by the product teams and community members! #MSBizAppsSummit #CommunityRocks
Check out how to claim yours today!