We have the same requirement but we found a work-around that appears to meet our immediate need (until a better solution comes along). It takes about a day to implement (manually) or it could be scripted: https://docs.microsoft.com/en-us/power-platform/admin/powerapps-powershell
The work-around is to create a crap-ton of DLP policies... each with their own connector that would otherwise be deleted or blocked. It doesn't matter which data group you put each connector in but, essentially, one DLP policy per connector works like a jersey barrier between each one. This prevents things like the following scenario:
Beth wants to use her personal accounts to move items between her Dropbox and Gmail (both in our no-business-data-allowed data group). The terms "business-data-only" and "no-business-data-allowed" mean nothing (unfortunately) -- they really only act as walled gardens between the two sets. Meaning, by default, Beth can have at it - she can use our company tenant's flow count to conduct her personal business (which, besides being annoying, might also be embarrassing/detrimental to our company if she got caught doing something nefarious).
By creating a separate DLP policy for Dropbox and another for Gmail, they become isolated from each other and her flow gets suspended. Again, it doesn't matter which data group I put these in. In my case, I put both in the "business-data-only" group in both policies and not only do they stop working with each other, but none of the other connectors in our main DLP policy for our self-service environment work with any connectors that are "walled-off" in these other DLP policies. Awkward but it works.
If/when the per-connector block becomes available, we'll switch to that ...hopefully soon. 🙂 Else, we'll just script this and automate it so that new connectors automatically get their own DLP policy until they can be reviewed.
