Traditional data centers are usually built in a very non-scalable fashion: everything goes through a central pair of firewalls (and/or load balancers) with thousands of rules that no one really understands; servers in different security zones are hanging off VLANs connected to the central firewalls.
Some people love to migrate the whole concept intact to a newly built private cloud (which immediately becomes server virtualization on steroids) because it’s easier to retain existing security architecture and firewall rulesets.
The traditional security architecture with few large security zones is inherently flawed – we’re usually forced to group servers from different applications in the same security zone regardless of the applications’ security requirements, its coding quality, or the level of server hardening.
The worst application in the set becomes the weakest link – once the intruder breaks into that application server, he usually has a free lunch within the security zone (unless you deployed strict layer-2 security measures – you did implement all of them, didn’t you?).
Why would we ever agree to use such a stupid architecture? Who said we agreed – we were forced by the physical limits of the VLAN-based architecture (4K VLANs, sometimes as low as 256) and firewalls (number of security zones and logical interfaces). Throw the usual IT silos in the mix and it’s obvious why it’s easier to add another (somewhat misplaced) server into an existing security zone than to ask the networking and security teams to create a new application-specific set of zones.
What you really should do when deploying applications in a private or public cloud is to make every application an independent tenant. The actual terminology and data objects you use don’t really matter – it’s important that each application gets its own independent set of security zones and its own firewall(s) with its own set of easy-to-understand rules.
The divide-and-conquer approach to cloud-based application security has obvious benefits. Each application becomes totally isolated from all other applications (apart from well-controlled inter-application dependencies); someone breaking into one application would have limited opportunities to attack other unrelated applications.
The drawbacks? There’s a “slight” management issue, as you’ll have to deal with tens or hundreds of small firewalls instead of a single hard-to-understand monstrosity. Also, don’t even try to go down this route with physical firewalls – you need virtual appliances that you can deploy under reasonable licensing terms (a license for a Palo Alto virtual firewall costs just a few K$), ideally based on the total consumed bandwidth, not on the number of instances.