Microsoft Azure Essentials Fundamentals of Azure Second Edition e-optimized 5x11 pdf

partition key, you could give someone access to just the data for California.  
You can fine-tune this by using a separation of concerns. You can give a web application permission 
to write messages to a queue, but not to read them or delete them. Then, you can give the worker 
role or Azure WebJob the permission to read the messages, process the messages, and delete the 
messages. Each component has the least amount of security required to do its job.  
Here’s an example of an SAS, with each parameter explained: 
http://mystorage.blob.core.windows.net/mycontainer/myblob.txt (URL to the blob) 
?sv=2015-04-05 (storage service version) 
&st=2015-12-10T22%3A18%3A26Z (start time, in UTC time and URL encoded) 
&se=2015-12-10T22%3A23%3A26Z (end time, in UTC time and URL encoded) 
&sr=b (resource is a blob) 
&sp=r (read access) 
&sip=168.1.5.60-168.1.5.70 (requests can only come from this range of IP addresses) 
&spr=https (only allow HTTPS requests) 

---

110 
CHAPTER 4  |    Azure Storage 
 
&sig=Z%2FRHIX5Xcg0Mq2rqI3OlWTjEg2tYkboXr1P9ZUXDtkk%3D (signature used for the authentication of the 
SAS) 
Note that the SAS query parameters must be URL encoded, such as %3A for colon (:) and %20 for a 
space. This SAS gives read access to a blob from 12/10/2015 10:18 PM to 12/10/2015 10:23 PM. 
When the storage service receives this request, it will take the query parameters and create the &sig 
value on its own and compare it to the one provided here. If they agree, it will verify the rest of the 
request. If our URL pointed to a file on a file share instead of a blob, the request would fail because 
blob is specified. If the request were to update the blob, it would fail because only read access has 
been granted.  
There are both account-level SAS and service-level SAS. With account-level SAS, you can do things 
like list containers, create containers, delete file shares, and so on. With service-level SAS, you can only 
access the data objects. For example, you can upload a blob into a container.  
You can also create stored access policies on container-like objects such as blob containers and file 
shares. This will let you set the default values for the query parameters, and then you can create the 
SAS by specifying the policy and the query parameter that is different for each request. For example, 
you might set up a policy that gives read access to a specific container. Then, when someone requests 
access to that container, you create an SAS from the policy and use it.  
There are two advantages to using stored access policies. First, this hides the parameters that are 
defined in the policy. So if you set your policy to give access to 30 minutes, it won’t show that in the 
URL—it just shows the policy name. This is more secure than letting all of your parameters be seen.  
The second reason to use stored access policies is that they can be revoked. You can either change 
the expiration date to be prior to the current date/time or remove the policy altogether. You might do 
this if you accidentally provided access to an object you didn’t mean to. With an ad hoc SAS URL, you 
have to remove the asset or change the storage account keys to revoke access.  
Shared access signatures and stored access policies are the two most secure ways to provide access to 
your data objects.