azure:az-500:storage_security [Core Dump]

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Storage (Account) Security ======
> An Azure geography is a defined area of the world that contains at least one Azure Region. An Azure region is an area within a geography, containing one or more datacenters.

===== Paired Regions =====

===== Azure Storage Access =====
   * Azure AD/RBAC authorization is preferred over all other authorization storage options for Azure Storage.

  * [[https://docs.microsoft.com/en-us/azure/storage/common/authorize-data-access|Authorize access to data in Azure Storage]]
  * [[https://docs.microsoft.com/en-us/azure/storage/common/storage-network-security]]
  * [[https://docs.microsoft.com/en-us/learn/modules/storage-security/4-shared-access-signatures]]
  * [[https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview]]
  * [[https://docs.microsoft.com/en-us/azure/storage/blobs/authorize-access-azure-active-directory|Azure AD]] is the recommended way to provide authorization for storage account access.

==== Types of Authorization ====
  * [[https://docs.microsoft.com/en-us/azure/storage/common/authorize-data-access#understand-authorization-for-data-operations]]

  * **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 and 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]]

====== 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. 

====== Azure Files Authentication ======
  * ACLs are preserved by default, you are not required to enable identity-based authentication on your storage account to preserve ACLs.
  * **Secure Transfer Required** should be enabled for **storage accounts.**