3 ms·
Um, I'm not Google, but I think for a typical small/medium-scale tech business we're not there yet. > "The problem with the “castle” approach is that once the
by nirv 9y ago
Um, I'm not Google, but I think for a typical small/medium-scale tech business we're not there yet.
> "The problem with the “castle” approach is that once the perimeter is breached, the entire internal network, and all the associated applications, are at risk. “Do not trust your network. It is probably already owned”"
Considering an example of a common software development company, we may assume they use VPN to get into private network with their project management, git, devel, staging, backups, documentation and other servers/applications. Each of them requires user authentication, each user has its own privileges. VPN here adds an extra layer of security. But either way, being behind the VPN or not, services potentially carry the same level of risk. Implementing perimeter security doesn't imply a lack of security of services within.
> "Google’s approach involves comprehensive inventory management, one that keeps track of who owns which machine in the network. A Device Inventory Service collects a variety of live information about each device […] Employees get the appropriate level of access regardless of what device they are using or where in the world they are logging in from. Lower levels of access require less stringent checks on the device itself. […] The applications themselves are routinely checked for breaches by vulnerability scanners."
> "VPN was cumbersome to use, and slowed performance, especially for overseas workers. And it is no walk in the park for admins either. To set up a new user, the admin would typically have to configure the cloud network, along with setting up the IPSec rules and firewall rules, the VPN. This is followed by a lot of testing"
Again, I'm glad that it works for Google and that they're able to routinely check all hardware credentials and servers "for breaches by vulnerability scanners", but this whole passage and complexity scheme behind it causes me a headache. I think I'll continue to rely on the traditional VPN, but based on the modern lean WireGuard[1].
[1] https://www.wireguard.com/ https://www.wireguard.com/
- oarsinsync 9y agoYou may wish to re-consider your position of relying on Wireguard. From their website: > WireGuard is not yet complete. You should not rely on this code. It has not undergone proper degrees of security auditing
- Hello71 9y agoI would trust my WireGuard significantly more than any installation of IPsec, if nothing else than because I will almost certainly configure IPsec in a manner that is completely insecure, but not obviously so.
- nirv 9y agoIt's true, but apparently it's getting close to be implemented into Linux[1][2]. [1] https://www.phoronix.com/scan.php?page=news_item&px=WireGuard-2017-Maturing https://www.phoronix.com/scan.php?page=news_item&px=WireGuar... [2] https://www.phoronix.com/scan.php?page=news_item&px=Systemd-237-WireGuard https://www.phoronix.com/scan.php?page=news_item&px=Systemd-...
- zackbloom 9y agoDoes the new Cloudflare Access product (maybe with their Warp product) address your concerns? It means visitors never need to have access to your physical network, their traffic only goes to the specific machines you intend.
- nirv 9y agoProbably. But I'm not inclined to rely on third-party companies for a core business infrastructure. The сompany behind a VPN I portray above most probably uses in-house self-hosted Gitlab/Confluence/etc instances. However, it's absolutely okay to outsource such needs when it's appropriate.
- Cidan 9y agoTake a look at Google Cloud IAP -- it's essentially a stripped down version of BeyondCorp for public use on Google Cloud. I've used this as a customer of Google's with great success, it really does just work. Disclaimer: I work for Google Cloud.