azure:az-500:alt:azure_storage

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
azure:az-500:alt:azure_storage [2022/07/24 13:00] – [Types] mmuzeazure:az-500:alt:azure_storage [2023/02/07 14:42] (current) – mmuze
Line 1: Line 1:
 ====== Azure Storage ====== ====== Azure Storage ======
   * [[https://docs.microsoft.com/en-us/azure/storage/common/storage-introduction]]   * [[https://docs.microsoft.com/en-us/azure/storage/common/storage-introduction]]
 +  * data is always encrypted at rest — can use Microsoft Managed Keys or Customer Managed Keys
  
 ====== Azure Storage Accounts ====== ====== Azure Storage Accounts ======
Line 8: Line 9:
   * General-purpose v2 accounts - Basic storage account type for blobs, files, queues, and tables. Recommended for most scenarios using Azure Storage.   * General-purpose v2 accounts - Basic storage account type for blobs, files, queues, and tables. Recommended for most scenarios using Azure Storage.
   * General-purpose v1 accounts - Legacy account type for blobs, files, queues, and tables. Use general-purpose v2 accounts instead when possible.   * General-purpose v1 accounts - Legacy account type for blobs, files, queues, and tables. Use general-purpose v2 accounts instead when possible.
-  * Block Blob Storage accounts+  * Block Blob Storage (premium) accounts - Premium storage account type for block blobs and append blobs. Recommended for scenarios with high transaction rates or that use smaller objects or require consistently low storage latency.
   * File Storage accounts   * File Storage accounts
   * Blob Storage accounts - Legacy Blob-only storage accounts. Use general-purpose v2 accounts instead when possible.   * Blob Storage accounts - Legacy Blob-only storage accounts. Use general-purpose v2 accounts instead when possible.
  
 ====== Authorization ====== ====== Authorization ======
-  * shared key +===== Types of Authorization ===== 
-  * shared access signature +  * [[https://docs.microsoft.com/en-us/azure/storage/common/authorize-data-access#understand-authorization-for-data-operations]] 
-  * Azure AD RBAC+ 
 +  * **Azure Active Directory (Azure AD) integration/RBAC** 
 +      * This is the generally recommend method to use 
 +      * You can grant permissions that are scoped to the level of an individual container or queue. 
 +  * **Shared Key** for blobs, files, queues, and tables. A client using Shared Key passes a header with every request that is signed using the storage account access key. 
 +    * It is recommended to disable and not use this option. 
 +    * MS recommends using Azure AD/RBAC instead of this option 
 +    * If shared keys are used it is recommended to use Azure Key vault and to rotate keys periodically. 
 +  * **Shared Access Signature (SAS)** 
 + 
 +====== Shared Access Signature(SAS) ====== 
 +  * SAS is a string that contains a security token that can be attached to a URI that gives access to storage objects 
 +  * [[https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview]] 
 + 
 +  * The only way to revoke a SAS (that was signed by a key) is to revoke (regenerate) the access key that was used to sign it. This is not ideal because that key could be used in other ways and this would be a disruptive operation. That is where a **stored access policy** can be of use (for service-level SAS only). 
 +  * There are tree types of SAS, user delegated, service SAS and account SAS. 
 +  * A **user delegation** SAS is secured with Azure Active Directory (Azure AD) credentials and also by the permissions specified for the SAS. A user delegation SAS applies to Blob storage only. 
 +  * A **service SAS** is secured with the storage account key. A service SAS delegates access to a resource in only one of the Azure Storage services: Blob storage, Queue storage, Table storage, or Azure Files. A service-level SAS applies to just one service (e.g. blob, Azure Files...). 
 +  * An **account SAS** is secured with the storage account key. An account SAS delegates access to resources in one or more of the storage services. All of the operations available via a service or user delegation SAS are also available via an account SAS. Account-level SAS applies to the Storage Account, therefore it could apply to any number of containers/Azure Storage Services in the account. 
 + 
 +  * A **SAS** can take one of two forms. **Ad hoc SAS** where the expiry and permissions are part of the SAS URI and Service **SAS** with **stored access policy** where the SAS references the policy that defines the expiry and permissions. 
 +    * A user delegated SAS and account SAS must be an ad hoc SAS 
 + 
 +===== Stored Access Policy ===== 
 +> A stored access policy provides an additional level of control over service-level shared access signatures (SAS) on the server side. 
 + 
 +  * A [[https://docs.microsoft.com/en-us/rest/api/storageservices/define-stored-access-policy|stored access policy]] is an additional level of protection that can be used in conjunction with //service-level shared access signatures (SAS)// authentication. It provides an expiration date and permissions that can be used independent of the SAS token/URL. This provides more flexibility for revoking access. 
 +  * [[https://docs.microsoft.com/en-us/rest/api/storageservices/define-stored-access-policy]] 
 + 
 +> To revoke a stored access policy, you can delete it, rename it by changing the signed identifier, or change the expiry time to a value in the past. Changing the signed identifier breaks the associations between any existing signatures and the stored access policy. Changing the expiry time to a value in the past causes any associated signatures to expire. Deleting or modifying the stored access policy immediately affects all of the shared access signatures associated with it. 
 +====== Storage Service Encryption ====== 
 +  * All data (including metadata) written to Azure Storage is automatically encrypted using Storage Service Encryption (SSE). 
 +  * You can rely on Microsoft-managed keys for the encryption of your storage account, or you can manage encryption with your own keys. 
  
 ====== Blob Storage ====== ====== Blob Storage ======
Line 21: Line 54:
  
   * [[https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction]]   * [[https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction]]
 +
 ===== Types ===== ===== Types =====
   * block blobs   * block blobs
Line 31: Line 65:
       * support random read/write operations for things like VHD disk images for VMs       * support random read/write operations for things like VHD disk images for VMs
       * store random access files up to 8 TiB in size       * store random access files up to 8 TiB in size
 +
 +===== Access Tiers for Blob Storage =====
 +  * [[https://docs.microsoft.com/en-us/azure/storage/blobs/access-tiers-overview]]
 +
 +===== Encryption =====
 +  * A blob-only feature is the ability to specify an encryption scope
 +  * An encryption scope can be applied to a container or blob itself
 +  * If an encryption scope is set at the container level then one cannot be set at the blob level.
 +  * **MMK:** Microsoft Managed Keys
 +  * **CMK:** Customer Managed Keys
  
 ====== Azure Files ====== ====== Azure Files ======
Line 43: Line 87:
 ====== Azure Disks ====== ====== Azure Disks ======
 > Block-level storage volumes for Azure VMs. > Block-level storage volumes for Azure VMs.
 +===== Azure Disk Encryption =====
 +  * [[https://learn.microsoft.com/en-us/azure/virtual-machines/disk-encryption-overview]]
  
 +===== Windows =====
 +  * DE is support for standard tier VMs
  
- +===== Linux ===== 
- +  * For Linux scale sets only encryptions is supported on the data volume, but **not** the OS volume 
 +  * Encryption is **not** supported for customer Linux images—only the Gallery images are supported.
  • azure/az-500/alt/azure_storage.1658667608.txt.gz
  • Last modified: 2022/07/24 13:00
  • by mmuze