Configure security and governance

Fabric security is layered. Start with identity, then determine the required scope—workspace, item, or data—and grant the least privilege at that scope. Governance features such as sensitivity labels and endorsement describe and manage data; they do not silently replace authorization.

Objective coverage

Implement workspace-level access controls

Workspace roles are Admin, Member, Contributor, and Viewer. They apply broadly to items in the workspace and include authoring or administration capabilities according to role. Use security groups rather than many individual assignments, and reserve Admin for principals that truly manage the workspace.

A role assignment is not the same as a data permission. Fabric evaluates control-plane and data-plane paths, and item types can enforce additional SQL, semantic-model, or OneLake rules. Test the actual access route the user will employ.

Implement item-level access controls

Item sharing grants access to a specific item without placing the recipient in the entire workspace. Use it when a consumer needs a lakehouse, warehouse, report, or other supported item but should not discover or modify unrelated content. Item owners can manage permissions through the item, while workspace roles may already confer broader rights.

The least-privilege order is useful: first ask whether data can be served through a curated report or model; next consider item sharing; use a workspace role only when collaboration across the workspace is intended. Revoke stale direct shares and prefer groups for durable ownership.

Implement row-level, column-level, object-level, and folder/file-level access controls

These controls protect different dimensions:

RLS and CLS are enforcement, while a view is an interface. A view that omits a sensitive column is helpful, but protect the base object so an alternate query path cannot bypass the intended boundary. Evaluate SQL endpoints, Spark, Direct Lake, shortcuts, and OneLake APIs because enforcement support can differ by route.

Example RLS pattern in a warehouse:

CREATE FUNCTION Security.fn_region(@RegionCode char(2))
RETURNS TABLE WITH SCHEMABINDING AS
RETURN SELECT 1 AS allowed
WHERE @RegionCode = CAST(SESSION_CONTEXT(N'region') AS char(2));

CREATE SECURITY POLICY Security.RegionPolicy
ADD FILTER PREDICATE Security.fn_region(RegionCode) ON Sales.OrderFact
WITH (STATE = ON);

The exact identity mapping must be designed and tested; the predicate alone does not establish a trustworthy user-to-region assignment.

Implement dynamic data masking

Dynamic data masking (DDM) changes query results for users without the UNMASK privilege; it does not change stored values. Fabric Warehouse supports default, email, random, and custom-string masks as documented for supported data types.

ALTER TABLE dbo.Customer
ALTER COLUMN Email varchar(320) MASKED WITH (FUNCTION = 'email()');

DDM reduces accidental exposure in ordinary queries. It is not encryption and is not a strong boundary against a user who can infer values through repeated predicates or joins. Combine it with RLS, CLS, object permissions, and least privilege.

Apply sensitivity labels to items

Sensitivity labels come from Microsoft Purview Information Protection. A tenant administrator enables their use, and labels must be published to the relevant users. Depending on supported item and path, Fabric can apply defaults, require labels, inherit labels downstream, and carry them into supported exports.

Do not equate a label with universal access control. Labels classify content and can invoke protection in documented cases, but access control is unsupported in other routes and cross-tenant scenarios. Verify the current item and export-path matrix.

Endorse items

Endorsement helps users identify trustworthy assets:

Endorsement improves discovery and trust signaling. It does not grant permission, encrypt data, or prove that every downstream use is correct.

Implement and use Microsoft Fabric audit logs

Fabric user activities are available through Microsoft Purview Audit. Search by time, user, operation, workload, or item context; export results for a documented investigation when needed. Audit records answer who performed which recorded action and when. Diagnostic and workload logs answer different operational questions.

Establish retention, reviewer roles, alerting criteria, and an evidence-handling procedure before an incident. A missing result can reflect retention, licensing, ingestion delay, filter choice, or an activity not represented by the searched operation—not necessarily proof that nothing happened.

Configure and implement OneLake security

OneLake security roles provide data access for selected tables or folders. A role can include members and define read or read/write permissions at paths, allowing data access without broad workspace authoring rights. Plan roles around job functions and stable groups.

Evaluate access as a path:

1. Does the principal have access to the Fabric item or relevant endpoint?
2. Which workspace or item permission applies?
3. Which OneLake security role and path applies?
4. Is a downstream engine enforcing another policy?
5. Does a shortcut introduce source credentials or source-side security?

Test with representative users, including denied cases. Administrators and item owners can have elevated rights that make their tests misleading.

Build an access decision from the outside in

Workspace roles define a broad collaboration boundary. Admin manages the workspace and access; Member collaborates broadly and can manage many workspace capabilities; Contributor creates and changes content; Viewer primarily consumes. Admin, Member, and Contributor are elevated identities for OneLake because their workspace rights include write access. A narrow OneLake read role therefore cannot be used to reduce the data rights already granted by one of those broader workspace roles.

