SymmetricalDataSecurity: Best Security Practices for Microsoft Azure: Locking Down Your Environment

As you know, moving your workloads to the cloud doesn’t mean you’re not responsible for the security of your operating system, applications and data. Building on the security of the Azure infrastructure, this shared security responsibility starts with making sure your Azure environment is secure. In this post, we’re going to walk step-by-step through what you need to do to secure access at the administrative, application and network layers.

We’ll follow this up with the next steps to ensure security of your workload. Make sure you also share your own tips for managing security in Azure in the comments section below!

Now on to the best practices…

Plan before your Cloud Adoption

I want to talk about this general principle before I start on the security tips because it’s essential and often overlooked. Unfortunately, it’s a common mistake for application owners/departments or business units to bypass IT and security teams to sign up with cloud services without any plan or much forethought. Such adoption of cloud services often leads to complicated and costly corrections later on when your IT and security teams become involved. For example, if you don’t clearly separate your subscriptions, you can inadvertently give access to production services to employees who don’t need such access. I must admit, thinking and planning takes time, but when you invest your time planning your cloud adoption strategy, it allows you to establish a solid foundation upon which you can build and grow without fearing costly changes later on.

Now we’ll walk through the general flow of the Microsoft Cloud Service (Azure) sign-up and introduce you to the some fundamental concepts associated with Microsoft Azure. This will help you better understand the relationship between these components, what the security principles for each step are, and what options are at your disposal.

Creating Your Azure Account

To do anything in Azure, you need an account. When you create an account with Azure using the Azure Account Center, there are two choices provided to sign up: a) Microsoft account such as <user>@outlook.com, <user>@hotmail.com or <user>@live.com; or b) Your organization/work account — these are sourced from Azure Active Directory.

Microsoft Azure subscriptions use Azure Active Directory to sign users into the management portal and to secure access to the Azure management API. It’s recommended to use organization/work accounts that are created from within Azure Active Directory and provide more options for managing them. For example, organization/work accounts can be supplemented with multi-factor authentication which is always recommended for privileged users such as “account administrator/global administrator.”

Consider creating a “service” email account in your organization, e.g., a distribution list (DL) with an external SMTP address associated with it that can be used for Azure sign-up. This email DL should hold few key project/stakeholders as members, that way, your Azure Account is unaffected by employee turnover. For example, “Comp_Azure_Srv@yourdomain.com” could be the user ID used for your Azure account sign-up process. This will become your “Account Administrator or Global Administrator.” Simply place this user is your “root” account. The account administrator is the only one who is authorized to access the account center to create subscriptions, cancel subscriptions, change billing for a subscription, change service administrator, and more. There is a one-to-one relationship between Azure account and account administrator.

Setting up Your Subscription

Once the Azure account is created, the next step is to set up subscriptions. Every cloud service belongs to a subscription; subscriptions help you organize access to cloud service resources. The account administrator, the person who creates the Azure account, is the only one who can create subscriptions and is designated as the default “service administrator” for the subscription. There is a one-to-one relationship between subscription and service administrator. Access to the Azure Management Portal is granted to this administrator. You can also create up to 10 co-administrators per subscriptions. You can create multiple subscriptions based on your requirements, e.g., you can create individual subscriptions based on the type of environment, such as “development,” “staging” and “production.” This enables you to view usage and control access to each service granularly; it is then advisable to separate your workloads into specific subscriptions to avoid accidental changes, etc.

Figure 1 – Azure Account to Subscription and Access Administrators

Setting Role-Based Access Controls (RBAC)

Now that the subscriptions are created, you can start to control which cloud resources your employees can access and what actions they can perform on those resources. In the new Microsoft Azure Preview Portal, Microsoft has announced the preview release of Role-Based Access Control (RBAC). Using RBAC, you can limit the access of users and groups by assigning them roles on Azure resources. Azure role-based access control comes with different built-in roles: “owner,” “reader” and “contributor,” that can be assigned to users, groups and services.

