Home > Docs > Best Practices > Security > Data Exfiltration Prevention

🚪 Data Exfiltration Prevention on Microsoft Fabric¶

Last Updated: 2026-04-27 | Version: 1.0.0 | Anchor: SOC 2 Type II Readiness (Wave 5)

Disclaimer: This document describes architectural and technical controls to reduce the likelihood and impact of data exfiltration. It is not a guarantee. A determined insider with sufficient privilege can defeat any control. Layered defense, behavior monitoring, and process controls are equally important. Engage your security and legal teams before relying on these patterns in regulated environments.

📑 Table of Contents¶

• 🎯 Overview — The Exfiltration Threat Model
• 🛣️ Exfiltration Vectors in Fabric
• 🛡️ Layered Defense Model
• 🚧 OAP — Outbound Access Protection (Deep Dive)
• 📥 COPY INTO Restrictions
• 📤 Power BI Export Restrictions
• 📓 Notebook Download Restrictions
• 🌐 Cross-Tenant Sharing Controls
• 🔍 DLP Integration (Microsoft Purview)
• 🏷️ Sensitivity Label Enforcement
• 📈 Egress Monitoring
• 🕵️ Detective Controls
• 👁️ Insider Threat Patterns
• 🤝 Vendor / Third-Party Controls
• 🎰 Casino Implementation
• 🏛️ Federal Implementation
• 🚫 Anti-Patterns
• 📋 Implementation Checklist
• 📚 References

🎯 Overview — The Exfiltration Threat Model¶

Data exfiltration is the unauthorized movement of data outside the trust boundary of the organization. Unlike unauthorized access (which is about reading), exfiltration is about taking. It is the dominant cause of regulated-data breaches and the highest-impact failure mode for any analytics platform.

In a Fabric workload, the trust boundary is typically: - A specific tenant - A workspace or set of workspaces in a domain - The customer-controlled storage accounts (CMK-encrypted, OAP-fenced, private-endpoint-isolated)

Anything that crosses that boundary unsupervised is an exfiltration event.

The Four Threat Personas¶

Auditors will ask: "Show me the control that prevents an analyst from copying the player table to their personal OneDrive." You need an answer for every persona, every vector.

What "Prevention" Actually Means¶

True prevention is rare. Realistic goals:

1. Eliminate the easy path. No double-clicks should yield a CSV of regulated data.
2. Add friction. A user determined to exfiltrate must defeat multiple layers (network, identity, data, app, audit) — each leaving evidence.
3. Detect within hours, not weeks. Behavior monitoring + DLP + SIEM correlation.
4. Minimize blast radius. Workspace isolation, encryption, sensitivity labels, OneLake row/column controls.
5. Preserve audit trail integrity. When (not if) an event happens, you can investigate.

📝 Scope: This is a Wave 5 deep-dive. Closely related Wave 5 docs: Zero-Trust Blueprint, STRIDE Threat Model, Audit Trail Immutability, SOC 2 Type II Readiness. Existing dependencies: OAP, Network Security, Data Governance Deep Dive, OneLake Security.

🛣️ Exfiltration Vectors in Fabric¶

The comprehensive list of exfiltration paths a Fabric tenant must consider. Every vector below is real and observed. A program that addresses only some of them has gaps.

⚠️ Be honest about scope. Vectors 14 (camera) and parts of BYOD are organizational/process controls, not technical. Document them in your security awareness training; do not pretend they're solved by a Bicep parameter.

🛡️ Layered Defense Model¶

No single control prevents exfiltration. Defense-in-depth places obstacles at the network, identity, data, application, and audit layers. An attacker must defeat all five to succeed silently.

