Skip to main content

Configuration and Security of Azure Storage Accounts

Hands-On Lab

 

Photo of Shawn Johnson

Shawn Johnson

Azure Training Architect II in Content

Length

01:30:00

Difficulty

Intermediate

This hands-on lab provides some experience with configuring and securing an Azure storage account. We log into the Azure portal and create a storage account, then get familiar with the configuration options for it, including replication options, access tiers, and secure transfers. We RDP into a Windows VM and install Microsoft Azure Storage Explorer. Then we connect to Blob storage, and attempt to upload and retrieve data from the blob. Using the Azure Portal, we use access policies and shared access signatures to both permit access to the storage account and deny access to blob data. Subsequent attempts to upload and retrieve data from blob storage should fail. Completing the lab provides the experience required to configure and secure an Azure Storage account.

What are Hands-On Labs?

Hands-On Labs are scenario-based learning environments where learners can practice without consequences. Don't compromise a system or waste money on expensive downloads. Practice real-world skills without the real-world risk, no assembly required.

Configuration and Security of Azure Storage Accounts

Introduction

This learning activity provides some experience with configuring and securing an Azure storage account.

We will log into the Azure portal and create a storage account, then get familiar with the configuration options for it, including replication options, access tiers, and secure transfers.

We will RDP into a Windows VM and install Microsoft Azure Storage Explorer. Then we will connect to Blob storage, and attempt to upload and retrieve data from the blob.

Using the Azure Portal, we will use access policies and shared access signatures to both permit access to the storage account and deny access to blob data. Subsequent attempts to upload and retrieve data from blob storage should fail.

Completing the lab will provide the experience required to configure and secure an Azure storage account.

Once you log in to the Azure portal, using credentials from the hands-on lab page, we can get moving on the tasks.

Note that we'll be doing a lot of key creating and reconfiguring things. If we're getting errors we can't get past in the Azure Storage Explorer, try shutting it and starting it up again.

In the Azure Portal, Create and Configure a Storage Account

In the Azure Portal, click Storage accounts in the left navigation pane, then click on + Add in the storage accounts blade. Create a storage account in the current resource group. Most of the information is provided here, but we need to give it a unique Storage account name. Use only numbers or lowercase letters. Then, set Replication to Locally-redundant storage (LRS).

We'll leave the rest of the settings along, and then click Review + create. Once Azure has validated that we set things correctly, we can go ahead and click Create.

Once it's finished, we'll see the notification. Click on Go to resource there, and we can take a look. Click on Configuration in the left-hand menu to see what we can change after creation.

Log into the VM with RDP, Then Download and Install Microsoft Azure Storage Explorer

In the far left menu, click on Virtual machines. In there, click on our virtual machine's name. In the Overview screen, there's a Connect button. Once we click on that, we can see a new button to click for downloading an RDP file.

Once we open it in our Remote Desktop app, we want to change a setting or two. Make sure we're not connecting to an admin session. We also want to make sure that this remote session doesn't launch in full-screen mode. Set the resolution instead for something that will give us room to maneuver in both the remote and local desktops.

These RDP login credentials are what we'll need for logging into the VM:

  • UserName: azureuser
  • Password: LA!2018!Lab

We need to get to Storage Explorer, but first we've got to change some Internet Explorer settings. Click the Tools icon (the gear in the upper-right corner of the window) and select Internet options. Click over to the Security tab, then click on Custom level... down in the Security level for this zone section. Scroll down about halfway on this page, and enable Downloads. Now we can use the Storage Explorer URL that's back on the hands-on lab page:
https://go.microsoft.com/fwlink/?LinkId=708343&clcid=0x409
Once we've plugged that URL into the browser, we'll get a download window pop-up. Click Save, and run it when prompted. We need to accept all of the license agreements, leave the defaults set, and then launch it when the install finishes.

Download Sample Images to be Uploaded into Blob Storage

Let's set that window aside for a bit, and open up Powershell. Run this code in there:

Add-Type -AssemblyName System.IO.Compression.FileSystem

$url = "https://github.com/linuxacademy/content-azure-labs/blob/master/zips/Azure-LearningActivity-CfgSecMon.zip?raw=true"
$zipfile = "C:UsersazureuserDesktopAzure-LearningActivity-CfgSecMon.zip"
$folder = "C:UsersazureuserDesktopimages"

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Invoke-WebRequest -UseBasicParsing -OutFile $zipfile $url

[System.IO.Compression.ZipFile]::ExtractToDirectory($zipfile, $folder)

Remove-Item -Path $zipfile

This code will download a zip file from a GitHub repository, then extract it, so that the file and the extracted directory (images) are both sitting on the desktop. Hitting enter let's the script finish, which deletes the original zip file.

Open Azure Storage Explorer, Connect to the Azure Account, and Upload Image Files

Back over in the Storage Explorer window, click on the plug looking button, which will begin the process of setting up a new connection. In the first window that pops up, leave Add an Azure Account selected, make sure the Azure environment is set to Azure, and click the Sign in... button.

A login window will pop up, and we can use the Azure Portal credentials that are sitting on the hands-on lab page.

Once we're in, we can click Apply (on the left-hand side of the Storage Explorer window) and we'll be able to see our storage account. Expand that (by clicking the arrow next to it) and right click on Blob Containers, then select Create Blob Container. Name it images, and look over on the right as it gets created. There's an Upload button. Click on that, select Upload Files..., then the ... to the right of Files box. Browse to the images folder on our desktop and highlight a few to grab.

