←back to thread

656 points EthanHeilman | 1 comments | | HN request time: 0.001s | source
Show context
uncomputation ◴[] No.30103419[source]
> “Enterprise applications should be able to be used over the public internet.”

Isn’t exposing your internal domains and systems outside VPN-gated access a risk? My understanding is this means internaltool.faang.com should now be publicly accessible.

replies(10): >>30103496 #>>30103558 #>>30103584 #>>30103588 #>>30103623 #>>30104344 #>>30104669 #>>30105221 #>>30106774 #>>30106879 #
tptacek ◴[] No.30104669[source]
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.

replies(4): >>30104873 #>>30106246 #>>30106871 #>>30107049 #
mjg59 ◴[] No.30106871[source]
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.

replies(1): >>30106926 #
tptacek ◴[] No.30106926[source]
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.

replies(2): >>30107068 #>>30110524 #
1. mjg59 ◴[] No.30107068{3}[source]
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.