Securing Power Platform with DLP
Securing Power Platform with DLP
Introduction
The Power Platform has revolutionized business processes by empowering citizen and professional developers to build custom applications, automate workflows, and analyze data with remarkable speed. However, this accessibility comes with an inherent responsibility: ensuring that sensitive organizational data remains protected. Data Loss Prevention (DLP) policies are paramount in governing how data interacts within and across the Power Platform components – Power Apps, Power Automate, Power BI, and Microsoft Dataverse.
This article is designed for IT administrators, security architects, and governance leads who are responsible for implementing and managing data security within their Microsoft 365 and Power Platform ecosystems. We will delve into the critical role DLP plays in mitigating data exfiltration risks and maintaining regulatory compliance, providing practical guidance on establishing robust defenses.
Why this matters
The rapid adoption of Power Platform applications, often driven by departmental needs, can inadvertently create shadow IT scenarios if not properly governed. Without effective DLP, sensitive organizational data, such as customer Personally Identifiable Information (PII), financial records, or intellectual property, could inadvertently be shared with unauthorized external services or individuals. This poses significant risks, including regulatory non-compliance (e.g., GDPR, HIPAA), reputational damage, financial penalties, and compromised data integrity. Implementing DLP helps to proactively prevent such incidents, ensuring data sovereignty and maintaining the organization's security posture. It directly impacts compliance, reduces financial risk associated with breaches, and fosters a more secure environment for productivity.
Key concepts
- Data Loss Prevention (DLP): A set of policies and technologies designed to prevent sensitive information from leaving the organization's control. In Power Platform, this primarily involves controlling how connectors can share data.
- Connectors: Pre-built proxies that allow Power Platform services to interact with other online and on-premises services (e.g., SharePoint, SQL Server, Twitter, Dropbox).
- Data Groups: Categories defined within a DLP policy (Business, Non-Business, Blocked) that determine which connectors can be used together. Connectors in different groups generally cannot exchange data within the same Power App or Power Automate flow.
- Environment: A container for Power Apps, Power Automate flows, and Dataverse databases. DLP policies are scoped to one or more environments.
- Tenant-level Policy: A DLP policy that applies to all environments within a Microsoft Power Platform tenant by default, except for those specifically excluded.
- Environment-level Policy: A DLP policy applied to a specific environment, overriding tenant-level policies for that environment.
- Default environment: A special environment automatically created for each tenant. Users with Power Platform licenses generally have maker access. Often requires stricter DLP.
Step-by-step implementation
Implementing Power Platform DLP typically involves defining your data classification, organizing connectors, and then applying policies.
- Understand your data: Identify the types of data your organization uses (e.g., PII, financial, public) and their sensitivity levels. This will guide your connector categorization.
- Access the Power Platform admin center: Navigate to admin.powerplatform.microsoft.com.
- Create a new policy:
From the left navigation, select Policies > Data policies. Click New policy. * Give your policy a meaningful name (e.g., "Tenant-wide Business Data Policy").
- Define data groups and connector classification:
On the Connectors step, categorize connectors into Business and Non-Business groups based on your data classification. Connectors in the Blocked group cannot be used at all. For example, SharePoint, SQL Server, and Dataverse might be in the Business group, while Twitter, Dropbox, and generic HTTP connectors might be in the Non-Business group. Google Drive might be Blocked if not allowed.
- Configure custom connector behavior:
Under Custom connectors, specify whether newly created custom connectors should default to Business, Non-Business, or Blocked*. This ensures new connectors adhere to policy by default.
- Apply policy scope:
On the Scope step, choose whether to apply the policy to All environments (tenant-level) or Specific environments. If applying to specific environments, select the target environments. Consider a stricter policy for the Default environment.
- Review and create: Review your selections and create the policy.
- PowerShell for Listing DLP Policies: You can also manage and audit DLP policies using PowerShell.
# Install the Microsoft.PowerApps.Administration.PowerShell module if not already installed
# Install-Module -Name Microsoft.PowerApps.Administration.PowerShell
# Connect to Power Apps environment
# You might need to use Connect-PnPOnline or similar for specific environments,
# for admin level, Connect-Microsoft.PowerApps.Administration.PowerShell is sufficient.
Connect-Microsoft.PowerApps.Administration.PowerShell
# Get all Power Platform DLP policies in the tenant
Get-PowerAppDlpPolicy | Format-Table DisplayName, IsDefault, EnvironmentIds, DataGroupConfiguration
# Example: Get a specific DLP policy by display name
Get-PowerAppDlpPolicy -DisplayName "Tenant-wide Business Data Policy"Example configuration
This JSON snippet illustrates the core structure of a Power Platform DLP policy, focusing on connector classification and data group enforcement. While you configure this through the UI, understanding the underlying structure is beneficial.
{
"displayName": "Tenant-Wide Restricted Data Policy",
"id": "/providers/Microsoft.PowerApps/tenantSettings/default/policies/Tenant-Wide-Restricted-Data-Policy",
"name": "Tenant-Wide-Restricted-Data-Policy",
"properties": {
"dataPolicyType": "DLP",
"description": "Prevents sensitive data sharing between business and non-business services tenant-wide.",
"environmentIds": [], // Empty array for tenant-wide policy
"defaultConnectorClassification": "NonBusiness",
"customConnectorClassification": {
"defaultNewCustomConnectorClassification": "NonBusiness"
},
"connectorConfigurations": {
"shared_sharepoint": {
"classification": "Business"
},
"shared_sql": {
"classification": "Business"
},
"shared_microsoftteams": {
"classification": "Business"
},
"shared_outlook": {
"classification": "Business"
},
"shared_onedriveforbusiness": {
"classification": "Business"
},
"shared_twitter": {
"classification": "NonBusiness"
},
"shared_dropbox": {
"classification": "NonBusiness"
},
"shared_http": {
"classification": "NonBusiness"
},
"shared_googledrive": {
"classification": "Blocked"
},
"shared_facebook": {
"classification": "Blocked"
}
},
"dataGroups": {
"Business": {
"displayName": "Business",
"description": "Connectors that handle business-critical and sensitive data.",
"connectors": [
"shared_sharepoint",
"shared_sql",
"shared_microsoftteams",
"shared_outlook",
"shared_onedriveforbusiness"
]
},
"NonBusiness": {
"displayName": "Non-Business",
"description": "Connectors that handle less sensitive or public data.",
"connectors": [
"shared_twitter",
"shared_dropbox",
"shared_http"
]
},
"Blocked": {
"displayName": "Blocked",
"description": "Connectors that are not permitted in any context.",
"connectors": [
"shared_googledrive",
"shared_facebook"
]
}
},
"policyGroups": [
{
"id": "1",
"isDefault": true,
"name": "Default group",
"connectors": {
"shared_sharepoint": {
"isAllowed": true,
"dataAccess": "NoRestriction"
},
"shared_sql": {
"isAllowed": true,
"dataAccess": "NoRestriction"
},
"shared_microsoftteams": {
"isAllowed": true,
"dataAccess": "NoRestriction"
},
"shared_outlook": {
"isAllowed": true,
"dataAccess": "NoRestriction"
},
"shared_onedriveforbusiness": {
"isAllowed": true,
"dataAccess": "NoRestriction"
},
"shared_twitter": {
"isAllowed": true,
"dataAccess": "NoRestriction"
},
"shared_dropbox": {
"isAllowed": true,
"dataAccess": "NoRestriction"
},
"shared_http": {
"isAllowed": true,
"dataAccess": "NoRestriction"
}
}
}
]
},
"type": "Microsoft.PowerApps/tenantSettings/policies"
}Common pitfalls
- Overly Permissive Default Environment DLP: Neglecting to apply a strict DLP policy to the default environment, which is often accessible to all users for maker activities.
- Lack of Communication to Makers: Implementing DLP without proper communication and training for Power Platform makers, leading to frustration and workarounds.
- Infrequent Review of Connectors: Not regularly reviewing newly released connectors or existing connector usage, allowing new avenues for data exfiltration to emerge.
- Ignoring Custom Connectors: Not having a strategy for governing custom connectors, which can bypass standard DLP rules if not explicitly classified.
- "Set it and forget it" mentality: DLP policies are not static. Business needs, new applications, and security threats evolve, requiring periodic review and adjustment.
- Solely Relying on Tenant-level Policies: Not customizing DLP for specific environments with distinct data sensitivity or usage patterns.
Best practices
- Adopt a Zero Trust Mentality: Assume breach and implement "least privilege" for data access and connector usage. Only allow connections that are explicitly required for business processes.
- Prioritize the Default Environment: Implement the strictest possible DLP policy for the default environment as per the Microsoft Cloud Adoption Framework for Power Platform guidance. Consider categorizing the default environment as a 'personal productivity' environment.
- Establish a Maker-Friendly Governance Model: Communicate DLP policies clearly to makers. Provide guidance, training, and a clear process for requesting exceptions or new connectors. This fosters collaboration rather than circumvention.
- Regularly Review and Audit: Schedule periodic reviews of your DLP policies, connector classifications, and audit logs. This ensures policies remain effective and adapt to evolving business needs and new Power Platform features.
- Leverage Environment Segmentation: Utilize distinct environments for different business units, data classifications (e.g., development, test, production), and apply granular DLP policies to each, rather than a monolithic approach.
- Develop a Custom Connector Strategy: Have a process for approving and classifying custom connectors. Treat them with the same scrutiny as built-in connectors regarding data groups.