We started talking about encryption in the Cloud in an earlier blog. We indicated that you could satisfy many compliance and privacy laws by “simply” encrypting everything in the Cloud. We described the three states that your data is in out in the Cloud: data-in-motion, data-at-rest, and data-in-process. This time, we’ll concentrate on data-in-motion.
In a typical three-tier solution, each transaction will normally go through three “tiers” or layers:
- Web Server to receive the message and determine which application server needs to handle it, and return the response to the sender.
- Application Server to actually process the transaction. Often there are multiple application servers involved in a single user transaction.
- Database Server to manage the database or files associated with the solution.
In most Cloud implementations, these different tiers are each implemented as multiple virtual servers running in one or more physical servers.
As we have said before, virtualization is one of the key technologies that enable the Cloud. Virtualization allows one physical server to be used for multiple applications, and in most organizations increases the utilization of a physical server from the 10-40% range to the 70-85% range. This saves lots of money, space, power and air conditioning. Many organizations have already virtualized all or most of their applications within in their own data center to get those cost savings, and I strongly recommend that the virtualization step be done before you move a workload to the Cloud.
Your data is in motion in the Cloud as it moves from your facility through the Internet to your Cloud Service Provider (CSP). It is also in motion as it moves around inside your CSP:
- From the edge of the CSP’s infrastructure where it joins the Internet to the physical server that first receives your message, usually in the Web Server tier.
- Between two physical servers as your message is passed among the different components of your application, either between different tiers or within a tier.
- Between two virtual servers inside the same physical server when two components share the same physical server, either between different tiers or within a tier.
- Between a virtual or physical server and the storage devices which hold your data, usually from the Database tier.
One of the biggest differences between a Public Cloud and a Private Cloud is how much sharing of physical resources is permitted. In a Public Cloud, your virtual servers are sharing physical servers with other customers. In a Private Cloud, only your virtual servers are running within a physical server – the physical server is “assigned” to you. Over time, of course, which physical servers that are assigned to you may change as your performance needs change.
In this post we will ignore the connections to storage, whether that be NAS (Network Attached Storage) or SAN (Storage Area Network). These two terms can be confusing, but for now we can consider them as just storage that holds your files and databases, along with those of the other customers of your CSP. Just like for servers, in a Private Cloud you usually have specific storage devices assigned for your use. In a Public Cloud you usually are sharing storage devices with other customers.
A communication between a workstation at your site and, for example, the virtual web server that will first receive the message at your CSP goes through many parts:
- From the workstation in your facility to your connection to the Internet.
- Across the Internet.
- From your CSP’s connection to the Internet to the physical server containing your Web Server.
- Through the hypervisor (virtualization) layer of that physical server to your Web Server virtual service (VM, for Virtual Machine).
How much of this path do you need to secure? That depends on the security requirements of the data you are sending back and forth. If you aren’t securing the network traffic within your own site today, you probably don’t need to secure it there when you move to the Cloud.
Some network security solutions:
- SSL (Secure Socket Layer):
You have used SSL when you buy something over the Internet. It provides usually good enough security from the workstation to the web server (1-4 in the figure above). It is very inexpensive, but it does add some noticeable overhead to establish the connection. For that reason it is really only useful for human-to-computer transactions – it has too much overhead to be used for high-volume computer-to-computer transactions. The use of SSL does not require the CSP to do anything – it is all in how your have defined your web site.
- VPN (Virtual Public Network):
VPNs are commonly used for mobile or home-based workforces. Your laptop connects to the Internet from the hotel room, in the airport, Starbucks, or from home. You then sign-on to your VPN and you have secure communications to your office network, just as if you were in the building. Many CSPs offer VPNs to cover parts 1-2 in the figure above. Of course, it does not protect you from the eyes of your competitor who is sipping coffee at the next table.
- IPSec (Internet Protocol Security):
IPSec is a popular form of VPN, often used between facilities where there is a high volume of traffic. In that case, there is usually a physical IPSec device at the edge of the two facilities to provide high-speed encryption / decryption without putting a workload on servers. In the case of the Cloud, your CSP will specify, and probably provide, the IPSec device to install in your network where it connects to the Internet.
New products come out periodically in this area, but most are based on either the SSL or VPN concept, or a combination of the two. Plus there are specialized products. The US Department of Defense uses HAIPE IS (High Assurance Internet Protocol Encryptor Interoperability Specification) to allow classified information to be securely transmitted over the Internet. HAIPE IS requires expensive physical devices to replace normal network routers, and adds significantly to the amount of network bandwidth required.
SSL itself is very simple to administer and is usually good enough for human-to-computer communications. However, VPNs need to be configured and managed. Failure to configure a VPN correctly often leads to network data being accessible to inappropriate devices, and these configuration errors are hard to detect.
Of course, customers and partners can complicate the options. If the communications are human-to-computer, than SSL is probably the right solution. If you are already using some VPN implementation to connect to partners or large volume customers, then you may have the complication of integrating that VPN solution into your CSPs VPN solution.
We haven’t covered what goes on inside your CSP after your message gets to the edge of the CSP (for VPNs) or the first Web Server (for SSL). Private Cloud providers often use VLANs within their facility to separate the components that “belong” to a specific customer. A VLAN (Virtual Local Area Network) allows a network to be configured so that only certain devices can talk to a specific set of devices. Depending on the specific product, that may protect traffic between physical servers (part 3 in the figure above) or virtual servers (parts 3 and 4). Configuring a VLAN is a significant effort. Every time a new server is added, or subtracted, from a customer, the CSP must reconfigure the VLAN. Failure to do that correctly is likely to leave your data exposed to others, and again these configuration errors are hard to detect.
All of these solutions treat each CSP customer as an entity – everything belonging to that customer is the same. That may be the way you are operating in your own site, but many IT infrastructures are divided, often by VLANs, into multiple sections based on the security requirements of the data. It adds significant complication to replicate that in a CSP. You will only be able to do that in a Private Cloud implementation, and you may actually have to implement multiple Private Clouds to get what you need.
There is a solution that can handle multiple security groups within one company, and which can handle parts 1-4 in the figure above plus communication between VMs or servers within the CSP: the Unisys Stealth Solution for Network. Stealth implements what it calls “communities of interest” based on the identity of the user or server, and only permits communication between physical or virtual devices that share a community of interest. The encryption is very strong. It is easy to manage since it is driven by the user’s identity without any separate network configuration requirements. Stealth enables secure network traffic under the customer’s control.
The last word:
Don’t spend more on data-in-motion encryption than you need to. Security requirements vary depending on what data is included. You need minimal security, and probably none, on data accessed from your public web site. For customer-specific transactions, SSL should be sufficient; and everything else needs nothing. For sensitive transactions involving your confidential information or other protected data, choose the mechanism that provides the appropriate level at the lowest cost. As always, the key is specifying your real requirements and understanding how your CSP will meet them, and getting that all in the contract. If your CSP doesn’t seem to understand what you need, you are either not talking to the appropriate people at the CSP or you are talking to the wrong CSP. In the later case, say “thanks” and move on.
Next time, we will talk about securing Data-at-Rest in the Cloud.
Keep your sense of humor.