If your organization is considering or is already using cloud computing services, you may be using one of several...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
cloud deployment models.
First is the public cloud, in which a cloud service is provided via the public Internet. Next is a private cloud, whose infrastructure is designed for the exclusive use of a single organization and is typically hosted and managed by that organization. A community cloud can be provisioned for the exclusive use of a group of customers that have shared business interests and operational concerns (security or compliance, for instance).
Finally, there is the hybrid cloud, which is defined by the National Institute of Standards and Technology (NIST) Special Publication 800-145 as "a composition of two or more distinct cloud infrastructures (private, community or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability [e.g., cloud bursting for load balancing between clouds]."
Hybrid clouds are in effect a compromise: They can offer the "best of all worlds," e.g., the flexibility and availability of a public cloud with the focused resources, services and specialized security provisions of a private cloud. In this tip, we'll review hybrid cloud security best practices for the enterprise.
Hybrid cloud security issues
Security must be addressed at multiple points in a hybrid cloud environment. For example, security must be addressed at the points where data moves into and out of a cloud; security must also be addressed for data residing in a cloud. Data encryption is among the primary security controls. Before the implementation, decide if data is to be encrypted -- both at rest and in motion -- and then investigate if the cloud provider can accept your encryption requirements. Additional security considerations include determining if firewalls and other security devices are ICSA-certified; securing local data center services and applications; providing security to applications that link to public clouds, ensuring that data stored on more than one cloud environment are secure; and ensuring the security connecting mobile devices to your hybrid cloud. Techniques to achieve these goals include updating and strengthening firewall rules; expanding use of intrusion detection systems and other network monitoring devices to identify potential malicious code while in transit; review and update access policies and permission to prevent unauthorized access; authenticate the cloud resources and your own infrastructure before linking the two by using two-factor authentication, smart cards and verifying certificates; and even an open source virtual private network (VPN) that establishes a secure link between the cloud and the enterprise.
Due diligence when addressing hybrid cloud security should include a goal of achieving a level of parity -- from a security perspective -- between private and cloud infrastructures. If this is not possible, it may be necessary to define the security parameters of data sets and systems, and then check to see if the cloud service provider can accommodate your security specifications. Bear in mind that there may be security implications associated with regulatory compliance with certain applications, such as financial systems. Further, an organization's ability to proactively manage and impact its security position with cloud-based systems and applications will be a key consideration.
Security benefits and limitations of hybrid clouds
Hybrid clouds provide an appropriate "mix" of computing resources, so you can build the most efficient and cost-effective operating environment.
One example of a hybrid cloud is a joint activity with NetApp and Amazon Web Services (AWS) in which NetApp Private Storage for AWS enables enterprises to build a cloud infrastructure that balances private and cloud resources. Another example is an organization (e.g., a holding company) that offers systems and services for a variety of markets through individual organizations. Each organization will probably have its own unique service delivery, storage and networking requirements.
Another benefit of a hybrid cloud is the opportunity to leverage multiple resources to achieve the level of service and performance you require. You obtain and pay for only the resources you need for a specific requirement. In theory, this makes sense if there are a diversity of applications and other requirements, such as disaster recovery, that can be served by varying how each solution is delivered over one or more clouds.
But all this flexibility has its drawbacks. Hybrid clouds present security and management challenges because you now have many more resources over which you must provide oversight. For example, in a hybrid and/or multiple cloud environment, there are more opportunities for security breaches because there are more "entry points" into which malicious code can be delivered -- your network and your cloud providers' networks. Even assuming each cloud you use has first-rate security and perimeter protection, that's not a guarantee that data transiting between cloud perimeters is truly secure unless you employ some of the options we mentioned earlier, such as VPNs linking clouds and enterprise networks, strong firewall rules, robust data encryption and two-factor authentication.
Security professionals should constantly try to minimize the porosity of their network perimeters. Using a hybrid configuration or simply using multiple clouds only increases the potential for perimeter leaks to occur. You may also need multiple management systems to oversee the various cloud assets you are using. This may not only add to your overhead, but may also contribute to difficulty monitoring data flows and cross-network traffic for malicious code.
Another reason security with hybrid and multiple cloud environments is a challenge is because once you relocate systems and data outside your control, you will need to increase your diligence to ensure the cloud service provider's security controls are protecting your systems and data. It may not be enough to use your own monitoring tools; you may not be able to get sufficiently "inside" the other clouds to proactively monitor traffic.
Begin by determining in advance what your technical requirements will be, e.g., storage capacity, network bandwidth and latency, sufficient workload processing power. Next, determine how many different cloud resources you may need. See if you can reduce the number of cloud service providers by aggregating multiple workloads and requirements among fewer cloud providers; define your security requirements for each application in advance; provide these details to the cloud provider to ensure they can be met; determine what the data flows across cloud services will be and try and minimize these transits because they provide possible entry points for hackers and malicious code. Lastly, review the security capabilities of cloud services and ensure they are consistent with your requirements, and ensure cloud service providers use ICSA-accredited devices wherever possible.
Migrating an existing application running in a virtual machine from an enterprise environment to a similar VM in a public cloud sounds like a viable option. Check to see if the cloud environment is running a different hypervisor than VMware, for example. Further, determine what changes will be needed in the way you manage security, as you will now have more than one environment to manage that is not your own.
Assuming you can overcome potential security breaches and challenges to resource management, performance management and network management, hybrids can make sense. In a perfect world, a system should be running in the most appropriate environment, with the right resources for the job. The assumption is that a hybrid cloud environment can provide all the resources needed -- and when they are needed.
About the author:
Paul Kirvan is an independent consultant and IT auditor, as well as a technical writer, editor and educator. He has more than 25 years' experience in business continuity, disaster recovery, security, enterprise risk management and telecom/IT auditing, and more than 30 years' experience in technical writing/editing, technical training and public speaking. Mr. Kirvan has been directly involved with dozens of business continuity, security, IT audit, risk and telecom consulting engagements, ranging from operational audits and strategy definition projects to plan design and implementation, program exercising, execution and maintenance, and RFP preparation and response. Mr. Kirvan is currently a member of the board and secretary of the U.S. chapter of the Business Continuity Institute (BCI). He is also a Certified Information Systems Auditor and a Fellow of the BCI.