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 North-South traffic converges into a single point.

    What then should be with the described problem in the context of a software-defined environment?

    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 4 perimeters that should be taken into account: internal client networks, external client networks, DMZ (demilitarized zones) and the internal network.



    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  IP addresses , VLAN or location.

    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  IP addresses, VLan, hypervisor technologies, a specific data center , etc. These objects can exist in one cluster, several clusters, several data centers, or even several cloud providers.



    The resulting group policy is then distributed and executed for each participant in the Horizon View bubble, micro-segmenting each element into its own security perimeter.

    Let's continue. Our application is stillmust be managed by a specific administrator (View Admin). Like any other user, administrators will use the View Client for their vDesktop, then the NSX Distributed Firewall will recognize them as part of the View Admins group in Active Directory and apply dynamic rules to their vDesktops, allowing them to control any elements inside the Horizon View bubble , but also limiting them only to these elements.



    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 “OS-Type” attribute of the virtual machine to dynamically select group members.



    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 creating a de facto micro-segmented perimeter of 1 machine everywhere in the data center, allowing you to check all traffic.

    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 IP addresses , a set of hosts , etc. , and also provide the benefits of reducing the overall complexity of developing security policies. Group policies, micro-segmentation for one virtual machine, traffic inspection .... All that.


    Also popular now: