Storage

Blob Storage access tiers :

• Hot access tier : Optimized for storing data that is accessed frequently.
• Cool access tier : Optimized for data that is infrequently accessed and stored for at least 30 days.
• Archive access tier : Appropriate for data that is rarely accessed and stored for at least 180 days, with flexible latency requirements.
• Premium Blob Storage : Best suited for I/O intensive workloads that require low and consistent storage latency.
  • Best for workloads that perform many small transactions like a mapping application that requires frequent and fast updates.

Only the hot and cool access tiers can be set at the account level. The archive access tier isn't available at the account level.

You can use Azure Blob Storage lifecycle management policy rules to accomplish several tasks.

• Transition blobs to a cooler storage tier (Hot to Cool, Hot to Archive, Cool to Archive) to optimize for performance and cost.
• Delete blobs at the end of their lifecycles.
• Define rule-based conditions to run once per day at the Azure storage account level.
• Apply rule-based conditions to containers or a subset of blobs.

Object replication (ObjR) copies blobs in a container asynchronously according to policy rules that you configure.
During the replication process, the following contents are copied from the source container to the destination container :

• The blob contents.
• The blob metadata and properties.
• Any versions of data associated with the blob.

Things to know about blob object replication

• Object replication requires that blob versioning is enabled on both the source and destination accounts. Change feed must be enabled for the source account.
• ObjR doesn't support blob snapshots. Any snapshots on a blob in the source account aren't replicated to the destination account.
• ObjR is supported when the source and destination accounts are in the Hot or Cool tier. The source and destination accounts can be in different tiers.
• When you configure object replication, you create a replication policy that specifies the source Azure storage account and the destination storage account.

Azure Blob Storage supports two forms of immutability policies for implementing immutable storage:

• Time-based retention policies let users set policies to store data for a specified interval.
  When a time-based retention policy is in place, objects can be created and read, but not modified or deleted.
  After the retention period has expired, objects can be deleted, but not overwritten.
  The Hot, Cool, and Archive access tiers support immutable storage by using time-retention policies.

• Legal hold policies store immutable data until the legal hold is explicitly cleared.
  When a legal hold is set, objects can be created and read, but not modified or deleted.
  Premium Blob Storage uses legal holds to support immutable storage.

A blob can be any type of data and any size file. Azure Storage offers three types of blobs: block blob, page blob, and append blob.

• Block blobs : consist of blocks of data that are assembled to make a blob. It is the default type for a new blob.

  • When you're creating a new blob, if you don't choose a specific type, the new blob is created as a block blob.
  • Block blobs are ideal for storing text and binary data in the cloud, like files, images, and videos.

• Append blobs : are similar to a block blob because the append blob also consists of blocks of data.

  • The blocks of data in an append blob are optimized for append operations.
  • Append blobs are useful for logging scenarios, where the amount of data can increase as the logging operation continues.

• Page blobs : can be up to 8 TB in size. Page blobs are more efficient for frequent read/write operations.

  • Azure VM uses page blobs for Operating System disks and data disks.

After you create a blob, you can't change its type.

The Storage Sync Service is the top-level Azure resource for Azure File Sync.
This resource is a peer of the storage account resource and can be deployed in a similar manner.

• The Storage Sync Service forms sync relationships with multiple storage accounts by using multiple sync groups.
• The service requires a distinct top-level resource from the storage account resource to support the sync relationships.
• A subscription can have multiple Storage Sync Service resources deployed.

A sync group defines the sync topology for a set of files. Endpoints within a sync group are kept in sync with each other.

The registered server object represents a trust relationship between your server/cluster and the Storage Sync Service resource.
You can register as many servers to a Storage Sync Service resource as you want.

The Azure File Sync agent is a downloadable package that enables Windows Server to be synced with an Azure Files share.
The Azure File Sync agent has three main components :

• FileSyncSvc.exe : This file is the background Windows service that's responsible for monitoring changes on server endpoints and for initiating sync sessions to Azure
• StorageSync.sys : This file is the Azure File Sync file system filter that supports cloud tiering.
  • The filter is responsible for tiering files to Azure Files when cloud tiering is enabled.
• PowerShell cmdlets : These PowerShell management cmdlets allow you to interact with the Microsoft.StorageSync.

Server endpoint

A server endpoint represents a specific location on a registered server, such as a folder on a server volume.
Multiple server endpoints can exist on the same volume if their namespaces are unique.

Cloud endpoint

A cloud endpoint is an Azure Files share that's part of a sync group. As part of a sync group, the entire cloud endpoint (Azure Files share) syncs.

• An Azure Files share can be a member of one cloud endpoint only.
• An Azure Files share can be a member of one sync group only.

Azure Disk Encryption (ADE) encrypts the VM's virtual hard disks (VHDs). If VHD is protected with ADE, the disk image is accessible only by the VM that owns the disk.

Server-Side Encryption (SSE) is performed on the physical disks in the data center. If someone directly accesses the physical disk, the data will be encrypted.

When the data is accessed from the disk, it's decrypted and loaded into memory. This form of encryption is also referred to as encryption at rest or Azure Storage encryption.

