Securing Azure Storage
The course is part of this learning path
Securing Azure Storage starts with an overview outlining the various authentication and authorization methods available to access Azure storage resources. We then look at each method, examining its benefits and disadvantages. Setting up access to storage resources using account keys and the various shared access signature variants demonstrates the practical implications and use cases of each access method. The course ends with a look at implementing Azure files as a mapped drive within an Azure virtual machine.
- Overview of Azure account storage authentication and access
- Create an account key rotation policy
- See how to integrate storage account keys with Azure Key Vault
- Implement Shared Access Signatures
- Map a virtual machine drive to an Azure file share
- Students working towards the AZ-500: Microsoft Azure Security Technologies exam
- Those wanting to learn how to secure an Azure storage account
- Be familiar with Active Directory concepts such as managed identities and role-based access control, Azure Key Vault, and the basics of Azure storage resources
Let's look at setting up authentication for Azure Files implemented with the SMB protocol by creating a file share and accessing it from a virtual machine. First, I'll create a file share, imaginatively called file share. Even though we're told transaction costs are higher on cooler tiers, they'll be virtually no transactions, so I'm not worried. Soft delete is currently disabled, so I'll enable it and set the retention period to one day. I'll be accessing the file share with identity-based authentication, so I will need to configure Azure Active Directory Domain Services. I'll be using a domain-joined virtual machine to access the file share. Once you've set up AD domain services, it's just a case of checking enable Azure AD DS.
Next, we need to specify the default access for the file share. For the sake of brevity and ease of use, I'll go with enable permissions for all authenticated users, but in the interests of least privileged access, set the default role to Storage File Data SMB Share Reader. I assume that all users will at least want to see and read the file share's content. The other built-in SMB share-specific roles are contributor, which has modify permissions, and elevated contributor, which can set NTFS permissions on folders and files within the share. For RBAC permissions set within the Azure portal to work, you must ensure that under configuration, default to Azure Active Directory authorization in the Azure portal is enabled.
With the active directory configured, let's set up the file share on the VM with a user without elevated permissions. I'll grab a small script from the file share's connect context menu item. The authentication method is Active Directory, and I'll map the share to drive letter F. Click show script and copy the script. After logging into the VM, I'll open a PowerShell window and paste in the script. The script tests for a connection to the storage account over port 445 and, if successful, creates a persistent drive mapping to the F drive. Remember when I selected "Enable permissions for all authenticated users and groups" as the default for active directory authentication? If I'd selected disable permissions and not set the SMB share reader role per user, I wouldn't have permission to run this script. You might think that a user with elevated permissions could set up the share drive mapping for other users in the domain. However, this is not the case. You could set up a global mapping in a hybrid scenario with on-premises machines using a group policy, but in a cloud-only situation, it is not possible at this time.
Ok, here we have F drive mapped to the file share. When I go to create a folder within the share, naturally, as a reader, I don't have permission. Let's return to the portal and give the user the storage file data SMB share contributor role on the file share. So that's add role, select the role, and choose the user to assign the role. In a production environment, you'd been assigning these roles to groups and users to those groups.
While that role is being assigned – it does require a few minutes to take effect – I'll log into the VM as an elevated user and look at the user the file share uses for authentication. Using the magic of video, I've already done the drive mapping. Go to server tools and open Active Directory users and computers. Under the domain, in AzureFilesConfig, we can see the user Active directory has created with the name of the storage account. The role assignment on the other user should have taken effect by now, so let's log back in as the standard user. Now I can successfully create a folder in the file share. Back in the portal, the new folder is displayed in the file share.
Hallam is a software architect with over 20 years experience across a wide range of industries. He began his software career as a Delphi/Interbase disciple but changed his allegiance to Microsoft with its deep and broad ecosystem. While Hallam has designed and crafted custom software utilizing web, mobile and desktop technologies, good quality reliable data is the key to a successful solution. The challenge of quickly turning data into useful information for digestion by humans and machines has led Hallam to specialize in database design and process automation. Showing customers how leverage new technology to change and improve their business processes is one of the key drivers keeping Hallam coming back to the keyboard.