Overview

Over the years it has been drilled into me to use “Least Privilege” access whenever and however possible. Least Privilege is all about limiting users, systems, and services to only those privileges which are absolutely essential to get the job done. Microsoft Azure should be no different and some would argue even more important when it comes to Least Privilege. However what tends to happen in the cloud space is business units want to avoid/bypass IT Departments and setup in the case of this article Microsoft Azure subscriptions without much thought. This can lead to incorrect users having access to production services and once discovered is hard to correct as once services are deployed you can’t easily move services between subscriptions.

Microsoft Azure Subscription Components:

Enterprise Administrator

Standard Customer – Not Applicable

Enterprise Agreement Customers – The Enterprise Administrator has the ability to add or associate Accounts to the Enrolment, can view usage data across all Accounts, can view the monetary commitment balance associated to the Enrolment, and can provide Account Owner visibility to view charges.

There is no limit to the number of Enterprise Administrators on an Enrolment.

Account Owner

Standard Customer – The Account Owner is the Microsoft Account (formerly Live ID) or Azure Active Directory (AAD) Account that is responsible financially for the Microsoft Azure monetary commitment. Microsoft will send invoices to the email address associated with the Account Owner. The Account Owner can add Subscriptions for their Account, update the Service Administrator and Co-Administrators for an individual Subscription and view usage data for their Account.

Enterprise Agreement Customers – this definition changes slightly. The Account Owner (by default) will not have visibility of the monetary commitment balance unless they also have Enterprise Administrator rights. An Enterprise Administrator can choose to grant the Account Owner the rights to view the monetary commitment.

There is a limit of 1 Account Owner for each Account.

Subscription

A Subscription is a billing container for deployed Microsoft Azure services.

There is a limit of 1 Service Administrator for each Subscription.

There is a limit of 200 Co-Administrators for each Subscription.

Service Administrator

The Service Administrator can perform all functions within a Subscription including add/remove Co-Administrators. By default the Service Administrator will be the same as the Account Owner.

Co-Administrator

A Co-administrator can perform all functions within a Subscription except change the Service Administrator and add/remove other Co-administrators.

Use Multiple Microsoft Azure Subscriptions

Multiple Subscriptions allow a company to easy view billing for each Subscription and limit who can access the Microsoft Azure services associated with that subscription.

An example of using multiple subscriptions might be:

Subscription 1

• Name: “Company – Project 1 – Development”
• Service Administrator: Development Manager
• Co-Administrators: Developers on Project 1

Note: A developer may not need to be a Co-Administrator but instead only require a Management Certificate as explained below.

Subscription 2

• Name: “Company – Project 1 – Test”
• Service Administrator: Test Manager
• Co-Administrator: Testers on Project 1

Subscription 3

• Name: “Company – Project 1 – Pre-Production”
• Service Administrator: IT Manager
• Co-Administrator: Senior IT Support Team (Level 3)

Subscription 4

• Name: “Company – Project 1 – Production”
• Service Administrator: IT Manager
• Co-Administrator: Senior IT Support Team (Level 3)

Use Descriptive Names for Microsoft Azure Subscriptions

When it comes to naming a Microsoft Azure subscription, it is good practice to use descriptive names.

I typically recommend the following format, but as long as you develop a format that works for your company go for it.

My Recommendation:

<Company> – <ProjectName> – <Environment>

Explanation of My Recommendation

<Company> is the name of your company. You might be wondering “Why would I add my company name to my company’s Subscriptions that seems a little overkill”. The reason I recommend this is if/when you hire a contractor or outside company to assist you with your Microsoft Azure services you will most likely need to make then a Co-administrator on a particular Subscription. When that contractor/company logs into the Microsoft Azure portal they see a list of all subscription they are associated with. So they might see: CustomerASubscription1, CustomerASubscription2, CustomerBSubscription1, etc.

If you named your Subscription “Development” and some other company named their Subscription “Development” then the contractor/company would see “Development” and “Development” in the list. To me that adds a risk where they could accidentally perform some action on the wrong Subscription. The risk is pretty small as they would more than likely also need to know the service name such as storage account “XYZ”, but still a risk is a risk and when possible should be mitigated.

<ProjectName> is the name that your project is known by. You might have one project that is all about your company’s intranet which is called “Inside” and another project that is all about your company’s public web site. In this case you might have one set of service for “Inside” where you use “Inside” as the project name and another set of services for your public website where you might use the name “PublicWebsite” as the project name.

Now you might be thinking “That seems like I might end up with a lot of Subscription in the end which is pretty overkill”. Yes, you are correct you might, but then again I would rather have a lot of Subscriptions that I can control access to over, say, one big Subscription called “Production”. Plus do I really want the administrator of ProjectA having full access to ProjectB services in Production?

