Keeping sensitive information in memory

[Alexander Konovalenko]

I am going to process sensitive information in my app and want to
prevent it from ever getting written to disk in an unencrypted form. I
hope that all disks in the Google data centers are properly sanitized
before being disposed of (are they?). But defense in depth never
hurts.

The processing of sensitive data will occur both in front-end and
back-end instances. The data has to be stored unencrypted in memory.
Do the appservers running Python and Java instances use any form of
unencrypted swap? SSD, hard disk, whatever. If so, I will file a
feature request to provide a way to lock memory pages from being
swapped out (using the mlock() system call). Note that even when there
is plenty of free RAM, the OS can still swap some pages out.

Alexander

[Philip]

Check this video: http://www.youtube.com/watch?v=1SCZzgfdTBo

They crush all disks.

[Brandon Wirtz]

Don't do sensitive stuff on servers you don't own. GAE is safer than most
things, but you don't know what lives in logs, who has access to logs, lots
of things.

Look in to services that meet HIPPA compliance for hosting, (I don’t believe
GAE does at this time)

Also be aware you don't know where your servers are "in the US" so you also
shouldn't use GAE if you have to comply with State laws about storage or
transmission of sensitive data.

They crush all disks.

--
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-a...@googlegroups.com.
To unsubscribe from this group, send email to
google-appengi...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.

[Nick Johnson]

Hi Alexander,

We don't generally talk in detail about our datacenters or our security infrastructure externally, but some information is available. The link Phillip provided goes into some details, and this article about our security certifications, and the links from it regarding our data security statements should be relevant:

http://googleenterprise.blogspot.com/2011/08/security-first-google-apps-and-google.html?utm_source=entblog&utm_medium=blog&utm_campaign=Feed%3A+OfficialGoogleEnterpriseBlog+%28Official+Google+Enterprise+Blog%29

-Nick Johnson

--
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-a...@googlegroups.com.
To unsubscribe from this group, send email to google-appengi...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.

--
Nick Johnson, Developer Programs Engineer, App Engine

[Alexander Konovalenko]

On Wed, Oct 5, 2011, Nick Johnson <nickj...@google.com> wrote:
> Hi Alexander,
> We don't generally talk in detail about our datacenters or our security
> infrastructure externally, but some information is available. The link
> Phillip provided goes into some details, and this article about our security
> certifications, and the links from it regarding our data security statements
> should be relevant:
> http://googleenterprise.blogspot.com/2011/08/security-first-google-apps-and-google.html?utm_source=entblog&utm_medium=blog&utm_campaign=Feed%3A+OfficialGoogleEnterpriseBlog+%28Official+Google+Enterprise+Blog%29

Hello Nick,

Thanks for the link. Because I did not receive an answer to my
question, I will assume that you may use swap. So I went forward and
filed a feature request to support mlock() in Python and Go runtimes.

http://code.google.com/p/googleappengine/issues/detail?id=6041

Alexander

[Nick Johnson]

Hi Alexander,

Is potential usage of swap really relevant here, given what we've made public about how we treat our drives? What is your threat model?

-Nick Johnson

 

http://code.google.com/p/googleappengine/issues/detail?id=6041

Alexander

[Alexander Konovalenko]

On Wed, Oct 5, 2011 at 11:55, Nick Johnson <nickj...@google.com> wrote:
>
> Is potential usage of swap really relevant here, given what we've made
> public about how we treat our drives? What is your threat model?

I want to minimize potential exposure of previously processed
sensitive information in case of an appserver compromise. After all,
appservers run arbitrary user-supplied code. I'm sure your sandboxing
is good, but the risk is still high. Suppose some appservers are
compromised on June 1 and are fixed on June 15. If sensitive data is
only ever stored in memory, just the data that was processed between
June 1 and June 15 might have been affected. If there might be any
remnants of the data on disks, *all* previously processed data might
be affected. And that's what I'll have to say to my clients. (If you
won't tell us about the compromise, that's another story.) So
unencrypted swapping effectively makes me unable to delete data
permanently when it is no longer needed.

mlocking() provides defense in depth. On disks information can live
for much longer than in RAM. If sensitive data doesn't have to be
stored on disk, we'd better make sure it never is.

Alexander

[Murph]

To be honest, if any part of the GAE servers are compromised, they have your entire application (everything you've uploaded) and data right there, if they have full control over the server host.  Securing the system's memory & swap is not going to offer terribly much at that point.

This is just somewhere you're going to have to trust Google to get the security perimeter of the servers and network absolutely perfect.  If trusting them with that is too high a risk for your data, then frankly you shouldn't be on GAE, and probably shouldn't be on any external cloud solution.

[Tim Hoffman]

Agreed, they could upload a new version of the app undermining anything you might have done.