Azure Storage

Azure Storage

Performance Tiers
When creating a storage account, you must choose between the Standard and Premium performance tiers. This setting cannot be changed later.

Standard This tier supports all storage services: blobs, tables, files, queues, and unmanaged Azure virtual machine disks. It uses magnetic disks to provide cost-efficient and reliable storage.

Premium This tier is designed to support workloads with greater demands on I/O and is backed by high performance SSD disks. They only support page blobs, and do not support the other storage services. In addition, Premium storage accounts only support the locally-redundant (LRS) replication option, and do not support access tiers.

Replication options

Locally redundant storage (LRS)
Makes three synchronous copies of your data within a single datacenter. Available for general purpose or blob storage accounts, at both the Standard and Premium performance tiers.

Zone redundant storage (ZRS)
Makes three synchronous copies of your data across multiple availability zones within a region. Available for general purpose v2 storage accounts only, at the Standard performance tier only.

Geographically redundant storage (GRS)
Same as LRS (three copies local), plus three additional asynchronous copies to a second data center hundreds of miles away from the primary region. Data replication typically occurs within 15 minutes, although no SLA is provided. Available for general purpose or blob storage accounts, at the Standard performance tier only.

Read-access geographically redundant storage (RAGRS)
Same capabilities as GRS, plus you have read-only access to the data in the secondary data center. Available for general purpose or blob storage accounts, at the Standard performance tier only.

Access tiers
Access tiers apply to blob storage only.

Hot This access tier is optimized for the frequent access of objects in the storage account. Relative to other tiers, data access costs are low while storage costs are higher.

Cool This access tier is optimized for storing large amounts of data that is infrequently accessed and stored for at least 30 days. The availability SLA is lower than for the hot tier. Relative to the Hot tier, data access costs are higher and storage costs are lower.

Archive This access tier is designed for long-term archiving of infrequently-used data that can tolerate several hours of retrieval latency, and will remain in the Archive tier for at least 180 days. This tier is the most cost-effective option for storing data, but accessing that data is more expensive than accessing data in the Hot or Cool tiers.Data in the Archive storage tier is stored offline and must be rehydrated to the Cool or Hot tier before it can be accessed. This process can take up to 15 hours.

There is a fourth tier, Premium, providing highperformance access for frequently-used data, based on solid-state disks. It is only available from the Block Blob storage account type.

Account Kind
The blob storage account is a specialized storage account used to store block blobs and append blobs. You can’t store page blobs in these accounts, therefore you can’t use them for unmanaged disks.

Only general-purpose v2 and blob storage accounts support the hot, cool and archive access tiers.

Only general-purpose v2 accounts support zone-redundant (ZRS) storage.

$resourceGroup = “ExamRefRG”
$accountName = “mystorage112300”
$location = “WestUS”
$sku = “Standard_LRS”
$kind = “StorageV2”
$tier = “Hot”
New-AzResourceGroup -Name $resourceGroup -Location $location New-AzStorageAccount -ResourceGroupName $resourceGroup -Name $accountName -SkuName Standard_LRS -Location $location -Kind $kind -AccessTier $tier

Set-AzStorageAccount -ResourceGroupName $resourceGroup -Name $accountName -AccessTier Cool -Force

Configure network access to the storage account

Each storage account service exposes its own endpoint used to manage the data in that storage service (blobs in blob storage, entities in tables, and so on). These service-specific endpoints are not exposed through Azure Resource Manager, instead they are (by default) Internet-facing endpoints.

Storage Firewall
The storage firewall is used to control which IP address and virtual networks can access the storage account. It applies to all storage account services (blobs, tables,
queues and files).

