On Wed, 26 Oct 2011 06:17:28 +1100
Justin Clift <jclift(a)redhat.com> wrote:
With the way HekaFS is encrypting data (tenant specific certs),
it's
pretty clear the data will be safe "at rest".
How do we protect against the hosting provider from reading
certs/keys out of tenant memory while it's running, and keeping them
for later?
Asking because apparently it isn't hard to extract encryption
passwords from traditional encrypted file systems if they're running
in a VM (and you're superuser on the host). So, same thought, but
with the certs.
Right now we keep certs and keys away from the HekaFS (GlusterFS)
servers, but they're still vulnerable on the clients. If the clients
are also in a public cloud, then the public cloud provider could get
them from memory as you describe. Unfortunately, there's not much one
can do about this. Those keys have to exist in memory at least during
the lifetime of an I/O, and as soon as you do that you're vulnerable to
trapping and freezing the instance to get it.
In a way, this is where the future replication/caching features of
HekaFS really become essential. If you want to put your storage in the
cloud but run private clients somewhere else to avoid this particular
vulnerability, then you're going to be dealing with higher latency.
However, with caching at the client side you can avoid that latency
most of the time and also get the full advantage of client-side
encryption. Otherwise you're stuck choosing between security and
performance.