1
As you probably 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. As the first in a series of posts on Azure best practices, we will walk step-by-step through what you need to do to secure access at the administrative, application and network layers.
In a follow-up post, we’ll talk about the next steps to ensure the 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 it. While thinking and planning takes time, it is a good investment. When you spend 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. Importantly, 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 in 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 subscription and can create multiple subscriptions based on your requirements. For example, you can create individual subscriptions based on the type of environment, such as “development,” “staging” and “production.” It is advisable to separate your workloads into specific subscriptions to avoid accidental changes, enabling you to view usage and control access to each service granularly.
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
Figure 3 – Contributor Access on the VM level
Control Your Access Points to Azure Resources
Next, you need to decide how your users will access the cloud resources that they have been given access to. Microsoft Azure allows multiple access methods and management capabilities, so 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://go.microsoft.com/fwlink/?linkid=518999&clcid=0x409
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 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 (VMs) in Azure, because 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, application and DB VMs.
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 solutions like Trend Micro Deep Security, 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 these 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.
Figure 6 – Restricted Access to DB Server using ACL to allow from a specific workstation Source IP
Similarly, the outbound communication flow of your VM should be restricted based on your security and application requirements.
The logical diagram in Figure 7 below depicts the network control choices we have discussed for our sample three-tier application stack.
Learn More
In a follow-up post on Azure security best practices, we’ll discuss the next steps to ensure the security of your workload.
And if you’re in Chicago attending the Microsoft Ignite Conference (from May 4-8), drop by the Trend Micro booth (no. 230) to talk to security experts about how we can help with securing your Azure workloads. In the meantime, visit us online here.
Figure 7 – Network Access Controls with 3-Tier Application Stack
Read our next blog post in this series to learn how to create a defense in depth security posture.References:
https://msdn.microsoft.com/en-ca/library/azure/hh531793.aspx
http://azure.microsoft.com/en-us/documentation/articles/role-based-access-control-configure/#builtinroles
https://msdn.microsoft.com/library/azure/dn468213.aspx
http://azure.microsoft.com/en-us/documentation/articles/azure-preview-portal-using-resource-groups/
http://weblogs.asp.net/scottgu/azure-sql-databases-api-management-media-services-websites-role-based-access-control-and-more
http://go.microsoft.com/fwlink/?linkid=518999&clcid=0x409
https://msdn.microsoft.com/en-us/library/azure/dn631643.aspx
https://msdn.microsoft.com/en-us/library/azure/dn848316.aspx
No comments:
Post a Comment