Download the authoritative guide: Enterprise Data Storage 2018: Optimizing Your Storage Infrastructure
I think everyone agrees that if you are going to move data to a cloud (unless it is your own private cloud) it must be encrypted and even then it should be carefully considered.
Most home Internet backups, from various vendors, provide the encryption key. I currently have two backup vendors for my home PCs, being the paranoid person that I am. But I honestly let both vendors handle the encryption.
That might be fine for home backups but it’s not going to be okay for operational usage with tens to thousands of users for any small medium or large company for daily data not backup. The issues are large and complex when deciding what to do or not to do with key management, and your goal needs to be to protect your data and meet all legal requirements (Sarbanes/Oxley, HIPPA, etc).
Here is what I see the issues are:https://o1.qnsr.com/log/p.gif?;n=203;c=204650394;s=9477;x=7936;f=201801171506010;u=j;z=TIMESTAMP;a=20392931;e=i
1) Who controls the keys and has access to them?
2) How do users interface with their keys and what happens when a user leaves?
3) When do the keys get applied to the data?
4) Who is responsible if bad things happen?
The first question I would ask a cloud service provider is: can they read my data?
If the cloud provider has access to the keys by providing the key management system, you need to be concerned if there is any possible way that a rogue employee with access to the keys and the systems could access your data.
If this is even a potential you likely need to determine if you have legally liability if it happens. More than likely if you are aware of the remote possibility, you are likely liable if, say, someone accesses patient records.
Let’s say that you are responsible for key management. In that case there are a variety of questions to ask.
For example, do you have the experience and understanding of the key management system to administrate it?
What happens if the administrator leaves or goes rogue? What needs to happen in an organization is a very solid well thought out plan to ensure that no one person has all of the information and knowledge. Temper that with the knowledge that if everyone has access to the keys, the only thing you’re protecting yourself from is the cloud – provided that none of your staff are selling the keys on the black market.
Key management control needs to be well designed and well thought out for the long term if you are going to move data to the cloud. You cannot assume that everyone will stay forever. Most important, I think that companies have the responsibility to manage and control their encryption policy – this should not be left to the cloud vendor, given the potential liability.
I see a number of types of user issues, chiefly:
1) How do users interface with their keys and what happens when a user leaves?
2) Is the system simple enough for the non-technical employee?
3) What if a user forgets their key?
4) What if a user changes their key and does not tell you and leaves?
Any key management system must allow for all levels of skills and computer knowledge. It must address issues of file ownership after someone leaves or is on extended leave, for example.
Who has the right to look at the files and who does not have the rights? How are accesses logged, such that you know if someone is sharing keys or there is an attempt to break in and get your files? Is the key management logging safe from a smart hacker? What happens if a user forgets their keys? We all can forget stuff, or there could be a medical issue or physical reason (head injury, for example) that causes this. What are the processes and procedures when this happens? You of course do not want users writing down the keys on Post-It Notes. It is not if, it is when a user forgets their keys – at which point it will be too late to institute a procedure.
The last issue I listed is about the malicious user and how you control what happens if they change keys and do not tell you. San Francisco learned this the hard way with their network passwords (see the case of the rogue admin). You need to think about the possible events and the required outcome to ensure that your operations are protected against this event.
When do the keys get applied to the data?
One of the questions I always ask is: when do the keys get applied to the data? And that leads to a related question, which is: when are hash checked to ensure that the data is not corrupted?
If your data is encrypted by an application running on your cloud provider, what happens to the data that is currently on your local systems? Do you move it up the cloud and then apply encryption? Is the data validated between your local system before you turn it off, and once it is in the cloud? These are two important questions to consider.
I have no issues with the cloud vendor running the key management application, but there are two things to consider. One is, do you want to transfer your data over an unprotected unencrypted network?
If you don’t have a VPN between you and the cloud provider and are just using the Internet, your data is at risk in flight. Of course the risk is small but for things like HIPPA and Sarbanes/Oxley compliance data, do you really want to fines that are associated with the risk?
The second issue to consider is data integrity. If you are moving large amounts of data between you and your cloud provider, the likelihood of a silent data corruption during the movement is pretty high. You can search “network silent data corruption” but here is a good article (look for Silent Data Corruption, SDC). It’s more prevalent that you think.
You need a plan that ensures that all of your data gets from your current system to the cloud with a near 100% assurance that the integrity in intact. This means that you need, in my opinion, to encrypt the data on our own machines and ensure that the hashes are created. Move the files to the cloud system and validate every hash for every file.
You also need this procedure for every file that will be moved from local systems to the cloud in the future. As I have said time and time again, silent data corruption is real and you need to protect yourself from it.
Who is responsible if problems occur?
Remember when Ronald Regan was shot and Al Haig said he was in charge? Well, there needs to be a plan for someone to be in charge and well defined roles of responsibility if something really bad happens.
Remember the RSA breach of security that led to significant issues for a number of companies? In each company that was vulnerable, I’m pretty sure there was an action plan to prevent a security breach. And for those that did not they were attacked and there was a breach.
I know from some friends that prevented a breach that there were some key things that needed to be done. Those who did not do those key things were attacked and the rest is history.
This is going to be no different than what will be needed to protect your data in the cloud environment. Putting data into the cloud means that more than likely there are far more entry points into the system – especially if you are not using a VPN.
So let’s say you get your key management system from the cloud vendor but you are responsible for the management and the cloud vendor had a security breach. Who is in charge? These kinds of n-case events must be decided before they happen, not afterwards.
When moving your data into the cloud, key management is one of the critical planning items that must be planned and implemented. I have covered a few of the areas I think are important as part of the planning process, but this is not an exhaustive list. And each one of you that is thinking of moving to the cloud needs to do the planning that is appropriate for your business and workflow.
Using the cloud presents some new challenges for storage, with encryption being in my opinion one of the critical areas that needs to be well thought out. A plan needs to be written down and updated as things change, and executed when something happens.
Without this type of rigor you are potentially at risk for something bad happening, especially if you have legal obligations.