I am looking at the Connection Security section at Connection Security | OpenZiti , but I have a doubt that is not quite related to network connection security:
As shown in the figure below, the controller is directly connected with all the networking gateways, meaning that each router must be able to directly access the centralized controller, or is there a pattern similar to the mqtt broker (broker), where an intermediate route can be used for transit, to complete the networking?
Before providing any answer, why are you asking? For example, do you have a scenario where direct access is not possible or is there some other concern??
Hi @PhilipGriffiths . I'm glad you've pinpointed the crux of the issue so succinctly. Thank you for your attention. The problem is actually quite simple, but the scenario is more complex.
I've drawn a simple schematic to illustrate that I now want to connect the school and its multiple laboratories' networks together through a zero-trust architecture. Let me briefly introduce the scenario I'm facing:
The school network is a hybrid cloud that includes both public and private clouds, isolated from each other by a firewall (the actual network topology is more complex, but the diagram has been simplified to explain the issue at hand). Considering the exposure of risk surfaces and the convergence of hacker intrusion paths, the school's network security regulations stipulate that WEB applications containing sensitive data in the private cloud are not allowed to connect to the Internet. This is understandable, as systems like the campus's educational grading system, teaching material management system, and fire monitoring system should not and do not need to be exposed to the Internet. Meanwhile, the school's official website is hosted on the school's public cloud, accessible to the internet. At the same time, some laboratory organizations also need to access the school's experimental data (public cloud).
As shown in the diagram, the zero-trust design is implemented through ZITI, where Private-web1 is not allowed to connect directly to the Internet. My idea is to use a host that can connect to the Internet (with non-sensitive data, after registration) as an intermediate Agent, manually configuring it as a NAT router or a bridging network node. Other Private-web applications would then configure their routes to point to this Agent, solely to allow the ZITI-SDK on Private-web1 to access the ZITI-Controller.
However, there is a drawback to this approach. It's akin to exploiting a loophole in the school's network security regulations, as it effectively opens up a Layer 3 network channel that is not converged into ZITI's zero-trust architecture. If a hacker were to compromise the Private-web host, they could access the Internet without going through ZITI (for example, by downloading more hacking tools, Trojans, etc.), and even if ZITI policies cut off Private-web or the Ziti router, it would be too late, requiring manual disconnection of the relevant network connections (such as shutting down the Agent).
If ZITI supported a Broker mode, it would be possible to install a ZITI-BROKER-ROUTER on the Agent host, forcing all traffic from terminals connected to the private cloud, such as Private-web and IOT-Router, to go through ZITI's encrypted links. If the Private-web host were compromised, hackers would not be able to bypass ZITI to access the Internet, significantly reducing the exposure surface. Moreover, if a problem is detected, it could be directly cut off from the Controller via the BROKER.
I am a newcomer to the fields of network security, zero trust, and PKI encryption, and I apologize if my questions seem basic or naive, or if they have already been discussed. However, I believe that hybrid cloud scenarios or similar security domain partitioning scenarios are quite common. Are there better solutions that do not require opening up a Layer 3 network, yet allow isolated hosts to access the Controller?
Thank you again.
How do the security policies define "connect to the internet"? Many Ziti users whitelist IP's of the network infrastructure through their firewalls. So in your theoretical case, if Private Web 1 were compromised, the actor could still not egress directly to the internet because that system is only allowed to connect to the Network Controller and any external Edge Routers you might have. That connection is outbound only, and to the specific address(es) (IP or FQDN) of the infrastructure nodes. That sort of configuration protects against the threat vector you have identified here. And as all of these connections are encrypted and cryptographically authenticated, the nodes are not "connected to the internet" in any practical sense, they are using public IP transport in much the same way as they do electrical power, as a utility.
I should really finish my coffee before responding some days. Since 0.22.31, Ziti Edge Tunnel has supported a basic HTTP proxy for controller connections. So the broker you are referring to could be an HTTP proxy, configured with whatever rules are required.
@mike.gorman HTTP Proxy is great, this is exactly what I wanted, thank you.
