By Michal Grzeszczak, Senior Consultant, XtravirtAs a Senior Consultant at Xtravirt, I recently spent time with a customer, a major European airline, to plan and oversee the deployment of VMware NSX®. In the aviation industry, a data breach could have catastrophic repercussions. Concerned about data security, the customer chose VMware NSX for its security capabilities. This is because NSX allows for micro-segmentation, a practice through which workloads are individually cordoned off to prevent any East-West movement in the event of a breach. In contrast to most IT networks, where one firewall protects the entire perimeter, a breach in a micro-segmented network can only impact a small subset of data. With the objective to increase environment security and control East-West traffic, the project was managed in five key phases: Phase 1 – Discovery and Planning Xtravirt kicked off the project with a 2-day planning workshop with key technical staff and subject matter experts. In this phase we confirm and capture the full scope of requirements and ensure we fully understand the current environment. This process reveals any prerequisites, potential roadblocks and validates the use case. In this instance, the customer has two data centres, one vCenter Server (version 6.5) and uses vRealize Network Insight (vRNI) to monitor their environment. During the initial discovery phase, it became apparent that vRealize Network Insight (vRNI) could be used to better understand East-West traffic and to map the customer's applications to the security policy that could be provided by NSX Distributed Firewall (NSX DFW). Both solutions, vRNI and NSX DFW, are quite unique in the market and help solve many typical problems associated with securing workloads in modern data centres. In this instance, they helped to: - gain a better understanding of the flows of the applications, how they communicate with the outside world as well as within the application itself - secure East-West traffic and avoid reliance on the perimeter firewall to segment those workloads. Phase 2 – Installation and configuration of vRNI The installation and configuration of vRNI onto the customer's environment involved adding the "Data Sources" to the vRNI, where the data (flows) would be collected. There are many data sources supported by vRNI, including for example - vCenter, NSX-V, NSX-T, as well as third party devices like Cisco, AWS and Arista. A list of supported solutions can be found here: https://docs.vmware.com/en/VMware-vRealize-Network-Insight/3.6/com.vmware.vrni.install.doc/GUID-4BA21C7A-18FD-4411-BFAC-CADEF0050D76.html After adding the necessary sources, vRNI collected all the flows for a 30-day monitoring period. Other VMware solutions such as Application Rule Manager, allow for a maximum of 7-days monitoring and provide a great option for small applications. However, vRNI's 30-day monitoring period is especially useful when applications in the environment are particularly active during specific times, like a payroll application. Phase 3 – Defining workloads The next step was to define which workloads were part of which application. In this particular case, we had 4 main requirements: - micro-segmentation of Application "A" which consisted of 3 tiers. Each tier needed to talk to other tiers only on needed ports, thus securing flows within the application. - micro-segmentation of Application "B" which consisted of 3 sub-applications. The goal here was to secure traffic between sub-applications and not within each sub-application. - mapping of the shared services (active directory, monitoring etc.) that are necessary for the applications to function properly. - mapping of the users that need access to those applications. As the users and shared services communicate with all applications in the environment, we started with the first two requirements. It is very easy to create a logical application in vRNI. You simply add workloads to the tiers that make each application. In the case of Application "A", the action was to create three tiers, each with corresponding workloads. In the case of application "B", even when dealing with multiple applications, the process was the same as the requirement was to secure Inter-Application flows. We simply added workloads from each sub-application to the corresponding Tier in vRNI. Phase 4 – Security planning The next step was to go to the "Plan Security" section of vRNI and select our new logical application. That presented us with a "pizza" view of the tiers of the application, in both application cases. We then selected each tier of the pizza/application and extracted incoming and outgoing flows to a .csv file. This part of the application mapping can be done directly in vRNI. However, due to the complexity of the applications, we needed to view these flows in an Excel sheet. The most time-consuming part of the implementation at this point had been to map flows from vRNI to the design document section for security rules / security groups / IPSets in NSX DFW. Use of filtering options in Excel and colour coding the types of traffic allowed us to have a clear visual representation of the flows in the environment. We divided the flows into Shared Services, Inter-Application communication between applications that we were mapping, Intra-Application communication between workloads that we were mapping as well as user access. Phase 5 – Application Mapping Establishing communication between mapped applications and unmapped applications is the final stage. Under the scope of the engagement our role was to map 2 out of 70 applications. Our role as consultants was to ensure knowledge transfer and develop a repeatable process so the customer could complete their own application mapping. Once the whole environment is mapped, then Security Groups / IPSets in DFW can be created for all applications. Specific rules will be put in place to cover necessary flows between applications. During the process of application mapping we were able to get necessary information about Shared Services and Users. The former was mapped into a separate NSX DFW section on top of all the other sections to be checked by DFW first (rules in NSX DFW are checked top to bottom). These sections will need to be constantly updated as more applications will be mapped and will require additional ports to be open to communicate with Shared Services. The latter was divided into floors, buildings and countries with corresponding IPSets to provide more controlled access. Those IPSets were added to two Security Groups - "Super Users" and "General Users" and were added to each application's section to allow for management traffic. Conclusion By scoping out the project with the customer from the offset and having a clear and concise goal in place we were able to decide on the right tools for the job and move forward with minimal stumbling blocks. vRNI gave us a clearer picture of the road ahead and defined the East – West traffic that needed to be segmented and controlled to ensure that any potential data breaches could be stopped fast and with minimal leakage. vRNI and NSX DFW created the perfect combination for a creating a market leading security solution and better still working to a planned and repeatable process made the whole operation smooth from beginning to end. Find out more If you would like to learn more about how Xtravirt can help you improve the security of your IT environment, contact us and we'd be happy to use our wealth of knowledge and experience to assist you. Xtravirt (www.xtravirt.com) are the VMware Global Services Partner of the Year and have achieved the VMware Master Services Competency for Network Virtualization – a testament to our expertise in delivering NSX environments. About the author Michal Grzeszczak joined the Xtravirt consulting team in September 2017. He has an in-depth understanding of NSX along with experience in software-defined networking, virtualization and data centre support.
via Latest imported feed items on VMware Blogs https://ift.tt/2Oz1Oi3 | 
Comments
Post a Comment