Migrating your data center to the cloud – a network security perspective

The “cloud” is a hot topic in the network security world these days as many organizations want to take advantage of the many benefits that the cloud has to offer by starting to plan data center migrations.  Here are some of the more common reasons for migrating your physical data center (or at least some critical applications within the data center) to a virtual data center:

1. Improving disaster-recovery capabilities
2. Addressing regulatory requirements for keeping certain customers’ personal data in-country rather than offshore
3. Reducing operating costs

Regardless of the motivation, such a migration is a complex process that involves many stakeholders who oftentimes don’t speak the same language. One of the key teams involved in a data center migration process is the network security team. Let’s examine the process of migrating a data center from the perspective of the network security team.

Moving a physical data center to a private or hybrid cloud involves a repetition of four basic steps:

1. Select a server in the old data center
2. Create a clone of the server in the new data center
3. Make all applications that rely on the old server refer to the new copy (This is the step in the process at which the network security team must be involved. In order for business applications to use the newly cloned server, the network security policies on the relevant firewalls and routers must allow the necessary traffic to and from its new IP address.)
4. Shut down the old server

While these steps seem simple enough, the challenge is that you must perform these actions without disrupting existing services and without unplanned downtime. In fact, in a recent survey we conducted, more than two-thirds of organizations encounter application connectivity disruptions or outages during data center migration projects.

Why are outages or disruptions so common? It’s often unclear exactly which applications depend on a particular server in the old data center as servers commonly support multiple applications. Furthermore, it’s not always clear which other servers need to communicate with the server currently being migrated, and what ports and protocols should be allowed. The reason for the uncertainty is that in many organizations the record-keeping, indicating which applications depend on which servers, and what traffic flows support each application, is inaccurate, outdated, or simply non-existent.

It’s not all doom and gloom though as there is one reliable, often untapped source of information that always exists: the firewall policies themselves. After all, before any servers were migrated, all the applications were working – so, obviously, all the traffic flows they relied on were, and still are, allowed by some firewall rules.

By using the existing firewall rules, you can migrate a server without any surprises. First you can discover all of the firewall rules that refer to the old server’s IP address. Then you can  add the IP address of the cloned server to all the discovered rules (so the old and new servers can work concurrently). After this is achieved, the application engineers can reconfigure all of the applications’ components to use the new IP address – without fear that the traffic will be blocked. And once all the applications that rely on the server have been reconfigured and tested, it becomes possible to safely shut down the old server, and to remove all the references to its decommissioned address from the firewall rules.