Cloud Computing: problems and potential solutions
Cloud computing is hot enough for Microsoft to get involved. However there are at least 2 big issues with CC: security and vendor lock-in.
To avoid vendor lock-in, one needs to be able to save the data locally which are sent exclusively out to the Cloud. This means that the browser has to be modified to be able to save a copy as well as send it out to Cloud. Also be able to restore it from the saved data to alternate Cloud. Note that this "saved data" can be encrypted and preserved onto yet another Cloud.
To improve security, one way is to encrypt the data at the point of the browser so that the entered data isn't directly sent: Names can be scrambled and sent as "bogus" string. Bigger challenges are numbers and dates. As long as these data belong to one person, then unique offset constant can be used to store data. The problem is with sharing the data among more than one person. One alternative method would be to use unique offset per, say, date field. (For example, birth dates are all offset by 250 days while "entry date" (or due date) is offset by 3 days and these offsets are stored and shared via a different Cloud service [and encrypted as well, of course.]) For numbers, common numbers would need same offsets, unfortunately, or else the math won't add up. (Hmm: maybe a new math is possible? Like, if one is Safesforce.com customer, using predefined algorithm to construct an encrypted processing engine?)
Copyright 2008, DannyHSDad, All Rights Reserved.
To avoid vendor lock-in, one needs to be able to save the data locally which are sent exclusively out to the Cloud. This means that the browser has to be modified to be able to save a copy as well as send it out to Cloud. Also be able to restore it from the saved data to alternate Cloud. Note that this "saved data" can be encrypted and preserved onto yet another Cloud.
To improve security, one way is to encrypt the data at the point of the browser so that the entered data isn't directly sent: Names can be scrambled and sent as "bogus" string. Bigger challenges are numbers and dates. As long as these data belong to one person, then unique offset constant can be used to store data. The problem is with sharing the data among more than one person. One alternative method would be to use unique offset per, say, date field. (For example, birth dates are all offset by 250 days while "entry date" (or due date) is offset by 3 days and these offsets are stored and shared via a different Cloud service [and encrypted as well, of course.]) For numbers, common numbers would need same offsets, unfortunately, or else the math won't add up. (Hmm: maybe a new math is possible? Like, if one is Safesforce.com customer, using predefined algorithm to construct an encrypted processing engine?)
Copyright 2008, DannyHSDad, All Rights Reserved.
Labels: Cloud Computing, redundency, software security
posted by DannyHSDad at
8:03 PM
