Lock operators map \\account.file.core.windows.net\share by pasting the storage account key into Windows. Which access method should the security engineer select instead?
Select an answer to reveal the explanation.
Short Explanation
Stop pasting the silo key into every Windows map-network-drive dialog. Hook SMB up to AD DS, Entra Domain Services, or Entra Kerberos so operators sign in as themselves.
Full Explanation
Lock operators who map Azure Files by pasting the storage account key into Windows should instead use identity-based SMB authentication with on-premises AD DS, Microsoft Entra Domain Services, or Microsoft Entra Kerberos for hybrid identities. Identity-based auth lets operators sign in as themselves, supports share-level RBAC and NTFS ACLs, and removes the shared silo key from every map-network-drive dialog on gatehouse PCs. That is the sustainable access method for people and domain-joined clients in a canal authority.
Continuing to use the account key for SMB and storing it in a desktop sticky note for the shift fails by concept: shared keys are powerful, hard to attribute, and routinely leaked through local notes. Requiring anonymous public SMB mounts without credentials for faster gatehouse PCs fails by removing authentication entirely. Disabling Azure Files and copying share contents to public blob containers for drive-letter mapping fails because it abandons Files SMB identity controls and often increases public exposure rather than fixing authentication.
Exam caveat: identity-based Azure Files SMB supports AD DS, Entra Domain Services, and Entra Kerberos for hybrid identities; Private Endpoints may accompany hardening but do not replace identity-based auth. Operational check: enable the chosen identity source for the storage account, assign Storage File Data SMB Share roles, set NTFS ACLs on lock-plan directories, verify operators mount with their Entra or AD credentials without pasting the account key, and remove key-based mount instructions from the gatehouse runbook.