flowchart TB
    subgraph Threat["🎯 Threat Actor"]
        Insider[Insider<br/>malicious / compromised]
        External[External<br/>credential theft]
        Accidental[Accidental<br/>misdirection]
    end

    subgraph Network["🌐 Network Layer"]
        OAP[OAP — Outbound<br/>Access Protection]
        PE[Private Endpoints]
        IPF[IP Firewall]
        VNet[Managed VNet]
    end

    subgraph Identity["🆔 Identity Layer"]
        CA[Conditional Access<br/>+ MFA]
        DC[Device Compliance]
        PIM[Entra PIM<br/>just-in-time]
        WI[Workspace Identity]
    end

    subgraph Data["📦 Data Layer"]
        Labels[Sensitivity<br/>Labels]
        DLP[Purview DLP<br/>Policies]
        OLS[OneLake Security<br/>row/column]
        CMK[CMK Encryption]
    end

    subgraph App["⚙️ Application Layer"]
        ExportOff[Export-to-Excel<br/>Disabled]
        DownloadOff[Notebook<br/>Download Off]
        ShareBlock[External Share<br/>Block]
        CopyRestrict[COPY INTO<br/>Allowlist]
    end

    subgraph Audit["📜 Audit & Detection"]
        Logs[Workspace Monitoring<br/>+ Log Analytics]
        Sentinel[Microsoft Sentinel<br/>UEBA]
        Reflex[Data Activator<br/>Reflex]
        SOC[SOC<br/>Investigation]
    end

    subgraph Asset["🔒 Protected Asset"]
        OneLake[(OneLake<br/>regulated data)]
    end

    Threat --> Network
    Network -->|allowed| Identity
    Identity -->|authenticated| Data
    Data -->|labeled| App
    App -->|permitted action| OneLake
    Network -.->|every event| Audit
    Identity -.->|every event| Audit
    Data -.->|policy match| Audit
    App -.->|user action| Audit
    Audit --> SOC

    style Threat fill:#fee,stroke:#c00
    style Asset fill:#efe,stroke:#0a0
    style Audit fill:#eef,stroke:#00c

Layer Responsibilities¶

The unique value of layered defense: no layer is asked to be perfect, but the combination makes silent exfiltration impractical.

🚧 OAP — Outbound Access Protection (Deep Dive)¶

OAP is the single highest-leverage technical control for exfiltration prevention. Reference: existing OAP doc.

What OAP Blocks¶

OAP is a network-egress control. It prevents the workspace from sending data outbound. It does not prevent users with legitimate read access from pulling data through approved client tools.

Configuration Patterns¶

The recommended pattern is default-deny + per-domain allowlist:

Bicep — OAP Module Reference¶

@description('Workspace ID for OAP target')
param workspaceId string

@description('Approved ADLS Gen2 storage rules')
param storageRules array = [
  {
    storageAccountName: 'stcasinoprod'
    containers: [ 'bronze', 'silver', 'gold' ]
    accessLevel: 'ReadWrite'
  }
]

@description('Approved cross-workspace targets')
param crossWorkspaceRules array = []

@description('Approved external connector types')
param allowedConnectors array = [
  'AzureDataLakeStorageGen2'
  'FabricLakehouse'
  'FabricWarehouse'
  'Eventhouse'
]

resource oap 'Microsoft.Fabric/workspaces/outboundAccessProtection@2026-01-01' = {
  name: '${workspaceId}/default'
  properties: {
    enabled: true
    defaultAction: 'Deny'
    storageRules: storageRules
    crossWorkspaceRules: crossWorkspaceRules
    connectorRules: {
      mode: 'AllowList'
      allowedConnectors: allowedConnectors
    }
  }
}

output oapEnabled bool = oap.properties.enabled

Validation Tests¶

Every workspace deployment should run an OAP smoke test:

# tests/security/test_oap_egress_block.py
import pytest
from pyspark.sql.utils import AnalysisException

UNAUTHORIZED_PATH = (
    "abfss://exfil@unauthorizedstorage.dfs.core.windows.net/test"
)

def test_oap_blocks_unauthorized_egress(spark):
    """OAP should refuse a write to a non-allowlisted storage account."""
    df = spark.createDataFrame([(1, "synthetic")], ["id", "value"])
    with pytest.raises((AnalysisException, PermissionError)) as exc:
        df.write.format("delta").mode("overwrite").save(UNAUTHORIZED_PATH)
    assert "outbound" in str(exc.value).lower() or "denied" in str(exc.value).lower()

def test_oap_allows_approved_egress(spark, approved_path):
    """OAP should permit writes to allowlisted destinations."""
    df = spark.createDataFrame([(1, "synthetic")], ["id", "value"])
    df.write.format("delta").mode("overwrite").save(approved_path)
    assert spark.read.format("delta").load(approved_path).count() == 1

