10 Workloads That Should Never Go in a Public Cloud

Thursday Jan 27th 2011 by Kenneth Hess
Share:

Security is the primary reason you should never consider deploying any these 10 workloads to a public cloud.

Cloud discussions aside, business is risky enough without adding another unknown variable to the equation. The public cloud offers inexpensive computing power, rapid application deployment, elastic bandwidth allocation and a slew of security problems. However, the risk isn't necessarily the fault of the public cloud provider, it's yours. When you deploy a workload to the cloud, you're exposing it to the entire planet, and not all of the planet's inhabitants are benevolent, productive members of society. There are those who would steal your information, ransom it or display it to all the world's eager eyes.

If you don't believe there's a problem with public cloud offerings, look at this recent warning from the European Union to its members. You should never deploy any of these 10 workloads to the public cloud unless you're willing to absorb the legal and financial impacts of their impending decimation.

Note that this discussion focuses on self-deployed applications and services -- not those sold by cloud-based software companies or hosting providers.

1. Databases

Databases aren't inherently insecure, but the applications that access them can be, and that spells disaster for your data. It's possible to add protection for your data with practices, such as tunneling the connecting between your application and the database, scrubbing the data before attaching to the database, and always using secure protocols and certificates when processing data.

2. Email

Placing email services on the Internet is equivalent to placing a neon sign outside your house that reads, "We're not home and we've left the doors unlocked." If you're thinking security through obscurity will help you, don't go there. Changing the port numbers has no effect. If you want your private email read by the world, set up your email services in the cloud. Unlike databases, email protocols are inherently insecure. It is possible, however, to make email more secure by using secure protocols and signed certificates.

3. Monitoring and Performance

The data generated by monitoring and performance software might seem mundane and unintelligible to all but a select ilk of IT specialist. However, this data holds valuable information concerning system names, system types, vulnerabilities and architectures. By exposing this information to the world-at-large, you're leaving yourself open for an attack on your systems like Jackals attacking the weakest in the herd. It's best to keep your monitoring and performance data secreted behind your own firewall.

4. Customer Relationship Tools

There are some excellent cloud-based customer relationship management tools available at very low cost. Use them instead of spinning your own solution. Unless you're a crack programmer or have one in your organization, leave the complexities of those systems to professional providers. If your customer base and information fall to predators, you'll have no recourse except in the court system -- with you as the defendant.

5. Ticketing Systems

Your ticketing system and data should remain in your own network. Why? A ticketing system can reveal weaknesses and exploits in your software that you don't want revealed to the general public. As long as your system's database is inside your network, getting past your firewall and other security measures may prove too difficult for would-be attackers.

6. System Administration Applications

Should you really want to compromise your systems, their data, and your integrity, deploy a system administrative tool to the public cloud. The fireworks will be impressive. Your systems will mostly likely find themselves repurposed into SPAM engines or a convenient hop for crackers who need a safe jump box from which to leap into another network. Keep system administration tools quietly tucked away on your local systems. Don't worry, you can still manage your remote systems with the local tools.

7. Customer Processing

If you've set up your own online customer processing system and deployed it to a cloud-based provider, I hope you aren't storing the data in a cloud-based database system (See No. 1 Databases). The solution is to securely process the credit card information and destroy it when the session is complete. There's no need for you to store credit card information. If you do indeed have such a need, store these numbers inside your own network on a secured database system.

8. Marketing Applications

Home-grown marketing applications installed on public cloud servers will mostly likely provide your competitors with some easy pickings via your friendly neighborhood hacker. Leave such applications and security to the teams of developers and security folks who make sure data is safe and protected. Although, not 100-percent effective against malicious behavior, you're better off letting someone else handle the stress. The alternative is to run the application on your own internal systems.

9. Business Intelligence

Business Intelligence (BI) includes an encyclopedia of information about your company, its inner workings, customer base, profitability, project information, statistics, inventory and whatever else you want to include. Do you really want to risk this information in the public cloud? If you do, you should know that your self-deployed system could face an onslaught of cyber tapping that might result in much shuffling and excuse-making at the shareholder meeting. Do yourself a favor and use one of the commercial solutions -- if you're bent on using cloud-based infrastructure and software. Otherwise, play it safer by deploying your BI system in-house. Alternatively, there's always pen and paper.

10. Deployment Services

New system deployment services, such as Windows Deployment Services (WDS), require a very high level of security and shouldn't be cloud-deployed unless you comply with this stipulation. Like the other services in this list, commercially deployed and supported versions exist. Competitive pricing and convenience rival anything you can put together yourself, and you can place your security concerns on the shoulders of your provider.

Ken Hess is a freelance writer who writes on a variety of open source topics including Linux, databases, and virtualization. He is also the coauthor of Practical Virtualization Solutions, which was published in October 2009. You may reach him through his web site at http://www.kenhess.com.

Follow ServerWatch on Twitter

Share:
Home
Mobile Site | Full Site
Copyright 2017 © QuinStreet Inc. All Rights Reserved