Miscellaneous 4 min. read

SDP Vs. VPN: Which is Best for DevOps Security?

SDP Vs. VPN: Which is Best for DevOps Security?

Software-defined perimeters offer a better approach to security than VPN and other legacy security technologies. In the challenging, dynamic information environments of modern DevOps, the benefits of SDP vs. VPN are very real. Here is how a low-impact, quickly-deployable software-defined perimeter can remove constraints on DevOps productivity.

Introducing Software-Defined Perimeters

The software-defined perimeter (SDP) is a 21st Century approach to information security designed for today’s dynamic, heterogeneous, and amorphous information environment. SDP focuses on protecting business resources individually, rather than protecting the networks where resources are deployed.

Resource protection is provided by interrogating the identity of every user and device that requests access to that resource. Using a “zero trust” approach to access control, the SDP does not distinguish between on-site users and remote users, between employees and contractors, or between managed devices and user-owned devices. An SDP system only grants access to a resource if both the user and device can be authenticated and found in compliance with access control policies for that resource.

Since an SDP is network-agnostic, its protection is not limited to resources deployed to a company’s on-site network. Access to resources hosted on virtual clouds or third-party X-as-a-Service providers can be managed under the company’s existing control policies.

VPN’s Brittle Perimeters

SDP’s identity-centric approach to information security is a marked change from traditional practices. In the past, a company’s security efforts focused on protecting the on-site network, and everything attached to it, from outside threats. Implicit in this approach was the assumption that people, devices, and resources connected to the internal network could be trusted. Like a moat surrounding a castle, the firewall protected the network from untrusted outsiders and kept resources invisible.

However, the castle-and-moat approach made it difficult to affordably link field offices and other sites to the central network. The VPN affordably solved this problem by creating an encrypted, virtual private network over the internet.

Site-to-site VPN technology was also repurposed as a remote access solution. This is where the technology saw its most visible adoption — and where the technology creates the most problems. Since VPN was created as a network-to-network solution, a VPN gateway gives every connection full access to the network it protects. As a result, a compromised device — or a compromised user — can give cybercriminals unrestricted access to everything on the network.

Mitigating these VPN-generated security risks requires layers of additional network infrastructure and security policies. For example, dedicated subnets with their own VPN gateways can be created for specific teams and the resources they use. However, the security improvements come at the expense of manageability. Security policies and network infrastructure become more difficult to change and this brittleness undermines business productivity.

VPN technology makes businesses less efficient in other ways. As the VPN gateway combines both the control plane and the data plane in a single service, it becomes a bottleneck for network traffic. The data passing between a user and a resource gets backhauled through the VPN gateway regardless of the geometry of the network path. Administrators must balance the costs of scaling to that volume against the business impact of high-latency bandwidth.

High-latency, brittle connections are not the only ways end-user productivity suffers from VPN’s limitations. When resources are deployed to separate subnets, the end-user must switch between VPN gateways within the client app — or even switch between different VPN clients.

SDP vs. VPN: What are the Differences?

SDP is a much more flexible way to manage security and remote access than the traditional combination of a secure perimeter and a VPN. 

Where VPN’s focus on providing access to networks creates a vector for security breaches, SDP’s focus on denying access to each resource makes attacks harder to execute. Even if successful, the security breach would only give attackers access to a specific resource with no path to other resources.

Another security weakness of VPN technology is its visibility. A VPN gateway must advertise its presence on the public internet and is discoverable using simple DNS-lookup tools. SDP security, on the other hand, hides resources whether they are deployed to an on-premises network or in the cloud.

SDP security also removes much of the management overhead imposed by the traditional castle-and-moat security framework. Since SDP is network-agnostic, administrators do not need to create complex subnet structures.  And the secure connections between resources and end-users can take the most direct path rather than getting backhauled through a VPN gateway.

SDP for DevOps

DevOps teams get the earliest benefit when companies migrate to a software-defined perimeter security system. Contractors and employees change roles and move from project to project, requiring changes to their access permissions. DevOps teams also manage a resource landscape that crosses in-house networks, cloud hosting services, and third-party X-as-a-Service providers. The brittleness of traditional security frameworks makes DevOps teams less productive and erodes security due to work-around practices like over-permissioning.

Unfortunately, past approaches to SDP are enterprise-scale business transformations. Google, for example, pioneered the commercial adoption of many SDP practices. Its BeyondCorp initiative migrated the entire company from securing network perimeters to securing resources with zero trust solutions. But it took C-level executive commitment and a decade of work to rearchitect Google’s infrastructure and change workforce processes.

Twingate for DevOps

Twingate offers a less intrusive path to SDP security. Deploying an SDP Access Node to a resource is as simple as entering a single Docker command. The SDP Controller integrates with your existing security stack so you can leverage existing identity and access control policies. End-users follow a consumer-like journey to self-provision the SDP Client to their device.

Because Twingate supports all TCP and UDP traffic, you do not need to change resource settings or network configurations. You can also deploy Twingate’s Access Nodes to any resource whether you host it on-site, in the cloud, or source it from a third party. At the same time, the applications your developers use will just work without any changes needed to the operating system.

Your developers’ productivity will not be impacted by high-latency VPN gateways. Once users and their devices are authenticated by the Controller, all data passes directly between the Client and the Access Node through encrypted tunnels. And the developers’ experience becomes much simpler. Rather than choosing between VPN client/gateway combinations to access resources, users simply launch the Twingate Client. The Controller and Access Nodes handle the rest.

Contact Twingate to learn more about how your DevOps team can get software-defined perimeter security up-and-running.

Get the latest stories and tips from Hotspot Shield in your inbox