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.
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.
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
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.