When OAP Doesn't Help¶

⚠️ Critical limitation. OAP secures the destination set. It does not stop exfiltration to allowed destinations.

A malicious user with write access to stcasinoprod/bronze (an OAP-allowed account) can still: - Copy regulated data into a less-protected container within stcasinoprod - Write to stcasinoprod then access it from outside Fabric via the storage's own data plane (if storage RBAC permits) - Stage data for external retrieval by a separate process they control

OAP must be paired with: - Storage-account RBAC and private endpoints (data plane locked down) - OneLake security row/column rules (cannot read what they want to copy) - Audit log analysis on writes to monitored containers - DLP policies on outbound files

📥 COPY INTO Restrictions¶

Default Behavior¶

COPY INTO is a Warehouse / SQL endpoint T-SQL statement that bulk-loads from Azure storage. By default, the destination of a COPY INTO is a Warehouse table — not external storage — so traditional COPY INTO is an ingress tool, not egress.

The exfiltration risk emerges when: - Users have permission to COPY INTO-to-external-Warehouse-or-Storage via the inverse pattern (CREATE EXTERNAL TABLE AS SELECT, OPENROWSET writes, BCP). - Users use SELECT INTO to a remote linked database. - Users run PolyBase-style writes if/when supported.

Workspace Policy to Restrict Destinations¶

For Fabric Warehouses, use: - OAP to block writes from Warehouse endpoints to non-allowlisted storage - Workspace IP firewall so the SQL endpoint is reachable only from corporate IPs and Bastion subnets - Object-level GRANT/DENY so only specific service accounts can use COPY INTO-style operations

-- Restrict COPY INTO and bulk-load privileges to a service principal only
DENY ADMINISTER BULK OPERATIONS TO [analyst_role];
DENY ALTER ANY EXTERNAL DATA SOURCE TO [analyst_role];
DENY ALTER ANY EXTERNAL FILE FORMAT TO [analyst_role];

-- Allow read-only on regulated tables; no bulk writes
GRANT SELECT ON SCHEMA::gold TO [analyst_role];
DENY INSERT, UPDATE, DELETE ON SCHEMA::gold TO [analyst_role];

Audit Log Analysis¶

Every COPY INTO and external-table operation appears in the Fabric SQL audit. Monitor for unusual patterns.

// Detect bulk-load operations to or from external sources
FabricSQLAuditLogs
| where TimeGenerated > ago(24h)
| where StatementType in ("COPY", "BULK INSERT", "EXTERNAL TABLE", "OPENROWSET")
| where StatementText !contains "stcasinoprod"  // exclude approved sources
    and StatementText !contains "stfederalprod"
| project TimeGenerated, UserPrincipalName, WorkspaceName, DatabaseName,
          StatementType, StatementText, RowsAffected, ClientIP
| order by TimeGenerated desc

📤 Power BI Export Restrictions¶

Power BI's "Export to Excel" / "Export to CSV" is the most common accidental and intentional exfiltration vector for analytics data. Lock it down by default; allow it only for non-regulated workspaces.

Tenant-Wide Settings¶

In the Fabric Admin Portal → Tenant settings:

Sensitivity Labels with Protection¶

Apply Microsoft Information Protection labels with encryption + content-marking + access restrictions to regulated reports.

When a user opens an Excel file that was exported (before label tightening), MIP encryption keeps the file readable only to authorized identities — even if it leaves the tenant.

Persona — BI Consumer View-Only¶

The standard pattern for casino floor managers, federal field staff, healthcare clinical reviewers:

The user can interact with reports and dashboards but cannot move data anywhere.

📓 Notebook Download Restrictions¶

A .ipynb file with cell outputs can contain thousands of rows of regulated data — a single download can be a major breach.

Workspace Policy: Disable Download¶

Configure at workspace level (Settings → Security → Item Export):

Cell-Output Hygiene¶

For workspaces where download must be allowed, train and code-review for:

# ❌ Anti-pattern: large display() calls leave regulated data in cell output
display(spark.table("lh_gold.player_master"))