Inventory people, service principals, and groups; assign each to a job function; and grant the lowest workspace role that permits the required collaboration. Prefer Microsoft Entra security groups so joiner, mover, and leaver changes occur in one identity system. Separate administration from content development, keep at least two governed owners, and review assignments periodically. Validate with a user who has no overlapping group membership. For services, document the identity, credential owner, rotation method, allowed workspace, and exact jobs.

Choose a workspace role only when the identity needs capabilities across the workspace. Do not grant Contributor merely to let a consumer query one table; use item and data permissions. Conversely, repeated direct shares across most items are a signal that the person may genuinely belong in the workspace. The failure mode to avoid is permission accumulation: a user receives narrow access directly but also inherits broad access through a workspace group, so a test of the narrow policy appears ineffective.

Scenario. Data engineers belong to a Contributor group, the platform team uses a small Admin group, and report consumers are not workspace members. A contractor who needs one lakehouse is shared that item and assigned a narrow OneLake role. Test the contractor, a Contributor, and an unassigned account. The contractor should not discover unrelated workspace items; the Contributor will still have broad OneLake rights. This three-identity test is more informative than testing only as the workspace owner.

When access is unexpectedly allowed, enumerate every workspace role and group, direct item permission, OneLake role, SQL grant, semantic-model role, and cached session. When access is denied, check the same layers in order plus tenant settings and endpoint-specific prerequisites. Remove ambiguity by using a fresh test identity and a private browser session. Record both positive and negative tests; “the administrator could open it” is not evidence of least privilege.

Item permissions and the data plane

Item permissions answer “may this identity interact with this item?” but not always “may it read every underlying row through every engine?” Read commonly exposes item metadata. Additional permissions such as ReadData or ReadAll govern documented compute or OneLake routes for supported items. A report, semantic model, SQL endpoint, and lakehouse can therefore participate in one experience while enforcing different permissions.

Start at the consumer experience and trace backward: report → semantic model → SQL endpoint or OneLake table → source or shortcut target. Grant the report or item permission first, then only the downstream data permission the intended route requires. Use Manage permissions to inspect direct grants and reshare rights. Avoid granting build, write, or reshare unless the user must create new content or delegate access. Re-test after removing a grant because tokens and sessions can temporarily obscure the result.

Use a curated report when consumers need answers, item sharing when they need a specific reusable item, and workspace membership when they participate in the workspace lifecycle. Granting ReadAll for OneLake access is materially different from granting basic Read metadata access. Direct Lake also requires careful reasoning about which identity and fallback path performs the query. Never infer the data plane solely from whether the item appears in navigation.

Worked access trace. Lee can open a report but receives an error when connecting directly to the lakehouse SQL endpoint. That can be correct: the report path may be authorized through its semantic model while direct SQL data access was never granted. If the requirement is report consumption only, do not “fix” the result with Contributor. If direct analysis is required, grant the documented endpoint permission and test a permitted and forbidden table.

Classify the failing action precisely: discover item, open item, query SQL, read OneLake, build a semantic model, write data, or reshare. Each action points to a different permission. Examine group expansion and inherited workspace roles before adding another direct grant. A mini-lab should create a matrix of three users by four actions and predict each outcome before testing it.

Data-level controls

Object or folder security chooses the tables, schemas, or paths a role can reach. Column security removes selected attributes. Row security applies a predicate to records. These controls can be combined, but OneLake roles use a grant model: a restrictive role does not deny access obtained from another role or permission path. Engine-native SQL or semantic-model security may have different authoring and enforcement surfaces, so identify the query route in every design.

Define access from a business policy, not from the current folder layout. Create roles for stable functions, grant only required tables or folders, then apply row and column rules where supported. Use immutable business keys and a governed identity-to-scope mapping for dynamic row filtering. Validate Spark, SQL, Direct Lake, and OneLake API paths that are actually in scope. Test nulls, multiple group memberships, new rows, schema changes, and an identity that should see nothing.

Prefer object or folder grants when whole datasets differ by audience. Use CLS when a column must not be visible, RLS when records differ by user context, and a curated view when a stable consumer contract or derived logic is needed. Masking is not a substitute for removing a sensitive column. Avoid elaborate per-user roles; group-driven roles and mapping tables scale better and are auditable. Check current feature support before assuming the same rule is enforced by every Fabric engine.

Worked policy. Regional analysts may read Sales.OrderFact only for their region and must not see Customer.Email; finance may read all regions and the email column. Create separate group-based roles, apply the region predicate to the analyst role and exclude or restrict Email, then test an analyst in two regions, finance, and an unassigned user. Adding an analyst to Contributor would invalidate the intended OneLake restriction and should be caught by the test.

