There’s an argument to be made that some datacenter
topologies have segmented their networks such that there’s
no reason for clients to authenticate. I’m generally not a
fan of this approach because over the years I’ve come to
believe there is untrusted code running “in the perimeter”
So I don't think this statement on it's own is necessarily egregiously bad, but I think there are some excellent general take-a-ways that should apply to anyone who's running a SaaS business:
1. "Certain Network Topologies" should be "Most", or at least "Your" network topology. And this statement doesn't need to be confusing: You're going to run sensitive services on your network, you're going to run databases, and those services really shouldn't be exposed to the outside world. Even your applications should ideally not be exposed directly to the outside world, they should be proxied by a load balancer / network gateway that forwards only expected traffic to your service. Make your LBs default to not allowing traffic so that you can confirm this. Use services like ELB and VPC if you're in Amazon.
2. "Untrusted code running in the perimeter" is a situation that you should A) control, and B) aggressively be defensive about.
3. If you're going to go all the way with service auth, you need to think about how safe your secrets are. If your code is shipping with the secrets, then you're really gunning for security by obscurity. Keeping secrets on disk is a security hole. Heck, even keeping plaintext secrets in memory is not fool-proof.
I liked the article, but generally speaking, you really do need a comprehensive solution to service-to-service auth if you want to go down that road, because taking shortcuts is going to just expose you to a ton of downsides without even attaining the upshot. And regardless of if you set up service-to-service auth, you really should be segmenting networks anyways for a host of reasons, and layering auth on top of that. So these two things are inter-related on some levels, but form a layered security approach together :-).
1. "Certain Network Topologies" should be "Most", or at least "Your" network topology. And this statement doesn't need to be confusing: You're going to run sensitive services on your network, you're going to run databases, and those services really shouldn't be exposed to the outside world. Even your applications should ideally not be exposed directly to the outside world, they should be proxied by a load balancer / network gateway that forwards only expected traffic to your service. Make your LBs default to not allowing traffic so that you can confirm this. Use services like ELB and VPC if you're in Amazon.
2. "Untrusted code running in the perimeter" is a situation that you should A) control, and B) aggressively be defensive about.
3. If you're going to go all the way with service auth, you need to think about how safe your secrets are. If your code is shipping with the secrets, then you're really gunning for security by obscurity. Keeping secrets on disk is a security hole. Heck, even keeping plaintext secrets in memory is not fool-proof.
I liked the article, but generally speaking, you really do need a comprehensive solution to service-to-service auth if you want to go down that road, because taking shortcuts is going to just expose you to a ton of downsides without even attaining the upshot. And regardless of if you set up service-to-service auth, you really should be segmenting networks anyways for a host of reasons, and layering auth on top of that. So these two things are inter-related on some levels, but form a layered security approach together :-).