-
Notifications
You must be signed in to change notification settings - Fork 31
1. Why, what and how ZTM
Before describing the original design intent, let's first talk about what we understand to be the “problem” of the network. We believe that the core problem of the network is in the following two areas:
- Security. Network security is becoming an increasingly important topic and a “headache” in the information field. If the goal of “network security” is to have a “secure network”, then the TCP/IP network we use today is fundamentally contrary to this goal. The core goal of the networks we use today is “connectivity”, not “security”. Network security issues have arisen as the scale of usage has grown and the number of users has exceeded expectations. As the core foundation, the current network identity is based on IP, access control is also based on IP + Port, although with the development of more application-layer identity (e.g., JWT) and access control mechanisms, but this has not changed the underlying layer of IP-based identity and IP + Port-based control system; at the same time, the application layer of the new mechanisms, which further increase the complexity of the network.
- Complexity. The networks we currently use have exploded in size and usage over the last few decades. So today's networks, whether it is an internal corporate network, or the network required between decentralized branch offices, or even the core backbone of the Internet on which we rely, the firewall policies (including application layer firewall policies, such as WAF), routing policies for these networks, are extraordinarily complex. The dynamic changes in the network, further exacerbating this complexity. Complexity on the one hand pushes up the management cost, on the other hand, it creates new problems, including network security vulnerabilities are often caused by “untimely” changes in complex rules; it can even be said that “the complexity of the network is the root of all evil.”
In response to questions such as the one above, we designed ZTM for the following reasons:
- The identity of the underlying network should exist outside of IP, in a broader and manageable form, such as digital certificates. Identity based on digital certificates is one of the centers of ZTM. In ZTM it is called EP (End Point). In ZTM, EP replaces the traditional IP role
- Routing of network data should be hierarchical. Currently, the basic network routing is at Layer 3; the target “secure network” should have a Layer 7 routing mechanism in addition to the Layer 3 routing, and the two types of routing (Layer 3 and Layer 7) should be able to be coordinated with each other and work together.
- The smallest unit of network “resource” should be “service”, service = IP + port. The current IP-based resource management, management granularity is not fine enough, will lead to additional management work, and create management hazards. “Service” is one of the core of ZTM.
- Compatible with stock IP networks. As the most complex infrastructure of human beings, network is not only expensive to build, but also a huge amount of resources are built on it. Building a new network on top of an existing IP network is not only a cost consideration, but also an iterative value choice.
- Built-in access control mechanisms. Regardless of the sender, transit, or receiver, there should be built-in identification, recognition, and access control mechanisms. Access control should be “build-in” instead of “add-on” as in traditional networks.
- In ZTM, any two endpoints (EP=end point) that communicate with each other either have direct routes in the IP network or can reach some common relay node (Hub). This is different from traditional IP networks where two IPs can pass straight through to each other or else have to go through a series of NATs and reverse proxies.EP-->Hub<--EP and EP-->Router/NAT/ReverseProxy-->EP, with the former being the ZTM model, note the direction of the arrows in it. This structure can be fully adapted to meet the scenarios of “no public IP on both sides of the communication”, such as remote office, branch network, etc.
- When A(EP) and B(EP) need to communicate, in ZTM, they usually connect to the common reachable C(HUB) via HTTP2 first.
- In ZTM, any “resource” accessed by a client, which we call “Service”, is physically an (or a group of) “IP plus port”. IP plus port”. Here, we fully draw on the concept of “service” in the microservice system. Through the introduction of the “service” concept, all the smallest granularity of resources and access control objectives, are converged to “IP + Port”. This is often the basis of firewall management. In other words, ZTM management resources are naturally adapted to firewalls, so there is no need for additional firewall management in ZTM.
- In ZTM, the traditional “client” and “server” are both local, and ZTM maps a service to a local port. When a user accesses the service, the user actually accesses the local port. The advantage of this is that the first point of enforcement of access control is at the “client”; and the “client”, by means of device authentication, etc., ensures that the “client device and user” are the basis of trust. “is the basis of trust. This is the core feature of the current zero-trust system (Trusted Device), which is also one of the reasons why ZTM is called Zero Trust.
- In addition to the authentication and access control completed at the client, a TCP/IP connection (also includes UDP) through the full path will be identified and access control. This mechanism is made possible because the underlying transport of ZTM utilizes the HTTP2 protocol, which provides certificate information and allows additional information to be passed through the Header. This mechanism is discussed in detail in the BeyondCorp [https://cloud.google.com/beyondcorp] paper
To summarize, when A(EP) and B(EP) need to communicate, they first connect to the jointly reachable C(Hub) via HTTP2, a process in which both AC and BC connections are established based on certificates that are encrypted and trusted. Then A and B to build a tunnel (Tunnel), the actual transmission of data in the tunnel processing, and usually using application layer encryption, such as A is SSH Client and B is SSH Server. this “channel encryption” superimposed “application layer encryption This strategy of “channel encryption” overlaying “application layer encryption” ensures that third parties (e.g., Hubs) in the communication link are unable to access the content of the communication and realize “man-in-the-middle” attacks.
Based on this principle, let's look at the following example to further understand how ZTM works. A user has an ssh service (sshd) running on the company network, and the user wants to access this ssh service from home. The following actions need to be done:
- deploy a ZTM EP within the office network, EP-Office
- deploy a ZTM EP at home, EP-Home
- deploy a ZTM Hub in a location that is commonly accessible from the office and home (e.g., a public cloud host)
- EP-Office and EP-Home are connected to the Hub.
- EP-Office registers a sshd service to the Hub.
- EP-Home maps the service to a local port.
- Users accessing EP-Home's mapped port at home actually access EP-Office's sshd service.