Nordlicht Reisen GmbH, a fictional travel agency, has a storage account with booking receipts. Accounting is supposed to read one container once a month, a service provider is supposed to upload files, and nobody else should be able to reach the account from the internet. There are four tools for this, and this lesson goes through them: account keys, shared access signatures (SAS), stored access policies and the storage firewall.
This lesson covers in the study guide: manage access keys, create and use SAS tokens, configure stored access policies, configure Azure Storage firewalls and virtual networks.
Prior knowledge. Lesson 2.1 creates the storage account itself. Roles and scopes are lesson 1.3. How an application accesses blobs without keys by using a managed identity is shown in K3, lesson 3.3.1. Here the topic is managing access from the administrator's side.
Manage access keys
Every storage account has access keys. They give full access to all data in the account, like an administrator password. Whoever has them needs no identity and no role.
Hence Microsoft's advice: keys only where there is no alternative. Access with Microsoft Entra and role assignments (lesson 1.3) is better. If you want to rule out keys altogether, switch off the setting Enable storage account key access (on the Security tab when you create the account; later in the account's configuration). The account then rejects requests signed with the key or with a SAS derived from it (account SAS, service SAS).
Managing means: viewing them, rotating them (regenerating) and protecting them. In the portal: account → Security + networking → Access keys. Commands:
az storage account keys list --account-name <eindeutiger-name> `
--resource-group rg-az104-zugriff
az storage account keys renew --account-name <eindeutiger-name> `
--resource-group rg-az104-zugriff --key key1
In Azure PowerShell: Get-AzStorageAccountKey and New-AzStorageAccountKey -KeyName key1. Two things are relevant for the exam:
- Rotating invalidates the old key. Everything that uses it fails until it uses the other valid key or the newly generated one. That is why there are two
keys (
key1,key2): first switch the applications to the second, then rotate the first. - A ReadOnly lock on the account prevents listing the keys (lesson 1.5). If you want to work anyway, you need Microsoft Entra.
Keys never belong in scripts or repositories. Where to keep them: Azure Key Vault (K3, lesson 3.3.2).