Storing your data in the cloud, for some, has eerie implications, implying that you are handing over your potentially sensitive information to someone else.
Well, that doesn’t have to be the case in Azure. I introduce you to storage accounts in Azure. Storage accounts allow you to store your data in Azure and also allow you to have granular control over who is accessing that data and for how long. The two features we’ll discuss in the coming article will assure nobody is accessing your data except yourself and people you explicitly authorize. First, here’s a brief introduction to storage accounts.
Azure storage is quite extensible and offers many ways to store data for whatever your purpose may be, whether it’s storing a NoSQL store, structured data, or unstructured data.
Azure storage allows you to replicate across data centers or geographic regions for high availability, it has encryption built in, it’s accessible from anywhere in the world, and it’s fully managed (no maintenance required)!
Microsoft also provides SDKs for Azure storage in .NET, Java, Node.js, Python, PHP, Ruby, Go, and others as well as a REST API.
Being that all of your storage is behind a REST API in Azure, gaining access to your storage account is as simple as making a GET request given the appropriate calls, so locking down access is essential!
First Level of Security
The first level of securing your storage accounts is by using an access key. An access key uses the storage service and other parameters to produce an encrypted signature string that’s passed in the requ
est, in the authorization header. Whoever has these keys has read and write access to your storage account. For as long as they have that key, they can access your storage account. Until you regenerate the key, anyone who has that key has full access to your storage account.
An example use case for this is when you’d like to have your application access your storage accounts, for a place to store files that users are uploading while using your application. This ensures any user data that’s uploaded is secure in that location. Also, with built-in encryption (at rest), you can ensure the safety of that data.
Second Level of Security
The second, added level of securing your storage accounts are shared access signatures.
A shared access signature (SAS) creates a URI, granting the person-specific rights for a set period. You can limit the access to only one service (blob, file, queue, or table) and permission level (read, write, delete), or limit the type of resource to service, container, or object.
The SAS is generated based on your access key, so if you create a SAS and you entered a too-broad time domain, you can quickly regenerate the shared key and start over. Two keys are created for you when you create a storage account so you can alternate and use two SASs for two different purposes.
Furthermore, for blobs, tables, files, and queues, you can generate an additional access policy for tighter control over the start and end time of that access to that specific resource. For example, I could only allow read access to my single blob object for 24 hours via HTTPS protocol.
Do you still want more?
Are you or your company interested in securing your storage accounts and making sure your data doesn’t fall into the wrong hands? Perhaps you’d like to learn about transport-level encryption and how you can secure the data in transit as well as at rest.
All of this and more is covered in the new Azure Infrastructure and Deployment course on Linux Academy! This course prepares you for the Microsoft Azure Administrator Associate certification Exam AZ-100.
This course includes an in-depth discovery of subscriptions, virtual machines, virtual networks, storage accounts, and Azure Active Directory. With Hands-On Labs, you’ll be able to use what you’re learning in your pre-built Azure environment!
I can’t wait to see you in this course and share the intricacies of building infrastructure in Azure.