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