Divide and conquer: multidimensional security policies
Current infrastructures to ensure infrastructure security, which are aimed at controlling traffic using technical means, cannot provide the necessary segmentation and scaling in modern data centers. Support for any cloud solution requires 100% virtualization, while the scale of application and service virtualization today does not exceed 70%. Yes, there are still physical servers and legacy applications to which the same security policies should be applied. But instead of taking this state of affairs as the norm, we should consider them as exceptions to the general architecture, and develop a security structure around what makes up the bulk of the load, that is, around virtualized applications in the form of virtual machines and containers.
This is what is meant by such a one-dimensional and consistent approach. Consider an example of segmentation of a high-level data center and outline a simple three-level scheme:
We could logically present the security that is needed here, as a sequence of perimeters rearranging the end systems connected by firewall policies:
Note that if all these rules were implemented through a single firewall without contextual implementation , they would form a single list that could be managed globally. Now let's add a “dimension” to these rules, allowing administrators to work on each server.
As you can see, in order to add this simple policy, every firewall or entity must be affected. What if other “measurements” are required, for example, the need to make any application (or application component) isolated from any other in the default data center?
Implementing complex security policies that affect the multidimensional structure of the application is extremely difficult. When multiple entities or physical devices are used together, the problem is exacerbated by the correct and efficient distribution of security policies to them.
A one-dimensional, consistent approach to security policies has not established itself as the right tactic to support operational security.
Multidimensionality in Virtual Space
We are not saying that safety equipment is no longer needed. In the context of data centers, they are usually required for the physical perimeter, where
What then should be with the described problem in the context of a
To illustrate this approach, we will use Horizon View, VMware's VDI solution, as a security application. From a network and security point of view, this is a rather complicated application for deployment, as some servers can be accessed from the Internet, others are buried deep inside data centers, and virtual desktops are often located at different security perimeters depending on which user group appeals to them.
The following diagram gives an idea of the interaction between components in a Horizon View environment with at least
In the context of NSX, we will use Service Composer, which creates “bubbles” designed to group objects depending on the attribute of the workload and regardless of their
To begin, let's look at the environment with which we will work:
The first step is to group the relevant parts of the application that need to be protected. We will create 3 groups depending on the type of workload: one for Security Servers acting as proxies to the Internet, another for Connection Servers acting as desktop brokers, and finally for all virtual desktops that will be created. The idea here is that administrators (View admins) can now add any of these services anywhere in the data center, and they will be automatically added to the appropriate groups.
Let's make the last bubble to cover the entire Horizon View ecosystem.
Please note that objects and groups have no links to the underlying infrastructure, since they are not identified by
The resulting group policy is then distributed and executed for each participant in the Horizon View bubble,
Let's continue. Our application
The same goes for regular users who would like to receive additional rules for a specific vDesktop based on their participation in AD groups.
As we can see, the transition from a one-dimensional sequential static set of rules to this contextual approach allows us to apply security in a more intuitive way by setting the perimeter around the natural borders of the application, desktop, or anything that seems logical for these services, completely independent of any another piece of infrastructure.
Adding “measurements” to an application becomes easier because we approach the problem from the side of functional groups, and not from the point of view of creating complex security policies. For example, now you can easily set corporate security rules for “all MS Win2003srv” using the
In the past, this would require understanding where all the Windows 2003 servers are located, which firewalls they are closed on, and then copying adapted versions of the same set of rules to host different IPs on each firewall. When some servers are updated to the current version, the same manual process will occur again until our “bubble” simply removes them from the list, as they will not meet the membership criteria.
Finally, since the sum of these security groups is applied to each individual virtual machine, we benefit from working with group policies by
Comprehensive Security As It Is
Consistent one-dimensional security policies, such as those we find in physical firewalls, have proven to be functionally difficult to implement various aspects related to applications located in the data center.
Network virtualization with distributed virtualized security services offers new possibilities, allowing you to rearrange services rather than a range of