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]> 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/
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 google-
[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
.
--
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 google-
[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
.