Virtual Network Service Endpoints
In some scenarios, a storage account is only accessed from within an Azure virtual network. In this case, it is desirable from a security standpoint to block all Internet
access. Configuring Virtual Network Service Endpoints for your Azure storage accounts allows you to remove access from the public Internet, and only allow traffic from a virtual network for improved security.
Another benefit of using service endpoints is optimized routing. Service endpoints create a direct network route from the virtual network to the storage service. This is important when forced tunneling is used to direct outbound Internet traffic from the virtual network via an on-premises network security device. Without service endpoints, access from the virtual network to the storage account would also be routed via the on-premises network, adding significant latency. With service endpoints, the direct route to the storage account takes precedence over the on-premises route, so
no additional latency is incurred.

Blob storage access levels
Storage accounts support an additional access control mechanism, limited only to blob storage. By default, no public read access is enabled for anonymous users, and only users with rights granted through role-based access control (RBAC), or with the storage account name and key, will have access to the stored blobs. To enable anonymous user access, you must change the container access level. The supported levels are as follows:

No public read access The container and its blobs can be accessed only by the storage account owner. This is the default for all new containers.

Public read-only access for blobs only Blobs within the container can be read by anonymous request, but container data is not available. Anonymous clients cannot enumerate the blobs within the container.

Full public read-only access All container and blob data can be read by anonymous request. Clients can enumerate blobs within the container by anonymous request but cannot enumerate containers within the storage account.

A Shared Access Signature token (SAS token) is a URI query string parameter that grants access to specific containers, blob, queues, and tables.

Manage access keys
The simplest, and most powerful control over access to a storage is account is via the access keys. With the storage account name and an access key of the Azure Storage Account, you have full access to all data in all services within the storage account. Rolling a storage account access key will invalidate any Shared Access Signature tokens that were generated using that key.

Managing Access Keys in Azure Key Vault
Create an Azure Key Vault and then securely store the key in Azure Key Vault (using software protected keys) using PowerShell

$vaultName = “[key vault name]”
$rgName = “[resource group name]”
$location = “[location]”
$keyName = “[key name]”
$secretName = “[secret name]”
$storageAccount = “[storage account]”
# create the key vault
New-AzKeyVault -VaultName $vaultName -ResourceGroupName $rgName -Location $location
# create a software managed key
$key = Add-AzKeyVaultKey -VaultName $vaultName -Name $keyName -Destination ‘Software’
# retrieve the storage account key (the secret)
$storageKey = Get-AzStorageAccountKey -ResourceGroupName $rgName -Name $storageAccount
# convert the secret to a secure string
$secretvalue = ConvertTo-SecureString
$storageKey[0].Value -AsPlainText -Force
# set the secret value
$secret = Set-AzKeyVaultSecret -VaultName $vaultName -Name $secretName -SecretValue $secretvalue

Generate a shared access signature

$accountName = “[storage account]”
$rgName = “[resource group name]”
$container = “[storage container name]”
$blob = “[blob path]”
$storageKey = Get-AzStorageAccountKey -ResourceGroupName $rgName -Name $accountName $context = New-AzStorageContext -StorageAccountName $accountName -StorageAccountKey $storageKey[0].Value
$startTime = Get-Date
$endTime = $startTime.AddHours(4)
New-AzStorageBlobSASToken -Container $container -Blob $blob -Permission “rwd” -StartTime $startTime -ExpiryTime $endTime -Context $context

Using shared access signatures

Using a stored access policy
standard SAS token incorporates the access parameters (start and end time, permissions, etc) as part of the token. The parameters cannot be changed without generating a new token, and the only way to revoke an existing token before its expiry time is to roll over the storage account key used to generate the token Or to delete the blob. Stored access policies allow the parameters for a SAS token to be decoupled from the token itself. The access policy specifies the start time, end time and access permissions, and is created independently of the SAS tokens. SAS tokens are generated that reference the stored access policy instead of embedding the access parameters explicitly. With this arrangement, the parameters of existing tokens can be modified by simply editing the stored access policy. An existing token can be deactivated by simply setting the expiry time in the access policy to a time in the past.

Comments are closed.