Let’s assume you’re a security engineer working for a service provider and your organization has just decided to roll out its first cloud computing service. The good news is that cloud security mechanisms aren’t much different from the traditional enterprise or service provider security solutions. The bad news is that “cloud services” can be anything from a virtual colocation business, to access to shared storage, to Web-based applications.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
For that reason, discussing generic cloud security makes no sense, but talking about multi-tenant cloud security for a range of cloud services does. One of the fundamental building blocks of a successful cloud service is seamless auto-provisioning.
Making the auto-provisioning process and the resulting cloud infrastructure secure might not be as easy as it looks. Starting with the easiest cases first, here’s a look at cloud security issues for a variety of specific multi-tenant cloud services.
Software as a Service (SaaS) is really just a large-scale Web application solution. Any experienced software development team should be able to design, develop and deploy a secure application with strict isolation between groups of users. Note: Make sure you don’t fall into the “We already have software developers, so let’s use them” trap. Just because someone can spell HTML, Java Script, MySQL and PHP does not mean that person can develop secure applications -- as proven by numerous successful break-ins into large organizations using banally simple tools like SQL injection or cross-site scription (XSS).
Database-as-a-Service security should also be pretty straightforward. Create a separate database for each customer and let customers create their own users. You should be worried about break-in attempts and denial-of-service attacks, so you might want to monitor authentication failures and implement automatic blacklist filters if your database software doesn’t provide that functionality.
Desktop-as-a-Service, also known as Virtual desktop infrastructure (VDI), is another service with a clear-cut fix: Deploy a separate virtual machine for each customer, and protect them with passwords or (even better) two-factor authentication. Note: When deciding on a two-factor authentication solution, try to make it as simple and as ubiquitous as possible. For example, Google just launched 2-step verification that uses your mobile phone to send you the second password you need to log into Gmail.
To protect the users’ virtual machines, use private virtual LANs (VLANs)offered by VMware’s vSphere 4 virtual distributed switch (vDS) or Cisco Nexus 1000V. A private VLAN ensures that a virtual machine can communicate with adjacent routers that provide connectivity to the Internet, but not with virtual machines in the same VLAN (thus preventing hacking attempts among Desktop as a Service users).
You should also rely heavily on the inherent firewalling capabilities of the operating system used in your VDI offering. Implementing proper security at host OS level is always more effective than trying to secure badly configured systems with a central firewall. Using virtual machine templates and centralized management/software update tools make the process manageable.
Infrastructure as a Service (the offering formerly known as hosting or colocation) is probably the hardest to secure, although there are numerous security design and implementation options.
- The traditional approach is to push the security burden toward your customers. While this approach makes your life easier, enterprise customers trying to migrate existing applications into the cloud will not be delighted to discover all the protection mechanisms they’ve assumed during the application development phase are gone.
- Minimal security. This effort provides baseline security. For example, allow only HTTPS (HTTP over SSL or HTTP Secure) and Secure Shell (SSH) access to customer virtual machines. This approach, which is similar to the one used by Amazon Web Services, might work well for new applications (and startups), but it still fails the expectations of enterprises trying to offload their existing workload into the cloud.
- Private VLANs. You could use private VLANs to offer better rudimentary security -- at least your customers won’t be able to attack each other. Private VLANs are a good fit to scale out shared-database applications (for example, typical Web applications) because the Web servers don’t need to communicate with each other directly.
Distributed computing applications or typical enterprise workloads with a spaghetti mess of Remote Procedure Call (RPC) and Simple Object Access Protocol (SOAP) services require direct communication between virtual machines belonging to the same customer, forcing you to deploy a separate VLAN for each customer. Most networking devices cannot support more than approximately 4,000 VLANs, making this approach somewhat non-scalable.
You can successfully deploy a PVLAN-based approach if you’re willing to segment your data center into smaller blocks, tie each customer to one of the blocks, and use routing between them. If your data center architecture asks for end-to-end omnipresent VLANs to support limitless VM migration, you’re out of luck.
Virtual appliances. A successful IaaS implementation allows your customer to deploy new virtual machines with just a few clicks, preferably starting with predefined templates. You can use the same approach to offer customers click-to-deploy security. Numerous vendors offer virtual security appliances, including VMware’s security suite (vShield Zones, vShield App, vShield Edge, all of them managed with vCloud Director), Cisco's Virtual Security Gateway, Juniper's Altor Virtual Firewall and Vyatta's virtual firewall. You could give each customer a separate VLAN and allow customers to either connect the VLAN directly into the Internet or plug a virtual firewall between the VLAN and the rest of the network (Vyatta and Yunteq have announced that service).
Need for customer trust crosses all cloud security services
Regardless of the type of cloud services you offer and the security mechanisms you use, don’t forget that what matters most is that your customers trust you. Residential consumers are usually easy -- most of them are happy as soon as you tell them you back up their data and they see that their data is password-protected. Just make sure you don’t stumble into a major disaster.
Enterprise users are more demanding. Some will ask you to document your security mechanisms and processes. A few will have to audit your security to meet their internal compliance requirements. If you target the enterprise market, be prepared. Document your processes, get a relevant security certification (the cloud services subsidiary of my company decided to go for ISO 27001), and work closely with your customers to ensure their security/compliance needs are met.
About the author:Ivan Pepelnjak, CCIE No. 1354, is a 25-year veteran of the networking industry. He has more than 10 years of experience in designing, installing, troubleshooting and operating large service provider and enterprise WAN and LAN networks and is currently chief technology advisor at NIL Data Communications, focusing on advanced IP-based networks and Web technologies. His books include MPLS and VPN Architectures and EIGRP Network Design. Check out his IOS Hints blog, and ask him your networking questions at SearchTelecom.com's Ask the Expert.