3 ms·

It's not everything, it's services that are only used internally (which might or might not be the case for Jira depending on the use case). There's no two logi

It's not everything, it's services that are only used internally (which might or might not be the case for Jira depending on the use case). There's no two login forms anyway if your IT doesn't want it to be, on one hand VPNs are usually not accessed on demand during the work day and on the other hand all Jira versions I'm aware of can be integrated with some form of SSO anyway if you feel like it. Offices are usually internal and wouldn't have to deal with a VPN anyway.

Spivak 7y ago
The problem is that my fellow IT people define "only used internally" to mean "only used by employees" instead of "only useful to someone physically at our office." Protect your VPN with SSO and then protect your service with the same SSO is incredibly common and perfectly demonstrates, in my view, the stupidity of VPNs. The VPN added NOTHING to your your authentication or authorization. If you're going to fully check a users credentials at the VPN where users are in a totally untrusted domain and fully check them again at the service then clearly your internal network is also being considered an untrusted domain -- which I think should be the case -- but then all the VPN does is move users from one untrusted domain to another. Why is the VPN there? I think offices would actually be more secure if services like this were only accessible externally (doesn't have to be literally, just philosophically no reason to route out and back in your WAN). Instead of connecting to a VPN and having access to the internal network where there's probably a lot of surface area exposed the external only model means that you're only connected to the single service you authenticated to.
- tastroder 7y ago
  I don't think I get this argumentation. VPNs are easy to use these days so there's no "physically at our office" angle imho. The VPN adds a zone that the client can trust (which should not entail your whole internal network being exposed to it but I've never seen that anywhere to be quite honest). They get their Windows/AV/whatnot updates from that, connect to the services they need on the road. Simultaneously the VPN shields said services in a managable way, though that's more of a on-premise vs. cloud discussion I feel like, with the VPN being the way to get access to the on-premise stuff if you do not happen to be in the office. Maybe I'm missing your alternative? VPNs have some upsides over, say, a reverse proxy for that use case (weird sales clients for example that talk TCP, not HTTPS) in the setups I've seen. It also prevents exposure to the exact scenario we see in this very thread. Finding public instances of popular software is easy, enabling drive-by exposure to vulnerabilities. Putting them behind a proxy/VPN at least provides a hurdle for non-targeted attacks from my point of view.

Spivak 7y ago

The problem is that my fellow IT people define "only used internally" to mean "only used by employees" instead of "only useful to someone physically at our office." Protect your VPN with SSO and then protect your service with the same SSO is incredibly common and perfectly demonstrates, in my view, the stupidity of VPNs. The VPN added NOTHING to your your authentication or authorization. If you're going to fully check a users credentials at the VPN where users are in a totally untrusted domain and fully check them again at the service then clearly your internal network is also being considered an untrusted domain -- which I think should be the case -- but then all the VPN does is move users from one untrusted domain to another. Why is the VPN there? I think offices would actually be more secure if services like this were only accessible externally (doesn't have to be literally, just philosophically no reason to route out and back in your WAN). Instead of connecting to a VPN and having access to the internal network where there's probably a lot of surface area exposed the external only model means that you're only connected to the single service you authenticated to.

tastroder 7y ago
I don't think I get this argumentation. VPNs are easy to use these days so there's no "physically at our office" angle imho. The VPN adds a zone that the client can trust (which should not entail your whole internal network being exposed to it but I've never seen that anywhere to be quite honest). They get their Windows/AV/whatnot updates from that, connect to the services they need on the road. Simultaneously the VPN shields said services in a managable way, though that's more of a on-premise vs. cloud discussion I feel like, with the VPN being the way to get access to the on-premise stuff if you do not happen to be in the office. Maybe I'm missing your alternative? VPNs have some upsides over, say, a reverse proxy for that use case (weird sales clients for example that talk TCP, not HTTPS) in the setups I've seen. It also prevents exposure to the exact scenario we see in this very thread. Finding public instances of popular software is easy, enabling drive-by exposure to vulnerabilities. Putting them behind a proxy/VPN at least provides a hurdle for non-targeted attacks from my point of view.