Published on 2015-12-10
VPN encapsulates the intended transmission from one network to another. Encryption is used to hide the data from any systems in-flight.
Delivering data from one network to another has nothing to do with addresses -- routers will push packets regardless. Encryption is usable at all levels, can exist in multiple layers, and can be strengthened or improved independently of the service itself (e.g. use ed25519 keys VPN is an unnecessary addition to the security model because the requisite pieces are already provided via firewalls and encryption services like SSH and TLS.
VPN adds another "switch" to flip when performing "real work," especially when working from home or unfamiliar environments. Employees can, and will, forget to enable the VPN when working, or will have trouble establishing a VPN tunnel from a Starbucks when on-call. This can and does increase troubleshooting load, including maintenance and support load from IT, even when everything is functioning normally because the VPN adds cognitive overhead to an Engineer's debugging process. Additionally, during high-stress situations employees (including Management) may circumvent the VPN for the sake of expediency, which removes its protection.The VPN provides a single point of failure -- accessing systems over the office-bound VPN failed repeatedly while we tried to resolve networking issues. For several days there was intermittent connectivity to internal addresses in GCP, greatly hampering developer productivity.Using external IP address access for Engineering operations means connections are always the same, work successfully over the public internet, and can be verified, every time. No one has to remember to turn on an External Interface in order to access a service, they simply connect and are authenticated through. When paired with multifactor authentication like and using hardware tokens like the thoroughly-vetted-and-reviewed Yubikey, systems are often more secure than when accessed using an authenticated VPN connection.
VPNs are usually evangelized as a reason for everyone to "rest easy" knowing
that they are operating within a perceived-controlled environment. This cannot
be further from the truth -- the networked environment is just as vulnerable (if
not more so) than one's own computer. Even worse, should any one employee's
laptop be compromised, VPN access is at the attacker's control and once through
the VPN they have free reign among the unencrypted internal services.
In contrast, using multiple layers of authorization and encryption (RE:
Duo Security and TLS/SSH) mean that the connections are always secured
and can be limited in their scope. Should one find that a given app or
host is misbehaving, they can change authentication credentials and
audit the offending part instead.
VPNs tend to be set up such that each endpoint provides access to the rest of the network as a sort of "high ground." There are no real limits or tests of traffic from the VPN into the rest of the network. Some VPNs provide VLAN isolation, but these VPNs are meant to allow engineering work to happen, and so often provide access directly to the most desirable targets.Using multiple layers of firewalls instead means that traffic is constantly checked, both on initial ingress and further attempts to contact / connect with other instances. This means that a person or system which isn't supposed to contact the database cannot contact the database despite otherwise having access.
It is, but only due to historical issues which have nothing to do with current technology.The reasons for using VPNs are tied to old-school business models (i.e. datacenter-to-datacenter and office-to-office connectivity), old software which does not support encryption, IPv4 limitations, and enshrined "Security Best Practices":
None of these issues apply today:
For all of these reasons, we don't need VPN if we can encrypt and authenticate our services. None of the technology is stopping us.
Google works with many companies which have security requirements that mandate the use of a VPN. (See reasons above.) If they did not provide "feature parity" with those legacy systems, they wouldn't be able to work with the larger companies that give them lots of money in hosting costs. In short, it costs them almost nothing to offer it, and they give their clients the ability to check a box in their requirements documentation for security audits. Details here.
Google uses things like the Yubikey and authenticating-gateways to secure their networks since they transitioned to a zero-trust design after the detection of an APT in 2009. If one of the largest and most-exposed companies is using a zero-trust model, one would assume it succeeds where a perimeter-defense design failed.
Port 22 (SSH) is open to the world on all GCP instances, as SSH is their only means of access. Botnets are constantly trying to access those systems with common accounts (e.g. admin, cisco, etc) and yet none of them get in. They are refused precisely because password-based logins are not used (unless someone explicitly does so). In the past, using SSH keys was believed considerably more effort than it was worth -- "just use a password" -- until enough systems were attacked due to weak passwords. During a recent port scan of an in-use production network, the only ports publicly accessible to an outside IP address were the following:
Otherwise, the firewall denied anything not explicitly approved. The added fact that the only hosts which responded to cleartext requests were explicitly and specifically designed to do so should say something about the security of the setup.