Right, if Francois Zimmermann is in no mood for sharing his Heinz baked beans with the imminent threat of Doomsday, then fine, I will get my own tin of beans and get on with my survival strategy. This, you may recall from my previous blog, is about creating a multi-tier application blueprint using NSX with Hitachi Enterprise Cloud (HEC) which plays an important role in securing your data from potential everyday hackers let alone those in a Doomsday threat. This is where I get into the technical detail especially around micro-segmentation? More of that later.
The “Micro” in Micro Segmentation
To create a more secure environment than a traditional DMZ we would have to change the DMZ from being traditional, monolithic and predefined structure into one that is more flexible, agile and dynamic.
Micro segmentation is a well used term when it comes to network virtualization, but what does it actually mean? It stands for a way to permit traffic from one instance to the other, even if they are on the same network with the same IP address.
You can think of micro-segmentation as isolation of workloads on the same network. As an example, typical networks are like trains, you can move from one carriage to another carriage within the same train easily. Micro-segmentation is more like cars on a highway. All are driving on the same highway in the same direction (more or less), but changing from one car to another while moving is almost impossible.
If you think of this network with a given IP subnet as a segment, typically every server within that segment can talk to each other. So traditionally, you had to separate an entire segment in order to prevent one server in segment A talking to another server in segment B.
While servers in the same segment, like Server A1 and Server A2 can directly “talk” to each other.
Now, in the software defined world this is all “snow from yesterday” (sorry – famous Austrian saying which means – Old News). With the new capabilities of dynamic firewalling and policy based VM security profiles, we could achieve a similar outcome without putting the servers in two different networks.
In this case, the firewall would be acting as if it might sit right in between the two servers, allowing only specific protocols to connect to the peer server. In some cases, communication can be terminated entirely to any peer server, which is often used in desktop environments.
A micro segmented network might look like this:
Now in this case, Server A is only allowed to talk to Server B through a firewall, using specific ports to communicate. All other direct communication is prohibited. This makes the management easier since you can add a security layer even if servers are running in the same network. The big benefit is, that this security layer can be managed centrally and applied on demand to any group of servers.
So what does all of this mean for our “Micro DMZ” project? Everything!
The first step is to setup up one DMZ per service. A service might be any WEB server and DB server pair or similar. In a traditional datacentre you might use a static DMZ and place the WebServer there and then place the DB server in an internal network. But as described in part 1 of my blog series, there might be a more secure way of doing that.
And this is where “micro” comes into play. Instead of creating a big DMZ housing everything exposed to the internet, we are creating many small DMZs. One for each service. The service itself does not need to know anything about that, since the software defined infrastructure takes care of setting all the rules and routes in order to work properly.
Tip: If you want to see all the techy details and want to get a crash course in subnet calculations (what was /24 again?) visit this technical part of this blog
Now, when a new service is rolled out, it gets its very own DMZ and firewall rules. With the use of micro segmentation within the DMZ – web servers cannot talk to each other but they can talk to their DB server peers. This makes the DMZ itself more secure. Also, since each service has its own DMZ, a security breach will never affect other services, indeed it might very well only affect the very Webserver experiencing the security flaw.
With this technology, you can limit the impact of a security breach from being catastrophic to just being slightly annoying at best.
So are we now in Lock Down?
In a Doomsday scenario, instead of the rebels rushing into my shelter and stealing and breaking my stuff, they just get a glimpse of my security fence. If they manage to break through that, they see…
…wait for it…
Another security fence
The use of multiple DMZs and micro segmentation within those DMZs is enhancing the security layer significnatly. Everything is managed from a central instance so no micro management (pun intended) for the micro segmentation is needed. If we run through the technical part of this configuration and finish all of the step by step configuration items we are nearly done reaching the final solution. If the configuration of the blueprint is completed successfully, everything should automatically unfold in our Hitachi Enterprise Cloud solution, again, saving us a ton of time and effort for every new deployment of a service. Also, with every additional new service deployment the security is enhanced, not diminished!
Meanwhile, I’ve worked up an appetite so I need to crack into my stock of baked beans whilst the tests run. I’ll be back later with the results and take you through some seriously deep dive technical actions which makes the magic unfold and finally get us into secure lock down.
I wonder how my buddy, ole Mr"Get your own beans" is getting on with his NSX shelter? Is it secure enough to protect his services from the latest ransomware madness?
Which leaves me to ask, "What are you doing to enhance your security for your new or existing services?"