Azure Vault key security pattern: Cloud design patterns part I

3.2

You can find my all .Net core posts here.

By this post, I am starting the series of post on Cloud design patterns. These patterns are mostly generic and can be used with any cloud provider but in this series, I will mainly focus on the Azure.

Let us first see some of the basic information for the design patterns.

What is Software design pattern?

As per the Wikipedia:

  • In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design
  • It is not a finished design that can be transformed directly into the source or machine code
  • It is a description or template for how to solve a problem that can be used in many different situations
  • Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system

In simple words:

  • When we start creating an application or module from scratch, we face some Software designs problems
  • We want to implement the best solution for our product
  • Solution to common software design problems is called the design pattern
  • Design patterns are really useful when you are working on the architecture of any system

What is Cloud design pattern?

  • The concepts of the design patterns apply here as well but instead of software, we work for the best solution for the Cloud
  • We should use some of the solutions which are proven to be the best solutions for the cloud, these are nothing but the Cloud design patterns

As Security is my favorite topic, let us start with a design pattern for the security in the cloud.

Vault key design pattern

Let us understand this by a simple example:

  • Imagine you have an application in which the client can upload or download various files and these files are managed in the cloud storage
  • To perform these upload\download operations, the application needs to do the process of fetching the files from the Cloud storage and give it back to the client or get the file from the client and send it to the cloud storage
  • Web applications might use streams or different operations to achieve above process
  • Here your web application is handling many things like all the upload\download operations along with the security required to connect to the cloud storage
  • But we should understand that Cloud storage has that capability to manage the upload\download nowadays
  • In such case, the web application should offload some of their work to the cloud storage and should allow the client to directly deal with the cloud storage
  • But in such cases, security is a big concern because you are directly allowing the client to access your cloud storage
  • To deal with this situation, we need a pattern which can be helpful

Introducing the Vault-key pattern in Azure

  • One of the solutions to the situation we discussed above would be to provide a runtime generated key\token to the client and the client can access the storage using that keys\tokens

3.1

  • As you can see above, whenever the client wants to do the upload\download operations with the cloud storage, the web application will provide the token to the client
  • The client can use this token to access the cloud storage
  • Note that, these keys become invalid after the specific time

As per the Microsoft team:

  • Use a token or key that provides clients with restricted direct access to a specific resource or service in order to offload data transfer operations from the application code
  • This pattern is particularly useful in applications that use cloud-hosted storage systems or queues, and can minimize cost and maximize scalability and performance

So if your client needs to upload the file then they need to write below code in the client:


// Make sure the endpoint matches with the web role's endpoint.
var tokenServiceEndpoint = ConfigurationManager.AppSettings["serviceEndpointUrl"];

try
{
var blobSas = GetBlobSas(new Uri(tokenServiceEndpoint)).Result;

// Create storage credentials object based on SAS
var credentials = new StorageCredentials(blobSas.Credentials);

// Using the returned SAS credentials and BLOB Uri create a block blob instance to upload
var blob = new CloudBlockBlob(blobSas.BlobUri, credentials);

using (var stream = GetFileToUpload(10))
{
blob.UploadFromStream(stream);  ////
}

Console.WriteLine("Blob uploaded successful: {0}", blobSas.Name);
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}

Note – I have used sample code from the mspnp. This is just one piece of code, whole code can be found here – https://github.com/mspnp/cloud-design-patterns/blob/master/valet-key/ValetKey.Client/Program.cs

Some of the important points to consider when you are going to use Vault key design pattern:

  • Validate the upload\download operations because a hacker can misuse the keys
  • Enable logging for all the operations related to Vault key
  • Use HTTPS to deliver the keys securely to the client
  • Allow only specific permission to the client, keys can be configured accordingly
  • The key should be disabled after specific time to make the process more secure, it should not be too short or too long
  • The client should always notify the application when they are done with the operations with the cloud storage

Some of the benefits of Vault key pattern:

  • Maximize the performance and scalability of the application by offloading the work which can be handled by the cloud storage
  • Minimize the cost by redirecting the clients to the cloud storage
  • Very helpful for large upload\download operations
  • Useful when the data is stored in a different data centers

If you are more interested in the AWS then there is Key Management System(KMS) in AWS which is the alternative of the Azure Vault key. More details here.

If you want to know more about the Vault key coding then I have forked the code from the Microsoft samples for this pattern which you can find here.

Hope it helps.

2 thoughts on “Azure Vault key security pattern: Cloud design patterns part I

Leave a comment