Voltar 
In the past, there was a clear demarcation between the role of the enterprise network and the internet. Network architects focused on the networks that were under their direct control, and relied on their service provider to provide access to the internet.
With the rise of cloud applications, we’re seeing a shift in the demarcation. That’s because network architects have key business applications that are hosted in the cloud, and now they have to think about network performance in a different light, with access to the applications following traffic paths that are mostly outside of their network’s boundaries. Additionally, each application also has unique requirements around network performance that must be considered. For example, webinar (one-to-many) streaming needs high bandwidth, real-time collaboration needs low latency, and backend systems hosted in virtual private clouds may have very high resilience and redundancy requirements. Further complicating matters, unlike private applications, cloud applications don’t have a predictable set of IP addresses and ports, and are constantly changing and evolving, making them a nebulous and ever-changing target. Perhaps the term “cloud” is even more apropos than we realized!
Security, of course, is a critical enabler of applications, and that’s why the Secure Access Service Edge (SASE) has now emerged as an important conceptual model for describing how to protect users and applications that operate beyond the traditional network perimeter. SASE is a model that recognizes that the location of the user and the application can no longer be thought of as fixed. In other words, the traditional castle-and-moat approach to application and network security doesn’t protect people who aren’t in the castle.
Netskope’s platform engineering team is responsible for designing and operating NewEdge, the private security cloud on which the Netskope Cloud Security Platform runs. There’s a tremendous amount of interest from customers wanting to know how to support and secure their complex mix of applications, managed (IT-led), unmanaged (Shadow IT), on-prem, private apps in the cloud, third-party SaaS, and more. In many conversations about SASE, I find it very helpful to draw upon my decade of experience in the CDN space to walk through the elements that factor into the path that end-user traffic takes under various scenarios. This is because SASE is a new topic for everyone. The architecture of carrier networks, cloud providers, CDNs, and the internet is not necessarily widely understood, and sometimes the language for many concepts is not standardized across the industry.
Take the term “data center,” for example. In my world, a data center meant a physical building with concrete walls, raised floors, and carefully monitored environment controls. I’ve always presumed that if you told me that you have two data centers, you own two such buildings, like the famous NAP of the Americas in Miami, Florida (congratulations!). Today, only colocation facilities, telcos, a handful of managed service providers, and a very small number of enterprises own and build their own “data centers.” In fact, many colocation providers don’t own the building, they just lease space within a larger data center. In contrast, a point of presence (POP) is a location where you have placed servers, but don’t own or operate the data center. Yet in the security space, you will often see “POPs” referred to as data centers, which can sometimes cause confusion.
Semantics aside, I now recognize that the definition of data center is changing, and that the easiest way to facilitate a discussion about points of presence is to use the language that is the most widely understood in the security space. In this article and in the future, I’ll use “data center” to refer to any location where servers or network equipment is present.
As an architect, I love discussions with our customers about end-to-end latency and how to ensure a great user experience. This is easy to do with a big empty white board and fresh box of dry erase pens. It’s a bit harder to have the same discussion in writing, when we need to first check if we are using terms in the same way. This is why I felt that it is prudent to explain the “path of the packet” in this blog.
In the Secure Access Service Edge (SASE) model for delivering cloud-based security services, the “packet” flows through several logical components and boundaries, and it’s useful to provide them with names in order to clarify what’s what.
First Mile
Generally speaking, users could be in a number of different locations. They might be located at the office or at home, and they need to use a cloud-based application. In the first mile, the user’s request to access an application traverses a local area network to the network’s edge.
For users working from home, the user and the network edge are in the same building. On enterprise networks, there are generally far fewer network edges than offices or campuses. While SASE is an enabler of “local internet breakout,” most organizations still concentrate their network edges to one or a few locations.
Given that the user’s location is indeterminate, and the quality of the security at the network edge is questionable or nonexistent, then the protection at the perimeter is also indeterminate at best. If you don’t know if the user’s going to be behind a corporate firewall, then you can’t expect that firewall to deliver visibility or protection. The SASE model addresses this point, by delivering consistent visibility and enforcement of security policy in the middle mile, rather than relying on security measures that may or may not exist in the first mile.
Middle Mile
Secure Access Service Edge isn’t a “destination,” but rather the delivery of networking and security services for traffic en route to the internet, cloud applications, or the data center. When users access applications, the packet has an entry (the SASE edge) and an exit (the SASE egress) point, with the processing of policy in the compute happening at some point in between. Keep in mind, this is a logical model for the purposes of discussion, but with the variety of architectures in the market, it should be noted that there are implementations with edge/compute/egress all in the same data center, and others where either egress or edge is decoupled, but the other two are in the same data center, and some where each function takes pl