Storage Security (part 2)

By Ashwin Venugopal -



To read part 1 please click here

Shared Access Signatures

For untrusted clients you can use a Shared Access Signature (SAS) which is a string that contains a security token that can be attached to a URI as well as delegate access to storage objects and specified constraints, such as the permissions and the time range of access. 

Types of SAS

  • You can use a service-level SAS to allow access to specific resources in a storage account. You'd use this type of SAS, for example, to allow an app to retrieve a list of files in a file system or to download a file.

  • Use an account-level SAS to allow access to anything that a service-level SAS can allow, plus additional resources and abilities. For example, you can use an account-level SAS to allow the ability to create file systems.

  • A user delegation SAS, introduced with version 2018-11-09, is secured with Azure AD credentials. This type of SAS is supported for the Blob service only and can be used to grant access to containers and blobs. 

Additionally, a service SAS can reference a stored access policy that provides an additional level of control over a set of signatures, including the ability to modify or revoke access to the resource if necessary.

Azure AD Storage Authentication

In addition to the shared key and SAS, Azure Blob and Queue storage supports using Azure AD to authorize storage requests. The security principle is authenticated by Azure AD to return an OAuth 2.0 token. The token can then be used to authorize a request against Blob or Queue storage.

  • Authorization with Azure AD is available for all general-purpose and Blob storage accounts in all the public regions as well as national clouds.

  • Built-in storage roles are provided including Owner, Contributor, and Reader.

  • The role can be scoped from Management Group to individual blob or queue. Best practices dictate granting only the narrowest possible scope. 

  • RBAC role assignments may take up to five minutes to propagate. 

When a security principle attempts to access a blob or queue resource, the request must be authorized, unless it is a blob available for anonymous access.

Storage Service Encryption

Azure Storage security

Azure Storage provides a comprehensive set of security capabilities that together enable developers to build secure applications:

  • All data written to Azure Storage is automatically encrypted using Storage Service Encryption (SSE).
  • Azure AD and RBAC are supported for Azure Storage for both resource management operations and data operations.
  • Data can be stored in transit between an application and Azure by using Client-Side Encryption, HTTPS, or SMB 3.0.
  • OS and data disks used by Azure virtual machines can be encrypted using Azure Disk Encryption.
  • Delegated access to the data objects in Azure Storage can be granted using a shared access signature. 

Encryption Key Management

You can rely either on Microsoft-managed keys for the encryption of your storage account, or you can manage encryption with your own keys that has two options:

  • You can specify a customer-managed key to use for encrypting and decrypting all data in the storage account. It is used to encrypt all data in all services in your storage account.
  • You can specify a customer-provided key on Blob storage operations. A client making a read or write request against Blob storage can include an encryption key on the request for granular control over how blob data is encrypted and decrypted.

Blob Data Retention Policies

Time-based vs Legal hold policies

  • Time-based retention policy support- When a time-based retention policy is set, blobs can be created and read, but not modified or deleted but when this policy is applied on a container, all the blobs in the container will stay in the immutable state for the duration of the effective retention period and as users can extend the retention interval, immutable storage uses the most recent value of the user-specified retention interval to calculate the effective retention period.

  • Legal hold policy support- When a legal hold policy is set, blobs can be created and read, but not modified or deleted. The legal holds are temporary holds that can be used for legal investigation purposes or general protection policies and each of them are used to be associated with one or more tags which are used as a name identifier, such as a case ID or event, to categorize and describe the purpose of the hold. 

Azure Files Authentication

Azure Files supports identity-based authentication over Server Message Block (SMB) through on-premises AD Domain Services and Azure AD Domain Services and allows you to replace existing file servers with Azure file shares without replacing your existing directive service, maintaining seamless user access to shares.

Azure files also enforces authorization on user access to both the share and the directory/file levels and at the directory/file level, Azure files supports preserving, inheriting, and enforcing Windows DACLs just like any Windows file servers. Whether you plan to enforce authorization or not, you can use Azure file shares to back up DACLs along with your data.