# ✅ Pattern: redacted display
df = spark.table("lh_gold.player_master")
display(df.limit(10).select("player_id", "join_date"))  # exclude PII columns
print(f"row_count={df.count()}")  # aggregate only

A pre-commit linter or CI check can flag display(...) and .show() of tables tagged Confidential.

Workspace Identity for Notebook Execution¶

Notebooks should authenticate to OneLake and external connectors via Workspace Identity (managed identity), not via embedded secrets. This eliminates the "hard-coded SAS token in notebook → leaked notebook → durable credential exposure" path.

# ✅ Workspace Identity — no credential in notebook
from notebookutils import mssparkutils
df = spark.read.format("delta").load(
    "abfss://gold@stcasinoprod.dfs.core.windows.net/player_master"
)

# ❌ Anti-pattern — embedded SAS token, leaks if notebook is downloaded
sas = "?sv=2023-01-01&ss=b&srt=co&sp=rwdlac&se=2026-12-31..."
df = spark.read.format("delta").load(
    f"https://stcasinoprod.blob.core.windows.net/gold/player_master{sas}"
)

🌐 Cross-Tenant Sharing Controls¶

Cross-tenant B2B sharing is a major exfiltration path because once data crosses tenants, your DLP/labels travel only if MIP encryption is enforced and the receiving tenant honors it.

Tenant-Level B2B Settings¶

In Entra ID → External Identities → Cross-tenant access settings:

External User Policy¶

In Fabric Admin Portal → Tenant settings:

Data Residency¶

Casino, federal, and healthcare workloads frequently have data residency requirements. Cross-tenant sharing can move data to tenants in other regions.

• Pin storage to in-region regions (US Gov for federal)
• Tag workspaces with dataResidency: us-gov
• Conditional Access: block sign-in to in-scope workspaces from non-approved geographies
• Sensitivity label: Region-Locked: US-Only with named-group encryption

🔍 DLP Integration (Microsoft Purview)¶

Microsoft Purview Data Loss Prevention extends content-aware policies to Fabric. Purview DLP can scan content and trigger actions when sensitive patterns are detected.

Trigger Conditions¶

Common DLP rules for Fabric:

Block / Warn / Audit Modes¶

DLP policies progress through enforcement modes:

The recommended path: deploy in audit-only for 30 days, tune rules, promote to warn for 30 days, then block.

DLP Policy Example (Purview)¶

policy:
  name: Casino-Financial-Bulk-PII-Block
  scope:
    fabric_workspaces:
      - ws_casino_prod
      - ws_casino_compliance
  conditions:
    - any_of:
        - sensitive_info_type: U.S. Social Security Number
          min_count: 5
        - sensitive_info_type: Credit Card Number
          min_count: 10
        - keyword_dictionary: ctr_sar_terms
          min_count: 3
  actions:
    - block_export: true
    - block_share_external: true
    - notify_user:
        message: "This dataset contains regulated financial PII and cannot be exported."
    - notify_admin:
        recipients: ["security-ops@contoso.com"]
        severity: high
    - log_event: true
  exceptions:
    - role: "compliance-officer"
      requires_justification: true

🏷️ Sensitivity Label Enforcement¶

Sensitivity labels are the substrate the entire exfiltration program rides on. Without labels, DLP cannot decide what to protect, and audit cannot determine severity of an event.

Auto-Labeling¶

Auto-label policies inspect content and apply a label when patterns match:

Inheritance Through Medallion¶

Labels should propagate from raw → curated layers. Configure Purview to enforce inheritance.

# Pseudocode — verify label propagation in CI
def test_label_inheritance():
    bronze_label = purview.get_label("lh_bronze.player_transactions")
    silver_label = purview.get_label("lh_silver.player_transactions_clean")
    gold_label   = purview.get_label("lh_gold.player_kpi")
    # Silver and Gold must be at least as restrictive as Bronze
    assert label_rank(silver_label) >= label_rank(bronze_label)
    assert label_rank(gold_label)   >= label_rank(bronze_label)

Protection Actions¶

Each label has content-marking (visible) and protection (cryptographic) settings:

The user-identity watermark is critical: any screenshot taken of a regulated report can be traced back to the viewer.

