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/25 20:27] – 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 24: Line 25:
     * If shared keys are used it is recommended to use Azure Key vault and to rotate keys periodically.     * 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)**
 +
 +====== 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 43: Line 68:
 ===== Access Tiers for Blob Storage ===== ===== Access Tiers for Blob Storage =====
   * [[https://docs.microsoft.com/en-us/azure/storage/blobs/access-tiers-overview]]   * [[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 55: 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.1658780857.txt.gz
  • Last modified: 2022/07/25 20:27
  • by mmuze