<Environment> is the name I choose to use because in most of the deployment of Microsoft Azure services I have worked with, that really is what it turns out to be. A group of Microsoft Azure services that all form part of “Development”, “Test”, or “Production”.

NOTE: I don’t recommend using an environment name of “Staging” because I feel that it can become confusing when Windows Azure deployments have two slots “Staging” and “Production”.

Use Named User Accounts

A named account is an account that is associated to a single person and typically named in such a way as to identify that person. Example: First.Last@outlook.com instead of SweetGuy88@outlook.com. You might know who SweetGuy88 is today but in six months times I bet you forget who that is and have to run around trying to figure it out. Save yourself the hassle and used named accounts day 1 where possible.

Another thing I recommend is that you setup named accounts @ your company name instead of @hotmail, @outlook, etc. When you setup a Microsoft Account, you are required to verify your identity which means Microsoft sends an email to first.last@company.com that you must click verify before the account is considered verified. When I use contractors or outside companies I recommend that they setup the accounts to be the same as the work email address I know them by. This helps me as an administrator identity who is inside my organisation and who isn’t.

Establish Guidelines for Microsoft Accounts (formerly Live IDs)

Microsoft Accounts are out of your company’s control for the most part. As such I recommend you establish some guidelines for Microsoft Accounts that you try and push your users to adopt. It would be nice if Microsoft had a way to setup Enterprise Microsoft Accounts that as an Enterprise I could better control. Federation with Microsoft Azure Active Directory helps in this matter but does not solve the problem 100%.

The Guidelines I personally use are:

• Use a strong password. Example: 16 characters long with mixed case and numbers. The longer and more complicated the better. If this account is associated with your production Windows Azure subscription, then this account can access not only the Microsoft Azure services (Stop/Delete services) but also has access to all the data in your storage accounts within the associated Subscription.
• Use a named account. Use an account name that is easy to identity. first.last instead of SweetGuy88.
• Link to your company email. This way the account will have to be verified using a company email address they have access to. Also if the person leaves your organisation you may in some cases be able to reset the password if required.
• Change Passwords Regularly. This is always a good practice but is becoming harder and harder to do when we have so many passwords to remember. If remembering passwords becomes an issue a tool such as LastPass or KeePass might provide assistance.
• Add Alternate email address. I also associate with my Microsoft Account another email address so that if I forget my password, I have another ways to get back in.

Use Microsoft Azure Affinity Groups

Microsoft’s Definition – Affinity groups allow you to group your Microsoft Azure services to optimize performance. All services within an affinity group will be located in the same data center. An Affinity Group is required in order to create a virtual network.

Why is this a good practice? Originally when Microsoft Azure datacentres were built, latency between different parts of the datacentres could be high. Today this is less of a reason to use Affinity Groups as Microsoft datacentres are now built in a way to keep latency down. Affinity Groups are now used mainly to simplify deployment of services, instead of having to pick both a Region and Subscription you only need to pick an Affinity Group. Affinity Groups are used in all of Microsoft’s backend management logic of Microsoft Azure. When services are moved, restarted, restored, etc. an Affinity Group is taken into an account and treated as a set of services and kept close together and in the same physical datacentre. Once services are deployed you can’t move services easily into an Affinity Group.

Use Management Certificates

Microsoft’s Definition – Management Certificates permit client access to resources in your Microsoft Azure subscription. Management certificates are x.509 v3 certificates that only contain a public key, and are saved as a .cer file.

If a person requires the ability to deploy or change services running in Microsoft Azure but does not require access to the Azure Management Portal, then provide them only a Management Certificate. This scenario is common with a large development teams. A developer that needs to deploy to Microsoft Azure services through a tool such as Visual Studio may only require a Management Certificate.

NOTE: There is a limit of 100 management certificates per Microsoft Azure subscription. There is also a limit of 100 management certificates for all Subscriptions under a specific Service Administrator’s user ID. If the user ID for the Account Administrator has already been used to add 100 management certificates and there is a need for more certificates, you can add a Co-Administrator to add the additional certificates.  Before adding more than 100 certificates, see if you can reuse an existing certificate. Using Co-Administrators adds potentially unneeded complexity to your certificate management process.

Standard Customer – Good Practice Setup

Enterprise Agreement Customers – Good Practice Setup

Summary of Good Practices

1. Use Multiple Microsoft Azure Subscriptions
2. Use Descriptive Names for MicrosoftAzure Subscriptions
3. Use Named User Accounts
4. Establish Guidelines for Microsoft Accounts (formerly Live IDs)
5. Use Microsoft Azure Affinity Groups
6. Use Management Certificates.