Robust Resilient Architecture: The Game-Changer for Software-Defined Perimeter Specifications

In the past, we have written about the evolving software-defined perimeter (SDP) specification from the Cloud Security Alliance (CSA) as an effective way to implement the principles of Zero Trust security. And we have explained that by using a  software-defined perimeter architecture—like that found in Appgate SDP, our industry-leading Zero Trust Network Access (ZTNA) solution—you can turn the internet into a safer solution for your organization’s network. 

The core elements of SDP architecture as defined by the CSA are:

1. The Controller (the policy decision point);
2. An Initiating Host (the user/device) that authenticates to the Controller and subsequently is allowed access to authorized services via;
3. An Accepting Host/Gateway (policy enforcement point)

Trusted tokens are a fourth-dimension game changer

The CSA specification covers trusted communications between SDP system elements, but not how they should be used. Indeed, there is an underlying assumption that the Gateways which control access to organizational resources will take their instruction directly from the Controllers over a trusted communications path to facilitate and enforce access control decisions.

This is where Appgate SDP differs from most software-defined perimeter implementations ... by adding a fourth dimension to the model, namely the use of trusted tokens. Think of this as being akin to the dimension of time in the space-time model.

Tokens are a game changer when considering how to build a Robust Resilient Architecture.

Appgate SDP uses two types of tokens: 1) claims tokens represent the result of a successful (user) authentication; and 2) entitlement tokens represent the resulting access authorization granted to that user. Both are produced whenever a new user session is successfully initiated. These signed and encrypted tokens are then passed to the user’s device, not the Gateway. The device then forwards these to the Gateway(s).

One of the key things that the CSA SDP specification is very clear about is that decisions and enforcement should be handled by separate elements in the system. This is, in part, what makes the software-defined perimeter such a compelling proposition for the modern age. This use of tokens allows for the operation of the system to also be handled by a separate element ... the Client on the user’s device.

Controllers are REST API-based and just a token-issuing service as far as the Clients are concerned. The Controller can be stateless because all the information needed by the Gateways is locked away in the two tokens. Once the tokens are issued the connection is dropped and an audit log is the only record that remains. Tokens are continuously re-evaluated for changes in context or risk.

Client devices now have complete operational independence as they need no further reference to the Controller unless there is a change in context or risk. They make their own connectivity decisions, perform load balancing across multiple Gateways and are free to fail-over to an alternative Gateway at any time. This also removes any requirements for Gateways to communicate between themselves making it possible to autoscale groups easily.

Gateways have all the information they require to setup and manage the user's access rules included in the tokens. This means they also need no further reference to the Controller when setting up a new session. Indeed, it is easy to show that a Client can sign in to a Controller while all the Gateways are shut down, and then you could shut down the Controller so the only live element left are tokens on the Client device. When a Gateway appears later, the Client sees this, passes its tokens (as long as they have not expired) and is immediately granted access. 

Going back to the space-time model analogy, the Client now has the freedom to choose how and when to perform its operations. This new operational dimension makes it possible to enjoy the benefits of the software-defined perimeter but framed within a truly robust resilient architecture. This is an implementation that all but eliminates the need for a real-time, always-on infrastructure.

The eight building blocks that underpin Appgate SDP

Appgate SDP is based on number of key security principles and operating concepts that, in turn, follow CSA’s SDP approach. The result is a powerful but immensely flexible solution that can be configured to meet your exact security and compliance requirements regardless of network topology. And advanced  automation and orchestration  tools can be deployed to further streamline administration. The eight key concepts that underpin Appgate SDP’s system design are:

• Zero Trust-based
• Robust resilient architecture
• Rapid implementation
• Individual policy controls
• Dynamic least privilege access model
• Easy deployment and use
• Decentralized access
• Performant at scale

Want to learn more? Register for a live Appgate SDP demo.

Additional Zero Trust Network Access resources

Blog: Operational and business benefits of Appgate’s Zero Trust platform
Webinar: Zero Trust Maturity and the Role of ZTNA ft. guest David Holmes of Forrester
Datasheet: Appgate SDP overview
Video: Kill the NAC: Zero Trust Network Access for the Corporate Network