Advantages of identity-based authentication

Identity-based authentication for Azure Files offers several benefits over using Shared Key authentication:
  • Extend the traditional identity-based file share access experience to the cloud with on-premises AD DS and Azure AD DS. Azure files supports using both on-premises AD DS or Azure AD DS credentials to access Azure file shares over SMB from either on-premises AD DS or Azure AD DS domain-joined VMs.

  • Enforce granular access control on Azure file shares. You can grant permissions to a specific identity at the share, directory, or file level. You can also grant all teams access to non-sensitive directories, while limiting access to directories containing sensitive financial data to your Finance team only.

  • Back up Windows ACLs (also known as NTFS) along with your data. Azure files preserves your ACLs along with your data when you back up a file share to Azure file shares over SMB. 

  Secure Transfer Required

When a secure transfer is required, a call to an Azure Storage REST API operation must be made over HTTPS. Any request made over HTTP is rejected. Connecting to an Azure file share over SMB without encryption fails when secure transfer is required for the storage account. By default, the secure transfer required property is enabled when you create a storage account. Azure Storage doesn't support HTTPS for custom domain names, this option is not applied when you are using a custom domain name. 



To read part 1 please click here





Comments

Post a Comment

Popular posts from this blog

Query, Visualize, & Monitor Data in Azure Sentinel

By Ashwin Venugopal -
Image
  Azure Sentinel Workbooks Several ready for use templates are provided by the Azure Sentinel that can be used to create your own workbook and then modify them as needed for Contoso. Most of the data connectors it uses to ingest data come with their own workbooks, but better insight can be obtained by simply looking into the data that is being ingested by using tables and visualizations, including bar and pie charts. You can also make your own workbook easily by using this data from the beginning instead of using the predefined templates. Workbook Page You can easily access the workbook page from the Azure Sentinel from the navigation pane which consists of the: Workbook header- You can add a new workbook and review the saved workbooks as well as templates that are available on the workbook page. Templates section- You can access existing workbook templates on the Templates tab. You can save some of the workbooks for quick access and they will appear on the My Workbooks tab.  From the
Read more

Planning for Implementing SAP Solutions on Azure (Part 2 of 5)

By Ashwin Venugopal -
Image
  To read part 1 please click  here To read part 3 please click  here To read part 4 please click  here To read part 5 please click  here Load Balancing The load balancer uses probe ports to determine as well as route the traffic to an active DBMS node, but of there's any failover then the most common SAP application architecture can automatically reconnect against the private virtual IP address without the need for the SAP application to reconfigure it, while the load balancer redirect the traffic against the private virtual IP address without any need for the SAP application to reconfigure. The loaf balancer also offers an option of DirectServerReturn which if configured, can help in directing the traffic from the DBMS VM to the SAP application layer directly to the application layer without routing through the load balancer. But, if it isn't configured, then the return traffic to the SAP application layer is routed through the load balancer. You can also use Azure Load Balan
Read more

Work with String Data Using KQL Statements

By Ashwin Venugopal -
Image
  Extract Data from Unstructured String Fields Unstructured string fields often contains the Security log data and requires parsing to extract data. There are multiple ways of pulling information from string fields in KQL and the two primary operators used are extract and parse.  Extract It gets a match for a regular expression from a text string. You can convert the extracted substring to the indicated type.  Arguments regex- A regular expression. captureGroup- A positive int constant indicating the capture group to extract. 0 stands for the entire match, 1 for the value matched by the first '('parenthesis')' in the regular expression, 2 or more for subsequent parenthesis.  text- A string to search. typeLiteral- An optional type literal. If provided, the extracted substring is converted to this type.  Returns If regex finds a match in text- the substring matched against the indicated capture group captureGroup, optionally converted to typeLiteral. If there's no mat
Read more