Blog Zscaler

Ricevi gli ultimi aggiornamenti dal blog di Zscaler nella tua casella di posta

Best Practices

How SASE Vendors Design Their Solution - Part 1: The Pillars of SASE Architecture

JULIAN WEINBERGER, JOE ARRA
novembre 09, 2026 - 5 Min. di lettura
>How SASE Vendors Design Their Solution - Part 1: The Pillars of SASE Architecture

The Foundation of a Modern Security Cloud: True Multi-tenancy

The promise of the Secure Access Service Edge (SASE) is to deliver a converged, high-performance security and networking stack from the cloud. The architectural decisions made by a vendor are the most critical factor in delivering on this promise. At the core of a purpose-built SASE platform lies a multi-tenant cloud architecture. This isn't simply about hosting virtual machines in the cloud; it's about building a service from the ground up where a single, unified software stack serves all tenants simultaneously.

This design is inherently efficient. Resources are shared, updates are seamless across the entire platform, and the service can scale dynamically to meet demand without the need to spin up dedicated virtual appliances for each customer or for each discrete security function. The real magic, however, happens in the data plane.

The Good: Single-Scan Multi-Action (SSMA) Engines

The most elegant and efficient SASE designs employ a Single-Scan Multi-Action (SSMA) engine. Imagine your data packets flowing into the security cloud. With SSMA, that stream of data is inspected in memory, in a single pass. As that single inspection occurs, the engine can apply all security policies at once: Secure Web Gateway (SWG), Cloud Access Security Broker (CASB), Data Loss Prevention (DLP), and threat prevention.

This single-pass approach is the architectural lynchpin for performance. Because the data is not written to disk or duplicated for different security services, latency is minimized. The processing overhead is drastically reduced, allowing the platform to handle enormous volumes of traffic, even with full SSL/TLS decryption enabled, without a noticeable impact on user experience. This is the "good" design—an integrated, high-throughput data plane built for the scale of the modern enterprise.

The Bad and The Ugly: Service Chaining and Virtual Appliance Overhead

Not all SASE solutions are created equal. Many legacy SASE providers, often evolving from disparate product lines, have resorted to "stitching" together their services in the cloud. This approach, known as service chaining, is the architectural opposite of SSMA.

In this model, each security function—firewall, DLP, sandboxing—runs as a separate virtual machine (VM) or container. To apply a full security stack, a user's traffic must be passed sequentially from one virtual appliance to the next. Some vendors even use outdated protocols like the Internet Content Adaptation Protocol (ICAP) to redirect traffic between services.

This design is fundamentally inefficient and creates a host of problems:

  • Increased Latency: Each "hop" between virtual appliances adds latency. Packets are often duplicated, decrypted, and re-encrypted multiple times, compounding the performance penalty.
  • Operational Complexity: Managing a chain of virtual appliances is complex. Each component has its own resource limits, potential points of failure, and management overhead. Scaling the solution requires scaling each individual VM, leading to a clumsy and inefficient use of cloud resources.
  • Throughput Bottlenecks: The overall throughput of the system is limited by the slowest link in the service chain. Full SSL decryption, a computationally expensive task, becomes a significant bottleneck when it has to be performed by multiple, separate engines.

This stitched-together approach is the "ugly" secret of many first-generation cloud security vendors. It’s a relic of the on-premises world, ported to the cloud without a fundamental redesign.

Architectural Trade-offs at a Glance

The choice between these two architectures represents a critical trade-off. While service chaining may have allowed vendors to get to market quickly by repurposing existing products, it sacrifices the performance, scalability, and operational simplicity that are the hallmarks of a true SASE platform.

Capability

True SASE (SSMA)

Stitched SASE (Service Chaining)

Inspection Model

Single-pass, inline memory inspection

Multi-pass, sequential VM/container hops

Performance

Minimal latency; high throughput

High latency due to packet copies and multiple hops

Scalability

Elastic and efficient; scales as a unified service

Clunky and inefficient; scales per virtual appliance

Operational Overhead

Low; single policy engine and unified management

High; managing and troubleshooting a chain of services

SSL/TLS Decryption

Decrypt-once, inspect-many

Multiple decryption/re-encryption cycles

Ultimately, the architectural foundation of a SASE vendor's solution dictates its ability to deliver security without compromise. A true SASE architecture is purpose-built for the cloud, while a stitched one is merely cloud-hosted.

FAQs

The best SASE platforms use a multi-tenant cloud with a single-pass inspection engine. A single-pass engine decrypts traffic once and applies all security policies (SWG, CASB, DLP, and threat prevention) in memory in one pass. Service-chained designs pass traffic through a separate virtual appliance for each function. That adds latency, multiplies decryption work, and makes scaling harder.

True multi-tenancy is critical because it allows a single, unified software stack to serve all tenants simultaneously from the ground up, rather than simply hosting isolated virtual machines in the cloud. This native cloud design ensures seamless updates, dynamic scaling, and optimal resource efficiency without the need to spin up separate virtual appliances for every customer or discrete security feature.

Service chaining severely degrades performance by introducing cumulative latency and throughput bottlenecks. Because traffic must jump sequentially from one virtual appliance to another, packets are frequently duplicated, decrypted, and re-encrypted multiple times. Furthermore, the overall speed of the network is restricted by the slowest virtual appliance in the chain, making computationally heavy tasks like SSL/TLS decryption a major bottleneck.

In legacy SASE designs, the Internet Content Adaptation Protocol (ICAP) is used to redirect data traffic between disconnected security services running on separate virtual machines. This represents an inefficient, "stitched-together" architecture that relies on outdated on-premises protocols to connect separate security functions (like sandboxing or DLP) rather than processing them inline.

A decrypt-once, inspect-many model (used in SSMA) is superior because it performs the computationally heavy task of SSL/TLS decryption only once. Once decrypted in memory, all security engines inspect the traffic simultaneously. Legacy service chaining requires multiple decryption and re-encryption cycles as traffic moves through different virtual appliances, which heavily penalizes hardware performance and ruins the user experience.

form submtited
Grazie per aver letto

Questo post è stato utile?

Esclusione di responsabilità: questo articolo del blog è stato creato da Zscaler esclusivamente a scopo informativo ed è fornito "così com'è", senza alcuna garanzia circa l'accuratezza, la completezza o l'affidabilità dei contenuti. Zscaler declina ogni responsabilità per eventuali errori o omissioni, così come per le eventuali azioni intraprese sulla base delle informazioni fornite. Eventuali link a siti web o risorse di terze parti sono offerti unicamente per praticità, e Zscaler non è responsabile del relativo contenuto, né delle pratiche adottate. Tutti i contenuti sono soggetti a modifiche senza preavviso. Accedendo a questo blog, l'utente accetta le presenti condizioni e riconosce di essere l'unico responsabile della verifica e dell'uso delle informazioni secondo quanto appropriato per rispondere alle proprie esigenze.

Ricevi gli ultimi aggiornamenti dal blog di Zscaler nella tua casella di posta

Inviando il modulo, si accetta la nostra Informativa sulla privacy.