Awesome RavenDB Feature of the Day: Encryption
Join the DZone community and get the full member experience.Join For Free
another upcoming feature for the next ravendb release is full encryption support. we got several requests for this feature from customers that are interested in using ravendb to store highly critical data. think financial records, health information, etc.
for those sort of applications, there are often regulatory concerns about the data at rest. i’ll state upfront that i think that a lot of those regulations make absolutely no sense from a practical standpoint, but…
the end result is that we can never put any plaintext data on disk. which result in some interesting problems for our use case. to start with, it is fairly easy to go about creating encryption for documents. they are independent from one another and are usually read / written in a single chunk. in fact, there have been several articles published on exactly how to do that. the problem is with indexes , which are not read as a whole, in fact, we have to support random reads through it.
in the currently released version, you could encrypt documents using a custom bundle, but you can’t get real encryption across the board. this like in flight documents, partial map/reduce data and the indexes themselves will not be encrypted and be saved in plain text format, even with a custom bundle.
in the next version of ravendb (this feature will be available for the enterprise version), we have made sure that all of that just works. everything is encrypted, and there is no plain text data on disk for any reason. ravendb will transparently encrypt/decrypt the data for you when it is actually sent to disk.
by default, we use aes-128 (you can change that, if you want, but there is a not insignificant hit if you want to just to aes-256 and it is just as secure, barring a quantum computer) to encrypt the data.
the funny part (or not so funny part) is that the actual process of encrypting the data was a relatively straightforward process. we had to spend a lot more time & effort on the actual management aspect of this feature.
for example, encryption requires an encryption key, so how do you manage that?
in ravendb, we have two types of configurations. server wide, which is usually located at the app.config file and database specific, which is located at the system database. for the app.config file, we provide support for encrypting the file using dpapi, using the standard .net config file encryption system. for database specific values, we provide our own support for encrypting the values using dpapi.
so, the end result is:
- your documents and indexes are encrypted when they are on disk using strong encryption.
- you can use a server wide or database specific key for the encryption (for that matter, you turn on/off encryption at the database level).
- your encryption key is guarded using dpapi.
- obviously, you should backup the encryption key, because we have no way of recovering your data without it.
- the data is safely encrypted on disk, and the os guarantee that no one can access the encryption key.
and, finally: you get to tick off the “no plaintext data at rest” checkbox and move on to do actual feature development .
Published at DZone with permission of Oren Eini, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.