Just like most people I love how easy it is to work with the Windows Azure platform. You download a publish settings file, import it in Visual Studio and now you have access to the complete subscription. Besides that you can use it in the PowerShell Cmdlets, in the azure-cli, use it in combination with the Service Management API…
But what happens when other people get a hold of your publish settings file? Do you realize they can access all your data? That they can connect to your Cloud Services using Remote Desktop and get a hold of your code? That they can stop Virtual Machines and download the disks? …
Now before reading the rest of this post, I suggest you go to the Windows Azure portal, to the Settings menu and finally the Management Certificates tab. How many certificates do you see? 10? 20? 100? Most of these certificates come from a publish settings file (which is just an XML file that contains your subscriptions and a certificate). For each certificate you see there, do you know who has access to them?
Oh and while we’re at it, do you know how secure these publish settings file are exactly? Well, … they’re not. If someone steals your USB-stick, your laptop or any other device holding your publish settings file then I suggest you quickly remove those certificates from the portal.
Reducing the attack surface
So what we tend to do is split up our subscriptions. For example, we have a subscription that we use for Trainings and Demos and for each project we have a subscription in which we run the Test and CI environments. The worst thing that could happen here is that if people get access to these subscriptions they might get a hold of our code. But the data and the privacy of our users could not be compromised.
Now for each production environment of our projects we have a different subscription. And only a handful of people have access to these subscriptions. Now in order to improve security (I’m not saying you’ll close down everything) you could choose not to use a publish settings file.
If you remember the good olden days of Windows Azure, you had to generate a certificate, upload it to the portal and copy your subscription id from here to there. Let’s see how we can integrate this with a smartcard (or something similar like a dongle).
Smartcards…
So here in Belgium most of us have a Belgian eID (a smartcard) which holds our personal information, including 2 certificates which can be used for authentication and for signing. Here is a picture of my eID (where I look like an escaped convict):
If you connect the smartcard using a card reader it will install the public key of the certificate on your machine (in the Current User\Personal Store):
But the private key will remain on the card and as soon as you’ll try to access it you’ll need to enter a pin code. This means that you’ll have 2 extra layers of security before people could access that certificate. First they would need to get a hold of your card and second they would also need to know your PIN code.
Linking your smartcard to your subscription
So the first thing I’ll do is go to my Personal store (using Start > Run > certmgr.msc) and export the certificate intended for authentication. I’m unable to export the private key (which is a good thing!) and I’ll simply export it to sandrino.cer
Now go to the Management Portal, open the Settings menu, open the Management Certificates tab and click the Upload button. This is where you’ll be uploading the *.cer file (the public key):
As you can see it’s very clear which certificate belongs to me. If I would ever leave the company or no longer work for that customer, the administrator could simply remove the certificate with my name on it and that would be the end of it.
Securely deploying our Cloud Service
Now whenever you want to deploy a Cloud Service in Visual Studio you’ll see the Sign In page:
This is where you typically import the publish settings file. Don’t. In the dropdown choose the Manage option and add a new subscription. Choose the certificate from your smartcard (the thumbprint will match the one you’ll see in the portal) and enter the subscription ID (also from the portal). Press OK:
Uh-oh!? Visual Studio is trying to access my private key and the smartcard kicks in, which requires me to enter my PIN code first. Something you’ll want to try next is remove the card, restart Visual Studio and try to publish your project:
Yes indeed. In order to authenticate to the Service Management API, Visual Studio needs your private key (which is stored on your smartcard). By using this for you “production subscriptions”, it would mean Visual Studio will always ask for your smartcard & PIN code before it can do anything with your subscription.
What about my PowerShell scripts?
Just like Visual Studio, you can use the PowerShell Cmdlets with a publish settings file or with a certificate. If you want to use a certificate, you’ll need to run this:
Set-AzureSubscription -SubscriptionName “My Subscription” -SubscriptionId <paste-your-id-here> -Certificate C:\path\to\your\public\key.cer
Now this means you can also use the PowerShell Cmdlets together with you smartcard (the “insert smartcard” and “enter PIN” screens are handled automatically by your smartcard):
Just my 2 cents
Authenticating using a smartcard will add some friction to the “Windows Azure experience”, but it’s up to you to decide whether you need it or not on your project. Just keep in mind that users are trusting you with their personal information, so you should at least have some governance in place.
Enjoy!