Well - I was just testing a new application blueprint in our solution center in the Netherlands when Francois Zimmermann threw me a blog about the Doomsday clock - and that I shouldn't bother getting it to work, since there might not be a next quarter to enjoy it...
Well - while he was shopping for his favourite Heinz baked beans, I was thinking about some automation possibilities using our Hitachi Enterprise Cloud with VMware's NSX. If you now wonder how in the world I can think of automation if Doomsday is imminent, let me explain my slightly geeky line of thought...
If Doomsday ever comes, the chaos outside will be massive. There´s likely to be de-militarized zones set up sooner or later to mark the boundaries between a secure community and the chaotic, dangerous outside world where gangs may roam and rule the empty lands.
Ok - this might be a bit of an over dramatic and depressing thought but in the digital world this is already happening.
The digital Doomsday world
Today it is quite dangerous to expose any of your servers straight to the internet. This is why it is not only best practice but actually crucial to have a so called DMZ (Demilitarized Zone) where the internet exposed servers of any datacenter live. This DMZ is typically secured by a firewall externally to the internet and one internally to the inner datacenter which is the secure community. So if you want to prevent being in the news as the "worlds biggest bot net provider", it is essential that web servers are secured and only accessible for their intended use case.
However, there is one problem with this DMZ concept. The more servers there are accessing the internet, the bigger the DMZ needs to be. One of the difficulties with this concept is, if somebody (a gang) is able to break into the DMZ and compromise one of the servers, they basically have access to the entire DMZ. From there it might only be one step away from entering into the datacenter core network. Or, they simply enslave all the DMZ servers to run DoS attacks for the highest bidder against any given target.
Now, this is not so much a sci-fi scenario. We hear about hacks, data leaks and security breaches nearly every week in the digital world. Since this world is getting more and more complex, managing a DMZ has grown from an occasional task to a highly critical full time job. If something goes wrong in the DMZ security, the Doomsday clock for any company might strike 5 minutes PAST midnight instantly.
Ok, so what could the Programmable Data Center do for me to change that? Everything!
The Programmable Data Center to the rescue
Lets imagine that each service which needs to be directly exposed to the internet has its own DMZ. In fact, it is a micro
DMZ only valid for the web server (ie. exposed to the internet) components of the service, while the Data Base (DB) server or the data components will still live in the secure internal network.
Lets further assume that these micro DMZs are created only if a web application is deployed. Plus, they are not able to access other DMZs. In fact - they do not even know of other DMZs (no routing tables, etc...).
That would elevate the security for a DMZ tremendously, since the so called attack surface is much smaller. If one of the micro DMZ's is compromised, it is only the few servers in there which can be taken over and not all the servers as in a traditional DMZ.
Ok, got it but how would someone do that? The effort in creating all these micro DMZs on demand, managing and controlling them would be monumental compared to a single DMZ. Who should take care of all of that? Well, you might already have guessed the answer:
Hitachi Enterprise Cloud (HEC) with NSX can do that for you.
This got me thinking, so I started to create a blueprint in HEC which does exactly that. It includes a Web Server component which will be exposed to the internet and therefore lives in a micro DMZ. Additionally, it has a DB server component which will live in the internal datacenter DB network. The Web Server can access the DB server only through a firewall to get valid data for its queries while the DB server can't access the DMZ at all. Also, the Web Server will get its own external IP address in its own external subnet which assembles its micro DMZ.
I was keen to get started modelling this in NSX and then creating a blueprint using this functionality. However, I was still concerned that Doomsday was rapidly approaching and I needed to check in with Francois Zimmermann and see if he might share some of those favourite Heinz baked beans with me. Should I survive Doomsday, you will catch my next part on what techniques I use in HEC with NSX in my blog. Hang in there....