What is a Corporate VPN?

Corporate virtual private networks (VPNs) evolved in a centralized business environment that no longer exists. Today’s corporate network is much more dynamic and access must be managed across employees, contractors, and third-parties. As a result, VPN-based network security practices have become more brittle and difficult to manage.

The efficiency of DevOps teams suffers in the face of the constraints VPN systems impose. But there is a way to keep IT resources secure while efficiently managing access permissions. Frameworks based on zero-trust security practices provide DevOps teams frictionless control over resource access.

Understanding Corporate VPNs

Before the internet, companies connected remote facilities with central computing resources by leasing dedicated lines from telecommunications companies. This approach to building wide-area networks (WANs) was too expensive for many businesses — and all but impossible for internal teams.

The public internet provided a more affordable WAN alternative that VPN technology kept secure. At the same time, VPNs let employees in the field access the company’s internal IT resources remotely without compromising the central network’s security perimeter.

Limitations of VPNs

When VPNs first emerged, IT departments developed their security strategies on a castle-and-moat framework. All resources resided on-premises and were deployed to a privileged network around which a secure perimeter was built. 

Corporate VPNs provided a protected gateway through that perimeter. The VPN gateway used end-user credentials from the VPN client for authentication and granted access to the network. Encryption and encapsulation of the data passing between the network and the client kept the data secure.

Unfortunately, the castle-and-moat framework only works best when all resources reside on a privileged network and access can be limited to trusted people and devices.

That clear distinction between inside and outside, trusted and not trusted, no longer exists. Third-party X-as-a-service providers account for a growing share of corporate IT resources. Even when a company owns its resources, the applications may be running on third-party cloud platforms. And access permissions must be managed across a population of employees, contractors, and outside partners who use a mix of managed and personal devices.

Security Issues with Corporate VPNs

The castle-and-moat framework underpinning corporate VPN systems also contains an inherent security weakness. The framework assumes that everything inside the secure perimeter is safe. As a result, any authenticated VPN connection has full access to a company’s network.

Treating incoming connections this way made sense in VPN’s original context — connecting privileged networks into a WAN. Unfortunately, this approach also lets a compromised client device, or user, take advantage of the “secure” VPN connection.

The VPN gateways also represent security risks as they require public IP addresses and advertise the VPN vendor’s name. Relatively simple tools let cybercriminals use this information to penetrate network security systems.

IT departments can mitigate these risks by segmenting the network, installing unique VPN gateways to each segment, and adding other layers of security. Yet adding more complexity makes network management more difficult and brittle than it already is.

Alternatives to Corporate VPNs

There are alternatives to traditional corporate VPNs. However, they can be costly and require significant effort to put into place.

Multi-Protocol Label Switching (MPLS) services provide secure site-to-site network connections and remote access without relying on the internet. Instead, the data flow through the internal networks of telecommunications companies like AT&T and Verizon. But just like the last century’s leased-line connections, MPLS services are too expensive for most small and medium-sized organizations.

Software-Defined Wide Area Networks (SD-WAN) virtualize the control and management of a WAN. They are cheaper and faster to deploy than MPLS systems and offer better performance than pure internet connections. However, SD-WANs are not private networks. While they can integrate MPLS, LTE and other services, they typically rely on the internet to transport data. And SD-WAN lacks the end-to-end security controls today’s IT environment demands.

Google’s BeyondCorp Removes Trust

In 2014, Google introduced a new framework for corporate network security. The company had been a target five years earlier of the Operation Aurora cyberattacks. In its aftermath, Google’s security team realized that the castle-and-moat framework could not counter sophisticated, state-sponsored threats to their networks.

Google’s solution, dubbed BeyondCorp, does away with the trusted network and its brittle defenses. BeyondCorp is a zero-trust framework that assumes no network, user, or device is safe. Access to resources requires the authentication of both users and devices. And that authentication is ephemeral — devices and users must re-authenticate every session. Google is so confident in its approach that it eliminated privileged networks and deployed its resources on the public internet.

Zero Trust’s Challenges

Strengthening enterprise security while providing easier remote access, better end-user experiences, and less complex network management. The zero-trust framework’s promise has wide appeal across the IT community. Of course, most businesses do not have Google’s resources or internet-native DNA. 

Implementing a zero-trust framework at Google has taken years and impacted the entire business. Access proxies had to be developed to migrate applications from the privileged network to the internet. Authentication required an access control engine that dynamically assigned levels of trust to devices and users. Workflows, infrastructure, legacy systems, and fat-client applications had to be brought into compliance with the new framework.

Despite Google’s web-centric business and wealth of resources, the company could only say that the migration was “well underway” a full five years after the Operation Aurora cyberattacks. BeyondCorp is an enterprise-wide transformation effort that requires strong, sustained C-level commitment and support throughout the company for a decade.

Access Remote Developer Resources with Twingate

DevOps teams, however, need the zero-trust framework’s benefits now. Employees and contractors constantly move between projects. People join the team, leave the team, and require changing roles and permissions. Managing these dynamic teams within the context of VPN-based security negatively impacts efficiency.

Twingate offers a faster, frictionless way for DevOps teams to securely manage remote access. At the heart of Twingate’s solution is a form of zero-trust called the software-defined perimeter (SDP). Like BeyondCorp, SDP uses device-based and user-based authentication to control access to each resource. But Twingate’s SDP approach operates on a need-to-know basis. Company resources are only visible to the devices and users with access permissions. 

Both administrators and end-users get a frictionless experience. No hardware or software changes are needed on the network. Fine-grained controls and one-click permission management enables easy onboarding, offboarding, and crossboarding. And the consumer-like client gets end-users set up quickly.Twingate eliminates the inefficiencies and security weaknesses of corporate VPNs while letting DevOps teams provide end-users targeted, secure access to developer resources. Learn more about Twingate’s SDP-based network security solution.