Encryption might be the right solution for your application, but it does carry some significant limitations on your ability to use app engine and increases your app's complexity significantly.
If you intend to encrypt your data, you will need to consider the following issues (and probably more besides) 1. Encrypted data can be very difficult to query. Consider the query "SELECT * FROM Document WHERE author = 'Joe' AND tag = 'Science'". Both the author and tag fields cannot be encrypted, unless you intend to also encrypt the query values. If you intend to encrypt these fields as well, then things like ordering your data correctly become very difficult. Debugging your queries won't be much fun either. Some queries (such as those that match the beginning of a string) will not be possible. 2. You need to decide whether you intend to encrypt the data on app engine, or in the client (probably the browser). If you intend to do it on app engine, then the means of encryption and decryption need to form part of your uploaded application, and you need to consider how you will protect the *means* by which data is encrypted and decrypted. In this situation, the data will spend some time on app engine in an unencrypted state. If you intend to encrypt in the browser, then you seriously limit the useful work you can do with the data on app engine. 3. If you intend to use the task queue, you may need to encrypt the data in your tasks as well. 4. You cannot encrypt your application code - I'm not sure if google does this for you, but I suspect not. 5. Structured data is more difficult to maintain if it is encrypted. Consider the following database model class Person(db.Model): name : StringProperty() address : StringProperty() email : StringProperty() .... To truly encrypt all of your data on app engine you would need to encrypt each of these fields separately, or combine them into a single encrypted field, which will make querying on them almost impossible. 6. Application logs are probably not encrypted (I doubt they are, but not sure), and you need to be careful what data is exposed in your logs. 7. Using the admin console to look at your data will be next to useless. Your next best option would probably be an implementation based on either the custom admin pages or the remote API. 8. Encryption reduces your application performance. So when you say it does not hurt to encrypt, that may be true for your application, but encrypting data in the data store presents significant barriers for most applications, and can seriously limit the amount of value you can get out of app engine. For most applications it makes a lot of sense to understand the security around the datastore itself, and see encryption as last resort. If all you need is a cloud based data storage solution where you dump encrypted blobs of data, then you may get better mileage using Google storage for developers - http://code.google.com/apis/storage/ I'm trying to highlight that data encryption on app engine is not actually a very simple solution to data security for most classes of application. Given this is the case, its a pity the only other option is to assume it is not secure - knowing what security measures google has in place would be a real help for the majority of classes of application. On May 22, 11:01 pm, Keren Or Shalom <[email protected]> wrote: > I believe that the cloud is the solution and it does not hurt to encrypt. > > My requirement is very stringent because if I succeed my system would become > systemic. > > On 23 May 2010 00:38, hawkett <[email protected]> wrote: > > > > > > > I don't necessarily disagree with the approach - depending on your > > organisation, it will probably provide the most reliable data > > security. > > > All solutions carry a risk of a data breach, however, and the > > encryption solution is no different. One of the arguments for cloud > > data security is that organisations generally over-estimate their own > > ability to secure their data, and that cloud data is actually more > > secure - precisely because the cloud vendor has greater capability > > (knowledge, processes, people, infrastructure) to provide that > > security. From this perspective it may be *less* responsible to do > > data security in-house. > > > So my point is that when a someone asks 'What is the data security > > situation with app engine' - it would be nice to do better than 'you > > better encrypt it'. Encryption might be the right answer for your > > organisation - but some information from google around auditing > > processes, employee access policies, notification when your data was > > accessed, the reasons why your data might be accessed etc. would > > probably lead most businesses to opt for a solution that didn't > > involve them taking on the security burden themselves. Most > > businesses would say 'ok, that sounds good - I understand breaches can > > happen, but it sounds like you guys are pretty organised and take this > > stuff seriously'. > > > I'm sure google has a great many policies and procedures in place to > > secure app engine data, but when the presented options are 'encrypt > > it' or 'we'll look at it if we want', well, its a much harder sell. > > > On May 22, 8:44 pm, Keren Or Shalom <[email protected]> wrote: > > > I don't believe it would be responsible for any business to count on the > > > goodwill of a provider no matter how good his reputation to preserve the > > > security of strategic data. It does not matter what might be the promise > > of > > > Google I think the only way is the way that Geoffrey propose. > > > > On 22 May 2010 21:07, hawkett <[email protected]> wrote: > > > > > Hi Geoffrey, > > > > > I'm sure you didn't mean your response to come across this way - but > > > > it reads - 'encrypt your data, or expect google to look at it for > > > > whatever reason they see fit'. As this thread alone shows, data > > > > security is of huge importance to many people using or considering the > > > > use of app engine. > > > > > Is this approach to data security also your perception of app engine > > > > for business? > > > >http://googlecode.blogspot.com/2010/05/announcing-google-app-engine-f. > > .. > > > > > Sorry for the semi-rant, but it's hard work convincing folks to put > > > > their data in the cloud, and every authoritative (you are listed as an > > > > API guru) statement that erodes their perception of the cloud vendor's > > > > security practices makes that job harder. I guess this highlights > > > > again the need for unambiguous statements on this - probably in the > > > > form of an SLA. I recommend that anyone who has similar concerns star > > > > this issue - > >http://code.google.com/p/googleappengine/issues/detail?id=501 > > > > - raised nearly 2 years ago. Ironic that the issue id is '501' - HTTP > > > > speak for 'Not Implemented'. Some kudos though for starting that > > > > process as of a couple of days ago - > > > >http://code.google.com/appengine/business/sla.html, > > > > despite the lack of data privacy clauses. As noted in the issue, the > > > > number one concern is data privacy, not uptime. > > > > > Colin > > > > > On May 21, 2:08 pm, Geoffrey Spear <[email protected]> wrote: > > > > > On May 21, 4:20 am, Madame Or <[email protected]> wrote: > > > > > > > Given the high sensitivity of my data it is very important that no > > one > > > > > > except of course the individuals I would allow and the software I > > > > > > would enable to access the data stored in that BigTable. Hence I > > would > > > > > > like to know also if it is possible to prevent anyone, including > > > > > > Google, to have access to my data stored in BigTable? > > > > > > There's no way to prevent Google from accessing anything stored on > > > > > their servers. It's unlikely they'd do so without a good reason, but > > > > > if you want to ensure security, use strong encryption. > > > > > > -- > > > > > You received this message because you are subscribed to the Google > > Groups > > > > "Google App Engine" group. > > > > > To post to this group, send email to > > [email protected]. > > > > > To unsubscribe from this group, send email to > > > > [email protected]<google-appengine%2Bunsubscrib > > > > [email protected]><google-appengine%2Bunsubscrib > > [email protected]> > > > > . > > > > > For more options, visit this group athttp:// > > > > groups.google.com/group/google-appengine?hl=en. > > > > > -- > > > > You received this message because you are subscribed to the Google > > Groups > > > > "Google App Engine" group. > > > > To post to this group, send email to [email protected] > > . > > > > To unsubscribe from this group, send email to > > > > [email protected]<google-appengine%2Bunsubscrib > > > > [email protected]><google-appengine%2Bunsubscrib > > [email protected]> > > > > . > > > > For more options, visit this group at > > > >http://groups.google.com/group/google-appengine?hl=en. > > > > -- > > > V07768198309 > > > > -- > > > You received this message because you are subscribed to the Google Groups > > "Google App Engine" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > [email protected]<google-appengine%2Bunsubscrib > > [email protected]> > > . > > > For more options, visit this group athttp:// > > groups.google.com/group/google-appengine?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Google App Engine" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<google-appengine%2Bunsubscrib > > [email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/google-appengine?hl=en. > > -- > V07768198309 > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group > athttp://groups.google.com/group/google-appengine?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
