By Jano van Deventer and Andrew Terranova
This is Part 3 of a 5 part blog series.
In the first part of this blog series, we covered an overview of zero trust architecture concepts. The main concept is that trust should never be assumed based on where a user is in a network. The concept of a user or device being trusted because it is inside is no longer assumed. Instead, every request to access a network resource must be authenticated and authorized. For more information, please read the Part 1 Introduction post.
This post will focus on an approach to zero trust known as Software Defined Perimeter (SDP). This model borrows concepts from virtualization technology, and other software defined architectures. A controller functions as a broker of trust between a client and a gateway. This can flexibly establish a Transport Layer Security (TLS) tunnel terminating on the gateway inside the network perimeter, allowing access to applications.
Software Defined Perimeter
An SDP has many concepts in common with Software Defined Networks (SDN) and Software Defined Data Centers (SDDC), and it should be considered as a complementing technology rather than a replacement technology. In practice, SDP works more like software defined tunnels and these tunnels are TLS VPNs connecting users and services. Each device establishes a unique VPN tunnel with the service that is requested, and the origin is cloaked from public view.
With SDP the data plane and the control plane are kept separate, with the main objective of verifying the identity of the user and the posture of the device via the control plane before the data plane tunnel is established. At the center of an SDP architecture is the controller that manages the flows between clients and servers, typically via an SDP gateway.
Software Defined Perimeter Architecture
SDP leans heavily on the concepts of Network Access Control (NAC) in an attempt to minimize the impact of existing and emerging network threats by adding authentication of the hosts. Similar to micro-segmentation, SDP enforces the principle of only providing access to the services that are required. Besides this authentication function the SDP Controller can enforce authorization policies that may include host type, malware checks, time of day access, and other parameters. The data plane will typically rely on an overlay network to connect hosts via VPN tunnels.
An SDP implementation usually requires use of client software on each device and hardware or software gateways and controller appliances. Gateways may be needed at each site where applications are located so deploying, managing, and maintaining this infrastructure can be challenging, especially in large globally distributed, high availability environments. In all, SDP is still an unterminated client-based VPN tunnel that adds identity verification, but does nothing for service insertion, application performance, or truly ‘SaaSify-ing’ enterprise applications. In addition, customer firewalls still need to be configured to accept inbound connections and allow traffic from the SDP gateways. Firewall rules introduce complexity, holes in the perimeter, and added IT maintenance.
As with most security architectures, there are plenty of choices and options available when designing a zero trust network; these options do not need to be mutually exclusive. A strategy around defense in depth along with a layered security approach are keys to architecting scalable and secure networks built around zero trust.
An overview of each of these three architectures will be instructive to any organization working to map out their security roadmap. In this post we described the SDP approach. The following link will take you to a post explaining two other architectures.
*** This is a Security Bloggers Network syndicated blog from The Akamai Blog authored by Andrew Terranova. Read the original post at: http://feedproxy.google.com/~r/TheAkamaiBlog/~3/n7sgMKJQY40/zero-trust-security-architectures---software-defined-perimeter.html