10 Workloads That Should Never Go in 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.Security is the primary reason you should never consider deploying any these 10 workloads to a public cloud.
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.
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.
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.