I read the federal government’s Zero-Trust Memo so you don’t have to

It is a risk. The discourse on VPNs is messy. It's true that you shouldn't rely solely on VPNs for access control to applications. It's also true that putting important services behind a VPN significantly reduces your attack surface, and also puts you in a position to get your arms around monitoring access.

The right way to set this stuff up is to have a strong modern VPN (preferably using WireGuard, because the implementations of every other VPN protocol are pretty unsafe) with SSO integration, and to have the applications exposed by that VPN also integrate with your SSO. Your users are generally on the VPN all day, and they're logging in to individual applications or SSH servers via Okta or Google.

"RIP VPNs" is not a great take.

Thanks for saying this. This was exactly my take. Saying goodbye to VPNs just completely ignores the risk of RCE vulnerabilities on your services. You can have a VPN that still brings you into a zero trust network.

It does essentially define away the authentication bypass problem, which is a class of vulnerability we still regularly find in modern web applications. To say nothing of the fact that no human has ever implemented a SAML RP without a game-over vulnerability. Seems like a self-evidently bad plan.

I don't like VPNs. I think there's better ways of protecting our infrastructure without them. AWS offers a lot of technologies for doing just that.

A VPN is another failure layer that when it goes down all of your remote workers are hosed. The productivity losses are immense. I've seen it first-hand. The same for bastion hosts. Some tiny misconfiguration that sneaks in and everybody is fubared.

Bastion hosts and VPNs: we have better ways of protecting our valuables that's also a huge win for worker mobility and security.

That's true of legacy VPNs like OpenVPN, and less true of modern VPNs. But either way: a VPN is a meaningful attack surface reduction for all internal apps that don't require individual apps to opt-in or stage changes for, and doesn't require point-by-point auditing of every app. Most organizations I've worked with would be hard-pressed to even generate an inventory of all their internal apps, let alone an assurance that they're properly employing web application security techniques to ensure that they're safe to expose on the Internet.

We're just going to disagree about this.

It's not clear to me that a VPN endpoint is a meaningfully smaller attack surface than an authenticating proxy? The VPN approach has a couple of downsides:

* You don't have a central location to perform more granular access control. Per-service context aware access restrictions (device state, host location, that sort of thing) need to be punted down to the services rather than being centrally managed.

* Device state validation is either a one-shot event or, again, needs to be incorporated into the services rather than just living in one place.

I love Wireguard and there's a whole bunch of problems it solves, but I really don't see a need for a VPN for access to most corporate resources.

Sure: an authenticating proxy serves the same purpose. I agree that unless you have a pretty clever VPN configuration, you're losing the device context stuff, which matters a lot in some places.

I'd do:

* SSO integration on all internal apps.

* An authenticating proxy if the org that owned it was sharp and had total institutional buy-in both from developers and from ops.

* A WireGuard VPN otherwise.

If you can get the govt to drop FIPS or wireguard to change to ...different crypto, wireguard would take off like hotcakes.

I'd be flogging tailscale so hard!

Stupid policies.

If you have the institutional buy-in to handle auth being done at the proxy level, that gets you away from having to implement SSO per service. I agree that doing this well isn't trivial, but in the long term there's a reasonably compelling argument that it makes life easier for both developers and ops.

> * SSO integration on all internal apps.

> * An authenticating proxy

I'm having trouble understanding what the fundamental difference is between these. Is it just a matter of a single, centralized proxy at the perimeter of your service network versus in-service SSO? Is there a functional difference between being in the same process space versus a sidecar on the same host versus a service on another host?

Ultimately it boils down to trusting the authority, whether that's a function (code review), a shared library (BOM), an RPC (TLS), a sidecar (kernel), or a foreign service (mTLS). There are different strengths and weaknesses for each of these, but it's not clear to me that the options you would prefer are distinctly more or less secure -- maybe there is an argument for defense in depth, but I'm not certain that's what you're pitching.

Most SSO solutions don't verify device identity or state, so you're not ensuring that the connection is coming from a computer you trust running software you trust.

I guess it's a matter of what the IdP attests. It's definitely possible for an IdP like Okta to include a ton of client details as part of the attestation payload. Stuff like GeoIP, client certificate fields, MDM status, etc.

Right, but you have to individually set up all of your apps to work with it; the proxy can be mandatory for all apps by dint of network controls.