So you've been offered a Cloud solution. Sounds compelling. No upfront cost, dump your old server and let the experts manage your data at a 'surprisingly affordable monthly rate'.
But wait - the basic premise is, you have to hand over one of your most valuable assets - your data. As a manufacturer, you probably possess commercially valuable data: Product recipes that took years to perfect. Know-how, job costings and quality records that you wouldn't want to make public. All in a perfectly good system that aint broke.
So the critical question is, is your data really secure?
In six months you might be wondering, do I still own my most valuable asset? Has it leaked to the public now? And if system response speed in practice falls short of assurances and is restricting productivity can I roll back? To which the true answer maybe N Y N
The fundamental technical reasons why your data is not safe in a cloud application: Explained by a cloud developer:
There's a saying in gambling, don't bet it if you can't afford to lose it.
In the same sense, if you can't afford to lose your data, don't key it in to a browser. Here's why:
Cloud by definition means conceding the storage of your data to a public location. The proposition may initially sound appealing - someone else will take expert care of your data, and eliminate the need for your own IT staff. Cost-sharing by multiple customers on the same server, reduces capital expenses. However, this promise is flawed due to fundamental security vulnerabilities in the cloud application itself, as described below.
It's important to recognize that any security measure is only as strong as its weakest link. In the case of cloud applications, the browser is that weak link. Browsers are public domain software, and even the widely used commercial browser vendors release frequent updates to patch security vulnerabilities. This should raise concerns. Any user can right-click on a page to 'view source'. It's possible to edit that source in a text editor and then re-submit it to the server using the browser. It's like a hackers christmas wish..
A story of two halves:
To develop a cloud application, two different components are constructed, each by necessity in a different language: the browser program code and the server code. The browser program code, written primarily in HTML, is responsible for building the user interface (UI), presenting questions to users, and presenting data output from the server. On the other hand, the server code is paired to respond to the requests made by the browser and fetches or modifies the necessary stored data based on browser instructions.
The fundamental security issue arises from the fact that the server has no knowledge of which browser it is interacting with. As cloud technology requires the server to listen publicly to all users connecting via a browser, customized and unexpected requests from the browser can lead to unintended data retrieval or editing. This vulnerability is commonly exploited through attacks like SQL Injection, where malicious queries can be executed by manipulating the browser's request. This lack of identification and authentication poses a difficult variable challenge for the developer in maintaining security.This makes cloud servers favourite targets for hackers who can easily launch brute-force attacks on passwords.
In contrast, a local client/server network has several inbuilt mechanisms at operating system level to validate users' identities, such as Windows login credentials and physical device information, ensuring a secure environment limited to specific physical devices.
A fundamental technical fact is that as soon as you do something online, it is no longer private. Regardless of any masking tools or precautions you take, at the very least your ISP records all the data you uploaded and downloaded. Packets of data can also be intercepted and copied anywhere in the transit path. The concept of privacy becomes void the moment you connect to the internet. If you require privacy, you must keep data traffic internal.
And remember that browsers are fundamentally unreliable. Try this. Click the browser Back button a couple of times and then the Forward button. Thats a developer’s nightmare, how to trash a cloud application in one easy lesson. At this point all bets are off.. you’ve probably trashed critical data. Developers live in hope you won’t discover that hole because there’s no way to detect what happened and they won’t be able to blame you for their system spontaneously losing data.
Conclusion?
It is a valid reservation to be nervous about the reliability and security of a cloud application.
Decide whether you're being sold Cloud because it's a trendy name or because you really do want to share your data publicly.
If you're being offered a Cloud solution, consider these factors:
It's not really secure. And it's not really dependable. It could lock you out at any time for a variety of reasons. In the end the outage will turn out to be 'nobodys' fault. By design, its going to go slower at peak times.. consider the irony of that.
It's not really cheaper. Consider total cost of ownership (TCO) by reading the fine print. Software vendors are rapidly scrambling to the cloud, not out of generosity, but because the recurring revenue income is favored by their shareholders. It's important to weigh the sacrifices made for the 'no deposit lease' option. There are increased ISP costs, new devices, implementation consulting, and upfront training fees. There are some ways to mitigate the security issues detailed above, such as a private cloud VPN. But that’s not Cloud then is it? You’re just reverting back to a private Server VPN at an additional cost.
It’s not really opt out anytime you feel like it. Implicitly, Saas means a Term Contract. Check the initial term. You cannot break the term whether happy or not. It might be paid monthly but you can bet its not cancel on a months notice. You will be chained to it for a lot longer than that. And by the time you've finished the initial term you will have put so much data 'under the bridge' so to speak, that winding it all back and restoring your old 'good' system will be impractical and costly. Once you commit to the cloud solution, it becomes a one-way path. If you ever have the slightest disagreement with your vendor over payments you will suddenly realize who effectively owns your data now.. and it's not you..
This week I had two frustrating Unresponsive Pages outages on the internet. Something I wanted to watch, something I wanted to do. Had to 'try later' when it no longer mattered. I’m glad I don’t use cloud apps for anything mission critical. I’m glad it didn’t affect an ontime delivery.
Sure you could take the risk. Maybe it wont go down at a critical time.
But why introduce a severe risk to your business that is completely unnecessary? With your existing Client Server setup, internet outages will simply never affect your business software!
There are no doubt many organisations who have no data privacy requirements and can operate relatively effectively on an unreliable platform, which can credibly benefit from a cheap solution offered by a public cloud environment. The Manufacturing sector is likely not one of them.
References:
https://geek911.com/reasons-not-move-cloud/
https://workflowotg.com/four-reasons-not-to-move-to-the-cloud/
https://www.projectcubicle.com/7-cloud-computing-risks-and-how-to-avoid-them/