DP-600 - Security and Governance

Workspace Roles

Workspace roles apply across all items in the workspace. Use Azure AD security groups for role assignments to simplify management. Avoid assigning individuals directly when groups are available.

Item-Level Permissions

Item-level permissions grant access to a single Fabric item without granting workspace membership:

Row-Level Security (RLS)

RLS restricts which data rows users can see in reports and queries.

Static RLS

// Role: "EastRegion"  -  only see East rows
[Region] = "East"

// Role: "SalesManager"  -  only see rows where Sales > 10000
[SalesAmount] > 10000

Dynamic RLS

// Each user sees only their own data via a mapping table
// UserSales table has columns: [UserEmail], [SalesPersonID]
[SalesPersonID] = LOOKUPVALUE(
    UserSales[SalesPersonID],
    UserSales[UserEmail], USERPRINCIPALNAME()
)

RLS setup steps:

1. Power BI Desktop: Modeling tab -> Manage Roles -> create role -> add DAX filter
2. Publish report and dataset to Service
3. Service: Dataset Settings -> Row-level security -> assign users/groups to roles
4. Test with: Service -> Dataset -> ... -> Test as role

Object-Level Security (OLS)

OLS hides entire tables or columns from users in specific roles. The object does not appear in the field list, and referencing it in a query causes an error.

OLS is configured using Tabular Editor (external tool, free edition available):

1. Open model in Tabular Editor from Power BI Desktop (External Tools ribbon)
2. Select a role -> navigate to table or column permissions -> set to None
3. Save and sync back to the model

Column-Level Security in Fabric Warehouse

In Fabric Data Warehouse, you can restrict column access using T-SQL permissions:

-- Deny access to specific columns for a role
DENY SELECT ON dbo.Customers (SSN, CreditScore, Salary) TO AnalystRole;

-- Grant access to all except restricted columns
GRANT SELECT ON dbo.Customers TO AnalystRole;
DENY SELECT ON dbo.Customers (SSN) TO AnalystRole;

Dynamic Data Masking is an alternative - it partially obfuscates column values for unauthorized users:

-- Mask all but the last 4 digits of SSN
ALTER TABLE dbo.Customers
ALTER COLUMN SSN ADD MASKED WITH (FUNCTION = 'partial(0,"XXX-XX-",4)');

Sensitivity Labels

Microsoft Purview Information Protection sensitivity labels classify Fabric content:

Key behaviors:

• Label inheritance: Reports and dashboards built on a Confidential dataset inherit the Confidential label
• Downstream propagation: Label stricter than upstream -> label stays; label less strict -> blocked by policy
• Export protection: Labels can enforce encryption when content is exported to .pbix, Excel, or PDF
• Audit logging: Label changes are logged in Microsoft Purview audit logs

Endorsement

Endorsed items appear with badges in the Fabric portal and rank higher in search results. Endorsement helps users discover trusted, curated data assets. Certified datasets are the gold standard for shared semantic models.

Deployment Pipelines

Deployment pipelines promote Fabric content through stages: Development -> Test -> Production, each mapped to a separate workspace.

Key concepts:

• Comparing stages: The pipeline UI shows a diff of what has changed between stages before deploying
• Selective deployment: Deploy specific items, not the entire workspace
• Deployment rules: Override data source connection strings, parameters, or gateway per stage - ensures Production points to the production database, not the dev database
• Automated deployment: Trigger deployments via REST API from CI/CD pipelines (Azure DevOps, GitHub Actions)

Git Integration

Fabric workspaces can be connected to an Azure DevOps or GitHub repository branch:

• Supported items: semantic models (TMDL), notebooks (.ipynb), data pipelines (JSON), dataflows, reports
• Changes made in Fabric are committed to the repo; changes in the repo are pulled into the workspace
• Enables pull request reviews before merging to the main branch
• Each workspace connects to exactly one branch; different branches map to Dev/Test/Prod workspaces

Semantic models stored in Git use TMDL (Tabular Model Definition Language) or PBIP format - a folder of files representing the model (tables, measures, roles, expressions) that can be code-reviewed and diff-compared in a PR.