| Great question. It helps to think in terms of vulnerability surfaces and the amount of harm that can be caused by a compromise. If we use a VPN, then access is controlled to the boundary of that VPN. All code that is running within that boundary must remain secure for our remote services to stay protected. This is a large vulnerability surface, the likelihood of a compromise is proportional to the the size of our vulnerability surface. If any service within a VPN boundary is compromised, then there are no safeguards preventing an attacker from jumping service to service and causing a lot more harm. With VPNs, our vulnerability surface is large and amount of harm that can happen is also very large. In contrast, the approach described in the above guide dynamically creates short-lived access to a specific service. In such a setup, our vulnerability surface is a lot smaller - it is limited to the code of our secure tunnel and our target service. It doesn't include all the other code within the same network boundary because our target is not listening on a network accessible port - even within its local network - it only needs to listen on the loopback address. Just-in-time, short lived creation and deletion of the Inlet also reduces the amount of time traffic can reach the private service - which further reduces our vulnerability surface, If a compromise does happen, the amount of harm that can be caused is also a lot smaller, in this setting, because other services within the same boundary also don't have open unnecessary ports - lateral movement becomes a lot more difficult for an attacker. |