Cloud 101CircleEventsBlog
Get 50% off the Cloud Infrastructure Security training bundle with code 'unlock50advantage'

6 SDP Deployment Models to Achieve Zero Trust

Published 04/16/2022

6 SDP Deployment Models to Achieve Zero Trust

Written by the SDP and Zero Trust Working Group

With Software Defined Perimeter (SDP), enterprises can move away from traditional (and largely ineffective) perimeter-centric models, achieving the goals of Zero Trust and therefore improving their security effectiveness and resiliency. SDPs replace physical appliances with logical components that operate under the organization’s control, regardless of where they are physically deployed, thereby minimizing the logical perimeter.

SDP aims to give enterprise security architects, network providers, and application owners the ability to:

  • Deploy dynamic “software-defined” perimeters
  • Hide networks and resources
  • Prevent unauthorized access to the services running on them
  • Enforce an identity-centric access policy model

Blog Summary: In this blog we will explain six SDP deployment models outlined in the Software-Defined Perimeter (SDP) Specification v2.0. This blog is intended for solution architects and security leaders that are deploying Zero Trust and SDP products in their enterprises.

Deployment Models Explained

SDP connects clients (humans or non-person entities) to resources depicted as servers in the diagrams that follow. These resources may be of any type, as long as they are addressable across a network. They may be services running on physical or virtual servers, services running on IaaS or PaaS platforms, or containerized services.

This section briefly introduces the six SDP deployment models. While they use different network topologies, they logically provide the same benefit of enforcing access to protected resources. For a complete introduction to these deployment models, see the SDP Architecture Guide.

Note that in the diagrams below, the blue lines indicate network connections secured by mutually authenticated cryptography protocols, such as mTLS or Internet Key Exchange (IKE), that provide countermeasures to MITM attacks. The gray lines indicate the network connections utilizing the native application protocol, which may or may not be encrypted. The diagrams omit the SDP Controller for simplicity.

Several of the deployment models use SDP Gateways. An SDP Gateway is a software agent that acts as an SDP Accepting Host, and provides isolation and access controls for the protected services.

#1 Client-to-Gateway Model

When one or more servers must be protected behind an SDP Gateway, the connections between the IH and the AH (Gateway) are secured regardless of underlying network topology. In the Client-to-Gateway model, the Gateway is remotely accessible but hidden, and provides a secure perimeter. This model does not require any changes to protected servers.

#2 Client-to-Server Model

When an organization needs to secure communications end-to-end, the Client-to-Server model combines the service and the AH in a single host. In this model, the server is hidden within the secure perimeter and the server must have SDP software to act as an AH.

#3 Server-to-Server Model

The Server-to-Server model ensures that all connections between servers are encrypted regardless of the underlying network. In this model, all servers are hidden within the secure perimeter.

#4 Client-to-Server-to-Client Model

In some instances, peer-to-peer traffic passes through an intermediary server, such as with VOIP, chat, and video conferencing services. In the Client-to-Server-to-Client model, the server is hidden within the secure perimeter.

#5 Client-to-Gateway-to-Client Model

The Client-to-Gateway-to-Client model is a variation of Client-to-Server-to-Client. This model supports peer-to-peer network protocols that require clients to connect directly to one another while enforcing access policies. In this model, the gateway is hidden within the perimeter.

#6 Gateway-to-Gateway Model

The Gateway-to-Gateway model was not included in the SDP Specification 1.0. This model is well-suited for certain IoT environments. In this model, the gateways are hidden within the perimeter.

Learn More

This blog is based on the Software-Defined Perimeter (SDP) Specification v2.0, which encompasses the architectural components, interactions, and basic security communications protocol for SDP. It focuses on the control plane that enables secure connectivity within the security perimeter, and the data plane that enforces secure connectivity between initiating hosts and accepting hosts, be they servers, devices, or services.

Dedication

The paper this blog is based on was dedicated to the memory of Juanita Koilpillai, a security leader, influencer, mentor, and friend. Juanita was a luminary in her field and broke many glass ceilings on her path to becoming founder and chief executive at two successful start-ups. In return, Juanita shared her knowledge by mentoring young women with careers in technology. She played a prominent mentorship role in IEEE’s Women In Engineering (IEEE WIE) Organization. She also created a philanthropic fund in memory of her father and founded MERGE, a non-profit to support local youth projects. She was instrumental in the authorship of the Software-Defined Perimeter (SDP) Specification v2.0 as well as several other CSA, IEEE and NIST publications.

Share this content on your favorite social network today!