OP is using weird terminology. It would probably be clearer to say "Anything connected to the Internet is a ticking time bomb. Any servers or admins which need to talk to the database should instead use a VPN." which indeed was best practice until recently.
But we should remember why it's not always considered best practices... you shouldn't assume that your private network is any more secure than the public network. When you have too many devices attached to that private (overlay?) network, it can be at just as much risk as if it was on the public internet. So, the zero-trust model is that you don't trust anything... public... private... it should all be untrusted.
Given that this was a "third-party cloud provider", I'm assuming that it was a credential leak and they only have username/password protections. Moreover, I doubt you'd have been able to add the provider's DB to an ATT based private VPN/network.
yep was trying to avoid word which carry varying connotations, e.g. vpn or zero trust.
zero implicit trust is likely the best term? you have to trust something, but enforce (and therefore trust) strong (not network based) identity, authN and authZ. this can be done anywhere via a software-only overlay.
a litmus test is server iptables (to use an example) looks like:
iptables -P INPUT DROP
iptables -P FORWARD DROP
and the only route outbound from the server is to the private overlay on one port, and that server still can't make those connections unless it is strongly identified and authenticated, and the overlay will not connect the client and server unless they are both authorized to communicate for that particular service(1)
(1)so for example if there is a zero day causing the 'server' to try to communicate with some_IP then the private overlay will not accept the connection, even though it is coming from the server
For highly secured services, I completely see the rationale for a private overlayed network. Tailscale, et al are great for this, where you're only exposing services to members of the private network. The problems start when people make the assumption that the private network is a secured network.
I don't think any of this would have mattered to ATT, as the breach was from a third party that wouldn't have been on a private network anyway.
But, that would be a great service bonus -- only being able to connect to a service via a user-configurable private overlay network. It would be nice, but highly impractical... I can't even begin thinking about how customer support would be able to handle a scheme like this.
Sorry, I was trying to refer to creating overly VPN networks with vendors. So in the ATT case, it would mean their DB vendor (I’m assuming) creating separate VPN networks for each of their customers to connect through (in addition to username/pass credentials). The logistics of managing separate VPNs for each customer, for each user account, etc seems overwhelming.
For more traditional single-entity networks, you’re right. But with more and more BYOD, those networks are at a higher risk than they used to be. That’s the reason for the shift… VPN tech is still sound, but it requires that you trust the devices that are connected to it.
If you’re now also trying to trust devices from your company and your customers, that’s harder to work my head around.