Leave everything the same in the Upload Files window, then click Upload.

Enable Security on the Storage Account Using the Various Methods Available

Access Key

Back in the Azure portal, we should still be sitting in our storage account. Find Access keys in the left-hand storage account menu. Once we're in there, click on the blue copy button next to the key1 Key. Head back over to Storage Explorer and click the plug again. This time, we're going to select Use a storage account name and key and click Next. In the next window, give this connection any name you like, add our storage account name in the next box, paste our key into the Account key box, and choose Azure for a Storage domain. Leave the Use HTTP unchecked and click Next. Then click Connect.

Now the file tree looks a little different. We can see our storage account key. Expand that, and we'll see the same file/directory layout that we see (and saw earlier when we made a container) down in the Storage Accounts. If we look in Blob Containers, we'll see the images that we created earlier, containing whatever images we uploaded a little while ago.

Just to see if things are working, access-wise, let's upload a few more images. Then let's try to download a couple. The Upload and Download buttons should both work fine.

Regenerating a Key

In the event that we need to create a new key, we'd go back into the Access Keys in the Azure portal, and just hit the "refresh" button next to key1. This will pop a warning up, which is fine. But now, let's go back into Storage Explorer. If we try to browse the one we just set up with a key, we'll be blocked. Until we replace the key in Storage Explorer, it won't work.

Shared Access Signatures

For granting access in a more granular fashion, these are the way to go. Back in the Azure portal, in Storage accounts, there's an option Shared access signature. Click on that, and we can look at all of the options. We can grant and restrict privileges to services, and resource types, then specify what exact permissions are being granted. We can even set dates and times for when these permissions start and expire.

For our test signature, set things up this way:

  • Allowed services: Blob
  • Allowed resource types: Service
  • Allowed permissions: Read and List
  • Start and expiry date/time: Set it to expire at 11:59:59 PM, tonight
  • Allowed protocols: HTTPS only
  • Signing key: key1

Once those are all set, click on the Generate SAS and connection string button. This process is similar to making an access key. To make this work, head back over to Storage Explorer and click the plug again. This time, we're going to select Use a shared access signature URI and click Next.

In the next window, most everything is filled out. Edit the name a bit (add -SAS or something to the end of it), then click Next. Click Connect to actually connect it to the storage account.

If we try to explore our blob container, we're going to get an error. It's because we didn't allow Container or Object in the Allowed resource types. Let's make yet another shared access signature, same as the one we just made, but this time allow those resource types.

Now if we try to browse this newest blob container in the Azure Storage Explorer, it should work without a problem. We can download files too. But we can't upload them, because we only gave ourselves read access. Let's make another shared access signature to fix that.

The only difference with this one will be checking the Write box in the Allowed permissions area. Generate the string again, then get this all added into Storage Explorer again. When we browser and test again, we'll see that we can browse and download, but we can also upload.

Revoking Access

Since we used our key1 to sign this, resetting that key (like we did earlier) will revoke access to anyone or anything else that was using that key. There's another way.

Settings on the Service Itself

In our storage account, navigate to Blobs in the left-hand menu, then click on the images container. Now we can see all the images we've uploaded into it, on the right-hand side. Over on the left though is a link called Access policy. Let's add one, and see what happens. Click the + Add policy button under the Stored access policies section.

For the Identifier spot, let's call it Test SAP. In the Permissions dropdown, select Read, Write, and List. Give it start and expiry times that will only last until the end of today. Click OK when we're done. Don't be fooled though. We're not really done. We still have to click Save, otherwise we'll lose these changes when we navigate away.

Applying Our Configuration

Get back into Azure Storage Explorer, and right click on the first images container that we set up. Find Get Shared Access Signature in the menu and click that. The first dropdown we can select from is Access policy. And the one we just created should be in there. Select that, and notice that everything else in this dialog is greyed out. That's because they've already been defined in the access policy. All we need to do now is click Create. Copy the URL on the next window, because we'll need it. Click Close.

Back over in the Storage Explorer window, click on the plug looking button again, and select the Use a shared access signature URI option in the window that pops up. Click Next, and later the Display name so that it's unique. Click Next again, then Connect.

To prove that resetting a key won't affect this though, we're going to set up yet another connection. Add an account (with the plug button), then select Use a storage account name and key from the list. In the next window, give this connection any name you like, add put our storage account name in the next box. Paste our key into the Account key box (you'll probably have to copy it to the clipboard again from the Access keys page in the Azure portal), and choose Azure for a Storage domain. Leave the Use HTTP unchecked and click Next. Then click Connect.

We should be able to browse with this account.

Now, from the account we set up with a shared access signature, let's see if we can browse and upload files. We can, right? Now we need to restrict access on this account. We can do it by resetting the key, but that's going to mess up anything else (like the final account we set up) that uses the key.

Instead, let's get back into the Azure Portal, into our blob's Access Policy, and then delete the stored access policy that we created a while back. Remember to hit Save up top, or the operation won't get applied.

Now, back over in Storage Explorer, right click on the SAS-Attached Services link in the file tree, and click Refresh. Now try to browse the blob container that's in it. It doesn't work anymore.

But if we go back and browse in the newest account we created, we can still see and edit things.

Conclusion

So, you can see how using two tools in tandem is actually allowing for better controls over who has access to our Azure storage containers. We were hoping to learn something handy like this, right? Congratulations!