Shulou(Shulou.com)06/02 Report--

In today's blog post we will discuss the security of Azure Storage and how to use shared access signatures (SAS) and stored access policies to control access to containers and Blob. A SAS is basically a URI with query parameters that specify options such as expiration time, permissions, and signatures. I will cover these in more detail later in this article. Note that shared access signatures can also be used with tables and queues, but I will only discuss Blob storage

What is a shared access signature (SAS)

A shared access signature (SAS) is a URI that allows consumers to have access to storage resources, such as blob or containers, for a specified period of time. The time span and permissions can be derived from the stored access policy or specified in the URI.

Some friends may see here will propose that I use the storage account key on it, why should I use this feature? Because this allows the client to access the container and Blob in the storage account without knowing that we store the account key. From a security perspective, if the storage account key is placed in the client application, it may be subject to * and may be stolen and used by others, or even replace normal files with infected files. Using the storage account key, there are no restrictions on access to the storage account. In the real environment of the enterprise, unlimited access may not be the permission control scenario we want to see.

Default container permissions

Container permissions are the first thing to use when controlling access to Blob storage. You can set the permissions for each container in the blob store to one of the following:

Private: public access to Blob or container public read access to Blob:Blob public read access to Container:Blob container and Blob

If the permission is set to Private, you can access Blob and containers only if you have a storage account name and key, or use a shared access signature.

If the permission is set to Blob, anyone with URL in the container can read the blob as well as the blob property and metadata. Unless they use a share access signature with appropriate permissions, they will not be able to write a Blob or get any information about the container in which the Blob resides, nor will they be able to get the Blob list in the container.

If the permission is set to Container, the container and Blob are publicly readable. You can list the Blob in the container or download Blob. You can read container properties and metadata; you can also read blob properties and metadata. Please note that even with this permission, it is still not possible to modify, upload or delete Blob. If you want to make changes, upload or delete will require an account key or appropriate SAS.

This shows that we can use a combination of container permissions and shared access signatures to control the granularity of access to Blob and containers.

Storage access policy

Here are two ways to create a SAS URI. First, you can create a temporary SAS to access the file or container and specify the expiration date and permissions to use. If you do so, you should consider setting the time span to a small time span such as 15 minutes to minimize the chances of others using the same URL to access the same files. For example, if we are retrieving SAS URI to display a set of pictures, someone might see uri in Fiddler and use them until they are out of date. When using SAS URI, the only other way to revoke access is to change the storage account key, which can have a serious impact, depending on how many applications are using the storage account.

The second way to create a SAS URI is to set the storage access policy for the container and specify the name, startup time, expiration time, permissions, and so on. Then, when we need a SAS URI, we can create it and specify the name of the stored access policy, rather than all the parameters required for a particular version of URI. When authorization is made, information is retrieved from the stored access policy. In addition, unlike temporary SAS URI, if you want to revoke access, you can simply change the stored access policy, and all SAS URI inherited from the stored access policy will be modified immediately, which is preferable to changing the storage account key!

It is important to note that a container can have up to 5 storage access policies. Each policy can be used by any number of shared access signatures. For example, you can set different access policies for read / write and read-only access, using different expiration times. There is no limit to the number of specific uri you can use.

When you create a storage access policy, you can specify any combination of startup time, expiration time, and permissions. If you specify them on a policy, you must omit the parameters from the actual SAS URI. Alternatively, you can specify some of these parameters in the stored access policy and others in SAS URI. In fact, you can specify all the parameters on the SAS URI when you create the storage access policy, but if you do, you can only use the stored access policy to revoke the signature, not modify the behavior of the signature.

The access policy for shared access signatures and stores must contain all the fields required to verify the signature, and there must be no duplicate fields. For example, you cannot set the access policy for storage to have permission Rmap W, or create a SAS URI and specify read-only permissions.

Set the stored access policy on the container by writing a complete list of policies to use. If you want to cancel access to one of the policies, you can delete it by writing a list of policies and excluding the policy. If you want to change the permissions of one of the policies, you must overwrite the stored policy list with a new list that contains the modified policy.

So far, I'm sure you've learned about the storage access policy, so let's take a look at the shared access signature.

Shared access signature

As mentioned earlier, a SAS is a URI that includes all the information in its query parameters to verify the identity required for access to the Blob or container. Query parameters can include the following (the actual query parameters are in parentheses after the parameter name):

