Q&A: Moving Between Cloud Technologies
Moving from private to public or hybrid clouds can be risky. These best practices can help you avoid common traps.
Many organizations start with private clouds, then move to a public cloud (or adopt a hybrid mix). That move can be filled with risks, especially regarding security -- and once you have a public/hybrid cloud in place, what new skills does IT need to manage it? To learn about the problems and best practices from moving between cloud models, we contacted Andrew Hay, chief evangelist at CloudPassage; the firm's Halo cloud server security platform is used to safely deploy servers in public and hybrid clouds.
Enterprise Strategies: Why do organizations start with private clouds, and what's driving them to move to a public or hybrid model?
Andrew Hay: The private cloud architecture most closely emulates the standard on-premise server and application deployments that organizations have become accustomed to. In most cases, it's quite easy to migrate from an organization's data center to a third-party hosting provider without having to fully redesign system architectures. As with traditional data centers, pricing is often fixed with little fluctuation or opportunity for cost savings.
Public and hybrid clouds offer the opportunity for organizations to shift some of that CAPEX to OPEX, and only spend money on the servers and applications as they are used -- similar to utility billing for electrical power. This utility-billing model allows organizations to spin up servers for small and relatively short-term projects without having to pay the usual monthly or yearly fees often associated with physical server or private cloud instance hosting.
What are some of the potential problems they face?
When organizations migrate from on-premises to private cloud, many of the same technical controls are migrated as well (e.g., antivirus, firewalls, and other host security tools). These continue to work in private clouds because they were designed for relatively static environments with little change in operating roles and responsibilities.
Public cloud, however, presents several nuances that directly impact the way traditional security tools operate. Traditional security tools were created at a time when cloud infrastructures did not exist. Multi-tenant -- and even some single-tenant -- cloud-hosting environments introduce many nuances, such as dynamic IP addressing of servers, cloud bursting, rapid deployment, and equally rapid server decommissioning, which the vast majority of security tools cannot handle.
Why is perimeter security not sufficient for protecting a private cloud?
Perimeter security tools were invented as a way to provide the broadest protection at a minimal cost, whereas endpoint security tools were designed to protect the individual host from threats. Consider the example of the umbrella versus the rain suit. Both are adept at protecting you from rain, but deploying an umbrella, though easier and less expensive, often presents a far greater likelihood that your pants might still get wet from errant raindrops. The umbrella provides surface-level protection but, by way of its design, can usually protect your torso and head, and that's if the wind isn't a factor. The rain suit, on the other hand, provides complete protection for the person. Their clothes are dry and both hands are free to perform other tasks.
Network security tools are good at protecting as much as possible (with a technological umbrella) but protecting the host itself (with a technological rain coat) provides far better security.
Also, in the case of a third-party private cloud, you may not even own the technological umbrella. Your organization may find itself at the mercy of the cloud provider's tool-selection criteria and the way it is deployed -- likely without any input from you, the customer, about how the tools must be tuned to align with your organizational security program.
Shouldn't it be easier to go hybrid after starting with a private cloud?
Unfortunately, organizations use security tools that simply cannot adapt to the dynamic nature of public clouds. In a perfect world, organizations would purchase tools with portability as a core architectural function -- allowing them to seamlessly move between physical and virtual servers, in addition to public, private, and hybrid cloud architectures, without having to worry if their chosen tool worked on server x on cloud y.
Because most organizations probably languished over long and expensive projects to select their current tools, most try to shoehorn said tools into cloud environments. However, they quickly realize that the tools function incorrectly or, in the worst cases, stop functioning altogether in their chosen environment.
What are the ramifications of trying to transition security controls from private to public?
The technical nature of public cloud-hosting environments makes them more difficult to secure. This may simply be due to the age of cloud technology -- still an infant by technology standards. This means that we do not yet have industry-accepted practices or as many tools designed to handle the environment.
A technique sometimes called "cloud bursting" can be used to increase available compute power extremely rapidly by cloning virtual servers, typically within seconds to minutes. That's certainly not enough time for manual security configuration or review. Although highly beneficial, high-speed scalability also means high-speed growth of vulnerabilities and attackable surface area. Using poorly secured images for cloud bursting or failing to automate security in the stack results in a growing threat of server compromise and nasty compliance problems during audits.
Traditional firewall technologies present another challenge in cloud environments. Network address assignment is far more dynamic in clouds, especially in public clouds. There is rarely a guarantee that your server will spin up with the same IP address every time. Current host-based firewalls can usually handle changes of this nature, but what about firewall policies defined with specific source and destination IP addresses? How will you accurately keep track of cloud server assets or administer network access controls when IP addresses can change to an arbitrary address within a massive IP address space? Also, with hybrid cloud environments, the cloud instance can move to a completely different environment -- even ending up on the other side of the firewall configured to protect it.
When moving from private to public cloud architectures, companies need to have a better understanding of how their data will be segregated, in addition to the technical security controls that are available to them. The tools they have relied upon for addressing on-premises security concerns might not be built to handle the nuances of cloud environments. There are some things to keep in mind when looking to secure cloud environments. Primarily, organizations need to ensure that their chosen tools can be built into their cloud instance images to bake security into the provisioning process. Vulnerabilities should also be addressed prior to bursting or cloning cloud servers, and changes should be closely monitored to limit the expansion of the attackable surface area. Finally, the security tools used should be designed to handle the dynamic nature of cloud environments without disrupting operations or administrative access.
Once an organization has created a private cloud, doesn't that give them the experience they need to work with a public or hybrid cloud?
Not necessarily. If the organization operated their private cloud as they would a data center, they may have never experienced the elastic and portability capabilities and concerns offered by cloud environments. Also, if organizations felt that their data was safe because it was "their cloud," the shock of operating in a multi-tenant public or hybrid cloud environment might present numerous concerns about the security of data as well as the separation of duties and responsibility between the provider and the organization.
Once an organization has moved to the public/hybrid cloud, what skills does IT need to manage this technology? How is it different from managing a private cloud?
IT will need to extend their existing processes, procedures, and tools to manage servers in public and hybrid clouds -- especially those for monitoring and provisioning. The organization will also need to be conscious of their utility-based bills to ensure that they're not hemorrhaging money on an architecture that may have been implemented to cut costs in the short-to-medium term.
Security becomes a big concern as the organization's infrastructure is no longer constrained within its own sandbox world. Organizations need to understand the security implications of operating in cloud environments, especially that network-based controls no longer exist.
A private cloud allows organizations to replicate much of their standard processes and procedures, in addition to its existing tools. Public and hybrid clouds, on the other hand, change the rules of engagement, and documentation and tools need to be updated or adjusted accordingly. In the case of tools, organizations may need to look outside of their current tool belts to extend their security and management capabilities.
What compliance issues need be considered migrating to public from private?
As with any architecture, concerns about the transmission, storage and gathering of personally identifiable information (PII), health records (HIPAA), and payment card industry (PCI) information are of paramount concern, particularly given the nature of the mandated fines and penalties for non-compliance.
The multi-tenancy and shared data environments of cloud providers need to be heavily scrutinized and proof of adherence to regulatory mandates is also extremely important. That way, organizations can show their auditor where their responsibility ends, and that their provider can attest to the compliance of their infrastructure.
What products or services does CloudPassage offer that addresses the issues we've discussed?
CloudPassage's Halo cloud server security platform provides a broad set of security capabilities critical to protecting application, database, and analytics servers. With Halo, dynamic cloud firewalls, multi-factor authentication, configuration security monitoring, server access management, server intrusion detection and more can be deployed in a matter of minutes. Halo provides an easily used Web interface and a rich set of REST APIs enabling deep integration with other management and security tools.
Because Halo is delivered as a security software-as-a-service, no hardware or server deployments is required. It deploys using standard server software deployment modules like yum, apt, Chef, Puppet, and RightScale. Halo provides users with pre-defined starter security policies to speed deployment. Full support is provided during the free 30-day trial period.