DLP Policy Strategy
Welcome everyone! This post is part of my wider series on how to implement low-code not just from a technology and process perspective, but also for a people enablement and adoption perspective to truly maximise value from the platform - This post gives an overview of the structured approach I’ve defined and how I’m breaking down my blog posts
Holistic Low-Code Enablement - Blog structure and navigation — EmPOWER Your World
This is the next episode going down the platform governance track to enable our developers to do their best work through establishing balanced platform controls. As you’ll remember from the Scalable Governance V2 post we can use a T-Shirt model to govern small, simple, low risk solutions lightly to enable everyone across an organisation to solve their own problems, and govern those important and critical solutions with care to ensure we’re managing the different types of risk through leveraging our standard IT best practice approaches.
In my last post I spoke about how we can align our environment strategy to enable and manage these t-shirt sizes so the right people, can do the right things, in the right way, in the right place. The DLP strategy we apply to these environments goes hand in hand with the environments so that’s what we’ll look at today! 😁
In the below picture you can see an example of how we might define our environments for organisations who are either primarily using seeded M365 ‘standard’ licenses, or have additional premium licenses.
For each of these scenarios I’ve showed some general themes in how I see the use of different connector classifications being used across the T-Shirt sizes of risk
Unblockable - You can see by the grey bar that the connectors that Microsoft make ‘unblockable’ are available to everyone in all scenarios (we’ll talk more about how we can have some control over these later) - The vast majority of these are standard connectors like Teams, Outlook, SharePoint etc. The tools that people use day to day already.
Standard Connectors - The light blue bar - With additional connectors comes more risk. This is from each connector individually, but also through combining of connectors. As the risk is increased we want additional controls, perhaps higher capability, or maybe just more visibility of what they’re being used for.
For a standard licensed organisation we might not want to make these available to the whole organisation in the default environment so they’re made available from Medium upwards. For X-Large these are commonly connecting to core business systems or enterprise data sources or services and less likely to be part of a solution.
For a premium licensed org we have the option of routing new makers to their own developer environment and so have more granular control available so we might make more connectors available in ‘Small’ to some makers of higher capability, experience or trust.
Premium Connectors - The dark blue bar - These are generally the enterprise type of connectors - large scale data sources, core business systems, large scale or impact services.
For a standard licensed org - there are usually a relatively small number of these and so greater management is needed around these to ensure we’re investing them in the best use cases to get the most value. Hence these requiring the higher governance of Large and X-Large
For a premium licensed org there are sufficient licenses for everyone who needs them (which may be 100% of the org, or less) and so we want to make them available more broadly to enable people to deliver greater value and get the maximum return for that license investment (e.g. teaching people to use Dataverse for Medium and perhaps Small use cases rather than SharePoint)
Custom Connectors - These are the ones that are created and managed by our IT organisation to connect to exposed APIs for our enterprise systems, data sources, and services. They might be used where an ‘out of the box’ connector doesn’t exist, or perhaps where we want to provide different functionality or controls.
For a standard licensed org - These are licensed like premium connectors and so generally will only be made available on Large and X-Large use cases.
For a premium licensed org - They’ll more often be used on higher risk / higher value use cases in Large and X-Large use cases, however as there is sufficient premium licenses we can use use them to make more controlled connections to enterprise data / systems / service available in select scenarios in Medium or potentially even Small use cases.
So we understand our types of connector and the types of use cases we might be willing to make them available in and under which licensing conditions.
The way we make these connectors available are by creating a DLP policy containing the connectors we want to make available, and then applying them to an Environment.
How do we design our DLP policy? What do we need to consider?
We have 3 categories we can apply to our connectors - Business, Non-Business, and Blocked.
Blocked is obvious… Whatever is in that category can’t be used by anyone for anything. This should be set as the default setting for any new connectors made available by Microsoft
Business and Non-Business give us a way to make connectors available to people. Connection can’t take place across the two groups
Connectors in the Business group can only be used with other connectors in the Business group.
Connectors in the Non-Business group can only be used with other connectors in the Non-Business group.
Within our DLP Policy we should include the connectors that group that are needed by the users of those environment in line with our T-Shirt themes. Some will be the Unblockable connectors, perhaps supplemented with Standard, Premium, and / or Custom connectors!
As well as controlling what can be done at a connector level, we have an increasing number of connectors that we can control at a more granular level too! Let’s take a look a how that works…
By making the connectors available we can control if someone can / can’t connect to that system, data source, or service.
Just because they can use the connector that’s not enough though! They will also need permissions to that resource. Using the connector doesn’t automatically give them additional rights to do more than they could previously. (The caveat being as long as they’re authenticated using their own credentials, not a service account which has increased permissions.)
The next level of control is the ability on some connectors to be able to define the triggers or actions that it can be used for, and if there are specific end points that be connected to. With out of the box connectors this is being rolled out slowly so isn’t available across all connectors yet. The other option is to use a Custom Connector to be really prescriptive as to what can and can’t be done, where and by whom.
So once we’ve designed what our connectors are allowed to do, where they’re allowed to do it, and which connectors are allowed to interact with each other, we can apply them to environments. This could be to a single environment, a set of Dev / QA / UAT / Prod environments, or groups of multiple environments as shown in the t-shirt aligned picture below. The simpler we can make our DLP policies, the better.
We can also apply multiple DLP policies to any environment but there is some complexity in doing this. Rather than how we might expect this to work by applying a DLP policy to open up and allow specific connectors it’s the opposite. Each applied policy locks access down further. What you end up with is the minimum set of connectors that exist in all of the applied DLP policies.
I’ve drawn an example below where 3 policies have been applied to an environment. Our solution in the environment will only be able to connect to the Systems, Sources, and Services which exist in all of those DLP Policies - In the picture you can see that in this example only connectors 2,4, and 8 exist in all policies so any other functionality that has been built using connectors 1,3,5,6,7,9 won’t work!
The simpler we can make our DLP policy strategy, with as few layers as possible, the easier it will be to manage and the lower the risk of unintenteded consequences when we make changes to our DLP policies!
From this post you can continue to see how our scalable governance model gives us a foundation to holistically design, and manage, the implementation of our platform. It gives us a joined up way to balance the management of risk with empowering the organisation to solve problems at the right place in the organisation with an appropriate level of governance to keep our data, organisation, and people safe.
Additional posts connected to this topic :
Scalable Governance of Low Code solutions for any organisation — EmPOWER Your World
Turbo charge your Power Platform with Managed Environments and Environment Groups — EmPOWER Your World
If you find this post or any other of my posts useful please subscribe below to make sure you don’t miss out on future posts when they’re published! :)