Blob URI: this is the address of Blob. We should always use HTTPS to construct shared access signatures. Example: https://sql12bak.blob.core.chinacloudapi.cn storage service version (sv): indicates the storage service version to use. Example: sv = 2019-02-02 this is optional, if not specified, it will be set to the latest version available. Start time (st): this is the time when SAS takes effect. If omitted, SAS takes effect immediately. Due to the time difference between computers (clock skew), please be careful. If you set the start time to now, you may use 5 minutes on another resource in the future, and access may not be allowed for another 5 minutes. Unless the time is not long, it is recommended that you do not set this setting or set the start time to 15 minutes before the current time. This file must be in ISO 8061 format. Example: st=2020-01-19T03:27:10Z expiration time (seconds): this is the time when the SAS is no longer valid. We should always use it or associate it with a storage access policy with this setting. This file must be in ISO 8061 format. Example: se=2020-01-19T11:27:10Z storage resource (sr): tells whether the resource is blob, queue, etc. Example: sr = b, which indicates that the resource is blob, or sr = c, that the resource is a container. Permissions (sp): this defines the actions that can be performed on the storage resource. Example: sp = rw, which grants read (r) and write (w) access. Signature (sig): used to verify access to Blob. This is the HMAC calculated on the string-to-symbol and key using the SHA256 algorithm and then encoded using Base64 encoding.

Example: sig = Z%2FRHIX5Xcg0Mq2rqI3OlWTjEg2tYkboXr1P9ZUXDtkk%3D

Putting all this together results in the following URI, which allows read / write access to container in the storage account sql12bak from 11:27:10 AM on January 19, 2020 to 7:27:10 PM on January 19, 2020

Https://sql12bak.blob.core.chinacloudapi.cn/?sv=2019-02-02&ss=bfqt&srt=sco&sp=rw&se=2020-01-19T11:27:10Z&st=2020-01-19T03:27:10Z&spr=https&sig=pOyu%2FIVLKBVeQWydo3vxIJKEi46NXxwk%2FH%2BtXyas5c8%3D

This is a temporary SAS. This file can be created when the Blob is accessed by specifying all the required query parameters and the raw URI of Blob.

Revoke the authority

The important difference between temporary SAS URI and access policies that use storage is related to the revocation of allowed permissions. With SAS, no matter which process you create, anyone who gets the URI can use it. So, in the scenario mentioned earlier, if a customer captures a SAS URI using Fiddler, he can send it to someone else, who can then access the file in the storage account and upload or download it.

The SAS URI is associated with the account key used to create the signature and the associated storage access policy, if any. If no storage access policy is specified, the only way to undo the shared access signature is to change the storage account key.

Typically, SAS can work until:

The expiration time for SAS has been reached.

If a stored access policy is used, SAS stops working when the expiration time of the stored access policy is reached. This occurs because the time has actually expired, or because the expiration time of the stored access policy has been modified to the past.

If you use a stored access policy and the policy referenced by SAS is deleted, SAS will no longer work.

The account key used to create the SAS will be recreated.

Best practic

When creating or distributing a SAS, you always need to use HTTPS. If the SAS is passed through HTTP, it can be read and used by the person who executes the middleman.

Use stored access policies whenever possible, because they can be used to revoke permissions without having to regenerate the storage account key. If permanent access is required, set the expiration time to a long time and ensure that it is updated regularly to move it to a further future.

When using temporary SAS URI, use the smallest possible date range to limit exposure.

If necessary, ask the client application to update SAS. Therefore, if you have access to the image and the SAS expires, the application should be able to update it so that the client is free of obstacles.

As mentioned earlier, when setting the SAS start time, be sure to resolve the clock offset problem by excluding the start time parameter or subtracting 15 minutes from the current time.

Please specify the resources you need to access. If the customer only needs to access one Blob, do not let them access the entire container.

After writing SAS to storage but before using it, verify the data written using SAS to ensure that it is not corrupted or malicious.

Don't always use SAS. If you want more control over the validation of input data, or if you want to add additional security in authentication, you may need to create a middle-tier service to read and write to the blob storage. In addition, if there is an easier way to provide access, use it. For example, if you want all the Blob in the container to be readable to the public, make the container public instead of creating a SAS for each client that needs to be accessed.

Use storage analytics to monitor our application. This will help us discover authentication failures due to SAS provider service problems or accidental deletion of stored access policies.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.