What is the Best Azure VPN?

DevOps teams have come to rely on Microsoft Azure’s strength in hybrid cloud computing. While you can find many VPN solutions for securing access to Azure-hosted resources, traditional VPN technology makes DevOps less efficient. In the end, abandoning VPN’s trust-based framework for a zero-trust framework is the best way to secure access to resources on Azure.

What is Azure VPN Gateway?

Microsoft’s decades-long history in the enterprise software space isn’t the only reason companies choose Microsoft Azure’s cloud services. Security is designed into the entire Azure infrastructure from the custom hardware in its data centers to the 3,500-strong team of cybersecurity experts monitoring the system round-the-clock. 

However, Microsoft Azure’s responsibility for security has its limits. Access control, for example, is not something Azure can do on its own. It is up to each customer to decide who has access to which resources — and what systems to use to control that access.

For a price, you could choose Microsoft’s own VPN Gateway service to connect an Azure virtual network to your corporate network. VPN Gateway also supports remote access across the public internet. However, setting up Azure’s VPN Gateway is not a simple plug-and-play process. Assuming your network’s existing VPN infrastructure is compatible, integrating it with Azure’s solution can require additional configuration work.

Alternative VPNs for Azure Cloud Security

You will find several alternatives to VPN Gateway in Azure’s Marketplace. Microsoft works with each vendor to ensure that their software works with Azure and deploys easily. Customers also get the benefit of unified billing within their Azure accounts. 

Enterprise-class solutions like Citrix’s Application Delivery Controller offer VPN capability as part of a larger suite of security services. These options can be overkill for simpler remote access needs — especially if your organization does not use Citrix products throughout its network infrastructure.

At the other end of the scale are more narrowly-focused solutions like Netgate’s pfSense and OpenVPN’s Access Server. The proprietary versions of long-established open-source projects, these solutions offer business-friendly features and support levels at affordable prices. However, because these solutions depend on the underlying open-source projects they are not always able to provide the streamlined user experience and manageability of more polished commercial applications.

Are VPNs the Right Approach Anymore?

Whether a VPN solution is developed by an enterprise provider or by open-source contributors, it is based on a mid-1990s framework designed for a very different business network. Back in the day, IT resources resided on-premises and connected to a proprietary network. Only company employees, most of whom worked on-site, could access that network. 

IT departments focused their efforts on protecting the network’s perimeter. For the handful of people working remotely, VPN gateways provided secure, encrypted tunnels through the secure perimeter. Once inside, these trusted employees had full access to the network.

In today’s IT environment, there is no clearly-defined perimeter. Some resources are managed centrally, while others are hosted on cloud services like Azure. And X-as-a-Service resources are not managed by the IT department at all.

The workforce accessing those resources is no longer limited to company employees using managed devices. Access also must be managed across a dynamic population of contractors, third-party partners, and BYOD smartphones or laptops.

VPN technology’s underlying assumptions of the secure perimeter and trusted users are not compatible with today’s environment. Efforts to address the weakness of VPN, such as creating subnets and deploying multiple VPN gateways, leads to more brittle security policies that are not responsive to today’s business needs.

Zero Trust for Secure Azure

Zero trust is a security concept that avoids the pitfalls of VPN technology. Rather than protecting a secure perimeter around a trusted network, zero trust assumes that nothing can be trusted. Not the users, not their devices, not even the network itself.

Google was the first company to adopt zero trust in response to state-sponsored cyberattacks in 2009. This BeyondCorp initiative recognized that the perimeter can never be secure. Over a decade, Google refocused its security efforts on each individual resource. 

Any user requesting access must be authenticated and approved on a session by session basis. It does not matter whether the user is an employee or a contractor, whether they use a managed device or their smartphone, or whether their device is on a company network or the public internet. In fact, Google has taken zero trust so far that all of its resources connect directly to the public internet and are discoverable over DNS.

Twingate’s Zero Trust Security

Twingate’s implementation of zero trust takes security one step further by operating resources on a need-to-know basis. This is an approach to security, first developed by the US Department of Defense, called the software-defined perimeter (SDP). 

All resources, whether on the internet or a private network, are hidden by default. By limiting access to these “black” resources to users and devices that comply with access control policies, the threat surface is dramatically reduced.

A Twingate SDP deployment consists of three elements: a Client running on the user’s device, an Access Node deployed between a resource and its network, and a Controller. The Client software has no in-built knowledge of the company’s IT resources other than the location of the Controller. When the Client sends a connection request, the Controller works with the company’s existing security stack to authenticate and approve the request. Only when the Controller hands the client over to the Access Node will the Client receive a secure, encrypted tunnel to the resource. Each session is ephemeral and the Client must go through the authentication and approval process all over again to reconnect with the Access Node.

Securing DevOps Resources on Azure with Twingate

Twingate’s approach to secure access is specifically designed to help DevOps teams eliminate the headaches imposed by VPN technology. The Twingate Controller decides which resources the Client may access which means end-users do not have to juggle multiple VPN clients. In addition, the end-users self-provision their Client through a consumer-like experience that does not require changes to their device’s settings.

The experience for DevOps admins is also a lot easier. They can deploy an Access Node to a resource with a single-line Docker command. The resource, whether on a corporate server or an Azure virtual network, does not need to be reconfigured. Twingate integrates with your existing security stack so there is no need to maintain parallel policies. And managing the constant personnel changes becomes much easier with one-click onboarding and offboarding.

Find out more about how Twingate makes DevOps more efficient by contacting us.