If a filter appears bypassed, look for broad workspace write, another granting role, ownership, a different engine, or a cached result. If a query fails, distinguish inability to reach the item from denial at table, column, or row evaluation. Use a minimal query against one known object and progressively add columns and predicates. Preserve the identity, endpoint, query, expected rows, actual rows, and effective memberships as security-test evidence.

Masking, classification, trust, and evidence

Dynamic data masking is a presentation control evaluated at query time for principals without UNMASK. Configure a supported mask on the target column, grant ordinary query access to a test role, and compare results with and without UNMASK. Choose a mask that reduces accidental exposure without misleading users about the data type. Because values remain unchanged and inference can be possible, use encryption, RLS, CLS, or denied object access for true confidentiality boundaries. Troubleshoot by checking the querying principal, UNMASK grants, object permissions, endpoint, and supported type.

Sensitivity labels classify an item according to organizational information protection policy. Prerequisites include tenant configuration, labels published to the author, and a supported item or propagation path. Choose a label based on the data's policy classification, not the item's popularity. Apply it, verify the displayed label and any documented downstream inheritance or export behavior, and test the relevant route. A label can persist as governance metadata or invoke supported protection, but it is not evidence that workspace, item, and data permissions are correct. If a label is unavailable, inspect Purview publication, licensing, tenant settings, user scope, and item support.

Endorsement describes organizational trust. Owners can promote suitable items; authorized reviewers certify items or designate master data according to the organization's governance process. Define criteria—owner, documentation, quality checks, freshness, security review, and support contact—before applying a badge. Review it when those facts change. Certification does not grant access or guarantee that a consumer's interpretation is valid. If endorsement options are missing, verify write permission, tenant configuration, and designated certifier status.

Fabric audit evidence is searched through Microsoft Purview Audit. Establish the investigation question and time zone, then query an appropriate time range, users, operations, and workload context. Preserve exported results with the query criteria and investigation record. Audit is for recorded user and admin activity; Monitoring hub and workload logs explain operational executions. Account for retention, licensing, ingestion delay, operation naming, and clock boundaries before concluding an event is absent. As a mini-lab, perform a benign item-share change, wait for ingestion, locate its audit record, and compare what the audit event tells you with what the item's current permission page tells you.

OneLake security roles grant supported table and folder access within a data item. The author needs the documented Fabric Write or Reshare capability, and role members should be stable groups where possible. Create the role, choose Read or ReadWrite as required, select data objects, apply optional row or column filters, assign members, and test through the intended engine. Default roles can map documented item or workspace permissions to data access. Because grants are additive, always inspect other roles and broad workspace rights when a user sees too much. For a shortcut, evaluate both the OneLake reference and the remote source identity or credential path.

For exam scenarios, separate four verbs: authorize with workspace, item, and data permissions; obscure returned values with masking; classify with a sensitivity label; signal trust with endorsement. Then distinguish audit evidence from operational monitoring. A request for “one table only” points away from Contributor and toward item plus OneLake data permissions. A request to hide rows by region points to RLS, not a label or mask.

Recall and mini-lab. Why can a Contributor bypass the intent of a narrow OneLake read role? What additional capability does a user need when Read allows item discovery but not direct data access? Contrast CLS with DDM in one sentence. Explain why Certified and Confidential answer different questions. Finally, design a five-row access matrix for an administrator, engineer, analyst, report-only consumer, and unassigned user; include at least one denied test for workspace, item, SQL, and OneLake access.

Security scenario drills

Report consumer versus direct lake access

Nora must view a governed Power BI report but must not browse lakehouse files or query its SQL endpoint. Share the report/app through the supported consumption path and provide only the semantic-model/report permissions that path requires. Do not add Nora as Contributor and do not grant ReadAll merely because the report uses OneLake-backed data. Test report rendering, build/export behavior as required, direct SQL, direct OneLake, unrelated item discovery, and reshare.

If the report works but direct SQL fails, that may be the intended least- privilege outcome. If the report fails, trace the semantic model's connection, identity, Direct Lake/fallback behavior, model security, and source permissions instead of granting a broad workspace role. Record the successful consumer path and every denied alternate route.

Regional analysts with protected attributes

Analysts may see orders only for assigned regions and must not see personal email; Finance may see all regions and email. Start with group-based identities and ensure analysts do not inherit Admin, Member, or Contributor. Grant the appropriate item/data access, implement a region policy using a governed identity-to-region mapping, and use CLS/object design to remove Email from the analyst path. DDM may reduce accidental display but is not the primary boundary.

Test an analyst in one region, an analyst assigned to two regions, Finance, an unassigned user, a null/unknown region, and Spark/SQL/Direct Lake routes in scope. Count expected versus actual rows and columns. If an analyst sees everything, inspect additive OneLake roles and workspace write before rewriting the RLS predicate.

Labeled and certified does not mean authorized

