In my previous post I explained why current security architectures aiming at inspecting all inline traffic via hardware appliances are failing to provide proper segmentation and scale in modern day data centers. As I described, this has nothing to do with the type of security technology being deployed but rather with engineering security services that can answer the requirements of scale, high bandwidth, micro-segmentation and distributed applications.
We have to remind ourselves why we are having these architectural discussions: the application and service landscape has been virtualized, generally in excess of 70%, while entertaining any cloud solution will force you down the path of moving to 100% virtualization. Yes, there are still physical servers and legacy applications to which we will extend security services to. But instead of being the norm, we now have to consider their place in the overall architecture as exceptions and design security and networking services around what makes up the bulk of the workloads, i.e. virtualized applications in the form of VMs and containers.
With this understanding, let’s discuss how years of deploying hardware security architectures have boxed us in a complex unidimensional, sequential approach to security policies and how we can now move beyond this implementation scheme with virtualization and the proper software tools.
Here is what I mean by a unidimensional and sequential approach. Consider the following high-level data center segmentation and let’s map a simple 3-tiered “blue” application to it:
We could represent logically the security processing required by this application as a sequence of perimeters regrouping endpoint systems linked by firewall policies:
Note that if these rules were implemented in a single firewall with no contextual implementation, they would form a single list to be managed globally. Now let’s add a “dimension” to these rules by allowing administrators to work on each servers of application “blue.”
As we can see, every firewall context or instance needs to be touched in order to add this simple policy. What if you wanted more “dimensions” such as:
- A common set of rules for all the web servers in any of our applications, anywhere they might be in our data center. For example in our diagram with the web servers of the ”blue” and “orange” applications regardless of the fact one reside in the DMZ and the other is located in the corporate zone.
- A security policy tailored specifically for Windows 2003 servers that would evolve as new vulnerabilities are uncovered.
- Making any application (ie any component making up the application) isolated from any other application in the data center by default.
Implementing compound security policies reflecting the multi-dimensional nature of an application has been a struggle for ever. When multiple contexts or physical appliances are used along the path, the problem is exacerbated with the distribution of these policies correctly and efficiently across them which quickly becomes an operational challenge.
A unidimensional, sequential approach to security policies has not proven to be the right tactic to support operational simplicity.
Multi-dimension in the virtual realm
First let’s make clear that I am not saying hardware security devices are not needed anymore. In the context of a data center, they are usually required on the physical perimeter, where all the North-South traffic converges on a single entry point.
With that said, how can a software defined environment address the problems described?
To illustrate this approach, we will use Horizon View, VMware’s VDI solution, as the application to secure. From a network and security perspective, it is a relatively complex application to deploy as some servers are accessed from the Internet while others are buried deep inside the data center and the virtual desktops often land in different security perimeters depending which user group accesses them.
The following diagram made by Ray Heffer (http://hub-apac.insight.com/h/i/130698224-network-ports-diagram-for-vmware-horizon-6-version-6-1-1/166576 ) gives you an idea of the interaction between the components in the Horizon View environment with minimally 4 perimeters to take into account: internal client networks, external client networks, DMZ and an internal network. A detailed list of the flows can be found in the Knowledge Based article “VMware View ports and network connectivity requirements (KB1027217)”
In the context of NSX, I will leverage Service Composer which creates “bubbles” meant to group dynamically objects based on workloads attributes independently of their IP address, VLAN or location. These “bubbles” can by nested, related to, independent or intersecting. Think of it as “Set Theory” applied to security.
First let’s lay out the environment we are going to work with:
The first step will be to group the significant pieces of the application that need to be secured. I will start by creating 3 groups based on the type of workload: one for the Security Servers acting as proxies facing the Internet, another for the Connection Servers acting as desktop brokers and finally all the virtual desktops that will be created. The idea here is that the View administrators can now add any of these services anywhere in the data center and they would be automatically added to their appropriate group.
Let’s do one last “bubble” to encompass the entire Horizon View ecosystem
Please take note that the objects and the groups have no references to the underlying infrastructure as they are not defined by their IP addresses, VLans, hypervisor technology, a specific data center, etc. These objects could exist in a single cluster, multiple clusters, multiple data center or even in a provider’s cloud.
Now that we have defined the larger perimeter as the actual Horizon View application, let’s have a look at what kind of flows need to cross the application-based boundary :
- An external client connecting to the Security Servers
- An internal client connecting to the Connection Servers
- An internal client connecting directly to its vDesktop (external clients are always proxied through the Security Servers)
- The Connections Servers authenticating the View Client to AD
- The Connection Servers connecting to vCenter to pick the vDesktop
- The vDesktops authenticating to AD
That’s it. 6 rules totals needed to make Horizon View work compared to the list of 75 rules in the Knowledge Base. Take note that there are no rules allowing Horizon View to communicate with any other application in the SDDC so the only East-West traffic allowed in our example is within the Horizon View “bubble” / perimeter itself, which I could restrict further if I wanted to by leveraging the nested “bubbles”.
The resulting “group policy” is then distributed and enforced on each member of the Horizon View “bubble”, micro-segmenting each element in its own security perimeter.
Let’s continue our example.
We still need to have this application managed by the proper “View Admins”. As any other users, the administrators would use a View Client to reach their vDesktop, then NSX Distributed Firewall would recognize them as part of the “View Admin” group in Active Directory and apply dynamically complementary rules to their vDesktops, allowing them to manage any of the elements inside the Horizon View “bubble” but also restricting them to these elements only.
Same goes for the regular users who would get additional rules pushed to each specific vDesktop based on their AD group membership.
As we can see, moving from a unidimensional, sequential, static set of rules to this contextual approach lets us apply security in a much more intuitive way by setting the perimeter around the natural boundary of the application, a desktop, a compliance scope or whatever else seems logical for these services, in total independence to any piece in the infrastructure.
Adding “dimensions” to the application now becomes easy because we approach the problem by functional groups rather than building complex compounded policies. For example, I can now easily set an enterprise-wide security context for “all the MS Win2003srv”, leveraging the OS-Type attribute of the VM to dynamically pick the members of the group, which would have automatically incorporated some of the servers in our Horizon View application.
In the past, this simple business need would have required to understand where all the Windows 2003 servers are located, which firewall fronts them and then copy adapted versions of the same rule set to accommodate the various IPs in each firewall. When some servers would be upgraded to a current version of Windows’ server, the same manual process will have to happen again while our bubble would just remove it from its list as it would not match the membership criteria’s.
Lastly, because the sum of these security groups is applied to each individual VM, we get the benefit of working with group policies and enforcing them at every vNIC, creating by de facto a micro-segmented perimeter of 1 machine everywhere in the data center allowing us to inspect all traffic may it be North-South or East-West.
“Complex security isn’t” – Bill Cheswick
Sequential, unidimensional security policies such as the ones we find in physical firewalls have proven to be operationally challenging for implementing the multiple dimensions associated with applications residing in our data center. Too often have we implemented shortcuts or sub-optimal controls because of the inherent complexity it created.
Network virtualization along with distributed virtualized security services (http://blogs.vmware.com/networkvirtualization/2016/01/vmware-nsx-and-split-and-smear-micro-segmentation.html ) offer new avenues by allowing us to regroup services with granular and meaningful boundaries rather than an IP range, a set of hosts, etc. with the direct benefit of lowering the overall complexity in the design of our security policies.
Group policies, granular enforcement at the vNIC, micro-segmentation to 1 VM, inspect all traffic, etc.
Welcome to the virtualized world!
Comments
0 Comments have been added so far