Earlier quoted context omitted.
My understanding based on the folks I know at Google is that BeyondCorp paper was a PoC that was implemented in part of their corp network, that is called Production, not to be confused with the production network that hosts their search site. That network still requires a VPN and a hardened Linux laptop to access. Not every service has been modified to implement the RPC calls / authenticated protobuf code changes. S…
BeyondCorp is not just a proof of concept. Everything at Google is accessed through it, including production-production (through a proxy maybe? Not sure the details). You're right about the requirement to have a hardened device -- which acts sort of like a token (as described in the BeyondCorp whitepapers). But it can be Windows, Linux, Mac, Chromebook, Android or iPhone. I never use VPN and I work on production stuf…
Remote access to production infrastructure (death to the VPN)
91–100 of 120 posts
Re: Remote access to production infrastructure (death to the VPN)
#92In my experience, the best way to eliminate the VPN is to expose your various internal business services as websites w/ TLS1.2 & multi-factor authentication. Obviously, this isn't practical for everything. But, if the thing you were using VPN for is already a web application, you are basically halfway there. Ideally, you just directly expose a secure web application to clients, but in some cases (i.e. very old legacy…
Why wouldn't it be even more secure with a VPN in front of it? Is defense in depth no longer a good strategy?
Defense in depth is a concept that should be applied with some thought, it would be good if your additional layer did something different. For example good reactive security, endpoint attestation, etc.
Re: Remote access to production infrastructure (death to the VPN)
#93Earlier quoted context omitted.
He doesn't ACTUALLY suggest port knocking, just the concept ("do something in order to open a firewall hole"). The proposed solution using Lambda w/ 2FA is actually pretty cool.
Correct, but his solution is a hair improvement at best over port knocking. A VPN means an individual connection is authorized into the interior courtyard. A Lambda with 2FA to whitelist an IP, then a cron job to cleanup means everyone at your local cafe wireless access point is also authorized into the inner courtyard.
Re: Remote access to production infrastructure (death to the VPN)
#94I work in this space who has a commercial offering. Ill just leave this CSA spec here for reference. Please also look up SPA - newer than port knocking, but based on same premise. https://downloads.cloudsecurityalliance.org/initiatives/sdp/...
Re: Remote access to production infrastructure (death to the VPN)
#95Bridge a network device – such as a laptop or even another server … into a larger network of servers – such as in the cloud or on-prem … across the Internet – protected with an additional layer of encryption
Re: Remote access to production infrastructure (death to the VPN)
#96> One of my biggest pet peeves about VPNs is that they hijack all your network traffic. They can be configured not to, but our customers and security controls like NIST 800-53 SC-7(7) typically require that they do. VPN is dead because some customers want you to route the internet interfaces of all machines through the VPN server. How does this even make any sense?
Re: Remote access to production infrastructure (death to the VPN)
#97In my experience, the best way to eliminate the VPN is to expose your various internal business services as websites w/ TLS1.2 & multi-factor authentication. Obviously, this isn't practical for everything. But, if the thing you were using VPN for is already a web application, you are basically halfway there. Ideally, you just directly expose a secure web application to clients, but in some cases (i.e. very old legacy…
I want this, but with a twist. 1) I want the websites to do certificate verification on the certs I'm using on my desktop. 2) Then on top of that my website should use usb security key verification as well. Easy enough to do #2, but I want #1 to be ubiquitous as well. ... So basically my HTTPS server will use my public key as my identity, not my username/email and password.
Re: Remote access to production infrastructure (death to the VPN)
#98IAP supports HTTP and TCP connections, so you can put it in front of your website (say an internal admin webapp), or use it to tunnel SSH onto a machine that doesn't have a public IP, using your IAM roles.
If you're running Kubernetes in GKE, you can also wire IAP up to an Ingress, to protect any TCP/HTTP services you have in your k8s cluster. This one is a bit tricky to configure, but is very nice once you have it up and running.
Re: Remote access to production infrastructure (death to the VPN)
#99Earlier quoted context omitted.
My understanding based on the folks I know at Google is that BeyondCorp paper was a PoC that was implemented in part of their corp network, that is called Production, not to be confused with the production network that hosts their search site. That network still requires a VPN and a hardened Linux laptop to access. Not every service has been modified to implement the RPC calls / authenticated protobuf code changes. S…
With BeyondCorp, the production network you access does host all of the critical jobs including search. But of course you only get to manipulate these jobs in an approved way, e.g. using an RPC to bring up or bring down a job. Interacting with jobs by sending them RPCs requires ACLs naturally. You don't get direct SSH access to production machines or any other lower level network access like packet sniffing on the pr…
Re: Remote access to production infrastructure (death to the VPN)
#100TLDR: Use a complicated SSH proxy instead of a VPN. This has some serious downsides for non-SSH applications. For example, to connect to a production database cluster, one would need to ssh through the proxy to a bastion host, and then set up port forwarding from the bastion host to the database. Setting up a simple database connection now requires shell access to a production server. This is less secure and more com…
A great point. It does depend on your use case, and your dependence on manual operations. For our organization, almost all database interactions and maintenance are performed in code; if somebody is connecting manually, something pretty bad has happened. So for us, we are not really impacted by having to perform port forwarding like this on rare occasion. I completely agree that it could be much more impactful to oth…
If intentionality is desired, one can use per-server VPNs.