A curated lakehouse is labeled Highly Confidential and certified as the trusted source. A new user still cannot open it. This is consistent: the sensitivity label classifies and may protect supported flows; certification signals that an authorized governance process trusts the asset; neither grants the user an item or data permission. Determine the business requirement and grant the narrow workspace/item/OneLake or endpoint permission only if approved.

Conversely, a user with access can still mishandle content if the label/export route is not supported or organizational policy is absent. Test the exact item, downstream inheritance/export path, and access separately. Review certification when owner, quality, freshness, security, or documentation changes.

Audit an unexpected permission change

A restricted table became readable to a contractor. Preserve the observation, identity, time zone, item, endpoint, and current effective memberships. Search Purview Audit over an appropriate window for share, permission, role, or group- related operations available to the investigation; export with query criteria. Compare audit history with current workspace roles, direct item grants, OneLake roles, SQL/model roles, and Entra group membership.

Audit can show recorded actions but may not encode the entire present effective- permission calculation, and absence can reflect retention, ingestion delay, or filter choice. After removing the unintended grant, re-test denied and approved users, identify the control gap, and add periodic access review or alerting. Keep sensitive audit evidence under restricted investigation handling.

Shortcut across security boundaries

A lakehouse shortcut points to an external storage account. The shortcut object, Fabric item, OneLake role, connection identity, and source ACL all participate. Granting the user access to see the lakehouse does not necessarily authorize the target, and a workspace Contributor can be broader than the intended narrow role. Document whether access uses a shared connection, delegated identity, or another supported credential route.

Test an owner, intended reader, denied reader, and expired/rotated connection. Deleting the shortcut removes the reference, not external data. Sensitivity and endorsement should be reviewed for the exposed Fabric item, but neither repairs the underlying authorization path.

Capstone: governed analytics workspace

A health-services analytics team (using synthetic exam data) needs engineers to build, regional analysts to query only their region, executives to consume one report, and an external auditor to inspect access-change evidence for a limited period. Design the boundary before assigning roles.

Place engineers in an Entra group with Contributor only in the development workspace. Keep workspace Admin and Member groups small and separate. Analysts and executives should not become Contributors in Production. Share the required warehouse/lakehouse or semantic/report item and grant the documented data path: regional row policy plus protected columns for analysts; report-only consumption for executives. Give the audit investigator controlled Purview Audit access and an evidence export location, not broad data authoring.

Classify sensitive items through published Purview labels and verify supported inheritance/export routes. Certify the curated semantic model only after owner, source, quality, freshness, security, documentation, and support criteria pass. Certification signals trusted reuse; the label communicates sensitivity; the permission layers enforce access.

Expected access matrix

“Elevated” is a warning in the matrix: administrators and Contributors are poor negative-test identities because workspace write can supersede narrow OneLake grants. Test each persona with clean membership and record effective groups, endpoint, action, expected and actual result.

Changes and investigation

Simulate four events: an analyst changes region, an engineer leaves, a label is changed, and an unintended direct item share is added. Group-driven regional mapping and engineer access should update through governed identity processes. The label change follows information-protection policy and review. The direct share should be discovered through access review and investigated through the relevant audit activities and current effective-permission state.

Preserve audit query criteria, UTC/local time interpretation, operation/user/item identifiers, exported evidence, and investigator. Remove the unintended share, retest both allowed and denied paths, and add a preventive control. Do not infer from a missing search result that no change occurred until retention, ingestion delay, licensing, operation naming, and filters are considered.

Acceptance evidence

The capstone passes when least-privilege groups and owners are documented; workspace, item, OneLake/SQL/model policies form one traced path; regional and column tests include denied cases; direct lake access remains unavailable to report-only users; label and endorsement behavior is verified separately from authorization; shortcut/source credentials are owned and rotated; and a benign permission change can be found, explained, remediated, and retested.

Exam distinctions

• Workspace roles are broad collaboration grants; item permissions are narrower.
• RLS filters rows; CLS restricts columns; OLS restricts objects; OneLake roles restrict tables or paths.
• DDM changes displayed results, not stored data, and is not encryption.
• Sensitivity labels classify and can protect supported flows; endorsement signals trust.
• Audit logs, OneLake diagnostics, and workload execution logs have different purposes.
• A OneLake shortcut can expose a reference while source-side security and credentials still matter.

Active recall

1. Why is Viewer not a universal statement about every data access path?
2. When is item sharing preferable to workspace membership?
3. Which control hides a column entirely, and which only masks its returned value?
4. What is the difference between Certified and a sensitivity label?
5. Which identities should be used for negative access tests?
6. Where would you investigate a recorded item-deletion activity?

Authoritative sources

• Fabric permission model
• OneLake data access control model
• Dynamic data masking in Fabric Data Warehouse
• Information protection in Fabric
• Endorsement overview
• Track user activities in Microsoft Fabric
• Official DP-700 study guide