Blog Zscaler
Recevez les dernières mises à jour du blog de Zscaler dans votre boîte de réception
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.
Cet article a-t-il été utile ?
Clause de non-responsabilité : Cet article de blog a été créé par Zscaler à des fins d’information uniquement et est fourni « en l’état » sans aucune garantie d’exactitude, d’exhaustivité ou de fiabilité. Zscaler n’assume aucune responsabilité pour toute erreur ou omission ou pour toute action prise sur la base des informations fournies. Tous les sites Web ou ressources de tiers liés à cet article de blog sont fournis pour des raisons de commodité uniquement, et Zscaler n’est pas responsable de leur contenu ni de leurs pratiques. Tout le contenu peut être modifié sans préavis. En accédant à ce blog, vous acceptez ces conditions et reconnaissez qu’il est de votre responsabilité de vérifier et d’utiliser les informations en fonction de vos besoins.
Recevez les dernières mises à jour du blog de Zscaler dans votre boîte de réception
En envoyant le formulaire, vous acceptez notre politique de confidentialité.


