There is an old saying which states that the only people in the world that like VPNs are cyber attackers. VPNs have always been painful for users to use, and difficult for administrators to operate. Now, especially in our modern app topologies, VPNs are a security vulnerability and are regularly exploited by cyber attacks. And it isn’t just the VPNs on our laptops. This pain extends all the way to the cloud, and all the way through to our databases.
VPN pain knows no bounds
There are often VPNs between database servers and application servers:
These VPNs are growing because app servers are increasingly deployed closer to users at the edges of clouds, and database servers are often more centralized, frequently in on-premise sites or corporate data centers. There are three major problems with these VPNs:
VPN problem #1: You are left with a broad attack surface. VPNs expose your databases to the world because VPNs are full layer 3 tunnels which expose entire networks or subnets.
VPN problem #2: You need to open holes because VPNs require inbound access – you are forced to open inbound firewall ports and link listeners…which can then be exploited by cyber attacks.
VPN problem #3: You are saddled with high complexity and operational cost. VPNs are bad enough, and we also need to add more infrastructure and configurations to try to narrow the large attack surface and holes described above. For example, we bolt-on more complexity such as ACLs, IDS/IPS, and DDoS protection.
The solution to this VPN problem is a new, application specific type of Zero Trust
Here’s what changes in this form of app specific Zero Trust:
App specific Zero Trust solution to problem #1: You minimize the attack surface – you replace the wide open VPN tunnel with least privileged access with microsegmentation. In this example, the app server only needs JDBC access to the database server, and is only granted the access if it is authenticated and authorized by a built-in, bi-directional, X.509 certificate based solution.
App specific Zero Trust solution to problem #2: You closed the holes. Remember those open inbound holes and link listeners in the VPN diagram above? Gone. This Zero Trust solution doesn’t require you to open any inbound firewall ports or link listeners, like you need to do for VPNs. You can actually embed the Zero Trust into applications or as wrappers on standard JDBC drivers.
App specific Zero Trust solution to problem #3: You lowered your operational costs and simplified. Bolted-on infrastructure such as ACLs, IDS/IPS, and DDoS protection…gone (there is no open door for them to need to defend; you closed the door). You can eliminate the firewall, or you can replace all the rules with one rule: deny all. Your Zero Trust solution is a Security-as-Code solution, cloud-orchestrated, with APIs for your DevOps, NetOps or cloud orchestration solutions to leverage for full control, visibility and automation.
App specific Zero Trust is magic?
Ok, I know this sounds like magic. And there is a lot of magic, or at least innovation. But it is all made very simple. The best part is you don’t need to take my world for it:
Open source. We open sourced the software (OpenZiti). Go here to see how we did this for PostgreSQL, and then give it a whirl.
A video is worth 10,000 words. Check out this video demo in which our developer does it all in about 15 minutes.
Dive in. Get deeper on the architecture and software with this whitepaper. The paper describes this use case, as well as other use cases enabled by the same Zero Trust Platform, and provides customer case studies.
Start simple. If you prefer the turnkey SaaS approach to the open source, then you can try our SaaS for free for 14-days (no credit card required until then).