It’s easier to first create and assign access to the “subscription level” and then make adjustments at the resource levels. For example, John Smith (your DBA), can be assigned as a “reader” role at the subscription level, and based on his job role (i.e. DBA) and application structure (three-tier application, Web, app and DB), you can then assign the “contributor” role to him at the virtual machine level that is running the database for your application.

Figure 2 – Reader Access on the Subscription level

fig 3

Figure 3 – Contributor Access on the VM level

Control Your Access Points to Azure Resources

Next, you need to decide how your user will access the cloud resources that they have been given access to. Microsoft Azure allows multiple accesses and management capabilities, and it’s important to restrict remote access to your VM from a dedicated hardened workstation that runs only required services and applications and may have restricted network access to only what is needed to perform tasks at hand. These workstations are not used by your users for day-to-day activities. You can further lock down access to Azure resources by having a Remote Desktop Gateway (RDGW) installed on premise that is connected to the Azure environment. This RDGW, together with Windows Server Network Access Protection (NAP), helps ensure that only clients that meet specific security criteria established by your AD GPOs can connect.

In this type of setup, the local instance of Windows Firewall (or a non-Microsoft client firewall) is configured to block inbound connections, such as RDP. The administrator can log on to the on premise hardened workstation and start an RDP session that connects to Azure VM, but cannot log on to a corporate PC and use RDP to connect to the hardened workstation itself. This practice is meant to restrict and reduce your attack surface. The following logical view shows how access to the Azure VM is only allowed from the hardened on premise workstation via RDGW.

Figure 4 – Taken From: http://ift.tt/1ES4T5l

Network Layer Security Considerations

Network security is one of the most important building blocks of your overall security design, whether it is done on premise or in the public cloud. Microsoft Azure provides the infrastructure necessary to securely connect your virtual machines (VMs) to one another, and be the bridge between the cloud and your on premise data center. The responsibilities for network protection and management are shared between you and Microsoft. For example, Microsoft Azure takes care of spoofing attacks by performing hypervisor-based checks on the outgoing network, i.e., a compute node is disallowed from sending traffic from any IP other than its own. Similarly, as an Azure subscriber, you cannot walk into a Microsoft data center and rewire a server rack, but you are allowed to do the equivalent within your cloud environment through a number of different virtual mechanisms, including guest OS firewalls, VNET Gateway configuration, and virtual private network (VPN).

Let’s take an “inside-out” look toward the networking in Azure; just like with an on premise model, you should plan your network design based on your security, connectivity and application requirements. This must be done prior to launching your workloads (VM) in Azure since, after a VM has been deployed, you can’t move it to the virtual network without redeploying it.

By leveraging Windows Azure virtual networking service, you can create virtual networks for the purposes of segregating your three-tier application stack where you put your Web, app and DB VM’s.

Figure 5 – 3-Tier Virtual Network

Once the virtual network is created, you can attach your virtual machine to a Windows Azure Virtual Network. All VMs attached to the virtual network can only talk to other VMs attached to the same virtual network. If communication should be restricted among VMs within the same subnet, e.g., VMs in Web-Tier can’t talk to each other (east-west), then either use the guest OS Firewall, or deploy third-party host-based firewall solution. To restrict the traffic flow between subnets and VMs (e.g., the VMs in Web-Tier can’t talk to DB-Tier), you can use guest OS firewall, deploy a third-party host-based firewall solution, or you can also use network level access control from Azure called Network Security Groups as long as your vNet is not associated with affinity groups. NSGs will allow a two-tier level of traffic filtering on inbound and outbound flow and implement a traffic flow firewall policy that is maintained at the network level instead of the OS level.

External access to the VM from the Internet is defined by creating input endpoints that allow inbound communication to your VM. In the three-tier network design, VMs placed in an app-tier and DB-Tier usually don’t need direct access from the Internet. For this reason, it’s recommended to restrict direct access to them by not having any input endpoints for such VMs and creating input endpoints to only open ports that you need open from the Internet. When access to application and DB servers from outside is required, you can also specify access control lists (ACLs) on input endpoints to control the source IPs from which the VM will allow inbound traffic, as shown below.