Azure has several resources that can be used for data storage. You can think of data disks, databases with integrated storage but also storage accounts. In a storage account, basically any type of data can be stored. You can use a storage account to store media files but you can also hang it as a share on a VM.
Containers
Containers can be used within a storage account. Media files can be stored in these containers, whether or not in a folder structure. The files and folders are given their own URL so that they can be accessed from an application or VM or called up from an end user’s browser.
File shares
A storage account can be configured to behave as a network share on a file server. In this way, files in which collaborations are taking place can be stored in the Azure Cloud.
Rights
Rights can be set on and in a storage account at various layers. Who or what can access which data? This can be set at Storage Account level, at container level but also at resource/file level. Depending on the desired functionality, these rights can be configured.
The consequence of implementing rights is that authentication is required to access the storage account and/or the data stored in it. There are several ways to access data within a storage account where restrictions are set on access:
Access keys – Access keys can be used to access the storage account and everything in it. This method of access is the least restrictive and easiest to implement. Once access is obtained with an access key, you have rights to read, write, delete, etc. This also makes it the least “secure” way. If it contains data that is not sensitive and must be accessed by everyone, then this is obviously sufficient que security. Access keys are valid for a fixed period of time.
Shared Access Signature – Suppose not all data within a storage account can be accessed with the same rights, then it is important to apply the right rights at the right level. Or perhaps you want something or someone to be able to see everything but not be allowed to do any operations. This can be done using Shared Access Signature and shared access tokens. This requires a bit more configuration, both in the Storage Account and on the application side, but does provide a more layered form of security. In addition, keys are limited in validity and so you have more control over the period during which the data is available. You can therefore grant rights at different levels as well as different types of rights (read, write, update, etc.) as well as determine the duration of access.
In practice
We provide at least 1 storage account for every customer. Even if it is not directly required for the desired functionality in the environment. Experience shows that sooner or later this account is used to test how it functions within the environment or to write away logs.
To access the data within a storage account from an application, VM or on your workstation, you therefore need an access key or a Shared access token (linked to a shared access key). True can provide these. The access key is shared in the ticket upon delivery. If more granular rights are desired, they can be set by the owner of the data using a shared access signature and shared access token. Of course, True can provide support for this.
Incidentally, this information is also available/generated for you as the account owner. By logging into the portal (portal.azure.com) you can find the storage account. In the left column you will find both the access key and the shared access signature.
On the access key page, you will find the key and URL (there are 2). This is basically all that is needed to access the data within the storage account. As stated before, this gives access to all data within the storage account.
At the storage account level, the signature can be determined. Here, the applicable rights can be set.
Next, access must be set at the container level by generating a SAS token. The token and URL can be used to gain access to the data it releases.
Default settings
Basically, storage accounts that we deliver are not connected to the Internet. We connect them to the Vnet where your resources are located. This way, the data can be accessed by the applications and/or VMs within your environment. If you want to make the data available to outside parties, we can configure this. Here we can whitelist on certain IP addresses or we can open the entire storage account to the Internet. The latter is obviously not wise if sensitive data is stored in your storage account.
We provide storage accounts that default to locally-redundant. If you need higher availability we can change it to zone-redundant or geo-redundant. This incurs additional costs because you pay for replication outside the “main zone”.
We have soft-delete enabled for 7 days. This means that files deleted are still available and can be retrieved up to 7 days after deletion. This applies to blobs (the files themselves) as well as the parent containers.
Monitoring
Because this is a “serverless” solution, we have little insight into storage account performance data. Whereas on other resources we can monitor CPU usage, RAM usage, IOPS, with storage account we can only monitor whether it is available.
To conclude
We rarely encounter it but storage account have another functionality that is nice to know: you can place static websites on it. By placing the code for such a page in the account and enabling the functionality, a simple static website can be served that way. Useful for your website’s FAQ page, for example.
Find more specifics in the official Microsoft documentation here.