📈 Egress Monitoring¶

Detection assumes prevention will fail. Monitor for the patterns prevention couldn't stop.

KQL — Unusual Download Patterns¶

// Single user downloading large volume from a Lakehouse in a short window
FabricActivityLogs
| where TimeGenerated > ago(1h)
| where Activity in ("ExportReport", "DownloadFile", "ExportToExcel", "DownloadNotebook")
| extend RowsExported = tolong(coalesce(ActivityDetail.rowCount, "0"))
| summarize TotalRows = sum(RowsExported), Events = count(),
            Items = make_set(ItemName)
    by UserId, WorkspaceName, bin(TimeGenerated, 5m)
| where TotalRows > 10000 or Events > 20
| order by TotalRows desc

KQL — Off-Hours Activity¶

// Privileged user activity outside business hours
let business_hours = range(7, 19); // 7am-7pm
FabricActivityLogs
| where TimeGenerated > ago(7d)
| extend HourOfDay = datetime_part("hour", TimeGenerated)
| where HourOfDay !in (business_hours)
| where Activity in ("ExportReport", "ExportToExcel", "DownloadFile",
                     "ShareReport", "CreateShortcut")
| summarize Events = count() by UserId, Activity, bin(TimeGenerated, 1d)
| where Events > 5
| order by Events desc

KQL — First-Time-Download¶

// Detect when a user downloads a report for the first time ever
let baseline = FabricActivityLogs
| where TimeGenerated between (ago(180d) .. ago(1d))
| where Activity == "ExportReport"
| distinct UserId, ReportId;
FabricActivityLogs
| where TimeGenerated > ago(1d)
| where Activity == "ExportReport"
| join kind=leftanti baseline on UserId, ReportId
| project TimeGenerated, UserId, ReportId, WorkspaceName

Sentinel Detection Rules¶

Promote the highest-fidelity KQL queries into Microsoft Sentinel analytic rules:

Alert Thresholds¶

⚠️ Tune to your environment. A 10,000-row threshold may be normal for a finance analyst building a forecast. The threshold matters less than the delta from that user's baseline. UEBA does this automatically.

🕵️ Detective Controls¶

User Behavior Analytics (UEBA)¶

Microsoft Defender for Cloud Apps (MCAS) and Microsoft Sentinel UEBA produce per-user behavioral baselines. Anomalies that warrant alerts:

Volume-Based Anomaly Detection¶

Compare each user's current hour to their median hour over 30 days. Alert when the current hour is > 5x median or > 95^th-percentile.

# Concept: per-user export-volume z-score
SELECT user_id, current_hour_rows,
       (current_hour_rows - median_30d_hour) /
       NULLIF(stddev_30d_hour, 0) AS z_score
FROM exfil_baseline
WHERE z_score > 3
   OR current_hour_rows > p95_30d_hour;

First-Time-Download Alerts¶

When a user opens a report or table they've never accessed before AND immediately exports it, that is a high-fidelity signal even at low volume.

👁️ Insider Threat Patterns¶

Insider exfiltration follows known behavioral patterns. Couple HR signals (resignation date, HR-flagged employees) with technical signals where lawful.

Pre-Resignation Behavior¶

Common signals in the 30 days before an insider resigns or is terminated:

⚠️ Legal scope. Pre-resignation monitoring requires HR partnership, written workforce policy, and (in many jurisdictions) prior notice in employment agreements. Engage legal before deploying.

Privileged User Oversight¶

Audit Trail Integrity¶

If the audit trail can be tampered with by the same insider you're trying to detect, it's not an audit trail. See audit trail immutability for:

• Immutable Blob storage (WORM)
• Log forwarding to a separate tenant
• Tamper-evident hashing (cryptographic chain)
• Privileged-access PIM gating around log deletion

🤝 Vendor / Third-Party Controls¶

Sub-processors (vendors who process your data) are exfiltration vectors at the contractual layer. Microsoft is one such sub-processor; so are any ISVs you integrate.

Data Processing Agreement (DPA) Requirements¶

Every vendor processing regulated data should have:

Sub-Processor Management¶

Maintain a register of every vendor with access to regulated data:

Right to Audit¶

