I had an interesting security conversation today, about network architecture. Hmm... don't run away just yet.
I think we'd all be agreed that it is safest to put your production networks away from your testing networks, and to make sure the data in your test areas is not live sensitive data - I'm not going to go over well trodden ground.
I also think most would agree that splitting web servers from applications and both from data is the way forwards, and using firewalls to split them out is only sensible. We may also split out external and internal DMZs on the internal and external firewalls, and of course our internal LAN. This is all stuff that can be found in books and on websites, of course.
But what of the relatively new worlds of web services and 'cloud computing'? I chuckled recently when these were referred to as Marketecture. In reality, these don't change anything about the way we build systems, in fact sometimes they are just making it unnecessarily complicated for the poor souls designing and building it.
Back to my interesting conversation though. Picture if you will a 3 tier network, external firewall with external DMZ hanging off it, and an internal firewall with the LAN and data tiers hanging off it. Where do you put the application tier?
My companion pointed to a case where it was also hanging off the internal firewall, and asked whether it shouldn't be attached to the external firewall as well. I argued the point that it didn't really matter as you could just punch a hole through the internal firewall anyway, but is that really such a good idea? No, not really, so I capitulated, and realised that that was in fact how I have always done it in practical terms, I'd just never really thought about it too hard until faced with the direct question.
The fact of the matter is, the diagrams we draw of these things are really only ever representative. I don't think I've ever seen a network diagram which could be used to trace a real physical network - to make the important decisions, yes - to dismantle and rebuild, no.