10.2 Selecting and Configuring Access to Azure Files

Choosing an Access Method

Azure Files is the only Azure Storage service where the protocol determines the security model, so start there.

The decision tree the exam expects:

• Windows file shares that need per-user permissions → SMB with identity-based authentication.
• Lift-and-shift Linux workloads needing POSIX semantics → NFS 4.1 on premium, secured with private endpoints and network rules because there is no user identity.
• Applications rather than users → REST with a managed identity and the data-plane RBAC roles.

---

Identity-Based Authentication over SMB

Using the storage account key for SMB means every user who mounts the share is the same super-user. Identity-based authentication replaces that with real principals.

The two-layer permission model

This is the part candidates get wrong.

1. Share-level permissions = Azure RBAC. Assigned on the file share (or storage account) scope:
   • Storage File Data SMB Share Reader — read.
   • Storage File Data SMB Share Contributor — read, write, delete.
   • Storage File Data SMB Share Elevated Contributor — read, write, delete plus modify NTFS ACLs. You can also set a default share-level permission on the storage account so all authenticated identities receive a baseline role instead of assigning each one.
2. Directory and file permissions = Windows NTFS ACLs, set from a domain-joined client with icacls or File Explorer, and preserved through robocopy migrations.

Effective access is the intersection: RBAC must let you onto the share, and the NTFS ACL must let you touch the file. A user with Elevated Contributor but a Deny NTFS ACL still cannot read the file.

For REST/SDK access the roles are different again — Storage File Data Privileged Contributor / Reader bypass NTFS ACLs for administrative tooling, which is why they should be tightly held.

---

NFS 4.1 Shares

NFS shares behave differently in ways that show up as exam discriminators:

• Require the premium FileStorage account kind with the NFS protocol chosen at share creation; you cannot switch protocols later.
• No identity-based authentication. Access control is entirely network-based: place the account behind a private endpoint or restrict it to selected virtual networks, then rely on POSIX UID/GID inside the share.
• The "Secure transfer required" setting must be disabled for the account, because the NFS 4.1 configuration used by Azure Files does not carry the encryption that setting enforces. This makes network isolation mandatory rather than optional — the traffic is not encrypted in transit.
• Public network access should be disabled outright.

If a scenario says "Linux workload, must be encrypted in transit, must authenticate users" the answer is SMB with identity-based authentication, not NFS.

---

Network, Encryption, and Data Protection

• Private endpoints give the share a private IP and a privatelink.file.core.windows.net DNS record. Combine with public network access disabled.
• Service endpoints plus firewall rules are the lighter-weight alternative when a private endpoint is not viable.
• Port 445 egress is blocked by many ISPs and corporate firewalls — the standard cause of "cannot mount from home". Azure File Sync or a VPN/ExpressRoute path is the remediation, not opening 445 to the internet.
• SMB security settings on the account let you restrict allowed SMB versions, authentication mechanisms (Kerberos only), and channel encryption strength. Requiring AES-256-GCM and disabling SMB 2.1 is the hardened baseline.
• Encryption at rest is always on with Microsoft-managed keys; switch to customer-managed keys in Key Vault when policy demands, and enable infrastructure encryption at account creation for double encryption.
• Data protection: enable soft delete for file shares (retention in days) so a deleted share is recoverable, take share snapshots for point-in-time copies, and use Azure Backup for scheduled, policy-driven protection with its own vault-level controls.