NSX's micro-segmentation capabilities essentially allow placement of virtual firewalls around every server to control East-West traffic, thereby limiting lateral exploration of networks by hackers, and making it significantly easier to protect applications and data. It can enable a level of security that previously would have been prohibitively expensive and complicated using traditional hardware.
From a security perspective, a greenfield scenario is ideal because it allows security to be baked in from the start and setting up micro-segmentation is relatively easy. From the outset, security teams can plan the different datacenter zones and tiers they need and assign IP addresses accordingly. They can then create bespoke security policies to support the segmentation architecture to precisely suit their needs. It's all clean and logical.
However, most organizations will likely face a brownfield scenario, where they are migrating existing applications from a physical to a virtualized environment. In these cases, existing security policies will need to be migrated and adjusted, but chances are the original design didn't have micro-segmentation in mind, making the process of identifying and designing the zones and tiers within the micro-segmented environments much more difficult.
It can be challenging to work out which servers should live in which zones, and to define the necessary firewall rules, because security teams often don't have adequate visibility into how traffic flows between application components. So how should you approach planning and managing the migration of brownfield applications to an NSX virtualized environment?
Application connectivity: a process of discovery. The critical first step is discovering and mapping the connectivity flows of the applications you wish to migrate. You need to know the existing flows in order to make the necessary changes when you migrate to NSX.
It's a challenging task that shouldn't be underestimated. Disciplined organizations that maintain accurate, up-to-date, machine-readable records of the traffic flows supporting each application can quickly start the migration process. In most cases, however, this discovery step will combine all available data sources: importing data from CMDB or home-grown repositories, machine-assisted discovery, and intelligent traffic-based application connectivity discovery.
Moving your applications to their new home. Once you have successfully discovered all the traffic flows, you are ready to migrate your applications to NSX. The first step is to identify the servers you need to move, as for each server you will need to define a matching server in the new environment.
To do this you should develop a mapping table, with a new IP address identified for each new server. At this stage you should also identify and define the workload for each server, covering the required storage, CPU, operating system and database. The next step is to install your existing applications onto the servers.
This involves reconfiguring the connectivity flows for every server that has been moved, as well as any servers and applications that might be connected to those that you have migrated. This will require some adjustments of your policies, and potentially writing some new policies so your NSX and on-premise environments can work in harmony, without disruption to your previously-discovered traffic patterns that work with the new server IP addresses.
Also, you will have to ensure the security controls and policies that are provided by VMware align with and support your existing application flows. If you don't do this, and you just rely on your old filtering policies, communication to your new servers could be blocked. You need to allow traffic to and from new addresses - and to do this it is critical you ensure that your policies, both in your NSX and on-premise environments, support this.
So you will need to go over every filtering rule in your network security equipment, discovering all the places where the servers' old addresses appear. Then you need to duplicate those rules, modifying them to include the new server addresses.
Once your new filtering policies are written, you need to deploy them to the relevant devices. This involves configuring firewalls, routers and load balancers to allow traffic to and from the new servers.
Testing to production. By this stage you will have a functional system which you can test thoroughly, to ensure all the required functionality is in place and everything operates as it should. You can only move on from this stage once you are confident the application in its test environment is equivalent to the final production environment.
Moving from test to production is essentially about renaming things: there may be a public name for the server, or a website that users need to access your application. You now need to reconfigure the official published access points to direct to your NSX deployment instead of the old server. It's also important at this stage to check whether you need to make changes to your filtering policy too.
Decommissioning legacy versions. The final stage is decommissioning the legacy versions of application connectivity - but don't do it before you're absolutely ready. Make sure your new system has had time to mature, is stable and is fully tested for an adequate time period. To avoid creating security gaps and entry points for hackers, best practice requires decommissioning all the filtering rules from your old firewalls, routers and load balancers. However, don't forget to check that these rules aren't still being used by other functioning applications in your NSX deployment, before decommissioning them!
Managing the network
Once you have completed the migration process you will need to manage and maintain the security policy across your entire enterprise network. The most effective way is with an automation solution that holistically supports NSX firewalls and cloud security controls, alongside your existing traditional on-premise firewall estate.
It's important to note that your NSX deployment will be subjected to the same compliance and auditing requirements as your existing network, so you'll need a security management solution capable of providing visibility across both your physical and virtual network functions so that its compliance status can be centrally monitored and logged for audit purposes.
Migrating applications to NSX is also a good opportunity to remove unnecessary security policy clutter that likely accumulated over the years, such as duplicate, redundant and unnecessary rules. A good security policy management solution will automatically flag any redundancies and other risks, making it easy to streamline and clean up your policies.
In conclusion, migrating applications to NSX requires strong, repeatable processes to ensure success. There is no silver bullet solution that can convert everything at the click of a mouse. Automation is critical to the success of the project, eliminating many of the time-consuming, error-prone manual security processes, such as connectivity discovery and mapping, migrating, and ongoing maintenance. And, as a result, your team will be freed up to strategically maximise the benefits of the NSX deployment and focus on maximizing the increased flexibility and enhanced network security that you signed up for.