Skip to main content

Operational Best Practices for Microsoft Fabric

Microsoft Fabric operational security builds on Azure’s established best practices but introduces domain-specific enhancements that align with the Fabric architecture and governance model. This chapter provides guidance for secure and resilient operations in Fabric Landing Zones.

Define and Deploy Strong Operational Practices​

Fabric environments must support the continuous evolution of operational models. Microsoft Fabric introduces deeply integrated monitoring, fine-grained access models, and multi-tenant awareness. Core pillars include:

  • Integration with Microsoft Defender for Cloud
  • Deployment tracking and CI/CD via Fabric CLI and GitOps
  • Entra ID-based access control for domains, workspaces, and artifacts
  • Workspace-level diagnostics and event routing

Reference: Azure Operational Security Best Practices

Enforce Multifactor Authentication (MFA)​

Fabric workspaces often contain highly sensitive business data. Enforce MFA for all users who can access:

  • Fabric workspaces
  • Lakehouse and Warehouse artifacts
  • Data Pipelines
  • Notebooks and Reports

We recommend using Conditional Access Policies (CAP) to tailor MFA challenges by risk level and identity type. Use Entra ID P2 for risk-based policies via Identity Protection.

Operational Security for OneLake and Domains​

Operational teams should:

  • Separate DevOps pipelines per domain to isolate blast radius
  • Use service principals with scoped permissions per workspace
  • Configure workspace-level Diagnostic Settings for audit logs
  • Use the fabric monitor CLI to ingest logs into Log Analytics or Sentinel

Secure DevOps Pipelines with the Fabric CLI​

The Fabric CLI should be treated as a privileged deployment interface. Follow these practices:

  • Use federated identity or workload identity federation (OIDC) for automation agents
  • Store CLI credentials in Azure Key Vault or GitHub Secrets
  • Use separate service principals per environment (dev, test, prod)
  • Enforce least privilege via Entra roles (e.g., Fabric Artifact Contributor)

Implement Operational Observability​

Monitor Key Resources​

Enable Fabric Monitoring for:

  • Lakehouses (data ingestion, refresh, latency, volume)
  • Warehouses (query performance, concurrency)
  • Pipelines (failure rate, duration)
  • Reports and Metrics (Power BI activities)

Use Kusto queries in Log Analytics or export events to Azure Event Hubs for integration with external SIEMs like Microsoft Sentinel.

YAML Diagnostic Configuration​

diagnosticSettings:
  - name: workspace-telemetry
    workspaceId: "/subscriptions/123/resourceGroups/rg-observability/providers/Microsoft.OperationalInsights/workspaces/logs-fabric"
    logs:
      - category: AuditLogs
        enabled: true
      - category: Usage
        enabled: true
    metrics:
      - category: AllMetrics
        enabled: true
    destinations:
      - logAnalytics
      - eventHub

Organize Management with Entra ID and Domains​

  • Assign admins at domain level via Entra groups
  • Use Microsoft Entra Privileged Identity Management (PIM) for JIT access
  • Tag each domain/workspace with cost-center, environment, data-owner

Automate Security Response and Compliance​

  • Integrate Defender for Cloud with Fabric resource types
  • Define alert rules for Fabric activities (e.g., failed login, policy bypass)
  • Route alerts to Microsoft Sentinel
  • Create playbooks to quarantine suspicious workspaces or revoke access

Integrate with Azure Policy​

While Fabric resources aren’t governed by Azure Policy directly, use metadata tagging and CLI validation scripts to enforce standards such as:

  • Required tags
  • Naming conventions
  • Allowed SKUs and configurations

Sample policy-as-code enforcement should be placed in DevOps pipelines.

Contributors