SYSM-362 - Getting issue details... STATUS
Assess shortcut from Azure (ADLSgen2) to Fabric
Compare access control mechanisms between Azure and Fabric for ADLS shortcuts
Evaluate security implications of ADLS Gen2 shortcuts in Fabric
- Latency consideration
Version | Date | Description | Contributor |
V0.1 |
| Initial document | COLOMBANI Théo |
SYSM-389 - Compare access control mechanisms between Azure and Fabric for ADLS shortcuts
| Dimension | Azure ADLS Gen2 | Fabric / OneLake |
|---|---|---|
| Main control model | Azure RBAC + ACL | Workspace roles + item permissions + OneLake security |
| Granularity | RBAC = broad, ACL = fine-grained | Workspace, item, folder, shortcut path |
| Effective access on shortcut | Target authorization in ADLS | Most restrictive combination of shortcut path and target path |
| Identity behavior | End-user / app identity in Azure | Usually passthrough, but some engines use owner identity |
| Key risk | Over-granted RBAC or non-Entra auth | Misunderstanding engine-specific behavior |
In ADLS Gen2, Azure RBAC provides coarse-grained control and ACLs provide fine-grained control. Shared Key and some SAS patterns do not rely on Microsoft Entra identity in the same way.
For shortcuts, Fabric applies the most restrictive permission between the shortcut path and the target path.
Key exception to document
| Scenario | Important behavior |
|---|---|
| DirectLake over SQL / T-SQL delegated identity scenarios | The engine may use the item owner identity to access the shortcut target, not the end-user identity. OneLake roles still filter what the user can see. |
Recommendation block
- Document Azure and Fabric as two control layers, not one.
- Use ACLs for fine-grained data access in ADLS.
- Test security behavior by engine, not only at shortcut creation time.
- Explicitly document the owner-identity exception for BI/query scenarios.
SYSM-388 - Evaluate security implications of ADLS Gen2 shortcuts in Fabric
| Check area | What to assess | Expected output |
|---|---|---|
| Authentication method | Organizational account, Service Principal, Workspace Identity, SAS, Account Key | Approved / Restricted / Forbidden list |
| Credential risk | Scope of access granted in ADLS | Risk level by auth method |
| Least privilege | RBAC vs ACL usage | Required minimum roles and ACL pattern |
| Firewall | Trusted Workspace Access requirement | Supported network pattern |
| Cross-tenant | Whether target storage is in another tenant | Supported / unsupported design |
| Engine behavior | Spark / SQL / semantic model differences | Security caveats by engine |
ADLS shortcuts use a delegated authorization model: access is authorized using the credential configured on the shortcut. Supported auth types are Organizational account, Service Principal, Workspace Identity, SAS, and Account Key. Microsoft warns that Account Key grants full access to the storage account.
Recommended decision table
| Authentication kind | Recommendation | Why |
|---|---|---|
| Workspace Identity | Preferred | No secret/certificate management; Microsoft positions it as a secure option. |
| Service Principal | Approved | Good for central IT-managed access and cross-tenant cases. |
| Organizational account | Limited use | More user-dependent; less suitable for stable platform patterns. |
| SAS | Exception only | Valid, but should be tightly scoped and governed. |
| Account Key | Avoid | Full storage account access. |
Recommendation block
- Prefer Workspace Identity by default.
- Use Service Principal for centralized managed access or cross-tenant scenarios.
- Avoid Account Key.
- Require ACL-based least privilege, not only broad RBAC.
- Validate firewall-enabled storage early.