[kyrra]

As you can sort-of see from the linked site, this is a public version of what Google uses internally, which is called BeyondCorp[0].

It's really an amazing way to think about security for a company. If you deploy it universally across your company, VPNs become obsolete. This solves a popular attack vector where bad-actors just need to get onto a corporate network to do damage. If you can authenticate at every service your employees connect to, it closes down that vector.

[0] https://cloud.google.com/beyondcorp/

[hdhzy]

As far as I remember BeyondCorp required users to be equipped only with attested hardware (no BYOD). This device's health then was constantly being monitored and taken into account when granting / denying access. I'd like to see the differences between IAP and Google's internal BeyondCorp. Quick search did not reveal anything.

[wffurr]

The only BYOD device allowed is Chromebooks with a signed bootloader, aka no developer mode or Crouton.

[kuschku]

Unless you modify the hardware, of course.

Considering Google has teams designing custom PCBs and even ICs, there's a non-insignificant amount of Google devs who could easily circumvent this entire system.

[weeks]

The purpose of ascertaining device identity is to prevent someone who can't obtain legitimate Google issued hardware from using stolen user credentials. If you're already a Google employee you can just ask for more trusted hardware, so there would be little point in breaking that part of the security model.

[kuschku]

Well, there was recently a case where one of the developers for Google's custom LIDAR hardware stole the plans and gave them to Uber.

And people argued he had no option to hide it.

As I mentioned there, too, it's trivial to break that security if you have the knowledge to design and reverse custom ICs, and you could just steal the laptop of someone else, clone their trusted hardware system, and ensure their laptop is back in place.

Then later use that account to download the data to be sent to Uber.

I mean, for many cases of corporate espionage this is easily doable — it's just fancy DRM, after all. Not by the average dev, but for people who design this hardware or similar hardware in the first place, definitely.

[londons_explore]

Google's model requires two factor user auth, and trusted hardware.

Even someone with serious hardware-foo would only be able to maybe break the trusted hardware bit (by cloning one device id to another, or emulating a device). They couldn't get round the two factor authentication bit.

I'd say it's still a pretty watertight model.

[pizzetta]

Like many things, I'm sure you can make a case for exceptions or whitelists --although granted they likely monitor and or shunt traffic to less trusted vlans or something?

[londons_explore]

The ultimate BeyondCorp setup has no vlans. All networking kit is considered untrusted (and can be the public internet). All traffic is end to end encrypted between the employees device and the specific server they want to communicate with via HTTPS.

Obviously, getting entirely to that model is a lot of work, mostly for services which don't use HTTPS (network shares, ftp, smtp, ssh, enterprise java apps, etc.)

[brazzledazzle]

I think that's why the describe this as "...a building block toward BeyondCorp..." We'd pay for them to develop a service that did the whole 9 yards (multi-platform agents, CA, client-certs, etc.).

[closeparen]

In general, you can prevent BYOD with this approach by rolling out client certificates with config management and requiring them at the proxy.

[londons_explore]

And the client certs can be tpm backed so they can't be copy+pasted to other machines.

[mikecb]

Part of the announcement was that additional contextual auth capabilities would be added.

[lazylizard]

i really dont get what this is. is it not web based auth? why are VPNs obsolete? this does not co-exist with VPNs? how is this different from , say, shiboleth or other saml or sso schemes?