For high-criticality vendors, exercise the audit clause periodically — even just a documentation review counts. Auditors will ask for evidence that this was done.

🎰 Casino Implementation¶

The casino domain handles NIGC MICS financial-reporting data, player PII, and CTR/SAR records. Exfiltration concerns:

Casino Configuration¶

Floor Staff: Zero Download Capability¶

The casino floor manager and surveillance team need real-time visibility but zero download capability. The pattern:

🏛️ Federal Implementation¶

DOJ — Restricted Access, No Export¶

Tribal Health — HIPAA, Encryption + Watermark on Every Export¶

SBA — Borrower PII, Opt-In for Sharing¶

USDA, NOAA, EPA, DOI — Tiered¶

🚫 Anti-Patterns¶

📋 Implementation Checklist¶

Before declaring "Data Exfiltration Prevention ready":

Network Layer¶

• OAP enabled on every regulated workspace with default-deny
• OAP allowlists reviewed quarterly with named owner
• OAP smoke test passes in CI for every workspace deployment
• Private Endpoints configured for all storage accounts
• Workspace IP firewall restricts to corporate ranges
• Managed VNet integrated where applicable

Identity Layer¶

• Conditional Access enforces MFA for all users
• Conditional Access enforces compliant managed device for regulated workspaces
• Entra PIM gates privileged access (just-in-time)
• Workspace Identity used for service-to-service authentication
• Quarterly access review process running
• B2B cross-tenant access default-deny with allowlist

Data Layer¶

• Sensitivity labels deployed (Public, Internal, Confidential, Highly Confidential)
• Auto-labeling rules in place for casino PII, CTR/SAR, PHI, federal CUI
• Label inheritance verified through medallion (CI test)
• CMK enabled for storage with rotation policy
• OneLake security row/column controls in place for confidential tables
• DLP policies promoted past audit-only mode

Application Layer¶

• Power BI export disabled tenant-wide for Confidential and above
• Notebook download disabled in regulated workspaces
• Lakehouse Files download disabled in regulated containers
• Print and forwarding restrictions on Highly Confidential labels
• Power BI subscription to external email blocked
• Cross-tenant sharing blocked by tenant policy

Audit & Detection Layer¶

• Workspace Monitoring enabled with ≥ 12-month retention
• Log Analytics retention ≥ 12 months for regulated workspaces (≥ 6 years for HIPAA)
• Sentinel UEBA enabled
• Sentinel analytic rules: bulk-export, off-hours, first-time-download, cross-tenant-share, OAP-block-burst
• Data Activator Reflex on OAP block bursts
• Logs forwarded to immutable storage in a separate trust boundary
• Audit trail immutability controls implemented

Process & Governance¶

• Pre-resignation monitoring policy reviewed by legal
• Sub-processor register current with DPAs on file
• DLP false-positive review monthly
• Insider-threat tabletop exercise run annually
• Workforce security awareness training completed
• Exfiltration-incident runbook current and tested

📚 References¶

Microsoft Resources¶

• Outbound Access Protection (Fabric)
• Microsoft Purview Data Loss Prevention
• Sensitivity Labels in Fabric
• OneLake Security Overview
• Microsoft Defender for Cloud Apps (UEBA)
• Microsoft Sentinel UEBA
• Conditional Access Documentation
• Cross-tenant access settings

Industry & Standards¶

• NIST SP 800-53 — AC-4 Information Flow Enforcement
• HIPAA Security Rule — 45 CFR §164.312
• FedRAMP Moderate Baseline
• NIGC MICS Standards
• Title 31 BSA — Currency Transaction Reports

Related Wave 5 Docs¶

• SOC 2 Type II Readiness — Wave 5 anchor
• Zero-Trust Blueprint
• STRIDE Threat Model
• Audit Trail Immutability
• GDPR Right to Deletion
• CCPA Privacy Rights
• ISO 27001 Mapping
• Supply Chain Security

Related Existing Docs¶

• Outbound Access Protection
• Network Security
• Customer-Managed Keys
• Data Governance Deep Dive
• Identity & RBAC Patterns
• SQL Audit Logs Compliance
• OneLake Security (feature)

⬆️ Back to Top | 📚 Security Index | 🏠 Home