Securing Power Platform

Power Platform is powerful and accessible - which is exactly what makes it a security challenge. When business users can build apps and automations without IT involvement, how do you maintain control? Here's our governance framework.

The Security Model

Power Platform security operates at multiple layers. Tenant settings control what's possible across your entire organization. Environment settings control what's possible in specific workspaces. DLP policies control what data connectors can talk to each other. And then there's row-level security within Dataverse itself.

If you only configure one layer, you've got gaps. If you over-configure, you've made the platform unusable. The balance is tricky.

Our DLP Strategy

Data Loss Prevention policies are the heavy lifting tool. We classify connectors into three categories: Business (approved for production use), Non-Business (approved for personal/experimental use), and Blocked (not approved under any circumstances).

Business connectors: SharePoint, Dataverse, approved SQL databases, Teams, Outlook, approved third-party systems like Paycom. These can talk to each other in production apps.

Non-Business: Personal OneDrive, Twitter, personal email services. Fine for experimentation, but can't mix with business data.

Blocked: High-risk connectors that have no legitimate business use in our environment. File sharing services we don't use, social media platforms, etc.

The key insight: DLP policies prevent data from flowing between connector categories. An app can't pull data from Dataverse (business) and post it to a personal Twitter account (blocked). This is your primary data exfiltration control.

Environment Strategy

We run multiple environments: Production (tightly controlled, change management required), Test (for validating before production), Development (for building and experimenting), and Personal (sandboxes for citizen developer learning).

Each environment has its own DLP policy. Production is most restrictive. Personal is most permissive. This lets people learn and experiment without putting production data at risk.

The FortiGate Integration

Our FortiGate firewalls provide network-level visibility into Power Platform traffic. We can see what external services are being called, what data volumes are moving, and whether anything unusual is happening. This doesn't replace platform controls, but it provides a second layer of observability.

The Audit Trail

Power Platform activity logging feeds into our SIEM (Arctic Wolf). Failed authentication attempts, permission changes, app sharing changes, connector usage - all of this gets logged and monitored. If someone tries something they shouldn't, we'll see it.

The combination of DLP policies, environment controls, network visibility, and activity monitoring gives us defense in depth. No single layer is sufficient, but together they create a security posture that lets us enable citizen development while maintaining appropriate controls.