Over the past couple of years, there’s been a dramatic shift in the acceptance of public cloud platforms for running applications and workloads. Not just among startups and smaller businesses looking at the affordability of cloud economics, but in general, the fear around using a multi-tenant cloud for running all workloads has subsided.
It’s difficult to point to a single catalyst for this change. While cost savings is a significant driver, other factors have also played a role, including the success of industry disruption with cloud agility (Netflix, Uber and Airbnb) and the need for greater integration with other businesses, whether they’re a partner in your value chain or a supplier of a service you’re consuming (such as a cloud or SaaS solution).
For enterprises, the shift to public cloud has always been contingent on trusting that your data is safe in someone else’s data center. Not only from a security perspective, but also private and in accordance with the ever-growing list of regulations for protecting that data.
Microsoft has gone to great lengths to secure your trust in the Azure platform, achieving more compliance certifications than any other cloud provider. You can see the long and growing list of those certifications here.
But knowing you can entrust Microsoft Azure with your data is only the first step in the process of running secure workloads on it. The fact that Microsoft has achieved a certification, whether it’s HIPAA/HITRUST, PCI or ISO, does not automatically grant you the same certification.
It is still incumbent upon you and your organization to make sure your processes and your use of Azure services align with your data protection and compliance needs. Similarly, the security of your applications and data is not solely on the shoulders of the cloud provider and care needs to be taken for new applications, existing applications being migrated and especially hybrid workloads that leverage both public and private cloud infrastructure.
This is why Rackspace recommends a defense in depth approach. Much like an onion, there are layers to security in the cloud. As you peel those layers back and go deeper into the solution, the responsibility of those layers shifts from the cloud provider (in this case, Microsoft) to you.
Here we will review what those layers are and as we peel them back, we’ll show you where the shift in responsibility moves from Microsoft to you, and how you can use the services Azure provides to protect your workloads. Additionally, we’ll look at the differences between traditional perimeter protection, which you will leverage to prevent unauthorized access, and then look at the “assume breach” strategy and detection employed by Microsoft and Rackspace as a part of our managed security services designed specifically for your environment.
Perimeter protection refers to the traditional approach to IT security; protecting your network by implementing both physical and software solutions to prevent unauthorized or unwanted access to your environment. This has traditionally been handled with edge network appliances like firewalls, load balancers and more recently web application firewalls which are added on top of the physical security measures to ensure that only authorized personnel can access the physical devices residing within the raised floor of the data center.
This has traditionally been handled with edge network appliances like firewalls, load balancers and more recently, web application firewalls which are added on top of the physical security measures to ensure only authorized personnel can access the physical devices residing within the raised floor of the data center.
For physical security in Azure, the responsibility resides solely with Microsoft and begins at their data centers with the use of traditional security measures and technology.
Physical measures include the use of perimeter fencing outside the data centers, security monitoring and controlling access with multi-factor requirements such as badge and biometric readers. This assures only authorized personnel with a legitimate business need can gain access to the facility.
Technology also supplements physical security as you move up the stack from the physical data center facility to the physical network and hosts that run the cloud fabrics of compute, network and storage.
Microsoft staffs a Security Operations Center that monitors and protects against threats with various tools, and even leverages the power of Azure through Artificial Intelligence as part of their continuous monitoring and penetration testing process. One of the larger tools is a distributed denial of service (DDoS) defense system that protects the Azure platform from externally launched attacks as well as attacks from other Azure tenants.
It should be noted that the activities in this section, including DDoS prevention and SOC activities, are focused on the Microsoft Cloud in general and are not scoped to a customer’s specific use of Azure.
Cloud access layer
As we peel back the next layer, we move from the physical and platform protections into a shared control space where traffic is moving from the Internet towards your private network. This is the “cloud access layer,” and it’s identified by the public IP addresses that are exposed to the public Internet and allow traffic to be routed over specific ports back to private services and resources in Azure. Routing is handled by Network Address Translation (NAT) to pass traffic back to the private IP addresses and port within a virtual network.
This is the “cloud access layer,” and it’s identified by the public IP addresses that are exposed to the public Internet and allow traffic to be routed over specific ports back to private services and resources in Azure. Routing is handled by Network Address Translation (NAT) to pass traffic back to the private IP addresses and port within a virtual network.
While you can’t bring your own public IP addresses to Azure, they are optional and are not required for each virtual machine (VM), but only used when exposing resources in a DMZ or leveraging Azure public facing services like Azure SQL Databases and Azure Storage. They are also configurable and can be associated with VMs, external load balancers, VPN Gateways and applications gateway (layer 7 load balancers).
At this layer it’s important to not allow each VM you create to have a public IP, and instead only allow your Internet-facing content to be exposed via public IP. Only allow the resources that are serving up your public-facing applications and content to have a public IP and then leverage the administrative gateways like VPN Gateways or ExpressRoute for your internal connectivity to Azure.
Virtual network isolation
When traffic reaches your virtual network, a greater share of the administration shifts to you. The Azure platform provides virtual network isolation that acts as a boundary between you and other Azure tenants and also your multiple virtual networks in Azure.
A virtual network or vNet is a private network for isolation of your cloud resources in Azure with full control over private IP space, DNS, security and routing. You can choose your IP scheme from a Class A, B, or C private IP block for your network.
You can further sub-divide that block by carving it up into subnets, grouping resources into multiple tiers of subnets, or keeping it relatively flat with a frontend DMZ and backend subnet.
By default, all resources within a virtual network are natively routable to each other by what are called System Routes. This is the case even from subnet to subnet which means no one has to spend time setting up route tables in the virtual network.
This only applies to the virtual network, unless vNet peering or ExpressRoute are enabled, in which case routing between vNets is possible provided there is no IP overlap.
The function of system routes is great for ease of setup, but that also makes it easy for nefarious elements to move laterally within your environment should they gain access. At a minimum, subnets within a vNet should be used to create a multi-tier topology with a front-end public-facing subnet net or DMZ with back-end services grouped logically based on their function or tier within the application.
Network security groups
With Azure, much like other cloud platforms, the traffic control function shifts from traditional stateful firewalls and network security appliances to a new construct called network security groups (NSGs). NSGs are a collection of rules or access control lists (ACLs) that allow or deny network traffic in a virtual network. NSG rules or ACLs are grouped together in an NSG and then applied to resources within Azure to allow or deny traffic.
The best practice is to apply NSGs to a subnet within your virtual network which would apply to all the virtual machines with that subnet. It is also possible to apply further restrictions to a specific VM by applying additional NSGs to the network interface card assigned to the VM.
Putting the pieces together
Moving to a cloud platform is not an easy undertaking and there are many considerations to take into account along the way. Going down this road alone is fraught with struggle and difficulty.
In order to maximize the value of the cloud and focus on where you can add the most value to your end customers, you’ll need a guide to help you on your journey. At Rackspace, you’ll not only get the guidance necessary to get the most out of Azure, you’ll have a partner that handles the infrastructure for you, allowing your focus to remain on your applications.
In part two of this series we’ll discuss how to mitigate the effects of a breach using external threat protection, network security, user defined routing and the expertise of a capable security partner.