Encryption at host ensures that data stored on the VM host is encrypted at rest and flows encrypted to the Storage service.
Disks with encryption at host enabled aren't encrypted with SSE.
Instead, the server hosting your VM provides the encryption for your data, and that encrypted data flows into Azure Storage.

All data written to Azure Storage is automatically encrypted. Azure Storage encryption offers two ways to manage encryption keys at the storage account level:

• Microsoft-managed keys : By default, Microsoft manages the keys used to encrypt your storage account.
• Customer-managed keys : You can optionally choose to manage encryption keys for your storage account. Customer-managed keys must be stored in Azure Key Vault.

Data in transit : Data can be secured in transit between an application and Azure by using Client-Side Encryption, HTTPS or SMB 3.

Disk encryption : Operating system disks and data disks used by Azure Virtual Machines can be encrypted by using Azure Disk Encryption.

Shared access signatures (SAS) provide secure delegated access to resources in your storage account. With a SAS, you have granular control over how a client can access your data.

Azure Storage supports three types of SAS :

• User delegation SAS : Can only be used for Blob storage and is secured with Azure AD credentials.
• Service SAS : delegates access to a resource in any one of four Azure Storage services: Blob, Queue, Table or File (shares using REST not with SMB).
  • A service SAS is secured using a storage account key.
• Account SAS : has the same controls as a service SAS, but can also control access to service-level operations, such as Get Service Stats.
  • An account SAS is secured using a storage account key.

When creating a SAS, you can set :

• Allowed resource types : Service, Container, Object.
• Expiration date/time.
• Allowed Ip adresses.
• Allowed protocols : HTPPS Only or HTTPS and HTPP
• Allowed permissions.
• Signing method and key.
• ...

Use stored access policies to delegate access

SAS is a secure way to give access to clients without having to share your Azure credentials. This ease of use comes with a downside.
Anyone with the correct SAS can access the file while it's still valid.

The only way you can revoke access to the storage is to regenerate access keys. Regeneration requires you to update all apps that are using the old shared key to use the new one.

Another option is to associate the SASs with a stored access policy.
Stored access policy give you the option to revoke permissions without having to regenerate the keys.

A stored access policy is created with the following properties : Identifier(name), Start/Expiry time, Permissions.
All these actions can be done after releasing the SAS token for resource access :

• Controlling permissions for the signature.
• Revoking access.
• Changing the start time and the end time for a signature's validity.

Azure Storage creates two 512-bit access keys for every storage account that's created. You share these keys to grant clients access to the storage account.
These keys grant anyone with access the equivalent of root access to your storage.

Shared Key authorization is supported with the four Azure Storage services : Blobs, Queues, Table Or File (Shares using REST/SMB)

Firewall policies and rules limit access to your storage account. Requests can be limited to specific IP addresses/ranges or to a list of subnets in an Azure virtual network.

The default network rule is to allow all connections from all networks.

VNet service endpoints restrict network access and provide direct connection to your Azure storage.
You can secure storage accounts to your VNet and enable private IP addresses in the virtual network to reach the service endpoint.

By default, Azure services are all designed for direct internet access. All Azure resources have public IP addresses, including PaaS services such as Azure SQL Database and Azure Storage.
Because these services are exposed to the internet, anyone can potentially access your Azure services.

Service endpoints can connect certain PaaS services directly to your private address space in Azure, so they act like they’re on the same virtual network.
Use your private address space to access the PaaS services directly. Adding service endpoints doesn't remove the public endpoint. It simply provides a redirection of traffic.

Azure service endpoints are available for many services, such as: Azure Storage, Azure SQL Database, Azure Cosmos DB, Azure Key Vault, Azure Data Lake, Azure Service Bus

How service endpoints work

To enable a service endpoint, you must:

1. Turn off public access to the service.
2. Add the service endpoint to a virtual network.

When you enable a service endpoint, you restrict the flow of traffic and enable your Azure VMs to access the service directly from your private address space.
Devices cannot access the service from a public network.

Secure transfer enables an Azure storage account to accept requests from secure connections.
When you require secure transfer, any requests originating from non-secure connections are rejected.

By default, storage accounts accept connections from clients on any network.
To limit access to selected networks, you must first change the default action. You can restrict access to specific IP addresses, ranges, or virtual networks.

Azure AD and RBAC are supported for Azure Storage for both resource management operations and data operations.

Azure AD supports : Blob, Table, Queue. File shares using SMB is only supported by Active DIrectory AD. Share using REST is not supported.

Authorization : Every request made against a secured resource in Blob Storage, Azure File... must be authorized.

Authorization type supported by storage service

Azure artifact	Shared Key storage account key	SAS	Azure AD	AD Domain Services
Azure Blobs	Yes	Yes	Yes	Not supported
Azure Files (SMB)	Yes	Not supported	Only supported with AD DS	Yes but credentials must be synced to Azure AD
Azure Files (REST)	Yes	Yes	Not supported	Not supported
Azure Queues	Yes	Yes	Yes	Not supported
Azure Tables	Yes	Yes	Yes	Not supported