> "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].