The idea that many vendors have is an agent on the client and server that scrutinizes every connection, at both ends, based on policy and/or entitlement to specific resources. For an enterprise this means not having to worry as much about locking down your internal network as it is no longer the only boundary. In reality this is a very tall order. All your internal systems, legacy systems, cloud vendors, etc. have to be on board. The reality is a hybrid solution with all the attendant complexity.

Good point. I would also like as an argument that the hybrid approach should be seen as having multiple lines of defense. A corporate network should have an outer boundary that is hard-ish to penetrate. Personal devices should either require approval or use some kind of vpn to access any part of this network. Inside, the network should be divided into subnets with their own border protections, in case an attacker penetrates the outer shell/userland. For all subnets, zero-trust should be implemented when possible, even for communication within a subnet. Finally, monitoring should be in place to listen for unusual activity, whether that is unusual or suspicious traffic, unexpected changes in configurations of nodes on the network, etc.

Zero trust means "don't authn/authz based on IP address, authn/authz at the application level where you should have been doing that in the first place."

How long has authn/authz been in your lexicon? Took me a second but I rather like the abbreviation even if the spelling omitted is different.

If you are to provide access to an app or network, you need to trust (something) under some circumstances.

> provide access to a network

That's your first mistake. You should be providing access to software, not networks. The idea of a "trusted" network that applications or users can communicate on is the fundamental idea that zero-trust architecture aims to get rid of.

> You should be providing access to software, not networks.

You should be providing access to an identity, not software. If someone is running the same software but with the wrong identity, it should be denied access.

One non-malicious example that comes to mind is the right application from the wrong environment, e.g. dev frontend calling prod backend, or even worse prod backend calling test DB, etc.

I think they meant that software is 'what the identity should gain access to', and you 'should not grant that identity access to networks'; it is worded a bit confusingly.

From a known identity to an API

I feel like you need to go back and read the comment I'm responding to again, because you have deeply misinterpreted what I'm saying. I'm talking about the things users access, not who they are when they access them.

Close! Identity and environment. Even if you have "launch the missiles" authority, you might not have it on the weekends, at night, or from Cuba.

Indeed. Resulting in similar complexity between cloud and internal apps.

You can also call it 'perimeter-less security'.

As for zero trust - that seems to be a bit of a misnomer to me - doesn't it tend to aggregate trust into one big bucket - certs?

Won't anybody who can do man-in-the-middle or has access to root certs have total free reign?

Security services wet dream.

absolutely. can even completely 'eliminate' the network by closing all inbound firewall ports (not even allowing dynamic hole punching), and then opening ephemeral, session-specific L3 outbound connects (from both sides* of the session) only for authorized sessions.

* requires intermediate 'gateways' which can bridge both sides to enable bidirectional data flow, initiated from either side