Seems that we are closing on the way to implement the idea.
Although your model seems to fit my needs my system is more like a database of transaction on a bank account. One of the requirement being to make secure transactions through means of payment and electronic means of communications do you have an idea about implementing that. Anyone got an idea of the price of a large scale implementation? On 23 May 2010 17:55, Robert Kluin <[email protected]> wrote: > Keren, > I think it is important to consider the data you are dealing with and > what it means to make it secure. We do something like what you mention. > If you can secure the account number or name or whatever perhaps it is > sufficient. > > One of our apps is effectively a front-end to an accounting system. The > details of transactions on our app are completely worthless to someone > without also having access to info in the accounting system. The backend > system runs on secure client-site servers and talks to the GAE app through > an interface. This means if someone had all the GAE data it would be almost > worthless to them. > > Robert > > > > On May 23, 2010, at 10:15, Keren Or Shalom <[email protected]> wrote: > > > As I read your answer I may be found a solution and you might tell me what > it is worth. > > > We could for example encrypt the account number of a customer and not the > transaction or the value of the transaction. > > > This way I could send a query on the encrypted value of the customer > account which wouldn't increase in a significant way the time of treatment? > What do you say? > > > May be you need to know more of why I need security and what the system is > meant to do. > > > On 23 May 2010 16:28, hawkett < <[email protected]>[email protected]>wrote: > >> 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/> >> 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> >> 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> >> 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> >> 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]>[email protected]. >> > > > > > To unsubscribe from this group, send email to >> > > > > <google-appengine%[email protected]> >> [email protected]<google-appengine%2Bunsubscrib >> <[email protected]>[email protected]><google-appengine%2Bunsubscrib >> > > <[email protected]>[email protected]> >> > > > > . >> > > > > > For more options, visit this group athttp:// >> > > > > <http://groups.google.com/group/google-appengine?hl=en> >> 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]>[email protected] >> > > . >> > > > > To unsubscribe from this group, send email to >> > > > > <google-appengine%[email protected]> >> [email protected]<google-appengine%2Bunsubscrib >> <[email protected]>[email protected]><google-appengine%2Bunsubscrib >> > > <[email protected]>[email protected]> >> > > > > . >> > > > > For more options, visit this group at >> > > > > <http://groups.google.com/group/google-appengine?hl=en> >> 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]>[email protected]. >> > > > To unsubscribe from this group, send email to >> > > <google-appengine%[email protected]> >> [email protected]<google-appengine%2Bunsubscrib >> <[email protected]>[email protected]> >> > > . >> > > > For more options, visit this group athttp:// >> > > <http://groups.google.com/group/google-appengine?hl=en> >> 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]>[email protected]. >> > > To unsubscribe from this group, send email to >> > > <google-appengine%[email protected]> >> [email protected]<google-appengine%2Bunsubscrib >> <[email protected]>[email protected]> >> > > . >> > > For more options, visit this group at >> > > <http://groups.google.com/group/google-appengine?hl=en> >> 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]>[email protected]. >> > To unsubscribe from this group, send email to >> <google-appengine%[email protected]> >> [email protected]. >> > For more options, visit this group >> > athttp://<http://groups.google.com/group/google-appengine?hl=en> >> 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]> >> [email protected]. >> To unsubscribe from this group, send email to >> <google-appengine%[email protected]> >> [email protected]. >> For more options, visit this group at >> <http://groups.google.com/group/google-appengine?hl=en> >> 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 at > http://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%[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 at http://groups.google.com/group/google-appengine?hl=en.
