Google makes zero-trust work by having a highly "centralized" or "uniform" tech stack all the way from tooling, to hosting, to infra. So everything defaults to zero-trust and it's not something you would need to think about setting up.
Most big organizations have built up their internal/external tech over decades, with large parts of it being essentially "mothballed", and high degree of heterogeneity stemming from tech changes over time/acquisitions/departments having flexibility in what tools and design they can use. Shifting to zero-trust requires a lot of migration work across all of this, "training" ie figuring out how to get stubborn IT people to buy in to the new way of doing things, and most likely a shift to the "centralized" kind of model that Google uses.
Even if the first two are funded, that third "centralized"/"uniform" model can be very expensive. One of the reasons Google has to deprecate things so much is that the centralized model requires constant migrations and breaking upgrades to keep things running, which makes it so "mothballing" isn't a thing: you either have enough people assigned to handle the migrations, or turn it down.
I agree that zero-trust is the best security model and it solves many problems. But I guess I'm also saying it's much easier said than done. With my startup I want to solve a lot of these kinds of problems (ie introducing "uniformity" that follows best practices) for my customers, but it's inevitable that some point a customer will ask for the ability to "turn off zero-trust and allow for IP whitelisting" - is it worth it to close a potentially big deal? It's also probable that any reasonably successful company will at some point perform an acquisition involving a company without a zero-trust model - is that reason to cancel the acquisition?
> Shifting to zero-trust requires a lot of migration work across all of this, "training" ie figuring out how to get stubborn IT people to buy in to the new way of doing things[...]
You're right, most times organizations need a fire lit underneath them to change, for Google, it probably was the NSA annotation "SSL added and removed here :^)" on a slide showing Google's architecture from the Snowden leaks.
> You're right, most times organizations need a fire lit underneath them to change, for Google, it probably was the NSA annotation "SSL added and removed here :^)" on a slide showing Google's architecture from the Snowden leaks.
Most big organizations have built up their internal/external tech over decades, with large parts of it being essentially "mothballed", and high degree of heterogeneity stemming from tech changes over time/acquisitions/departments having flexibility in what tools and design they can use. Shifting to zero-trust requires a lot of migration work across all of this, "training" ie figuring out how to get stubborn IT people to buy in to the new way of doing things, and most likely a shift to the "centralized" kind of model that Google uses.
Even if the first two are funded, that third "centralized"/"uniform" model can be very expensive. One of the reasons Google has to deprecate things so much is that the centralized model requires constant migrations and breaking upgrades to keep things running, which makes it so "mothballing" isn't a thing: you either have enough people assigned to handle the migrations, or turn it down.
I agree that zero-trust is the best security model and it solves many problems. But I guess I'm also saying it's much easier said than done. With my startup I want to solve a lot of these kinds of problems (ie introducing "uniformity" that follows best practices) for my customers, but it's inevitable that some point a customer will ask for the ability to "turn off zero-trust and allow for IP whitelisting" - is it worth it to close a potentially big deal? It's also probable that any reasonably successful company will at some point perform an acquisition involving a company without a zero-trust model - is that reason to cancel the acquisition?