Tips on Connecting Private/Public Clouds, Part 2

In last week’s posting, we focused on the private cloud.  Let’s talk about the public cloud now.

In a public cloud, the infrastructure is shared and the location of that infrastructure may be unknown.  The customer has no physical access to the infrastructure.   Its data may be stored on a dedicated disk, but most likely it is not; everything is virtual.  So the data is on a virtual disk and it appears isolated from other companies’ data, but physically it’s probably hosted on a very large array of disks set up in batteries of RAIDS shared among all the customers using that facility.   The same happens for the servers, the switches, the firewalls and anything else being used in this infrastructure.  Nothing is really as it appears; everything is virtual and shared.

This of course allows much greater savings than the private cloud, because a single physical server can be shared among several customers, and the same goes for disks and any other resource in the datacenter.  There is no private cage with reserved racks and computers; everything is shared and the only thing that keeps things isolated from one customer to another is the VM software running the virtualization.

Companies offering this solution have adopted different business models.  Some offer redundancy and backups included in the cost of the servers; some do not.  Some companies are truly virtual in that the server’s location may be unknown; some specify precisely where the server is.   Some companies rent out a physical server per customer, defeating in a way the scope of virtualization and going back to the rented physical infrastructure of many years ago.

Then there are several companies that have come up with software to measure the actual use of resources, so that customers can be billed based on the actual use rather than on a reserved amount of CPU or disk that they may never have used fully.  Since the resources are shared, they are dynamically allocated to the various customers, and therefore allowing each customer to pay based only on actual usage seems like a fair business model, which helps reduce costs for the customers even further and making the provider economically more competitive.

With the public cloud you get away from having to deal with hardware altogether.  No more hardware costs, amortization, obsolescence; no more A+ certified personnel to maintain that hardware; no more technical issues to deal with.  Outsourcing is not new.  But this is a form of total infrastructure outsourcing that makes a lot of sense for basically anyone.  The private cloud model defeats the purpose, as it implies maintaining the same old model of having to deal with hardware issues in house.  The advantages are too little when the savings of not having to deal with hardware are not properly realized.

Leveraging the cloud in its true sense can only be achieved using the public cloud; delegating entirely the issues of hardware to an infrastructure in the cloud vendor and getting away completely from having to deal with any hardware issues.

Nevertheless, since private and public clouds are a reality, how do we connect private and public clouds? The only logical way is via a VPN.

Too many companies, especially small companies, are connecting to their public cloud via remote terminal connections.   This is not safe; unless you can set your firewall rules to allow only specific source subnets, using RDP means exposing a Windows login to anyone.  And hackers have all the time in the world to attempt breaking that login.   Your protection in such case is only as strong as your weakest password.  Such logins should not be open to the public; it should be protected behind a VPN.

A site-to-site VPN is typically built using IPSEC; although devices such as Network Box nowadays support site-to-site SSL VPN, which in my opinion works much better.  Eventually, as more and more vendors start supporting site-to-site SSL VPN, IPSEC will disappear; it is clunky and messy, routing through it is not the simplest thing, and it is sometimes rather unstable.  SSL has none of these issues, and provides numerous advantages.  It is very stable and routing is very simple.  You can even set BGP through an SSL VPN; large networks that use dynamic protocols internally can take full advantage of this possibility, which is not so simple (if not impossible) with IPSEC.

Depending on the type of services hosted on each side, remote access software such as Citrix should be considered as well.  It offers adequate security, nice wire speed, simplicity in its set up, and although it shouldn’t replace the VPN option, it can certainly complement it at least for users who do not have a need for complete access to a network but simply need to access a handful of applications.  There are many competitors emerging, thanks to the cloud offers.

To connect the customer premises to the private cloud a VPN can be considered as well, though many companies are adopting other options, such as MPLS.  This creates a private connection from the office to the private cloud, and ensures security of the communications.  But it cannot usually be adopted to connect to the public cloud because in that case the Internet link is not under the control of the customer but is provided as part of the infrastructure by the hosting provider.  Therefore VPN is basically the only real option.

Got any questions on private/public cloud security issues? We’re more than happy to address them – contact us.