Zero trust DMZ
Eliminate the headaches and vulnerabilities of open ports, ACLs and VPNs. Close all access to all your servers and data. New rule for your DMZ firewalls: deny-all inbound
Securing your DMZ
ZTNA enables us to authorize our internal users. The problem is external flows which don't get fully authorized until we let them into our DMZ. This includes APIs, B2B, remote management, 3rd party access, multicloud, IoT and ops (SIEM, APN, log collection, DevOps, etc).
Without zero days, malware, auth bugs, exposed VPNs, business logic gaps and misconfigurations, doing the final auth in the DMZ would be ok. And it is, 99% of the time. Unfortunately, the attackers only need one hole. At that point, your DMZ is attacked from anywhere on the Internet.
Zero trust DMZ
NetFoundry zero trust networks, hosted by you or by NetFoundry (as SaaS) move the authorization outside of your DMZ. The zero trust overlay enforcement point (PEP) is initiated before any sessions are allowed to enter the overlay in the first place.
Your DMZ closes all inbound firewall ports, and has no exposed perimeter. Instead, authorized sessions from your DMZ open outbound only sessions to the specific private overlay nodes and applications your policy permits. See below for full details.
Zero Trust DMZ - architecture
You converge networking and security, moving the policy enforcement point. Apps and devices need to identify, authenticate and authorize before they can can send packets to your private Ziti overlay fabric. You move the policy enforcement point all the way back to the initiation of the session, preventing unauthenticated data from ever reaching your firewalls. Your app and web servers are protected - not accessible to unauthenticated users on the Internet.
Your passport gate your private Ziti overlay networks. Nothing gets on your private Ziti overlay without passports. Cryptographically validated X.509s are the passports. The Ziti platform takes care of automated enrollment, PKI and certificate renewals. The X.509 functions like it is a Yubikey or hardware dongle physically loaded on each device, so is much more difficult to steal or hijack than passwords, SMS codes,etc. The solution is similar to network access control (NAC) solutions, except it is for Internet-distributed devices and apps, and secured with modern cryptography. Your app and web servers will now only talk to parties which are X.509 authenticated.
You extend your Ziti networks anywhere, without needing to control the underlay networks. Ziti enables you to deploy 'endpoints' as software, anywhere, even inside the process space of your apps (via Ziti SDKs). This enables any type of client, server or API to be authenticated, which means your servers are protected from unauthenticated endpoints.
Your secure your servers with mutual TLS. Mutual TLS (mTLS) is a big deal. Not just for security or compliance requirements, but because it is far more secure. TLS secures clients - mTLS secures your servers. But of course there is a catch. mTLS can be difficult to implement. So Ziti provides mTLS in all directions, controlled by you from one platform, across all edges and clouds, for all use cases, including remote access, log collection, SIEM, remote management, DevOps and GitOps, APM data and CI/CD .
Network performance and reliability. Your private Ziti overlay network fabric includes HA, load balancing and dynamic routing across multiple tier one backbones. You can put parts of the Ziti data plane into your environments, so you don't have to backhaul latency sensitive sessions to the cloud. Every session follows it own optimized routing - eliminate tunneling all sessions to one place, and then routing out from there.