OneLake gives Microsoft Fabric a unified storage foundation, but unified storage does not mean unrestricted storage. As more lakehouses, warehouses, semantic models, and shortcuts share the same analytical platform, security must answer two different questions: who may manage an item, and what data may that person actually read or change? Treating those as separate control planes is essential to building a governed Fabric estate.<\/p>\n
The current DP-600<\/a> role includes securing and maintaining analytical assets, while DP-700<\/a> includes data-engineering security and operations. OneLake security sits underneath both roles because storage-level access can affect engineering tools, SQL analytics, notebooks, semantic models, and direct file access.<\/p>\n A durable governance design combines identity, workspace permissions, item sharing, OneLake data roles, row and column controls, lineage, labels, auditability, and ownership. No single setting can carry the entire security model.<\/p>\n Fabric uses workspace roles and item permissions to govern management actions such as creating, configuring, sharing, and administering items. OneLake security governs access to the underlying data itself. Keeping those layers distinct prevents a common mistake: assuming that someone who can interact with a workspace automatically needs broad access to every row and file stored there.<\/p>\n A platform administrator may need the ability to manage capacity and workspace configuration without reading restricted finance data. A data steward may need to manage access policies without editing notebooks. An analyst may need read access to a curated gold table while having no reason to see raw customer extracts. Architecture should express those differences explicitly.<\/p>\n This separation also makes reviews clearer. Control-plane reviews ask who can administer and share. Data-plane reviews ask who can see or change data. Combining them into one generic \u201caccess\u201d discussion hides risk.<\/p>\n OneLake access is tied to Microsoft Entra identities such as users, groups, and nonuser identities. Group-based assignment is usually easier to operate than granting rights to individuals one at a time. A group can represent a business function, project team, application identity class, or approved consumer population and can be reviewed centrally.<\/p>\n Use groups that reflect real ownership and responsibility. A broad \u201cAll Analysts\u201d group may be convenient, but it becomes difficult to justify when some datasets contain regional, legal, or contractual restrictions. More precise groups can support least privilege without creating hundreds of one-off assignments.<\/p>\n Service principals and managed identities deserve the same discipline as human users. Pipelines, notebooks, and external applications should receive only the permissions required for their task. Nonuser identities are often long-lived and automated, so excessive rights can create persistent exposure.<\/p>\n OneLake security uses role-based access control to grant access to supported Fabric data. Roles can define permissions and scope them to the relevant data, with members assigned through Entra identities. Microsoft documents a deny-by-default approach for OneLake security, which supports least-privilege design when roles are planned deliberately.<\/p>\n Object-level decisions come first. Does a consumer need the whole lakehouse, a schema, a table, or a folder? Grant the smallest useful scope. Broad permissions are easy to issue and hard to retract after downstream processes begin depending on them.<\/p>\n Data access should follow the published product contract. A gold sales table intended for corporate analysts can have broader readership than a bronze landing area containing source identifiers and unfiltered personal data. Security becomes simpler when the data architecture already separates audiences.<\/p>\n Whole-table access is often too coarse. OneLake security can refine supported data access with row-level and column-level controls. Row-level security can restrict which records a member sees, while column-level security can hide sensitive fields that should not be exposed to that audience.<\/p>\n For example, a regional operations group may read only records for its region, while a support team may need customer case data without financial attributes. Designing those policies close to the data can reduce the number of duplicate, manually filtered datasets that teams create solely for security.<\/p>\n Fine-grained controls should remain understandable. Overlapping roles, complex filters, and multiple access paths can become difficult to reason about. Document the intended effective access and test it with representative identities. If operators cannot explain why a user can see a row, the policy model is too opaque.<\/p>\n Power BI semantic models can implement their own row-level security, which may be the right control for report consumption. Storage-level and semantic-model security solve related but different problems. A semantic role can shape what a report viewer sees, while OneLake security governs direct access to underlying data through supported engines and interfaces.<\/p>\n Do not assume semantic-model RLS protects raw storage. A user with a different access path may bypass the report entirely if storage permissions are too broad. Likewise, overly restrictive storage controls can break legitimate semantic-model or engineering workflows. Design the layers together.<\/p>\n The existing semantic-model design<\/a> discussion is relevant because security is part of the model contract, not an afterthought attached to a report. Decide whether a restriction belongs at storage, semantic, or both levels based on every supported access path.<\/p>\n Shortcuts are valuable because they allow data reuse without creating another full copy, but they also create a dependency between the producer’s security model and the consumer’s environment. Teams should understand which identity is evaluated, what permissions are enforced, and how changes at the source affect downstream access.<\/p>\n A shortcut should not become a convenient way around a source domain’s governance. If the producing team considers a dataset restricted, the consuming workspace should not make it broadly discoverable simply because the data appears as a local path. Governance responsibilities need to travel with the data product.<\/p>\n Record ownership and expected availability for shortcut-backed datasets. Security incidents and operational incidents become harder when no one knows which team controls the authoritative source.<\/p>\n Security policies are strongest when users can understand why data is sensitive and where it came from. Sensitivity labels, endorsed items, descriptive metadata, ownership information, and lineage give context that raw permissions do not. A user deciding whether to export a dataset needs to know whether it contains confidential data, not just whether the Export button is enabled.<\/p>\n Lineage also supports impact analysis. If a restricted source column feeds several lakehouse tables and semantic models, governance teams should be able to trace that propagation. A change to classification or retention policy can then be evaluated across consumers instead of handled as a manual search.<\/p>\n Catalog quality matters. Duplicate datasets with vague names encourage users to select whichever version they can access, which can undermine governance even when permissions are technically correct. Mark authoritative products and retire unsupported copies.<\/p>\n A governance program needs evidence of what happened, not only intended policy. Fabric and Microsoft 365 auditing capabilities can help teams review access and administrative activity, investigate incidents, and support compliance requirements. Audit design should start from questions the organization may need to answer later.<\/p>\n Useful questions include: who changed permissions on a sensitive item, when was a role membership modified, which application accessed a protected dataset, and which workspace published an externally shared artifact? Retention and review procedures should align with regulatory and internal requirements.<\/p>\n Logs are most valuable when ownership is clear. Define who reviews high-risk events, how alerts are escalated, and what evidence must be retained. Collecting activity without a response process creates visibility without governance.<\/p>\n Least privilege is easier to maintain when datasets are designed for specific audiences. Curated tables can remove unnecessary sensitive fields, aggregated products can reduce exposure, and separate workspaces can create stronger administrative boundaries. Security is then supported by architecture instead of relying on increasingly complex permission rules over a monolithic data store.<\/p>\n The general logic of dynamic access control<\/a> is useful even though OneLake has its own implementation: access should follow identity and policy, not informal assumptions about who \u201cnormally\u201d uses a system. The exact technology changes, but the principle of policy-driven authorization remains.<\/p>\n Avoid granting broad access \u201ctemporarily\u201d without an expiry or review. Temporary permissions often become permanent dependencies. If emergency access is required, record the reason, scope, owner, and removal date.<\/p>\n Data governance continues after access is granted. Define retention, deletion, legal hold, archival, schema-change, and deprecation processes. A sensitive table that no longer has a business purpose should not remain accessible indefinitely simply because storage is inexpensive.<\/p>\n Changes to schemas and security need coordination. Renaming a column used by a row-level rule or removing a table referenced by a role can cause failures or unintended access changes. Treat governance configuration as part of the deployment lifecycle and test it alongside data transformations.<\/p>\nSeparate control-plane permissions from data-plane permissions<\/h3>\n
Use Microsoft Entra identities as the basis for governed access<\/h3>\n
Apply OneLake security roles to the data that needs protection<\/h3>\n
Use row- and column-level controls for finer-grained access<\/h3>\n
Coordinate OneLake controls with Power BI semantic-model security<\/h3>\n
Protect shortcuts and shared data as cross-domain dependencies<\/h3>\n
Use labels, lineage, and catalog metadata to make governance visible<\/h3>\n
Audit access and administrative activity<\/h3>\n
Apply least privilege as an architectural principle<\/h3>\n
Govern data through its full lifecycle<\/h3>\n